MODULAR STATT MONOLITHISCH NEUE ANSÄTZE FÜR DIE WIEDERVERWENDUNG VON SICHERHEITSKONZEPTENDas zentrale Dokument in jedem Sicherheitslebenszyklus ist das Sicherheitskonzept (SiKo). Hohe Komplexität

und Variantenvielfalt von ECU-Architektur und Funktionen gehen bei der Erstellung von Sicherheitskonzepten

jedoch stets mit steigenden Ressourcen bei Entwicklern und Reviewern einher. Modular konzipierte und wieder-

verwendbare SiKos sind daher ein Schlüssel für eine effizientere Umsetzung und ergänzen die Anforderungen

der relevanten Norm ISO 26262. Teile bestehender SiKos können dadurch definiert wiederverwendet werden,

wie Berner & Mattner Systemtechnik beschreibt.

ENTWICKLUNG FUNKTIONALE SICHERHEIT

44

Funktionale Sicherheit

NEUE HERAUSFORDERUNGEN DURCH NEUE ANFORDERUNGEN

Neue Entwicklungen von E/E-Systemen im Fahrzeug verursachen im Bereich der funktionalen Sicherheit immer höhere Aufwände. Bei komplexen Fahrerassis-tenzsystemen ist es heute beispielsweise der Normalfall, dass eine Gruppe von Funktionen (wie Adaptive Cruise Con-trol, Fahrspurassistent etc.) auf eine Gruppe von Steuergeräten ko-allokiert wird (beispielsweise Sensor-ECU für Kamera und Radar, Zentralsteuergerät etc.). Darüber hinaus werden Sensoren, Software-Funktionen oder Aktuatoren, die sich in anderem Kontext schon bewährt haben, auch für neue Funktio-nen wiederverwendet. Nicht zuletzt unterstützt der Autosar-Standard diesen Trend und erhöht die Variantenvielfalt. Mit Blick auf begrenzte Entwicklungsres-sourcen und -budgets ist eine Strukturie-rung des SiKos im Hinblick auf effiziente Wiederverwendung sinnvoll.

Die relevante Norm ISO 26262 bietet in ihrer aktuellen Form keine konkreten Handreichungen hierfür. Zwar werden bestimmte Inhalte gefordert – die Struk-tur des Dokuments ist jedoch relativ frei und unterscheidet sich in der Praxis oft-mals von Autor zu Autor. Folge: Jedes SiKo ist einzigartig. Wiederverwendbar-keit und Nachvollziehbarkeit durch ver-

teilte Entwicklerteams, Reviewer und potenzielle Wiederverwender sind nur aufwendig zu erreichen.

STRUKTURIERTES VORGEHEN BEI DER SIKO-ERSTELLUNG

Eine strukturierte Vorgehensweise bei der Erstellung von SiKos ermöglicht hin-gegen eine arbeitsteilige Erstellung und die Nachvollziehbarkeit der technischen Argumentation. Vor allem die Modulari-sierung, ➊, das heißt die Gliederung nach Systemteilen und damit die Vorbe-reitung einer systematisch begründeten Übernahme einzelner Kapitel, erleichtert die Variantenbildung erheblich. Kunden-projekte haben gezeigt, wie der Sicher-heitsprozess mit wiederverwendbaren SiKos effektiver und kostengünstiger gestaltet werden kann. Bereits beim zweiten SiKo zur selben Funktions-gruppe reduzierte sich der Aufwand um 50 %, ebenso wie typische Copy-and-Paste-Fehler.

Wird der Prozess zur funktionalen Sicherheit bereits in den „konventionel-len“ Entwicklungsprozess integriert, las-sen sich frühzeitig Entscheidungen zu Architektur und Software-Komponenten treffen: eine wichtige Voraussetzung für einen reibungslosen Entwicklungspro-zess. Jedoch werden aktuell die Aktivitä-ten zur funktionalen Sicherheit erst spät

1. Hazard 01: „Motor beschleunigt unangefordert“

1.1. Funktionales Sicherheitskonzept

1.1.1. Funktionale Sicherheitsanforderungen

1.1.1.1. ...

1.2. Technisches Sicherheitskonzept

1.2.1. Funktionale Sicherheitsanforderung 01

1.2.1.1. Technische Sicherheits- anforderung 01.01.

1.2.1.2. ...

1.2.2. Funktionale Sicherheitsanforderung 02

1.2.2.1. Technische Sicherheits- anforderung 02.01.

1.2.2.2. ...

2. Hazard 02: …

Funktionales und technischesSicherheitskonzept in einem Dokument

1. Sicherheitsziele

1.1. Hazard 01: „Motor beschleunigt unangefordert“

1.1.1. Safety Features

1.1.1.1. Safety Feature 01

1.1.1.1.1. Architektur

1.1.1.1.2. ...

1.1.1.2. Safety Feature 02

1.1.1.2.1. …

1.2. Hazard 02: …

Funktionales Sicherheitskonzept

1. Safety Features

1.1. Safety Feature 01

1.1.1. Zuordung Safety Features zu Subsystemen

1.2. Safety Feature 02

1.2.1. ...

2. Subsysteme

2.1. Subsystem A

2.1.1. Strategie zur Umsetzung

2.1.2. ...

2.2. Subsystem B

2.2.1. …

Technisches Sicherheitskonzept

AUTOREN

BJÖRN LAUSTSENist Systemingenieur bei der

Berner & Mattner Systemtechnik GmbH in München.

DR. BERNHARD KAISERist Leiter Competence Center Safety

und Systems Engineering bei der Berner & Mattner

Systemtechnik GmbH in München.

JÜRGEN MEYERist Bereichsleiter Automotive

bei der Berner & Mattner Systemtechnik GmbH in München.

➊ Durch die strikte Trennung des funktionalen und technischen Teils des Sicherheitskonzepts (SiKo) sowie einer Strukturierung anhand von technischen Komponenten lassen sich die Anteile, die systema-tisch und begründet wiederverwendet werden kön-nen, stark erhöhen

45 04I2014 9. Jahrgang

Funktionale Sicherheit

begonnen. Aber auch hier bieten modu-lare SiKo-Kapitel zusätzliche Effizienz-vorteile, da bestehende Teile einfacher in das fortschreitende Systemdesign integ-riert werden können. Wie das Vorgehen aussehen kann, zeigt der Artikel.

TRENNUNG VON FUNKTIONALEM UND TECHNISCHEM SICHERHEITSKONZEPT

Traditionell beginnen SiKos mit den Gefährdungen und Sicherheitszielen, die sich aus der Gefahren- und Risikoana-lyse ableiten. Anschließend werden diese Sicherheitsziele im funktionalen SiKo auf einzelne funktionale Bestandteile des Systems allokiert, um Maßnahmen gegen mögliche Fehler, die zu Gefähr-dungen führen können, zu formulieren. Im technischen SiKo werden diese Maß-nahmen auf technischer Ebene weiter verfeinert. Der Nachteil: Oftmals werden funktionale Sicherheitsziele und techni-sche Maßnahmen in einem Dokument ohne klare Trennung dargestellt und Teile der technischen Umsetzung bereits im funktionalen Teil vorweggenommen. Eine systematische Wiederverwendung für eine neue technische Lösung ist spä-ter kaum möglich, da technische Details über das ganze Konzept verteilt sind.

REALISIERUNG IN ZWEI TEILEN

Das funktionale SiKo sollte daher stets unabhängig von der technischen Reali-sierung formuliert werden. Gerade im Autosar-Kontext ist dieses Vorgehen von Vorteil: Das funktionale SiKo ist somit unabhängig von der Zuordnung der Funktion zur ECU. Ein bewährter Trick: die funktionalen Sicherheitsanforderun-gen im Passiv formulieren („Es ist zu verhindern, dass …“), die technischen jedoch im Aktiv (zum Beispiel „Die Überwachungsfunktion muss …“). So vermeidet der Autor im funktionalen SiKo eine Festlegung auf technische Lösungen – in Folgeprojekten könnten diese sich anders gestalten. Im techni-schen Konzept fordert der Autor die Umsetzung der ASIL-konformen Lösung hingegen verbindlich ein. Das funktio-nale SiKo lässt sich so für Funktionen, die in jedem Fahrzeug vorhanden sind (beispielsweise Abblendlicht), jedoch immer wieder neu technisch umgesetzt werden, oftmals eins zu eins wie der-verwenden.

TECHNISCHES SICHERHEITSKONZEPT

Ein weiterer Nachteil der traditionellen Strukturierung – auch des technischen SiKos nach Sicherheitszielen – liegt darin, dass oft mehrere Komponenten an der Einhaltung eines Sicherheitsziels beteiligt sind. Zunächst ergeben sich daraus Wiederholungen, wenn für ver-schiedene Sicherheitsziele auf eine gemeinsame Maßnahme oder Argumen-tationsstruktur in einer Komponente zurückgegriffen wird. Besonders deut-lich wird dies an zentralen Komponenten wie dem Prozessor, der meist an allen Sicherheitszielen beteiligt ist.

Soll ausschließlich ein Teil des SiKos in ein neues Projekt übernommen wer-den, muss stets erneut analysiert wer-den, welche zusätzlichen Maßnahmen nötig sind, um das Sicherheitsziel zu erreichen.

Ein Vorgehen, das diese Nachteile ver-meidet und sich in zahlreichen Kunden-projekten bewährt hat, ist die Strukturie-rung des technischen SiKos anhand der technischen Architektur. Eine Struktur, die sich nach technischen Komponenten gliedert, zum Beispiel Analog-Digital-Wandler (ADC) oder Spannungsversor-gungen, bietet den Vorteil, dass diese Komponenten jeweils in einem separaten Kapitel umfassend abgehandelt werden. Alle Sicherheitsziele, deren Verletzung durch Maßnahmen in diesen Komponen-ten vermieden wird, verlinken auf diese Kapitel. Dadurch können einzelne Kapitel bei Wiederverwendung dieser Komponen-ten übernommen und – projekt bezogen – nur diejenigen Sicherheits ziele angepasst werden, die sich unterscheiden.

Bei Komponentenänderungen müssen zudem nur Anpassungen in einem Kapi-tel vorgenommen werden – und nicht im gesamten SiKo. Inkonsistenzen und ver-breitete Copy-and-Paste-Fehler lassen sich so vermeiden. Allerdings müssen zusätzlich zu den Anforderungen des SiKos auch die Voraussetzungen und Randbedingungen festgehalten werden, unter denen die Kapitel gültig sind. Der Autor kann nun bei der Wiederverwen-dung sofort nachvollziehen, ob Anpas-sungen im neuen Projektkontext nötig sind. Gerade bei Standardkomponenten, wie etwa einem ADC, sind die Auswir-kungen eines Fehlers kontextabhängig sehr unterschiedlich. So kann zum Bei-spiel von einem Sensor über den ADC

ein sicherheitsunkritischer Temperatur-wert aus dem Fahrzeuginnenraum einge-lesen werden, aber auch ein sicherheits-kritischer von der Speicherzelle einer Batterie.

ZUORDNUNG DER SICHERHEITS-MASSNAHMEN AUF FUNKTIONEN

Im Kontext der Ko-Allokation verschiede-ner Funktionen auf dasselbe Steuergerät ist bereits im Prozess der Systemarchi-tekturentwicklung eine klare Trennung der verschiedenen Funktionen zu emp-fehlen. Dies ermöglicht es, im SiKo die Subsystem-spezifischen Kapitel abge-schlossen und mit Blick auf die Wieder-verwendbarkeit maximal portabel zu halten. Durch die Strukturierung des technischen SiKos können Sicherheits-maßnahmen applikationsadäquat auf die verschiedenen Systemteile zugeordnet und wiederverwendet werden.

Ein Beispiel für die Wiederverwend-barkeit von Komponenten und Teilen von SiKos zeigt 2. Dort ist ein Regler, wie er beispielsweise für den Elektroantrieb eines Hybrid-Fahrzeugs eingesetzt wird, schematisch dargestellt. Viele der Kom-ponenten des E-Antriebs, wie die Strom-sensoren oder der Rotorpositionssensor, können aus früheren Projekten über-nommen werden. Maßnahmen, um defi-nierte Sicherheitsziele (zum Beispiel „Bei Überschreitung eines definierten Dreh-moments ist der Antrieb sicher drehmo-mentfrei zu schalten“) zu erreichen, beziehungsweise Fehlfunktionen einzel-ner Komponenten zu dokumentieren können ebenfalls in bestehenden SiKos definiert worden sein. Dadurch lassen sich diese Teile einschließlich der defi-nierten Maßnahmen in das neue SiKo übernehmen.

SICHERHEITSMECHANISMEN UND FEHLERMODI

In komplexen Systemen mit unterschied-lichen Fehlermodi gibt es jedoch meist nicht nur eine Maßnahme, die genau gegen exakt einen Fehlermodus wirkt und diesen komplett abdeckt. Es existie-ren Maßnahmen, die gegen mehrere Feh-ler wirken. Umgekehrt benötigen man-che Fehler mehr als eine Maßnahme. Eine echte Herausforderung, gerade bei der Wiederverwendung von Maßnah-men, liegt darin, den Überblick über die bereits abgedeckten beziehungsweise

ENTWICKLUNG FUNKTIONAlE SICHERHEIT

46

noch nicht vollständig abgedeckten Feh-lermodi sicherzustellen.

Zur Übersicht der Fehlermodi und zur Überprüfung, welche Fehlermodi von welchen Sicherheitsmechanismen abge-deckt werden, hat Berner & Mattner eine Matrixnotation eingeführt, die sich bereits in vielen Projekten bewährt hat. ➌ zeigt eine solche Matrix anhand des Beispiels „Rotor Position Integrity“. In der linken Spalte sind die unterschiedli-chen Fehlermodi der technischen Kom-ponenten untereinander, im oberen Bereich sind die entsprechenden Sicher-heitsmaßnahmen nebeneinander aufge-listet. Kreuze markieren, welche Maß-nahmen gegen welche Fehler wirken. So

kann der FuSi-Ingenieur auf einen Blick erkennen, welcher Sicherheitsmechanis-mus gegen welche Fehlermodi wirkt. Die Darstellungsform liefert eine gute Über-sicht über bereits erfolgreich abgedeckte Fehlermodi, aber auch über noch nicht ausreichend abgedeckte. Die Matrix unterstützt den Reviewer darin, die Grundidee der Absicherungen zu verste-hen und die Vollständigkeit der Abde-ckung aller Fehlermodi zu prüfen. Bei einer späteren Wiederverwendung in neuem Kontext, oder beim Austausch einer Komponente im System müssen die Spalten beziehungsweise Zeilen neu befüllt und der Abdeckungsnachweis wiederholt werden.

FAZIT

Mit einem gut strukturierten SiKo und einer strikten Trennung des funktionalen und technischen Teils sowie einer Struk-turierung anhand von technischen Kom-ponenten lassen sich die Anteile eines SiKos, welche systematisch und begrün-det wiederverwendet werden können, stark erhöhen. Um SiKos in andere Pro-jekte zu migrieren, sollten Standardlö-sungen in Katalogen gesammelt werden. Diese lassen sich für gleiche Funktionen in Folgeprojekten oder sogar für abwei-chende Funktionen mit ähnlichen Feh-lermechanismen wiederverwenden, was eine erheblich schnellere Erstellung und Begutachtung von SiKos ermöglicht. Dies erleichtert den Nachweis der Produktsi-cherheit im Rahmen des Safety Cases der ISO26262 und reduziert Aufwand und Ressourcen in der Entwicklung neuer Funktionen. Das Competence Center Safety & Systems Engineering von Ber-ner & Mattner bietet in diesem Umfeld dedizierte Expertise und engagiert sich beispielsweise im Forschungsprojekt SPES XT an der Weiterentwicklung des vorgestellten Ansatzes.

CurrentSensors

ADC

Safety Limit

Torque / Speed Actual

Calculation

Torque Monitoring

DO

Rotor Position Sensor

ADC

CANTransceiver

TorqueController

PWM Unit

TimerDrivers

Power Supply

CANController

Current Signal

PWM

EmergencyShut off

3 phaseMotor

Inverter Power StageRotor Position Signal

Torque / Speed Reference

µC with Software

M

Rotor Position IntegrityASIL C

Failure Mode

AS

IL

CP

ull-

Up

Ran

ge C

heck

C C C (...

)(.

..)

(...

)

(...

)

Cyc

lical

Sw

itch

to

Vref

C

Saf

ety

Mea

sure

Allocation

Signal Line Break Signal Conditioning

Signal Conditioning

Signal Conditioning

ADC

ADC

ADC

Short Circuit to GND

(...)

Hanging MUX

Pin stuck-at GND

(...)

X X

X

X

X

➌ Eine Matrixdarstellung erleichtert es, die Abdeckung zwischen Fehlermodi und Sicherheitsmechanismen zu visualisieren und zu prüfen

READ THE ENGLISH E-MAGAZINEorder your test issue now: springervieweg-service@springer.com

DOWNLOAD DES BEITRAGSwww.springerprofessional.de/ATZelektronik

➋ Schematische Darstellung eines Elektroantriebs; der sicherheits relevante Pfad der Sicherheitsanforderung ist in Gelb dargestellt

47 04I2014 9. Jahrgang