Startseite > Automotive > Software + Tools > AUTOSAR goes Multicore – mit Sicherheit

Safety Automotive

AUTOSAR goes Multicore – mit Sicherheit

4. Juli 2014, 11:32 Uhr | Steffi Eckardt

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Überwachen der Laufzeit

AUTOSAR spezifiziert mit der Betriebssystemklasse SC2 eine Laufzeitüberwachung. Diese greift allerdings für sicherheitsrelevante Anwendungen zu kurz. Das AUTOSAR-Betriebssystem prüft zwar, dass keine Task übermäßige Laufzeit beansprucht oder Interrupts zu lange sperrt, aber die Konfiguration der korrekten und sicheren Task-Reihenfolge und des Task Triggering stellt für den Entwickler eine sehr hohe Komplexität dar, die schwer abzusichern ist. Von den Firmen TTTech und Vector Informatik gibt es eine alternative Lösung. Diese besteht aus einem nach ASIL-D entwickelten Program Flow Monitor, der die Ausführungszeiten und -reihenfolge der Tasks und der darin enthaltenen Funktionen überwacht.

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Für jeden Kern wird eine Instanz dieses Program Flow Monitor angelegt. Die Informationen über die Funktionsausführung erhält der Monitor durch die in der Software eingefügten Checkpoints (Bild 2). Nur wenn die sicherheitsrelevanten Programmteile korrekt abgearbeitet werden, werden diese Checkpoints in der richtigen Reihenfolge und mit dem richtigen Timing durchlaufen.

Der zentrale Watchdog Manager sammelt die Statusmeldungen aller Monitore und triggert den Watchdog. Es ist nicht möglich, jeden Kern separat zu verwalten, weil die Tasks oft über Kerngrenzen hinweg voneinander abhängen. Zum anderen erlaubt die AUTOSAR-Spezifikation nur einen gemeinsamen Neustart aller Kerne. Deshalb muss der Watchdog Manager als zentrales Modul für das gesamte Steuergerät entwickelt werden. Die Monitore selber laufen dagegen auf jedem Kern unabhängig ab und sind in der Lage, ihren Status über Kerngrenzen hinweg dem Watchdog Manager mitzuteilen.

Speicherschutz und sichere Kommunikation im Steuergerät

Eine perfekte Störungsfreiheit ist nur dann erreichbar, wenn die Hardware über eine Memory Protection Unit (MPU) verfügt. Sie sorgt dafür, dass die Anwendungsteile nur auf vordefinierte Speicherbereiche zugreifen können (Bild 3).

Diese Speicherbereiche sind für jeden Kern getrennt definiert, müssen sich aber die Hardware-Resourcen (RAM usw.) mit den anderen Kernen teilen. Das Betriebssystem hat hierbei eine zentrale Rolle: Bei jedem Task-Wechsel muss es die MPU umprogrammieren, damit ein Wechsel der Speicherpartition erfolgt. Dieser für den Kontextwechsel zuständige Teil des Betriebssystems ist eine sicherheitsrelevante Komponente und muss in jedem Fall der höchsten erforderlichen Sicherheitsstufe entsprechen.

Der Schutz vor fehlerhaftem Datenüberschreiben ist das eine. Das andere ist die Notwendigkeit eines korrekten Datenaustausches zwischen den Tasks und über verschiedene Prozessorkerne hinweg. Im AUTOSAR-Architekturmodell erfolgt ein solcher Datenaustausch zwischen zwei Tasks über den Virtual Function Bus (VFB). In der Implementierung wird der VFB durch das Runtime Environment (RTE) dargestellt.

Für ein sicherheitsrelevantes Steuergerät mit Multicore-Architektur werden folgende zusätzliche Anforderungen an die RTE gestellt: Sie muss die Kommunikation über Speicherpartitionen hinweg ermöglichen und dabei unterscheiden, ob ein Kommunikationsweg über Kerngrenzen hinweg (Inter-Core) oder zwischen zwei auf demselben Kern ablaufenden Tasks (Intra-Core) verläuft. Eine Datenübertragung über Kerngrenzen hinweg erfordert zusätzliche Koordinationsmechanismen. Das Betriebssystem stellt der RTE hierfür eine Inter-OS-Application Communicator (IOC) genannte Funktion bereit. Diese erlaubt den Datenaustausch zwischen Tasks und Interrupt-Service-Routinen auf verschiedenen Kernen.

Nutzung von Standardlösungen

Das Gewährleisten von funktionaler Sicherheit nach ISO 26262 auf Multicore-Steuergeräten scheint also keine ganz einfache Aufgabe zu sein. Das Rad muss allerdings nicht neu erfunden, sondern korrekt verwendet werden. Steuergeräteentwickler erhalten von Vector Informatik und TTTech Betriebssysteme, RTE und Program Flow Monitoring für Multicore-Architekturen bis ASIL D.

Generell sind Multicore-Systeme deutlich komplexer als Single-Core-Lösungen. Das muss jedoch nicht für die Konfiguration der Basis-Software gelten: Nach dem Verteilen der Software auf die Prozessorkerne ist der weitere Konfigurationsaufwand für ein Multicore-System bei optimaler Werkzeug-Unterstützung nicht schwerer als für eine Single-Core-Architektur. Der Entwickler fasst Tasks, Interrupt-Service-Routinen und ähnliches in Containern, den OS Applications, zusammen. Diese OS Applications weist er anschließend den Prozessorkernen zu. Im Konfigurationswerkzeug DaVinci Configurator Pro von Vector Informatik sind das nur wenige Klicks. Der integrierte RTE-Generator kümmert sich selbsttätig darum, die richtigen Kommunikationsmethoden, Intra- oder Inter-Core, zwischen den Software-Modulen einzurichten.

Es gibt also bereits viel Unterstützung für Multicore-Steuergeräte wie Basis-Software und Konfigurationswerkzeuge. Für die Erstellung der Software-Architektur und Verteilung der Software-Anteile auf die Prozessorkerne ist eine gute Werkzeugunterstützung weit schwieriger zu realisieren. Sie ist auch zumeist auf die Bewertung von Varianten beschränkt. Hier sind auf absehbare Zeit weiterhin das Experten-Know-how und die Erfahrung des Steuergeräteentwicklers gefragt.

Die Autoren

Dr.-Ing. Helmut Brock
ist seit 1999 bei Vector Informatik und dort als Produktmanager Betriebssysteme tätig.

helmut.brock@vector.com

Dipl.-Ing. (FH) Joachim Kalmbach
ist seit 2006 bei Vector Informatik und dort als Produktmanager im Bereich Embedded Software tätig. Seine Themenschwerpunkte sind AUTOSAR und Multicore.

joachim.kalmbach@vector.com