Wiederverwendung von Embedded-Software in Safety-kritischen Automotive-Systemen

Wenn es um Safety-Zertifizierung geht, können ursprünglich für andere Projekte entwickelte Standardelemente nicht so einfach in neuen Code implementiert werden. ISO 26262 spricht hierbei von „Safety Elements out of Context“ (SEooC). Wobei handelt es sich hier genau, und was gibt es bei der Implementierung solcher Elemente zu beachten?

Anbieter zum Thema

Ansys

eSystems MTG GmbH

HCC-Embedded

Ein ganz entscheidender Wesenszug einer effizienten Produktentwicklung ist es, dass das Rad nicht immer wieder von Neuem erfunden werden muss. Im Bereich der Embedded-Programmierung begann dieses Konzept mit der Verwendung vertrauenswürdiger Bibliotheken, und es wurde ergänzt durch Konzepte wie die objektorientierte Programmierung und Java, die uns das Entwickeln der heutigen komplexen Systeme ermöglichen.

Safety-Normen wirken ebenfalls auf die Verwendung erprobter Softwareelemente hin, jedoch stellen sich hierbei komplexe Herausforderungen ein, denn es entstehen unweigerlich Schwachstellen, wenn man in ein Projekt Elemente einbringt, bei deren Entwicklung nicht das gleiche Maß an Stringenz angewandt wurde. Aus diesem Grund werden in den Safety-Standards Möglichkeiten spezifiziert, die Komponenten für die Verwendung in einem Safety-kritischen Projekt zu validieren.

Bildergalerie

Das Streben nach Effizienz kann jedoch auch zum Entstehen von Konzepten führen, die in Safety-kritischen Systemen einfach nicht funktionieren. COTS-Software (Commercial-off-the-shelf), also gleichsam Standardsoftware „von der Stange“, ist ein Begriff, der in zahlreichen Branchen auf vielerlei Weise verwendet wird. Auch wenn diese Bezeichnung im industriellen Safety-Bereich eine ganz bestimmte Bedeutung hat, kann er als Vorwand dafür genutzt werden, Abkürzungen zu nehmen, was in Safety-Projekten aber schlicht nicht hinnehmbar ist, denn ein System ist stets nur so sicher wie sein schwächstes Element. Der Begriff SOUP (Software of Unknown Pedigree/Provenance; dt.: Software unbekannter Herkunft) kommt im Medizintechnik-Standard IEC 62304 vor, aber es gibt gute Gründe, in einem Safety-Projekt nichts „Unbekanntes“ zu benutzen. Man kann solche Elemente noch so gründlich prüfen, aber wie will man Jahre später etwas warten, dessen Ursprünge man nicht kennt?

Bedeutung des Begriffs „Safety Element out of Context“ (SEooC)

Im Automotive-Bereich dient das in der Norm ISO 26262-10 definierte „Safety Element out of Context“ (SEooC) als Methode zur Verwendung von Komponenten, die ursprünglich nicht für das betreffende Projekt konzipiert wurden, in einem Fahrzeug.

Der Begriff SEooC ist ein wenig umständlich, aber er definiert das Problem durchaus zutreffend, denn sämtliche Softwarebibliotheken, die man in ein System integriert, wurden schließlich „außerhalb des Kontexts“ entwickelt. Sie wurden für die Umsetzung einer bestimmten Funktionalität konzipiert, ohne zu wissen, wie sie innerhalb des Zielsystems eingesetzt werden. Der Begriff „Element“ zeigt an, dass es sich hier um eine Einheit oder ein Modul mit einem ganz bestimmten Funktionalitätsbereich handelt. Das Wort „Safety“ wiederum lässt erkennen, dass das Modul im Kontext eines gewissen Umfangs an Safety-Anforderungen entwickelt wurde.

Gemäß ISO 26262-10-9 lässt sich zwischen zwei grundlegenden Arten von Software-SEooCs unterscheiden:

Das Proven-in-Use-Konzept (betriebsbewährt)

Bei Software dieser Art wird das Proven-in-Use-Argument (nebst ergänzenden Maßnahmen) genutzt, um eine COTS-Komponente nach einem bestimmten Safety-Level zu validieren. Wie dies erreicht werden kann, ist in der ISO 26262-8-14 spezifiziert, jedoch bleibt im Zusammenhang mit Software viel Interpretationsspielraum. Entscheidend ist hier das Konzept der beobachtbaren Fehler mit Aufzeichnungen aus dem Einsatz eines Produkts, sodass alle auftretenden Fehler zuverlässig aufgezeichnet und gesammelt werden können, um ein zutreffendes Bild von der Zuverlässigkeit der Software zu erhalten. Dies muss in die jeweilige Konfiguration einbezogen werden.

Die Frage, wie relevant diese Ergebnisse für das jeweilige Zielprojekt tatsächlich sind, ist allerdings alles andere als trivial, da die Konfiguration und die Einsatzumgebung eines Safety-Projekts so gut wie sicher von den Rahmenbedingungen der Testfälle abweichen, die zum Ermitteln der Zuverlässigkeit der Software verwendet wurden. Außerdem kann man nicht unbedingt darauf vertrauen, dass ein nicht nach Safety-Standards entwickeltes Softwareelement alle Fehler zuverlässig meldet.

Das ISO-26262-6-Konzept

Der standardmäßige Weg zur Entwicklung eines Softwareelements in Safety-Systemen für den Automotive-Bereich ist in Abschnitt 6 der Norm ISO 26262 (Entwicklung funktionaler Sicherheit in Straßenfahrzeugen) definiert. Es ist von der kompletten Entwicklung des Zielsystems nach dem V-Modell abgeleitet, wie es in den vorausgehenden Abschnitten der Norm definiert wurde, und stellt in sich ebenfalls ein V-Modell dar.

Da das betreffende Element außerhalb des Kontexts entwickelt und somit nicht vom Safety-Plan des Zielprojekts abgeleitet wird, sind ergänzende Maßnahmen erforderlich. Die wichtigste zusätzliche Aktion ist das Aufstellen einer Liste von Annahmen bezüglich des Betriebs des SEooC. Diese Annahmen gilt es im Zuge der Integration auf der Zielplattform zu validieren.

Branchenübergreifende Wiederverwendung

Aus praktischer Sicht ist es sinnvoll, viele eingebettete Komponenten über mehrere Branchen hinweg anzuwenden. Zum Beispiel ist ein Dateisystem zum Abspeichern von Daten oder ein Netzwerk-Stack zum Übertragen von Daten nicht branchenspezifisch. Im Idealfall können die in einem Projekt gewonnenen Vorteile auch in neuen Projekten genutzt werden – unabhängig davon, in welchem Industriezweig letztendlich der Einsatz erfolgt.

Hinsichtlich der Software sind die Safety-Anforderungen zum Entwickeln von Software in den verschiedenen Branchen weitgehend ähnlich, auch wenn abhängig vom geforderten Safety-Level ein unterschiedliches Maß an Stringenz angewandt wird. Wählt man ein gemäß ISO 26262-6 entwickeltes SEooC-Konzept, so erhält man eine solide Basis für die normübergreifende Zuordnung von Artefakten (z. B. IEC 61508 für funktionale Sicherheit in der Industrie oder IEC 62304 für Medizingeräte).

Definition des ASIL für SEooCs

In sämtlichen Safety-Normen werden Safety-Levels spezifiziert. Je gravierender die Folgewirkungen eines Ausfalls im Zielsystem sind, um so strikter sind die Maßnahmen, die für die Implementierung und Validierung der Software vorgeschrieben sind. Die Festlegung eines Automotive Safety Integrity Level (ASIL) für ein SEooC kann sich problematisch gestalten.

Am einfachsten ist es, die Entwicklung stets am höchsten ASIL (ASIL/D) auszurichten. In diesem Fall ist die Integration in beliebige Projekte ohne größere Nacharbeiten möglich, und auch die Übertragung von einer Branche zur anderen ist einfacher. Nachteilig hieran ist allerdings, dass derartige SEooCs deutlich teurer sind als solche, die nach einem niedrigeren ASIL entwickelt wurden.

Abdeckung des gesamten Softwarewartungs-Lebenszyklus

Ein entscheidender Bestandteil einer jeden Safety-Projektentwicklung ist die Fähigkeit zur Reaktion auf Probleme, die während der Entwicklung oder nach der Freigabe auftreten. Sobald ein Projekt ausgereift ist, benötigt man eine Methodik zur zuverlässigen Modifikation des Projekts beim Auftreten etwaiger Probleme.

Eine entscheidende Stärke des ISO-26262-6-Konzepts ist folgender Aspekt: Da sämtliche Standard-Artefakte mit Rückverfolgbarkeit zwischen Design, Implementierung und Test hervorgebracht wurden, lässt sich eine umfassende und exakte Auswirkungsanalyse durchführen, und die daraus resultierenden Änderungen lassen sich präzise ausführen und außerdem so vornehmen, dass die künftige Wartbarkeit sichergestellt ist. Je weiter man nach der Projektfreigabe voranschreitet (in Bezug auf Zeit und Personal), umso entscheidender ist es, über die Artefakte mitsamt den zugehörigen Prozessen zu verfügen, damit die Änderungen auf sichere Weise vorgenommen werden können.

Wie lassen sich SEooCs beziehen?

SEooCs können in Safety-Systemen als eingebettete Komponenten dienen und die Kosten senken. Das Design eingebetteter Komponenten für die Wiederverwendung in einem Safety-Kontext ist allerdings zwangsläufig komplex, sodass der Bezug dieser Komponenten mit Bedacht erfolgen muss. Im Interesse optimaler Ergebnisse muss die Entwicklung in einer Umgebung erfolgen, die auf die Anforderungen des Lebenszyklus von Safety-Produkten abgestimmt ist.

Am besten ist es, ein vollständiges Safety-Element gemäß ISO 26262-6 zu entwickeln und die Annahmen und Testfälle für die Wiederverwendung vorzubereiten. Zusätzlich wird ein Projektmanagement-System benötigt, mit dem sich jede kundenseitige Verwendung eines SEooC in einem semi-unabhängigen Projekt pflegen lässt, damit für das betreffende Projekt der gesamte Softwarewartungs-Lebenszyklus unabhängig angewandt werden kann.

SOTIF und ISO 26262

Funktionale Sicherheit mit IEC 61508: Systematische Fehler mit Struktur und Prozessen eindämmen

* Dave Hughes ist Gründer und CEO von HCC Embedded in Budapest.

(ID:45716231)