Bild 4: Die Safety-Entwicklung ist keine eigene Projektphase sondern ein begleitender Prozess der Systementwicklung.

Bild 2: Die Safety-Entwicklung ist keine eigene Projektphase sondern ein begleitender Prozess der Systementwicklung. (Bild: AVL)

Entwicklungspartnerschaften in verteilten Teams mit unterschiedlichem Wissensstand und kulturellem Hintergrund sowie die zunehmende Internationalisierung in der Systementwicklung erfordern ein aktives Steuern von Prozessen, um die Erstellung aller durch Normen geforderte Work Products jederzeit zu gewährleisten.

Bild 1: Konzeptphase – Aktivitäten mit potentiellen Kommunikationspfaden zwischen Cybersecurity und Safety.

Bild 1: Konzeptphase – Aktivitäten mit potentiellen Kommunikationspfaden zwischen Cybersecurity und Safety. SAE Vehicle Electrical System Security Committee, 2016.

Security und Safety zusammenführen

Sicherheitskritische eingebettete Systeme sind zunehmend Teil von Netzwerken, die untereinander und mit Cloud-Diensten interagieren. Eine zentrale Herausforderung solcher Netzwerke ist neben der Gewährleistung der Datensicherheit der Systeme (cyber-security related) die Gewährleistung der funktionalen Sicherheit (safety related). Dies betrifft fahrer-erlebbare Funktionen wie beispielsweise teilautonomes Fahren oder neue technologische Schwerpunkte im elektrifizierten Antrieb.

Die Funktionale Sicherheit befasst sich mit potentiellen Fehlern in der Elektrik/Elektronik, die zu Gefährdungen führen können. Präventive Designstrategien führen zu redundanten Systemen, Diagnoseabdeckung und Testmethoden, die ein sicheres Erkennen und Verhindern von Fehler gewährleisten.

Statt unterschiedlicher Systemdesigns mit dem Fokus auf Sicherheit, Funktion oder Cybersicherheit, besteht die Herausforderung darin, ein integriertes System zu entwickeln, das alle Anforderungen in einem einzigen Design abdeckt.

Eckdaten

Programmbestandteile des Functional Safety Management Tools von AVL:

  • Workflow & Abbildung der verwendeten Safety-Norm
  • Tailoring zum Anpassen des Entwicklungsumfang nach Normvorgaben
  • Development Interface Agreement (DIA) für die Budget- und Zeitplanung
  • Konsistente versionierte Datenablage
  • Automatisiertes konsistentes Reporting
  • Rollen- Rechte- und Zeitmanagement
  • Projektvorlagen in ähnlichen Projekten weiterverwenden

Das Hauptziel der Entwickler bei AVL ist die Anwendung universell einsetzbarer Methoden für das integrierte Systemdesign. Der Schwerpunkt liegt auf der Identifizierung und Bewertung von Anforderungen und Einschränkungen der Funktionalen Sicherheit in frühen Designphasen. Die Methodik ist mit einem Werkzeug, dem Functional Safety Management Tool, abbildbar. Im Fokus steht dabei eine effiziente und nachverfolgbare Anwendung der relevanten Normen (Bild 1).

Normen für die Fahrzeugentwicklung

Forschung und Industriepraxis haben zur international anerkannten Norm für Funktionale Sicherheit ISO 26262:20111 geführt, die auf der ISO 61508:2010, der entsprechenden Norm für die industrielle Automatisierung, basiert. Die kürzlich veröffentlichte zweite Edition ISO 26262:2018 schließt die auch Zweiräder und weitere Fahrzeuge ein. Mit der ISO 25119:2018 ist aktuell ebenfalls eine Norm für den Off-Highway-Bereich erschienen.

Die SAE-Richtlinie J30612 ist aktuell die einzige veröffentlichte Branchenvereinbarung für automobile Cybersicherheit. Mit der ISO CD 21434 wird zukünftig auch automobile Security zu einem einheitlichen Bestandteil des gesamten Entwicklungsprozesses. Sie beschreibt Aspekte für die Produktdefinition, das Design, die Implementierung sowie das Testen, nicht aber spezifische Technologien.

Herausforderung Prozessmanagement

Beim Prozessmanagement prägen individuelle Lösungen den aktuellen Stand der Technik. Sie basieren auf Office Tools, PLM-Werkzeugen zum Generieren einzelner Artefakte sowie Workbench-Applikationen zur Unterstützung bei der Erstellung von Arbeitsprodukten im Safety Lifecycle. Das sind beispielsweise Gefahren- und Risikoanalysen wie auch eine Modellierung der Systemarchitektur.

Im Bereich des Safety Engineering existieren Lösungen für Teilbereiche – holistische Ansätze für das Safety Management existieren proprietär. Komplexe Zusammenarbeitsmodelle zwischen Dienstleistern, System-Zulieferern und Fahrzeugherstellern erschweren das Nutzer- und Rechtemanagement, die Nachverfolgbarkeit und die Konsistenz.

Aktivitäten nach ISO26262:2018 werden typischerweise in Excel-Tabellen geplant und dokumentiert. Diese Tabellen listen Aktivitäten wie die Erstellung des Development Interface Agreement (DIA), das Tailoring der Norm auf das Projekt und die geforderten Work Products auf.

Das bringt Nachteile mit sich:

  • Eingeschränktes User Management – Zugriffsrechte auf alle Daten/Eingabefelder
  • Reduzierte Nachverfolgbarkeit – unkontrollierte Datenverbreitung und -änderung
  • Mangelnde Datenkonsistenz – Single Source und Integrität der Daten nicht garantiert
  • Performanz bei großen Datenmengen
  • Eingeschränkte Darstellung der Anforderungen

Das Functional Safety Management Tool

Die jeweilige Norm gibt das Rahmenwerk vor, um Funktionale Sicherheit der elektrischen und elektronischen (E/E) Systeme zu gewährleisten. Die AVL unterstützt die Steuerung des Entwicklungsprozesses mit einem Functional Safety Management Tool (FSMT), um alle Anforderungen effizient in verteilten Teams und Kundenprojekten abzubilden. So berücksichtigt und organisiert das Werkzeug mehr als 2000 Anforderungen und etwa 500 Work Products, welche von der ISO 26262:2018 auf knapp 400 Normseiten für den Entwicklungsprozess gefordert sind, und speichert jede Veränderung nachverfolgbar ab. Ein hierarchischer Ansatz fasst die Normteile als Cluster zusammen und verknüpft sie mit Aktivitäten, die nach Normstruktur vorgeschrieben sind.

Tasks, die die entsprechenden Maßnahmen im Prozess beschreiben beinhalten Objectives, Methoden und Deliverables:

  • Objectives als Ziele der Maßnahmen; sie sind durch firmeninterne Ziele erweiterbar
  • Methoden, die zur Abarbeitung der Aufgaben in der jeweiligen Sicherheitsanforderungsstufe (SIL) zur Verfügung stehen
  • Deliverables als versionierte Work Products

Die Normen ISO 26262:2011 und ISO 26262:2018 sind im FSMT als Referenzprozesse verfügbar. Ein daraus instanziiertes Projekt lässt sich über folgende Programmbestandteile strukturieren und steuern:

Workflow & Abbildung der verwendeten Safety-Norm

Die Programmfunktion Ansichten bildet die für den Benutzer relevanten Daten ab, wobei jede Ansicht die speziell für die Aufgabe relevante Funktion abbildet. Zum Beispiel sind das Deliverables View, Meilensteinplan und Reviews für Deliverables, Tailoring, Definitionen projektrelevanter Inhalte und weitere.

Das Tailoring beschreibt das Anpassen von Aktivitäten und Anforderungen des Entwicklungsvorgangs entsprechend der jeweiligen Norm. Jede Anpassung ist explizit zu dokumentieren. So werden Eingaben erzwungen und automatisch in den Safety-Plan oder im Safety Case Report übernommen.

Die Aufteilung von Verantwortlichkeiten der Aktivitäten zwischen Kunden und Entwicklungsparteien ist angebotsrelevant und dient der Abgrenzung des Entwicklungsumfangs. Das Development Interface Agreement (DIA) ist die Ausgangsbasis für die Budget- und Zeitplanung der Safety-Aktivitäten. Im FSMT ist eine solche DIA einfach und nachvollziehbar zu planen und anschließend im Zusammenarbeitsmodell transparent durch alle Beteiligten nutzbar.

Versionierte Datenablage und konsistentes Reporting

Im Rahmen der Entwicklung sind domänenspezifische Dokumente, die Safety Engineering Work Products, zu erstellen. Dies betrifft durchgeführte Hazard And Risk Assessments (HARA), Failure Mode and Effects Analysis (FMEA) und Functional and Technical Safety Concept (FSC, TSC). Einzelnen Personen betreuen meist unterschiedliche Teilprojekte über lange Zeiträume. Eine Zusammenfassung mehrerer im Projekt versionierter Deliverables zu einem Arbeitsprodukt stellt dann nach ISO 26262:2018 den Nachweis zur gesamthaften Erfüllung von Anforderungen dar. Die Work Products kommen in automatisch generierbaren Safety Case Reports als strukturierte Übersicht zur Verwendung.

Verschiedene Revisionskontrollsysteme unterstützten in Kundenprojekten, um einen rechtssicheren dokumentierten Datenaustausch mit den Partnern zu gewährleisten.

Mithilfe benutzerdefinierter Vorlagen und Konfigurationen der in der Software vorliegenden Daten lassen sich dynamische und statische Reporte generieren. So ist es möglich, Deckblätter, allgemeine Einleitungen oder die Erklärung des Aufbaus als Vorlage zu integrieren und die Kerninhalte des Reportes nach Bedarf zu spezifizieren. Auch sind damit regelmäßige Statuspräsentationen unter Systementwicklern, Projektmanagern und Projektleitern stets effizient vorzubereiten.

Rollen- Rechte- und Zeitmanagement

Eine der zentralen Herausforderungen ist die Zusammenarbeit in verteilten Entwicklerteams und Personalwechsel. Ungewollte Anpassung von Templates, versehentliches Überschreiben und Löschen von Prozesselementen sind nicht erwünscht. Es ist in der Praxis eine große Aufgabe gültige Dokumente und Zeitplanungen bei Änderungen für die Beteiligten in verschiedenen Systemen konsistent zu halten.

Bild 4: Die Safety-Entwicklung ist keine eigene Projektphase sondern ein begleitender Prozess der Systementwicklung.

Bild 2: Die Safety-Entwicklung ist keine eigene Projektphase sondern ein begleitender Prozess der Systementwicklung. AVL

Eine integrierte Benutzerverwaltung erlaubt es dem Functional Safety Manager (FSM) unterschiedliche Rechte zu vergeben. So kann er als Projektadministrator alle projektbezogenen Eigenschaften anpassen, während der Functional Safety Engineer (FSE) die Work Products einpflegt und Statusdetails ändern kann. Eine Import-/Export-Schnittstelle erlaubt es, ein Template für die Planung über unterschiedliche Projektphasen zu erstellen, extern anzupassen und wieder einzulesen.

Bestimmte Arbeitsprozesse wie „Evidence of Competence“, “Evidence of Quality Management”, aber auch Tailoring oder DIA-Einträge wiederholen sich bei ähnlichen Projekten. Projektvorlagen erlauben es eine Ausgangsbasis für bestimmte Entwicklungstypen (beispielsweise für Batteriefahrzeuge oder autonomes Fahren) anzulegen. Der FSM kann sich damit auf kundenspezifische und nicht wiederkehrende Eigenschaften für ein Projekt fokussieren.

Prozesse planen, nachverfolgen und umsetzen

Wird ein Fahrzeug nach einer bestimmen Safety-Norm entwickelt, so gibt diese die Aktivitäten und Ziele in den einzelnen Projektphasen der Entwicklung vor. Häufig ist die Safety-Entwicklung fälschlicherweise als eigene Projektphase im Entwicklungsprozess angesehen, anstatt sie als begleitenden Prozess der Systementwicklung zu verstehen. Bild 2 veranschaulicht diesen Zusammenhang zwischen typischen Arbeitsprodukten/Aktivitäten in den Entwicklungsphasen beispielhaft.

Die Anforderungen an den Aufbau und Inhalt solcher Work Products leiten sich typischerweise aus folgenden Einflüssen ab:

  • Die verwendete Safety-Norm gibt die Kerninhalte und Ziele des Arbeitsproduktes vor.
  • Der spezifische Systementwicklungsprozess gibt an, wie Work Products zu erarbeiten sind und welche Dokumente/Vorlagen dafür zur Anwendung kommen sollen (intern und extern).
  • Kundenspezifische Merkmale geben Zusatzanforderungen von Kundenseite wieder.

Um diese Anforderungen klar ersichtlich und gesammelt zusammenzuführen, lassen sich die Projektaufgaben basierend auf einem kombinierten FSMT-Standard (Sicherheitsnorm + spezifische Prozesse) planen, nachverfolgen und umsetzen (Bild 3).

Bild 5: Kombinierte Prozesssicht.

Bild 3: Kombinierte Prozesssicht. AVL

Damit sind Prozesse individuell kombinierbar. Diese sind im Tool allgemein gültig und lassen sich für jedes Projekt anpassen. FSMT wurde nach ISO 26262-8:2018 zertifiziert und findet in Projekten mit höchsten Anforderungen bis ASIL D (Automotive Safety Integrity Level) Verwendung.

Den Projektfortschritt genau verfolgen

Sowohl für das Projektmanagement, als auch für die Organisation hat die zentrale Übersicht zum Status der Sicherheitsaktivitäten hohe Relevanz. Zum einen ist das wichtig zur Beurteilung des Projektfortschritts und der Einleitung von eventuell notwendigen Gegenmaßnahmen, zum anderen dient es als Nachweis für die normkonforme Entwicklung.

Langfristig bietet die Verwendung des Verwaltungssoftware durch die zentrale Ablage der Projektdaten zudem relevante Erfahrungswerte für den Personalaufwand und die Akquisition von Projekten. Die Übersicht von technologischen Entwicklungsschwerpunkten und Trends hilft Synergien zu identifizieren.

Mithilfe der integrierten Management-Ansicht sind projektübergreifend Aussagen über Aufgaben möglich, die offen, in Bearbeitung oder geschlossen sind (Bild 4).

Bild 6: Auszug aus der Darstellung Management.

Bild 4: Auszug aus der Darstellung Management. AVL

Die Bedeutung von der funktionalen operativen Sicherheit von Systemen und Fahrzeugen steigt mit der zunehmenden Vernetzung und Komplexität der elektrischen und elektronischen Systeme für Antrieb und autonomes Fahren im Fahrzeug weiter. Die Entwicklung dieser Systeme bedingt ein funktionierendes Functional Safety Management zur Absicherung. Im Rahmen von Entwicklungsprojekten setzt die AVL bewährte Vorgehensweisen im Safety-Prozess ein und nutzt das eigenentwickelte Functional Safety Management Tool zur weiteren Verbesserung. Die Werkzeugkette unterstützt heute die ISO 26262:2011 wie auch die ISO 26262:2018 und wird künftig auch Prozesse aus der ISO 25119:2018 sowie relevante Security-Standards unterstützen. Neben Serienprojekten ist das Werkzeug in den EU-Forschungsprojekten Afar-Cloud und Ghost im Einsatz.

Thomas Wambera

AVL Deutschland

Dr. Georg Macher

Technische Universität Graz, Österreich

Bernhard Frohner

AVL List in Graz, Österreich

(jwa)

Sie möchten gerne weiterlesen?

Unternehmen

AVL List GmbH

Hans-List-Platz 1
8020 Graz
Austria