System-Software für Assistenzsysteme Die fünf wichtigsten Regeln

Große Herausforderungen für die Entwickler bei ADAS-Systemen
Die nächste Generation von ADAS-Systemen stellt Entwickler vor große Herausforderungen.

Dieser Beitrag beschreibt die fünf wichtigsten Überlegungen zur System-Software für OEMs, Tier-1-Anbieter und deren Zulieferer, die erfolgreiche ADAS-Software-Umgebungen, -Infrastrukturen und -Produkte vermarkten wollen.

Die fünf wichtigsten Regeln für die Software-Entwicklung bei Fahrerassistenzsystemen:

1. Update-Funktionen einplanen

Die Software von herkömmlichen Assistenzsystemen besitzt in der Regel noch einen überschaubaren Umfang und wird von Teams entwickelt, die Erfahrung mit sicherheitskritischen Entwicklungsprozessen haben. Kommende ADAS-Systeme, die etwa eine 3D-Grafikverarbeitung benötigen, werden deutlich mehr Code erfordern. Zudem können sie auf die Software von Drittanbietern angewiesen sein, die von Programmierern erstellt wird, die keine Erfahrung in der sicheren Software-Entwicklung aufweisen. Entwickler müssen bei diesen zunehmend komplexeren Systemen daher von vorne­herein damit rechnen, dass schwerwiegende Probleme auftauchen können. Deshalb sollten sie unbedingt ein zuverlässiges System zum Einspielen von nachträglichen Software Patches und Upgrades integrieren.

Es gibt zwar schon offene Standards für Software Upgrades (vornehmlich Open Mobile Alliance DM/FUMO). Diese unterstützen aber nicht die schwierigen Aspekte praktischer Software Upgrades, wie z.B. die Versionsverwaltung, die geplante Auslieferung an eine große Zahl entfernter Systeme und die Optimierung der Patch-Größe für eingeschränkte Funknetze. Die Automobilindustrie muss daher neue Wege gehen und die Technik einen Schritt weiter führen, um ein hohes Maß an Vertrauen in die Sicherheit der Upgrade-Infrastruktur und Patches zu erlangen.

Sichere Upgrades im Feld erfordern eine Verschlüsselungsinfrastruktur, die in den SoC und seine Software integriert ist. Vor allem die Software wird über digitale Signaturen auf ihre Integrität und Authentizität überprüft. Die entsprechenden Verifikationsschlüssel müssen dafür gegen Manipulation geschützt werden. Ein solcher Schlüssel muss sich in einem manipulationssicheren On-Chip-Speicher befinden oder über einen Hardware-basierten Schlüssel geschützt werden. Die zur Validierung verwendete Software muss selbst auch gegen Manipulation geschützt werden. Dazu dient eine Kombination aus sicherem Booten und dynamischer Integritätsüberprüfung (Remote Attestation). Integrierter sicherer Speicher und eine verlässliche, unveränderliche Firmware sind die Vertrauensbasis für praktisch jede wichtige Sicherheitsfunktion in einem System

2. ISO-26262-Vorgaben beachten

Der Standard ISO 26262 wurde erstmals im Jahr 2011 veröffentlicht und dient als Orientierungshilfe in der Automobil­industrie. Vordenker im Automobil­bereich, darunter OEMs, Tier-1- und Tier-2-Zulieferer, sehen ISO 26262 als interne Vorgabe an, um die hohen Anforderungen von ADAS und anderen Systemen zu erfüllen. Erfahrung mit ISO 26262 sowie die Fähigkeit, den höchsten Sicherheitsgrad (ASIL D) zu erreichen und Zulieferer auszuwählen, die den gleichen Anforderungen entsprechen (z.B. über unabhängige Prüfer wie der TÜV), sorgen eindeutig für einen Wettbewerbsvorteil.

ISO 26262 befasst sich mit dem Einsatz von Software-Entwicklungs-Tools für sicherheitskritische Software und fordert eine Tool-Qualifikation durch eine Kombination aus zuverlässiger Anwendung (Vertrauen durch Nutzung), Evaluierung des Entwicklungsprozesses beim Tool-Hersteller und Überprüfung der Tool-Funktion. Tools, die nach dem höchsten Tool-Qualifizierungsgrad T3 eingestuft sind, liefern Ergebnisse, die für einen Einsatz in sicherheitsrelevanten Systemen geeignet sind. Einige Compiler-Anbieter behaupten, dass ein zertifizierbarer Compiler vom Hersteller selbst qualifiziert werden kann. Derzeit sind aber nur die Green-Hills- und ARM-C-Compiler unabhängig durch den TÜV nach ISO 26262 ASIL D zertifiziert.