Softwarekomponenten-Schutz in einem ISO-26262-System

Systemdesign Softwarekomponenten-Schutz in einem ISO-26262-System

15.05.2015 Yi Zheng, Chris Hobbs *

Anbieter zum Thema

Die Automobil-Entwicklungsnorm ISO 26262 sieht die Isolation der Softwarekomponenten gegen gegenseitige Beeinflussung als wichtigste Aufgabe an. Der Artikel zeigt Ansätze zum Komponentenschutz auf.

Digitaler Instrumentencluster im Automobil: Die Automobil-Norm ISO 26262 fordert als wichtigste Aufgabe die Isolation der einzelnen Softwarekomponenten gegen die gegenseitige Beeinflussung.
(Bild: QNX)

Im Bereich der Automechanik blicken die Hersteller auf ein ganzes Jahrhundert an Erfahrungen zurück, so dass in diesem Bereich nur noch eine ständige Verbesserung und Revision von Details erforderlich ist. Bei der Bordelektronik, die Dutzende elektronischer Steuergeräte (ECUs) und eine Head-Unit umfasst, auf welcher komplexe Infotainment-Software ausgeführt wird, stehen die Dinge ganz anders. Diese Systeme entwickeln sich nicht nur sehr schnell weiter, auch die Nachfrage der Endkunden nach neuen Anwendungen und Diensten setzt die Autohersteller unter Druck.

Die Autohersteller müssen all diese Features liefern, ohne dass die Kosten durch die Decke gehen. Die Notwendigkeit einer Kostenoptimierung treibt die Hersteller dazu, die inzwischen verfügbaren hochleistungsfähigen und kostengünstigen Prozessoren zu nutzen und zahlreiche bordeigene Systeme auf einer gemeinsamen Platine zu konsolidieren. Wenn auch nur ein Modul mit einem Kostenpunkt von 50 $ je Fahrzeug eliminiert werden kann, ergibt dies bei 5 Millionen produzierten Fahrzeugen bereits eine beträchtliche Einsparung.

Fazit: Komponententrennung ist nicht trivial

Kein Ansatz kann allein eine Trennung zwischen Softwarekomponenten – wie in der ISO 26262 gefordert – verwirklichen. Zudem kann auch kein Ansatz für sich einen geeigneten Nachweis der Trennung liefern.

Kombination der Kräfte

Setzt man jedoch einander ergänzende Design- und Validierungstechniken gemeinsam ein, dann kann die Aussage, dass eine Trennung der Komponenten vorliegt, mit hinreichendem Konfidenzniveau getroffen werden. Einige dieser Ansätze benötigen Unterstützung durch das darunterliegende Betriebssystem; andere lassen sich auf der Applikationsebene implementieren.

Eine solche Konsolidierung birgt jedoch neue Herausforderungen. Insbesondere sind viele Fahrzeugsysteme sicherheitsrelevant, während es sich bei anderen um Consumer-Anwendungen handelt, für die es unmöglich ist, Sicherheit nachzuweisen – doch diese höchst unterschiedlichen Systeme müssen möglicherweise auf derselben CPU laufen.

Die Frage lautet also, wie sich ein System entwickeln und validieren lässt, das Komponenten enthält, die keine Sicherheitszertifizierung benötigen (etwa eine 3-D-Anzeige, auf der Consumer-Anwendungen laufen), aber auch Komponenten wie ein Totwinkelassistenz-Modul, deren Verlässlichkeit und Unabhängigkeit von externen unerwarteten Beeinflussungen methodisch streng entwickelt und bewiesen werden müssen.So ist es kein Zufall, dass die ISO 26262 Road Vehicles—Functional Safety (Straßenfahrzeuge – Funktionale Sicherheit) als wichtigste Aufgabe die Isolation der einzelnen Komponenten nennt.

Arten der Beeinflussung der Komponenten

Der Mikrokernel als Schutzsystem: Bei einem Betriebssystem mit Mikrokernel laufen alle Komponenten (auch Dateisystem, Gerätetreiber, Netzwerkstack usw.) in separaten Adressräumen und sind sowohl gegen den Kernel als auch gegeneinander isoliert.
(Grafik: QNX)

Die meisten nach ISO 26262 aufgebauten Systeme enthalten verschiedene Softwareelemente, die gemäß unterschiedlichen ASILs entwickelt wurden. Verhält sich eine dieser Komponenten nicht korrekt, könnte dies das Verhalten einer anderen Komponente beeinflussen und so die Sicherheitsanforderungen verletzen.

Es gibt verschiedenste Arten von Beeinflussung – je nachdem, ob die Komponenten aktiv zusammenarbeiten oder vollständig unabhängig voneinander sein sollen. Eine Komponente könnte etwa:

einer anderen Komponente Systemressourcen entziehen (Dateideskriptoren, Mutexe, Flash-Speicher);

einer anderen Komponente Rechenzeit wegnehmen, so dass sie ihre Aufgaben nicht mehr erfüllen kann;

auf den privaten Speicher einer anderen Komponente zugreifen;

Daten korrumpieren, die auch von einer anderen Komponente genutzt werden;

mit einer anderen Komponente, mit der sie interagiert, einen Deadlock oder einen Livelock erzeugen;

den Vertrag über die Zusammenarbeit mit einer anderen Komponente verletzen, indem sie etwa zu viele Nachrichten sendet, Nachrichten ständig wiederholt oder Nachrichten mit fehlerhaften Daten sendet.