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.
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.
Im Folgenden das Schritt-für-Schritt Vorgehen, welches sich bei Solcept bewährt hat:
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.
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.
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.
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.
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.
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.
Die folgende Checkliste kann verwendet werden, um die Vollständigkeit des Analyseberichts sicherzustellen:
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!
ist MSc EE ETHZ und Hardware-, System- und Safety-Spezialist sowie Mitbesitzer an Solcept. Seine früheren beruflichen Tätigkeiten waren im kaufmännischen Bereich und in der Entwicklung von Medizin- und Kommunikationstechnik. Prinzipien, die ihn bei Entwicklungsarbeiten leiten sind Einfachheit und Sicherheit. Samuel ist Alltagsvelofahrer, wandert gerne und hält sich mit Yoga fit.
Projekte? Ideen? Fragen? Machen wir einen kostenlosen Erst-Workshop!
Keine Kommentare