Funktionale Sicherheit

Um was geht es überhaupt?

Es geht hier nur um die Bereiche, wo wir als Solcept Erfahrung haben. Das heisst es geht um Entwicklung von Software und Elektronik. Wir lassen also den restlichen Lebenszyklus von Produktion bis Entsorgung aussen vor, wie auch die Details der Systementwicklung auf z.B. Fahrzeug- oder Flugzeug-Ebene.

Was bedeutet funktionale Sicherheit?

Funktionale Sicherheit bedeutet, dass die Risiken eines Produktes von Verletzungen oder schlimmerem minimiert werden. Funktional deswegen, weil die Sicherheit von der richtigen Funktion des Systems abhängt. Z.B. dass ein Fahrzeug nicht abfährt, wenn man gerade am einsteigen ist, dass die Anzeige im Cockpit dem Piloten nicht vorgaukelt, noch mehr Treibsoff zu haben als real in den Tanks vorhanden ist.

Darin unterscheidet sich die funktionale Sicherheit von "Nebeneffekten" der Funktion des Systems, wie z.B. Explosionsschutz, Spannungsschutz, Brandsschutz etc.

Was heisst hier "normal"?

Als Startpunkt für diese Übersicht gehe ich von einer "normalen" embedded Entwicklung in der Industrie aus. Beachten Sie, dass die Qualitätsstufen ohne funktionale Sicherheit (z.B. QM (Quality Managed) in der Automobilindustrie oder DAL-E (Design Assurance Level E) in der Luftfahrt) bereits einen massiv höheren Aufwand erfordern, als die Entwicklung, von der wir hier ausgehen. Dies, weil diese Entwicklungen bereits nach Level 3 von automotive SPICE oder CMMI (Common Maturity Model Integration) erfolgen sollten. Das heisst, dass bereits ziemlich viele Anforderungen, Unittests, Traceability etc. vorhanden sind.

Normen

Geschichtlich nahmen die Normen für sicherheitskritische Systeme im embedded Bereich ihren Anfang 1982 in den Vereinigten Staaten mit der Norm DO-178, welche auf Airliner abzielte. Diese Norm, heute in der Version DO-178C, ist immer noch die Mutter aller Normen und ihre Konzepte wurden von anderen Industrien übernommen. In Deutschland entstand 1998 die IEC 61508, primär für die Chemieindustrie, aber auch als Schirmnorm, von der die meisten anderen Industrien ihre Normen abgeleitet haben.

Ich möchte hier das Thema der verschiedenen Normen nicht weiter vertiefen, in vielen Fällen kommt man nicht mit nur einer aus, es gibt einen ganze Sammlung von Dokumenten, welche man beachten muss. Dennoch sind die Grundkonzepte gleich, so dass sich unabhängig von der Industrie definieren lässt, was man für funktionale Sicherheit tun muss.

The Name of the Game

Zuletzt hier in der Einführung der wohl wichtigste Punkt für alle, die für funktionale Sicherheit entwickeln wollen. Man kann zu den Normen und den von ihnen verlangten Modellen stehen wie man will, in dem Moment wo man ja sagt zu einem Projekt mit funktionaler Sicherheit, muss man das Spiel der funktionalen Sicherheit spielen. Also buchstabengetreu die verlangten Arbeiten ausführen und die Dokumente erstellen. Dies gilt für die Ingenieure, welche die Arbeit tun, aber vor allem auch für die Führung, welche die Zeit und Ressourcen zur Verfügung stellen muss. Sonst... muss man ein anderes Spiel ohne funktionale Sicherheit spielen.

Was heisst denn...?

Einige wenige Grundbegriffe sind wichtig, daher hier eine kurze Definition

• Funktionale Sicherheit: Sicherheit, die von der richtigen Funktion des Systems abhängt, daher nicht Explosionsschutz, Spannungsschutz, Brandsschutz etc.
• Systematische Fehler: Fehler, welche während der Entwicklung in das Design, das System eingebaut werden (diese Fehler können im ganzen System vorkommen)
• Zufällige Fehler: Fehler, welche zufällig auftreten, Ausfälle (diese Fehler können nur in der Hardware vorkommen, da die Software keinen Alterungsprozessen unterworfen ist)
• Artefakt: alle Arbeitsprodukte (Dokumente, Code, Daten...)

Wieso machen die das?

Es gibt ein paar Grundprinzipien der funktionalen Sicherheit, welche zu verstehen helfen, wieso man genau so entwickeln soll und nicht anders.

• Qualität: Der wichtigste Punkt ist wohl die Konzentration auf Prozesse, auf strukturiertes Vorgehen. Der Grundsatz hier ist "use quality to manage risk“. Man versucht die Risiken zu vermindern, indem man die Entwicklungsqualität hoch hält, ganz eliminieren kann man sie jedoch nicht. Das bedeutet auch, dass je höher das Risiko ist (ausgedrückt als "Sicherheitslevel"), desto höher sind auch die Qualitätshürden.
• Teile und herrsche: Das Gesamtsystem (Fahrzeug, Flugzeug, Gerät...) wird in immer kleinere Untersysteme aufgeteilt, so dass ein Mensch, nämlich der verantwortliche Ingenieur, die ganze Kompliziertheit auf seiner Ebene noch überblicken kann.
• Planung: Wenn ein Projekt sauber geplant ist, dann passieren weniger Fehler, weil keine Notfallübungen über das Wochenende nötig sind. Solche Quick Fixes durch den heldenhaften Entwickler sind durch Änderungsmanagement und Dokumentationsanforderungen in allen Standards unterdrückt.
• Evidenz: Was nicht dokumentiert ist, ist nicht geschehen. Dies ist einerseits eine Grundforderung von Qualitätsmanagementsystemen (wie der Qualitätspapst W.E. Deming sagte: "In God we trust, all others bring data"), andererseits auch eine Forderung des Haftpflichtrechtes. Niemandem kann ein Strick daraus gedreht werden, dass er einen Fehler begangen hat, aber daraus, dass er einen Schritt ausgelassen, eine Review nicht gemacht, einen Test nicht durchgeführt hat.
• 4 (bis 6) Augen Prinzip: Alles was irgendwie wichtig ist, muss mindestens einmal durch eine Review geprüft werden, teilweise auch durch mehrere.
• Gesamtschau: Am Ende muss die funktionale Sicherheit immer für das ganze betrachtete sicherheitskritische System (Fahrzeug, Gerät, Flugzeug...) stimmen. Das heisst, es gibt keine funktionale Sicherheit, welche für ein Teilsystem oder ein eingebautes Gerät alleine betrachtet werden kann. Es gibt dadurch auch keine vollständige "Zertifizierung" von z.B. Sensoren, Aktoren, Softwaren. Die meisten Aspekte können "vor-zertifiziert" werden, doch muss sichergestellt werden, dass die Gesamtsicherheit nicht durch z.B. Schnittstellenprobleme oder Fehler in der Verwendung beeinträchtigt wird.
• Verfolgbarkeit: Es soll verhindert werden, dass Fehler entstehen aufgrund von Annahmen, welche der Ingenieur für sein Artefakt macht. Daher müssen Anforderungen von der obersten (Geräte-)Ebene bis zur Implementation verfolgbar sein und es dürfen keine Annahmen möglich sein.

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:

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.

Was tut das Projektteam?

Das ganze Projektteam und der Projektleiter werden auch in die Pflicht genommen und müssen sich um folgende Aspekte kümmern.

Pläne

Damit nichts dem Zufall überlassen wird, müssen Projekte zur Entwicklung von sicherheitskritischen Systemen alle geplant ablaufen. So müssen Prozesse, Rollen, Verantwortlichkeiten etc. als Pläne zusammengefasst werden:

• Development Interface Agreement: Wenn mehrere Partner gemeinsam entwickeln, werden alle Verantwortlichkeiten detailliert verteilt, damit keine davon vergessen gehen kann.
• Safetyplan oder Plan on Software/ Hardware Aspects of Certification: Dies ist der Gesamtplan für das Sicherheits-Projekt, er beinhaltet alle Prozesse, alle Verantwortlichkeiten, alle Termine und Abläufe.
• Verifikationsplan: Er stellt dar, wie die Artefakte verifiziert werden.
• Integrationsplan: Eine Planung, wie die Subsysteme, Systeme etc. auf allen Ebenen zusammengebracht werden.
• Konfigurationsmanagementplan: Er zeig im Detail auf, wie die Beziehungen zwischen den Artefakten und ihren Versionen und Änderungsständen über den Lebenszyklus des Produktes verwaltet werden.
• Qualitätssicherungsplan: Macht klar, wer die Qualität der im Projekt erzeugten Artefakte wann und wie sichert.
• und andere: Bleifrei-Entwicklungsplan...

Konfigurationsmanagement

Das Konfigurationsmamagement stellt sicher, dass zu jedem Zeitpunkt alle Artefakte zusammenpassen.

• Releases: In verschiedenen Phasen des Projektes werden Releases erzeugt. Diese umfassen nicht nur Software und Produktionsdaten, sondern immer alle Artefakte des Projektes.
• Audits: Um sicherzustellen, dass alle Artefakte in einem Release zusammenpassen, muss ein Audit jedes Release durchgeführt werden.
• Aufbewahrung: Je nach Industrie kann verlangt werden, dass es in 20 oder mehr Jahren möglich sein muss, aufgrund der in der Entwicklung benutzten Prozesse und mit den gleichen Werkzeugen z.B. das exakt gleiche Binary wieder zu erstellen. Wie haben Sie vor 20 Jahren entwickelt?

Änderungsmanagement

Nach dem ersten formalen Release tritt das Änderungsmamagement in Kraft. Es wird die Zusammensetzung eines Change Control Boards definiert. Dieses muss für jede Änderung einem genau definierten Ablauf folgend sicherstellen, dass folgende Fragen beantwortet werden:

• Braucht es die Änderung wirklich?
• Wie wirkt sich die Änderung auf Sicherheit aus?
• Wie wird sichergestellt, wie und dass die Änderungen verifiziert wird?
• Wann wird die Änderung umgesetzt?

Der ganze Prozess natürlich immer mit detaillierter Rückverfolgbarkeit (Traceability).

Audits

Alle wichtigen Artefakte, je nach Sicherheitslevel sind das einige, müssen auditiert werden, d.h. eine weitere Person muss eine Review durchführen. Diese Audits sollen sicherstellen, dass man keine Abkürzungen genommen hat. Daher ist für die Auditoren immer eine starke Unabhängigkeit vom Projekt gefordert, häufig werden Dritte beigezogen: benannte Stellen, der Kunde selbst, Behörden (EASA, FAA...).

Statements

Am Schluss entsteht das wichtigste Dokument für den Kunden bzw. die Behörde, die finale Erklärung, dass das Produkt sicher ist.

• Safety Case oder Software/ Hardware Accomplishment Summary: Diese Dokumente müssen aufzeigen, was von den Plänen wie durchgeführt wurde und erklären, wieso das Produkt sicher ist.

Auch Psychologie: Kommunikation

Gerade von Ingenieuren wird der psychologische Anteil an der Kommunikation meist unterschätzt. Funktionale Sicherheit ist Team-Arbeit, also Kommunikation zwischen Menschen und diese lässt sich nicht auf reine Informationsübertragung reduzieren.

Die meisten Aufgaben, vor allem wenn etwas kompliziertere sicherheitskritische Systeme entwickelt werden sollen, lassen sich nicht von Anfang an so beschreiben, dass der Ingenieur sich nachher ein paar Wochen in sein Kämmerchen zurückziehen kann und seine Lösung genügend gut ist. Es braucht Kommunikation zwischen allen Beteiligten, damit die Schnittstellen stimmen und der Konsens erreicht wird, der dann in den vielen Artefakten dokumentiert wird.

Auch gutes und damit sicheres Design lässt sich nicht über Metriken erreichen, sondern nur über einen Trade-Off, einen Ausgleich und diesen Konsens gibt es nicht ohne Kommunikation miteinander.

Die Grundlage für jede Kommunikation, die ankommen soll, sind Beziehungen. Vor allem wenn die Kommunikation mal etwas schwergewichtiger ist: "das ist komplett falsch". Gute Beziehungen heisst nicht, dass alle mit allen jedes Wochenende verbringen müssen, die Beziehungen müssen dennoch so gut sein, dass eine emphatische Kommunikation möglich ist.

Zu guter letzt ist es wichtig, dass man trotz der peinlich genauen Arbeitsweise der funktionale Sicherheit eine Stimmung im Team erreicht, welche die Arbeit angenehm macht.

Was tut die Firma?

Es ist nun aber nicht so einfach, dass die ganze Verantwortung für die funktionale Sicherheit an das Projektteam delegiert werden kann. Vor allem dann nicht, wenn man noch den Produktlebenszyklus von der Produktion bis zur Entsorgung einschliesst. Die Organisation hat einiges zu leisten.

Prozesse/ Modelle

Für funktionale Sicherheit wird davon ausgegangen, dass die Organisation Prozesse hat, diese lebt und auch verbessert. Für die Entwicklung sind automotive SPICE oder CMMI (Capability Maturity Model Integration) als Prozessmodelle verbreitet. Und diese Modelle gehen viel weiter als ISO 9001, es sind mehr Ziele zu erreichen und mehr Tätigkeiten vorgegeben. In der Luftfahrt brauchen Sie ein DOA (Design Organization Approval), wobei dieses auch vom Kunden transferiert werden kann, wenn er die Verantwortung für die finale Qualitätssicherung übernimmt.

Die Frage, welche sich mir persönlich jeweils stellt ist die, ob und wie diese Prozesse und Modelle dann wirklich gelebt werden, vor allem bei der Zusammenarbeit mit grossen Organisationen mit hoher, zertifizierter Maturität....

Level 3

Was heisst Level 3? Level 3 heisst in allen Prozessmodellen, dass Prozesse für die ganze Organisation, d.h. für alle Projekte definiert sind und gelebt werden. Sie werden dann je nach Projekt durch einen Prozess namens "Tailoring" an das Projekt angepasst. Die Prozesse umfassen Arbeitsweisen, Werkzeuge, Vorlagen, Checklisten...

All diese Prozesse müssen kontinuierlich verbesssert werden, es wird eine lernende Organisation gefordert.

Sicherheitskultur

Last but not least einer der wichtigsten Faktoren: die Sicherheitskultur. Die Organisation muss vor allem sicherstellen, dass die Sicherheit vor kommerziellen Aspekten steht. Das heisst, dass es nicht mehr möglich ist mit einem heroischen Wochenendeinsatz kurzfristig das Produkt auf den Markt zu werfen. Alle Pläne, Reviews, Audits müssen eingehalten werden.

Zusätzlich wird eine proaktive Einstellung zu Fehlern gefordert und dass aus Fehlern gelernt wird, auf Projekt- und Firmenebene. Klare Pläne ohne ad-hoc Ressourcenallokation sind gefordert und eine nachverfolgbare Verantwortlichkeit.

Keep It Simple

Wie wir bisher gesehen haben, ist der Aufwand für jede Anforderung, jedes Bauteil, jede Zeile Code riesig. Das heisst im Umkehrschluss, dass über jedem Projekt zur funktionalen Sicherheit stehen sollte: Keep it Simple! Jede Anforderung, jedes "nice-to-have" das wegfällt, kann viel Aufwand sparen. Die Devise ist: vereinfachen, was immer geht, auch wenn das dem Produktmanagement häufig zuwider ist.

Was tun wir nun, wenn wir sicherheitskritische Systeme entwickeln wollen?

Und nun, wir soll man vorgehen, dass man in der Lage ist, so zu entwickeln, dass das Produkt funktional sicher genannt werden kann?

Sollen wir neu entwickeln?

Grundsätzlich kann man bestehenden Code, bestehende Schemas und eventuelle Dokumentation nicht für die funktionale Sicherheit "einfach" wiederverwenden. Man muss also alle Tätigkeiten durchführen wie für eine Neuentwicklung und mit Artefakten belegen. Die bestehenden Artefakte können höchstens als "Inspirationsquelle" dienen. Durch die angestrebten Vereinfachungen und die Korrektur der Fehler, welche die strikten Prozesse unweigerlich aufdecken, wird das Produkt so oder so geändert aus dem Prozess hervorgehen.

In seltenen Fällen, wenn die Vereinfachung durch z.B. eine neue Plattform es rechtfertigt, kann eine komplette Neuentwicklung sinnvoll sein. Vom Sicherheitsaspekt her hat ein komplette Neuentwicklung übrigens den Nachteil, dass eventuell neue Fehler eingebaut werden, welche in einem langjährigen Produkt ausgemerzt wurden.

Aber das Produkt läuft doch schon seit Jahren?

Und dann kommt immer wieder die Frage: Können wir das Produkt nicht einfach so lassen, es gab ja bisher keine Ausfälle. Theoretisch ist das möglich, doch sind die Hürden an den Nachweis von Betriebsstunden und lückenlose Rückverfolgbarkeit von Fehlern über Jahre meist so hoch, dass diese Variante praktisch nicht anwendbar ist.

Wie kann man die Entwicklungsfähigkeiten selbst Aufbauen?

Wir sind den Weg gegangen zuerst einmal Level 3 zu erreichen, für uns mit CMMI-DEV (Common Maturity Model Integration for DEVelopment). Dazu haben wir Audits mit externen Spezialisten durchgeführt, zuerst vor allem mit Fokus auf Effizienz. Dann haben wir für die anzuwendenden Sicherheitsnormen und -level eine Gap-Analyse durchführen lassen und die Arbeitsweise, d.h. unsere Prozesse verbessert um die Lücken zu den Sicherheitsnormen zu schliessen.

Der Aufwand für die Erstellung und Pflege einer solchen Prozesslandschaft ist erheblich. Für Solcept von 2011 bis 2018 (8..16 Ingenieure) war der Aufwand zwischen 2 und 4% der jährlichen Arbeitszeit und ca. 30'000 CHF per externes Audit oder per Gap-Analyse.

Es gibt noch andere Wege:

Einerseits gibt es komplette Prozesslandschaften zu kaufen. Die Frage bei diesen ist jedoch, was mit den bestehenden Arbeitsweisen passiert, d.h. ob die Prozesse überhaupt zu Ihrer Organisation passen und lebbar sind.

Man kann auch die Prozesse direkt nach den Sicherheitsnormen erstellen. Wir hatten da Zweifel, ob wir nicht den Fokus auf Effizienz verlieren, welcher CMMI beinhaltet.

Die dritte Methode wäre dann, dem Projektteam die Norm zu geben und dieses dann die Prozesse erarbeiten zu lassen. Diese Methode kollidiert jedoch mit den Anforderungen an Prozesse von Level 3 und mit der geforderten Sicherheitskultur.

Oder die Fähigkeiten von Solcept nutzen!

Wir entwickeln industrieübergreifend für funktionale Sicherheit und auf Wunsch transferieren wir das Projekt inklusive der ganzen Projektprozesse zu Ihnen zurück.

Wenn Sie sich nicht selbst mit den ganzen Prozessen herumschlagen möchten, kontaktieren Sie mich.

Andreas Stucki

Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!