Szenarien F Ur Entwicklung, Absicherung Und Test Von . PDF documents

1y ago

176 Views

0 Downloads

624.46 KB

11 Pages

Report/dmca

Preview/Download

Tags: Biostar bioinformatics, Elcentro college nursing, Student database management system

Transcription

Szenarien für Entwicklung, Absicherung und Test vonautomatisierten FahrzeugenG. Bagschik, T. Menzel, A. Reschka und M. Maurer†Zusammenfassung:Die Norm ISO 26262 stellt in der Fassung von 2011 den Stand der Technik für eine funktional sichere Entwicklung von sicherheitskritischen elektrischen/elektronischen Systemen fürKraftfahrzeuge dar. Dazu gehören Fahrerassistenzsysteme und Fahrzeugführungssysteme. ImEntwicklungsprozess der Norm ISO 26262 kann in mehreren Prozessschritten eine szenarienbasierte Sichtweise zur Generierung der von der Norm geforderten Arbeitsergebnisse für diefunktionale Absicherung der Systeme genutzt werden. Szenarienbasierte Ansätze werden dafürin mehreren Prozessschritten für unterschiedliche Betrachtungen verwendet, woraus sich widersprüchliche Anforderungen an die Darstellung der Szenarien ergeben. Dieser Beitrag definiertaufbauend auf vorherigen Veröffentlichungen zur Begriffsdefinition die Anforderungen an Darstellungsweisen von Szenarien und sich daraus ergebende Abstraktionsebenen und zeigt auf,wie sich diese Szenarien entlang des Entwicklungsprozesses nach Norm ISO 26262 ineinanderüberführen lassen.Schlüsselwörter: Automatisierte Fahrzeuge, Funktionale Sicherheit, ISO 26262, teme und teilautomatisierte Fahrzeugführungssysteme nach den Definitionen von Gasser et al. [2012] gehören in den oberen Fahrzeugklassen bereits zur Standardausstattung. Den nächsten Schritt stellt die Einführung hochautomatisierter und vollautomatisierter Systeme dar. Eine große Herausforderung für die Einführung von Fahrzeugführungssystemen liegt in der konzeptionellen und technischen Entwicklung, der Verifikation und der Validierung eines Sicherheitskonzeptes.Die Norm ISO 26262 ist ein Leitfaden für die Entwicklung von sicherheitskritischenelektrischen/elektronischen Systemen und legt damit auch einen Rahmen für die Entwicklung automatisierter Fahrzeugführungssysteme unter dem Aspekt der funktionalenSicherheit fest. In dem von der Norm ISO 26262 vorgeschlagenen Entwicklungsprozesskann die Beschreibung von Szenarien helfen Anforderungen zu formulieren, die benötigten Hard- und Softwarekomponenten zu konzeptionieren und das funktionale Sicherheitskonzept im Testprozess zu validieren und verifizieren. Bereits in der Gefährdungsanalyseund Risikobewertung und spätestens bei der Erstellung von Testfällen werden Szenarien G. Bagschik, T. Menzel und A. Reschka sind wissenschaftliche Mitarbeiter am Institut für Regelungstechnik der Technischen Universität Braunschweig (Email: {bagschik, menzel, reschka}@ifr.ing.tu-bs.de).†M. Maurer ist Professor und Institutsleiter an selbigem Institut (Email: [email protected]).

zur Beschreibung der Eingangsdaten des Entwicklungsgegenstandes benötigt. Daraus ergeben sich für die Darstellung von Szenarien in den Entwicklungsphasen unterschiedlicheAnforderungen, die in diesem Beitrag analysiert werden.Der Ansatz, der in diesem Beitrag dargestellt wird, stellt eine Definition von Szenarien auf unterschiedlichen Abstraktionsebenen vor. Auf diese Weise können Szenarien vonBeginn des Entwicklungsprozesses an bereits in der Konzeptphase identifiziert werdenund im weiteren Verlauf detailliert und konkretisiert werden. Dies erlaubt einen strukturierten Ansatz ausgehend von der Definition des Entwicklungsgegenstandes, über eineGefährdungsanalyse und Risikobewertung, bis hin zur Ableitung von Testfällen für dieValidierung und Verifikation des Gesamtsystems. Aus diesem Grund stellen die Autorenin diesem Beitrag ausgehend von der Definition des Begriffs Szenario nach Ulbrich et al.[2015] eine erweiterte Definition vor und führen die Abstraktionsebenen der funktionalen,logischen und konkreten Szenarien ein.1.1Bisherige ArbeitenUlbrich et al. [2015] haben die Begriffe Szene, Situation und Szenario aus diversen Quellenverglichen und eine einheitliche Definition für automatisierte Fahrzeugführungssystemeund Fahrerassistenzsysteme vorgeschlagen.Bagschik et al. [2016] haben aufbauend auf diesen Definitionen eine Vorgehensweise zurGenerierung potenziell gefährlicher Szenarien für eine Gefährdungsanalyse und Risikobewertung nach dem Entwicklungsprozess der Norm ISO 26262 erarbeitet. Diese Vorgehensweise nutzt eine abstrahierte Beschreibung der Verkehrsteilnehmer sowie der Szenerie undkombiniert diese mit einer Modellierung von funktionalen Fehlern für einen eingeschränkten Anwendungsfall des vollautomatisierten Fahrens im Projekt automatisch fahrerlosfahrendes Absicherungsfahrzeug für Arbeitsstellen auf Bundesautobahnen (aFAS).Schuldt et al. [2013] motivieren einen szenarienbasierten Testprozess und stellen einesystematische Testfallgenerierung mittels eines 4-Ebenen-Modells vor.Bach et al. [2016] motivieren eine modellbasierte Szenariendarstellung mit räumlichenund zeitlichen Beziehungen als durchgängige Darstellungsweise im Entwicklungsprozessder Norm ISO 26262. Die Darstellung wurde prototypisch für ein ACC-System auf Autobahnen implementiert und die Ergebnisse wurden vorgestellt.Bergenhem et al. [2015] argumentieren, dass vollständige Anforderungen für automatisierte Fahrzeuge nur durch einen durchgängigen, nachverfolgbaren und verifizierbarenProzess der Anforderungserstellung im Sinne des V-Modells erreicht werden können [Verein Deutscher Ingenieure (VDI), 2004].Die genannten Veröffentlichungen verwenden Szenarien auf unterschiedlichen Abstraktionsebenen für die Entwicklung und Absicherung automatisierter Fahrzeuge. Dabei wirdder Begriff Szenario nicht einheitlich definiert, was ein gemeinsames Verständnis für dieNutzung von Szenarien im Entwicklungsprozess der Norm ISO 26262 erschwert. DieserBeitrag schlägt daher eine erweiterte Definition des Begriffs Szenario vor.1.2Aufbau des BeitragsIn diesem Beitrag werden im nächsten Abschnitt Anforderungen an die Darstellung undVerwendung von Szenarien im Entwicklungsprozess der Norm ISO 26262 abgeleitet undanalysiert. Danach folgt eine Definition verschiedener Abstraktionsebenen für Szenarien

im Entwicklungsprozess und wie diese Abstraktionsebenen ineinander überführt werdenkönnen.2Motivation und ProblemstellungDie Norm ISO 26262 stellt derzeit in der Fassung von 2011 [ISO, 2011] den Stand derTechnik für die funktionale sichere Entwicklung1 sicherheitskritischer E/E-Systeme dar.Abbildung 1 zeigt die Übersicht der Prozessschritte aus der Norm ISO 26262 und markiert(rot), in welchen Prozessschritten Szenarien genutzt werden können, um die gefordertenArbeitsergebnisse (vgl. englisch work products) zu erbringen. Der Begriff des Szenarioswurde von Ulbrich et al. [2015] in verschiedenen Disziplinen untersucht und es wurde eineDefinition für das automatisierte Fahren vorgeschlagen. Dieser Beitrag folgt der Definitiondes Szenarios von Ulbrich et al. [2015]. Go und Carroll [2004] stellen heraus, dass Szenarienin den meisten Anwendungen aus den gleichen Bestandteilen zusammengesetzt sind. Dabeikönnen Szenarien jedoch in unterschiedlichen Detailgraden spezifiziert und dargestelltwerden. Die Darstellung von Szenarien kann informativ, semi-formal oder formal erfolgen[Go und Carroll, 2004]. Diese Unterscheidung gibt einen Hinweis auf mehrere Detailgradeim Entwicklungsprozess der Norm ISO 26262.Da Szenarien im Entwicklungsprozess nach Norm ISO 26262 von der Konzeptphaseüber die technische Entwicklung bis zum Test und der Validierung des Gesamtsystemsverwendet werden, ist es notwendig, die aus den Prozessschritten resultierenden Anforderungen an Szenarien zu definieren. Die Anforderungen ermöglichen eine einheitlicheDefinition von Detailgraden für die Verwendung von Szenarien. Die folgenden Abschnitteorientieren sich an den Arbeitsergebnissen der Norm ISO 26262 und leiten Anforderungenan die Darstellungsweisen von Szenarien in den markierten Prozessschritten ab.2.1Szenarien in der Konzeptphase und EntwicklungsphaseIn der Konzeptphase (Teil 3) der Norm ISO 26262 werden vor der technischen Entwicklung der Entwicklungsgegenstand (vgl. englisch item) definiert, der Sicherheitslebenszyklus initiiert, eine Gefährdungsanalyse und Risikobewertung durchgeführt und resultierend aus der Analyse ein funktionales Sicherheitskonzept erstellt. In der Beschreibungdes Entwicklungsgegenstandes (vgl. englisch item definition) sollen funktionale Konzepte und Systemgrenzen, die Einsatzumgebung, die rechtlichen Rahmenbedingungen unddie Abhängigkeiten zu anderen Entwicklungsgegenständen beschrieben werden. Aus diesen Informationen lassen sich mögliche Betriebsszenarien für den Entwicklungsgegenstandableiten. Reschka [2017] schlägt vor, für diese Szenarien sichere Fahrzustände festzulegenund das Sollverhalten des zu entwickelnden Systems zu beschreiben. Die Betriebsszenariensind in diesem Prozessschritt abstrakt gehalten und für den menschlichen Sprachgebrauch(textuelle Beschreibung, Experten- und Entwicklergespräche) zu formulieren.Der nächste Prozessschritt, in dem in der Norm ISO 26262 Szenarien zur Erbringungder Arbeitsergebnisse gefordert werden, ist die Gefährdungsanalyse und Risikobewertung(GuR). Diese setzt sich aus den Teilschritten Situationsanalyse und Gefährdungsidentifikation und Klassifikation von gefährlichen Ereignissen zusammen. In der Situations1Die gesamte Systementwicklung für automatisierte Fahrzeuge umfasst zusätzlich parallele Entwicklungsprozesse, die andere Aspekte, wie beispielsweise die Funktionsentwicklung, des Systems behandeln.

3. Konzeptphase4. Produktentwicklung auf Systemebene3-5 Definition desEntwicklungsgegenstands4-5 Initiierung derProduktentwicklung3-6 Initiierung desSicherheitslebenszyklus4-6 Spezifikation von technischenSicherheitsanforderungen3-7 Gefährdungsanalyse undRisikobewertung4-7 Systemdesign3-8 FunktionalesSicherheitskonzept4-11 Freigabe Produktion4-10 FunktionaleSicherheitsbewertung4-9 Sicherheitsvalidierung6. Produktentwicklung aufSoftwareebene5-5 Initiierung Produktentwicklungauf Hardwareebene6-5 Initiierung Produktentwicklungauf Softwareebene5-6 Spezifikation von HardwareSicherheitsanforderungen6-7 Softwarearchitektur5-8 Evaluation von HardwareArchitekturmetriken5-9 Evaluation Verstöße gegenSicherheitsziele (Zufallsfehler)5-10 Hardware-Integration undTest7-5 Produktion7-6 Betrieb, Wartung undStilllegung4-8 Integration und Test5. Produktentwicklung aufHardwareebene5-7 Hardwaredesign7. Produktion und Betrieb6-8 Software-Modulplanung undImplementierung6-9 Software Modultests6-10 Software-Integration und Test6-11 Verifikation von SoftwareSicherheitsanforderungenAbbildung 1: Prozessübersicht der Norm ISO 26262. Rot markierte Phasen nutzen Szenarien zur Erbringung der Arbeitsergebnisse.analyse nach Norm ISO 26262 sollen alle Betriebssituationen2 und -zustände, in denenein funktionales Fehlverhalten (vgl. englisch malfunctioning behavior ) Schaden verursachen kann, identifiziert werden. Das funktionale Fehlverhalten kann dabei als Abweichungvom definierten Sollverhalten interpretiert werden. Gefährliche Szenarien, welche aus derKombination von Betriebsszenarien und funktionalem Fehlverhalten bestehen, werdenanschließend mit dem Sicherheitsintegritätslevel für Automobile (ASIL) bewertet. DieDarstellung der gefährlichen Szenarien muss somit andere Verkehrsteilnehmer und dasstationäre Umfeld beinhalten, um die Parameter Auftretenswahrscheinlichkeit des Betriebsszenarios, mögliche Schadensschwere und Beherrschbarkeit des gefährlichen Szenarios3 der ASIL-Klassifikation ermitteln zu können. Die Analyse der gefährlichen Szenarienwird nach derzeitigem Stand der Technik von Experten durchgeführt, weshalb diese Szenarien sprachlich formuliert werden müssen. Da menschliche Experten je nach Fachgebietund Expertise unterschiedlich detaillierte Begriffe für die Beschreibung eines Szenariosverwenden, muss ein einheitliches Vokabular für die funktionale Betrachtungsweise imProzessschritt der Gefährdungsanalyse und Risikobewertung definiert werden. Weiterhinkönnen die definierten Begriffe des Vokabulars, zum Beispiel durch Ontologien, formalgeordnet werden, um ein allgemeines Verständnis unter Experten zu gewährleisten. Somitkönnen sprachlich gefasste Szenarien aus Kombinatorik der geordneten Begriffe erzeugtund der Interpretationsraum für Experten verkleinert werden.Nachdem die gefährlichen Szenarien analysiert wurden und ein funktionales Sicherheitskonzept erstellt wurde, werden in Prozessschritt 4-6 technische Sicherheitsanforderungen festgelegt. Technische Anforderungen können gegenüber funktionalen Anforderungen2Die Autoren weisen darauf hin, dass der Begriff Betriebssituation aus dem Sprachgebrauch der NormISO 26262 nach Definition von Ulbrich et al. [2015] als Betriebsszenario bezeichnet werden müsste.3Die Beherrschbarkeit eines Szenarios umfasst die Beherrschbarkeit durch den Fahrer im eigenen Fahrzeug und die Beherrschbarkeit durch andere Verkehrsteilnehmer.

quantifiziert werden. Beispielsweise kann die funktionale Anforderung, einen Sicherheitsabstand einzuhalten, durch den einzuhaltenden Abstand in Metern im Zustandsraum formuliert werden. Jedes gefährliche Szenario kann von der sprachlichen und semi-formalenDarstellungsweise der Konzeptphase (3) für die Produktentwicklung auf Systemebene (4)in physikalische Zustandsgrößen überführt werden. Eine Auflistung dieser Zustandsgrößenist eindeutig, aber für den menschlichen Experten aufgrund der Detailtiefe nicht mehr intuitiv zu verarbeiten. Um die Anzahl der Szenarien zu reduzieren, können Zustandsgrößenin Wertebereichen zusammengefasst und somit sichere und unsichere Wertebereiche festgelegt werden. Diese Detaillierung der sprachlichen Elemente zu einer oder mehrerenZustandsgrößen führt dazu, dass Anforderungen an das zu entwickelnde System validierbar formuliert werden können, sodass in Prozessschritt 4-9 der Norm ISO 26262 eineSicherheitsvalidierung durchgeführt werden kann.2.2Szenarien im Testprozess und in der AbsicherungNach der technischen Entwicklung wird geprüft, ob das implementierte System die inden vorherigen Prozessschritten gestellten Anforderungen erfüllt. Für diese Verifikationmüssen Tests systematisch geplant, spezifiziert, durchgeführt, evaluiert und dokumentiertwerden [ISO, 2011, Teil 8, Abschnitt 9.2].Eine Testfallspezifikation muss in diesem Rahmen unabhängig von der Testmethodefolgende Informationen enthalten:1. Eindeutige Kennung2. Referenz auf das Testobjekt3. Vorbedingungen und Konfiguration44. Umgebungsbedingungen5. Eingangsdaten mit zeitlichem Verlauf6. Erwartetes Verhalten formuliert in WertebereichenEine große Herausforderung der Testfallerstellung liegt in der Spezifikation der Eingangsdaten. Die Eingangsdaten müssen den zeitlichen Verlauf aller Parameter beinhalten, diedas Verhalten des Testobjektes maßgeblich beeinflussen. Zeitgleich dürfen die Eingangsparameter keine Widersprüche5 aufweisen, sondern müssen aufgrund der Komplexität, imSinne von interagierenden Komponenten, aktueller Systeme konsistente Eingangsdaten inForm eines Szenarios darstellen [vgl. Ulbrich et al., 2015].Informationen über die Einsatzumgebung des zu testenden Systems sowie die auftretenden Betriebsszenarien werden bereits im Rahmen der Beschreibung des Entwicklungsgegenstandes in der Konzeptphase der Norm ISO 26262 zusammengestellt. DieseInformationen können als Grundlage für die Erstellung konsistenter Eingangsdaten beider Spezifikation von Testfällen genutzt werden. Die Szenarien der Beschreibung des Entwicklungsgegenstandes liegen auf einer abstrakten sprachlich gefassten Ebene vor und4Im Sinne einer SystemvarianteHiermit sind unbeabsichtigte Widersprüche gemeint. Fehlerinjektionen können später als Testmethode gezielt eingesetzt werden.5

müssen für die Verwendung im Rahmen eines Testfalls zunächst weiter detailliert undkonkretisiert werden.Der Detaillierungsschritt kann im Rahmen der Spezifikation von technischen Sicherheitsanforderungen erfolgen [Teil 4, Abschnitt 6 ISO, 2011]. Die technischen Sicherheitsanforderungen beschreiben unter anderem, wie der Entwicklungsgegenstand auf äußereAnregungen, die eine Einhaltung der Sicherheitsziele beeinflussen können, reagieren soll.Die technischen Anforderungen detaillieren die sprachlich gefassten Anforderungen imParameterraum (inklusive Parameterbereiche) und geben somit an, in welchen Bereichendie Funktionalität des Systems gegeben sein muss. Dieser Parameterraum muss im Verifikationsprozess systematisch geprüft und somit bei der Erstellung von Testfällen berücksichtigt werden. Zudem müssen die Szenarien im Detaillierungsschritt in eine formaleDarstellung überführt werden, um später eine reproduzierbare Testdurchführung gewährleisten zu können. In den Szenarien müssen alle Parameter zur Ausführung im jeweiligenPrüfverfahren (Simulation, Feldtest, etc.) beschrieben sein. Im Detaillierungsschritt stehtsomit die Überführung der Szenarien von einer informativen Beschreibung mit geordneten Begriffen in eine formale Beschreibung auf Basis physikalischer Systemzustandsgrößeninklusive zugehöriger Wertebereiche im Vordergrund.Zur Generierung der Eingangsdaten eines Testfalls müssen aus den Parameterbereichen der spezifizierten Szenarien in einem Konkretisierungsschritt die zu prüfenden Parameterstufen ausgewählt werden. Schuldt et al. [2013] schlagen für die Identifikationeiner repräsentativen Stichprobe Äquivalenzklassenbildung, Grenzwertanalysen und kombinatorische Verfahren vor. Diese Verfahren erlauben eine systematische Generierung vonTestfällen, geben jedoch noch keinen Hinweis auf die Testraumabdeckung. Die Testraumabdeckung muss im Testkonzept als Produkt der Auswahl der Szenarien, der zu verwendenden Prüfmethoden und der Quantisierung des Konkretisierungsschrittes ermitteltwerden. Die im Konkretisierungsschritt systematisch ermittelten und formal beschriebenen Szenarien stellen widerspruchsfreie Eingangsdaten für den Entwicklungsgegenstanddar und können im Rahmen eines Testfalles zur Verifikation genutzt werden.2.3Anforderungen an SzenarienAus den oben genannten Prozessschritten der Norm ISO 26262 lassen sich die folgenden Anforderungen an Szenarien im Entwicklungsprozess formulieren (Konzeptphase [K],Systementwicklung [S], Testprozess [T]):K1 Szenarien müssen aus der sprachlich gefassten Definition eines Entwicklungsgegenstands in eine semi-formale Darstellung überführt werden können.K2 Szenarien müssen für menschliche Experten in einheitlicher Fachsprache formuliertwerden können.S1 Szenarien müssen Parameterbereiche für Zustandsgrößen abbilden können.S2 Szenarien müssen eine formale Ordnung für die Darstellung in Parameterbereichenbereitstellen (zum Beispiel Dateiformat).T1 Szenarien müssen so detailliert beschrieben werden, dass sie mit Prüfverfahren ausgeführt werden können.

T2 Szenarien müssen eindeutig definiert werden und dürfen keine Interpretationsmöglichkeiten aufweisen (Reproduzierbarkeit).T3 Szenarien müssen effizient maschinen-lesbar dargestellt werden.Aus den oben genannten Anforderungen ergeben sich Widersprüche hinsichtlich derDarstellungsweise von Szenarien. Die Anforderungen K1 und T3 drücken den Bedarf für eine abstrakte sprachliche (K1) und im Gegensatz dazu eine effizient maschinen-lesbare (T3)Repräsentation der Szenarien aus. Da natürliche Sprache für Maschinen schwer zu verarbeiten ist und Menschen effiziente (meist binarisierte) Datenformate nicht lesen können,ergibt sich eine Notwendigkeit nach mehreren Darstellungsweisen der Szenarien. Ebenso ergibt sich aus den Anforderungen S1 und T2 eine gegensätzliche Sichtweise auf dieDarstellung von Szenarien. Wenn Bereiche für Zustandsgrößen angegeben werden können(S1), lässt dies einen gewissen Spielraum bei der Festlegung von konkreten Größen, diefür die Ausführung in unterschiedlichen Prüfverfahren notwendig sind (T2). Daraus ergibt sich neben den Forderungen nach einer sprachlichen und einer maschinen-lesbarenDarstellung noch eine Unterscheidung des Detailgrades bei letzterer Darstellung.3Szenarien für Entwicklung, Absicherung und TestWie im vorherigen Abschnitt hergeleitet, ergeben sich widersprüchliche Anforderungenan die Darstellungsweise von Szenarien im Entwicklungsprozess der Norm ISO 26262. Imfolgenden Abschnitt werden drei Abstraktionsebenen für Szenarien vorgeschlagen und eswird dargestellt, wie sich diese Ebenen im Verlauf des Entwicklungsprozesses ineinanderüberführen lassen.Abbildung 2 zeigt die Unterteilung der Abstraktionsebenen in funktionale, logische undkonkrete Szenarien, die in den folgenden Abschnitten definiert werden.3.1Funktionale SzenarienFunktionale Szenarien bilden die erste und somit abstrakteste Ebene von Szenarien, welche in der Konzeptphase der Norm ISO 26262 zur Definition des Entwicklungsgegenstandsund der Gefährdungsanalyse und Risikobewertung genutzt werden können. Die Darstellung von funktionalen Szenarien basiert auf einer sprachlichen Beschreibung. FunktionaleSzenarien können somit Expertenwissen abbilden und sind intuitiv lesbar. Die Autorenschlagen folgende Definition für funktionale Szenarien vor:Funktionale Szenarien stellen Betriebsszenarien des Entwicklungsgegenstandsauf semantischer Ebene dar. Die Entitäten und Beziehungen zwischen denEntitäten der Anwendungsdomäne werden in sprachlich gefassten Szenarienausgedrückt. Die Szenarien sind widerspruchsfrei. Das Vokabular der funktionalen Szenarien ist spezifisch für den Anwendungsfall und die -domäne undkann unterschiedliche Detailgrade aufweisen.Die Darstellung funktionaler Szenarien auf semantischer Ebene beinhaltet eine sprachliche und widerspruchsfreie Beschreibung der Entitäten (Bestandteile der Szenarien) undder Beziehungen und Interaktionen zwischen den Entitäten. Funktionale Szenarien lassen

Funktionale SzenarienLogische SzenarienKonkrete SzenarienBasisstrecke:Basisstrecke:3- streifige Autobahn in KurveBegrenzung auf 100 km/h durchVerkehrszeichen rechts und linksBasisstrecke:Stationäre Objekte:Stationäre Objekte:-Stationäre Objekte:-Bewegliche Objekte:Ego, Stau;Interaktion: Ego in Manöver„Annähern“ auf mittlerenFahrstreifen, Stau zähfließendBewegliche Objekte:Bewegliche Sommer, RegenBreite Fahrstreifen [2,3.3,5] mKurvenradius[0,6.0,9] kmPos Verkerszeichen [0.200] mStauende PosStau Geschw.Ego AbstandEgo Geschw.[10.200] m[0.30] km/h[50.300] m[80.130] km/h[10.40] C[20.100] µmBreite Fahrstreifen [3,2] mKurvenradius[0,7] kmPos Verkerszeichen [150] mStauende PosStau Geschw.Ego AbstandEgo Geschw.Umwelt:TemperaturTröpfchengröße40 m30 km/h200 m100 km/h20 C30 µmAbstraktionslevelSzenarienanzahlAbbildung 2: Abstraktionsebenen von Szenarien anhand eines Beispielszenarios imEntwicklungsprozess nach Norm ISO 26262sich somit durch ein Vokabular, das Entitäten (Fahrzeug A, Fahrzeug B) und deren Beziehung zueinander (Fahrzeug A überholt Fahrzeug B) einheitlich definiert, beschreiben.Der Detailgrad dieser Szenarien lässt sich nicht eindeutig definieren, da dieser durchdie aktuelle Entwicklungsphase, den Fokus der Betrachtung und die daraus resultierendeWahl des Vokabulars maßgeblich beeinflusst wird. Wird ein umfangreiches Vokabular zurBeschreibung aller Entitäten gewählt, kann eine große Anzahl von Szenarien aus demVokabular erzeugt werden. Für die widerspruchsfreie Erstellung von funktionalen Szenarien müssen die Begriffe des Vokabulars eindeutig voneinander trennbar sein. Quellen fürdie Beschreibung der Domäne können beispielsweise Normen und Richtlinien (Richtlinien zur Anlage von Autobahnen, Straßenverkehrsordnung, etc.) sein, in denen Entitätendes Verkehrsgeschehens benannt und differenzierbar definiert sind. Für den jeweiligenAnwendungsfall (Was tut der Entwicklungsgegenstand?) kann ein (firmen-)eigenes Vokabular genutzt werden, welches jedoch über Entwicklungsstände einheitlich definiert seinmuss. Somit können bereits erstellte Szenarien für weitere Entwicklungen nachverfolgbargenutzt werden.3.2Logische SzenarienLogische Szenarien stellen in der Definition dieses Beitrags eine Detaillierung der funktionalen Szenarien im physikalischen Zustandsraum dar. Somit lassen sich funktionaleSzenarien in Parameter der Entitäten (absolute Parameter) und Parameter der Beziehungen (relative Parameter) überführen. Die Autoren schlagen folgende Definition fürlogische Szenarien vor:

Logische Szenarien stellen Betriebsszenarien durch Entitäten und Beziehungendieser Entitäten mithilfe von Parameterbereichen im Zustandsraum dar. Fürdie einzelnen Parameterbereiche können optional statistische Verteilungen angegeben werden. Zusätzlich können optional die Beziehungen der Parameterbereiche zueinander mithilfe von Korrelationen oder numerischen Bedingungenmodelliert werden. Logische Szenarien enthalten eine formale Beschreibungvon Szenarien.Für eine schrittweise Detaillierung von Szenarien im Entwicklungsprozess werden logische Szenarien bereits formalisiert im Zustandsraum, jedoch in Wertebereichen der Parameter, angegeben. Für eine genauere Beschreibung der Parameterbereiche können statistische Verteilungen (Normalverteilung, Gleichverteilung etc.) modelliert werden. Beziehungen zwischen Parameterbereichen können zusätzlich durch numerische Bedingungen(z.B. bei Überholvorgängen muss Geschwindigkeit A größer Geschwindigkeit B sein) oderKorrelationsfunktionen (z.B. Fahrstreifenbreite in Abhängigkeit des Kurvenradius) näherspezifiziert werden.3.3Konkrete SzenarienKonkrete Szenarien beschreiben die Entitäten und Beziehungen der Entitäten mithilfevon eindeutigen Parametern im Zustandsraum. Jedes logische Szenario kann durch Konkretisierung der Parameterbereiche zu jeweils einem festen Wert in ein konkretes Szenarioüberführt werden. Die Autoren schlagen daher folgende Definition für konkrete Szenarienvor:Konkrete Szenarien stellen Betriebsszenarien eindeutig durch Entitäten undBeziehungen dieser Entitäten mithilfe von festen Werten im Zustandsraumdar.Aus einem logischen Szenario mit wertkontinuierlichen Parameterbereichen könnendurch infinitesimale Abtastung und Kombination der Wertebereiche theoretisch beliebigviele konkrete Szenarien abgeleitet werden. Die Konkretisierung erfolgt anhand der Identifikation und Kombination repräsentativer Diskretisierungsstufen der Parameter. Nur konkrete Szenarien können direkt in einen Testfall überführt und mit dem Fahrzeugführungssystem ausgeführt werden.3.4Einordnung in den EntwicklungsprozessFunktionale, logische und konkrete Szenarien lassen sich durch Detaillierung und Überführung in den Zustandsraum sowie Konkretisierung von Wertebereichen zu festen Parametern ineinander überführen. Abbildung 3 zeigt einen schematischen Entwicklungsprozess nach dem V-Modell mit der Zuordnung der in diesem Beitrag definierten Szenarien.Die funktionalen Szenarien werden vor der technischen Entwicklung zur Definitiondes Entwicklungsgegenstandes und der Gefährdungsanalyse und Risikobewertung genutzt.Durch die Detaillierung und die Überführung der sprachlich gefassten Szenarien in den Zustandsraum können technische Anforderungen durch valide und nicht valide Wertebereiche

FunktionaleSzenarienDef. rderungenSystemvalidierung& -abnahmeSystemintegration& nKomponententestRealisierungAbbildung 3: Funktionale, logische und konkrete Szenarien im V-Modell-basiertenEntwicklungsprozess; Abkürzung: GuR - Gefährdungsanalyse und Risikobewertungformuliert werden. Konkrete Szenarien dienen als Grundlage für ausführbare Testfälle undmüssen vorher, wie bereits von Ulbrich et al. [2015] formuliert, um das erwartete Sollverhalten des Testgegenstands und die zu verwendende Testinfrastruktur erweitert werden.Das Sollverhalten kann dabei aus den funktionalen (Betriebs-)Szenarien und der Definition des Entwicklungsgegenstandes abgeleitet werden. Ein weiterer Unterschied zwischenSzenarien und Testfällen besteht darin, dass das resultierende Verhalten des Testgegenstandes in einem Testfall nicht bekannt ist und erst durch die Ausführung eintritt. InSzenarien ist das Verhalten aller Teilnehmer zumindest durch ihre Ziele und Werte definiert. Diesen Aspekt und die damit zusammenhängende Transformation der Szenarienzu Testfällen wird im Entwicklungsprozess durch die Erstellung des Testkonzepts und dieIdentifikation von Testfällen erreicht.4Zusammenfassung und AusblickIn diesem Beitrag wurde der Entwicklungsprozess der Norm ISO 26262 hinsichtlich derUmsetzbarkeit einer szenarienbasierten Entwicklung betrachtet. Zu diesem Zweck wurdendie Prozessschritte identifiziert, in welchen Szenarien zur Erbringung der Ergebnisse desjeweiligen Prozessschrittes genutzt werden können. Weiterführend wurden Anforderungen an die Darstellungen von Szenarien definiert und Widersprüche hinsichtlich der ausunterschiedlichen Prozessschritten resultierenden Anforderungen aufgezeigt. Auf dieserGrundlage haben die Autoren unterschiedliche Abstraktionsebenen von Szenarien eingeführt, um alle Anforderungen erfüllen zu können. Des Weiteren wurden Definitionenfür die eingeführten Abstraktionsebenen vorgeschlagen und in den Entwicklungsprozessder Norm ISO 26262 eingeordnet.Aufbauend auf den eingeführten Abstraktionsebenen werden zukünftig Methoden undWerkzeuge benötigt, um die Darstellungen von Szenarien entlang des Prozesses der NormISO 26262 ineinander zu überführen. Dabei lassen sich bestehende Ansätze zur Szenarienmodellierung in die vorgeschlagenen Abstraktionsebenen einordnen. Anschließend kannder Bedarf nach fehlenden Darstellungsweisen und Methoden zur Detaillierung und Konkretisierung identifiziert werden.

5DanksagungDieser Beitrag entstand im Rahmen von PEGASUS - Projekt zur Etablierung von generellakzeptierten Gütekriterien, Werkzeugen und Methoden sowie Szenarien und Situationenzur Freigabe hochaut

wie sich diese Szenarien entlang des Entwicklungsprozesses nach Norm ISO 26262 ineinander uberf uhren lassen. Schl usselw orter: Automatisierte Fahrzeuge, Funktionale Sicherheit, ISO 26262, Szenarien, Testprozess 1 Einleitung Fahrerassistenzsysteme und teilautomatisier