Startseite > Automotive > Von der Anforderung zur fertigen Safety-Software-Architektur

Theorie in die Praxis umsetzen

Von der Anforderung zur fertigen Safety-Software-Architektur

13. Juli 2016, 13:45 Uhr | Von Dietmar Kinalzyk

Safety muss bereits bei der Entwicklung eines Steuergeräts Berücksichtigung finden.

Funktionale Sicherheit muss bereits von der ersten Entwicklungsphase eines Steuergeräts mit in die Prozesse eingeplant werden. Welche Herausforderungen sich dabei ergeben, welches Potenzial AUTOSAR bietet und wie die Umsetzung bei der Entwicklung erfolgen kann, zeigt das nachfolgende Beispiel.

▶ Diesen Artikel anhören

Mit der Veröffentlichung von ISO 26262 im Jahr 2011 waren alle Automobilhersteller und Zulieferer gefordert, die Normanforderungen bei der Entwicklung elektronischer Komponenten und Steuergeräte zu berücksichtigen. Im nachfolgenden Beispiel wird anhand der Entwicklung eines Steuergeräts im Karosseriebereich dargestellt, wie sich Kundenanforderungen in einer funktional sicheren Software-Architektur mit AUTOSAR in einem Body-Controller umsetzen lassen. Dabei werden die Rahmenbedingungen und Analysen auf das E-Gas-Prinzip als Standard abgebildet. Welche ISO-Anforderungen an die Software-Architektur deckt AUTOSAR ab? Wo liegen die Herausforderungen des Projekts?

Prozesse entwickeln

Die Prozesse geben vor, welche Schritte erforderlich sind, um eine erfolgreiche Safety-Entwicklung durchzuführen. Die Entwicklung sicherheitskritischer elektrischer und elektronischer Komponenten erfordert zusätzliche Maßnahmen. Auch die Prozesse, die auf einem etablierten Qualitätsmanagementsystem nach ISO 16949 basieren, müssen angepasst werden. Hauptfelder sind:

Sicherheitsanalysen und Methoden
Ableitung der Sicherheitsanforderungen top-down auf jeder Entwicklungsebene – System, Hardware, Software und Allokation – in einer geeigneten Architektur
Nachweise für Reviews mit entsprechender Tiefe (Inspection) nicht nur formal und technisch (Peer to Peer) erfassen, sondern auch aus Safety-Aspekten.

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Zunächst muss festgelegt werden, was das Thema Safety zusätzlich für das Unternehmen bedeutet. Hierbei wurde festgestellt, dass Automotive SPICE Assessments nicht mehr ausreichen, weil sie zu wenig auf die Produktinhalte eingehen. Bild 1 zeigt, wie Hella die Prozesswelt an die Norm angepasst hat. Die Kernprozesse für System, Hardware, Software und unterstützende Prozesse wurden in Hella Procedures HI-PE-1 erweitert. Die sicherheitsspezifischen Anteile sind in der Procedure HP-GE-569 „Development of electronic systems with safety relevant functions“ ausgelagert.

Funktionen mit Sicherheitszielen und Rahmenbedingungen

Das Steuergerät sollte nach bekannten Sicherheitsnormen entwickelt werden. Das Projekt startete 2011, also zur Zeit der Veröffentlichung der Norm ISO 26262. So spielten die Basisanforderungen der bisher gültigen Norm IEC 61508 in der Übergangszeit auch eine Rolle. Zum Projektstart waren folgende Funktionen mit Sicherheitszielen bekannt:

Steuerung nach ASIL B und ASIL A

Klemmensteuerung: Zündung (Klasse 15), Motorstartfreigabe (Kl. 50)
Schließsystem: Verriegeln mit Safe- oder Double-Lock (Diebstahlschutz: Fahrzeug kann von innen ohne Schlüssel nicht geöffnet werden)
Außenlicht (hinten) mit Notbetrieb

Die Sicherheitsziele wurden vom Kunden vorgegeben. Die Attribute Fehlertoleranzzeit, sicherer Zustand, Warnungskonzept waren nur teilweise bekannt und wurden mit dem Funktionale-Sicherheit-Konzept im Dialog mit dem Kunden erarbeitet. Das Verständnis für die DIA – Development Interface Agreement – als Arbeitsprodukt der Norm war allgemein noch nicht vorhanden. So beschränkte man sich im ersten Schritt auf die funktionalen und technischen Zusammenhänge.

Weitere Rahmenbedingungen waren:

AUTOSAR war als Software-Plattform-Standard gesetzt
Hella-Software-Plattform war als Standard gesetzt
E-Gas-Konzept sollte für die Safety-Umsetzung geprüft werden
Vorhandene Software-Applikationen sollten so weit wie möglich wiederverwendet werden.

Fehleranalysen im Design-Prozess

Auf jeder Ebene im Design-Prozess sind Sicherheitsanalysen gefordert. Hier unterstützen/fordern die etablierten Prozessmodelle wie Automotive SPICE zu wenig.

Auf jeder Ebene geht es darum, systematische Fehler zu vermeiden und zufällige (random) Hardware-Fehler abzumildern. Die Rückwirkungsfreiheit (Freedom of Interference) von Software-Komponenten auf Software-Safety-Komponenten wird in der „Failure Modes Effects and Diagnostic Analysis“ (FMECA) oder Software-FMEA (Failure Mode and Effects Analysis) auf Architekturebene geprüft. Ab ASIL B werden auch die Auswirkungen von sogenannten Soft Errors (Bitflips) überprüft und mit zusätzlichen Redundanzen vermieden. In dem Projekt wurden keine quantitativen FTAs durchgeführt, weil sie nur für ASIL C und D durch die Norm gefordert werden. In Bild 2 sind die linke Seite des V-Modells und die Zusammenhänge und Ziele der Analysen dargestellt. Es werden die folgenden Ebenen untersucht:

Fahrzeugebene: Gefahren- und Risikoanalyse gemäß dem Konzept zur funktionalen Sicherheit.
Systemebene: Auswirkungsanalyse (FMEA) und Funktionale-Sicherheit-Auswirkungsanalyse inklusive Kundenbetrieb nach dem technischen Sicherheitskonzept
Hardware-Design: „Failure Modes Effects and Diagnostic Analysis“-Verfahren (FMEDA) mit Hilfe von Software-Diagnosen zur Bestätigung und Erweiterung
Software-Design: „Failure Modes Effects and Criticality Analysis“-Verfahren (FMECA) via Software- Kritikalitätsanalyse mit Hazop Guidewords auf Architekturebene