Um die Erfassung der Systemanforderungen (SysRS) zu erleichtern, werden die im Systems Engineering (SE) verbreiteten Methoden wie beispielsweise eine Stakeholder-Analyse, Untersuchungen aller System-Interfaces und die Identifikation der verschiedenen Funktionsabläufe des Systems durchgeführt. Basierend auf diesen Anforderungen wird eine Systemarchitektur entworfen, bei der die Anforderungen, Funktionen und Schnittstellen der Subsysteme (SubSysRS) erfasst, also spezifiziert werden. Diese Subsysteme werden dann – analog zum Gesamtsystem – als eigene Systeme aufgefasst, die einzeln weiter analysiert, heruntergebrochen und spezifiziert werden.
Mit einer solchen rekursiven Vorgehensweise wird die Komplexität des Gesamtsystemes soweit zerlegt, bis überschaubare Subsysteme oder Komponenten entstanden sind. Falls wirklich alle Anforderungen erfasst, verstanden und korrekt umgesetzt worden sind, sollten in der Systemintegration, also beim Zusammenfügen der Komponenten und Subsysteme, keinerlei Schwierigkeiten auftreten und alle Tests bestanden werden. Wie so oft zeigt allerdings die Realität, dass etwa der Zeitdruck und damit die Parallelisierung von Aktivitäten dazu führt, dass die Entwicklung basierend auf Annahmen beginnen muss. Dennoch bleibt die möglichst vollständige und widerspruchsfreie Erfassung der Anforderungen der am wenigsten riskante Weg zur erfolgreichen Systementwicklung.
Übersicht über die Safetyanalyse
Was passiert nun, wenn eine zusätzliche Sichtweise auf das Projekt hinzugefügt wird, beispielsweise weil für ein System im Automotive-Bereich festgestellt wird, dass zumindest eine der benötigten Funktionen Safety-kritisch ist? In diesem Fall kommt ein weiterer Standard ins Spiel, die ISO 26262, der Safety-Standard der in der Automobilindustrie für elektrische/elektronische Systeme verwendet wird. Das führt aber auch zu möglichen neuen Anforderungen an den Entwicklungsprozess. Die Frage lautet dann: Inwieweit lassen sich diese Safety-Prozess-Anforderungen berücksichtigen und lässt sich mit der oben beschriebenen Vorgehensweise das Entwicklungsrisiko minimieren? Um dies zu untersuchen, wollen wir die Vorgehensweise kurz beschreiben, um sie dann mit dem Systems-Engineering-Prozess zu vergleichen und später zu vereinigen.
Zunächst ist eine Definition des ‚Items‘ erforderlich. Dieses beschreibt die auf Fahrzeugebene umzusetzende Funktion sowie das verantwortliche System oder den verantwortlichen Verbund von Systemen. Für dieses Item wird dann eine Hazard- und Risk-Analyse (HARA) durchgeführt, bei der die möglichen Fehlfunktionen und ihre Auswirkungen in verschiedenen Szenarien, unter anderem Fahrsituationen, untersucht werden. Als Ergebnis werden Sicherheitsziele (Safety goals) festgelegt und mit dem sich daraus ergebenden Automotive Safety Integrity Level (ASIL) klassifiziert. Im nachfolgenden Functional-Safety-Concept werden diese Sicherheitsziele zu Safety Requirements für die beteiligten Elemente der vorläufigen Fahrzeugarchitektur umgearbeitet. Diese Safety-Anforderungen sollten immer noch implementationsunabhängig beschrieben sein. Erst im nächsten Schritt, dem Technical Safety Concept, werden detaillierte Safety-Anforderungen an die Systemelemente erstellt. Hierbei ist es empfehlenswert, jedem Systemelement ein eigenes Technical Safety Concept (oder zumindest ein Kapitel) zuzuweisen, da diese Elemente in den weiteren Entwicklungsschritten unabhängig behandelt werden. Gemäß ISO 26262 kann nun der Aufbruch in Hardware- und Software-Safety-Anforderungen erfolgen, da die Systemanforderungen für Safety jetzt identifiziert und den Architekturelementen zugewiesen sind.
Synthese von SE- und Safetyprozess
Soweit sehen sich der linke Teil des V-Modells für den üblichen SE-Entwicklungsprozess und der des Prozesses gemäß ISO 26262 sehr ähnlich. Erst beim zweiten Hinsehen fällt auf, dass die beiden Prozesse eine unterschiedliche Anzahl von Ebenen enthalten, was eine Synchronisierung der Prozesse erschwert. Dabei stellt sich die Frage, ob es eine Vorgehensweise gibt, die eine solche Synchronisierung ermöglicht – und damit die Vermeidung von Reibungsverlusten in der Entwicklung.
Im Folgenden wird ein Vorschlag für eine solche Synchronisierung vorgestellt. Dabei ist interessant zu beobachten, dass die beiden Prozesse tatsächlich nebeneinander laufen können und sich gegenseitig unterstützen: Zunächst wird klassisch die Spezifikation der Funktion auf Fahrzeugebene begonnen. Parallel dazu kann bereits mit der Hazard- und Risk-Analyse begonnen werden, da sie lediglich die Funktionen und ihre Fehlfunktionen auf Fahrzeugebene bewertet. Diese notwendige Information steht typischerweise schon zu Projektbeginn in ausreichender Detailtiefe zur Verfügung. Der nächste Schritt ist dann eine Fahrzeugarchitektur für die Funktion, bei der die großen Bausteine identifiziert und ihre Aufgaben und Schnittstellen definiert werden. Mit dieser Architektur kann dann bereits das Functional Safety Concept (FSC) erstellt werden, da sowohl die Bausteine als auch ihre Aufgaben bekannt sind. Es folgt die Verfeinerung der Fahrzeugarchitektur. Dabei helfen die Safety-Requirements aus dem FSC dabei, die erforderlichen Teilfunktionen vollständig zu erfassen. Durch ihre Herleitung aus den Safety Goals der HARA sichern sie die Funktion ab, andererseits sind sie konform mit der restlichen Fahrzeugarchitektur, da sie eine Verbindung dorthin haben. Damit erhalten wir eine Fahrzeugarchitektur die sowohl den Safety-Anforderungen als auch funktionalen Anforderungen entspricht.
Die nächsten Schritte finden im Rahmen der Systementwicklung eines Fahrzeug-Teilsystems statt. Der Safety-Ingenieur leitet aus dem FSC unter Berücksichtigung der Architekturkonzepte des eigenen System-of-Interest (SoI) das Technical Safety Concept (TSC) ab. Die anschließend entstehenden Systemanforderungen (SysReq) berücksichtigen hierbei nicht nur die vertraglich festgelegten Kundenanforderungen an das Sol, sondern auch die des TSC. Die Anforderungen der SysRS, die aus dem TSC entstammen, werden in der SRS als Safety-Requirements markiert. Diese Markierung wird über die nachfolgenden Dekompositionsschritte an resultierenden Anforderungen in den Komponentenspezifikationen (SubSysRS) weitergegeben. Wenn nun der Aufbruch in HW- und SW-Requirement-Spezifikationen erfolgt, sind – unabhängig von der Anzahl der Zwischenebenen – Requirements, die für Safety relevant sind, als solche gekennzeichnet und können entsprechend behandelt werden. Da die Anforderungen jetzt Teil der normalen Spezifikation sind, ist es möglich, sie ohne besonderen Aufwand zu bearbeiten – ohne dabei ihre Kritikalität zu übersehen. Mit diesem Ansatz ist es möglich, die Ebenen des Systems Engineerings und die der ISO 26262 miteinander zu verknüpfen, ohne großen Mehraufwand zu erzeugen und dennoch den Anforderungen beider Vorgehensweisen vollständig gerecht zu werden. co
Info
Zu dieser Rubrik
‚In erster Linie geht es um Kommunikation‘ – das war der Titel der Titelstory der ersten Ausgabe der develop3 systems engineering, heute KEM Systems Engineering. Tatsächlich wird die Bedeutung von Kommunikation in Projekten häufig unterschätzt. Projekte sind heute höchst interdisziplinär und im Regelfall über Zeitzonen, Kulturkreise und Sprachräume verteilt. Die präzise und konsistente Verwendung von Begriffen wird somit zur Schlüsselkompetenz. Eine der ersten Aufgaben des Systems Engineers im Projekt ist deshalb die Schaffung eines Vokabulars, das eine eindeutige Kommunikation fördert. Zur Unterstützung dieser Aufgabe veröffentlichen wir in enger Zusammenarbeit mit der Gesellschaft für Systems Engineering (GfSE) e.V. in jeder Ausgabe der KEM Systems Engineering Definitionen zu relevanten Begriffen des Systems Engineerings; Ausgangspunkt hierfür ist die deutsche Übersetzung V. 3.2.2 des Handbuchs Systems Engineering des International Council on Systems Engineering (INCOSE).
