Software wird branchenübergreifend immer komplexer und autonomer. Komplexe Systeme, wie beispielsweise Assistenzsysteme in Flugzeugen oder autonom fahrende Autos, stellen Hersteller vor besondere Herausforderungen. Welche Aspekte bei sicherheitskritischen Anwendungen zu beachten sind und wie du in deinen Projekten Risiken bewerten und auf ein Minimum reduzieren kannst, erfährst du in diesem Artikel.
Bei den Abstürzen der beiden Boeing-737-MAX-Maschinen im Oktober 2018 und März 2019 steht ein Softwarefehler im Verdacht, initialer Auslöser für das Unglück und den Tod von über 340 Menschen zu sein.
Inzwischen ist so gut wie sicher, dass ein defekter Sensor dafür gesorgt hat, dass sich das MCAS-Trimmsystem auf falsche Daten bezogen und die Flugbahn der beiden Boeing-Maschinen essentiell verändert hat.
Das MCAS-System sollte die Piloten dabei unterstützen, das Flugzeug stabil zu halten und das Abreißen des Luftstromes durch einen falschen Anstellwinkel zu verhindern. Stattdessen wird vermutet, dass das MCAS dafür gesorgt hat, dass sich die Nase der Boeing-737-MAX immer weiter senkte.
Die Auswertung der Blackboxen hat mittlerweile ergeben, dass die Piloten versuchten die Boeing-737-MAX durch Gegensteuern und die Beschleunigung des Flugzeugs außer Gefahr zu bringen. Doch genau hierin lag laut Experten-Aussagen der fatale Fehler. Es kam nach bisherigen Erkenntnissen zu einem Blowback, der schlussendlich zum Absturz der Boeing-737-MAX führte.
Sicherheit ist ein zentraler Dreh- und Angelpunkt bei der Entwicklung komplexer Anwendungen, die Risiken für Leib und Leben bergen. Kleinste Fehler, wie beispielsweise eine unzureichende Testabdeckung oder die fehlende Nachverfolgbarkeit von Anforderungsänderungen, können fatale Folgen nach sich ziehen.
Insbesondere durch die Innovationen unserer Zeit werden Systeme zunehmend komplexer.
Die Zahl der Abhängigkeiten zwischen diversen Subsystemen steigt stetig, ebenso die Menge der zu verarbeitenden Daten, die von einer zunehmenden Anzahl von Sensoren und Subsystemen erzeugt werden.
Für Hersteller stellen diese sicherheitskritischen Systeme ein schwer zu kalkulierendes Risiko dar. Die Gefährdung von Gesundheit und Menschenleben steht dabei ganz oben an, wie etwa im Fall der beiden abgestürzten Boeing-737-MAX. Das Image des Unternehmens steht ebenfalls auf dem Spiel, von den finanziellen Verlusten ganz abgesehen.
Folgende Methoden helfen bei der Konzeption und Erstellung sicherheitskritischer Software:
Durch die formale Verifikation wird der formale, mathematische Beweis erbracht, dass ein Programm korrekt ist. Korrekt bedeutet in diesem Zusammenhang, dass das Programm alle vorab spezifizierten Eigenschaften aufweist.
Mittels Model-Checking könnte am Beispiel einer Steuerung für den Schienenverkehr bewiesen werden, dass unter keinen Umständen ein Zustand eintreten kann, in dem zwei Züge kollidieren.
Diese Methode hat den großen Vorteil, dass das Programm für sämtliche spezifizierten Fälle und Daten die korrekten, erwarteten Ergebnisse liefert und Fehlfunktionen im Modell ausgeschlossen sind.
Bitte beachte, dass alle formalen Methoden auf Annahmen beruhen. Diese Annahmen können im Produktiveinsatz verletzt werden und es kann dennoch zu Fehlverhalten führen. Darum ersetzt formale Verifikation nicht das Testen!
Die Spezifikation stellt dabei eine hohe Herausforderung dar! Es ist entscheidend, wirklich alle Fälle und Daten zu bedenken, zu spezifizieren und natürlich auch zu verifizieren.
Wenn du anhand eines konkreten Beispiels mehr über Model-Checking erfahren möchtest, findest du hier weitergehende Informationen.
Formale Verifikation lässt sich durch verschiedene Konzepte umsetzen, siehe den Verweis oben. Leider ist sie bislang nur eingeschränkt anwendbar, da für eine einzelne Codezeile ein Vielfaches an Spezifikationen geschrieben werden muss.
Die probabilistische Sicherheitsanalyse stammt aus der Nukleartechnik, lässt sich aber auch in anderen Domänen einsetzen. Sie betrachtet das Auftreten seltener Ereignisse oder Kombinationen davon. Einzelausfälle, Mehrfachausfälle, Ausfälle durch eine gemeinsame Ursache und menschliches Versagen können mit ihrer jeweiligen Eintrittswahrscheinlichkeit berücksichtigt werden.
Die Simulations- und Treiber-Software muss alle möglichen Eingaben und Systemzustände prüfen. Wahrscheinlichkeiten und zeitliche Verläufe sind bei den Testläufen zu berücksichtigen. Aufgrund der Vielzahl möglicher Verzweigungen ist dieses Verfahren äußerst aufwändig und stößt je nach Komplexität des Systems schnell an Grenzen.
In solchen Fällen ist es hilfreich, wenn man die Anzahl der Verzweigungen auf die tatsächlich möglichen einschränken kann und diejenigen Szenarien außen vor lässt, die ohnehin nicht eintreten können.
Claudia Picoco beschreibt in ihrem Gastbeitrag auf unserem Blog, wie sie realistische Unfallmodelle aufbaut, aus denen sämtliche möglichen Unfallverläufe in Form von Dynamic Event Trees (DET) generiert und simuliert werden.
Trotz einer solchen Beschränkung auf die realistischen Szenarien bleibt die Skalierbarkeit bei der Simulation dynamischer Ereignisbäume noch ein großes Problem.
Durch weitere Forschung in diesem Bereich setzt sich itemis für die Verbesserung der Methodik ein, um insbesondere sicherheitskritische Systeme sicherer zu machen.
Ein weiterer wichtiger Punkt im Hinblick auf die Sicherheit von Software ist die Nachverfolgbarkeit der gestellten Anforderungen. Requirements-Traceability stellt formal sicher, dass alle Anforderungen an die Software im Produkt tatsächlich umgesetzt wurden.
Auch in diesem Kontext ist im Vorfeld besonderes Augenmerk auf die Anforderungserhebung zu legen, um wirklich alle möglichen Szenarien abzudecken.
Mit Hilfe von Requirements-Traceability lässt sich unter anderem nachvollziehen, ob Anforderungen richtig umgesetzt wurden und ob die Software die zuvor definierten Tests bestanden hat. Ebenfalls lässt es sich sicherstellen beziehungsweise überprüfen, dass im Fall von Anforderungsänderungen die relevanten Tests erneut durchgeführt werden.
Requirements-Traceability ist ein wichtiger Baustein bei der Einhaltung sicherheitsbezogener Normen, quer durch alle Branchen.
Angefangen bei IEC61508 als übergeordnete Norm für die Entwicklung von elektrischen, elektronischen und programmierbaren elektronischen Systemen im Allgemeinen. Bis hin zu anwendungsspezifischen Normen wie:
Eine Schwierigkeit bei der Sicherstellung von Requirements-Traceability ist die große Zahl an Werkzeugen und Informationen, die integriert und verknüpft werden müssen.
Im Blogbeitrag „Weaving testing into the web of traceability“ geht mein Kollege Andreas Graf etwas detaillierter auf die erforderliche Nachverfolgbarkeit von Anforderungen sicherheitskritischer Software im Automobilbereich ein.
Ein Angreifer hackt sich in die Steuerung eines autonom fahrenden Autos oder manipuliert die Weichenstellung im Zugverkehr. Auch solche Extrem-Szenarien sind mögliche Risiken in vernetzten, sicherheitskritischen Systemen.
Umso wichtiger ist es, drohende Risiken zu erkennen, deren Ausmaß richtig einzuschätzen und mit ihnen umzugehen – und das bereits während der Entwicklung.
Standards, die sich des Themas Cyber Security annehmen und klare Anforderungen definieren, kommen gerade erst auf.
Was jedoch bereits jetzt klar ist: Neue Methoden und Tools sind notwendig, um Bedrohungen frühzeitig und umfassend erkennen und einschätzen zu können. Nur so kann man noch im Entwicklungsprozess angemessen darauf reagieren.
Wenn dich das Thema Cyber Security interessiert, lies unbedingt auch den Beitrag „Why security is one of the biggest engineering challenges ahead“.
Ob es nun tatsächlich ein Softwarefehler war, der das Schicksal der beiden Boeing-737-MAX besiegelte, bleibt derzeit noch offen.
Umso wichtiger ist und bleibt die Minimierung möglicher Risiken sicherheitskritischer Systeme wie die des MCAS-Systems von Boeing.
Unabdingbar: Bereits während der Entwicklung müssen alle erdenklichen Risiken bedacht und deren Impact richtig eingeschätzt werden.
Im Fall der beiden Boeing-Maschinen hätte mutmaßlich die Deaktivierung des MCAS-Systems einen Absturz verhindern können. Sich jedoch darauf zu verlassen, dass die Piloten in einer Stresssituation in Bruchteilen von Sekunden die richtige Entscheidung treffen, bei einem noch neuen, ihnen unzureichend bekannten System, ist fahrlässig.
Wir haben aus dem Boeing-Unglück gelernt, dass wir weitere Anstrengungen unternehmen müssen, um bestehende Lösungen in die Entwicklungsprozesse einzuführen und diese durch Forschung und Innovation weiter zu verbessern.
Wenn dieser Beitrag hilfreich für dich war, hinterlasse mir jetzt einen kurzen Kommentar und teile den Beitrag mit deinem Netzwerk!