Hi Leute, ich habe diverse "theoretische" Dokumente über funktinale Sicherheit gefunden (u.A. bezogen auf Software oder fertige Module) aber nirgends habe ich etwas gefunden, wie Funktionale Sicherheit auf die Elektronik herunter gebrochen aussieht. Gibt es für Funktionale Sicherheit auf Elektronikebene ein Standartwerk? Gibt es irgendwo schöne Beispiele (Schaltplanauszüge) über funktionale Sicherheit? MfG Mike
Mike schrieb: > Gibt es für Funktionale Sicherheit auf Elektronikebene ein Standartwerk? > Gibt es irgendwo schöne Beispiele (Schaltplanauszüge) über funktionale > Sicherheit? Ist mir nichts bekannt, mache selber Funktionale Sicherheit. Hält sich jeder möglichst bedeckt. rgds
Mike schrieb: > Gibt es für Funktionale Sicherheit auf Elektronikebene ein Standartwerk? Standarten, welche in welcher Form auch immer einen Bezug zur FuSi bieten, sind mir nicht bekannt. Auch keine Standardwerke. > Gibt es irgendwo schöne Beispiele (Schaltplanauszüge) über funktionale > Sicherheit? FuSi ist ein weites Feld. Hier gibt es keine "Standardrezepte", sondern es kommt immer darauf an, was genau eigentlich erreicht werden soll bzw. wie das Sicherheitsziel aussieht, welche Rahmenbedingungen (Metriken) herrschen, wie das Gesamtkonzept der "Schaltung" (einschl. Hardware, Software etc.) eigentlich aussieht etc. Daher verstehe ich die Frage nicht so ganz - was sollten diese Schaltplanauszüge denn zeigen (Nochmals zur Verdeutlichung: Ich habe hier Schaltpläne für ASIL-C-Applikationen, die sich in keinem Punkt von einem "normalen" Schaltplan unterscheiden)?
Man muss sich alle Faelle ueberlegen. Was geschieht, wenn -die funktionale Einheit keinen Strom mehr bekommt -der Controller keinen Strom mehr bekommt -der Controller noch nicht programmiert ist -die kommunikation zum controller abbricht -Falscheingabe an der angehaengten Tastatur -Abbruch der Eingabe an der angehaengten Tastatur -die Lueftung des Geraetes aussteigt -die Luftschlitze des Geraetes irgendwie geschlossen werden -ein Sensor kaputtgeht -das Kabel zu einem Sensor abreisst was wurde gemacht, und die obigen Zustaende zu verhindern. Man ahnt's - das Geraet, resp der Prozess muss immer in einem sicheren Zustand sein, resp diesen sicheren Zustand im Fehlerfall anfahren.
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
Ich danke Euch, für die Vermittlung Eures Wissens! So war mir das nicht bekannt! Besonderen Dank an martin für seine ausführliche Beschreibung! MfG Mike
""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."" Schlagt mich tot wenn es nicht so ist, aber zumindestens bei uns ist es so, dass es normalerweise vom OEM eine Safety Analyse gibt wie sie entsprechendes Agieren eines Fahrers/Systems beurteilen. Darauf aufbauend und nach langer Diskussion ;) muss man dann sicherstellen, dass man die Ziele entsprechend ASILA,B,C etc. erfüllt. Verschiedene Sichtweisen und Lösungsansätze führen zum Teil zu ganz unterschiedlichen Ratings und Ergebnissen. Der Aufwand für Doku, Tests, Audits... steigt bei höheren Ratings recht stark an, es ist nicht nur die Schaltung, Programmierung alleine die Mehrarbeit bedeutet. Schau dir mal ISO26262 an, dort ist der Ablauf genau beschrieben. http://de.wikipedia.org/wiki/ISO_26262
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
> Gibt es für Funktionale Sicherheit auf Elektronikebene ein Standartwerk?
Mit gelber Farbe anmalen und Preis um Faktor fünf erhöhen.
Mehr ist das auch nicht... gehässigt guck
Mike schrieb: > Gibt es irgendwo schöne Beispiele (Schaltplanauszüge) über funktionale > Sicherheit? Das kommt wohl auf die Anwendung an. Stell dir z.B. einen Motor mit einer Motorsteuerung vor. Wenn du jetzt den Strom anschaltest - wie soll sich das Ding sinnvoll benehmen. Sicherlich ist es ein schlechter Plan, wenn der Motor automatisch mit maximaler Drehzahl losrennt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.