AUTOSAR goes Multicore – mit Sicherheit

SAFETY AUTOMOTIVE
AUTOSAR goes Multicore –
mit Sicherheit
Zur Zeit dominieren zwei Themen die Software-Entwicklung für
­Fahrzeugsteuergeräte: zum einen das zunehmende Umstellen der
Rechnerarchitekturen auf Multicore-Prozessoren und zum anderen die
Sicherheitsbetrachtungen nach ISO 26262. Jedes dieser beiden
­Themen ist schon für sich alleine komplex genug – was ergibt­
sich da erst aus der Kombination?
Von Helmut Brock und Joachim Kalmbach
D
er Hauptgrund für die Einführung von Multicore-Architekturen ist das Erhöhen der Rechnerleistung, ohne die Taktfrequenz anheben zu müssen. Dieses Ziel wird aber
nur erreicht, wenn sich ein ausreichender Anteil der Anwendungs-Software
parallelisieren lässt. Die klassische Referenz hierzu ist Amdahls Gesetz. Hieraus ergibt sich zum Beispiel für einen
Dual-Core-Prozessor und eine Software
mit einer Parallelisierbarkeit von 50 Prozent eine maximale Leistungssteigerung
von nur 30 Prozent im Vergleich zu einer
Single-Core-Architektur. Um eine bestmögliche Rechenleistung zu erreichen,
56
funktionale sicherheit Juli 2014
muss der Entwickler beim Verteilen der
Software-Module darauf achten, die
gemeinsame Ressourcennutzung über
Kerngrenzen hinweg zu minimieren. Bei
den Ressourcen handelt es sich um
Hardware-Register und – in den meisten
Fällen – um Datenbereiche. Die Herausforderung bei der kernübergreifenden
Ressourcennutzung ist nicht die Zugriffskoordination, sondern das Vermeiden von Wartezuständen bei konkurrierendem Zugriff auf die gemeinsamen
Ressourcen. In so einem Fall geht die
unabhängige Datenverarbeitung verloren und der Nutzen der Parallelisierung vermindert sich.
Funktionale Sicherheit nach ISO
26262
Das Berücksichtigen der Anforderungen
an die funktionale Sicherheit nach ISO
26262 ist inzwischen fester Bestandteil
des Entwicklungsprozesses im Automobilbau. Auf Basis der Gefahren- und
Risiko­analyse werden die Anforderungen an die Funktionen eines Steuergeräts bezüglich ihrer Sicherheitsrelevanz
bewertet und der passende Automo­tive
Safety Integrity Level (ASIL) wird zugeordnet. Wie wirkt sich das auf eine
Multicore-Software-Architektur aus,
wenn sicherheitsrelevante Funktionen
umzusetzen sind? Vor der Beantwortung dieser Frage ein paar Hinweise zum
Lockstep-Konzept für Multicore-Prozessoren, das in vielen Safety-Projekten
zum Einsatz kommt.
Lockstep Mode
Beim Lockstep Mode führen zwei Kerne
identischen Code aus. Ein unabhängiger
Komparator vergleicht die Ergebnisse
und erzeugt bei Unterschieden einen
Fehler-Trap. Das weitere Vorgehen hängt
SAFETY AUTOMOTIVE
Überwachen der Laufzeit
von der Hardware und dem Sicherheitskonzept des Steuergeräts ab. Die Hardware muss so ausgelegt sein, dass sie
nach dem Auftreten des Fehler-Trap
einen sicheren Zustand erreicht. Weil
beide Kerne identischen Code ausführen, sind außer der Fehlerbehandlung
keine Erweiterungen der Software bezüglich Multicore notwendig. Anders
formuliert: Auch wenn hier mehrere
Kerne zum Einsatz kommen, handelt es
sich nicht um eine Multicore-Architektur,
die zur Leistungssteigerung beiträgt.
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. 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 zen­
tra­les 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,
Core 1
Runnable
Runnable
ISR
Task
Runnable
SWC
Runnable
Runnable
Runnable
Task
Task
Runnable
Runnable
Runnable
OS Application
SWC
ISR
Task
Runnable
Runnable
Task
OS Application
SWC
Task
Runnable
Runnable
Runnable
ISR
Task
Runnable
SWC
SWC
Task
Task
Runnable
SWC
Task
Die Multicore-Architektur lässt sich zur
Erhöhung der Rechnerleistung oder bei
sicherheitsrelevanten Systemen auch
zur parallelen Realisierung von diversitären Algorithmen wie ASIL-Dekompositionen verwenden. Der Entwickler
ordnet die Software-Module gemäß
Parallelisierbarkeit und abhängig vom
Sicherheitskonzept den in AUTOSAR
definierten OS Applications zu. Diese
lassen sich den in der ISO 26262 definierten Partitionen gleichsetzen. Dabei
handelt es sich um Bereiche innerhalb
eines Steuergerätes, die störungsfrei
voneinander ablaufen müssen – Freedom from Interference. In MulticoreSteuergeräten werden die OS Applications den unterschiedlichen Rechnerkernen zugewiesen (Bild 1). Für den
Entwickler spielt es keine Rolle, ob das
Ziel der Aufteilung die Parallelisierbarkeit oder die Dekomposition ist: Er muss
einen störungsfreien Ablauf zwischen
den OS Applications herstellen. Das
erfordert im Wesentlichen das Überwachen von Laufzeiten und Vermeiden
einer fehlerhaften Änderung von sicherheitsrelevanten Speicherinhalten.
Runnable
Multicore-Architektur mit verteilter
Software
OS Application
Core 2
Bild 1: Der Entwickler fasst die Tasks in OS Applications zusammen und verteilt sie auf die Kerne.
(alle Bilder: Vector Informatik)
Functional
Safety
Normen und Zertifizierung
– funktionale Sicherheit
wird immer wichtiger!
Unsere Tools und unser
Know-how sorgen für den
Überblick:
> Testdienstleistungen
> Consulting & Training
> Softwaretest-Tools
Wir sind Ihr Partner:
www.hitex.com/safety
SAFETY AUTOMOTIVE
Application 1
Application 2
SWC a
SWC b
Application 3
Application 4
SWC d
SWC e
SWC c
Check
point
Check
point
Check
point
LIBS
DIAG
Program
Flow
Monitor
V2G
CAN LIN
OS
Multi Core
FR ETH
AVB
XCP
EXT
MCAL
Core 1
Watchdog
Manager
Satellite
ECU State
Manager
Satellite
Core Test
Complex Driver
SYS
I/O
Complex Driver
ECU State
Manager
MEM
Watchdog
Manager
COM
AMD
Program
Flow
Monitor
LIBS
RTE
Core 2
Bild 2: Das Flow Monitoring stellt zusammen mit den Checkpoints in der Applikation die korrekte
­Ablaufreihenfolge sicher.
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
Core 1
MPU
RAM
Application A
- Task 1
Task 1
- Stack
- Application Data
Application B
- Task 2
Task 2
- Stack
- Application Data
Core 1
Application C
- Task 3
Task 3
- Stack
- Application Data
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 InterOS-Application Communicator (IOC)
genannte Funktion bereit. Diese erlaubt
den Datenaustausch zwischen Tasks
und Interrupt-Service-Routinen auf
verschiedenen Kernen.
Nutzung von Standardlösungen
Bild 3: Die Memory Protection Unit sorgt dafür,
dass die Anwendungsteile nur auf vordefinierte
Speicherbereiche zugreifen können.
58
funktionale sicherheit Juli 2014
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-CoreLö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 WerkzeugUnterstützung nicht schwerer als für
eine Single-Core-Architektur. Der Entwickler fasst Tasks, Interrupt-ServiceRoutinen 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 SoftwareArchitektur 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-Knowhow und die Erfahrung des Steuergeräteentwicklers gefragt.
eck
Dr.-Ing. Helmut Brock
ist seit 1999 bei Vector Informatik und dort als Produktmanager Betriebssysteme tätig.
[email protected]
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.
[email protected]