Software Safety Analyse/ Software FMEA

Lesezeit 6 min

Müssen Sie eine Software Sicherheitsanalyse (SW FMEA) erstellen für Ihr Projekt und wissen nicht, wie man das macht? Haben Sie die vorhandene Literatur angeschaut, die Einträge im Web gesichtet und sind daraus doch nicht schlauer geworden?

Haben Sie in den für Ihr Projekt anwendbaren Normen nach Hinweisen zur Durchführung einer SW FMEA gesucht, aber nur vage Floskeln gefunden? Haben Sie zudem den Anspruch, dass Sie eine solche Analyse nicht nur proforma abhaken, sondern damit tatsächlich die Sicherheit Ihres Produkts erhöhen wollen?

Die folgende Beschreibung geht davon aus, dass Sie mit den grundsätzlichen Begriffen einer qualitativen FMEA bereits vertraut sind. Falls nicht, finden Sie entsprechende Informationen in "Effective FMEAs" von Carl S. Carlson oder in der IEC 60812.

Wieso überhaupt eine Software Sicherheitsanalyse?

Hardware-Komponenten werden immer zuverlässiger. Zufällige Hardware-Fehler (permanente und transiente) können zudem mit etablierten quantitativen Analysemethoden gut untersucht werden (z. B. FMEDA nach ISO 26262).

Schwieriger ist es hingegen, systematische Fehler (Software-Fehler gehören in diese Kategorie) zu analysieren und einzugrenzen. Mit zunehmender Komplexität und damit zunehmendem Anteil von Software wird die Produktsicherheit immer mehr durch systematische Softwarefehler bestimmt. Der Stellenwert der Software Sicherheitsanalyse nimmt damit dauernd zu.

Wie gehe ich am besten vor für eine solche Software FMEA?

Im Folgenden das Schritt-für-Schritt Vorgehen, welches sich bei Solcept bewährt hat:

1. Team bilden und einen Moderator bestimmen.
   • Im Gegensatz zu anderen FMEA's müssen Sie bei einer SW FMEA kein interdisziplinäres Team haben, d.h. das Team kann ausschliesslich aus SW-Spezialisten bestehen. Es ist allerdings von Vorteil, wenn die Teammitglieder einen möglichst diversitären Projekt- bzw. Erfahrungshintergrund haben und das zu beurteilende System und das dazugehörige Software-Design gut kennen.
2. Die Dokumentation einer qualitativen FMEA aufsetzen (z.B. gemäss IEC 60812).
   • D.h. eine Risikoanalyse mit Bewertung des Schweregrades eines Fehlers, dessen Auftretenswahrscheinlichkeit und der Wahrscheinlichkeit der Fehler-Detektion.
   • Dies kann in einem Spreadsheet gemacht werden oder mit einem dedizierten Software-Werkzeug.
     • Solche Software-Werkzeuge haben gegenüber Spreadsheets vor allem den Vorteil einer einfacheren und integrierten Dokumentation der Resultate aus den Experten-Meetings. Zusätzlich bieten sie Projekt-Management Features für z.B. die Nachverfolgung von Befunden.
3. Im Team das Sicherheitsziel, die Bewertungskataloge und die Risikomatrix der FMEA bestimmen (Anhaltspunkte siehe unten).
   • Ebenso die Art der Mediation/ Entscheidungsfindung im Falle von Meinungsverschiedenheiten innerhalb des Teams.
4. Im Team den Analysebereich der FMEA aufs Minimum reduzieren.
   • Die Diskussionen im Expertenteam sollen sich auf die hauptsächlichen Architektur-Themen der Software beschränken. Alle anderen Fehlerquellen müssen über die Architektur- und Codierrichtlinien eliminiert werden.
   • Die Abgrenzung zwischen Safety Analyse und Codierrichtlinien/ automatischer statischer Code Analyse ist insofern wichtig, als dass sie signifikante Auswirkungen auf den Gesamtaufwand des Projektes haben kann.
5. Im Team die Architektur- und Codierrichtlinien einem Review unterziehen.
   • Je nach Reife dieser Richtlinien muss das Team (z. B. in einem Brainstorming) Architekturelemente (z. B. state machine, fixed-point Arithmetik, Ringbuffer, Arrays, Kontrollstrukturen) und dazugehörige bekannte Fehlerquellen aufzählen und entscheiden, ob diese in den Richtlinien oder im Experten-Meeting abgehandelt werden.
   • Zu diesem Zeitpunkt werden auch die Regeln der statischen Code-Analyse (z. B. Untermenge der MISRA Regeln) bestimmt.
6. Im Team eine Liste der Präventions- und Detektionsmassnahmen erstellen.
   • Diese ist meist aufgrund des angewendeten Software Entwicklungsprozesses oder der anwendbaren Sicherheitsnorm ohnehin gegeben (z. B. Anwendung von Richtlinien, Code Reviews, Unit Tests, Robustness Tests und andere Verifikationsmassnahmen gemäss V-Modell, Review der Testabdeckung etc.). Sie können während der Analyse dann vereinfacht behandelt werden (tiefe Occurrence und Detection Ratings).
   • Es ist ein weitverbreiteter Fehler die Software Sicherheitsanalyse dazu zu missbrauchen, Massnahmen zu spezifizieren, die durch die normale Entwicklungstätigkeit ohnehin bereits getan werden müssen. Die Analyse macht dann fälschlicherweise den Anschein, als würden viele Risiken aufgefunden und entsprechende Massnahmen definiert, doch in Realität bildet sie nur den normalen Entwicklungsprozess ab.
7. Im Team die einzelnen Software Teile und die darin enthaltenen wesentlichen Architekturelemente durchgehen.
   • Anhand der möglichen Fehler, die darin auftreten können (Checklisten!) die Risiken einschätzen und allfällige Massnahmen definieren.
   • Zur Analyse gehört neben der Architektur auch eine Untersuchung des Kontroll- und Datenflusses. Falls dazu keine Dokumentation vorliegt, muss sie zuerst erstellt werden.
8. Anpassung des Software Designs durch das Entwicklungsteam.
9. Nach der Design Anpassung muss das Team die effektiv umgesetzten Massnahmen neu evaluieren und eventuell Nachbesserungen verlangen, bis die Risiken als genügend tief eingeschätzt werden.

Der Moderator dokumentiert die Ergebnisse aller obigen Schritte, d.h. der Experten-Meetings und sorgt dafür, dass alle Softwareteile, darin enthaltene Architekturelemente und ihre Fehlerquellen abgedeckt werden.

Welche Bewertungskataloge sind anzuwenden?

Die Bewertungskataloge richten sich nach den Projektbedürfnissen. Im Folgenden werden einige Anhaltspunkte gegeben.

Wichtig: Wenn man in einem Bereich weniger als 10 Stufen definiert, soll man trotzdem den Wertebereich zwischen 1 und 10 verwenden, damit der Einfluss auf die Risikozahl von allen Faktoren her identisch ist.

Schweregrad (Severity)

Will man nur die Sicherheit beurteilen, so genügt es, zwischen "no influence": 1 und "safety risk": 10 zu unterscheiden. Meistens wird aber mehr in die Analyse hineingepackt, z. B. der "Verlust der Verfügbarkeit" oder der Verlust von nicht-sicherheitsrelevanten (primären oder sekundären) Merkmalen des Produkts als Zwischenstufen.

Auftretenswahrscheinlichkeit (Occurrence)

Am unteren Ende der Skala ("almost never": 1 oder "remote": 1 sind hier Fehler angesiedelt, die bereits durch eine präventive Massnahme eliminiert werden. Ebenfalls wird eine tiefe Fehlerwahrscheinlichkeit angenommen, falls man zeigen kann, dass eine Software "well trusted" ist, d.h. wenn man nachweisen kann, dass sie in einer vergleichbaren Anwendung seit Jahren fehlerfrei läuft. Bei neuen Software-Teilen wird die Fehlerwahrscheinlichkeit mit zunehmender Komplexität höher eingestuft (auch hier zahlt sich Einfachheit aus).

Die höchste Fehlerwahrscheinlichkeit ("very high": 9, "almost certain": 10) besteht, wenn für einen Software-Teil die Anforderungen (noch) unvollständig sind oder gänzlich fehlen. Das heisst nicht, dass während der Software FMEA ein Anforderungs-Review durchgeführt wird! Vielmehr werden Punkte, deren Spezifikationen bezüglich des Sicherheitsziels als fehlend oder unklar erachtet werden, entsprechend behandelt.

Detektierbarkeit (Detection)

Hohe Detektierbarkeit ("obvious": 1) besteht, wenn entsprechende Verifikationsmassnahmen vorhanden sind, am besten bereits auf Unit Test Level und dann mit abnehmender Wahrscheinlichkeit auf Modultest- (mit oder ohne Hardware) oder Systemtest-Niveau. Review- oder Analyse-Massnahmen ergeben kleinere Detektierbarkeit, und zwar umso kleiner, je grösser der Bereich der Software ist, den man in der Review untersuchen muss. Das Rating "almost impossible" (10) wird vergeben, wenn man keine Ahnung hat, wie ein Fehler detektiert werden kann.

Risiko-Matrix

Im Prinzip kann mit einer einfachen Risikoprioritätszahl (RPN) gearbeitet werden, die man aus dem Produkt der Severity (S), Occurence (O) und Detection (D) Bewertung berechnet: RPN := S*O*D. Dazu wird dann ein RPN-Schwellwert bestimmt, über dem zwingend eine Massnahme ergriffen werden muss. Je nach Projekt sind aber auch detailliertere Entscheidungsmatrizen sinnvoll und können durch das Team bestimmt werden.

Was muss im Analysebericht vorhanden sein?

Die folgende Checkliste kann verwendet werden, um die Vollständigkeit des Analyseberichts sicherzustellen:

• Zweck der Analyse
• Sicherheitsziel, eventuell andere untersuchte Ziele (z. B. Verfügbarkeit, nicht sicherheitsrelevante funktionale Ausfälle)
• Beschreibung der Methode Schritt für Schritt
• Angewendete Normen
• Team-Mitglieder mit Ausbildungsgrad und Erfahrungshintergrund
• Bereich, über den sich die Analyse erstreckt, Detaillierungsgrad (gesamte Software/ Software-Teil...)
• Referenz auf anwendbare Software-Entwicklungsprozesse und Richtlinien
• Referenzierte Dokumente
• Liste der untersuchten Architekturelemente
• Verwendete Tools
• Verwendete Bewertungskataloge und Risikomatrizen
• Systembeschreibung (grob)
• Architekturbeschreibung und Identifizierung der analysierten Software-Teile
• Resultate Zusammenfassung
• Resultate Kommentar/ Erklärung, falls nötig
• Anhang: Liste der umgesetzten Massnahmen
• Anhang: Verweis auf die Protokolle der Experten-Meetings

Viel Erfolg!

Das beschriebene Verfahren hat sich bei Solcept als äusserst effektiv erwiesen. Der Wert für das Projekt und das Produkt liegt vor allem in den Diskussionen, die im Expertengremium stattfinden.

Unsere Erfahrung zeigt, dass sich durch das Verfahren nicht nur die Sicherheit erhöht. Es erhöht auch die Software-Qualität insgesamt, die Dokumentation und die Entwicklungsprozesse und es resultiert in einem grösseren Einsatz der Ingenieure bei der Definition von Prozessen und Richtlinien.

Im Übrigen ist es erstaunlich (und sehr vergleichbar zu den Auswirkungen von EMV-Messungen), welche Änderungen im Projekt sonst noch angestossen werden aufgrund der Arbeit des SW FMEA Teams. Sie werden sich beim Gedanken ertappen, dieses Instrument nicht nur in Projekten der funktionalen Sicherheit einzusetzen.

Wir wünschen Ihnen viel Erfolg dabei!

Samuel Leemann

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