Paper (pdf) - Berner & Mattner

Weitere Magazine

Empfehlungen

Info

früher vorgeschlagene Matrixmethode [4], um einerseits die Vollständigkeit der Maßnahmen zu garantieren, andererseits aber Over-Engineering zu vermeiden (siehe Bild 5). zFAS ESC-SG Fehler-Modi Sensor Eval CAN FuSi-Maßnahme Cross- Plausibilisierung durch Sensorfusion ASIL- Konforme SW- Entwicklung CAN- Absicherung durch CRC Ignorieren von Bremsanforderung bei v > v-max Fehlerhafte Bremsanforderung wg Phantom- Objekt □ ■ Fehlerhafte Bremsanforderung wg SW- Fehler □ ■ Fehlerhafte Bremsanforderung wg Botschafts- Verfälschung ■ ■ Bild 5: Matrix zur Allokation von Sicherheitsmaßnahmen zu Fehlermodi Im SysSiKo werden technische Entwurfsentscheidungen (etwa die Verwendung eines zFAS mit einheitlichen Schnittstellen zwischen Funktionen und Sensordaten/Aktuatorik) gegen daraus resultierende Herausforderungen der FuSi abgewogen und bewertet: So sind für Einzelpunktfehler anfällige Einkanaligkeiten evtl. durch Redundanzen oder Rückfallebenenlösungen zu ergänzen, so dass trotz der schlanken einkanaligen Funktionsarchitektur unter Umständen auf technischer Ebene wieder zusätzliche sicherheitsbedingte By-Pass-Lösungen generiert werden müssen. Die Bedeutung des SysSiKo ist also analog zur Bedeutung der Systemarchitektur in der funktionalen Entwicklung erheblich gewachsen. 4.5. Komponentenweise Umsetzung beim Lieferanten Sind die Sicherheitsanforderungen aus dem SysSiKo den Komponenten zugeordnet, auf die Lastenhefte der Komponenten verteilt und den Lieferanten übergeben, unterscheidet sich das weitere Vorgehen nicht mehr wesentlich von der klassischen Entwicklung. Für die Komponente ist ein technisches Sicherheitskonzept (TeSiKo) zu erstellen. Dieses greift die Sicherheitsanforderungen aus dem SysSiKo des OEMs auf und verfeinert sie zu konkreten Lösungen, ergänzt um weitere Sicherheitsmaßnahmen auf Grund der Komponenten-FMEA. Hierzu zählen bspw. Abschaltpfadtests, Spannungs- und Temperaturüberwachungen oder
Prozessor-Absicherungsmaßnahmen. Die Lösungen aus dem Sicherheitskonzept sind konform zu den Regeln der ISO 26262 entsprechend ihrem ASIL umzusetzen und die Nachweise dazu an den Komponentenverantwortlichen beim OEM zu liefern. Die Einhaltung der im SysSiKo des OEMs festgesetzten Zuverlässigkeits- und Metrik-Budgets sowie die zeitlichen Anforderungen bzgl. Fehlerdetektions- und Fehlerreaktionszeiten sind nachzuweisen. 4.6. Integration und Sicherheitsnachweis Im klassichen V-Modell verlaufen Komponenten-Integration und zugehörige Tests im rechten V-Ast in spiegelbildlicher Reihenfolge wie die Dekomposition in Komponenten, die im linken V-Ast stattfand. Dies gilt im funktionsorientierten Kontext weiterhin. Zu beachten ist jedoch, dass die im linken Ast formulierten funktionalen Sicherheitsanforderungen abstrakt und nicht unbedingt direkt testbar sind (ein häufig gehörter Kritikpunkt), da man bewusst auf die Benennung konkreter Signale, Schnittstellen und selbst Sicherheitsmaßnahmen verzichtet hat, um die Skalierbarkeit der Funktion nicht zu behindern. Zur Lösung dieses Problems bedient man sich für die Verifikation der funktionalen Sicherheitsanforderungen einer Kombination aus Funktionstest der funktionalen Sicherheitsanforderungen (bei dem sich die für den Test nötigen konkreten technischen Schnittstellen aus der Verlinkung zwischen Funktionsanforderung und Systemdesign im linken V-Ast ermitteln lassen) und einer strukturierten Argumentation im Sicherheitsnachweis (z.B. nach Kelly [4]), die nachvollziehbar die Erfüllung der abstrakten funktionalen Sicherheitsanforderungen belegt unter Bezugnahme auf die lückenlose Ableitung und die erfolgreichen Tests der konkreten technischen Realisierung. 5. Varianten, Änderungen und Wiederverwendung Ihre eigentliche Stärke spielt die funktionsorientierte Entwicklungsmethodik aus, wenn es zu Variantenbildung, Änderungen an einem bestehenden Produkt und zu Wiederverwendung von Funktionen oder aber technischen Lösungen im Rahmen neuer Funktionskomplexe kommt. Durch die Modularisierung und die Abstraktion der Funktion von der fahrzeugspezifischen Umsetzung müssen nur die Artefakte im Entwicklungsprozess angepasst werden, die von der Änderung betroffen sind (und natürlich müssen im rechten V- Ast alle Integrations- und Testschritte wiederholt werden). Diese Aussage gilt für Artefakte der normalen Entwicklung ebenso wie für die Arbeitsprodukte der FuSi-Aktivitäten: Wird z.B. nur ein Steuergerät durch ein Modell eines anderen Zulieferers ersetzt, so gelten FuSiKo und SysSiKo weiterhin; nur das TeSiKo der Komponente ist neu zu erstellen sowie die
Seite 1 und 2: Von der Komponenten- zur Funktionso
Seite 3 und 4: Power Steering EPS ECU M Lane Assis
Seite 5 und 6: Architektur-Ebene im linken V-Ast -
Seite 7 und 8: dieser verursacht wird durch einen
Seite 9: Bild 4: Zusammenhang FuSiKo / SysSi

Paper (pdf) - Berner & Mattner

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?