26880.jpg

Vector Informatik GmbH

Die Einführung der internationalen Norm ISO 26262 zur funktionalen Sicherheit von elektrisch/elektronischen Systemen im Automobil hat das Bewusstsein für dieses Thema in der Industrie deutlich verstärkt. Viele Hersteller und Lieferanten suchen daher nach Ansätzen, die Vorgaben aus der Norm pragmatisch und effizient zu erfüllen und gleichzeitig der steigenden Komplexität sicherheitsrelevanter Funktionen gerecht zu werden. Das Entwickeln sicherheitskritischer Systeme führt im Vergleich zu herkömmlichen Entwicklungen zu erhöhten Aufwänden. So sind zusätzliche Aktivitäten bei gleichbleibenden Rahmenbedingungen hinsichtlich Zeitplänen, Ressourcen und Kosten, unvermeidbar. Bestehende Entwicklungs-, Analyse- und Testmethoden sowie die dazugehörenden Werkzeuge sind oft fragmentiert und lassen sich nur mit großem Aufwand in einen durchgängigen Prozess integrieren.

Ganzheitliche Betrachtung von Systemarchitekturen

Eine wesentliche Forderung aller gängigen Sicherheitsnormen im Automotive- sowie im Non-Automotive-Bereich (zum Beispiel IEC 61511 Prozessindustrie, IEC61513 Kernkraftwerke, EN 50128 Eisenbahn) besteht darin, das Erfüllen der Systemsicherheitsziele durch das entwickelte Systemkonzept nachzuweisen. Sicherheitsziele werden typischerweise durch Gefährdungs- und Risikoanalysen auf der funktionalen Systemebene identifiziert. Die aus den Sicherheitszielen abgeleiteten funktionalen und technischen Sicherheitsanforderungen sind dann Systemkomponenten zuzuordnen. Das korrekte Umsetzen dieser Sicherheitsanforderungen ist durch eine geeignete Kombination von Reviews, Analysen und Tests sicherzustellen.

Das Erreichen der Systemsicherheitsziele hängt von einer Vielzahl verschiedener Faktoren ab. Ein Beispiel hierfür sind fehlerhaft programmierte Software-Funktionen oder zufällige Hardware-Fehler in kritischen Komponenten. Solche isolierten Fehler lassen sich mit gängigen Entwicklungsmethoden, wie in der ISO 26262 empfohlen, relativ einfach vermeiden oder zumindest entdecken und damit beherrschen. Problematischer wird es, wenn eine Kombination verschiedener Systemfaktoren aus unterschiedlichen Architekturebenen die Sicherheitsziele beeinflusst. Mit herkömmlichen, dokumentenbasierten Entwurfsmethoden sind solche Zusammenhänge bei komplexen Systemen kaum zu durchblicken. Hier zwei Beispiele für typische Entwurfsfehler:

Während der SW-Entwicklung werden inkorrekte Annahmen über die Integrität des Kommunikationsmediums zwischen zwei Funktionen gemacht. Somit werden Kommunikationsfehler nicht ausreichend berücksichtigt. Beispielsweise kann eine nachträgliche Umverteilung der SW-Funktionen auf verschiedene ECUs in unterschiedlichen Bussegmenten zur Verletzung der ursprünglichen Annahme führen, ohne dass dies dem SW-Entwickler bewusst wird.

Eine Hardware-Komponente zeigt durch Positionierung in einem Fahrzeugbereich, der extremen Umweltbedingungen wie beispielsweise Feuchtigkeit, mechanischem Stress oder elektromagnetischen Störungen ausgesetzt ist, untypisch hohe Ausfallraten. Die erhöhten Ausfallraten werden im Sicherheitskonzept nicht berücksichtigt.

Um solche komplexen Zusammenhänge während der Entwurfsphase berücksichtigen zu können, ist ein ganzheitlicher Ansatz zur Systemmodellierung notwendig. Dieser Ansatz vereint in einem Datenmodell alle funktionalen und nichtfunktionalen Anforderungen, den logischen Systementwurf, die Netzwerk-Architektur sowie die Software- und Hardware-Komponenten-Architektur. Ebenso sind der Leitungssatz sowie die topologische Verteilung der Komponenten und des Kabelbaums im Fahrzeug zu berücksichtigen. Wichtig ist hierbei die Möglichkeit, die Zusammenhänge der verschiedenen Architekturebenen sowie die domänenspezifischen Attribute der modellierten Artefakte (beispielsweise Buslatenzzeiten, Hardware-Ausfallraten oder Temperaturbereiche von Bauräumen) ebenfalls beschreiben zu können. Auf Basis dieser Daten lassen sich dann Analysefragen formulieren und teilweise automatisiert durchführen, wobei eine derartige Frage zum Beispiel so lauten könnte: „Werden Kabel, die für das Sicherheitskonzept relevante Signale übertragen, in crash-gefährdeten Bereichen verlegt?“

Modellbasierte Sicherheitsanalysen

Die ISO 26262 fordert, Sicherheitsanalysen auf System-, Software- und Hardware-Ebene durchzuführen, damit Schwächen im Entwurf entdeckt und verbessernde Maßnahmen ergriffen werden können. Ein Beispiel für solche Analysen ist die Fehler-Möglichkeits- und Einflussanalyse (FMEA). Mit ihr werden potenzielle Fehler einzelner Komponenten identifiziert und deren Auswirkungen auf Systemziele sowie deren

Round-Trip-Engineering für Safety-Designs: Das Durchführen von Sicherheitsanalysen sowie das Modellieren des Sicherheitskonzepts und des Systementwurfs erfolgen in einem Modell. Dadurch lassen sich Abhängigkeiten und Auswirkungen von Änderungen unmittelba

Round-Trip-Engineering für Safety-Designs: Das Durchführen von Sicherheitsanalysen sowie das Modellieren des Sicherheitskonzepts und des Systementwurfs erfolgen in einem Modell. Dadurch lassen sich Abhängigkeiten und Auswirkungen von Änderungen unmittelbaVector Informatik GmbH

Auftretenswahrscheinlichkeit betrachtet. Diese Analyseart ist gut geeignet, um Komponenten zu identifizieren die aus Sicht der Sicherheitsziele kritisch sind. Das Ergebnis ist aber sehr stark von der Qualität und dem Umfang des modellierten Systementwurfs abhängig auf dem die Analyse basiert. Bei nicht ausreichender Dokumentation der Systemabhängigkeiten greifen die Ingenieure häufig auf ihre individuelle Erfahrung und ihr Wissen zurück, was oft zu den im Beispiel oben angeführten Problemen führt.

Eine ganzheitliche Modellierung des Systems ist die optimale Voraussetzung für das Durchführen von Sicherheitsanalysen. Beim Durchführen der Analysen greift der Safety-Experte direkt auf Informationen aus dem Modell zu. Abhängigkeiten, insbesondere zwischen unterschiedlichen Architekturebenen, lassen sich automatisiert analysieren und deren Auswirkungen auf die Systemsicherheit bewerten. Die sich aus der Analyse ergebenden Maßnahmen werden direkt im Modell umgesetzt und mit der entsprechenden Analyse verlinkt. Dadurch wird eine Verfolgbarkeit zwischen dem Entwurf, der Analyse und den betroffenen Sicherheitszielen hergestellt, die bei der Führung des Sicherheitsnachweises sowie für Impaktanalysen bei Systemänderungen unabdingbar ist.

Die enge Verzahnung von dem System-entwurf, der Sicherheitsanalyse und dem Entwurf des Sicherheitskonzeptes erlaubt es, Auswirkungen von Modell-Änderungen unmittelbar zu analysieren und zu bewerten. Dadurch entfallen aufwändige Redesigns, die im Falle des sequentiellen Arbeitens des Entwurfs und der Sicherheitsanalyse unvermeidbar sind. Darüber hinaus lassen sich auch mehrere Umsetzungsvarianten eines Systems vergleichen und bewerten. Eine Systemoptimierung unter Einbeziehung sicherheitstechnischer Gesichtspunkte findet somit schon in einer frühen Phase der Systementwicklung statt.

Produktlinienansatz bringt Effizienzsteigerung

Die Personalisierung von Fahrzeugen, also das Bereitstellen unterschiedlicher Varianten und Ausprägungen, führt auch aus Systemsicht zu einer schier unüberschaubaren Variantenvielfalt. Der Safety-Engineer steht damit zunächst vor der Herausforderung, für jede Variante des Systems den geforderten Sicherheitsnachweis zu erbringen. Ein Weg, dieser Herausforderung zu begegnen, ist die Anwendung eines Produktlinienansatzes. Dieser Ansatz basiert auf der Analyse (Domain-Analysis) variantenbehafteter Systeme (Produktfamilien) hinsichtlich Gleichteilen (Commonalities) und Unterschieden (Variabilities). Das Identifizieren der Gleichteile bildet die Grundlage dafür, diese über eine Reihe von Produkten (Fahrzeugen) hinweg wiederzuverwenden. Zudem fallen Aufwände für das Erstellen von Anforderungsanalysen, Implementierungen oder Tests nur einmal an.

Gemeinsame Elemente der Sicherheitsarchitektur werden für unterschiedliche Fahrzeuge wiederverwendet.

Gemeinsame Elemente der Sicherheitsarchitektur werden für unterschiedliche Fahrzeuge wiederverwendet.Vector Informatik GmbH

Um das Konzept der Wiederverwendung auch für die Entwicklung sicherheitskritischer Systeme nutzbar zu machen, muss der Produktlinienansatz auf Gefahren- und Risikoanalysen sowie auf Sicherheitskonzepte ausgeweitet werden. Sofern sich diese Analysen und Konzepte auf einen gemeinsamen Satz von Features beziehen, stehen sie zur Wiederverwendung bereit. Aus dem funktionalen Sicherheitskonzept werden die technischen Sicherheitsanforderungen für konkrete Fahrzeugprojekte abgeleitet. Konkrete Fahrzeuge sind zum Beispiel durch eigene Betriebszustände, Sys- temarchitektur etc. gekennzeichnet. Durch das Anwenden der Domain-Analyse auf die technischen Sicherheitsanforderungen stehen auch Teile dieser Anforderungen zur Wiederverwendung bereit.

Um den Mehrwert des Wiederverwendens zu maximieren, lässt sich die Domain-Analyse ebenfalls auf Systemkomponenten (Software-Komponenten, Hardware-Komponenten) ausdehnen. Das Führen des Sicherheitsnachweises wird durch das Wiederverwenden eines Teils der Argumentationsstruktur (Safety Case Argumentation Structure) unterstützt. Annahmen über die konkrete Fahrzeugumgebung werden dabei als Anforderungen formuliert, deren Umsetzung oder Gültigkeit dann im konkreten Kontext zu analysieren sind.

Der modellbasierte Ansatz bildet die Voraussetzung für variantenspezifisch durchgeführte Analysen und Konsistenzprüfungen. Auf diese Weise ist sichergestellt, dass beispielsweise alle im Sicherheitsnachweis angeführten Maßnahmen und die aus dem wiederverwendeten Sicherheitskonzept resultierenden technischen Anforderungen im konkreten Fahrzeug auch tatsächlich umgesetzt werden. Wenn beispielsweise eine im Sicherheitskonzept vorgesehene Redundanz nicht vorhanden ist, identifiziert eine variantenspezifische Konsistenzprüfung dies als nicht erfüllte Anforderung.

Umsetzung mit Tools

Der alles entscheidende Erfolgsfaktor ist die Verfügbarkeit einer bewährten Werkzeugunterstützung, um den hier beschriebenen Paradigmenwechsel vom dokumentenzentrierten hin zum modelbasierten Ansatz in der täglichen Praxis umzusetzen. Eine wesentliche Anforderung an ein Werkzeug ist die Eignung zum Beschreiben komplexer Systeme durch ein entsprechendes semantisches Datenmodel. Aber auch domänenspezifische grafische Notationen und die Unterstützung bei Analysen sowie beim Führen des Sicherheitsnachweises sind unabdingbar.

Weitere Anforderungen ergeben sich aus der Zusammenarbeit in größeren Teams, wo die Bereitstellung einer Kolaborationsplattform für die Datenhaltung im Single-Source-Prinzip sowie der Austausch zwischen allen Projektbeteiligten gefragt sind. Zuständigkeiten und Verantwortlichkeiten müssen dabei über ein Rechte- und Rollenkonzept abgebildet werden können. Aus der zeitlichen Nachverfolgbarkeit (Versionshistorie) ergibt sich die Forderung nach einem integrierten Versions- und Konfigurationsmanagement.

Vector Informatik bietet mit PREEvision ein seit mehr als fünf Jahren im Markt etabliertes und bewährtes Werkzeug für Modelbasiertes Systems Engineering an. Darüber hinaus unterstützt PREEvision in den Bereichen Test (Testdatenmanagement), Planung (Produkt- und Releasemanagement) und Änderungsmanagement. Mit der neuesten Version unterstützt PREEvision einen ISO-26262-konformen Ansatz zur Modellierung, Analyse und Test von funktionalen Sicherheitskonzepten.

Albert Habermann und Dr. Simon Burton

: Albert Habermann ist als Projekt Manager im Bereich Customer Services für das Architektur-und Systems-Engineering-Werkzeug PREEvision bei Vector Informatik tätig. Dr. Simon Burton ist Safety-Spezialist und war zuletzt als Produktmanager für das Architektur- und Systems-Engineering-Werkzeug PREEvision bei Vector Informatik tätig.

(av)

Sie möchten gerne weiterlesen?

Unternehmen

Vector Informatik GmbH

Ingersheimer Str. 24
70499 Stuttgart
Germany