Funktionale Sicherheit in der Elektronik - Beispiele?

Hallo,

ein Standardwerk ist mir leider auch nicht bekannt (ausser die Normen 
selber); könnte auch daran liegen, dass es keine "Standard-Schaltpläne" 
bzw. Vorgehensweisen zum Schaltplandesign gibt, da die Lösungen stets 
ziemlich individuell sind.

Was jedoch standardisiert ist sind die Methoden, mit denen man an den 
Schaltplanentwurf herangeht und mit denen man das Design überprüft. Als 
erstes kommet immer (egal welche Norm, IEC61508, ISO 26262, ...) die 
Identifikation der möglichen Gefährdungen, die durch den 
Entwicklungsgegenstand verursacht werden können oder vermieden werden 
sollen, sowie deren Kritikalitäts-Einstufung. Hierzu gibt es 
verschiedene Ansätze, z.B. ein Boundary-Diagramm, eine FMEA oder FTA.

Dann erfolgt die Entwicklung entsprechender Sicherheitsfunktionalität. 
Diese wird dann auf die verschiedenen Komponenten des 
Entwicklungsgegenstands verteilt, wobei sich hier die Normen, was das 
Vererben der Kritikalität angeht, schon unterscheiden. Vereinfacht 
gesagt, kann man die Verantwortung zwischen Software, elektronischer 
Hardware und mechanischen Komponenten verteilen bzw. verschieben. Je 
nach Norm kann man noch durch Redundanz und Divergenzbildung noch die 
Kritikalität der entsprechenden Komponenten verändern (IEC61508: 
Aufteilung einer SIL-2-Kritikalität auf zwei SIL-1-Kritikalitäten).

Im Anschluss daran beginnt das, was Dich hier wohl interessiert, nämlich 
das Design der einzelnen Komponenten (elektrischen Schaltungen). Hier 
fließen verschiedene Anforderungen der unterschiedlichen Normen mit ein 
(z.B. diagnostischer Deckungsgrad) und beeinflussen so das 
Designergebnis. Allerdings können auch hier noch nahezu beliebige 
Verschiebungen der Verantwortlichkeiten erreicht werden, so dass z.B. 
für eine sehr hohe Kritikalität trotzdem eine sehr einfache Schaltung 
ohne Redundanzen möglich ist, während möglicherweise in anderen Fällen 
niedrige Kritikalitäten nur durch komplizierte Schaltungen mit 
eingebauten Diagnosen beherrschbar sind.

Allerdings ist hier in der Vergangenheit schon ein Trend absehbar, 
nämlich den zur Redundanz (obwohl Divergenz prinzipiell besser wäre). So 
etabliert sich der Dual-Core Lock-Step-Prozessor gerade als Mittel der 
Wahl für ASIL D-Systeme. Auch wird häufig auf Informationen von 
"Außerhalb" zugegriffen (z.B. extern angebundene Sensoren oder 
Steuergeräte - im Automobil z.B. ABS/ESP, Engine,...) und so die interne 
Redundanz zu reduzieren. Allerdings müssen diese externen Systeme die 
Verantwortung dann auch aktiv übernehmen (also nicht nach dem Motto: 
"Der macht das schon....")

Nach dem Design schließt sich immer eine Analyse der einzelnen 
Komponenten sowie des Gesamtsystems an. Auch hier kommen wieder 
qualitative und quantitative induktive und deduktive Methoden zum 
Einsatz (FMEA, FMEDA, (quantitaive) FTA, Common Cause Analysis, Freedom 
of Interference-Nachweise,... - die Liste von eehhh stellt nur einen 
ganz kleinen FMEA-Auszug dar). Dabei werden nicht selten Schwachstellen 
im Hardware-Design gefunden (speziell bei der Common Cause Analyse), die 
dann zu Änderungen des Erst-Entwurfes führen. Als Beispiel: Sensoren 
wurden redundant ausgelegt, die Stromversorgung jedoch nicht. Oder: es 
wurden mehrere digitale Hall-Zellen mit einer Kodierung mit 
Hamming-Distanzen >3 eingesetzt, die Leiterbahnen liegen jedoch direkt 
nebeneinander, so dass ein Bruch der Leiterbahnplatte zu einem falschen 
(gültigen) Sensorwert führen kann.

Diese Analysen sind der Knackpunkt an der ganzen Entwicklung; leider 
fließt hier auch immer ein hohes Maß an Erfahrung hinein, was nur schwer 
durch Bücher zu vermitteln ist. Die "offensichtlichen" Normativen 
Anforderungen wie Ausfallraten und diagnostische Deckungsgrade lassen 
sich jedoch immer "durch Materialeinsatz" erfüllen.

Zum Schluss muss dann natürlich noch eine Verifikation (Design 
enstpricht den Anforderungen) und eine Validation (Anforderungen 
erfüllen das Sicherheitsziel) durchgeführt werden. Dazu gehören dann 
auch übliche Teste wie EMV und ähnliches.

Du siehst, eine Sicherheitsentwicklung ist ein Zusammenspielen von 
vielen etablierten Methoden mit einer gehörigen Portion Wissen/Erfahrung 
und persönlichen Vorlieben (z.B. mach ich lieber etwas in Software, in 
Hardware oder kann die Mechanik das abdecken?). Daher stelle ich es mir 
auch schwer vor, hier ein "Standardwerk" zu schreiben. Dies wird auch 
durch die auf Fachtagungen vorgestellten Ansätze deutlich, die sich doch 
immer noch sehr stark voneinander unterscheiden.

Einen Lese-Tipp hätte ich dann aber doch noch: versuche mal, 
entsprechende Tagungsunterlagen zu bekommen.

Schöne Grüße,
Martin

Hallo,

ich gebe Dir recht, dass die Ermittlung der Gefahren und das Erstellen 
des systemweiten Sicherheitsdesigns eigentlich Aufgabe des OEM ist (die 
auch gerne Safety Analyse genannt wird) allerdings wollte ich hier 
erstens nicht zu spezifisch auf die 26262 eingehen und zweitens muss man 
als Tier-1 Systemlieferant leider immer noch häufig die Gefahren- und 
Risikoanalyse selber machen.

Auch ist es häufig sinnvoll sie unabhängig vom OEM zu machen, da dieser 
öfter (mangels Erfarung/Wissen) nicht in der Lage ist, alle möglichen 
Fehlfunktionen zu berücksichtigen. In beiden Fällen gibt es dann (oft 
lange) Diskussionen, bei denen schließlich der OEM aber stets das letzte 
Wort hat (als Gesamt-Systemverantwortlicher). Sollte er ein Risiko zu 
niedrig eingestuft oder vergessen haben, tut man jedoch gut daran, ihm 
dies dokumentiert mitzuteilen.

Die Überprüfungen nach dem Design heißen aber tatsächlich Safety 
Analysen, der Teil 9 der ISO beschreibt diese dann im Detail.

Und ja, der Aufwand kann erheblich werden; während z.B. für ein ASIL A 
(im Automotive-Umfeld niedrigste Kritikalität, die nicht mit normalen 
Qualitätsmaßnahmen zu bewältigen ist) sind für Hardware "nur"eine 
handvoll Prozessthemen zu betrachten, Nachweise zu Ausfallraten und 
Diagnose sind nicht notwendig. Für ASIL D (das ist die höchste Stufe) 
darf auf Fahrzeugebene ein kritischer Fehler nur mit 1e-8 pro Stunde 
auftreten, wobei 99% aller vorkommenden Fehlermodi diagnostiziert werden 
können müssen. Zusätzlich muss dann noch die ganze Arbeit von 
unabhängigen Stellen auditiert werden.

Ist halt wirklich ein komplexes Thema; von Bosch sagt man, dass die 
interne Aufwände für die Sicherheitsarbeiten etwa 10% des 
Gesamtaufwandes ausmachen soll.

Schöne Grüße,
Martin

In der Praxis versucht man den sicherheitszertifizierten Bereich so 
klein wie möglich zu halten. Da hilft es ungemein wenn durch abschalten 
ein sicherer Zustand erreicht werden kann. (In sehr vielen Fällen ist 
dies möglich, im Flugzeug oder bei z.B. steer by wire hingegen nicht).
Dann versucht man mit äusserer Grenzwertüberwachung und wenigen 
Systemzuständen durchzukommen. Im Industrie und Bahnbereich läuft das 
meist auf auf eine externe Sicherheitssteuerung hinaus welche normal nie 
eingreift und nur im Notfall der Sache ein hartes Ende setzt. Die 
Betriebssteuerung mit allen Konfortfunktionen und komplexen Algorithmen 
kommt dann meist ohne Sicherheitsauflagen aus.

viel Erfolg
Hauspapa