Paper (pdf) - Berner & Mattner

Von der Komponenten- zur Funktionsorientierten
Entwicklung in der Funktionalen Sicherheit
Passing from component-oriented to function-oriented
development in the domain of Functional Safety
Dr.-Ing. B. Kaiser, Berner&Mattner, Berlin;
Dipl.-Ing. B. Augustin, AUDI AG, Ingolstadt,
Dipl.-Math. C. Baumann, AUDI AG, Ingolstadt
Kurzfassung
In den letzten Jahren kam es in der Automobilindustrie zu einem Paradigmenwechsel von
der komponentenorientierten hin zu einer funktionsorientierten Entwicklung: Komponentenübergreifende
Systeme werden zunächst als Ganzes funktional modelliert, erst in einem
zweiten Schritt erfolgt die Allokation auf technische Komponenten. Auch die Methoden der
Funktionalen Sicherheit (FuSi) müssen sich an das neue Paradigma anpassen, da bspw. die
für die Gefährdungsanalyse wesentliche Definition der Betrachtungseinheit (“Item”)
schwieriger wird, die Abgrenzung funktionales vs. technisches Sicherheitskonzept eine ganz
neue Bedeutung erhält und die Sicherheitsanalysen sich neben Komponentenfehlern auch
auf Fehler im Zusammenwirken fokussieren müssen. Da der maßgebliche FuSi-Standard
ISO 26262 die funktionsorientierte Entwicklung nicht explizit adressiert, liefert der
vorliegende Artikel einige Vorschläge, wie diese Norm im Kontext der funktionsorientierten
Entwicklung ausgelegt werden kann.
Abstract
During the last couple of years, the paradigm of component-oriented development has been
shifting towards a function-oriented approach: complex functions that span across many
ECUs are first modeled and designed as a whole, and then the allocation to technical
components is done in a separate step. Also functional safety methods need to reflect this
new paradigm, as, for instance, the definition of the “item” for the hazard analysis becomes
more difficult, the separation of functional and technical safety concept gets a new
interpretation, and safety analyses have to focus more and more on failures of collaboration,
in addition to component failures. As the current standard ISO 26262 does not address
function-oriented development explicitly, the present article makes some proposals on how to
interpret the ISO 26262 in the context of function oriented development.

1. Von der Komponenten- zur Funktionsorientierten Entwicklung
Traditionell denkt die Automobilbranche komponentenorientiert: die Entwicklung findet in den
Domänen Antrieb, Fahrwerk, Karosserie und Innenraum statt, dort wird nach Systemen,
Baugruppen und schließlich Bauteilen strukturiert, die jeweils dedizierte Funktionen ausüben.
Die Funktionen vormals rein mechanischer Bauteile wurden durch elektronische Systeme
erweitert oder ganz übernommen, wobei aber immer noch ein Steuergerät (auch ECU
genannt, für Electronic Control Unit) genau einem mechatronischen System zugeordnet und
auf dessen abgegrenzten Funktionsbereich hin optimiert war. In diesem Setting war die
komponentenorientierte Entwicklung optimal, da die Expertise bezüglich Hardware,
Software, Mechanik und Einsatzumgebung an einer Stelle gebündelt war.
Die Vernetzung der Komponenten in Verbindung mit immer leistungsfähigerer Hard- und
Software und Sensorik erlaubte die Evolution neuer, bereichsübergreifender Funktionen zur
Steigerung von Komfort und Sicherheit. So konnte die im Bremsensteuergerät
untergebrachte ABS/ESC-Funktion das Antriebsmanagement im Motorsteuergerät anweisen,
nach Bedarf das Motordrehmoment zu reduzieren oder über die elektrische Servolenkung
auf den Lenkwinkel einwirken. Noch immer ließ sich die komponentenorientierte Sicht
aufrechterhalten, da die Funktion im Wesentlichen auf einem Steuergerät „gehosted“ war (im
Beispiel dem Bremsensteuergerät) und die mit dessen Entwicklung betraute Abteilung in der
Verantwortung für die ganze Funktion war.
Die heute bereits vorhandenen Hardwaresysteme ermöglichen weitere Synergien und damit
neue Funktionen, die mit geringem Zusatzaufwand realisierbar sind. Beispiele sind
Parkassistenten, die unter Zugriff auf vorhandene Sensoriken (z.B. der etablierten Funktion
Park Distance Control) und unter Beeinflussung mehrerer der vorhandenen Aktuatoren einen
weitgehend autonomen Ein- und Ausparkvorgang gestatten. Diese Funktionen
überschneiden sich bezüglich Sensor- und Aktuator-Zugriff mit anderen übergreifenden
Funktionen, etwa Spurhalteassistent, Notbremsassistent oder autonome Notbremsung
(siehe Bild 1). Ein Ende dieser Entwicklung ist nicht absehbar, da für die nächsten Jahre
auch das hochautomatisierte Fahren auf der Agenda für die Serieneinführung steht.
Es wird also zur Kernkompetenz der Fahrzeughersteller, komponentenübergreifende
Funktionen und deren Interaktion – auch in Gegenwart von Fehlern und
Funktionseinschränkungen – disziplinübergreifend spezifizieren, modellieren und verifizieren
zu können, wozu alle Entwicklungsbereiche enger als bisher werden kooperieren müssen.
Um sich dieser Herausforderung zu stellen, begannen viele Automobilunternehmen
umzudenken und von einer komponentenorientierten zu einer funktionsorientierten
Entwicklung überzugehen [1].

Power Steering
EPS ECU
M
Lane Assist
Camera
LDW ECU
Algorithm
Park Assist
Ultrasonic Sensors
PDC ECU
Algorithm
Motor Reg
Engine ECU
ABS / ESP
Wheel Sensor
Brake
Pedal
ABS/ESC
ESC ECU
Brake
Bild 1: Hochvernetzter und steuergeräteübergreifender Funktionskomplex
2. Kurze Darstellung der Funktionsorientierten Entwicklung
In der funktionsorientierten Entwicklung wird zunächst jede kundenerlebbare Funktion
möglichst unabhängig von einer späteren technischen Umsetzung definiert und das auf
Fahrzeugebene erlebbare Sollverhalten durch Funktionsblöcke modelliert. So wird einerseits
eine frühe Validation durch Simulation und Rapid Prototyping möglich und andererseits das
Ziel verfolgt, die Funktion in möglichst vielen verschiedenen Fahrzeugprojekten einsetzen zu
können.
Für neue Funktionen folgt dann eine Systemarchitekturphase. In dieser werden die
funktionalen Anforderungen aller im Projekt eingeplanten Funktionen auf die
Fahrzeugarchitektur abgebildet und die Funktionsblöcke auf tatsächliche Komponenten
(Sensorik, Aktuatorik, Steuergeräte) des jeweiligen Fahrzeugs allokiert. Jede Komponente
erhält folglich Anforderungen aus diversen Funktionen, die miteinander zu vereinigen und auf
Widersprüche und gesamtheitliche Umsetzbarkeit zu prüfen sind. Dabei liegt deutlich mehr
Verantwortung als in der Vergangenheit auf der Rolle des Systemarchitekten, der Aspekte
wie die Funktionsarchitektur im Fahrzeug, Bus-Latenzen, Rechenkapazitäten der

Steuergeräte, Fähigkeiten der Sensorik, Feature Interaction und Verhalten bei
Komponentenausfällen berücksichtigen muss.
Das vermehrte Aufkommen teil- und hochautomatisierter Assistenzfunktionen potenziert die
Anforderung funktionsorientiert zu entwickeln, da sich solche Funktionen zum großen Teil
dieselben Sensoren und Aktuatoren teilen. Es bietet sich an, ihre Kernfunktionen in einem
zentralen Fahrerassistenzsteuergerät (kurz: zFAS) zu bündeln, wo alle ihre Eingangsdaten
(d.h. Input der Sensorik) und Ausgangsdaten (d.h. Output zur Aktuatorik) über einheitliche
Schnittstellen kanalisiert werden (siehe Bild 2). So wird eine Auflösung eventueller
Widersprüche zwischen Funktionen durch zentrale Arbitrierung und eine gemeinsame
Rückfallstrategie bei Sensorausfällen möglich.
Ego-
Bewegungs-
Sensorik
Radar Ultraschall
Laser
Sensoren
Kamera
Sensordatenfusion
Bewegungsmanager
Bild 2: Systemarchitekturlösung mit zFAS
Um den Lösungsraum nicht einzuschränken, machen die Funktionsverantwortlichen keine
konkreten Vorgaben über Typ und Leistungsfähigkeit einzelner Sensoren, sondern
beschreiben auf funktionaler Ebene die Objekte, die erkannt werden sollen, einschließlich
Genauigkeits- und Entfernungsangaben, bleiben also auf funktionaler Ebene. Die
Systemdesigner haben anschließend zu bewerten, mit welcher Sensorik die geforderten
Gütemaße erfüllt werden können und wählen entsprechend das fahrzeugprojekt-spezifische
Sensorset aus.
Der weitere Entwicklungsprozess verläuft weitgehend analog zur klassischen
komponentenorientierten Entwicklung, i.d.R. bei den verschiedenen Komponentenlieferanten
entsprechend dem V-Modell. Die System-Integrationsebene – als Gegenpart zur System-

Architektur-Ebene im linken V-Ast – hat im rechten V-Ast eine herausgehobene Bedeutung.
Beim Validationstest am Ende des V’s dienen schließlich die Funktionsbeschreibungen vom
Beginn der funktionsorientierten Entwicklung als Referenz (vgl. Bild 3).
Bild 3: Darstellung der funktionsorientierten Entwicklung als V-Modell
3. Neue Herausforderungen für den Prozess der Funktionalen Sicherheit
Zur Umstellung des Entwicklungsprozesses auf die funktionsorientierte Entwicklung kommt
als weitere Herausforderung hinzu, dass quasi alle in Frage kommenden Systeme
sicherheitsrelevant sind und daher die Forderungen der ISO 26262 [2] zusätzlich in diesen
funktionsorientierten Prozess zu integrieren sind. Das domänenübergreifende Erstellen von
FuSi-Artefakten wie Sicherheitskonzepten ist für viele FuSi-Verantwortliche noch Neuland.
Hazards resultieren im Bereich des hochautomatisierten Fahrens nicht nur aus Fehlern in
einzelnen Komponenten, sondern auch aus Fehlern im Zusammenspiel der verschiedenen
Funktionen und Steuergeräte, was den Fokus von Sicherheitsanalysen verschiebt. Bei der
Objekterkennung ist die Güte der Sensoriken und Auswertungsalgorithmen für die Sicherheit
auf Fahrzeugebene entscheidend, so dass die Grenzen zwischen FuSi, Gebrauchssicherheit
und nomineller Performanz zu verschwimmen beginnen. Zusätzlich ist beim
hochautomatisierten Fahren im höheren Geschwindigkeitsbereich eine fail-safe Eigenschaft
der Funktion nicht mehr ausreichend, da es keinen unmittelbar erreichbaren sicheren
Zustand gibt und dieser erst durch einen (evtl. eingeschränkten) fail-operational Betrieb
erreicht werden kann. Deshalb muss die FuSi auf Systemebene Aspekte wie Redundanz,

Mehrkanaligkeit und Schutz vor gemeinsamen Fehlern deutlich stärker als bisher
berücksichtigen.
4. Integration der FuSi-Aktivitäten in die Funktionsorientierte Entwicklung
In der Praxis hat sich als vorteilhaft herausgestellt, den funktionsorientierten Prozess als
Vorlage zu nehmen und die FuSi-Aktivitäten darauf abzubilden. Wie sich auch beim
funktionsorientierten Entwicklungsansatz Vorteile bzgl. Portabilität (bzgl. Fahrzeugprojekte)
und Skalierbarkeit (bzgl. Fzg.architekturen, bspw. neuer Bustopologien) ergeben, führen die
so entstehenden Synergien auch in der FuSi zu Verbesserungen bezogen auf Systematik
und Effizienz. Die folgenden Erkenntnisse wurden aus Praxisprojekten gewonnen, bei denen
die Vorgaben der ISO 26262 auf funktionsorientierte Entwicklungsvorhaben interpretiert
wurden. Es werden die jeweiligen Besonderheiten der Hauptaktivitäten der ISO 26262
vorgestellt.
4.1. Item Definition
Bereits bei der Item Definition ist einiges zu beachten, denn dieses bildet die Grundlage für
die Gefährdungsanalyse und Risikobewertung (G&R) und grenzt den Arbeitsumfang des
gesamten nachfolgenden Sicherheitsprozesses ab. Die ISO 26262 verortet Hazards auf
Fahrzeugebene – und dort sind es primär die Aktuatoren, die Unfallszenarien auslösen.
Auch wenn althergebrachte Aktuatoren wie Lenkung und Bremse nicht zur Assistenzfunktion
im engeren Sinne gerechnet werden, sind sie Teil der Funktion und damit des Items. Es
bietet es sich an, für die G&R die Aktuatorik in den Scope mit einzubeziehen (und dabei von
vorhandenen G&Rs aus dem Fahrwerksbereich zu profitieren), im späteren System-
Sicherheitskonzept jedoch nur den reduzierten Scope des Funktionskernumfangs technisch
auszudefinieren. Somit unterscheidet die Item Definition also künftig mehrere „Scopes“ (man
denke an verschiedenfarbige Umrahmungen von Teilkomplexen) und es ist auf diese Weise
auch möglich, eine gemeinsame Item Definition für mehrere eng verwandte Funktionen (so
genannte Funktionskomplexe) auf einmal zu erstellen und diese durch Scopes abzugrenzen,
was Aufwand reduziert und Inkonsistenzen verhindert.
4.2. Gefährdungsanalyse und Risikobewertung (G&R)
Werden die o.g. Ratschläge bezüglich der Item Definition beherzigt, so wird auch die G&R
durch den neuen funktionsorientierten Ansatz vereinfacht und vereinheitlicht. So ist es etwa
bei der Gefährdung „Fehllenker bei Autobahnfahrt“ auf Fahrzeugebene gleichgültig, ob

dieser verursacht wird durch einen fehlerhaften Steuerbefehl eines Parkassistenten oder
durch einen internen Hardwarefehler des Lenkungssteuergeräts.
In der bisherigen komponentenorientierten Sicht hatten Analysten „innenliegender“
Komponenten oft die Schwierigkeit, bewertbare Gefährdungen auf Fahrzeugebene zu
analysieren, da solche Steuergeräte keinen unmittelbaren Zugriff auf Aktuatoren, sondern
meist nur Bus-Schnittstellen zu den Aktuator-Steuergeräten haben. In der
funktionsorientierten Sicht legen nun die Experten aller beteiligten Disziplinen (Sensorik,
Verarbeitung, Aktuatorik, Fahrerinterface) unter Leitung des Funktionsverantwortlichen die
gesamte Wirkkette der Funktion aus und analysieren diese auch bezüglich FuSi. Dadurch
steht bei der G&R eine höhere Expertise zur Verfügung und es tritt eine Verbesserung der
Konsistenz und eine Effizienzsteigerung durch Wiederverwendung ein.
Beim Übergang zum automatisierten Fahren scheint es zudem sinnvoll, die Gefährdungen
bei einer aktivierten automatisierten Funktion nicht mehr aktuatororientiert, sondern vielmehr
freiraum- bzw. trajektorienorientiert zu betrachten. Im automatisierten Modus ist bspw. der
Begriff „Selbstlenker“ für einen Hazard an sich schon fragwürdig, aber selbst der Term
„Fehllenker“ wäre nicht ohne Bezug zur Längsdynamik und zur Umgebungssituation zu
definieren. Somit erscheint die Suche nach Hazards alleine des Aktuators „Lenkung“ nicht
mehr zielführend – ein Hazard tritt nämlich erst dann auf, wenn durch das Zusammenspiel
von Antrieb, Lenkung und Bremse der tatsächliche Freiraum um das Fahrzeug verletzt wird
und Kollisionen entstehen können. Somit erhält man auch bereits in der G&R einen
Übergang von einer komponentenorientierten zu einer funktionsorientierten Denkweise.
4.3. Funktionales Sicherheitskonzept (FuSiKo)
In der Vergangenheit gingen funktionales und technisches Sicherheitskonzept oft fließend
ineinander über – das FuSiKo als grobere Vorstufe des technischen Konzepts – und waren
folglich in gleicher Weise, meist nach Sicherheitszielen, strukturiert. Dies sorgt zwar auf den
oberen Gliederungsebenen für gute Übersicht, zwingt aber bei weiterem Vordringen in die
technischen Details zu häufigen Wiederholungen oder Querverweisen, weil
Komponentenfehler mehrere Gefährdungen verursachen können, weil technische
Maßnahmen mehreren Sicherheitszielen auf einmal dienen können und vor allem, weil
Sicherheitsmaßnahmen an anderer Stelle allokiert sein können als dem Entstehungsort der
zugeordneten Fehler. Somit ist diese klassische Strukturierung bei verteilten Systemen mit
hoher Funktionsüberschneidung weder der Verständlichkeit förderlich, noch der
wünschenswerten definierten Wiederverwendung von Teilen des Sicherheitskonzepts.

In der funktionsorientierten Entwicklung bietet es sich nun an, funktionales und technisches
Sicherheitskonzept stärker zu trennen und ihnen klare Aufgaben zuzuweisen: das FuSiKo,
das weiterhin nach Sicherheitszielen strukturiert wird, wird einmal pro Fahrzeugfunktion
erstellt. Es bricht die Sicherheitsziele herunter auf Sicherheits-Features (z.B. Integrität der
Abstandserfassung zu einem Hindernis), die durch funktionale (technologieunabhängige)
Anforderungen ausdefiniert werden, z.B. „Es ist sicherzustellen, dass alle Fehler, die zur
Nichtentdeckung oder zur verspäteten Entdeckung von Hindernissen führen können, sicher
entdeckt und übermittelt werden und zur geordneten Beendigung der Funktion führen.“
Solche Anforderungen beziehen sich nicht auf eine spezifische Sensortechnologie und
nennen auch keine konkreten technischen Maßnahmen wie Plausibilisierungen. Die
Anforderungen sind bewusst abstrakt formuliert (z.B. „Jegliche … sind zu verhindern.“),
damit sie sich leicht in die technologieunabhängige funktionale Anforderungsspezifikation
integrieren lassen und unverändert weiter gelten, wenn dieselbe Funktion in einem späteren
Fahrzeugprojekt mit anderen technischen Mitteln realisiert wird.
Die Betrachtungen im FuSiKo basieren auf dem Funktionsblockmodell, das aus der
Funktionsspezifikation übernommen wird. Hieran werden die Auswirkungen möglicher Fehler
untersucht und funktionale Maßnahmen dagegen definiert. Die Sicherheitsanforderungen
werden vorhandenen Funktionsblöcken (z.B. Sensordatenfusion, Bewegungsmanager)
zugeordnet, wobei es zusätzlich nötig werden kann, neue Funktionsblöcke speziell für die
Erfüllung der Sicherheitsanforderungen hinzuzufügen: Entsprechend der freiraumorientierten
Hazard-Definition aus der G&R, liegt z.B. es bei teil- und hochautomatisiertem Fahren nahe,
einen neuen Funktionsblock vorzusehen, der sich drohenden Kollisionen zwischen Ego-
Fahrzeug und Umgebung widmet. Dieser „Kollisionswächter“ ist somit der „ASIL-Träger“ der
Funktion, während viele weitere Teile der Funktion anschließend ohne (bzw. mit geringeren)
Sicherheitsanforderungen auskommen.
4.4. Systemsicherheitskonzept (SysSiKo)
Das SysSiKo ist das FuSi-seitige Gegenstück zur Systemarchitektur, denn wie diese allokiert
es die abstrakten Sicherheitsfunktionen auf konkrete technische Komponenten. Hier laufen
die Anforderungen aus den FuSiKos aller Funktionen zusammen (siehe Bild 4). Das SysSiKo
wird entsprechend vom OEM erstellt und kann interpretiert werden als komponentenübergreifender
Teil des technischen Sicherheitskonzept gem. ISO 26262 (der detailliertere
Teil des technischen Sicherheitskonzepts, der sich bspw. mit der Absicherung von
Mikroprozessoren befasst, wird weiterhin vom Zulieferer erstellt).

Bild 4: Zusammenhang FuSiKo / SysSiKo / TeSiKo
Im SysSiKo werden die Maßnahmen aus den FuSiKos technisch konkretisiert und es wird
auf Fehlermodi der realen, projektspezifischen Implementierung Bezug genommen (etwa
Botschaftsverfälschungen durch ein CAN-Gateway eines spezifischen Fahrzeugs, das in der
funktionalen Betrachtung noch gar nicht existierte). Die Anforderungen werden zudem an
Komponenten adressiert (z.B. „Das ESC-Steuergerät muss bei Eintreffen einer gültigen
Notbremsungs-Signalisierung innerhalb von 200 ms das unter Einhaltung der
Fahrzeugstabilität maximal mögliche Bremsmoment aufbauen.“). Eine Traceability zu den
verschiedenen beteiligten FuSiKos wird durch identifizierbare Verweise hergestellt oder, falls
man das Sicherheitskonzept in Systemen wie DOORS pflegt, durch Links.
Ebenfalls im SysSiKo findet die Allokierung von ASILs und Budgets im Sinne der Hardwareund
Architekturmetriken statt, sowie die Budgetierung der Fehlerreaktionszeiten über die
Wirkketten, die im Falle komplexer Assistenzsysteme über drei und mehr Steuergeräte auf
verschiedenen Teilbussen verlaufen können und komplexe Modellierung erfordern. Der Blick
des FuSi-Analysten ist hier besonders auf das richtige Zusammenwirken der Komponenten
gerichtet, nicht nur auf ihre individuelle Fehlerfreiheit – und eine enge Kooperation mit dem
Systemarchitekten ist essentiell.
Im SysSiKo wechselt auch die Kapitel-Strukturierung von der sicherheitsziel-orientierten
Sicht auf die komponentenorientierte Sicht. Alle Aspekte bspw. der Umfelderfassung werden
im selben Kapitel betrachtet, gleich von welchen Sicherheitszielen sie sich herleiten.
Entsprechend findet hier auch eine Maximum-Bildung über den ASIL statt: jede Funktion
einer Komponente erbt den höchsten ASIL aller Sicherheitsanforderungen, die sie betreffen.
Da viele Maßnahmen im SysSiKo (etwa End-to-End-Absicherung der Kommunikation) gegen
diverse Fehlermodi verschiedener Komponenten wirken, empfiehlt sich die von uns bereits

früher vorgeschlagene Matrixmethode [4], um einerseits die Vollständigkeit der Maßnahmen
zu garantieren, andererseits aber Over-Engineering zu vermeiden (siehe Bild 5).
zFAS
ESC-SG
Fehler-Modi
Sensor Eval
CAN
FuSi-Maßnahme
Cross- Plausibilisierung
durch Sensorfusion
ASIL- Konforme SW-
Entwicklung
CAN- Absicherung durch
CRC
Ignorieren von
Bremsanforderung bei v
> v-max
Fehlerhafte Bremsanforderung wg
Phantom- Objekt □ ■
Fehlerhafte Bremsanforderung wg
SW- Fehler □ ■
Fehlerhafte Bremsanforderung wg
Botschafts- Verfälschung ■ ■
Bild 5: Matrix zur Allokation von Sicherheitsmaßnahmen zu Fehlermodi
Im SysSiKo werden technische Entwurfsentscheidungen (etwa die Verwendung eines zFAS
mit einheitlichen Schnittstellen zwischen Funktionen und Sensordaten/Aktuatorik) gegen
daraus resultierende Herausforderungen der FuSi abgewogen und bewertet: So sind für
Einzelpunktfehler anfällige Einkanaligkeiten evtl. durch Redundanzen oder
Rückfallebenenlösungen zu ergänzen, so dass trotz der schlanken einkanaligen
Funktionsarchitektur unter Umständen auf technischer Ebene wieder zusätzliche
sicherheitsbedingte By-Pass-Lösungen generiert werden müssen. Die Bedeutung des
SysSiKo ist also analog zur Bedeutung der Systemarchitektur in der funktionalen
Entwicklung erheblich gewachsen.
4.5. Komponentenweise Umsetzung beim Lieferanten
Sind die Sicherheitsanforderungen aus dem SysSiKo den Komponenten zugeordnet, auf die
Lastenhefte der Komponenten verteilt und den Lieferanten übergeben, unterscheidet sich
das weitere Vorgehen nicht mehr wesentlich von der klassischen Entwicklung. Für die
Komponente ist ein technisches Sicherheitskonzept (TeSiKo) zu erstellen. Dieses greift die
Sicherheitsanforderungen aus dem SysSiKo des OEMs auf und verfeinert sie zu konkreten
Lösungen, ergänzt um weitere Sicherheitsmaßnahmen auf Grund der Komponenten-FMEA.
Hierzu zählen bspw. Abschaltpfadtests, Spannungs- und Temperaturüberwachungen oder

Prozessor-Absicherungsmaßnahmen. Die Lösungen aus dem Sicherheitskonzept sind
konform zu den Regeln der ISO 26262 entsprechend ihrem ASIL umzusetzen und die
Nachweise dazu an den Komponentenverantwortlichen beim OEM zu liefern. Die Einhaltung
der im SysSiKo des OEMs festgesetzten Zuverlässigkeits- und Metrik-Budgets sowie die
zeitlichen Anforderungen bzgl. Fehlerdetektions- und Fehlerreaktionszeiten sind
nachzuweisen.
4.6. Integration und Sicherheitsnachweis
Im klassichen V-Modell verlaufen Komponenten-Integration und zugehörige Tests im rechten
V-Ast in spiegelbildlicher Reihenfolge wie die Dekomposition in Komponenten, die im linken
V-Ast stattfand. Dies gilt im funktionsorientierten Kontext weiterhin. Zu beachten ist jedoch,
dass die im linken Ast formulierten funktionalen Sicherheitsanforderungen abstrakt und nicht
unbedingt direkt testbar sind (ein häufig gehörter Kritikpunkt), da man bewusst auf die
Benennung konkreter Signale, Schnittstellen und selbst Sicherheitsmaßnahmen verzichtet
hat, um die Skalierbarkeit der Funktion nicht zu behindern.
Zur Lösung dieses Problems bedient man sich für die Verifikation der funktionalen
Sicherheitsanforderungen einer Kombination aus Funktionstest der funktionalen
Sicherheitsanforderungen (bei dem sich die für den Test nötigen konkreten technischen
Schnittstellen aus der Verlinkung zwischen Funktionsanforderung und Systemdesign im
linken V-Ast ermitteln lassen) und einer strukturierten Argumentation im Sicherheitsnachweis
(z.B. nach Kelly [4]), die nachvollziehbar die Erfüllung der abstrakten funktionalen
Sicherheitsanforderungen belegt unter Bezugnahme auf die lückenlose Ableitung und die
erfolgreichen Tests der konkreten technischen Realisierung.
5. Varianten, Änderungen und Wiederverwendung
Ihre eigentliche Stärke spielt die funktionsorientierte Entwicklungsmethodik aus, wenn es zu
Variantenbildung, Änderungen an einem bestehenden Produkt und zu Wiederverwendung
von Funktionen oder aber technischen Lösungen im Rahmen neuer Funktionskomplexe
kommt. Durch die Modularisierung und die Abstraktion der Funktion von der
fahrzeugspezifischen Umsetzung müssen nur die Artefakte im Entwicklungsprozess
angepasst werden, die von der Änderung betroffen sind (und natürlich müssen im rechten V-
Ast alle Integrations- und Testschritte wiederholt werden). Diese Aussage gilt für Artefakte
der normalen Entwicklung ebenso wie für die Arbeitsprodukte der FuSi-Aktivitäten: Wird z.B.
nur ein Steuergerät durch ein Modell eines anderen Zulieferers ersetzt, so gelten FuSiKo und
SysSiKo weiterhin; nur das TeSiKo der Komponente ist neu zu erstellen sowie die

komponentenbezogenen Analysen wie Design-FMEA. Selbst die nötig werdenden
Anpassungen bei Änderungen an der Funktion oder bei einer geänderten Realisierung in
einem anderen Fahrzeugprojekt vereinfachen sich durch die modularere Struktur aller FuSi-
Arbeitsprodukte. Entscheidend für die Wiederverwendung ist jedoch, dass schon in den
frühen Phasen (Item Definition, G&R, FuSiKo) der Empfehlung befolgt wird, alle Annahmen
explizit (z.B. in einer separaten Tabelle mit eindeutigen IDs) festzuhalten. So kann bei jeder
Veränderung oder Übernahme geprüft werden, ob alle Annahmen noch gelten und, falls
nicht, welche Teile der Konzepte von den Änderungen betroffen sind.
6. Fazit
Der vorliegende Beitrag stellte einen neuen und in weiten Teilen bereits praktisch erprobten
Ansatz vor, wie sich die FuSi-Aktivitäten gem. ISO 26262 in den funktionsorientierten
Entwicklungsprozess in der Automobilindustrie integrieren lassen. Die Veränderungen, die
sich unter diesen Vorzeichen für alle wesentlichen FuSi-Aktivitäten ergeben, wurden mit
Bezugnahme auf neue Assistenzfunktionen im Bereich des teil- und hochautomatisierten
Fahrens diskutiert. Der Hauptvorteil der Adaption der Sicherheitsaktivitäten an die
funktionsorientierte Entwicklung liegt in der Beherrschung der hohen Komplexität heutiger
steuergeräteübergreifender Funktionen und der Maximierung der Synergieeffekte durch
Übernahmepotential von FuSi-Arbeitsprodukten in veränderten Projektkontexten. Mehrere
Projekte im Bereich der Fahrerassistenzsysteme und des automatisierten Fahrens im
Kontext der Unternehmen Volkswagen und Audi haben gezeigt, dass sich tatsächlich
erhebliche Aufwandsreduktionen erzielen ließen und sich die Beherrschung der Komplexität
solcher Systeme im Bereich der FuSi vereinfachte. Außer im Fahrerassistenzbereich eignet
sich die Methode auch für andere komponentenübergreifende Funktionen, etwa in der
Hybridantriebstechnik, wo sowohl Antreiben als auch Bremsen durch komplexe Kooperation
mehrerer Komponenten realisiert werden.
[1] Dietrich, B. und Kuther, T.: Funktionsorientierte Entwicklung schafft Transparenz und
stellt perfektes Zusammenspiel aller Komponenten sicher. Elektronik Praxis Feb 2009
[2] ISO 26262 Road Vehicles – Functional Safety . International Standard
[3] Kaiser, B.: Approaches Towards Reusable Safety Concepts”. 2 nd VDA Automotive SYS
Conference, Berlin, 15./16.05.2012
[4] Kelly, T. und Weaver, R.: The Goal Structuring Notation – A Safety Argument Notation.
Proc. of Dependable Systems and Networks 2004 Workshop on Assurance Cases,
2004