Von getestet zu bewährt
Zuverlässige Fahrzeugsoftware – die nächste Phase
Fahrzeugsoftware muss absolut zuverlässig sein. Herkömmliche Verifizierungsansätze, die auf Tests und inkrementeller Analyse beruhen, reichen jedoch nicht mehr aus. Insbesondere Verletzungen der Speichersicherheit bleiben ein anhaltendes Risiko im Fahrzeubereich.
Heutige Fahrzeuge basieren auf Millionen von Codezeilen, die über Embedded-Systeme verteilt sind, um Bremsen, Batteriemanagement, Datenanbindung und fortschrittliche Fahrerassistenzfunktionen (ADAS) zu steuern. Die Zuverlässigkeit dieser Software zu gewährleisten, hat dabei höchste Priorität. Herkömmliche Verifizierungsansätze, die auf Tests und inkrementeller Analyse basieren, haben Schwierigkeiten, mit moderner Fahrzeugsoftware Schritt zu halten. Tests zeigen zwar das korrekte Verhalten in bestimmten Fällen, können jedoch nicht das Ausbleiben von Fehlern nachweisen. Dies hat Folgen für die Sicherheit und Zuverlässigkeit, da latente Mängel wie Probleme mit der Speichersicherheit zur Laufzeit auftreten können.
Verstöße gegen die Speichersicherheit sind nach wie vor eine häufige Ursache für Softwarefehler in Embedded-Fahrzeugsystemen. Fehler wie Pufferüberläufe, Zugriffe außerhalb der Grenzen, Use-after-Free-Fehler, Null-Zeiger-Dereferenzierungen und Integer-Überläufe sind schwer zu erkennen und hängen oft stark von der Ausführungsreihenfolge, dem Timing und den Datenwerten ab.
Diese Probleme sind größtenteils auf die anhaltende Abhängigkeit von C und C++ in der Fahrzeugentwicklung zurückzuführen. C und C++ bieten zwar deterministische Leistung und eine Low-Level-Kontrolle über Hardware-Ressourcen, setzen Entwickler jedoch auch direkt der manuellen Speicherverwaltung aus. Da Systeme immer komplexer und zunehmend parallel werden, wird es sehr schwierig, eine korrekte Speichernutzung über alle Ausführungspfade hinweg sicherzustellen.
Selbst neuere Sprachen wie Rust lösen diese Probleme in Fahrzeugsystemen trotz stärkerer standardmäßiger Speichersicherheit nicht vollständig. Die Anbindung an Hardware-Register, Echtzeitbetriebssysteme, Legacy-C/C++-Code oder leistungskritische Routinen erfordert oft den Einsatz unsicherer Konstrukte. Sobald unsicherer Code eingeführt wird, können viele der üblichen Arten speicherbezogener Fehler wieder auftreten, insbesondere in großen, langjährigen Embedded-Codebasen.
In Embedded-Umgebungen arbeitet Rust auch ohne die Standardbibliothek und stützt sich auf die Kernbibliothek. Für Entwickler ergibt sich somit eine zusätzliche Verantwortung, da sie die Einschränkungen der Speichersicherheit verwalten und benutzerdefinierte Panikbehandlungsverhalten definieren müssen.
Grenzen traditioneller Tests und statischer Analysen
Tests sind für die Validierung von Fahrzeugsoftware von grundlegender Bedeutung, aber von Natur aus begrenzt: Unit-, Integrations- und Hardware-in-the-Loop-Tests decken nur begrenzte Szenarien ab und können den gesamten Zustandsraum, Interrupts, Task-Interleavings und Datenbereiche realer Embedded-Systeme nicht vollständig untersuchen.
Statische Analysetools versuchen, diese Grenzen zu überwinden, indem sie Code ohne Ausführung analysieren, aber viele traditionelle Ansätze stützen sich auf Heuristiken oder konservative Annäherungen an das Programmverhalten. Dies führt häufig zu einer hohen Zahl von Fehlalarmen, die manuelle Überprüfungen erfordern, die Entwicklung verlangsamen, die Verifizierungskosten erhöhen sowie zu Reibungen zwischen den Entwickler- und Sicherheitsteams führen.
Noch wichtiger ist, dass bei der traditionellen statischen Analyse immer noch Fehler übersehen werden können. Um handhabbar zu bleiben, stützen sich die Analysen auf Annäherungen, die Ausführungspfade ausschließen oder Laufzeitbedingungen vereinfachen, was zu Fehlalarmen führt, die in sicherheitskritischen Systemen besonders gefährlich sind.
Falsch-negative Ergebnisse: Verstecktes Risiko in ASIL-bewerteten Systemen
Für sicherheitsrelevante Fahrzeugsoftware, die der Norm ISO 26262 unterliegt, stellen falsch-negative Ergebnisse ein weitaus größeres Risiko dar als falsch-positive Ergebnisse. Ein einziger übersehener Speicherfehler kann zu undefiniertem Verhalten während der Laufzeit führen, wodurch Fehlererkennungsmechanismen untergraben oder Kettenreaktionen in miteinander verbundenen Subsystemen ausgelöst werden können.
Diese Probleme treten häufig erst spät im Entwicklungszyklus auf, während der Systemintegration oder -validierung, wenn mehrere Steuergeräte unter realen Zeitbeschränkungen interagieren. In dieser Phase ist es wesentlich schwieriger, die Ursachen zu identifizieren, und Korrekturen können architektonische Änderungen oder erneute Zertifizierungsmaßnahmen erfordern. In softwaredefinierten Fahrzeugen, in denen Code plattform- und modellübergreifend wiederverwendet und aktualisiert wird, können latente Fehler über mehrere Bereitstellungen hinweg bestehen bleiben, wenn sie nicht auf Architektur- oder Codeebene beseitigt werden.
Über die Erkennung hinaus zur mathematischen Sicherheit
Da die Grenzen von Tests und heuristischer Analyse immer deutlicher werden, richtet sich der Fokus zunehmend auf mathematisch strenge Verifizierungstechniken, insbesondere auf die formale Verifizierung. Im Gegensatz zu Tests, bei denen das Verhalten stichprobenartig untersucht wird, oder zur statischen Analyse, die eine Annäherung daran darstellt, werden bei der formalen Verifizierung mathematische Modelle verwendet, um alle möglichen Softwareverhalten zu analysieren.
Durch Techniken wie abstrakte Interpretation und formale Beweisführung kann Software innerhalb definierter Grenzen gründlich über alle möglichen Ausführungspfade und Eingabewerte hinweg analysiert werden. Dadurch lässt sich nachweisen, dass ganze Klassen von Fehlern, wie zum Beispiel Verstöße gegen die Speichersicherheit, nicht vorhanden sind, anstatt nur einzelne Vorkommnisse zu erkennen.
Dieser Unterschied ist von großer Bedeutung. Eine fundierte und umfassende Verifizierung eliminiert die meisten Fehlalarme und alle falschen Negativmeldungen. Entwickler sind nicht mehr gezwungen, große Mengen an Warnmeldungen zu sichten, und Sicherheitsteams können darauf vertrauen, dass kritische Fehlermodi während der Laufzeit nicht auftreten. Bei komplexen Embedded-Systemen mit Parallelität, Interrupts und engen Zeitvorgaben ist dieses Maß an Sicherheit mit anderen Mitteln nur schwer zu erreichen.
Aufwand reduzieren und Vertrauen stärken
Aus Sicht der technischen Produktivität verändert die mathematisch umfassende Verifizierung die Wirtschaftlichkeit der Software-Sicherheit. Durch die Eliminierung falscher Ergebnisse können sich Teams auf die tatsächlichen Probleme konzentrieren, die das Systemverhalten und die Sicherheit beeinträchtigen. Dies reduziert den Verifizierungsaufwand und erhöht die Sicherheit der endgültigen Software.
Für Unternehmen, die Komponenten von Drittanbietern integrieren oder große Legacy-Codebasen pflegen, bieten formale Garantien eine Möglichkeit, Vertrauen aufzubauen, ohne bestehende Software neu schreiben oder umfassend modifizieren zu müssen. Anstatt sich auf Testabdeckungsmetriken oder manuelle Codeinspektionen zu verlassen, können Teams Eigenschaften direkt korrigieren.
Auswirkungen auf die Sicherheitszertifizierung
Standards für die funktionale Sicherheit (ISO 26262) legen den Schwerpunkt auf systematische Fehlervermeidung, vorhersehbares Verhalten und die Kontrolle unbeabsichtigter Störungen. Die Validierung dieser Eigenschaften kann mit zunehmend komplexer Software und einer stärker zentralisierten Architektur zu einer Herausforderung werden.
Mathematisch nachgewiesene Garantien liefern objektive Beweise dafür, dass bestimmte Arten von Fehlern in der analysierten Software nicht auftreten können. Dies stärkt die Sicherheitsfälle, unterstützt die Zertifizierungsnachweise und verringert die Abhängigkeit von defensiven Codierungspraktiken und Laufzeitüberwachung als primäre Mittel zur Risikominderung. Das frühzeitige Erkennen und Beseitigen von Fehlern im Lebenszyklus reduziert auch kostspielige Nacharbeiten während der Integration und Validierung.
Verifizierungs-Workflows der nächsten Generation
Da in der Fahrzeugentwicklung kontinuierliche Integration, Software-Wiederverwendung und Over-the-Air-/OTA-Update-Modelle zum Einsatz kommen, müssen sich auch die Verifizierungs-Workflows parallel weiterentwickeln. Moderne Ansätze kombinieren zunehmend traditionelle Tests für funktionales Verhalten, statische Analysen für Compliance und Codierungsstandards sowie formale Verifizierung, um kritische Fehlerklassen an der Quelle zu beseitigen. Diese mehrschichtige Strategie spiegelt die wachsende Erkenntnis wider, dass Tests allein nicht das Maß an Sicherheit bieten können, das für moderne, softwaredefinierte Fahrzeuge erforderlich ist.
Die Autorin
Caroline Guillaume
ist CEO von TrustInSoft. Sie verfügt über umfangreiche Erfahrung im Bereich kritischer Software. Unter anderem war sie 14 Jahre lang bei Thales Digital Identity and Security im Vertrieb tätig, unter anderem als Vice President of Sales – Software Monetization Europe und Vice President of Banking and Telecom Solutions Sales. Zuvor war sie als Director of Product Marketing bei Gemplus tätig.
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Funktionale Sicherheit im KI-Zeitalter
Wie prüfen, was man gar nicht kennt?
AUTOSAR-Classic-Anwendungen
Erfolgreiche Integration von hybridem C/C++- und Rust-Code
Herausforderungen mit C++
Verifizierung sicherheitskritischer Fahrzeugsoftware
