Startseite > Automotive > Software + Tools > Neue Konzepte in AUTOSAR einbinden

Safety Automotive

Neue Konzepte in AUTOSAR einbinden

3. Juli 2014, 14:13 Uhr | Von Gary Morgan, Simon Burton und Jürgen Crepin

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Laufzeitüberwachung

Das Betriebssystem verfügt zudem über Einrichtungen zur Überwachung der Laufzeit der Software, so dass Zeitüberschreitungen entdeckt werden können und die Ausführung der fehlerhaften Abschnitte abgebrochen wird. Benötigt eine Software-Komponente bei der Ausführung zu viel Zeit, verzögert sich die Ausführung von anderen Software-Komponenten. Das kann dazu führen, dass sicherheitsrelevante Funktionen nicht rechtzeitig ausgeführt werden. Die Basis-Software (BSW) kann Ausführungsmuster einer Task oder eines Interrupt kontrollieren, um zu verhindern, dass zum Beispiel ein unerwartet hoher Netzwerkverkehr zu einer Verzögerung der Ausführung anderer Komponenten führt, weil das System permanent mit der Abarbeitung von Interrupts durch das Netzwerk blockiert ist.

AUTOSAR unterstützte stets das Konzept der gängigen Watchdogs zur Überwachung der Funktionen und Komponenten, erweiterte die Mechanismen jedoch um die Möglichkeit, auch den Programmfluss zu überwachen. Das heißt, die Software-Komponenten werden nicht nur daraufhin geprüft, ob sie mit der erwarteten Regelmäßigkeit ausgeführt werden, sondern auch, ob die korrekte Reihenfolge der Befehle eingehalten wird. Diese Methode kommt zum Einsatz, um vor Fehlern bei der Berechnung zu schützen sowie systematische Fehler in der Software zu entdecken. Wichtig ist es, die für die Ausführung des Watchdog-Codes erforderliche Zeit zu beachten, um sicherzustellen, dass sie nicht die zulässige Zeit für die Komponente überschreitet. Der Konflikt zwischen geringer Verzögerung und hoher Abdeckung einerseits sowie die Forderung nach geringem Implementierungs-Overhead erfordern viel Engineering-Geschick bei der Optimierung solcher Systeme.

Sonderfall Basis-Software

Ungeachtet ihrer Sicherheitsintegritätsebenen verwenden alle Software-Komponenten auf der Anwendungsebene die gleichen Basis-Software-Komponenten. Weil AUTOSAR den Funktionsumfang der Software, aber nicht die Integritätsebene vorgibt, sorgt die Einführung verschiedener Sicherheitsstufen für Differenzierung.

Die Anwendung der oben beschriebenen Partitionierungsmechanismen ist auf die Basis-Software-Ebene nicht so einfach zu übertragen. Beispielsweise bestehen viele Interaktionen zwischen den BSW-Modulen. Ein Service-Aufruf aus einer SWC oder ein Interrupt kann deswegen die Ausführung einer Reihe von BSW-Modulen auslösen. Wenn diese Module aus Sicherheitsgründen unterschiedlichen OS Applications zugeordnet sind, muss die MPU den Speicherzugriff jedes Mal behandeln. Dieser Overhead für das Umschalten der MPUs belastet die CPU überproportional. Wird jedoch ein Fehler in einer Komponente auf der Applikationsebene entdeckt, lässt sich diese neu starten, ohne dass andere Funktionen gestört werden. Wird dagegen ein Fehler in einer Komponente auf der Basis-Software-Ebene entdeckt, ist ein Neustart nicht so einfach zu implementieren, weil beinahe alle Steuergeräte-Funktionen von dieser Software abhängig sind. Das verstößt somit gegen die Richtlinien der Trennung.

Verschiedene Basis-Software-Lieferanten stellen Konzepte zur Verfügung, um diese Probleme zu lösen. Die Konzepte reichen vom Bereitstellen eines kompletten, nach den höchsten Sicherheitsintegritätsebenen entwickelten Basis-Software-Stack bis hin zu angepassten Überwachungsmechanismen mit Integrationshinweisen für den ECU-Verantwortlichen. Aktueller Konsens ist, dass das Betriebssystem, die RTE sowie kritische Teile der Mikrocontroller-Abstraction-Layer nach den höchsten Integritätsebenen erforderlich sind.

Abgesicherte Kommunikation

AUTOSAR hat in der Kommunikation zwischen den Steuergeräten Schwachstellen bei der Sicherheit entdeckt. Bei der Signalübertragung zwischen Software-Komponenten auf verschiedenen ECUs kann das Signal an vielen Stellen beschädigt werden, beispielsweise durch physikalische oder elektromagnetische Störungen oder durch Fehler in der Kommunikations-Software auf der Sender- oder Empfängerseite. Typische Fehlerbilder, die erkannt werden müssen, sind Datenverlust, Korruption, Verfälschung oder Wiederholung. Das End-to-End-Konzept (E2E) von AUTOSAR wurde entwickelt, um solche Fehler abzusichern. Die Integrität der Kommunikation wird auf der Applikations-Software-Ebene geprüft. Notwendige Maßnahmen wie Checksums oder Sequenzzähler werden eingeführt, um möglichst viele Fehlerquellen abzudecken.

Mit den technischen Fortschritten Schritt halten

Nicht nur bei der Software sind in den letzten Jahren Fortschritte gemacht worden. In der aktuellen Generation von Steuergeräten kommen Multicore-Prozessoren verstärkt zum Einsatz. Diese Prozessoren bieten Leistungsverbesserungen und die Möglichkeit, eine echte Nebenläufigkeit von Funktionen abzubilden. Darüber hinaus bieten sie auch Vorteile für die funktionale Sicherheit, weil Prozesse getrennt laufen können. AUTOSAR hat auch auf diese Entwicklung reagiert und entsprechende Multicore-Ansätze in der Spezifikation des Betriebssystems integriert. Wo die Spezifizierung durch AUTOSAR nicht ausreicht, haben Hersteller für Differenzierung gesorgt. Daher eignen sich manche Multicore-Prozessoren besser für hohe Sicherheits-Level (ASIL) als andere.

Ein üblicher Ansatz, um die Integrität eines Systems mit Multicore-Prozessoren zu verbessern, ist es, zwei Kerne im Lockstep-Modus zu betreiben. Hierbei läuft die gleiche Software synchron auf jeweils zwei Kernen. Unterschiede in der Berechnung werden durch eine Überwachungs-Hardware erkannt und somit Hardware-Fehler in einem Kern entdeckt. Dieses Vorgehen führt nur zu geringen Laufzeit-Overheads, stellt aber schnell transiente und permanente Fehler in den Kernen fest. Deshalb ist es naheliegend, Systeme mit höchstem ASIL entsprechend zu betreiben. Ein anderer Ansatz ist es, Software-Komponenten mit unterschiedlichen Sicherheitsintegritätsanforderungen auf den verschiedenen Cores zu verteilen. Zum Beispiel werden Komponenten wie Diagnose und Netzwerkkommunikation, die nicht für die Echtzeitberechnung notwendig sind, einem eigenen Kern zugeordnet. So sind mögliche Laufzeitstörungen der Hauptfunktionen durch die Netzwerkkommunikation oder langsame Flash-Zugriffe ausgeschlossen. Hier kommt wieder der oben erwähnte Ansatz der OS Applications von AUTOSAR zum Einsatz. Die Komponenten werden über OS Applications auf die Cores verteilt und die Kommunikation zwischen OS Applications auf den verschiedenen Cores durch zusätzliche Funktionen in der RTE unterstützt.