Software-FMEA

Software-FMEA

FMEA für Software-Umfänge – braucht man das? Bis heute ist das auch in Kennerkreisen eine gar nicht so selten gestellte Frage. Die kurze Antwort lautet schlichtweg: ja. Eine inhaltlich sehr verwandte Frage – nämlich die, ob Software für sich überhaupt gefährlich sein kann – ist heute ebenfalls von diversen Komitees und Gremien mit „ja“ beantwortet worden. Die US-amerikanische Zulassungsbehörde FDA stuft etwa Software wie Health-Apps schon seit Jahren als Medizinprodukt (SaMD – Software as a Medical Device) ein, wenn die Auslobung sog. Heilversprechen enthält. 

Verletzungen entstehen im Rahmen einer Unfall- oder Cyberangriffs-Kausalkette final natürlich durch physische Faktoren wie Metall, Strahlung, Aufprall etc. Wenn diese Einordnung befriedigend wäre, könnte man sich auch Analyse und Bewertung sowie dann mehrkanalige Auslegung von Schaltern und ähnlichen Komponenten sparen. Tatsächlich wird man in Systemen mit Gefährdungsbezug  aber kaum Schalter finden, die ohne Abschätzung und Budgetierung von FIT-Raten oder ohne n00m-Auslegung integriert wurden.

Stand heute handelt es sich bei Software aus dieser Sicht genau genommen um Schalter – zusätzlich noch um die komplexesten aber auch am schnellsten zu gestaltenden, die es je gab.

Ansatz und Hintergrund: Entscheidungen

Ein zentraler Ansatz von FMEAs ist generell, dass Entscheidungen bewertet werden. Hier ein Risiko, dass aber kein Entscheidungspotential für ein Fahrzeug beinhaltet: in Kalifornien oder bei Fahrzeugen für den türkischen Markt steht mutmaßlich in keiner FMEA, dass ein Erdbeben auftreten könnte. Das ist – wie man den Nachrichten entnehmen kann – dort tektonisch bedingt durchaus ein handfestes Risiko. Nur: was sollten ein Chassis oder ein Software-basierter Steuerungsvorgang machen, wenn ein Auto im Rahmen eines Erdbebens ein Haus auf das Dach kriegt? Hier liegt in aller Regel kein Design-Ziel.

Gehen wir zu klassischen Projektkrümeln wie etwa Schrauben. Es gibt vermutlich keinen erwachsenen Menschen auf der Welt, der nicht weiß, was Schrauben sind. Trotzdem finden sich immer wieder Fixierungen und Verbindungen in FMEAs, die über Schrauben herstellt werden. Und das zu recht – schließlich bedeutet das Einsetzen einer oder mehrerer Schrauben keineswegs automatisch das Erreichen einer benötigten Fixierung für die gegebenenfalls an einer Schnittstelle wirkenden Kräfte. Schrauben können zu klein oder zu gr0ß sein, zu fest sitzen oder zu locker, sie sind so gewählt oder positioniert, dass sie ein Verdrehen nicht antizipieren, vielleicht nicht oft genug Montage/Demontage ermöglichen usw. usf.

Letzten Endes betrachtet man bei Design-Betrachtungen also die Entscheidungen von Entwicklern und Konstrukteuren: ist die Schraubentype M5x25 für den Einsatzzweck geeignet? Und: kann man zur Design-Phase noch erkennen, wenn ein Irrtum – eine falsche Entscheidung – vorläge?

Schlüssel: Merkmale

Wenn man behauptet, dass eine Software-FMEA keinen Sinn macht, behauptet man implizit so etwas wie: bei Software wird ja nichts entschieden. Das Gegenteil ist aber der Fall: mit jeder Zeile Code wird etwas entschieden. Das wäre dann vergleichbar mit einer Schraubverbindung im Bereich von Teilen/Parts. Ebenso wird auf höherer Ebene eigentlich durchgehend etwas entschieden: für oder gegen eine Programmiersprache, eine Version und Art der ausführenden Umgebung (Bash, Windows-Shell, Powershell, Java-Engine etc.), für oder gegen eine Modellierung (UML, SysML, Archimate, BPMN, …), ein Programmierparadigma (imperativ, funktional, objekt-orientiert, …). Diese Entscheidungen sind vergleichbar mit der Wahl oder Betrachtung von Komponenten.

Systeme und Software werden heute regelmäßig modellbasiert entwickelt. Diagramm 1 repräsentiert einen relativ einfachen Ablauf und stellt dabei die Interaktionen eines Hauptprogramms mit drei Modulen dar. Strukturell nicht anders als bei Platinen-Layouts in der Elektronik oder bei technischen Zeichnungen in der Mechanik stellen hier jede Linie, jeder Block und jeder Parameter-Eintrag eine Entscheidung eines Software-Ingenieurs dar. Auch wenn der Begriff in der Softwarewelt unüblich ist: es handelt sich hier um Produktmerkmale: in diesem Fall um Parametrisierung (welche Werte sollen Parameter haben?), Parametrierung (welche Parameter sollen überhaupt benutzt werden?), Granularität (Aufteilung in Module, Größe der Module). 

Diese Produktmerkmale kann man ebenso mit Fehlerursachen versehen wie in der Mechanik, Elektronik oder auch Finanzmathematik. Und natürlich kann man auch jeweils beschreiben, wie der Denkansatz eigentlich sein sollte und wie mögliche Design- bzw. Denkfehler früh gefunden werden könnten.

Neben Abläufen – wie in Diagramm 1 – gibt es bei Software zahlreiche weitere Design-Aspekte. Die Systemstruktur muss ebenso entwickelt werden. Das ist durchaus vergleichbar mit modell-basierten FMEAs: hier gibt es auch nicht nur einen Haufen Funktionen sondern Systemelemente, denen die Funktionen zugeordnet sind. 

Darüber hinaus gibt es auch eine Seite, die strukturell Prozess-FMEAs entspricht. Schließlich ist auch Software keineswegs fertig, weil eine Lösungsskizze auf einem Laptop eines Entwicklers gespeichert ist. Fragen des Packagings und des Deployments schließen sich an. Nicht umsonst sehen die Modellierungssprachen SysML und UML dafür auch eigene Diagrammnotationen vor.

Wie ist das mit der Komplexität?

Software-FMEAs können ähnlich wie Design-FMEAs von den Merkmalen her relativ ausufernd sein, keine Frage. Das „Universum“ ist hier ebenso breit und nicht so einfach auf Joker wie 4M in der Prozess-FMEA herunterbrechbar. Anderseits gibt es Häufungen wie sie im Design auch auftreten. So finden sich in Design-FMEAs sehr oft Betrachtungen von Punkten wie Geometrie/Tolerierung. Das ist deswegen so, weil das natürlich auch der Hauptgegenstand mechanischer Konstruktion ist. Das Pendant im Software-Bereich dazu ist die Ausführungsvorschrift bzw. der Algorithmus. Softwareentwickler entscheiden eben sehr häufig über diese Abläufe. Nahezu 80% aller Software-Implementierungen haben mit Problemen des Sortierens und des Suchens zu tun. Und hierfür gibt es diverse Algorithmen, ähnlich wie man auch genormte Schraubenformen einsetzt. Algorithmen können gut arbeiten bei kleinen Eingabemengen aber dann sehr langsam werden, man kann Geschwindigkeiten erhöhen, indem man mehr Speicher benutzt (so ähnlich wie das „Vorsortieren“ von Kleidung auch Extraplatz vor dem Koffer benötigt, den man Zuhause leicht hat – aber vor dem Schalter am Flughafen vielleicht nicht mehr) und Algorithmen können auch für den Programmierer einfacher oder viel schwerer handzuhaben sein.

Sinnfrage: JA!

Zur Absicherung all dieser Entscheidungen ist eine FMEA für Software genauso sinnvoll wie in der Mechanik. Oder noch sinnvoller. Denn: das Wissen von Ingenieuren in der Mechanik, Verfahrenstechnik oder Elektronik ist über viele Jahrzehnte kanonisch geworden. Also: wie beim Singen eines Kanons – man singt relativ genau dasselbe. Informatik und Softwaretechnik sind hingegen relativ jung. In der Programmiersprache C etwa kennen Programmierer durchschnittlich zwischen 5% und 10% der vorhandenen Sprachelemente. Die Programmierer in einem Projekt kennen aber kaum je die gleichen 5% der Konstrukte. Je nach Ausbildung und Art der durchgeführten Projekte kann es auch sein, das Programmierer nur minimal überschneidendes Wissen haben – also praktisch wie zueinander fachfremd stehen. Insofern ist der über FMEA-Workshops erreichbare Austausch über Vorgehensweisen, Maßnahmenqualitäten etc. hier sogar besonders empfehlenswert.