ENTWICKLUNGSSTANDARDS

elektronik-automotive.de28 Elektronik automotive Sonderausgabe Software 2018

Modellbasierte E/E-Entwicklung konform zu ISO 26262:

Fortschrittliche Systeme – aber sicher!

Elektrifizierung, Automatisierung und Fahrzeugvernetzung stellen höchste Anforderungen an die funktionale Sicherheit von Fahrzeugen.

Die elektronischen Systeme der neuen Fahrzeugfunktionen sind hochgradig vernetzt, was die Sicherheitsbetrachtung auf der Ebene

des Gesamtsystems erforderlich macht. Zudem müssen auf technolo­gischer Seite Trends wie Automotive Ethernet und AUTOSAR Adaptive

berücksichtigt werden. Modellbasierte Entwicklungsumgebungen unterstützen Ingenieure dabei, beide Herausforderungen zu meistern.

Von Dr. Nico Adler

Bei der Elektrik/Elektronik-Entwick-lung muss die funktionale Sicher-heit auf allen Ebenen betrachtet

werden. Dazu gehören das Architektur-Design, die Anforderungsanalyse, der Software- und Systementwurf, das

Kommunikationsdesign sowie die Ent-wicklung der Hardware-Komponenten und des Leitungssatzes (Bild 1). Gleich-zeitig ist die Wiederverwendung von Elektrik/Elektronik (E/E) in anderen Produktlinien und Ausstattungsvarian-

ten zu berücksichtigen. Mit Hilfe kon-sistenter E/E-Modelle lassen sich einer-seits die zahlreichen Optionen abbilden, die sich aufgrund dieser Freiheitgrade für die Entwicklung ergeben. Anderer-seits kann die Komplexität der Entwick-lung funktional sicherer E/E-Systeme beherrscht werden.

ISO 26262 – ein Standard mit Zukunft

Die Vorgaben für die Entwicklung si-cherheitsrelevanter E/E von Kraftfahr-zeugen sind im Standard ISO 26262 international festgelegt. Er wurde im Pkw-Segment etabliert und kommt bereits in den Bereichen Zweiräder, Lkw, Busse, landwirtschaftliche Maschi-nen und auch bei Halbleiterherstellern zum Einsatz. Er stellt nicht nur umfas-

(Bild: Vector Informatik)

ENTWICKLUNGSSTANDARDS

elektronik-automotive.de Elektronik automotive Sonderausgabe Software 2018 29

sende Anforderungen an die funktio-nale Sicherheit der Endprodukte, son-dern auch an die Methoden und Pro-zesse der Produktentwicklung sowie an das Management. Bei der Standar-disierung wurde auf bewährte Metho-den der Sicherheitsanalyse und auf vorhandene Industriestandards zurück-gegriffen. Aktuell wird eine Revision vorbereitet, die Erkenntnisse aus der Anwendung des Standards aufgreift und den Einsatzbereich ausweitet. Ein Werkzeug, mit dem sich die Vorgaben der ISO 26262 effizient umsetzen las-sen, ist PREEvision. Vector stellt damit eine modellbasierte Lösung bereit, mit der alle Ebenen der E/E-Architektur eines Fahrzeugs in einer eigens dafür entwickelten Beschreibungssprache konsistent Werkzeug-gestützt abge-bildet werden können. Mit ihr lässt sich die funktionale Sicherheit von E/E-Systemen und Komponenten analysie-ren und optimieren (Bild 2). Ausgehend von Anforderungen, die auf kunden-spezifische, erlebbare Fahrzeugfunk-tionen bezogen werden können, wird die logische Systemarchitektur entwor-fen. Auf dieser lässt sich die Software- und Hardware-Architektur inklusive der Netzwerktopologie aufbauen. Außer der Systemsicht stellt das Werk-zeug detaillierte Sichten auf die Schalt- und Stromlaufpläne sowie den Lei-tungssatz bereit. Ergänzend lassen sich die Layouts physikalischer Komponen-ten und Verbindungen sowie die Geo-metrie der Einbauräume im Fahrzeug hinterlegen. Ein Versions- und Ände-rungsmanagement unterstützt den Einsatz der Entwicklungsumgebung in Serienprojekten. Import- und Export-Schnittstellen, die zu relevanten Aus-tauschformaten konform sind, inte-grieren PREEvision in die vorhandene Werkzeuglandschaft und Umgebung des Kunden.

Funktionales Sicherheitskonzept

Als Startpunkt für eine systematische Identifizierung von Fehlfunktionen der Fahrzeugfunktionen lässt sich die qua-litative Analysemethode Hazard and Operability Study (HAZOP) einsetzen. Dazu werden Kundenfunktionen, An-forderungen oder logische Funktionen, die von der technischen Umsetzung in Software oder Hardware abstrahiert sind, herangezogen. Die HAZOP-Ergeb-nisse dienen als Basis für das „Hazard

Analysis and Risk Assessment“ (HARA), bei dem die Sicherheitsziele festgelegt werden.

Zum Festlegen der Gefährdungs-ereignisse (Hazardous Events) wird in PREEvision katalogbasiert sowohl auf Funktionen und zugehörige Fehlfunk-tionen als auch auf Betriebsmodi der Fahrzeugsysteme und Fahrsituationen zurückgegriffen. Durch Einstufen nach Schwere, Eintrittswahrscheinlichkeit und Beherrschbarkeit ergibt sich für jedes Gefährdungsereignis das Automotive Safety Integrity Level (ASIL). Auf dieser Grundlage werden die Sicherheitsziele mit zugehörigem ASIL festgelegt. Mit Hilfe Tabellen-basierter Editoren lassen sich ausgehend von den Sicherheitszie-len funktionale Sicherheitsanforderun-gen spezifizieren. Durch Prüfungen des Modells, die das Werkzeug kontinuier-lich im Hintergrund ausführt, werden Unzulässigkeiten wie invalide Dekom-positionen von Sicherheitsanforderun-gen unmittelbar zurückgemeldet. Auf der logischen Architekturebene dienen Wirkketten zur Beschreibung des funk-tionalen Sicherheitskon-zepts. Verwendet werden Sensor-, Aktuator und logi-sche Funktionsblöcke, deren Ports durch Schnittstellen-definitionen spezifiziert sind. Eine Hierarchisierung logi-scher Funktionen ist eben-falls möglich. Als Vorgehens-weise hat sich das Beschrei-ben und Umsetzen einer Wirkkette pro Sicherheitsziel bewährt. Die Sicherheitsan-forderungen lassen sich ein-fach mit den Objekten der logischen Ebene verknüpfen. So wird der Ingenieur bereits in der Konzeptphase in die Lage versetzt, die richtigen Maßnahmen zu treffen, um

die Sicherheitsziele mit den zugehöri-gen ASIL zu erfüllen.

Technisches Sicherheitskonzept

Nach ISO 26262 werden im Rahmen der Produktentwicklung auf Systemebene die funktionalen zu technischen Sicher-heitsanforderungen verfeinert und das Systemdesign sowie das technische Si-cherheitskonzept erarbeitet. Das Refe-renz-Phasenmodell für die Entwicklung eines sicherheitsbezogenen Fahrzeug-systems sieht danach eine Aufteilung in die Produktentwicklung von Hardware und Software vor, die im Rahmen der Integration wieder auf Systemebene angehoben wird. Diesem Ansatz folgend bildet PREEvision das technische Sicher-heitskonzept auf die Modellierungs-ebenen für Hardware und Software ab. Aus den technischen Sicherheitsan-forderungen entstehen dabei spezi-fische Hardware- und Software-Sicher-heitsanforderungen. Unterstützt durch Diagramme und Editoren lassen sich in PREEvision auf unterschiedlichen

Autosar Software und System

Anforderungen

Architektur

Leitungssatz Produktlinien

Änderungen Releases

Funktionale Sicherheit

Collaboration PlatformHardware-Komponenten

Kommunikation (Autosar etc.)

Testen

FunktionsgetriebenesDesign

Systemdesign

Bild 1. Funktionale Sicherheit ist ein integraler Bestandteil der E/E-Entwicklung. (Quelle: Vector Informatik)

AnforderungenPREEvision Ebenen

Kom

mun

ikatio

n

Hardware-Architektur

Leitungssatz

LogischeFunktionsarchitektur

Software-/Service-architektur

Sicherheits-anforderungen

FunktionalesSicherheitskonzept

TechnischesSicherheitskonzept

Sicherheits-analysen

Bild 2. Das funktionale und technische Sicherheitskonzept wird in PREEvision auf den Ebenen logische Funktionsarchi-tektur, Software-/Servicearchitektur und Hardware-Architek-tur abgebildet. Die Sicherheitsanforderungen können mit entsprechenden Komponenten auf diesen Ebenen verknüpft werden. Durch werkzeuggestützte Sicherheitsanalysen kann das Sicherheitskonzept iterativ verfeinert und mit den Anfor-derungen in Einklang gebracht werden. (Quelle: Vector Informatik)

ENTWICKLUNGSSTANDARDS

elektronik-automotive.de30 Elektronik automotive Sonderausgabe Software 2018

Detailgraden arbeiten. So ist es möglich, sowohl das Architekturdesign als auch das detaillierte Design von Hardware- und Software-Komponenten zu erstel-len. Dabei kommen Bibliotheken zum Einsatz, in denen die Ausfallrate und -arten für jedes Bauteil bereits hinterlegt sind. In ähnlicher Form können Sicher-heitsmechanismen mit den zugehörigenDiagnoseabdeckungsgraden integriert werden (Bild 3).

Sicherheitsanalysen

Zur Sicherheitsanalyse der Designs unterstützt PREEvision die induktiven Methoden Failure Mode and Effects Analysis (FMEA), Failure Mode, Effects and Diagnostic Analysis (FMEDA) und die deduktive Fault-Tree-Analysis-Me-thode (FTA). Zum Durchführen einer FMEA lassen sich Formblätter mit Hilfe geeigneter Editoren manuell ausfüllen. Alternativ dazu kann PREEvision Antei-le in einem FMEA-Formblatt auf Basis von Informationen aus dem Modell automatisch befüllen. Für die FTA kann der Anwender mit Hilfe von Diagram-men Fehlerbäume aufbauen und sie in Beziehung zu Sicherheitsanforderungen setzen. Das Ausführen einer qualitativen FTA ermittelt als Ergebnis Minimal-schnitte, die zum Eintreten des unter-suchten Hauptereignisses führen, zu-sammen mit den Wahrscheinlichkeiten für ihr Eintreten. Das bietet die Möglich-keit, die Designs gezielt zu verbessern. Zur Optimierung können im Diagramm

zusätzlich relevante Designelemente aus dem Modell angezeigt werden. Um zu prüfen, ob die Designs die geforder-ten Zielwerte erreichen, kann eine quantitative FTA durchgeführt werden. Wie Teilsysteme lassen sich in PREEvisi-on auch Fehlerbäume wiederverwen-den. Im Kontext von Systemvarianten können Fehlerbäume variantensensitiv analysiert werden. Die FMEDA ist insbe-sondere für Tier-1 von Bedeutung. In PREEvision kann hierzu die Hardware bis auf die Ebene elektronischer Schalt-pläne einer Komponente herunterge-brochen werden. Einzelne Bauteiltypen wie Mikrocontroller oder Widerstände werden in einer Bibliothek um Fehler-informationen angereichert (Bild 3). Nach dem Instanziieren dieser Bauteile im Schaltplan kann der Ingenieur die einzelnen Ausfallarten der Bauteile in Bezug auf Einzel-, Rest- oder Mehrfach-fehler einstufen. Darauf aufbauend lassen sich die geforderten Sicherheits-analysen Hardware Architec-tural Metrics und Failure Rate Class Method durchfüh-ren. Durch die Integration aller notwendigen Informa-tionen im PREEvision-Modell sind sowohl die Sicherheits-anforderungen, deren ASIL-Einstufung und die gefor-derten Zielwerte bekannt. Der Ingenieur erhält so eine direkte Rückmeldung da-rüber, ob diese erfüllt sind. Ein Ändern des Hardware-

Designs kann zielgerichtet erfolgen, zum Beispiel durch Einführung von weiteren Sicherheitsmechanismen oder die Verwendung ande-rer Bauteile aus der Biblio-thek.

Verifikation und Validierung

Zur Integration und zum Test auf Hardware-, Software- und Systemebene dient in PREEvision ein Testmanage-ment-Modul. Testspezifikati-onen können ausgehend von Anforderungen und Kunden-funktionen abgeleitet wer-den. Mit ihnen lassen sich die Tests entwerfen und imple-mentieren. Es ist möglich, Testaktivitäten zu planen

und die Ergebnisse der einzelnen Test-ausführungen – seien es manuelle Re-gressionstests oder automatisierte Tests – einzupflegen oder einzulesen. Die Er-gebnisse bereitet das Werkzeug in Form von Berichten und Diagrammen auf.

Zusammenarbeit zwischen Auto-mobilherstellern und -zulieferern

Durch ein Änderungsmanagement mit Ticketsystem können Änderungsanfra-gen und Defekte transparent verfolgt werden, indem sich Tickets mit Modell-elementen verknüpfen lassen. Zusätz-lich lassen sich kundenspezifische Le-benszyklen für Tickets festlegen. Ein integriertes Release-Management un-terstützt die Projektplanung und -ver-folgung. Darüber hinaus ist ein Review aller Modellanteile beispielsweise von Sicherheitsanforderungen möglich. Mit Hilfe einer Import-/Export-Schnittstelle, die das etablierte ReqIF-Austauschfor-

Bild 3. Sicherheitsanalysen für die Produktentwicklung auf Hardware-Ebene. (Bild: Vector Informatik)

Arbeitsprodukteauf Konsistenz prüfen

Aufgabenzur funktionalenSicherheit erledigen

Berichtzum Sicherheits-nachweis erzeugen

Sicherheits-plan

Sicher-heitsziele

HARA

DefinitionFahrzeug-

systemSSiSiSiSi hchchchererre ---

hheheeeitititi szszszieieieelleleeHHHHAHAAARAAAAARR

sysyysyststststemememem

Berichtzum Sicherheits-nachweis

Bild 4. Sicherheitsnachweis als inkrementelle Aktivität.

(Que

lle: V

ecto

r Inf

orm

atik)

elektronik-automotive.de

mat erweitert, kann gleichzeitig eine externe Abstimmung von Anforderun-gen zwischen OEM und mehreren Lie-feranten initiiert werden. Dieser Mecha-nismus unterstützt das in ISO 26262 erwähnte Development Interface Ag-reement für den Datenaustausch.

Iterativ zum Sicherheitsnachweis

Die von ISO 26262 geforderten Nach-weisdokumente können mit einer indi-viduell anpassbaren Reportgenerierung automatisch erstellt werden. In den Texten der Nachweisdokumente lassen sich Hyperlinks zum E/E-Modell hinter-legen. Das vereinfacht interne Reviews, Safety-Assessments und Audits. ISO 26262 empfiehlt, den Sicherheitsnach-weis nicht erst gegen Ende des Sicher-heitslebenszyklus anzugehen, sondern als inkrementelle Aktivität zu behan-deln. Mit PREEvision kann der Ingenieur Entwicklungsaufgaben im Rahmen der funktionalen Sicherheit deshalb iterativ bearbeiten. Während unterschiedlicher Entwicklungsphasen können Arbeits-produkte auf Konsistenz geprüft und ein Zwischenbericht zum Sicherheits-nachweis generiert werden. Diese Vorgehensweise führt am Schluss zum Sicherheitsnachweis, der belegt, dass alle Sicherheitsziele vollständig und erfüllt sind (Bild 4).

Modellbasierte Entwicklung

Modellbasierte Umgebungen bieten unterschiedliche Sichten auf die Fahr-zeug-E/E und stellen ein leistungsfähi-ges Mittel für die Entwicklung dar. Sie ermöglichen einen konsistenten Ent-wurf funktional sicherer Systeme und helfen Ingenieuren dabei, sich auf den Kern ihrer Arbeit zu fokussieren. Leis-tungsfähige Werkzeuge wie PREEvision bieten darüber hinaus eine Prozessun-terstützung, die sich an den Bedarf von OEM und Tier-1 anpassen lässt. Eine Nachverfolgbarkeit von der Anforde-rungsspezifikation bis hin zum Sicher-heitsnachweis ist durch den integrierten Ansatz gegeben. eck

Dr. Nico Adlerarbeitet als Produktmanager „PREEvision Funktionale Sicher-heit“ bei Vector Informatik.