Produktentwicklung auf Systemebene (Teil 4 der ISO 26262)

Benötigen Sie ein grundlegendes Verständnis dafür, was Sie als Fahrzeuglieferer bei der Produktentwicklung auf Systemebene zu tun haben? Mit einem Video und einem kostenlosen Whitepaper erfahren Sie hier, was Sie aus Sicht der Funktionalen Sicherheit gemäß Teil 4 der ISO 26262 beachten müssen.

Zurück zu Funktionaler Sicherheit

Die Ebene, auf der einzelne Technologien in ein Produkt integriert werden, kann grob als Systemebene (»system level«) bezeichnet werden. Die an einem System beteiligten Technologien sind Software, Hardware, Optik, Hydraulik und so weiter. Konkret werden wir uns in unserem Kontext auf Hardware und Software konzentrieren.

Traditionell haben Zulieferer in der Automobilindustrie Hardware-Entwicklungsabteilungen und Software-Entwicklungsabteilungen. Die Zusammenarbeit zwischen den beiden Fachbereichen ist oft schlecht organisiert. Die Mitarbeiter arbeiten selektiv zusammen, nur dann, wenn sie erkennen, dass es notwendig geworden ist. Oft ist es der Projektleiter, der auch die Koordination dieser Aktivitäten übernimmt.

Ein gravierender Nachteil dieses Ansatzes ist, dass die Systemebene nur implizit oder gewissermaßen beiläufig betrachtet wird, statt als eigenständige Disziplin gesehen und entwickelt zu werden. Um ein automobiles Gesamtsystem sicher zu machen, ist diese Disziplin aber absolut entscheidend. Es ist die Systemebene, die die Anforderungen für jede einzelne Technologie definieren und systematisch integrieren sollte.

Teil 4 der ISO 26262 enthält die entsprechenden Anforderungen.

Bild   Aufbau der ISO 26262:2018
Abspielen
Ihr kostenloses Whitepaper

Interessiert an einer kurzen Zusammenfassung über die Systemebene in der funktionalen Sicherheit? Unser kostenloses Whitepaper bietet Ihnen eine Zusammenfassung aller wichtigen Informationen, inklusive Abbildungen, die das Gesagte über Teil 4 der ISO 26262 zeigen – die ideale Lektüre für alle, die neu in das Thema Prozessverbesserungen von sicherheitskritischen Systemen einsteigen.

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 – eine eigenständige Engineering-Aufgabe

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.

Damit haben wir die erste wichtige Lektion: Sicherheitsaktivitäten müssen auf der Systemebene koordiniert werden.

Referenzphasenmodell der Systemebene

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.

Wir sind für Sie da.

Benötigen Sie Unterstützung für Ihr Projekt? Wir sind Ihre Ansprechpartner rund um Managementberatung und Verbesserungsprogramme in der Elektronikentwicklung.

Steffen Herrmann und das Sales-Team

Technisches Sicherheitskonzept (Clause 4.6)

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.

Funktionale Sicherheitsanforderungen werden in technische Sicherheitsanforderungen detailliert, so dass sie mit der parallel zu entwickelnden Systemarchitektur umgesetzt werden können.

Systematische Fehler und zufällige Hardware-Fehler müssen behandelt werden.

Sicherheitsanalysen sollten durchgeführt werden, um die Ursachen von Fehlern/Ausfällen und deren Auswirkungen systematisch zu identifizieren. Dies geschieht mit dem Ziel, die Spezifikation von Sicherheitsanforderungen, Sicherheitsmechanismen und Design abzusichern.

Systemintegration und Test (Clause 4.7)

Wir kommen nun zur Integration und zum Testen, basierend auf den Ergebnissen der Hardware- und Softwareentwicklung.

Was nun folgt, ist sehr ähnlich den Anforderungen aus Automotive SPICE®. Wir betrachten deshalb nur die Perspektive der ISO 26262, beziehen uns also speziell auf die funktionale Sicherheit.

Während der Integration und des Testens ist es leicht, relevante Testziele zu verfehlen. Und das trotz hohen Aufwands und Kosten. Häufig werden einige Aspekte mehrfach von verschiedenen Testgruppen getestet, während andere wichtige Konstellationen ohne entsprechende Koordination gar nicht getestet werden. Aus diesem Grund muss die funktionale Sicherheit systematisch angegangen werden. Es muss eine Strategie für die Koordination der Testziele und die Organisation der Tests festgelegt werden.

Testfälle müssen systematisch nach bestimmten Methoden entwickelt werden. Die ISO 26262 beschreibt, was für die Integration und das Testen von Systemen auf drei verschiedenen Ebenen notwendig ist. Erstens auf der Ebene der Hardware-Software-Integration, zweitens auf der Systemebene und drittens auf der Fahrzeugebene. Die Norm legt fest, dass Leistung, Wirksamkeit und Robustheit nachgewiesen werden müssen. Insgesamt muss der Nachweis erbracht werden, dass die Sicherheitsanforderungen auf der jeweiligen Ebene erfüllt werden.

Sicherheitsvalidierung (Clause 4.8)

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.

Entwicklungsergebnisse müssen systematisch integriert und auf mehreren Ebenen, von der Hardware-Software-Integration bis zum Gesamtfahrzeug, getestet werden, um die Erfüllung der Sicherheitsanforderungen und Sicherheitsziele nachzuweisen.

Seit 2008

Wir sind stolz, dass wir seit 2008 zu den Pionieren der Funktionalen Sicherheit zählen und unsere Erfahrung bei der Entwicklung der Sicherheitsnorm ISO 26262 einbringen konnten.

Automobilelektronik funktional sicher?
Wir sind die Experten!

700+ Projekte

Wir verfügen über die geballte Erfahrung aus über 700 Projekten zur Funktionalen Sicherheit nach ISO 26262 bei weltweit über 100 Kunden.

Automobilelektronik funktional sicher?
Wir sind die Experten!

+100 Spezialisten

Wir haben über 100 Spezialisten im Rahmen des Zertifizierungsprogramms »TÜV Rheinland Functional Safety (Automotive)« ausgebildet.

Automobilelektronik funktional sicher?
Wir sind die Experten!

+250 Jahre

Die Erfahrung unserer Expertinnen und Experten im Bereich Funktionale Sicherheit beträgt zusammen über stolze 250 Jahre.

Automobilelektronik funktional sicher?
Wir sind die Experten!

Fachbuch-Klassiker

Wir haben den Fachbuch-Klassiker »Funktionale Sicherheit in der Praxis« und das »Essentials Funktionale Sicherheit« verfasst.

Automobilelektronik funktional sicher?
Wir sind die Experten!

18 Experten

Bei uns engagieren sich bereits 18 Experten, die nach dem TÜV Rheinland Functional Safety (Automotive) zertifiziert oder selbst als Trainer zugelassen sind.

Automobilelektronik funktional sicher?
Wir sind die Experten!

Zertifizierung

Wir sind Partner im Zertifizierungsprogramm »Functional Safety Engineer (Automotive) des TÜV Rheinlands«.

Automobilelektronik funktional sicher?
Wir sind die Experten!

Gremienarbeit

Wir bringen unsere Expertise in Branchenverbände ein, beispielsweise in die Gremien des Zentralverbands der Elektroindustrie.

Automobilelektronik funktional sicher?
Wir sind die Experten!

Zusammenfassung

Der obige Abschnitt war ein Überblick der Entwicklung auf Systemebene aus der Perspektive der funktionalen Sicherheit gemäß ISO 26262.

Lassen Sie mich die 5 wichtigsten Lektionen zusammenfassen:

  • Sicherheitsaktivitäten müssen auf der Systemebene koordiniert werden.
  • Funktionale Sicherheitsanforderungen werden in technische Sicherheitsanforderungen detailliert, so dass sie mit der parallel zu entwickelnden Systemarchitektur umgesetzt werden können.
  • Systematische Fehler und zufällige Hardwarefehler müssen behandelt werden.
  • Sicherheitsanalysen sollten durchgeführt werden, um die Ursachen von Fehlern/Ausfällen und deren Auswirkungen systematisch zu identifizieren. Dies geschieht mit dem Ziel, die Spezifikation von Sicherheitsanforderungen, Sicherheitsmechanismen und Design abzusichern.
  • Die Entwicklungsergebnisse müssen systematisch integriert und auf mehreren Ebenen, von der Hardware-Software-Integration bis hin zum Gesamtfahrzeug, getestet werden, um die Erfüllung der Sicherheitsanforderungen und Sicherheitsziele nachzuweisen.

Wir unterstützen Sie dabei,

  • Ihre Prozesse nach den aktuellsten Normen der Sicherheit zu verbessern, um technisch zuverlässige, verfügbare, instandhaltbare und funktionale Produkte entwickeln und vermarkten zu können.
  • Sicherheitsmanagementsysteme konzipieren und umsetzen zu können.
  • durch Safety Audits zu bestätigen, dass Ihr Safety Management seinen Anforderungen gerecht wird.
  • zuverlässig beurteilen zu können, ob ein Lieferant entsprechende Komponenten tatsächlich beisteuern kann.
  • die Funktionale Sicherheit elektronischer Systeme und Komponenten bewerten zu können. 
  • Ihre Mitarbeiterinnen und Mitarbeiter bei allen Fragen der Funktionalen Sicherheit zu schulen.

Download Whitepaper