Die steigende Anzahl von Fahrerassistenzsystemen und die zunehmende Vernetzung elektronischer Komponenten im Fahrzeug führen dazu, dass immer mehr Steuergeräte im Auto eingesetzt werden. Die Autohersteller versuchen daher, mehr Funktionen in einer geringeren Zahl von Steuergeräten zu bündeln. So sollen Gewicht, Platzbedarf und Energieverbrauch optimiert werden.
Der Autor Robert Leibinger ist Produktmanager bei der Elektrobit Automotive GmbH, Erlangen
Die Autosar-Architektur dient dazu, die Komplexität zu reduzieren und die Wiederverwendung von Softwaregleichteilen über Herstellergrenzen hinaus zu erhöhen. In der Autosar-Welt werden spezifische Funktionen als Softwarekomponenten realisiert (SWC), die auf den Basissoftwarestack über eine Laufzeitumgebung (RTE) zugreifen. Solche Softwarekomponenten haben eine unterschiedlich hohe Sicherheitsrelevanz und sind daher mit unterschiedlichen ASIL-Leveln (Automotive Safety Integrity Level) bewertet. Werden Funktionen mit unterschiedlicher Sicherheitsrelevanz zusammengefasst, schreibt der Standard ISO/DIS 26262 vor, dass sich der jeweils höchste ASIL-Level an die anderen Komponenten weitervererbt.
Ein weit verbreiteter Ansatz, die Sicherheit zu erhöhen, ist die Isolation der Softwarekomponenten voneinander. So kann ein Fehlverhalten in einer Komponente die anderen nicht beeinflussen. Kernstück dieses Ansatzes ist die Garantie der Rückwirkungsfreiheit, die sogenannte „freedom from interference“, für die sicherheitsrelevanten Komponenten. Alternativ kann man Beeinflussungen aufspüren und entsprechende Gegenmaßnahmen einleiten, was sich in der Praxis aber als sehr schwierig erweist. Um diese Rückwirkungsfreiheit zu erreichen, brauchen die Komponenten einen Schutzmechanismus. Es scheint nur logisch, diesen in Autosar zu implementieren. Allerdings operieren im Autosar-Modell das Betriebssystem (OS), der Basissoftwarestack und die Laufzeitumgebung (RTE) mit den gleichen Privilegien. Das würde bedeuten, dass man alle Bestandteile nach den rigorosen Anforderungen der ISO 26262 entwickeln müsste. Angesichts der enormen Mengen an Softwarecode wäre das eine Herkulesaufgabe. Es muss also eine andere Lösung gefunden werden.
Die Autosar-Initiative hat daher in die Autosar Version 4.0 neue Funktionen integriert, die es ermöglichen, die Anforderungen der ISO 26262 zu erfüllen. Dazu zählen Memory Protection, End-to-End Communication Protection (E2E protection) und Time Protection.
Die E2E Protection sichert die Kommunikation
Die Unterteilung des Steuergerätespeichers in Partitionen (Memory Partitioning) unterstützt den gleichzeitigen Einsatz sicherheitskritischer und nicht-sicherheitskritischer Softwarekomponenten. Die getrennten Speicherbereiche tragen dazu bei, dass sich Fehler nur innerhalb definierter Grenzen fortpflanzen können. Die E2E Protection sichert die Kommunikation zwischen Steuergeräten, um zu zeigen, ob Signale korrekt übermittelt werden. Sie legt sowohl software- als auch hardwareseitige Fehler offen. Es ist nun beispielsweise möglich, Signale durch einen Nachrichtenzähler und eine Checksumme (CRC) zu sichern.
Elektrobit hat bereits zahlreiche Autosar-Projekte gemeinsam mit Automobilherstellern und Zulieferern umgesetzt. Daher weiß man, dass die Auswahl der eingesetzten Sicherheitskonzepte bei Steuergeräteprojekten in Autosar 4.0 viel Know-how und Erfahrung erfordert. Einerseits müssen alle Sicherheitslücken identifiziert und beseitigt werden. Andererseits muss die Lösung auch flexibel und mit vertretbarem Arbeitsaufwand umzusetzen sein. EB hat sich hier die bewährte Technik des Microkernels zu Nutze gemacht und eine Version des Autosar-Betriebssystems speziell für sicherheitsrelevante Systeme entwickelt. Anwendungs- und Betriebssystemcode sind darin konsequent getrennt, wodurch der Betriebssystemkern nicht durch fehlerhafte Anwendungen berührt wird.
Elektrobit, Tel.: 09131 7701-6709,
E-Mail: manuela.papadopol@elektrobit.com
Teilen:
