Autoren: Dr. Thomas Liedtke, Kugler Maag CIE GmbH, Christian Bayer, Elektrobit Automotive GmbH<\/p>\n
In unserem Paper zeigen wir die bei der Definition und der Erstellung eines Software Safety Concepts gemachten Erfahrungen auf. Safety-Analysen in der Softwareentwicklung sind (bis auf Ausnahmen) prim\u00e4r auf Software-Architekturebene vorgesehen. Verbleibende Restrisiken k\u00f6nnen durch Anwendung empfohlener Ma\u00dfnahmen der ISO 26262 [1] Band 6: Product development at software level im weiteren Entwicklungsverlauf als ausreichend klein eingestuft werden. Unser Software Safety Concept fokussiert sich auf die Ebene der Software Requirements Specification sowie die des Architectural Designs. Wir stellen die im realen Kundenprojekt durchgef\u00fchrten vier verschiedenen Safety-Analysen vor. Dabei beschreiben wir den Zweck, gemachte Erfahrungen und typische Befunde.<\/strong><\/p>\n F\u00fcr eine Fahrerassistenzfunktion stand ein OEM vor der Herausforderung, einen vorhandenen SW-Algorithmus zu optimieren und zu industrialisieren. Der Algorithmus diente zwei Kunden-erlebbaren Funktionen im sicherheitskritischen Kontext. Durch Dekomposition wurde auf Systemebene eine ASIL-B (D) Einstufung vorgenommen. Ein technisches Sicherheitskonzept (technical safety concept\/ TSK) fokussierte auf die zu erstellende Software-Komponente (SW-C) und diente als Basis der Softwareentwicklung. Eine Platform (HW und SW) mit entsprechendem Safety-Manual bot die notwendige Ausf\u00fchrungsumgebung an.<\/p>\n Die Firma Elektrobit Automotive GmbH (kurz: EB) wurde damit beauftragt, f\u00fcr die Software-Komponente darzulegen, welche Sicherheitsma\u00dfnahmen notwendig sind, um den Anforderungen aus dem TSK gerecht zu werden. Desweiteren wurde EB in die Softwareentwicklung auf Requirements-, Architektur- sowie die entsprechenden Testebenen eingebunden. Zur externen Beratung wurde die Safety-Expertise von Kugler Maag CIE hinzugezogen.<\/p>\n Aus OEM-Sicht sollte ein Dokument mit dem Titel „Software Safety Concept“ darlegen, welche Sicherheitsmechanismen warum implementiert wurden und wie diese die Sicherheit gew\u00e4hrleisten. Das Dokument sollte zum Finden und Dokumentieren der notwendigen Sicherheitsmechanismen dienen. Das externe Assessorenteam wollte das Dokument um die Sicherheitsanalysen und die Sicherheitsargumentation f\u00fcr das Projekt ausgebaut wissen, um letztlich die Freigabe der Software zu verargumentieren.<\/p>\n Entsprechend blickt das Projekt mit dem Software Safety Concept auf das zentrale Dokument, wenn es um Freigaben oder um die Bewertung neuer Change Requests f\u00fcr das Projekt geht.<\/p>\n Nachdem ein seperates Software Safety Concept kein in der ISO 26262 [1] spezifiziertes Workproduct darstellt, mussten zun\u00e4chst der Umfang und Inhalt definiert werden.<\/p>\n Der Zweck des Software Safety Concepts ist zum einen, die Abbildung der Safety Requirements auf die Architektur zu evaluieren und zum anderen, ma\u00dfgebliche Evidenzen durch die Auswahl und die Ergebnisse durchgef\u00fchrter Safety-Analysen f\u00fcr die Safety-Argumentation zu liefern.<\/p>\n Entsprechend stellten die SW-Safety-Requirements (betrafen im Wesentlichen die Behandlung von sicherheitsrelevanten und nicht-sicherheitsrelevanten Sensoren und Signalen), die abgeleitete SW-Architektur und die Traceability-Matrix die Analysebasis dar, welche iterativ untersucht und angepasst wurde.<\/p>\n Urspr\u00fcnglich war geplant, die Software in zwei Sub-Komponenten mit unterschiedlicher ASIL-Einstufung zu entwickeln. Jedoch konnte die Vermengung von Signalen mit unterschiedlicher ASIL-Allokation nicht verargumentiert und eine Freedom from Interference nicht hinreichend dargestellt werden. Es folgte die Forderung, dass s\u00e4mtliche Softwareteile nach gleichem ASIL zu entwickeln sind.<\/p>\n Safety-Analysen in der Software werden aufgrund ihrer Wirksamkeit meist in der Architekturebene durchgef\u00fchrt. F\u00fcr die weitere SW-Entwicklung sollten die ASIL-orientierten Vorgaben der ISO 26262 [1] die notwendige Sicherheit geben, um verbleibende systematische Fehler auf ein Mindestma\u00df zu reduzieren.<\/p>\n Zur Untersuchung folgender Fragestellungen wurden Safety-Analysen angesetzt:<\/p>\n Siehe Abbildung 1 (PDF<\/a>).<\/p>\n Das technische Sicherheitskonzept des OEM bestand aus ca. 1000 Datenbankeintr\u00e4gen und beinhaltete Definitionen, Systemerkl\u00e4rungen, relevante Ein- und Ausgangssignale sowie die geforderten ca. 40 funktionalen Sicherheitsanforderungen. Das klingt zun\u00e4chst \u00fcberschaubar, und trotzdem gl\u00e4nzten die Anforderungen durch<\/p>\n Im Projekt hatte man sich entschieden, eine systematische Anforderungsanalyse gemeinsam mit dem OEM durchzuf\u00fchren. Ziel war es, ein gleiches Verst\u00e4ndnis zu schaffen und Kundenanforderungen bei Missverst\u00e4ndnissen oder aufgedeckten Unzul\u00e4nglichkeiten zu \u00e4ndern.<\/p>\n Die Durchsprachen mit dem OEM in zahlreichen Treffen wurden mitprotokolliert und die Ergebnisse dokumentiert. Bei notwendigen \u00c4nderungen an den Kundenanforderungen wurden diese solange nachverfolgt, bis die \u00c4nderung in Form neuer Kundenanforderungen bei EB vorlag.<\/p>\n Lessons Learned:<\/strong><\/p>\n Eine FMEA auf Requirementsebene hatte folgende Ziele:<\/p>\n Die Analyse-Sitzungen starteten jeweils auf Basis der negierten Anforderungen. In zwei Richtungen wurden diese evaluiert:<\/p>\n In mehreren Sitzungen wurden Fehlerkombinationen und deren Auswirkungen evaluiert. Typische Befunde bezogen sich auf bislang unber\u00fccksichtigte komplexe Fehlerkombinationen und Fehlerarten (lang oder kurz anliegend, instabile Situation, \u2026). Anforderungen wurden aufgrund von Befunden entsprechend angepasst.<\/p>\n Lessons Learned:<\/strong><\/p>\n S\u00e4mtliche Diagramme (u.a. Komponenten, Sequenzen) sollten systematisch hinterfragt werden. Hierzu wurde f\u00fcr jede Diagrammart ein passender Fragenkatalog mit HAZOP-Leitworten [3] erstellt.<\/p>\n Der Prozess lief iterativ in den folgenden Phasen ab:<\/p>\n Beispiele der Anwendung m\u00f6glicher Leitworte f\u00fcr ein Komponentendiagramm sind:<\/p>\n Bei Sequenz- und Aktivit\u00e4tsdiagrammen kommen weitere Leitworte, wie z.B. f\u00fcr Timing und Abfolge, dazu.<\/p>\n Lessons Learned:<\/strong><\/p>\n Um nicht nur Bottom-up auf m\u00f6gliche Fehlerquellen schlie\u00dfen zu k\u00f6nnen, wurde eine Fehlerbaumanalyse basierend auf den Ebenen Software Safety Requirements und Safety-Architektur erstellt.<\/p>\n Hierbei wurden minimal cut sets aufgestellt und untersucht. Die Abh\u00e4ngigkeiten zwischen verschiedenen Safety-Mechanismen wurden hergestellt. Die Fehlerb\u00e4ume wurden in mehreren gemeinsamen Runden von Safety-Experten und Architekten aufgestellt.<\/p>\n Lessons Learned:<\/strong><\/p>\n Die Erstellung eines Software Safety Concepts half, den Umfang des Projektes zu begreifen. Es bildet nun das zentrale Dokument inklusive wesentlicher Evidenzen f\u00fcr die Safety-Argumentation. Bei neuen Kundenanforderungen erm\u00f6glicht es dem Team, effizient Einflu\u00dfanalysen auf bestehende Safety-Mechanismen durchzuf\u00fchren.<\/p>\n Der Aufwand f\u00fcr die Safety-Analysen war zun\u00e4chst untersch\u00e4tzt worden. Eine \u00dcbersicht \u00fcber Dauer, Aufwand und Nutzen gibt folgende tabellarische \u00dcbersicht:<\/p>\n1. Motivation – Projekt und Aufgabenstellung<\/h2>\n
2. Software Safety Concept<\/h2>\n
3. Safety-Analysen<\/h2>\n
\n
3.1 Systematische TSK-Analyse<\/h3>\n
\n
\n
3.2 Requirements FMEA<\/h3>\n
\n
\n
\n
3.3 Architektur-HAZOP<\/h3>\n
\n
\n
\n
\n
\n
\n
3.4 Fehlerbaumanalyse (FTA)<\/h3>\n
\n
4 Res\u00fcmee<\/h2>\n