Systementwurf unter Einbeziehung funktionaler Sicherheit bei automobilen Steuergeräten

Transkript

1 Systementwurf unter Einbeziehung funktionaler Sicherheit bei automobilen Steuergeräten Jan Meyer 1, Markus Fockel 2, Jörg Holtmann 2 1 HELLA KGaA Hueck & Co., PMT, Beckumerstr. 130, Lippstadt, jan.meyer@hella.com 2 Projektgruppe Entwurfstechnik Mechatronik, Fraunhofer IPT, Zukunftsmeile 1, Paderborn, { markus.fockel joerg.holtmann }@ipt.fraunhofer.de Zusammenfassung: Automobile Steuergeräte realisieren mehr und mehr sicherheitskritische Funktionen. Nicht erst durch die Einführung der ISO werden an die Entwicklung sicherheitskritischer Funktionen besondere Anforderungen zum Beispiel in Form von Sicherheitsanalysen gestellt. In der Praxis hat sich herausgestellt, dass durch den bisherigen Systementwurf nicht alle notwendigen Daten für die Sicherheitsanalysen vorlagen. Von daher war eine Erweiterung des bisherigen Vorgehens erforderlich, sodass die benötigten Daten zu den erforderlichen Zeitpunkten vorliegen und die Sicherheitsanalysen ohne aufwendige Nacharbeiten erstellt werden können. Dieser Artikel beschreibt die durchgeführten Erweiterungen und die Erfahrungen, die in Serienprojekten eines automobilen Zulieferers gesammelt wurden. 1 Motivation In Automobilen werden die jeweiligen Funktionen durch Steuergeräte (ECUs) umgesetzt. In den letzten Jahren ist ein Trend zu erkennen, dass immer mehr sicherheitskritische Funktionen durch einzelne Steuergeräte oder zusammen in einem Verbund ausgeführt werden. Damit im Betrieb keine Unfälle aufgrund fehlerhafter Steuergeräte entstehen, sind die notwendigen Schritte bei der Entwicklung im internationalen Standard ISO [ISO11] zusammengefasst worden. In dieser Norm ist festgelegt, welche Maßnahmen bei der Entwicklung für welche Sicherheitseinstufung eingesetzt werden müssen. Beispielsweise ist es bereits für einfache sicherheitskritische Systeme zwingend erforderlich, den Systementwurf in einer semi-formalen Notation vorzunehmen. Eine deswegen im Systementwurf häufig verwendete Modellierungssprache ist die Systems Modeling Language (SysML) [OMG10]. Dies ist aber nur eine Modellierungssprache und gibt noch nicht vor, welche Inhalte in welcher Form modelliert werden. Deswegen ist immer eine begleitende Methodik notwendig. Die bisherige Methodik bei der HELLA KGaA Hueck & Co. sah einen zweiteiligen Systementwurf vor. Auf der einen Seite eine lösungsneutrale funktionale Beschreibung des Systems in Form einer funktionalen Architektur und auf der anderen Seite die technische Lösung in Form einer technischen Architektur. In diesem Papier beschreiben wir diesen Systementwurf anhand der Bremsfunktionalität eines Komfortsteuergerätes. Copyright 2015 Jan Meyer, zur Veröffentlichung und Nutzung durch GfSE und die mit ihr verbundenen Organisationen freigegeben 1

2 Bei den notwendigen Sicherheitsanalysen für die sicherheitskritischen Bereiche hat sich in der Praxis herausgestellt, dass einige wesentliche Daten fehlten und diese mussten anschließend unter großem Aufwand nachgearbeitet werden. Bezüglich der verwendeten Methodik macht die ISO keine konkreten Vorgaben. Damit dieser Mehraufwand nicht in weiteren nachfolgenden Projekten auftritt, wurde der Systementwurf entsprechend ergänzt. In den weiteren Kapiteln dieses Papiers werden die neu hinzugefügten Ansätze und Regeln beschrieben, die dafür sorgen, dass aus dem Systementwurf heraus die Sicherheitsanalysen durchgeführt werden können. Als Ergebnis ist ein durchgängiger Systementwurf unter Berücksichtigung der funktionalen Sicherheit entstanden. 2 Beispiel aus dem Komfortbereich Zur besseren Darstellung werden in diesem Papier vereinfachte Darstellungen des Systementwurfs eines Komfortsteuersystems gezeigt. Hierbei verwenden wir nur einen kleinen Teil der Funktionalität eines Komfortsteuergerätes, nämlich die Ansteuerung des Bremslichts. Hierbei ist beispielsweise zwischen einem normalen Bremsen und einem Notfallbremsen zu unterscheiden. Bild 1 zeigt die Systemstruktur, die Anwendungsfälle und die Aktivitäten der Bremslichtsteuerung. Im zentralen Mittelpunkt steht das Komfortsteuergerät, welches die Steuerung des Bremslichts übernimmt. Als Eingabe dienen sowohl das Bremspedal des Fahrers oder aber vermehrt Fahrerassistenzsysteme, wie beispielsweise ACC Adaptive Cruise Control (ACC) Systeme, die eine automatische Bremsung bzw. Notbremsung auslösen können. Das Komfortsteuergerät liest die eingehenden Daten vom CAN-Bus und verarbeitet sie. Dabei wird in einer Priorisierung sichergestellt, dass wenn Signale für Bremsung und Notbremsung vorhanden sind, immer das Signal mit der höchsten Priorität, in diesem Fall der Notbremsung, ausgeführt wird. Zur Funktionalität des Komfortsteuergerätes gehören die drei Anwendungsfälle Zeige Bremsung an, Zeige Notfallbremsung an und Steuere Bremslicht, wobei letzterer durch ein Aktivitätsdiagramm weiter verfeinert ist. Die Funktionen (Anwendungsfälle und deren Verfeinerung in Aktionen) sind dabei dem Komfortsteuergerät zugewiesen (siehe blauen Block mit Stereotyp «Block» in Bild 1. Die Pfeile (Datenflüsse) zu den grünen Blöcken (externe Systeme mit Stereotyp «ExtBlock») beschreiben den Datenfluss von und zu den externen Geräten bzw. Aktoren. 2

3 Bild 1: Anwendungsfälle, Aktivitäten und Systemstruktur der Bremssteuerung. 3 Systementwurf unter Einbeziehung der funktionalen Sicherheit Für die Einordnung des hier beschriebenen Vorgehens beim Systementwurf ist es wichtig, die Charakteristika der Automobilbranche zu verstehen. Ein wesentliches Merkmal ist die Aufteilung in Automobilhersteller (OEM) und Zulieferer. Ein Großteil der Entwicklungsarbeit findet derzeit beim Zulieferer statt [WFO09]. Dieser ist für die Entwicklung und Produktion der Steuergeräte verantwortlich. Diese werden dann beim OEM zum Fahrzeug zusammengebaut. Bei der Steuergeräteentwicklung werden immer mehr sicherheitskritische Funktionen realisiert. Für die Entwicklung solcher sicherheitskritischer Funktionen ist die neue ISO anzuwenden. Diese besagt unter anderem, dass für sicherheitskritische Systeme eine (semi-) formale Notation genutzt werden muss, um Konsistenz und Eindeutigkeit be der Entwicklung zu gewährleisten. Von daher wird bei der HELLA KGaA Hueck & Co. die Systems Modeling Language (SysML) eingesetzt (siehe Bild 1). Zusätzlich zu der Modellierung des Systems werden für sicherheitskritische Systeme in der ISO Analysen für die sicherheitskritischen Funktionen spezifiziert. Je nach Sicherheitseinstufung werden dabei unterschiedliche Methoden und auch Kombinationen von Analysen vorgegeben. Die Sicherheitseinstufungen reichen dabei von nicht sicherheitskritisch (QM) bis hin zur höchsten Einstufung (ASIL D), wobei die Bremslichtsteuerung die Sicherheitseinstufung ASIL B aufweist. Bei den Sicherheitsanalysen geht es um die Erkennung von Fehlfunktionen, die zu einem Unfall oder einer Gefährdung führen. Aus den Fehlfunktionen werden Sicherheitsziele abgeleitet, die dafür sorgen, dass die analysierten Fehlfunktionen gar nicht erst eintreten. Für die Erreichung der Sicherheitsziele werden Anforderungen abgeleitet, die in einem Copyright 2015 Jan Meyer, zur Veröffentlichung und Nutzung durch GfSE und die mit ihr verbundenen Organisationen freigegeben 3

4 funktionalen und technischen Sicherheitskonzept abgelegt werden. Die Anforderungen werden anschließend im Systementwurf umgesetzt. Die Einarbeitung der Sicherheitsanforderungen erfolgt iterativ und in mehreren Schleifen im Entwicklungsprozess (siehe Bild 2). Es beginnt mit einer ersten Architektur. Diese wird auf die Sicherheitsziele und deren Anforderungen hin analysiert. Dabei werden die Stellen identifiziert, die sicherheitskritisch sind und dementsprechend abgesichert werden müssen. Dies kann beispielsweise durch eine redundante Auslegung oder einer Diagnosefunktion erfolgen. In der Architektur wird dieses umgesetzt und dann wieder analysiert, ob die Sicherheitsziele erfüllt sind. Es ist somit ein iteratives Verfahren, das zu zahlreichen Schleifen führt. In Bild 3 ist dieses schematisch dargestellt. Zu Beginn steht der erste Architekturentwurf, der so angepasst wird, dass die Sicherheitsziele erfüllt sind. Bild 2: Iteratives Vorgehen zwischen Anforderungen, Architektur und Sicherheitsanalysen Damit diese Iteration möglichst früh in der Entwicklung eines automobilen Steuergerätes erfolgen kann, muss der Systementwurf bestimmte Artefakte möglichst frühzeitig liefern. Hierzu ist zunächst die bisherige Entwicklung eines automobilen Steuergerätes zu betrachten. Das System ist in zwei Bereiche geteilt, wie es bei gängigen Methoden wie FAS [LW10] oder CONSENS [DDG+14] üblich ist. Zum einen gibt es die funktionale Architektur, und zum anderen die technische Architektur (siehe Bild 3). Die funktionale Architektur beschreibt die Funktionalität des Systems und die Datenflüsse zwischen den einzelnen Funktionen. Die Funktionen werden dabei möglichst lösungsneutral beschrieben. Die Funktionen werden immer weiter verfeinert, bis eine Lösung für eine Funktion zur Verfügung steht. Es entsteht durch die Verfeinerung eine Funktionshierarchie. Wegen der lösungsneutralen Beschreibung ist die funktionale Architektur weitestgehend stabil, da die Funktionen sich im Laufe der Zeit nicht ändern, nur deren technische Umsetzung. Diese Beschreibung wird dazu verwendet, eine technische Lösung für das System zu finden. 4

5 Bild 3: Abbildung der funktionalen und technischen Architektur auf ein V-Modell nach Automotive SPICE [VDA10] Die technische Umsetzung des Systems wird in der sogenannten technischen Architektur spezifiziert. In der technischen Architektur wird zunächst die logische Sicht beschrieben. Diese wird soweit verfeinert, bis sie einer Disziplin zugeordnet werden kann. Dabei kann es vorkommen, dass sie bereits physikalische Elemente definiert, damit die Hardware/Software Schnittstellen definiert sind. Neben der Realisierung des Systems und dessen Bestandteile gehört zu der technischen Architektur die Abbildung der Funktionen auf die einzelnen technischen Systeme. In Bild 4 ist die Abbildung der Funktionshierarchie auf die technische Hierarchie dargestellt. Dabei existiert keine 1:1 Kopie, da die beiden Bäume unterschiedlich aufgebaut sind, denn die funktionale Architektur ist weitestgehend unabhängig von Lösungen. Es macht daher keinen Sinn, nachdem Lösungen identifiziert sind, die funktionale Architektur weiter zu untergliedern, wenn ein technischer Block nur einen Teil der Funktion realisiert, denn dann geht diese Information für die Zukunft verloren. Zukünftig kann es nämlich eine Lösung geben, die die Funktion komplett erfüllt. Diese Lösung wird aber nicht ausgewählt, wenn die funktionale Architektur der technischen angepasst ist. Bild 4: Verknüpfung von funktionaler und technischer Architektur Copyright 2015 Jan Meyer, zur Veröffentlichung und Nutzung durch GfSE und die mit ihr verbundenen Organisationen freigegeben 5

6 Für die Erstellung der Sicherheitsziele und deren Anforderungen sind aber Informationen des Fahrzeugs oder deren Umgebung notwendig und nicht nur Informationen des Systems. Beispielsweise ist das Warnen des Verkehrs für das Komfortsteuergerät von Interesse. Jedoch taucht der übrige Verkehr nicht im Kontextmenü des Systems auf, sondern nur im Kontextmenü des Fahrzeugs. Diese Informationen sind daher nur dem OEM bekannt. Von daher ist es Aufgabe des OEMs die Sicherheitsanalysen durchzuführen und sie an den Zulieferer weiterzugeben. Jedoch werden in vielen Projekten unvollständige Analysedaten an den Zulieferer weitergegeben. Dieser muss dann anhand von Annahmen selber die Analysen erstellen, um sie dann anschließend mit dem OEM zu diskutieren. Dies Vorgehen ist ebenso bei der Plattformentwicklung anzuwenden, da bei dieser die Entwicklung ohne einen konkreten Kunden beginnt. Die Zulieferer entwickeln ihre Steuergeräte immer mehr in Plattformen, um eine systematische Wiederverwendung und damit eine Kostenreduzierung zu erreichen. Da es hierbei natürlich zunächst keinen Kunden gibt, müssen Annahmen über das Fahrzeug getroffen werden, um daraus die Sicherheitsziele und anforderungen abzuleiten. Diese werden bei einem erteilten Auftrag dann mit dem OEM abgeglichen und bei nicht zutreffenden Annahmen werden diese überarbeitet. 3.1 Einführung der Fahrzeugebene Der Systementwurf für ein automobiles Steuergerät sieht bisher keine Fahrzeugebene vor, da dieses für die Entwicklung an sich nicht benötigt wird. Es ist nur der Systemkontext definiert, damit die Ein- und Ausgabedaten und deren Kommunikationsmedien wie Kommunikationsbusse bekannt sind. Von daher muss eine geeignete Modellierung für die Fahrzeugebene definiert werden. Diese muss dabei die folgenden Informationen beinhalten: den Fahrzeugkontext, die Fahrzeugzustände und die Fahrzeugfunktionen. Hierzu wurde auf der Modellebene ein eigenes Paket Fahrzeugebene erstellt. Der Fahrzeugkontext wird mittels von Blockdefinitionsdiagrammen dargestellt, vergleichbar mit dem Systemkontext in Bild 2. Es zeigt die anderen Verkehrsteilnehmer und die Daten, die von ihnen kommen. Für die Fahrzeugzustände wird unterhalb des Blocks Fahrzeug ein Zustandsdiagramm erstellt. Damit eine Unterscheidung zu den Systemzuständen erfolgen kann, ist das Zustandsdiagramm mit dem neuen Stereotyp «VehicleStatechart» gekennzeichnet. Dies Vorgehen ist ebenfalls bei den Fahrzeugfunktionen zu sehen. Diese werden mittels Anwendungsfalldiagramme mit dem Stereotyp «VehicleUseCase» und einer weiteren Verfeinerung in Aktivitätsdiagrammen dargestellt. In diesem Fall ist die Funktion Sicherheit beim Unfall realisiert (siehe Bild 5). 6

7 Bild 5: Vorgenommene Ergänzungen für die Fahrzeugebene 3.2 Definition der Nachverfolgbarkeit Neben der Einführung der Fahrzeugebene ist die Nachverfolgbarkeit ein weiterer wichtiger Baustein für die Sicherheitsanalysen und deren Ableitung aus dem Systementwurf. So werden für die Fault Tree Analysis (FTA) und die Failure Modes and Effects Analysis (FMEA) die Funktionshierarchie und die Abbildung auf die technische Architektur genutzt, um die Analysen durchzuführen. Von daher ist es wichtig, eine Abbildung von den Funktionen auf die technische Architektur zu bekommen. Diese kann aber nicht beliebig erfolgen, da ansonsten nicht sichergestellt ist, dass zu jeder Komponente die zugehörige Funktion bekannt ist. In Bild 6 sind die drei verschiedenen Möglichkeiten dargestellt. Bei einer 1:1 Abbildung besteht kein Problem, da ersichtlich ist, welche Funktion die Komponente erfüllt. Ebenso verhält es sich bei einer n:1 Abbildung, d.h. n Funktionen werden innerhalb einer Komponente realisiert. Auch hier ist ersichtlich, welche Funktion die Komponente erfüllt. Anders sieht es bei einer 1:n Abbildung aus, d.h. eine Funktion wird auf zwei technische Komponenten aufgeteilt. Es ist aus dieser Abbildung aber nicht ersichtlich, welcher Teil der Funktion in welcher Komponente realisiert wird. Dadurch ist keine nutzbare Abbildung gegeben und es ist daher nicht möglich, eine Sicherheitsanalyse durchzuführen. Damit aber weiterhin eine Analyse durchgeführt werden kann, sind zwei Alternativen möglich. Auf der einen Seite kann die funktionale Architektur verfeinert werden, so dass die Funktion in weitere Funktionen aufgeteilt wird und diese dann den technischen Komponenten zugewiesen wird. Der Nachteil bei dieser Alternative ist, dass die funktionale Architektur dann genau den Inhalten der technischen Architektur entspricht. Von daher ist sie nicht mehr lösungsunabhängig. Dies behindert die Suche nach neuen Lösungen in neuen Generationen des zu entwickelnden Systems. Aus diesem Grund ist die zweite Alternative für den hier beschriebenen Systementwurf verwendet worden. Copyright 2015 Jan Meyer, zur Veröffentlichung und Nutzung durch GfSE und die mit ihr verbundenen Organisationen freigegeben 7

8 Bild 6: Übersicht über die verschiedenen Abbildungsformen zwischen funktionaler und technischer Architektur Diese sieht wie folgt aus. Die 1:n Abbildung ist nicht mehr erlaubt. Vielmehr wird eine logische Komponente Komfortsteuergerät eingeführt, die in die weiteren Komponenten Datenverarbeitung und Priorisierung aufgeteilt wird. Dabei wird in einem Aktivitätsdiagramm die Funktion auf die internen Komponenten aufgeteilt (s. rechter Teil der 1:n Abbildung in Bild 6). Die Aufteilung erfolgt mittels Swimlanes im Aktivitätsdiagramm, d.h. die Funktion Lese und verarbeite Daten wird der internen Komponente Datenverarbeitung und die Funktion Ermittle höchste Priorität der internen Komponente Priorisierung zugeordnet. Der Vorteil bei diesem Vorgehen ist, dass die Aufteilung der Funktionen auf die Komponenten eindeutig beschrieben ist. Weiterhin gibt es keine Rückwirkungen von der technischen auf die funktionale Architektur, sodass der Lösungsraum nicht weiter eingeschränkt wird. Die Anforderungen der Sicherheitsanalyse bleiben dabei weiterhin erfüllt. 4 Verwandte Arbeiten Für den Systementwurf existieren auf SysML-Basis z.b. die etablierten Methoden FAS [LW10] und CONSENS [DDG+14]. In FAS werden Funktionen sowie die technische Architektur in zwei verschiedenen Sichten jeweils als Strukturelemente in einem Blockdiagramm hierarchisch modelliert, die über Ports Informationen austauschen. In CONSENS wird u.a. eine Funktionshierarchie spezifiziert, deren Blattelemente auf Systemelemente der technischen Architektur ( Wirkstruktur ) allokiert werden. Beide Methoden sind allgemein auf mechatronische Systeme ausgerichtet und nicht speziell auf den Automobilbereich fokussiert. Deshalb beinhalten sie keine explizite Betrachtung 8

9 einer Fahrzeugebene. Außerdem beinhalten sie keine explizite Modellierungs- oder Prozessunterstützung für Sicherheitsanalysen. Dieser Beitrag kann daher als Erweiterung beider Methoden bzgl. Safety verstanden werden. Speziell für den Automobilbereich wurde die EAST-ADL entwickelt [EAST13]. Sie enthält die Architekturschichten Vehicle Level, Analysis Level, Design Level und Implementation Level. Auf dem Vehicle Level werden Features des Fahrzeugs spezifiziert. Im Analysis Level werden Analysefunktionen in einer Functional Analysis Architecture beschrieben. Diese ist vergleichbar mit der hier vorgestellten funktionalen Architektur. Im Design Level wird die Systemarchitektur inkl. Allokation auf Hardwarekomponenten beschrieben, was der hier vorgestellten technischen Architektur entspricht. Der Implementation Level beschreibt die Softwarekomponenten. Die EAST- ADL dient zur Beschreibung von automobilen Steuergeräten mit starkem Blickwinkel auf die Softwareentwicklung. Der Vehicle Level der EAST-ADL ist auf die Modellierung extern sichtbarer Features ausgerichtet. Verhaltensbeschreibungen wie Use-Cases oder Aktivitäten sind kein Bestandteil. Die EAST-ADL bietet auch Sprachelemente, um Fehlerpropagierungen durch die Architektur zu beschreiben. Diese Informationen können durch externe Safety-Analysewerkzeuge ausgenutzt werden [CJLP+08]. Ein methodisches Vorgehen, wie Elemente der funktionalen Architektur aus Safety-Gesichtspunkten auf den Design Level allokiert werden sollten, ist nicht spezifiziert. Eine weitere Möglichkeit für Sicherheitsanalysen im Systementwurf sind Component- Integrated Component Fault Trees [HTZL12]. Hier wurde ein Profil entwickelt, um Fehlerbäume (sog. Component Fault Trees) in SysML-Modellen spezifizieren zu können. So kann die Fehlerpropagierung durch die Systemarchitektur nachvollzogen werden. Für automatische Analysen können diese Informationen in ein externes FTA- Werkzeug automatisch übertragen werden [ADH+10]. Eine explizite Aufteilung des Systems in funktionale und technische Aspekte wird allerdings nicht festgelegt. 5 Zusammenfassung & Ausblick In diesem Papier werden die Erfahrungen und vorgenommenen Erweiterungen bei dem Systementwurf vor allem von sicherheitskritischen automobilen Steuergeräten beim Automobilzulieferer HELLA KGaA Hueck & Co. dargestellt. Auf Grund der Trennung in Zulieferer und OEM und der dennoch benötigten Daten wurde eine Fahrzeugebene in den Systementwurf eingeführt und die Festlegung, wie lösungsneutrale Funktionen auf ihre technischen Realisierungen abgebildet werden, definiert. Durch diese Erweiterungen ist es möglich, die Inhalte des Systementwurfs einfacher bei den Sicherheitsanalysen wieder zu verwenden. Bei der Erprobung in Serienprojekten hat sich herausgestellt, dass durch die vorgenommenen Ergänzungen im Systementwurf aufwendige Nacharbeiten vermieden wurden. Dies führte zu einer Zeit- und Kostenersparnis und darüber hinaus zur Einhaltung des Projektplans. Die hier vorgestellten Ergebnisse sind die Basis für weitere Arbeiten. Die Nutzung der Daten aus dem Systementwurf ist klar definiert. Jedoch werden die Daten derzeit oftmals Copyright 2015 Jan Meyer, zur Veröffentlichung und Nutzung durch GfSE und die mit ihr verbundenen Organisationen freigegeben 9

10 noch manuell in verschiedene Werkzeuge übertragen. Hier ist auf Basis der vorgenommen Erweiterungen im Systementwurf in naher Zukunft eine werkzeugbasierte Unterstützung, in Form von entsprechenden Transformationen, angestrebt. Dies hat besonders bei Änderungen innerhalb des Systementwurfs Vorteile, denn die geänderten Daten werden automatisiert in die Sicherheitsanalyse übernommen und der Safetymanager kann zeitnah die Änderungen in den Analysen erkennen und die Sicherheitsanforderungen entsprechend anpassen. Neben der Transformation zwischen den Werkzeugen ist noch eine weitere Ergänzung zur besseren Entwicklung von sicherheitskritischen Systemen geplant. Für die Umsetzung der Sicherheitsanforderungen gibt es bestimmte Lösungen. Zum Beispiel in Form von Diagnosefunktionen, Redundanz oder zusätzlichen Absicherungen. Diese können in Form von Mustern für den Systementwurf in der SysML als Bibliothek aufbereitet und für den Systementwurf genutzt werden. Hierdurch wird die Modellierung bei der Realisierung von Sicherheitsanforderungen standardisiert und vereinfacht. Danksagung: Dieser Beitrag wird teilweise mit Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) im Rahmen des Spitzenclusters "Intelligente Technische Systeme OstWestfalenLippe (it s OWL)" gefördert und vom Projektträger Karlsruhe (PTKA) betreut. Literaturverzeichnis [ADH+10] Adler, R.; Domis, D.; Höfig, K.; Kemmann, S.; Kuhn, T.; Schwinn, J.-P.; Trapp, M.: Integration of component fault trees into the UML. In: Proceedings of 3 rd Int. Workshop on Non-functional Properties in Domain Specific Languages, [CJLP+08] Chen, D.; Johansson R.; Lönn, H.; Papadopoulos, Y.; Sandberg, A.; Törner, F.; Törngren, M.: Modelling Support for Design of Safety-Critical Automotive Embedded Systems. In: SAFECOMP 2008, LNCS 5219:72-85, Springer, [DDG+14] Dorociak, R.; Dumitrescu, R.; Gausemeier, J.; Iwanek, P.: Specification Technique CONSENS for the Description of Self-optimizing Systems. In: Gausemeier, J.; Rammig, F.; Schäfer, W. (Hrsg.): Design Methodology for Intelligent Technical Systems. Springer, [EAST13] EAST-ADL Association: EAST-ADL Specification V [HTZL12] Höfig, K.; Trapp, M.; Zimmer, B.; Liggesmeyer, P.: Modeling Quality Aspects: Safety. In: Pohl, K. (Hrsg.); Hönninger, H. (Hrsg.); Achatz, R. (Hrsg.); Broy, M. (Hrsg.): Model-Based Engineering of Embedded Systems The SPES 2020 Methodology. Springer, [ISO11] International Organization for Standards: ISO Road Vehicles Functional Safety, [LW10] Lamm, J. G.; Weilkiens, T.: Funktionale Architekturen in SysML. In: Tag des Systems Engineering Hanser, [OMG12] Object Management Group (OMG): OMG Systems Modeling Language (OMG SysML). Version 1.3, OMG Document Number: formal/ [VDA10] Verband der Automobilindustrie (VDA): Automotive SPICE, [WFO09] Wallentowitz, H.; Freialdenhoven, A.; Olschewski, I.: Strategien in der Automobilindustrie, Vieweg + Teubner,