Funktionale Sicherheit: der Unterschied zu "normaler" Entwicklung

Der Kunde findet ihr Produkt fantastisch, hätte es nur gerne mit einem funktionalen Sicherheitslevel: DAL, SIL, ASIL, PL ...nur wenige Buchstaben mehr im Lastenheft. Was bedeutet das für Ihre Entwicklung? Was müssen Sie nun tun, wenn Sie den Kundenwunsch erfüllen wollen? Wenn Sie die entsprechenden Normen lesen und Ihnen immer noch nichts klar ist, sind Sie nicht der einzige...

Funktionale Sicherheit ist nicht einfach ein weiteres Feature für das Datenblatt, wie eine andere Farbe des Turnschuhs. Funktionale Sicherheit ist eher ein Berglauf, der die ganze Entwicklung fordert.

Ich zeige grob auf, was die wichtigsten Unterschiede von einer solchen funktional sicheren zu einer rein funktionalen Entwicklung sind. Dies geschieht in diesem ausführlichen Beitrag in folgenden Schritten:

Eine Zusammenfassung als kurze Liste finden sie hier.

 

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 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 embedded funktionale Sicherheit 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 heisst "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 Change Management 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 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

Eine Analyse, welche vor allem den Entwickler des gesamten Systems stark beschäftigt:

  • Hazard-/ Risikoanalyse: Zuallererst muss festgelegt werden, welchen der 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 noch ein kleines Glossar der häufigsten Abkürzungen:

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, EN 62061

Die anderen Analysen finden dann auf jeder Ebene statt: System, Subsystem, Komponente, Funktion, sowohl für Soft- als auch Hardware, 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 Wahrscheinlichkeiten zugeordnet werden.
  • Failure Modes and Effects Analysis (FMEA): Die FMEA im Gegensatz geht induktiv vor, vom der Ursache zum Fehler. Die Fragestellung ist hier für jedes Subsystem/ Bauteil: Was für sicherheitsrelevante Ausfälle könnten 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? 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 und -mechanismen für die 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 gerechnet wird.

Sicherheitsmechanismen

Basierend auf den Sicherheitsanalysen müssen Sicherheitsmassnahmen ergriffen werden, um die entdeckten Ausfälle abzufangen.

  • gegen zufällige Hardwarefehler
  • gegen systematische Softwarefehler
  • gegen 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 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 verfeinerte 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 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 (speziell "derived") Anforderungen ist zu verhindern, dass unbeabsichtigte Funktionen in die Implementation eingefügt werden, z.B. durch den Programmierer. Diese kommen üblicherweise von Anforderungen welche Interpretationsspielraum zulassen oder guten Absichten, wie defensivem Programmieren. Beide können zu unbeabsichtigten Fehlfunktionen führen. 

Zum V-Modell noch ein wichtiger Punkt: Das V-Modell sollte nicht primär als Ablaufdiagramm, sondern vor allem 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 hier 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. Teilweise finden sogar mehrere Reviews statt, wenn noch ein Qualitätssicherungs-Review oder die Review gegenüber dem Standard verlang wird.
  • Checklisten: Zu jedem Artefakt gibt es im Normalfall eine Checkliste. Ohne Evidenz der durchgeführten Review geht nichts, daher müssen alle ausgefüllten Checklisten als Review-Resultate abgelegt werden.
  • Tests: Es gibt Testspezifikationen, Testinstruktionen, vielleichtTestcode und natürlich auch hier wieder Evidenz aller Testresultate. Die Tests müssen Anforderungs-basiert sein, unter anderem darf es keinen Test ohne 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 genommen 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 die 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

Um eine homogene Qualität über das ganze Projekt sicherzustellen, werden für viele Artefakte Standards 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 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. Diese sollten möglichst lange erhältlich sein, damit man die Sicherheitsnachweise bei Komponentenänderungen nicht immer wieder erbringen muss. Zusätzlich wäre es gut, 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 nagt der Zahn der Zeit, bzw. der technologische Fortschritt. Und da es meines Wissens keine Organisation gibt, welche neue statistische Daten zu Ausfallwahrscheinlichkeit und -mechanismen moderner Komponenten erhebt, kann es sehr mühsam werden, eine realistische quantitative Analyse der Ausfallwahrscheinlichkeit einer Schaltung zu berechnen. 

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 funktionale 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.

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 der funktionalen Sicherheit 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.

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 (Common 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, auch 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.

Wie kommen wir da hin?

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

Stichworte/ Tags

29.10.2018 | Anton Sulovsky

Eine der besten und realistischsten Zusammenfassung, die ich je gelesen habe...

Was ist Ihre Meinung?

Teilen auf