O'Reilly logo

Automotive SPICE in der Praxis: Interpretationshilfe für Anwender und Assessoren by Jörg Zimmer, Lars Dittmann, Klaus Hörmann, Markus Müller

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

285
5 Funktionssicherheit
Nachdem immer mehr mechanische und hydraulische Systeme in sicherheitsrele-
vanten Baugruppen im Automobil durch elektrische und elektronische Lösungen
ersetzt oder zumindest ergänzt werden, stellt sich zunehmend die Frage nach der
»Funktionssicherheit« dieser Systeme. Der Kunde muss sich auf diese Systeme
verlassen können und diese Frage wird sein Kaufverhalten maßgeblich beeinflus-
sen. Dramatische Absatzrückgänge bei öffentlich breit diskutierten Sicherheits-
problemen an Fahrwerk und Bremsen bei einzelnen Fahrzeugmodellen sind all-
seits genügend bekannt. Wenn in Produkthaftungsfällen nachgewiesen werden
kann, dass der Stand der Technik bezüglich Entwicklungsmethodiken nicht ein-
gehalten wurde, drohen hohe Schadenersatzforderungen und Rechtskosten, ins-
besondere auf dem nordamerikanischen Markt.
Die hierfür maßgebliche Norm ist die [IEC 61508], die auch als [DIN EN
61508] vorliegt mit dem deutschen Titel »Funktionale Sicherheit sicherheitsbezo-
gener elektrischer/elektronischer/programmierbarer elektronischer Systeme«. Die
IEC 61508 ist als »Sicherheitsgrundnorm« ausgewiesen, das heißt, sie kann als
Basis für anwendungsspezifische Normen dienen. Eine auf der IEC 61508 auf-
bauende Norm für Sicherheitsfunktionen im Automobil (ASIL – Automotive
Safety Integrity Level) ist in Arbeit beim VDA/FAKRA AK 16 »Funk-
tionssicherheit« (FAKRA = DIN Fachausschuss Kraftfahrzeuge) mit dem Ziel,
den ISO-Standard 26262 zu entwickeln. Die meisten Automobilhersteller fordern
bereits heute von ihren Lieferanten, dass insbesondere die Entwicklung von Steu-
ergeräten und Software kompatibel zu IEC 61508 erfolgt.
Bei der IEC 61508 geht es darum, potenziell gefährliche Störungen oder Aus-
fälle, die ernsthafte Konsequenzen wie Verletzung oder Tod von Menschen oder
Umweltschäden bewirken können, zu erkennen und diesen im Rahmen maximal
zulässiger statistischer Grenzwerte entgegenzuwirken. Dabei werden die Systeme,
die zu solchen Gefährdungen beitragen können, ermittelt. Diese Systeme werden
als »sicherheitsbezogen« bezeichnet. Dabei kann eine Störung alleine
1
oder in
Kombination mit Störungen anderer Systeme zu der Gefährdung führen.
1. Dieser Fall wird oft als »sicherheitskritisch« bezeichnet, der Fall der Kombination als
»sicherheitsbezogen«, auch wenn die Begriffe nicht scharf abgegrenzt sind.
5 Funktionssicherheit
286
Ausgehend von einer maximal zulässigen Obergrenze für die Wahrscheinlich-
keit, dass ein potenziell gefährlicher Zustand eintritt, werden für alle beteiligten
Systeme (in diesem Fall z.B. Sensoren, Kabel, Stecker, Steuergerät) je nach ihrem
relativen Beitrag Sicherheitsstufen in Form von »Safety Integrity Levels« (SIL)
gefordert: Man unterscheidet vier Stufen von SIL 1 bis SIL 4. SIL 1 und 2 gelten
als relativ einfach zu erreichen, erfordern aber schon ziemlich gute Methoden in
Design und gründliche Tests und Reviews. Der Aufwand steigt sprunghaft, wenn
SIL 3 erreicht werden soll, z.B. durch die Notwendigkeit der Re-Validierung nach
Änderungen. Das Gleiche gilt, wenn SIL 4 erreicht werden soll, was einen sehr
aufwendigen Methodeneinsatz wie z.B. formale Designmethoden erfordert. Die
benötigten SIL können auf zwei Arten ermittelt werden:
Quantitativ: Die Häufigkeit von Hardwareausfällen wird vorhergesagt und
mit tolerierbaren Risikogrenzwerten verglichen.
Qualitativ: Der SIL wird durch qualitative Beurteilungen ermittelt, üblicher-
weise mittels eines Risikographen (siehe Abb. 5–1). Dieses Verfahren wird
insbesondere bei Software eingesetzt.
Abb. 5–1
Beispiel eines Risikographen












 
  
  
  
  
 



%12/./$%1+,%).%1%
2#(9$,)#(%-6%,3%).&,;22%

2#(6%1%)11%5%12)",%%1,%374.'
%).%1/$%1-%(1%1%1%12/.%./$%1
/$%).%1%12/./$%1
5/1;"%1'%(%.%$%'1:<%1%
2#(9$,)#(%-6%,3%).&,;22%

/$-%(1%1%1%12/.%./$%1
,!.'!.$!4%1.$%'1:<%1%
2#(9$,)#(%-6%,3%).&,;22%

+!3!231/0(!,%426)1+4.'


2%,3%.")2:&3%1

(94&)'")2$!4%1.$


-:',)#(4.3%1"%23)-

+!4--:',)#(


2%(1'%1).'

'%1).'

1%,!3)5(/#(












 
  
  
  
  
 



,%)#(3%%1,%374.'%).%1

/$%).%1%12/./$%1

/$-%(1%1%1%12/.%./$%1

2%(15)%,%/3%


2%,3%.")2:&3%1

(94&)'")2$!4%1.$


-:',)#(4.3%1"%23)--
3%.%$).'4.'%.

+!4--:',)#(


2%(1'%1).'

'%1).'

1%,!3)5(/#(
287
5 Funktionssicherheit
Die IEC 61508 erstreckt sich über Konzept, Planung, Entwicklung, Realisierung,
Inbetriebnahme, Instandhaltung, Modifikation bis hin zur Außerbetriebnahme
und Deinstallation des Systems. Dabei ist die Planung, Koordinierung u. Doku-
mentation der Sicherheitsaufgaben eine zentrale Managementaufgabe und
bezieht sich auf alle Phasen. Bezüglich Softwareentwicklung gehören zu diesen
Aufgaben u.a.:
Management für Functional Safety einrichten, Verantwortlichkeiten genau
festlegen
Konzeptphase
Sicherheitskritische Funktion definieren
Software-Sicherheitslebenszyklus für diese Funktion definieren
Durchführung von Gefahrenanalyse (hazard analysis) und Risikobewer-
tung
Konzept für Funktionssicherheit aufstellen
Entwicklungsphase
2
Planung der Softwaresicherheitsvalidierung
V-Modell-artiges Vorgehensmodell mit Spezifikation der Softwaresicher-
heitsanforderungen, Softwarearchitektur, Softwaresystementwurf, Modul-
entwurf, Codierung, Modulprüfung, Integrationsprüfung, Validierungs-
prüfung
Planung der Softwaresicherheitsvalidierung
Planung der Softwareverifikation
Änderungswesen mit verschiedenen Graden der erneuten Verifikation und
Validierung
Die Anforderungen an die Entwicklung unterscheiden sich deutlich bezüglich der
jeweiligen SIL. Dies betrifft z.T. sehr detaillierte Vorschriften bezüglich verwen-
deter Methoden, Dokumentation und Konfigurationsmanagement (siehe Abbil-
dung 5–2).
2. Hier nur für Software gezeigt. Die Norm beschreibt Maßnahmen zur Entwicklung auf
Systemebene sowie für die Hardware und die Software.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required