Nutzung von Simulink für Projekte nach ISO 26262

Ingenieure aus der Automobilindustrie, die an sicherheitsrelevanten Embedded Systems für klassische und autonome Fahrzeuge arbeiten, sind auf der Suche nach effizienten Wegen, um die von der ISO^® 26262 [1], einer Norm für funktionale Sicherheit bei der Entwicklung von Straßenfahrzeugen, vorgeschriebenen Prozessanforderungen zu erfüllen.

Bei all der Aufmerksamkeit, die autonome Fahrzeuge in den Medien erfahren, mangelt es keineswegs an Ratschlägen. Allzu oft konzentrieren sich diese Empfehlungen jedoch auf die neueste Codierungsmethode oder das aktuellste Fehlerbehebungs-Tool. Wie Branchenexperten bereits seit langem erkannt haben, kommt es bei der Sicherheit vielmehr darauf an, dass das System und seine Anforderungen übereinstimmen, als auf die Software und ihre Codierung [2].

Mit der kontinuierlichen und diskreten Zeitsimulation als Grundlage lässt sich mit Model-Based Design und Simulink^® Ihr komplettes System unter einer Vielzahl von Fahrbedingungen und Fehlerszenarien entwickeln und testen, noch lange bevor Sie sich auf das Testgelände begeben oder Flottentests durchführen. Darüber hinaus wird eine Reihe von Prozesstätigkeiten unterstützt, die in der ISO-Norm 26262 festgelegt sind, wie etwa die Tool-Qualifizierung. Das IEC Certification Kit enthält detaillierte Informationen zu diesen Möglichkeiten und stellt Tool-Zertifikate und Berichte der internationalen Zertifizierungsstelle TÜV SÜD zur Verfügung.

Dieser Artikel enthält den vom TÜV SÜD zugelassenen Workflow zur Nutzung von Simulink für Projekte gemäß ISO 26262. Nach einer einleitenden Erläuterung der ISO 26262 und des Model-Based Design werden folgende Punkte behandelt:

• Entwicklung von Anforderungen
• Entwurfsmodellierung
• Entwurfsverifikation
• Codegenerierung
• Code-Verifikation
• Tool-Qualifizierung

ISO 26262 und Model-Based Design

Zur ISO 26262 gehören Anleitungen für die manuelle Entwicklung und den Code sowie für das Model-Based Design. Dabei werden insbesondere fünf verschiedene Anwendungsfälle des Model-Based Design aufgeführt [3]:

• Spezifikation von Software-Sicherheitsanforderungen
• Entwicklung der Softwarearchitektur
• Entwicklung und Implementierung von Softwareeinheiten, mit oder ohne Codegenerierung
• Entwicklung, Implementierung und Integration von Softwarekomponenten, einschließlich der Codegenerierung aus Software-Komponentenmodellen
• Statische und/oder dynamische Verifikation

Ferner wird auf einige der Vorteile des Model-Based Design hingewiesen [3]:

Neben den spezifischen Gründen für den Einsatz von MBD (z. B. Simulation oder Codegenerierung) ist eine adäquat definierte Syntax und Semantik eine wichtige Grundlage für die Erfüllung von Kriterien wie Verständlichkeit, Eindeutigkeit, Korrektheit, Konsistenz und Verifizierbarkeit von Informationen oder Arbeitsprodukten, die durch Modelle beschrieben werden, insbesondere wenn verschiedene Akteure zusammenarbeiten.

In der Norm wird die grafische Modellierung erwähnt und darauf hingewiesen, dass Modellierungstools für die Softwareentwicklung semi-formale Methoden verwenden. Darin heißt es, dass die Modellierung nicht nur die zu realisierende Funktionalität (die Embedded Software) erfasst, sondern auch die Simulation des realen physikalischen Systems (Fahrzeug- und Umgebungsmodell) ermöglicht, um ein vollständiges Systemmodell zu erstellen:

Zusammen mit den Modellierungs- und Kodierungsrichtlinien können Modelle verwendet werden, um Software auf einer höheren Abstraktionsebene zu entwickeln, zu implementieren und zu integrieren

und

Modelle können auch als Möglichkeit zur Durchführung oder Unterstützung von Verifikationsmaßnahmen dienen (z. B. ein Regelstreckenmodell, das für Hardware-in-the-Loop-Tests von geschlossenen Regelungen benötigt wird, indem die Umgebung des zu testenden Geräts simuliert wird). Die Verwendung von Modellen zu Verifikationszwecken kann die frühzeitige und effiziente Erkennung von Fehlern in Arbeitsprodukten (darunter auch Software), eine effizientere Generierung von Testfällen, hochgradig automatisierte Tests oder sogar formale Verifikationsverfahren ermöglichen

Abbildung 1 zeigt ein typisches Simulink-Modell eines Closed-Loop-Systems. Es besteht aus einem Regler und einer Regelstrecke sowie aus Signalprozessoren. In der ISO-Norm 26262 stellen die Systemanforderungen und die Spezifikation des Architekturentwurfs zwar einen Faktor für die Softwareentwicklung dar, aber es geht um viel mehr, denn Sicherheit ist grundsätzlich eine Systemfrage [2].

Die der Software zugewiesenen Elemente der Systemarchitektur werden in der Regel so lange ausgearbeitet, bis sie zu einer hinreichend detaillierten Software-Blaupause werden, aus der sich der Produktionscode generieren lässt. ISO 26262 beschreibt diesen Prozess der Modellausarbeitung als „Modelloptimierung“ [2]:

Die Modelle selbst können aus verschiedenen hierarchischen Optimierungsebenen oder Verweisen auf optimierte Modelle auf einer niedrigeren Hierarchieebene bestehen (z. B. hierarchische Struktur mit Blackbox- und Whitebox-Ansichten für jedes Modellelement).

ISO 26262 empfiehlt entsprechende Methoden für verschiedene Aktivitäten auf der Basis von Automotive Safety Integrity Levels (ASILs). Anhand dieser Richtlinien können Sie einen geeigneten Workflow einrichten, der auf Ihren jeweiligen Anwendungsfällen basiert. Abbildung 2 gibt einen Überblick über den ISO 26262-Prozess. Durchgehende Pfeile zeigen Entwicklungsaktivitäten an, während gestrichelte Pfeile Verifikations- und Validierungsaktivitäten signalisieren.

Entwicklung von Anforderungen

Zu Beginn des sicherheitsrelevanten Entwicklungsprozesses erstellen Sie die funktionalen und sicherheitstechnischen Anforderungen. Nach ISO 26262 wird empfohlen, das Softwarearchitektur-Design mithilfe einer „bidirektionalen Rückverfolgbarkeit zwischen dem Softwarearchitektur-Design und den Software-Sicherheitsanforderungen“ zu verifizieren. Hierzu können Sie die Requirements Toolbox™ verwenden, um Anforderungen zu erstellen und auf Modelle, Tests und Code zu übertragen. Die Requirements Toolbox unterstützt die bidirektionale Verfolgung für andere Tools, beispielsweise Microsoft^® Word^®, Microsoft Excel^® und IBM^® Rational^® DOORS^®. Außerdem können Sie Simulink und die Requirements Toolbox verwenden, um formale und eindeutige Anforderungsspezifikationen zu erstellen. Der Implementierungs- und Verifikationsstatus der Anforderungen wird dabei innerhalb der Requirements Toolbox überwacht und verwaltet. Im generierten Code können dann die Anforderungsverknüpfungen erscheinen (Abbildung 3).

Entwurfsmodellierung

Sie können das Model-Based Design mit Simulink und dem System Composer verwenden, um Ihre Softwarearchitektur zu spezifizieren. Dazu gehören die statischen (d. h. Struktur mit Blockhierarchien und Schnittstelleninformationen) und dynamischen Aspekte (z. B. das Verhalten mit Funktionen, Logik, Daten- und Kontrollstrukturen).

Mit Simulink lassen sich zudem Funktionsmodelle Ihrer Softwareeinheiten und -komponenten von einer ausführbaren High-Level-Spezifikation bis hin zu einem detaillierten Entwurf für die Generierung von Produktionscode weiterentwickeln. Zu den typischen Optimierungen gehören:

• Konvertierung von zeitkontinuierlichen (S-Domäne) in zeitkonkrete (Z-Domäne) Blöcke mithilfe des Diskretisierungstools Simulink Control Design™
• Konvertieren von doppelt genauen Daten in einfache Genauigkeit oder Festkomma mithilfe von Fixed-Point Designer™
• Hinzufügen von Diagnosen, Moduslogik, Zustandsmaschinen und Zeitplanung mithilfe von Stateflow^®

Für ASIL A bis D empfiehlt es sich gemäß ISO 26262, Modellierungsrichtlinien zu verwenden. Hierfür können Sie die MAB-Stilrichtlinien [4] und die in Simulink bereitgestellten Hochintegritätsrichtlinien für ISO 26262 verwenden. Simulink Check™ automatisiert die Überprüfung hinsichtlich beider Richtlinien. Es kann dabei Probleme, wie das Einfügen von nicht konformen Blöcken, während der Bearbeitungszeit anzeigen. Sie können auch Ihre eigenen Richtlinien und Checks einfügen, die auch als Kontrollen zur Bearbeitungszeit konfiguriert werden können.

Entwurfsverifikation

In der Norm ISO 26262 wird eine Reihe von statischen und dynamischen Methoden zur Verifizierung von Softwareentwürfen und -implementierungen empfohlen, darunter Aktivitäten auf Unit- und Integrationsebene. Für das Model-Based Design heißt es: „Je nach Softwareentwicklungsprozess können die Testobjekte der von diesem Modell abgeleitete Code oder das Modell selbst oder beides sein.“

Simulink Test™ bietet Ihnen ein Framework für Verifikations- und Validierungsaktivitäten im Rahmen der ISO 26262 in Simulink. Sie können damit systematische, simulationsbasierte Tests für Modelle und für aus Modellen generierten Code erstellen, verwalten und ausführen. Abbildung 4 zeigt eine beispielhafte Testsequenz und Bewertungsblöcke.

Der TÜV SÜD-Bericht im IEC Certification Kit (für ISO 26262) verdeutlicht die Rolle von Simulink Test bei der Automatisierung der Verifizierung und Validierung:

[Simulink Test] ermöglicht die Automatisierung der wichtigsten Verifikations- und Validierungsaktivitäten für Simulink-Modelle und generierten Code. Die folgenden Anwendungsfälle zeigen Aktivitäten, die in einem Softwareentwicklungsprozess gemäß der ISO-Norm 26262 für Funktionale Sicherheit erforderlich sind:

• Entwicklung und Durchführung von Tests für Simulink-Modelle
• Entwicklung und Durchführung von Tests für Back-to-Back-Tests zwischen Modell und Code
• Auswertung der Testergebnisse
• Erstellung von Testberichten
• Identifizierung der Rückverfolgbarkeit zwischen Anforderungen und Testfällen

So empfiehlt ISO 26262 eine strukturelle Abdeckungsanalyse, um die Vollständigkeit der Tests zu bestimmen und unbeabsichtigte Funktionen zu identifizieren. Darin werden drei Methoden zur Erhöhung der Stringenz aufgeführt, von denen die letzten beiden für ASIL-D besonders empfehlenswert sind.

• Anweisungsabdeckung
• Verzweigungsabdeckung
• MC/DC-Abdeckung (Modified Condition/Decision Coverage)

Die Norm besagt, dass für das Model-Based Design „die Analyse der strukturellen Abdeckung auf der Modellebene mithilfe analoger Metriken für die strukturelle Abdeckung für Modelle durchgeführt werden kann.“ Weiter heißt es, dass bei unzureichender struktureller Abdeckung „zusätzliche Testfälle spezifiziert oder eine Begründung angegeben werden müssen.“

Simulink Coverage™ bietet eine Strukturabdeckungsanalyse für Modelle und generierten Code und lässt sich mit Simulink Test auf einfache Weise für die Testausführung aktivieren. Wenn die Modellabdeckung unzureichend ist, können Sie mit dem Simulink Design Verifier™ automatisch zusätzliche Testfälle generieren, um die erforderliche Abdeckung, einschließlich MC/DC, zu erreichen. Simulink Check beinhaltet das Model Testing Dashboard zur Bewertung von anforderungsbasierten Testfällen und Ergebnissen in Bezug auf Vollständigkeit und Qualitätsmetriken gemäß ISO 26262-6:2018, Abschnitt 9.4.3 und Abschnitt 9.4.5 (Abbildung 5).

Das IEC Certification Kit unterstützt die Qualifizierung von Tools mit Zertifikaten und Berichten des TÜV SÜD für Simulink Check, Simulink Coverage (einschließlich Modell- und Codeabdeckung), den Simulink Design Verifier sowie Simulink Test.

Codegenerierung

Laut ISO 26262 umfasst „die Implementierung der Softwareeinheiten die Erzeugung von Quellcode und die Übersetzung in Objektcode“. Um das zu erreichen, können Sie mit dem Embedded Coder^® C, C++ und AUTOSAR-Code aus Ihren Simulink- und System Composer-Modellen generieren. Der Code kann den Richtlinien von MISRA C^®:2012 für automatische Codes [5] entsprechen. In der ISO 26262 wird darauf hingewiesen, dass sich Code-Richtlinien für Model-Based Design und manuellen Code unterscheiden können, und nennt MISRA^® als Beispiel.

Das IEC Certification Kit unterstützt die Qualifizierung von Tools für den Embedded Coder (einschließlich ASIL A bis D) für C, C++ und AUTOSAR. Im Zertifizierungsbericht des TÜV SÜD heißt es:

Embedded Coder erfüllt die Anforderungen der ISO 26262 hinsichtlich der Tool-Unterstützung und -Automatisierung.

Der Embedded Coder wird normalerweise in einem der drei folgenden Anwendungsfälle eingesetzt:

1. Generierung von C Code für das Modell, das für die Generierung von Produktionscode verwendet wird
2. Generierung von C++ Code für das Modell, das für die Generierung von Produktionscode verwendet wird
3. Generierung von C/C++ Code und Dateien für AUTOSAR-Anwendungssoftware-Komponenten aus dem für die Seriencode-Generierung verwendeten Modell

Der Embedded Coder bietet verschiedene Optionen zur Optimierung des Codes im Hinblick auf Speicher und Geschwindigkeit. Darüber hinaus können Sie prozessorspezifische Optimierungen erstellen, die Hardware-Beschleuniger wie SIMD^® für ARM^® und Intel^® nutzen. Sie können überprüfen, ob der optimierte Code mit den Simulationsergebnissen innerhalb der vorgeschriebenen Toleranzen übereinstimmt, indem Sie die in ISO 26262 beschriebenen Model-to-Code-Tests mit Processor-in-the-Loop (PIL) verwenden.

Aus dem generierten Quellcode wird mithilfe Ihres Compilers und Linkers ausführbarer Objektcode erzeugt. Der im IEC Certification Kit enthaltene Workflow ermöglicht die für die Massenproduktion von ECUs kritischen Optimierungen von Coder, Compiler und Prozessor, solange der ausführbare Objektcode mit PIL-Tests verifiziert wird.

Code-Verifizierung

In der ISO 26262 sind mehrere Optionen für die Verifikation von verschiedenen Software-Designs und -Implementierungen vorgesehen. Im Rahmen des Model-Based Design können Sie die Modellabdeckung mit der Codeabdeckung vergleichen, indem Sie Simulink Coverage während des Software-in-the-Loop-Tests (SIL) verwenden oder den Simulink Code Inspector™ einsetzen.

Und schließlich können Sie mit dem Polyspace Bug Finder™ die Einhaltung der MISRA-Vorschriften überprüfen. Besonders praktisch ist der Einsatz der MISRA-Prüfung und der Code-Abdeckungsanalyse, wenn Ihr Projekt aus einer Kombination von generierter und manuell kodierter Software besteht. Für zusätzliche Stringenz können Sie mithilfe des Polyspace Code Prover™ die Abwesenheit von Laufzeitfehlern wie Division durch Null beweisen.

Das IEC Certification Kit unterstützt die Qualifizierung von Tools mit Zertifikaten und Berichten des TÜV SÜD für Polyspace^®-Produkte.

Nach der Kompilierung und Generierung des ausführbaren Codes können Sie die Modelltests für den Code, der auf dem Zielprozessor ausgeführt wird, mithilfe von PIL-Tests wiederverwenden (Abbildung 6).

Die Norm ISO 26262 empfiehlt nachdrücklich Back-to-Back-Tests für die ASILs C und D. Darin wird auf die Bedeutung von Tests in einer repräsentativen Ziel-Hardware-Umgebung hingewiesen und die Notwendigkeit betont, sich der Unterschiede zwischen der Test- und der Hardware-Umgebung bewusst zu sein:

Unterschiede zwischen der Test- und der Zielumgebung können sich im Quell- oder Objektcode ergeben, z. B. durch unterschiedliche Bitbreiten von Daten- und Adresswörtern der Prozessoren.

Aber wie jeder Informatiker wissen sollte [6], gibt es zahlreiche Quellen für mögliche numerische Unterschiede zwischen den Plattformen, insbesondere bei Fließkommadaten. Einige davon sind zunächst unbedeutend, können sich aber akkumulieren und ausweiten, was insbesondere bei Regelungssystemen mit Rückkopplung der Fall ist. In der ISO 26262 sind daher verschiedene In-the-Loop-Methoden für Back-to-Back-Tests aufgeführt:

So können beispielsweise Software-Unit-Tests in verschiedenen Umgebungen durchgeführt werden:

– Model-In-The-Loop-Tests; 
– Software-In-The-Loop-Tests; 
– Processor-In-The-Loop-Tests; sowie 
– Hardware-in-the-Loop-Tests.

Simulink Test automatisiert In-the-Loop-Tests, einschließlich SIL und PIL mit dem Embedded Coder und HIL mit Simulink Real-Time™, und liefert Berichte zum Bestehen/Nichtbestehen mit Abdeckungsmetriken von Simulink Coverage.

Tool-Qualifizierung

In der ISO 26262-8 werden weitere unterstützende Prozesse beschrieben, darunter die Änderungskontrolle, das Konfigurationsmanagement und die Dokumentation. Diese Prozesse werden von Simulink Projects, dem Simulink-Modellvergleich und -Zusammenführung bzw. dem Simulink Report Generator™ unterstützt.

Die Norm enthält zudem Leitlinien zur Klassifizierung und Qualifizierung von Tools. Dazu müssen die Nutzer die Tools für ihre spezifischen Projekte qualifizieren. Das IEC Certification Kit bietet eine effektive Vorqualifizierung von Tools durch typische Anwendungsfälle, Referenz-Workflows, Tool-Klassifizierungsanalysen, Software-Tool-Dokumentation, Tool-Qualifizierungspläne und Validierungstests. Wenn Ihr Projekt die unterstützten Anwendungsfälle umfasst und dem Referenz-Workflow folgt, können Sie die erforderlichen Artefakte für die Toolqualifizierung erstellen, indem Sie die Vorlagendokumente des Certification Kits anpassen und die Validierungstests in Ihrer Entwicklungsumgebung durchführen.

Der TÜV SÜD prüft und auditiert die Entwicklungs- und Qualitätsprozesse der MathWorks^®-Tools sowie die Fehlerberichtsfunktionen und die Artefakte der Tool-Vorqualifizierung und zertifiziert die Ergebnisse bei jeder Produktfreigabe. Zum IEC Certification Kit gehören diese TÜV SÜD-Zertifikate und -Berichte, die auf der Notwendigkeit eines angemessenen Verifikations- und Validierungsworkflows beruhen. Das Kit umfasst darüber hinaus Referenz-Workflows, die auf typischen Anwendungsfällen basieren, wie sie in diesem Artikel beschrieben werden.

Im Kit sind zudem detailliertere Erläuterungen enthalten, einschließlich einer Zuordnung der Zielvorgaben von ISO 26262 zu den Unterstützungsmöglichkeiten von Simulink (Abbildung 7).

Gemäß ISO26262:2018 eignen sich Simulink und Stateflow für Notationen der Software-Architektur und des Entwurfs von Software-Modulen sowie als Basis für die automatische Codegenerierung (Abbildung 8).

Bitte beachten Sie, dass die Anwendung qualifizierter Tools weder die Sicherheit der Software noch des damit untersuchten Systems garantiert.