Produktentwicklung auf Systemebene (Teil 4 der ISO 26262)

Hier erfahren Sie, wie die Systemebene in den Sicherheitslebenszyklus eingebettet ist. Sie werden etwas über das Referenzphasenmodell der Systemebene erfahren. Und Sie werden die Schlüsselaktivitäten im Zusammenhang mit der funktionalen Sicherheit auf dieser Ebene kennen lernen.

Die Systemebene folgt im Lebenszyklus der Konzeptphase. Die Tier 1-Lieferanten sind in der Regel für die Systemebene verantwortlich, während der Fahrzeughersteller in der Regel für die Konzeptphase (Teil 3 der ISO 26262) verantwortlich ist. Der Lieferant liefert ein System an die Produktionslinie des Fahrzeugherstellers. Falls erforderlich, gibt es mehrere verschachtelte Systeme und verschiedene Unterlieferanten.

Der erste Aspekt ist, dass die Systemebene als etwas gesehen werden muss, das explizite Aufmerksamkeit erfordert. Dass die Systemebene als solche gesehen und institutionalisiert werden muss, habe ich bereits erläutert. Man braucht einen Systemingenieur, um diese Ebene zu entwerfen, einschließlich der Mechanismen zur Fehlererkennung und Fehlerbehandlung.

Im Video und dem Whitepaper sehen Sie das Referenzphasenmodell der Systemebene. ISO 26262 ordnet die Sicherheitsaktivitäten drei Klauseln zu.

• Das technische Sicherheitskonzept (»Technical Safety Concept«/»TSC«) umfasst die Voraussetzungen für die Entwicklung von Hardware und Software.
• Die System- und Item-Integration inklusive Testen (»System and item integration and testing«) integriert und prüft die Ergebnisse der Disziplinen über mehrere Integrationsstufen bis hin zum Gesamtsystem.
• Schließlich muss die Sicherheitsvalidierung (»Safety validation«) den Nachweis erbringen, dass die Sicherheitsziele im Fahrzeug tatsächlich erreicht wurden, und dass der Entwicklungsgegenstand freigegeben, produziert und in Fahrzeuge eingebaut werden kann.

Hinweis für eine iterative Entwicklung: Dieses Referenzphasenmodell gruppiert Entwicklungsthemen logisch. Natürlich kann ich nur integrieren, was ich bereits entwickelt habe. Das Referenzphasenmodell sollte aber nicht so verstanden werden, dass das fertige Ergebnis der Hard- und Softwareentwicklung erst vollständig vorliegen muss, bevor ich mit der Integration beginnen kann. In der Praxis ist es immer so, dass mehrere Hardware-Muster und zahlreiche Software-Releases gebaut und integriert werden. Das bedeutet, dass das Referenzphasenmodell iterativ, mehrfach verwendet werden muss, und erst in der allerletzten Iteration müssen alle Anforderungen der ISO 26262 erfüllt werden.

Ich möchte nun die Klauseln des Referenzphasenmodells einzeln erläutern.

Die technischen Sicherheitsanforderungen (»Technical Safety Requirements«/»TSRs«) leiten sich hauptsächlich aus den vom Fahrzeughersteller definierten funktionalen Sicherheitsanforderungen (»Functional Safety Requirements«) ab, welche dem Tier 1 zur Verfügung stehen müssen. Die TSRs sind Sicherheitsanforderungen, die die Implementierung von Sicherheitsmechanismen verlangen. Sicherheitsmechanismen werden verwendet, um Fehler zu erkennen, zu melden und zu beherrschen. Es muss spezifiziert werden, in welchen sicheren Zustand das System wechseln muss, wenn ein Fehler erkannt wird. Man muss auch über Toleranzzeiten nachdenken, die sehr stark von der spezifischen Anwendung und anderen Sicherheitsmechanismen abhängen. Es müssen Anforderungen definiert werden, um zu vermeiden, dass Fehler, die nicht sofort zu einer Verletzung der Sicherheitsziele führen, später aber zu einer solchen beitragen könnten (»latente Fehler«), dauerhaft im Fahrzeug verbleiben und damit eine zukünftige Gefahr darstellen. Schließlich kann es notwendig sein, Sicherheitsanforderungen für Produktion, Betrieb und Service zu definieren.

Wir betrachten hier die Systemebene, für die eine Systemarchitektur zur Umsetzung der funktionalen Anforderungen (im Sinne der tatsächlich gewünschten Funktionalität) und der funktionalen Sicherheitsanforderungen entwickelt werden muss.

Die funktionale Sicherheit erfordert die Durchführung von Sicherheitsanalysen. Beispiele für Analysemethoden sind

• Fehler-Möglichkeits- und -Einfluss-Analysen (failure mode and effects analysis/FMEA) und
• Fehlerbaumanalysen (fault tree analysis/FTA).

Ihr Ziel ist es, systematisch und methodenbasiert über die Ursachen von Fehlern und deren Auswirkungen hinsichtlich der Verletzung von Sicherheitsanforderungen nachzudenken. Dabei sind sowohl systematische Fehler – zum Beispiel Fehler durch falsche Softwareprogrammierung - als auch zufällige Hardwarefehler zu berücksichtigen.

Die technischen Sicherheitsanforderungen müssen so detailliert sein, dass sie den Hard- und Software-Disziplinen direkt für die Umsetzung zugeordnet werden können.

Der bereits erwähnte Systemingenieur hat die Aufgabe, sicherzustellen, dass es eine explizite Spezifikation für die Schnittstelle zwischen Hardware und Software (das »Hardware-Software-Interface«) gibt.

Schließlich müssen die Qualität der Sicherheitsanforderungen und die Systemarchitektur verifiziert werden.

Die Sicherheitsvalidierung (»Safety validation«) konzentriert sich auf die Frage, ob die implementierten Sicherheitsmaßnahmen und -mechanismen für den vorgesehenen Einsatzzweck der Fahrzeuge angemessen sind. Zu diesem Zweck werden die eingebauten Systeme z.B. Langzeittests unter realen Bedingungen unterzogen. Verhalten sich die Systeme wie erwartet? Können die Fahrer damit umgehen, wie das System auf Fehler reagiert? Funktionieren die verschiedenen Fahrzeugkonfigurationen? Hier kommen unter anderem auch Sommer- und Wintertests zum Einsatz. Insgesamt muss hier der Nachweis erbracht werden, dass die Sicherheitsziele erreicht wurden, und dass das Item funktional sicher ist.