Was tut der Ingenieur?
Sicherheitsanalysen
Die erste Analyse beschäftigt den Entwickler des gesamten sicherheitskritischen Systems :
- Hazard-/ Risikoanalyse: Zuallererst muss festgelegt werden, welchen Sicherheitslevel das System oder Subsystem bzw. eine bestimmte Funktion haben soll. Das wird aus dem möglichen Schaden und der Häufigkeit, mit der ein solcher Schaden eintreten kann abgeleitet, meist aufgrund einer Art Flussdiagramm. Vor allem in der Luftfahrt gibt es für verschiedene Arten von Systemen auch bereits vorgegebene Sicherheitslevel. Hier ein kleines Glossar der häufigsten Abkürzungen für Sicherheitslevel:
Level | Bereich | Höchste Riskostufe | Industrie |
DAL: Design Assurance Level | E..A | A | Luftfahrt: ARP4761, ARP 4754A, DO-178C, DO-254... |
SIL: Safety Integrity Level | 1..4 | 4 | Industrie, IEC 61508 und Bahnen, EN 50128/9 |
ASIL: Automotive Safety Integrity Level | A..D | D | Automobil, ISO 26262 |
PL: Performance Level | a..e | e | Maschinen, ISO 13849 |
Class: Software Safety Class | A..C | C | Medizingeräte, IEC 62304 |
Die weiteren Analysen finden dann auf jeder der Hierarchie-Ebenen statt: System, Subsystem, Komponente, Funktion, sowohl als Hardware- wie auch als Software-Sicherheitsanalysen, teilweise in verschiedenen Ausprägungen. Von ihnen ist also jeder Entwickler betroffen. Es gibt verschiedene Varianten, die wichtigsten sind:
- Fault Tree Analysis (FTA, Fehlerbaumanalyse): Die Fehlerbaumanalyse geht deduktiv vor, d.h. vom Fehler zur Ursache. Die Fragestellung ist also: Was sind die Fehlerursachen in meinem System, die zu einem bestimmten Ausfall führen könnten? Z.B. welche Bauteile müssen ausfallen, damit die für die Sicherheit relevante Funktion beeinträchtigt wird?
Dadurch ist die Methode sehr gut für das Design, vor allem das top-down Systemdesign geeignet. Von der FTA existieren zwei Varianten, eine rein qualitative und eine quantitative, bei welcher den Fehlerereignissen Auftretens-Wahrscheinlichkeiten zugeordnet werden. - Failure Modes and Effects Analysis (FMEA): Im Gegensatz zur FTA geht die FMEA induktiv vor, d.h. von der Ursache zum Fehler. Die Fragestellung ist hier für jedes Subsystem/ Bauteil: Welche sicherheitsrelevanten "Effekte" können aus einem Fehler entstehen? Z.B. wenn dieses Bauteil seinen Wert über die Zeit ändert (d.h. es altert): wie wirkt sich das auf die Funktion aus? Z.B. wenn sich ein Zustandsautomat um ein Bit verschluckt: wie wirkt sich das auf die Funktion aus? Auch von der FMEA existieren zwei Varianten, eine rein qualitative und eine quantitative. Bei der letzteren werden der Analyse Ausfallwahrscheinlichkeiten für die verschiedenen Fehlerarten (Kurzschluss, Leerlauf, Drift, Stuck-At...) der Bauteile unterlegt.
Im industriellen und automotiven Umfeld wird für die Elektronik meist eine FMEDA (Failure Modes, Effects and Diagnosis Analysis) gemacht, bei der für Diagnose-Mechanismen (z.B. Rücklesen von Ausgabesignalen) eine Reduktion der Ausfallraten angerechnet wird.
Sicherheitsmechanismen
Basierend auf den Sicherheitsanalysen müssen Sicherheitsmassnahmen ergriffen werden, um die folgenden Ausfälle zu entdecken und abzufangen.
- zufällige Hardwarefehler
- systematische Softwarefehler
- systematische Hardwarefehler
Diese Massnahmen können umfassen: Plausibilitätschecks, Redundanz (d.h. mehrere Systeme, welche sich gegenseitig überprüfen), diversitäre Redundanz (Redundanz beruhend auf komplett verschiedenartig aufgebauten und entwickelten Komponenten), Überwachung des Programmflusses, Fehlerkorrektur für Speicher und viele andere mehr.
Anforderungen
Fehler in den Anforderungen sind die häufigste Ausfallursache. Daher haben Anforderungen ein hohes Gewicht in der funktionalen Sicherheit. Dabei sind verschiedene Aspekte zu beachten:
- V-Modell: Die Anforderungen müssen in allen Industrien gemäss dem V-Modell verwaltet werden, das heisst:
- Es gibt sukzessive verfeinerte Anforderungen auf jeder Ebene (z.B. System, Software, Software Unit): Der Umfang dieser Anforderungen sollte für jedes Element (System, Software, Unit) so sein, dass ein Mensch sie noch verstehen kann, die Details werden auf die nächstuntere Ebene verschoben.
- Auf jeder Ebene werden grundsätzlich alle Anforderungen getestet.
- Anforderungs-Traceability: Anforderungen und Tests müssen verfolgbar sein, unter anderem, damit die Wartbarkeit des gesamten Projektes bei Änderungen gewährleistet ist:
- Vertikal: es muss klar sein, welche Anforderungen auf einer hierarchischen Ebene die abstrakteren Anforderungen auf der nächst oberen Ebene abdecken.
- Horizontal: es muss klar sein, welche Tests welche Anforderungen testen.
- Bi-direktional: es muss möglich sein, von jeder Ebene aus zu allen anderen Ebenen den Beziehungen nachzugehen.
- Traceability-Coverage Analyse: Es muss nachgewiesen werden, dass alle Anforderungen auf jeder Ebene in verfeinerten Anforderungen bis zur Implementation existieren, und dass alle Anforderungen getestet werden
- "Derived" Anforderungen: Wenn aus der Architektur oder dem Design neue Anforderungen entstehen, entstehen "derived" Anforderungen, z.B. durch die Definition von Schnittstellen zwischen verschiedenen Subsystemen. "Derived" sind also Anforderungen, welche sich nicht auf eine höhere Ebene zurückführen lassen. Solche Anforderungen müssen einer separaten Analyse unterzogen werden. Es muss nachgewiesen werden, dass sie die Funktion des übergeordneten Elementes nicht beeinträchtigen und die Sicherheit nicht gefährden.
- Keine unbeabsichtigte Funktionalität: Ein weiterer wichtiger Aspekt von Anforderungen ist zu verhindern, dass unbeabsichtigte Funktionen in die Implementation eingefügt werden, z.B. durch den Programmierer oder durch unnötige "derived" Anforderungen. Diese kommen üblicherweise von Anforderungen, welche Interpretationsspielraum zulassen oder guten Absichten, wie defensivem Programmieren. Beides kann zu unbeabsichtigten (Fehl-)Funktionen führen.
Zum V-Modell muss hier noch ein wichtiges Missverständnis ausgeräumt werden: Das V-Modell sollte nicht primär als Ablaufdiagramm, sondern als Daten-Management-Modell angesehen werden. Es bildet das "teile und herrsche" ab und die Beziehungen zwischen den Artefakten. In der Praxis heisst das, dass man ohne Iterationen zwischen den Ebenen nicht auskommt. Diese sind natürlich der Effizienz zuliebe auf ein Minimum zu beschränken. Daraus ergibt sich ein natürlicher Ablauf, da man auf den unteren Detailierungsebenen nichts fertig spezifizieren und designen kann, wenn auf der oberen nicht alles stabil und freigegeben ist. So wie man auf den oberen Integrationsebenen nichts fertig testen kann, wenn die Test auf der unteren Ebene nicht vollständig durchgelaufen sind.
Verifikation
Verifikation wird häufig mit Testen gleichgesetzt. Dem ist für sicherheitskritische Systeme nicht so, Tests sind nur ein kleiner Teil der Verifikation. Der grösste Teil der Verifikation besteht aus Reviews.
- Reviews: Alle Artefakte müssen vor ihrer Freigabe durch eine Review verifiziert werden, häufig sogar durch einen Reviewer mit genau definierter Unabhängigkeit vom Projektteam, sogar von der Organisation. Teilweise finden sogar mehrere Reviews statt, wenn noch ein Qualitätssicherungs-Review oder ein Review gegenüber dem Standard verlangt wird.
- Checklisten: Zu jedem Artefakt gibt es im Normalfall eine Checkliste. Ohne Evidenz der durchgeführten Review werden diese als nicht durchgeführt betrachtet, daher müssen alle ausgefüllten Checklisten als Review-Resultate abgelegt werden.
- Tests: Es gibt Testspezifikationen, Testinstruktionen, vielleicht auch Testcode und natürlich auch hier Evidenz aller Testresultate, d.h. alle Resultate müssen dokumentiert sein. Die Tests müssen Anforderungs-basiert sein, unter anderem darf es keinen Test ohne zugehörige Anforderung geben.
- Code-Coverage Analyse: Für die Software müssen die Tests sicherstellen, dass aller Code durch die Tests abgedeckt wird, eingeschlossen dass alle Verzweigungen durchlaufen werden. Man beachte, dass es Coverage-Analyse heisst: Coverage ist kein Test an sich, sondern nur eine Analyse, ob die Tests gewisse minimale Qualitätskriterien erfüllen. Coverage kann mit Werkzeugen zur dynamischen Codeanalyse nachgewiesen werden.
Aus der verlangten Code-Abdeckung und dem Anforderungs-basierten Testen ergibt sich übrigens, dass es nicht erlaubt ist (explizit so in der Luftfahrt mit DO-178C), Tests für Code-Coverage zu schreiben, zu denen es keine Anforderungen gibt. Also erzeugt man eben einfach eine Anforderung? ...die dann als "derived" Anforderung einer Sicherheitsanalyse bedarf! Es darf keine unbeabsichtigte ("unintended") Funktionalität vorhanden sein. Daher lohnt es sich, nur das zu implementieren, was wirklich gefordert ist.
Standards/ Regeln
Um eine homogene Qualität über das ganze Projekt sicherzustellen, werden für viele Artefakte Standards, Regeln gefordert. Diese können intern entwickelt werden, jedoch tut man sich mit den externen Auditoren einfacher, wenn man bekannte Standards benutzt, z.B. MISRA für C/ C++ Code.
- Anforderungsstandards: Diese beschreiben genau, wie Anforderungen formuliert sein müssen, bis hin zur Formatierung.
- Designstandards: Klare Richtlinien für das Design, sie müssen mindestens alle Anforderungen der Norm abdecken, z.B. "no hidden dataflow", hierarchisches Design...
- Codierstandards: Für die Software soll nur eine sichere, deterministische und gut lesbare Untermenge der Programmiersprache verwendet werden. Codierstandards wie MISRA können mit Werkzeugen zur statischen Codeanalyse zum grossen Teil automatisch nachgewiesen werden.
Komponenten
Für die Elektronik sollen nur qualitativ hochwertige Komponenten ausgewählt werden. Bei der Auswahl soll auf die Langzeit-Verfügbarkeit geachtet werden, damit man die Sicherheitsnachweise bei Komponentenänderungen nicht immer wieder erbringen muss. Zusätzlich ist es unabdingbar, für die Berechnung der Ausfallwahrscheinlichkeiten gutes Zahlenmaterial zu haben.
Leider gibt es ausserhalb der AEC-Q Nachweise für die Automobilindustrie fast keine "high reliability" Bauteile mehr. Und auch an den "Standards" mit den Zahlen zur den Ausfallwahrscheinlichkeiten (Siemens SN 27500, MIL-HDBK-217F...) nagt der Zahn der Zeit, bzw. der technologische Fortschritt. Die Standards werden dennoch für quantitative Analysen herangezogen, da es meist nur um den Vergleich von verschiedenen technischen Lösungen oder die Erfüllung eines Zielwertes innerhalb des Gesamtsystems geht und nicht um eine realistische Aussage zur Ausfallwahrscheinlichkeit.
Werkzeuge
Keine moderne Elektronik- oder Softwareentwicklung ohne Software-Werkzeuge. Software? Ist die Software aller Werkzeuge im Projekt fehlerfrei? Was passiert, wenn ein Fehler in einem Werkzeug zu einem Fehler in einem Artefakt führt?
- Werkzeug-Klassifizierung: Für ein Projekt der funktionalen Sicherheit bedeutet dies, dass alle Werkzeuge klassifiziert werden müssen. Es muss gezeigt werden, ob und wenn ja welche Fehler das Werkzeug in einem Artefakt erzeugen kann.
- Werkzeug-Qualifikation: Je nach Resultat obiger Analyse muss das Werkzeug dann qualifiziert werden. D.h. es muss nachgewiesen werden, dass das Werkzeug, so wie es verwendet wird, diese Fehler nicht generiert oder dass die Fehler erkannt werden können.
Auch Psychologie: Feedback Geben und Annehmen
Funktionale Sicherheit ist doch logisch, eine klare Sache: sachlogisch. Denkt man am Anfang... Dem ist jedoch nicht wirklich so. Psychologische Aspekte spielen eine nicht unwesentliche Rolle, sowohl für die Zielerreichung, aber auch die Effizienz und vor allem für die eigene Zufriedenheit.
Kein Ingenieur kommt um Feedback herum, spätestens bei der Review seiner Resultate. Das positive Feedback anzunehmen stellt meist kein Problem dar, aber wenn was falsch ist, dann gehen manchmal die Emotionen hoch. Hier ist die eigene Einstellung zu Fehlern der Knackpunkt: Kann ich eigene Fehler annehmen und aus ihnen lernen? Bin ich bereit, bei fremden Fehlern hinzuschauen und darauf hinzuweisen? Bin ich bereit, solche Konflikte konstruktiv auszutragen? Denn "es funktioniert ja" ist nur in "normalen" Projekte ein Grund, schlechten Code nicht zu korrigieren, und vielleich auch dort nicht?
Und da es das Ziel sein sollte, die Review ohne Fehler zu bestehen, funktioniert Einzelkämpfertum nicht mehr. Wenn ich nicht meine Lösung mit anderen abspreche, sie gemeinsam erarbeite und einen Konsens finde, dann mache ich so viele Review-Runden bis mir schwindelt.
Zu guter letzt bin ich nur zufrieden wenn ich nicht jeden Fehler, jede Kritik als Angriff auf mich als Mensch auffasse, sondern als eine Einladung, noch besser zu werden, mich zu entwickeln.
| Anton Sulovsky
Eine der besten und realistischsten Zusammenfassung, die ich je gelesen habe...