Sieht so die Zukunft aus?

SPECIAL: AUTOSAR
Fehlertolerante Systemarchitekturen mit AUTOSAR-Basis-Software realisieren:
(Bild: Jakub Krechowicz – Fotolia; Vector Informatik)
Sieht so die Zukunft aus?
Hochautomatisiertes Fahren bringt neue Anforderungen an bestehende
Sicherheitskonzepte. Eine Funktion einfach abzuschalten, um den
sicheren Zustand zu erreichen, ist nicht mehr ausreichend. Der sichere
Zustand erfordert Energie und aktive Funktionen.
Von Jonas Wolf
I
n sicherheitsrelevanten Systemen im
Fahrzeug ist heute das Ausschalten
oder Zurücksetzen einer fehlerhaften
Funktion die häufigste Fehlerreaktion.
Sie wird als fail-silent bezeichnet. Die
Maßnahme ist einfach umzusetzen und
wirksam, um einen sicheren Zustand
einzunehmen und zu erhalten. Zunehmend übernehmen aber E/E-Systeme
im Fahrzeug auch Funktionen, die im
Falle eines Fehlers verfügbar bleiben
müssen, beispielsweise beim Ausfall
eines Mikrocontrollers. Dieses Verhalten
wird fail-operational genannt und im
Weiteren als fehlertolerant
bezeichnet. Die Forderung
Mikrocontroller- Funktionsüberwachung
übergreifende
Integrität
(ASIL- und ApplikationsMaßnahmen
nach fehlertoleranten Syste(ASIL-abhängig)
abhängig)
(ASIL-abhängig)
men wird im Automobilbau
Watchdog
Watchdog
Watchdog
in Zukunft stark zunehmen.
(Alive Monitoring) (Logic Monitoring)
(Deadline Monitoring)
Ein Beispiel: Lenkunterstützungssysteme in schweren
Memory Partitioning/
Lock-step CPU
Sensor Monitoring
Coexistence (Mixed ASIL)
SUVs sind heutzutage teilweise notwendig, um die
ECC RAM
Actuator Monitoring
Communication
Beherrschbarkeit durch den
Protection (E2E)
ECC ROM
Limiter
Fahrer sicherzustellen. Wähprojektspezifische
rend die Entwickler Fail-SiBITs
Applikations-Software
Standard-Software
lent-Systeme in der ZwiBild 1. Durch ein modulares Konzept lassen sich Sicherheitsschenzeit mit ISO 26262 gut
mechanismen effizient für das jeweilige Projekt zuschneiden.
beherrschen, sind Fragestel
(Quelle: Vector Informatik)
lungen beim Auslegen von
32
Elektronik automotive 11.2015
fehlertoleranten Systemen durch die ISO
26262 aktuell schwierig zu beantworten.
Insbesondere die genaue Definition des
sicheren Zustands bereitet in diesem
Zusammenhang noch Kopfzerbrechen.
Auch die zweite Auflage von ISO 26262,
deren Veröffentlichung für 2018 geplant
ist, wird hier noch keine endgültige
Klarheit schaffen. Unabhängig von den
Vorgaben durch Standards zeigen die
folgenden Kapitel, wie sich die bestehenden Sicherheitskonzepte mit AUTOSAR auf fehlertolerante Systeme ausweiten lassen.
Modulares Sicherheitskonzept für
Fail-Silent-Systeme
Safety-Ingenieure schneiden durch ein
modulares Konzept die unterschiedlichen Sicherheitsmechanismen effizient
auf das jeweilige Projekt zu (Bild 1). Dabei unterscheiden sie grob zwischen
Maßnahmen zur Mikrocontroller-Integri­
tät, Maßnahmen zur Funktionsüberwachung und übergreifenden Maßnahmen.
Maßnahmen zum Herstellen der
Integrität des Mikrocontrollers werden
abhängig vom höchsten Automotive
Safety Integrity Level (ASIL) der verwendeten Software getroffen. Diese sind
unabhängig von der auszuführenden
SPECIAL: AUTOSAR
Priorität
Task Zykluszeit Budget
Die Timing Protection
A
5 ms
1 ms
erkennt Überschreitung
B
10 ms
3 ms des erlaubten Zeit-Budgets.
C
12 ms
5 ms
A
A
B
A
Verzögerte
Aktivierung von
Task C um 1 ms.
A
B
C
C
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Zeit
Bild 2. Die AUTOSAR Timing Protection erkennt frühzeitig ein Überschreiten
der erlaubten Zeit-Budgets von Tasks und Interrupts. (Quelle: Vector Informatik)
Funktion und ergeben sich aus dem zu erreichenden Diagnosedeckungsgrad (Diagnostic Coverage, DC) für ein bestimmtes
ASIL. Oft machen die Mikrocontroller-Hersteller konkrete
Vorgaben basierend auf ihren Sicherheitsanalysen. So können
beispielsweise eingebaute Selbsttests (Built-in Tests, BITs), die
zyklisch durch die Software angestoßen werden, für eine DC
für ASIL D notwendig sein. Bereits ab ASIL B muss in der Regel
die Auftretenswahrscheinlichkeit sogenannter Single Event
Upsets (SEUs) oder Bit-Kipper betrachtet werden. Wirksamen
Schutz gegen SEUs bieten Mikrocontroller im Lock-Step-Betrieb
und Speicher mit Fehlererkennungs- und korrektur-Codes (ECC
RAM, ECC ROM). Beide Sicherheitsmechanismen sind in der
Hardware enthalten, nahezu transparent für die SoftwareEntwicklung und daher effiziente Lösungen.
Zur Funktionsüberwachung setzt der Entwickler normalerweise weitere Maßnahmen in der Applikation um. Hierzu gehören Monitoring-Aufgaben für Sensorik und Aktuatorik genauso wie Limiter oder eine Programmablaufkontrolle (Logic
Monitoring). Die Programmablaufkontrolle wird beispielsweise mit einem AUTOSAR-Watchdog erreicht.
Funktionsüberwachung und Mikrocontroller-Integrität sind
projektspezifisch festzulegen und umzusetzen. Es gibt jedoch
auch Maßnahmen, die in fast jedem Steuergerät mit Sicherheitsbezug zum Einsatz kommen und unabhängig von Funktion und ASIL sind. Nahezu jedes Steuergerät mit ASIL-Software
führt auch QM-Software aus. Um die Koexistenz nach ISO 26262
zu gewährleisten, sind eine Speicherseparierung und eine
Überwachung der zeitlichen Randbedingungen notwendig [1].
Das Partitionieren des Speichers erfolgt durch das Zusammenspiel einer Memory Protection Unit (MPU) mit einem AUTOSARBetriebssystem mit Scalability Class 3 (SC3), das die Ansteuerung
der MPU mit dem geforderten ASIL übernimmt. Das Überwachen
der zeitlichen Anforderungen erledigt üblicherweise der Watchdog durch ein Deadline Monitoring. Sobald sicherheitsrelevante Daten zwischen mehreren Steuergeräten ausgetauscht
werden, kommt eine Kommunikationssicherung (Communication Protection) ins Spiel. Hierzu bietet AUTOSAR mit der Endto-End Protection (E2E) einen wirksamen Sicherheitsmechanismus. Für diese übergreifenden Maßnahmen sind bis ASIL D
zertifizierte Produkte von Vector Informatik verfügbar.
Transition zu fehlertoleranten Systemen
Hardware wird aktuell aus Kostengründen nahezu redundanzfrei ausgelegt. Ein Hardware-Fehler führt daher in der Regel
direkt zu einer schwerwiegenden Beeinträchtigung der Funk-
SPECIAL: AUTOSAR
In der Luftfahrt kommen fehlertolerante
Systemarchitekturen seit vielen Jahren
zum Einsatz. Für die sicherheitskritischen
Flugsteuerungssysteme sind oft dreioder vierfach redundante Steuergeräte
zu einem komplexen System vereint.
Diese Redundanz in der Hardware ist
selbstverständlich äußerst kostenintensiv. Für den Einsatz fehlertoleranter
Systeme in der Automobilindustrie müs34
Elektronik automotive 11.2015
Durch das Einführen von Redundanzen
in der Hardware steigt grundsätzlich
auch die Komplexität in der Applikation.
So entstehen
neue HerausforSWC
SWC
SWC
SWC
derungen im
MICROSAR.RTE
Bereich der ReKanalSensor- und
statusStellwertgelungstechnik,
Fehleraustausch
MICROSAR.COM austausch
IO
beispielsweise
zustandsaustausch
bei Reglerstabilität oder Aktuatorik durch Eingriff redundanter Regler. Auch
die Datenkonsistenz in NetzXCP
werken („byzanMICROSAR.MCAL
MICROSAR.EXT
tinischer Fehler“
[6]) muss neu
Mikrocontroller
bewertet werLegende:
mögliche Neuerungen in der Basis-Software Basis-Software Applikation
den. Aus Sicht
der SystemarBild 4. MICROSAR-Software-Architektur für auf AUTOSAR basierende fehlerchitektur lässt
tolerante Systeme.
(Quelle: Vector Informatik)
MICROSAR.LIBS
Fehlertolerante
Systemarchitekturen
Software-Architektur mit AUTOSAR
für fehlertolerante Systeme
Complex Drivers
tion bis hin zum Ausfall. Auf der anderen
Seite existieren ausgereifte Verfahren
zur Quantifizierung von HardwareAusfällen wie in IEC 62380 und SN 29500
definiert, die eine Vorhersage über die
gewünschte Versagensrate erlauben [2].
Das Quantifizieren von SoftwareFehlern fällt oft schwer, weil es sich
ausschließlich um systematische Fehler
handelt [3]. Um die Fehlertoleranz gegenüber Software-Fehlern zu erhöhen,
ist die Timing Protection als Sicherheitsmechanismus ein geeignetes Mittel. Die
Timing Protection schützt beispielsweise gegen Endlosschleifen in SoftwareKomponenten, die das Ausführen der
eigentlich relevanten Funktion verhindern. Bei der Timing Protection vergibt
der Entwickler zeitliche Budgets für die
Laufzeit von Tasks und Interrupt-Routinen und für die Sperrzeiten von Interrupts und Ressourcen. Ebenso werden
die zeitlichen Abstände zwischen Tasks
und Interrupt-Routinen überwacht
(Bild 2). Das AUTOSAR-Betriebssystem
stoppt im Fehlerfall die verursachende
Task oder Interrupt-Routine und schließt
sie von der weiteren Ausführung aus.
Die Timing Protection ist jedoch nur ein
erster Schritt hin zu fehlertoleranten
Systemen, wie sie in Zukunft gebraucht
werden.
MICROSAR.V2G
Bild 3. Beispiel für eine fehlertolerante Systemarchitektur
durch redundante Auslegung. (Quelle: Vector Informatik)
MICROSAR.AVB
2. Spannungsversorgung
MICROSAR.ETH
2. SBC/
Watchdog
MICROSAR.FR
2. CANKommunikation
2. Aktuator
MICROSAR.LIN
2. Mikrocontroller
MICROSAR.CAN
2. Sensor
MICROSAR.MEM
1. Aktuator
Datenaustausch
MICROSAR.DIAG
1. Mikrocontroller
sich diese Komplexität zum Beispiel
durch einen Hot-Standby‑Betrieb beschränken. Dabei steuert zu einem
Zeitpunkt immer nur einer der beiden
Kanäle die Aktuatorik. Kommt es in
diesem Kanal zu einem Fehler, übernimmt der andere Kanal sofort die
Steuerung. Zur vereinfachten Applikationsentwicklung ist die AUTOSAR-BasisSoftware (Bild 4) aus den folgenden
Gründen von Nutzen:
➜ ➜Wiederverwendung: Die für ein modulares Sicherheitskonzept bereits
oben vorgestellten AUTOSAR-Komponenten verwendet der Entwickler
weiterhin für die Fehlererkennung.
➜ ➜Einsatz von bestehenden Mechanismen: Für das Umsetzen der Software
der redundanten Kanäle gibt es zwei
Philosophien, diversitär oder homogen. Die diversitäre Philosophie verwendet unterschiedliche Software
auf beiden Kanälen. Bei gleichartigen
Kanälen und Mikrocontrollern lässt
sich auf beiden Kanälen dieselbe
Software nutzen, die nur je nach
Kanal anders parametriert ist. Dafür
eignet sich der sogenannte PostBuilt-Selectable-Mechanismus von
AUTOSAR, der normalerweise beim
Entwickeln von Steuergerätevarianten zum Einsatz kommt. Das Verwenden von gleichartigen Kanälen erfordert das Untersuchen von Fehlern
mit gemeinsamer Ursache [7].
Um eine schnelle Übernahme im Fehlerfall durch den anderen Kanal zu ermöglichen, werden Sensor- und Stellwerte ebenso wie Statusinformationen
zum Kanal zwischen den Kanälen ausgetauscht (Bild 3). Durch die Mechanis-
MICROSAR.AMD
1. Sensor
1. Spannungsversorgung
Kanalumschaltung
1. SBC/
Watchdog
MICROSAR.SYS
1. CANKommunikation
sen daher neue Ansätze gesucht werden.
Hierbei lässt sich in der Risikoabschätzung auch von der geringeren Schwere
des Schadensausmaßes profitieren.
Eine mögliche Systemarchitektur
(Bild 3) weist in jedem Fall mindestens
zwei Kanäle auf. Ein Kanal besteht in
diesem Beispiel aus einem Sensor, einer
Logikeinheit und einem Aktuator [4]. Es
lässt sich schnell erkennen, dass beim
Versagen des Mikrocontrollers eines
Kanals auch die zugehörige Software
und damit die Funktion ausfällt. Mi­kro­
controller haben aufgrund ihrer Komplexität häufig die höchsten Ausfallraten in einem Steuergerät; daher ist das
korrekte Ausführen einer Funktion
selbst für kleinste Zeiträume nicht sichergestellt.
Damit dieses zweikanalige System
fehlertolerant ist, muss jeder Kanal für
sich alle Einzelfehler entdecken und sich
passiv schalten [5]. Ohne diese Anforderung sind beide Kanäle für den sicheren Betrieb der Funktion notwendig.
Dadurch würde sich die Ausfallrate
verdoppeln und nicht wie gewünscht
halbieren. Diese Systemarchitektur erfordert eine redundante Energieversorgung der beiden Kanäle ebenso wie
einen redundanten Kommunikationspfad zu relevanten Partnern. IEC 61508
bezeichnet ein solches System als 1-outof-2 with Diagnostics (1oo2D).
MICROSAR.OS (SC3/4)
Steuergerät
SPECIAL: AUTOSAR
men von AUTOSAR ist das mit nur einer Konfiguration der
Basis-Software umsetzbar. Die Kanalumschaltung im HotStandby‑Betrieb kann der Entwickler applikationsspezifisch als
Software-Komponente (SWC) implementieren oder die flexiblen Konfigurationsmöglichkeiten der AUTOSAR-ManagerKomponenten Basic Software Mode Manager (BSWM) und ECU
State Manager (ECUM) ausreizen. Zum Austausch des Fehlerzustands zwischen den Kanälen wird heute applikationsspezifische Software implementiert. Es ist jedoch vorstellbar, dass
in Zukunft standardisierte Basis-Software-Komponenten für
genau diesen Zweck spezifiziert werden.
Werkzeugunterstützung
Um den weiteren Grad an Komplexität zukünftig zu beherrschen, bedarf es bereits ab einer frühen Entwicklungsphase
wirksamer und durchgehender Werkzeugunterstützung. Dadurch werden die Ressourcen auf die Applikationsentwicklung
konzentriert und Ingenieure von lästiger und fehleranfälliger
Arbeit entlastet, beispielsweise der manuellen Konsistenzprüfung von redundanten Signalen im Systemmodell.
Ausblick
Mit den AUTOSAR-Bordmitteln lassen sich bereits heute Projekte mit Sicherheitsbezug effizient umsetzen. Wenn zusätzliche Fehlertoleranz von E/E-Systemen gefordert wird, sind neue
Systemarchitekturen erforderlich, die auch den Ausfall des
Mikrocontrollers verkraften. Daraus ergeben sich für die Applikation und Basis-Software neue Herausforderungen. Mit der
AUTOSAR-Methodik ist jedoch für diese Art von Systemarchitekturen die Komplexität beherrschbar. Die AUTOSAR-BasisSoftware bietet hier durch die Konfigurierbarkeit eine hervorragende Ausgangslage. Die zugehörige Werkzeugkette erleichtert das Beherrschen der benötigten Redundanz.
Zukünftig wird sich die Unterstützung durch die BasisSoftware und deren Werkzeuge noch weiter verbessern. Ein
erster Schritt ist jedoch das Bewusstsein, dass fehlertolerante
Systeme auch neue Ansätze in der Systemarchitektur brauchen.
eck
Literatur
[1]Definition des Fault tolerant time interval (FTTI) in ISO 26262-1, 1.45
[2]ISO 26262-5:9 Evaluation of safety goal violations due to random
hardware failures
[3]ISO 26262-10:4.3 Relationship between faults, errors and failures
[4]Definition eines Systems in ISO 26262-1, 1.129
[5]ISO 26262 Single-point fault metric (SPFM) für ASIL D
[6]L. Lamport et al.: The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems, 1982
[7]Definition einer Common Cause Failure in ISO 26262-1, 1.14
Dipl.-Ing. Jonas Wolf
studierte Luft- und Raumfahrttechnik an der
Universität Stuttgart. Er ist seit 2012 bei Vector
und jetzt als Senior Product Management
Engineer für funktionale Sicherheit und Cyber
Security tätig.
[email protected]