Entwicklung + Test llllISO 26262

Rezept fr
sichere Software
Entwicklung von SteuergerteBasis-Software nach
ISO/DIS 26262
Mit Einfhrung der neuen Norm ISO 26262
werden die Anforderungen an sicherheitsrelevante Funktionen deutlich anspruchsvoller als bisher, gleichzeitig aber auch
genauer eingegrenzt und klarer definiert.
Dabei mssen formell validierte Systeme
und die Wiederverwendung bestehender
Lsungen kein Widerspruch sein. Generische Sicherheitsmodule in Hardware und
Software knnen bewhrte Komponenten
ergnzen.
Von Dr. Thomas Wenzel, Martin Fassl und
Joachim Kalmbach

m Jahr 2011 tritt voraussichtlich

die derzeit in Abstimmung befindliche ISO 26262 als verbindliche
Sicherheitsnorm in Kraft. Sie definiert
funktionale Sicherheit fr elektrische
und elektronische Systeme in einer
anwendungsgerechten Art und Weise. Die zuknftige Norm ist an die
branchen-bergreifende IEC 61508
angelehnt und bercksichtigt beispielsweise auch, dass sicherheitsrelevante
und nicht sicherheitsrelevante Funktionen im Automobilbereich oft ineinandergreifen und sich daher nicht im-

ApplikationsSoftware
(ASIL D)
BasisSoftware
(ASIL D)

ASIL D

ASIL D + QM

ApplikationsSoftware
(ASIL D)
Sicherheitsschicht
(ASIL D)
Basis-Software
(QM)

Sicherheitsmechanismen
Re-Use der
BasisSoftware

ll Bild 1. ASIL-Dekomposition. Eine Durchfhrung ist auf System-,

Hardware- oder Software-Ebene mglich. Gem ISO 26262 ist
ein entsprechendes Confirmation Review ntig.

52

Elektronik automotive 11.2010

mer klar voneinander abgrenzen lassen.

Ziel der ISO 26262 ist es, eine bessere
Verstndlichkeit fr sicherheitsrelevante Funktionen zu schaffen und den
Interpretationsspielraum mglichst gering zu halten.
Die Herausforderung in der technischen Entwicklung liegt darin, alle
potentiellen Gefahren und Risiken im
verteilten System vorab richtig einzuschtzen und geeignete Manahmen
zur Risikominimierung umzusetzen.
Um dies zu ermglichen, schreibt die
ISO die Durchfhrung einer Gefahrenanalyse und Risikobewertung (Hazard Analysis and Risk Assessment) zu
Beginn der Entwicklung vor: Bei der
Analyse aller Betriebszustnde und der
entsprechenden Ausfallarten innerhalb
des zu betrachtenden Systems werden
verschiedene potentiell gefhrliche Situationen identifiziert. Im Anschluss
daran erfolgt die Klassifizierung jeder
Gefahr in eine entsprechende Sicherheitsanforderungsstufe (Automotive
Safety Integrity Level; ASIL) von A
bis D, wobei A die niedrigste und D die
hchste Sicherheitsstufe darstellen.
Mit steigendem ASIL wachsen die
Anforderungen an Hardware-Metriken
(z.B. FIT-Raten, Test-Coverage) des
Systems und den Software-Entwicklungsprozess (z.B. Testtiefe, Requirements Tracing, Review-Dokumenta-

tion), welche zustzlich zu den hohen

Qualittsanforderungen des Systemherstellers erfllt werden mssen.

Gestiegene Komplexitt durch

Standardisierung und Wiederverwendung beherrschen
In den letzten Jahren sind nicht nur
die Anzahl und die Komplexitt verschiedener Funktionen im Fahrzeug
gestiegen. Immer hufiger sind diese
auch ber das Fahrzeug verteilt. Diese
Entwicklung wurde auf der einen Seite
durch die deutlich steigende Rechenleistung der verwendeten Prozessoren,
andererseits durch die grere Bandbreite der Vernetzung begnstigt.
Die so umgesetzten Funktionen
haben inzwischen eine solche Komplexitt erreicht, dass herkmmliche
Entwicklungsmethoden den Anforderungen dieser Architektur nicht mehr
gengen. Deshalb haben sich 2003 die
Fahrzeughersteller in der Entwicklungspartnerschaft AUTOSAR zusammengeschlossen, um eine einheitliche
Software-Architektur fr Steuergerte
zu definieren und die Hardware von
der Software zu entkoppeln.
Vor der Definition von AUTOSAR
lagen hauptschlich der Kommunikations-Stack und die Diagnose im
Fokus der Automobilhersteller. Mit
www.elektroniknet.de

Entwicklung + Test llllISO 26262

App. 2

App. 4

Checkpoint
SafeApp2"

"

Comm
Services

I/O
Services

BSP
Prf-/Schutzfunktion

Nicht sicherheitsrelevante Standard-Software,

Betriebssystem

Sicherheitsrelevante
Funktion

Unkritische Anwendungs-Software

AUTOSAR erfhrt die Basis-Software

deutliche Erweiterungen. ber den bisherigen Umfang wie CAN, LIN, FlexRay und Diagnose hinaus kommen
jetzt noch Betriebssystem, Watchdog,
Memory-Stack und die Treiberschicht
fr den Mikrocontroller hinzu.
Mit der Ende 2009 verffentlichten
Version 4.0 hat die AUTOSAR-BasisSoftware eine hohe Komplexitt erreicht. ber 80 Software-Module werden ber Systembeschreibungsdateien
(AUTOSAR System Configuration
Description) definiert, mit Werkzeugen
konfiguriert und der Code generiert.

Anforderungen der AUTOSARBasis-Software fr sicherheitsrelevante Steuergerte

Lsst man die funktionalen Anforderungen auer Acht, bleibt im WesentCheckpoints
Safe"
Safe
"
"
Component
1" SWC

Checkpoints
Safe"
Safe
"
"
Component
2" SWC

SWC

SWC

J1939TP

MICROSAR CAL

Checkpoint
Safe CDD"
"

MICROSAR COM
MICROSAR IO

MICROSAR DIAG

Safe
Watchdog
Manager

XCP

Safe MPU
Manager

MICROSAR SYS

MICROSAR OS (SC3/4)

Watchdog

Complex Drivers

MICROSAR RTE

MICROSAR MOST

ll Bild 2. SafeExecution. Die Module mssen

gem Safety
Manual in ein
bestehendes
System integriert werden,
damit dieses
die Anforderungen der
ISO 26262 erfllt.

MICROSAR IP

Memory
Services

Checkpoint
SafeCDD"
"
Complex
Drivers

MICROSAR FR

System
Services

SafeWatchdogMgr

RTE

MICROSAR LIN

"

lichen eine Kernanforderung: Die Basis-Software darf die

sicherheitsrelevante
Software nicht beeinflussen bzw. stren. Dies bedeutet
Safezum einen, dass die
Watchdog
Basis-Software den
Speicher der sicherheitsrelevanten Software nicht verletzen
darf, und zum anderen, dass die BasisSoftware nicht mehr
Laufzeit bentigen
darf, als ihr zugedacht wurde. Zusammengefasst nennt man diese Bedingungen auch Rckwirkungsfreiheit oder
Freedom from Interference.
Der zunchst naheliegende Ansatz ist, die komplette Basis-Software
nach dem Standard fr sicherheitsrelevante Software zu entwickeln, der
unter ISO 26262 zusammengefasst
ist. Wie aber bereits erwhnt, ist die
AUTOSAR-Basis-Software komplex,
hat einen groen Funktionsumfang,
und ihre Spezifikationen unterliegen
kurzen nderungszyklen. Das macht
die Entwicklung nach ISO 26262 sehr
aufwendig.
Ein anderer Ansatz ist, die BasisSoftware von der sicherheitsrelevanten
Software mit Hilfe einer Absicherungsschicht sicher und rckwirkungsfrei zu
trennen (Software Partitioning). Die
dazu ntigen Funktionen sind bereits

MICROSAR CAN

Checkpoint
SafeApp1"

App. 3

MICROSAR MEM

OS

SafeMemoryProtection

Bootloader

App. 1

MICROSAR EXT

Mikrocontroller
berwachungs-/
Schutzfunktion

Sicherheitsrelevante
Funktion

AUTOSAR-BasisSoftware-Komponente (SWC)

Nicht sicherheitsrelevante
Funktion

ll Bild 3. Microsar von Vector wird durch die Software-Module SafeCOM und SafeExecution zu einer
abgesicherten AUTOSAR-Basis-Software-Lsung.

54

Elektronik automotive 11.2010

in AUTOSAR enthalten: Memory Protection und Program Flow Monitoring.

Somit kann eine ASIL-Dekomposition
der Basis-Software nach QM sowie
der Absicherungsschicht nach dem
gewnschten ASIL gem ISO 26262
durchgefhrt werden. Somit ist es ausreichend, lediglich die Module fr den
Speicherschutz (Memory Protection)
und das Laufzeitverhalten (Program
Flow Monitoring mit Watchdog) nach
ISO 26262 zu entwickeln.

Anwendung der ASIL-Dekomposition nach ISO 26262

Die ISO 26262 erfordert nicht zwangslufig die Neuentwicklung smtlicher
Software-Mechanismen. Die Norm
erlaubt es, einen bestimmten ASIL, der
fr das Erreichen eines Sicherheitszieles gefordert ist, durch die Kombination von unabhngigen Elementen und
entsprechende Aufteilung der Sicherheitsanforderungen in redundante Sicherheitsanforderungen darzustellen.
So ist es zum Beispiel mglich, ASIL
C durch die Kombination zweier Komponenten mit ASIL B und ASIL A unter
Bercksichtigung bestimmter Voraussetzungen zu erreichen (Bild 1). ASILDekomposition kann dabei auf System-, Hardware- und Software-Ebene
durchgefhrt werden. Bei der Durchfhrung ist darauf zu achten, dass die
Hardware-Architekturmetriken unberhrt bleiben und die Wahrscheinlichkeit der Verletzung des Sicherheitsziels
ausgeschlossen wird. Die ISO 26262
fordert zudem Confirmation Reviews,
welche gem den Sicherheitszielen
des ursprnglichen ASIL (in unserem
Beispiel ASIL C) durchzufhren sind.
Um die notwendige Unabhngigkeit
von Software-Komponenten verschiedener ASILs auf einem Steuergert zu
gewhrleisten, sind die im Standard
definierten Regeln der Rckwirkungsfreiheit einzuhalten und nachzuweisen.
Denn nur bei entsprechenden Manahmen und Nachweisen derselben
ist eine Coexistence von Elementen
im speziellen Fall von sicherheitsrelevanten und nicht sicherheitsrelevanten Elementen nebeneinander
zulssig. Generische Komponenten
(Subsysteme, Hardware-Komponenten, Software-Komponenten), fr die
whrend der Entwicklung noch kein
www.elektroniknet.de

_067

ISO 26262llll

konkreter Anwendungsfall (Item) und

somit noch keine Sicherheitsziele definiert sind, knnen gem ISO 26262
als Safety Element out of Context
(SEooC) entwickelt werden. Da in
diesem Falle die anwendbaren Sicherheitsanforderungen, die mit Hilfe des
Elements erfllt werden sollen, nicht
bekannt sind, mssen dafr Annahmen
(Assumptions) getroffen und entsprechend dokumentiert werden.
Beim ersten Einsatz des SEooC
muss mit Hilfe eines mitgelieferten
Sicherheitshandbuchs berprft werden, ob die getroffenen Annahmen mit
den im Anwendungsfall definierten
Sicherheitszielen und Sicherheitsanforderungen im Einklang stehen, deren Einhaltung untersttzen und keine
Widersprche bilden. Die korrekte
Verwendung gem Safety Manual ist
in Folge sicherzustellen und nachzuweisen.

Generische Umsetzung
der Absicherungsschicht
TTTech Automotive hat mit SafeExecution eine generische berwachungsschicht entwickelt, welche die
genannten Anforderungen hinsichtlich
Coexistence und Rckwirkungsfreiheit erfllt und durch die effiziente
Wiederverwendung von bestehenden
Komponenten zur Kostenreduktion
beitrgt. Durch die Modulintegration
fr Memory Protection und Program
Flow Monitoring knnen mgliche
Fehler in QM-entwickelten Teilen der
Basis- oder Applikations-Software sicher erkannt und eine geeignete Fehlerreaktion ausgelst werden (Bild 2).
Der Anwender muss dafr die Module
der SafeExecution entsprechend ihres
Safety Manuals integrieren und erhlt
so ein System, das den Anforderungen
der ISO 26262 gengt.

Dr. Thomas Wenzel

arbeitet seit 2006 am Institut fr Fahrzeugtechnik und Mobilitt und leitet seit Mrz
2010 das Kompetenzfeld Functional Safety.
Zuvor promovierte er im Bereich Regelungstechnik an der Coventry University.

Entwicklung + Test

SafeExecution ist damit neben

der bewhrten Lsung fr End-toEnd-Kommunikationsabsicherung
SafeCOM das zweite Modul fr die
Entwicklung sicherheitsgerichteter
Steuergerte von TTTech. SafeCOM
und SafeExecution sind generische
Software-Module, die durch die Integration in Microsar, die AUTOSARLsung von Vector, eine abgesicherte
Basis-Software aus einer Hand bieten
(Bild 3).
Die Wiederverwendung von zertifizierbar entwickelten, zentralen
Software-Komponenten reduziert die
Kosten fr die Integration der Anwendung. Anstelle einer applikationsspezifischen Lsung bieten TTTech und
Vector gemeinsam eine generische
Standardlsung und minimieren so
Entwicklungskosten von sicherheitsrelevanten Steuergerten nach ISO
26262. 
sj

Dipl.-Ing. Martin Fassl

Dipl.-Ing. (FH)
Joachim Kalmbach

studierte Technische Physik an der TU Wien

und arbeitet seit 1997 in der Hardware- und
Software-Entwicklung im Bereich Telekommunikation, Aerospace und Automotive. Er ist
seit 2008 bei der TTTech Automotive GmbH
als Produkt-Manager fr Entwicklungswerkzeuge und Standard-Software ttig.

studierte Informationstechnologie und Automation an der FH Reutlingen. Er trat 2006 in

die Vector Informatik GmbH ein und ist dort
als Produkt-Manager im Bereich Embedded
Software ttig. Seine Themenschwerpunkte
sind AUTOSAR und Functional Safety.

_067B7_Zentro_AUTO_11.pdf;S: 1;Format:(210.36 x 82.31 mm);15. Oct 2010 11:09:56

c
i
n
o
r
t
c
ele
www.elektroniknet.de

2
B
lle
a
H

13
1
/

Elektronik automotive 11.2010

55