Produktentwicklung auf Softwareebene (Teil 6 der ISO 26262)
Wollen Sie sicherheitskritische Softwarekomponenten für Autos und andere Straßenfahrzeuge entwickeln? In unserem Video und Whitepaper finden Sie die nötigen Infos, wie Sie dafür sorgen müssen, dass die Software fehlerfrei ist.
Zurück zur Funktionalen Sicherheit
Ein kompakter Überblick zur Produktentwicklung auf Software-Ebene? Unser kostenloses Whitepaper enthält alle wichtigen Informationen und hilfreiche Illustrationen zum sechsten Teil der ISO 26262 – ideal für alle, die neu in das Thema Prozessverbesserungen für sicherheitskritische Systeme einsteigen.
In diesem Whitepaper geht es um die Softwareentwicklung für elektronische Systeme für Straßenfahrzeuge, insbesondere für die Software, die in Steuergeräten in Autos verwendet wird. Wenn Sie an einer solchen Softwareentwicklung beteiligt sind, fragen Sie sich wahrscheinlich, wie sich diese Softwareentwicklung von der in anderen Bereichen unterscheidet.
Wir sprechen hier über Software in Straßenfahrzeugen. Das ist die gesamte Software in den verschiedenen Steuergeräten, Sensoren und Aktuatoren. Funktionale Sicherheit bedeutet nun, dass diese Software zur Sicherheit der Fahrzeuge beiträgt und die Sicherheit nicht gefährdet. Genauer gesagt, die Software muss gemäß ihrer Spezifikation fehlerfrei sein. Darum geht es bei der funktionalen Sicherheit und der internationalen Norm ISO 26262.
Es geht jedoch nicht darum, ob die Spezifikation selbst – für diese Software im Fahrzeug – ausreichend sicher ist. Dies ist ein anderes Thema, die »safety of the intended functionality« oder SOTIF genannt wird. Ein Beispiel für eine solche unzureichende Spezifikation ist, wenn ein Fahrzeughersteller automatisiertes Fahren verkauft und dem Fahrer suggeriert, dass er während der Fahrt die Zeitung lesen kann, die Software aber gemäß der Spezifikation einen auf der Straße stehenden Anhänger nicht von einer freien Fahrbahn mit blauem Himmel unterscheiden kann. Dann kann die Software in Bezug auf die funktionale Sicherheit korrekt sein, aber nicht in Bezug auf ihre eigentliche Funktion.
Wann immer es also um die Entwicklung sicherheitsrelevanter Software geht, muss Teil 6 der ISO 26262 angewendet werden.
In diesem Paper möchte ich für Sie 9 wichtige Lektionen herausarbeiten. Und ich werde Ihnen erklären, wo Sie Ihre Softwareentwicklung für den Automobilsektor anpassen müssen, wenn Sie bisher Software für andere (mutmaßlich nicht sicherheitsrelevante) Anwendungen geschrieben haben.
Bild
Struktur der ISO 26262:2018
Zunächst einmal müssen wir feststellen, dass die Verkehrssicherheit nicht nur von der Einhaltung der Verkehrsvorschriften abhängt, sondern dass die Fahrzeuge selbst eine Gefahr für Menschenleben darstellen, wenn sie sich falsch verhalten. Zum Beispiel, wenn ein Auto plötzlich beschleunigt, ohne dass jemand das Gaspedal betätigt. Je moderner die Fahrzeuge werden und je mehr Fortschritte in Richtung automatisiertes Fahren gemacht werden, desto mehr bestimmt Software das Verhalten der Fahrzeuge. Die Sicherheit von Fahrzeugen, seien es Autos, Lastwagen oder Motorräder, hängt zunehmend von fehlerfreier Software ab.
Mit zunehmendem Anteil von Software in den Fahrzeugen und mit weiteren Schritten in Richtung automatisiertes Fahren hängt die Sicherheit der Fahrzeuge immer mehr von fehlerfreier Software ab.
Diese Schlussfolgerung begründet, dass sich die Softwareentwicklung für den automobilen Einsatz von der Softwareentwicklung für andere Anwendungen unterscheiden muss. Es ist einfach inakzeptabel, wenn eine Software nicht auf die Bremsanforderung eines Fahrers reagiert, nur weil sie gerade damit beschäftigt ist den Speicher zu bereinigen.
Aber welche Strategie führt zu fehlerfreier Software?
Lassen Sie mich zunächst erklären, dass Software im Gegensatz zu elektronischen (Hardware-)Komponenten oder Speicherbausteinen keine zufälligen Fehler haben kann. Wenn Software nicht das tut, was sie tun soll, ist es per Definition ein systematischer Fehler.
Beispiele für systematische Softwarefehler
- Nicht alle vorgeschriebenen Tests wurden erfolgreich durchgeführt und dennoch wurde die Software freigegeben.
- Die Zeit, die ein Algorithmus zur Erkennung einer gefährlichen Verkehrssituation benötigt, wurde falsch berechnet, sodass es zu einer Kollision kommt.
- Die Zustandsübergänge eines Steuergeräts sind unvollständig spezifiziert, sodass es bei der Programmierung der Software dem Zufall überlassen bleibt, was sie tut.
Um all dies zu verhindern, muss die Softwareentwicklung nach einem modernen, ausgeklügelten und robusten Prozess erfolgen.
Softwarefehler müssen durch systematische Entwicklung vermieden werden.
Vorbeugen ist gut, aber Vorbeugen ist keine Garantie dafür, dass keine Situation eintritt, an die nicht gedacht wurde.
Dem Auftreten von Fehlern muss durch Mechanismen zur Fehlertoleranz begegnet werden.
Mechanismen zur Fehlertoleranz
- Prüfsummen für Nachrichten oder Speicherbereiche,
- Prüfungen auf zulässige Wertebereiche beim Aufruf einer Softwarefunktion,
- Software, die auf so genannten Sicherheits-Mikrocontrollern läuft und dazu dient, zu überwachen, ob die eigentliche Anwendungssoftware auf einem anderen Mikrocontroller noch korrekt funktioniert.
Eine solche Software muss dann beim Erkennen von Fehlern das gesamte System und das Fahrzeug in einen vorher definierten sicheren Zustand bringen.
All diese Prinzipien liegen der Softwareentwicklung für Automobilanwendungen zugrunde, wie sie in Teil 6 beschrieben ist. Wir tauchen nun tiefer in diesen Teil 6 ein.
Benötigen Sie Unterstützung für Ihr Projekt? Wir sind Ihre Ansprechpartner rund um Managementberatung und Verbesserungsprogramme in der Elektronikentwicklung.
Steffen Herrmann und das Sales-Team
Innerhalb des gesamten Sicherheitslebenszyklus, den wir bereits aus den vorangegangenen Whitepapern und Videos kennen, ist die Softwareentwicklung parallel zur Hardwareentwicklung als eigene Disziplin innerhalb der Systemebene integriert. Für die Softwareentwicklung ist ein Referenzphasenmodell in ISO 26262 definiert. Sie finden dieses auch in unserem Whitepaper. Es handelt sich um ein V-Modell, das fast identisch mit dem in Automotive SPICE® definierten ist. Wir legen im Folgenden den Schwerpunkt auf Anpassungen speziell für die funktionale Sicherheit im Automobilbereich.
In Bezug auf die funktionale Sicherheit basiert die Softwareentwicklung auf dem technischen Sicherheitskonzept mit seinen technischen Sicherheitsanforderungen an die Software, das in der linken oberen Ecke dargestellt ist (»Technical safety concept«). Die fertig entwickelte Software fließt dann weiter an die Integration und die Tests auf Systemebene ein, in der Sprache des Standards »System and item integration and testing«. Wir konzentrieren uns hier auf die eigentliche Softwareentwicklung.
Funktionale Sicherheit erfordert, dass der Softwareentwicklungsprozess an die Anforderungen der ISO 26262 angepasst wird.
Es ist eine Voraussetzung, dass Sie Softwareentwicklung nach einem geeigneten, dokumentierten Prozess durchführen, der akzeptiert ist und der auch tatsächlich angewendet wird. Dieser Prozess muss mit der ISO 26262 konform sein. Sie müssen über eine geeignete Softwareentwicklungsumgebung verfügen, was sich aber nicht grundlegend von nicht-automobilen Anwendungen unterscheidet.
Sie müssen Kodierungs- und Modellierungsrichtlinien/-regeln einhalten, für die die ISO 26262 eine Reihe spezifischer Kriterien aufführt. Dies wird in der Branche üblicherweise durch MISRA-Regeln abgedeckt.
Eine aktuell häufig gestellte Frage ist, ob agile Softwareentwicklung und funktionale Sicherheit kompatibel sind. Ja, das sind sie, aber nur, wenn eine Reihe von Dingen berücksichtigt wird. Die ISO 26262 verlangt von Ihnen, dass Sie bestimmte Dokumentationen erstellen, insbesondere im Zusammenhang mit dem Sicherheitsnachweis (Safety case). Das hindert Sie aber nicht daran, tägliche Stand-up-Meetings und eine Continuous Integration (CI) durchzuführen, was beides sehr nützlich ist.
Sobald Sie Software freigeben wollen, die tatsächlich in Fahrzeuge eingebaut werden soll, die auf der Straße fahren, müssen Sie strenge Prozesse einhalten. Sie können dann nicht mehr schnell einen Kundenwunsch umsetzen und bis zuletzt Software liefern.
Korrektes Softwareverhalten hängt nicht nur vom Software-Code selbst ab, sondern auch von den Daten, die ihn steuern. Diese Tatsache erfordert, dass Sie Konfigurations- und Kalibrierungsdaten dem gleichen Entwicklungsprozess unterwerfen wie die Softwareentwicklung selbst.
Schließlich ist es bei den diversen verschiedenen (Kommunikations-) Schnittstellen, die es heute innerhalb von Fahrzeugen und nach Außen gibt, notwendig, dass Gefahren bezüglich der Cybersecurity analysiert und nach entsprechenden Standards angegangen werden.
All dies sind Themen, die Sie bei Ihrer Entwicklung berücksichtigen müssen.
Wir sind stolz, dass wir seit 2008 zu den Pionieren der Funktionalen Sicherheit zählen und unsere Erfahrung bei der Entwicklung der Sicherheitsnorm ISO 26262 einbringen konnten.
Automobilelektronik funktional sicher?
Wir sind die Experten!
Wir verfügen über die geballte Erfahrung aus über 700 Projekten zur Funktionalen Sicherheit nach ISO 26262 bei weltweit über 100 Kunden.
Automobilelektronik funktional sicher?
Wir sind die Experten!
Wir haben über 100 Spezialisten im Rahmen des Zertifizierungsprogramms »TÜV Rheinland Functional Safety (Automotive)« ausgebildet.
Automobilelektronik funktional sicher?
Wir sind die Experten!
Die Erfahrung unserer Expertinnen und Experten im Bereich Funktionale Sicherheit beträgt zusammen über stolze 250 Jahre.
Automobilelektronik funktional sicher?
Wir sind die Experten!
Wir haben den Fachbuch-Klassiker »Funktionale Sicherheit in der Praxis« und das »Essentials Funktionale Sicherheit« verfasst.
Automobilelektronik funktional sicher?
Wir sind die Experten!
Bei uns engagieren sich bereits 18 Experten, die nach dem TÜV Rheinland Functional Safety (Automotive) zertifiziert oder selbst als Trainer zugelassen sind.
Automobilelektronik funktional sicher?
Wir sind die Experten!
Wir bringen unsere Expertise in Branchenverbände ein, beispielsweise in die Gremien des Zentralverbands der Elektroindustrie.
Automobilelektronik funktional sicher?
Wir sind die Experten!
Technische Sicherheitsanforderungen an die Software müssen zu qualitativ hochwertigen Software-Sicherheitsanforderungen verfeinert werden, damit sie in der Software umgesetzt werden können.
Dies umfasst Selbsttest- und Überwachungsfunktionen für Betriebssystem, Basissoftware und Anwendungssoftware.
Es handelt sich um Anforderungen für die Erkennung, Meldung und Beherrschung von Fehlern sicherheitsrelevanter Hardware.
Es müssen Anforderungen geschrieben werden, wann und wie im Falle eines Fehlers ein sicherer Zustand erreicht und aufrechterhalten werden kann, oder es muss definiert werden, wie zumindest ein degradierter Zustand erreicht werden kann.
Antworten auf folgende Fragen müssen spezifiziert werden
- Was sind die Anforderungen an die Fehlertoleranz?
- Wie oft müssen Testalgorithmen laufen und wie schnell müssen Fehlerreaktionen zur Laufzeit implementiert werden?
Die Softwareentwicklung muss auch zur Spezifikation der Schnittstelle zur Hardware beitragen (Verfeinern des »Hardware-Software-Interface«).
Die Softwarearchitektur muss alle funktionalen Anforderungen sowie Sicherheitsmechanismen implementieren.
Worauf dies hindeutet ist, dass die eigentliche (benutzer-erlebbare) Funktionalität sowie die Softwaresicherheitsanforderungen abgebildet werden müssen. Bei elektronischen Steuergeräten sind die eigentliche Funktionalität und die dazugehörigen Sicherheitsmechanismen kombiniert und oft nicht voneinander zu trennen.
Die Anforderungen der ISO 26262 überschneiden sich für diese Phase weitgehend mit Automotive SPICE, weshalb ich nur einen Aspekt aus der Sicht der funktionalen Sicherheit hinzufügen möchte.
Sie müssen so genannte Sicherheitsanalysen durchführen, bei denen Sie Abhängigkeiten zwischen Fehlern verstehen. Wenn Sie Teile der Software mit unterschiedlichen ASILs implementieren wollen, müssen Sie gute Argumente dafür haben, warum Software, die mit schwächeren Kriterien entwickelt wurde (also fehleranfälliger ist), kritischere Software (die mit mehr Aufwand entwickelt wurde) nicht negativ beeinflussen kann. Dies nennt man »freedom from interference«.
Die Analysen müssen das Laufzeitverhalten, die Speicherbereiche und den Nachrichten-/Informationsaustausch berücksichtigen.
Letztlich geht es bei allen Analysen um die Absicherung des Softwareentwurfs.
Sicherheitsanalysen müssen durchgeführt werden, um die Abhängigkeiten zwischen Softwarekomponenten zu verstehen und den Softwareentwurf zu validieren.
Auch die nächste Phase ist sehr ähnlich beschrieben, wie bei den meisten anderen Software-Entwicklungsprozess-Modellen, zum Beispiel nach Automotive SPICE. Es wird ein detaillierter Entwurf der kleinsten Software-Einheit (Software Unit Design) benötigt, welcher auch modellbasiert entstehen kann. Die ISO 26262 enthält außerdem Kriterien für die Richtlinien und Regeln, die hierbei einzuhalten sind »modelling guidelines«/»coding guidelines«).
Aus der Perspektive der funktionalen Sicherheit gibt es diesmal keine wichtige Lektion festzuhalten.
Wir verlassen nun die linke Seite des V-Modells und schauen uns die rechte Seite für Integration und Test an.
Unter dem Gesichtspunkt der funktionalen Sicherheit sehe ich hier zwei Punkte, die ich als wesentliche Unterschiede für die Softwareentwicklung im Automobilbereich hervorheben möchte.
Softwareintegration und -tests müssen nach einer bestimmten Methodik spezifiziert und erfolgreich durchgeführt werden.
Die Testabdeckung muss gemessen werden, um die Vollständigkeit von Tests zu analysieren und die Argumentation für das Erreichen der Testziele zu untermauern.
Dies fasst in Bezug auf funktional sichere Software zwei Aussagen zusammen, die über die übliche Softwareentwicklung hinausgehen.
Auf der Ebene der einzelnen Software Units (kleinsten Softwareeinheiten) umfasst die Verifikation
- den Nachweis der Umsetzung der Sicherheitsmechanismen,
- den Nachweis, dass es keine unbeabsichtigte Funktionalität im Code gibt,
- und dass ausreichende Ressourcen – d.h. Ausführungszeit, Speicher und Bandbreite für Nachrichten – zur Verfügung stehen.
ISO 26262 verlangt, dass Testfälle mit einer Reihe von Methoden entwickelt und bestimmte Arten von Tests durchgeführt werden. Je nach ASIL gibt es unterschiedliche Erwartungen in Bezug auf das, was zu tun ist.
Ein für die funktionale Sicherheit spezifischer Aspekt ist, dass die Codeabdeckung gemessen werden muss, um die Aussage zu untermauern, dass Tests intensiv genug durchgeführt wurden
Die nächste Phase behandelt alle weiteren Integrations- und Teststufen bis hin zur vollständig integrierten Software. Die Fragen sind die gleichen wie auf Modulebene, den Software Units: Sind die Sicherheitsmechanismen implementiert worden? Gibt es keine unbeabsichtigte Software? Sind genügend Ressourcen vorhanden? Auch hier ist ein methodisches Vorgehen zur Testfalldefinition und -durchführung notwendig. Die Testabdeckung muss gemessen werden.
Anders als bei Automotive SPICE gibt es für die funktionale Sicherheit eine eigene Klausel, die sich darauf bezieht, dass für die entwickelte Software der Nachweis erbracht werden muss, dass sie die an sie gestellten Anforderungen auf der Zielhardware und in der Zielumgebung erfüllt.
Sie sollte dazu in verschiedenen Umgebungen getestet werden. Zunächst sollte die Hardware mit der Software in einer simulierten Umgebung getestet werden. Dies wird als »Hardware-in-the-Loop« bezeichnet. Dann sollte sie in einem Netzwerk von realen elektronischen Steuergeräten getestet werden. Und schließlich sollte alles in Prototyp-Fahrzeugen getestet werden.
Auch hier müssen die Testfälle mit Methoden spezifiziert werden. Einige typische Beispiele für solche Methoden sind Use-Case-basiertes Testen, Äquivalenzklassengenerierung und Grenzwertanalyse.
Und schließlich müssen natürlich auch die Softwareanforderungen abgetestet werden.
Außerdem sollte »Error-Injection-Testing« durchgeführt werden, um die Sicherheitsmechanismen zu testen, z.B. durch absichtliches Verfälschen von Sensordaten. Dies soll beweisen, dass die Algorithmen Fehler auch wirklich erkennen und die gewünschte Reaktion auslösen.
Wir haben uns in diesem Paper mit den spezifischen Erwartungen an die Softwareentwicklung im Automobilbereich und im Rahmen der funktionalen Sicherheit befasst.
Ich möchte die neun wichtigsten Lektionen zusammenfassen, die hervorzuheben und im Auge zu behalten sind.
Bitte beachten Sie diese wichtigen Lektionen.
- Mit dem zunehmenden Anteil von Software in Fahrzeugen und mit weiteren Schritten in Richtung automatisiertes Fahren hängt die Sicherheit von Fahrzeugen immer mehr von fehlerfreier Software ab.
- Fehler in der Software müssen auch durch systematische Entwicklung vermieden werden.
- Dem möglichen Auftreten von Fehlern muss durch Mechanismen zur Fehlertoleranz begegnet werden.
- Funktionale Sicherheit erfordert eine Anpassung des Softwareentwicklungsprozesses an die Inhalte und Anforderungen der ISO 26262.
- Die technischen Sicherheitsanforderungen aus der Systemebene müssen zu Softwaresicherheitsanforderungen verfeinert werden, bevor sie umgesetzt werden können.
- Die Softwarearchitektur muss alle funktionalen Anforderungen und Sicherheitsmechanismen implementieren. Beides lässt sich in der Fahrzeugelektronik oft nicht trennen.
- Es müssen Sicherheitsanalysen durchgeführt werden, um die Abhängigkeiten zwischen den Softwarekomponenten zu verstehen und den Softwareentwurf zu validieren.
- Die Testabdeckung muss gemessen werden. Dies dient dazu, die Vollständigkeit der Tests zu bewerten und unterstützt die Argumentation, dass die Testziele erreicht wurden.
Wir unterstützen Sie dabei,
- Ihre Prozesse nach den aktuellsten Normen der Sicherheit zu verbessern, um technisch zuverlässige, verfügbare, instandhaltbare und funktionale Produkte entwickeln und vermarkten zu können.
- Sicherheitsmanagementsysteme konzipieren und umsetzen zu können.
- durch Safety Audits zu bestätigen, dass Ihr Safety Management seinen Anforderungen gerecht wird.
- zuverlässig beurteilen zu können, ob ein Lieferant entsprechende Komponenten tatsächlich beisteuern kann.
- die Funktionale Sicherheit elektronischer Systeme und Komponenten bewerten zu können.
- Ihre Mitarbeiterinnen und Mitarbeiter bei allen Fragen der Funktionalen Sicherheit zu schulen.
