Aus Theorie wird Praxis

Die größte Herausforderung bei einer Safety-Analyse ist die hohe Komplexität  heutiger Software-Architekturen. Oftmals erstrecken sich diese über unterschiedliche Abstraktionsebenen und ihre Entwicklung erfolgt parallel und verteilt auf unterschiedliche Entwicklungsteams. Fehler und ihre Effekte können dadurch nicht von einer Partei alleine analysiert werden. Deshalb ist es essentiell, ein gemeinsames Verständnis von Methode, Umfang und Tiefe der Analyse zu entwickeln. Ebenso müssen die Schnittstellen in der Analyse genau festgelegt werden. Dank erfahrener interdisziplinärer Projektteams ist FEV in der Lage, Prozesse zu entwickeln, die allen diesen Anforderungen gerecht werden – und dies selbst über Länder und Kontinentalgrenzen hinweg. Zudem verfügt FEV über umfassende zuliefererrelevante Daten, sowie  über Wissen um die Schnittstellen und deren spezifische Anforderungen. Nur so ist eine ganzheitliche Entwicklung und Absicherung möglich.

Die ISO26262 fordert verschiedene Safety-Analysen der Software-Architektur, die Entwickler vor große Herausforderungen stellen. Einerseits gilt es nachzuweisen, dass alle geforderten Software-Elemente vorhanden sind, effektiv sind und nach dem richtigen ASIL (Automotive Safety Integrity Level) entwickelt werden. Die zweite geforderte Safety-Analyse betrachtet darüber hinaus die abhängigen Fehler. Sie dient dazu nachzuweisen, dass alle Komponenten voneinander unabhängig sind und sich nicht gegenseitig beeinflussen. Für diesen Nachweis werden Fehler gemeinsamer Ursache sowie kaskadierende Fehler, die auf das Design der Software-Architektur zurückzuführen sind, betrachtet.

Einen praktischen Ansatz für die Herangehensweise hat die FEV entwickelt. Bastian Wirges, FEV-Experte für funktionale Sicherheit, erklärt am Beispiel einer Getriebesteuerungssoftware die Zusammenhänge und Abhängigkeiten. Im Rahmen des interdisziplinären Entwicklungsauftrags arbeiten Getriebe- und Software-Experten der FEV zusammen.

Herr Wirges, können Sie anhand eines stark vereinfachten Auszuges der Software-Architektur die Herangehensweise erklären?

Legen wir einmal die Bestimmung und Anwahl des nächsten Zielganges unseres Getriebes zugrunde: In einem ersten Schritt muss auf Getriebesystemebene die funktionale Kette mittels der HAZOP-Schlüsselwörter – beispielsweise zu hoch, zu niedrig, zu früh, zu spät, zu schnell, zu langsam, analysiert werden.
Ein „zu niedriger“ Gang kann zur Blockade der Räder führen, was einer Verletzung eines Sicherheitsziels auf Fahrzeugebene entspricht. Daher muss ein Sicherheitsmechanismus definiert werden, der überwacht, ob ein zu niedriger Gang eingelegt wird.

Und dann?

Für die Analysen der Software-Architektur muss der Daten- und Kontrollfluss der gesamten Architektur mit einem speziellen Fokus auf die Interaktion der Software-Komponenten und gemeinsam genutzten Ressourcen betrachtet werden. Hier werden Software-spezifische Schlüsselwörter gemäß der ‚Software Hazard Analysis and Resolution in Design‘-Methode – kurz SHARD – genutzt. Dazu gehören Schlüsselwörter wie: auslassen, hinzufügen, grob falsch, subtil falsch, falsche Zeit.

Was bedeutet dies für unser Getriebebeispiel?

Wenn die Information über den niedrigsten erlaubten Gang “falsch” vom Monitor empfangen wird, kann dieser nicht mehr effektiv arbeiten. Dies führt also zu einem kaskadierenden Fehler. Wenn die Information ganz „ausgelassen“ oder zu einer „falschen Zeit“ übermittelt wird, funktioniert der Monitor gar nicht mehr. Aus diesem Grund werden zwei weitere Sicherheitsmechanismen benötigt: Ein Schutz der Informationen, die übertragen werden sollen, sowie die Überwachung, ob diese Übertragung richtig und innerhalb der vorgegebenen Zeit stattgefunden hat.

Wie beeinflussen diese Analyse-Ergebnisse die weitere Entwicklung?

In diesem konkreten Fall wurde die Design-Entscheidung getroffen, den Schutz der Übertragung teilweise in einer zentralen Software-Komponente unterzubringen. Ein Fehler in dieser Komponente wäre damit ein Fehler gemeinsamer Ursache, so dass auch diese Funktion überwacht werden muss. An dieser Stelle stoppt die Analyse, da das System lediglich gegen Doppelfehler sowie latente Fehler robust sein muss.