Nutzung von Simulink für Projekte nach ISO 26262

Automobilingenieure, die an sicherheitsbezogenen Embedded-Systemen für herkömmliche und autonome Fahrzeuge arbeiten, suchen nach effizienten Möglichkeiten, die in ISO 26262 geforderten strengen Prozesse umzusetzen [1]. Hierbei handelt es sich um einen Standard für die funktionale Sicherheit bei der Entwicklung von PKWs.

Da autonome Fahrzeuge im Zentrum des Medieninteresses stehen, fehlt es nicht an guten Ratschlägen. Allzu häufig konzentrieren diese sich jedoch auf die aktuellste Programmiermethode oder das neueste Tool gegen Bugs. Wie Branchenexperten schon vor langer Zeit erkannt haben, geht es bei der Sicherheit mehr um den Entwurf des Systems und seiner Anforderungen als um die Software und die Programmiermethoden [2].

Auf der Grundlage zeitkontinuierlicher und zeitdiskreter Simulation können Sie mit Model-Based Design in Simulink^® Ihr gesamtes System entwerfen und unter zahlreichen unterschiedlichen Fahrbedingungen und Fehlerszenarien testen, lange bevor Sie es auf einem Testgelände fahren oder Flottentests durchführen. Ebenfalls unterstützt werden in ISO 26262 spezifizierte prozessunterstützende Maßnahmen einschließlich der Tool-Qualifikation. Das IEC Certification Kit umfasst die Details dieser Unterstützung und bietet Tool-Zertifikate und -Berichte von der internationalen Zertifizierungsstelle TÜV SÜD.

In diesem Artikel wird der vom TÜV SÜD anerkannte Workflow für die Verwendung von Simulink für Projekte nach ISO 26262 vorgestellt. Er bietet eine Einführung in ISO 26262 und Model-Based Design und beschreibt dann die folgenden Aufgaben:

• Entwicklung von Anforderungen
• Entwurfsmodellierung
• Codegenerierung 
• Entwurfsverifikation
• Codeverifikation
• Tool-Qualifikation

ISO 26262 und Model-Based Design

ISO 26262 bietet Leitlinien für das manuelle Entwerfen und Programmieren sowie für Model-Based Design. Außerdem bestätigt der Standard einige Vorteile des Einsatzes von Model-Based Design [3]:

Die nahtlose Nutzung von Modellen erleichtert eine sehr konsistente und effiziente Entwicklung.

Der Standard erwähnt die „große Verbreitung“ der mathematischen Modellierung und merkt an, dass Modellierungstools „semi-formale grafische Methoden“ für die Softwareentwicklung verwenden. Er erläutert, dass die Modellierung nicht nur die umzusetzende Funktionalität (die Embedded-Software) umfasst, sondern auch die Simulation des realen physischen Systems (Fahrzeugmodell und Umgebungsmodell), sodass ein Modell des gesamten Systems erstellt wird:

Auf diese Weise ist es möglich, auch sehr komplexe Automobilsysteme in hohem Detailgrad mit akzeptabler Berechnungsgeschwindigkeit zu modellieren, um ein Verhalten zu simulieren, das der Realität nahekommt. Während das Fahrzeug-/Umgebungsmodell während der Entwicklung nach und nach durch das reale System und seine reale Umgebung ersetzt wird, kann das Funktionalitätsmodell als Entwurf für die Implementierung von Embedded-Software in der Steuereinheit mithilfe der Codegenerierung dienen. [3]

Abbildung 1 zeigt ein typisches Regelkreis-Systemmodell von Simulink. Es besteht aus einem Regler und einer Regelstrecke sowie Signalprozessoren. In ISO 26262 ist die Systementwurfsspezifizierung eine Voraussetzung für die Softwareentwicklung., Doch zugleich ist sie weit mehr als das, da die Sicherheit im Wesentlichen auf der Systemebene zu verorten ist [2].

Dann wird Ihr Systementwurf weiter ausgearbeitet, bis er zu einem Software-Entwurf wird, der ausreichend detailliert ist, um Ihnen die Generierung von Produktionscode zu ermöglichen. ISO 26262 beschreibt diesen Prozess der Modellausarbeitung als eine „Modell-Evolution” [2]:

In der Praxis [gibt es eine] Evolution des Funktionalitätsmodells von einem frühen Spezifikationsmodell über ein Entwurfsmodell bis hin zu einem Implementierungsmodell und schließlich seiner automatischen Transformation in Code (Modell-Evolution).

ISO 26262 empfiehlt Methoden für verschiedene Maßnahmen anhand von Integritätsstufen der Fahrzeugsicherheit (Automotive Safety Integrity Levels, kurzASIL). Sie können diese Leitlinien verwenden, um anhand Ihrer Anwendungsfälle einen passenden Workflow einzurichten. Abbildung 2 zeigt einen Überblick über den Prozess gemäß ISO 26262. Durchgezogene Pfeile zeigen Entwicklungsaktivitäten, gestrichelte Pfeile zeigen Verifikations- und Validierungsmaßnahmen. Die in ISO 26262 erwähnte „Modell-Evolution“ wird durch ein Auslassungszeichen (…) dargestellt.

Entwicklung von Anforderungen

Sie beginnen den sicherheitsbezogenen Entwicklungsprozess, indem Sie zunächst funktionale und sicherheitsspezifische Anforderungen erstellen. ISO 26262 empfiehlt zur Verifikation des Softwarearchitekturentwurfs eine „bidirektionale Rückverfolgbarkeit zwischen dem Softwarearchitekturentwurf und den Sicherheitsanforderungen für die Software“. Um dies zu erreichen, können Sie Anforderungen mithilfe von Requirements Toolbox™ erstellen und zu Modellen, Tests und Code zurückverfolgen. Requirements Toolbox unterstützt die bidirektionale Rückverfolgbarkeit auch für andere Tools, darunter Microsoft^® Word^®, Microsoft Excel^® und IBM^® Rational^® DOORS^®. Der Implementierungs- und Verifikationsstatus der Anforderungen wird innerhalb von Requirements Toolbox überwacht und verwaltet. Anforderungslinks können im generierten Code enthalten sein (Abbildung 3).

Entwurfsmodellierung

Wie im Abschnitt „ISO 26262 und Model-Based Design“ erwähnt, beschreibt ISO 26262 die Evolution eines Funktionalitätsmodells von einer abstrakten ausführbaren Spezifikation bis zu einem detaillierten Entwurf, der für die Generierung von Produktionscode bereit ist. Häufige Veränderungen und Verfeinerungen sind:

• Umwandeln von zeitkontinuierlichen (S-Bereich) in zeitdiskrete (Z-Bereich) Blöcke mit dem Diskretisierungstool von Simulink Control Design™
• Umwandeln von Daten von doppelgenauen Darstellungen in Darstellungen mit einfacher Genauigkeit oder Festkomma-Darstellungen mit Fixed-Point Designer™
• Hinzufügen von Diagnosen, Betriebs-Logik, Zustandsautomaten und Scheduling mit Stateflow^®

Für ASIL B bis D empfiehlt ISO 26262 dringend die Verwendung von Modellierungsrichtlinien. Hierfür können Sie die MAAB-Richtlinien [4] und die Richtlinien für den Entwurf von Hochintegritätssystemen für ISO 26262 verwenden, die in Simulink bereitgestellt werden. Simulink Check™ automatisiert die Prüfung hinsichtlich beider Richtlinien. Das Tool kann während der Bearbeitung auf Probleme hinweisen, wie beispielsweise das Einfügen nicht richtlinienkonformer Blöcke. Sie können auch Ihre eigenen Richtlinien und Prüfungen aufnehmen.

Codegenerierung

ISO 26262 besagt, dass „die Implementierung der Softwareeinheiten die Generierung von Quellcode und die Umwandlung in Objektcode umfasst“. Hierfür können Sie mit Embedded Coder^® C-, C++- und AUTOSAR-Code aus Ihrem Simulink-Modell generieren. Der Code kann den Richtlinien in MISRA C^®:2012 für automatisch generierten Code [5] entsprechen. ISO 26262 weist darauf hin, dass sich Coderichtlinien für Model-Based Design und manuellen Code unterscheiden können und nennt MISRA^® als ein Beispiel.

Das IEC Certification Kit unterstützt die Tool-Qualifikation für Embedded Coder (einschließlich ASIL A–D) für C, C++ und AUTOSAR. Der Zertifizierungsbericht vom TÜV SÜD besagt:

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

Embedded Coder wird im Allgemeinen in einem der folgenden drei Anwendungsfälle genutzt:

1. Generierung von C-Code für das zur Generierung von Produktionscode verwendete Modell
2. Generierung von C-Code und Beschreibungsdateien für AUTOSAR-Anwendungssoftwarekomponenten für das zur Generierung von Produktionscode verwendete Modell
3. Generierung von C++-Code für das zur Generierung von Produktionscode verwendete Modell

Embedded Coder bietet Optionen für die Optimierung von Code im Hinblick auf die Arbeitsspeichernutzung und die Geschwindigkeit. Außerdem können Sie prozessorspezifische Optimierungen generieren, die Hardwarebeschleuniger wie SIMD^® für ARM^® und Intel^® nutzen. Sie können verifizieren, ob der optimierte Code den Simulationsergebnissen innerhalb vorgegebener Toleranzen entspricht, indem Sie Modell-zu-Code-Testing mit Processor-in-the-Loop (PIL) verwenden, wie in ISO 26262 beschrieben.

Ausführbarer Objektcode wird mithilfe Ihres Compilers und Linkers aus dem generierten Quellcode erzeugt. Der Workflow im IEC Certification Kit ermöglicht Optimierungen für Coder, Compiler und Prozessor, die für seriengefertigte ECUs sehr wichtig sind, sofern PIL-Testing für die Verifikation des ausführbaren Objektcodes verwendet wird.

Entwurfsverifizierung

ISO 26262 empfiehlt eine Reihe statischer und dynamischer Methoden für die Verifikation von Softwareentwürfen und ‑implementierungen, darunter Maßnahmen auf Komponenten- und Integrationsebene. Für Model-Based Design wird in ISO 26262 angegeben, dass „abhängig vom Softwareentwicklungsprozess die Testobjekte in dem Code bestehen können, der von diesem Modell abgeleitet wurde oder im Modell selbst.“

Simulink Test™ bietet ein Framework für Verifikations- und Validierungsmaßnahmen gemäß ISO 26262 in Simulink. Sie können es für die Erstellung, Verwaltung und Ausführung systematischer, simulationsbasierter Tests für Modelle und für aus Modellen generierten Code verwenden. Abbildung 4 zeigt ein Beispiel für Test-Sequence und Assessment-Blöcke.

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

Simulink Test ermöglicht die Automatisierung zentraler Verifikations- und Validierungsmaßnahmen für Modelle und generierten Code von Simulink. Die folgenden Anwendungsfälle zeigen Maßnahmen, die laut den Standards für die funktionale Sicherheit in ISO 26262 in einem Softwareentwicklungsprozess erforderlich sind:

• Entwicklung und Ausführung von Tests für Simulink-Modelle
• Entwicklung und Ausführung von Tests für das Back-to-Back-Testing von Modell und Code
• Bewertung von Testergebnissen
• Generierung von Testberichten
• Identifikation der Rückverfolgbarkeit zwischen Anforderungen und Testfällen

ISO 26262 empfiehlt eine Analyse der strukturellen Abdeckung, um die Vollständigkeit der Tests zu ermitteln und unbeabsichtigte Funktionalität zu identifizieren. Der Standard führt drei Abstufungen zur Erhöhung der Rigorosität auf. Dabei werden die letzten beiden für ASIL-D dringend empfohlen.

• Anweisungsabdeckung
• Verzweigungsabdeckung
• MC/DC-Abdeckung

Im Standard wird angemerkt, dass für Model-Based Design „die Analyse der strukturellen Abdeckung auf Modellebene durchgeführt werden kann, wobei analoge Metriken für die strukturelle Abdeckung für Modelle verwendet werden.“ Des Weiteren besagt der Standard, dass bei unzureichender struktureller Abdeckung „zusätzliche Testfälle spezifiziert oder eine Begründung angegeben werden muss“.

Simulink Coverage™ bietet die strukturelle Abdeckung für Modelle und generierten Code und kann leicht für die Testausführung mit Simulink Test aktiviert werden. Wenn Ihre Modellabdeckung nicht ausreicht, können Sie Simulink Design Verifier™ verwenden, um automatisch zusätzliche Testfälle zu generieren, mit denen Sie die erforderliche Abdeckung erreichen, einschließlich MC/DC. Außerdem refaktoriert Simulink Check Modelle, um ihre Komplexität zu reduzieren. Das Tool umfasst ein Metriken-Dashboard für die Bewertung der Projektqualität und die Erfüllung der Anforderungen von ISO 26262 an die „Erzwingung niedriger Komplexität und begrenzter Größe von Softwarekomponenten und -schnittstellen “ (Abbildung 5).

Das IEC Certification Kit unterstützt die Tool-Zulassung mit Zertifikaten und Berichten vom TÜV SÜD für Simulink Check, Simulink Coverage (einschließlich Modell- und Codeabdeckung), Simulink Design Verifier und Simulink Test.

Code-Verifikation

ISO 26262 bietet mehrere Optionen für die Verifikation von Softwareentwürfen und -implementierungen. Ein im IEC Certification Kit beschriebener Ansatz gestattet eine begrenzte Überprüfung durch Rückverfolgung, um unbeabsichtigte Funktionalität im generierten Code zu erkennen, wie Code, der nicht zu einem Block oder Signal zurückverfolgt werden kann. Das Kit generiert zu diesem Zweck automatisch eine Rückverfolgungsmatrix. Alternativ können Sie die Modellabdeckung mit der Codeabdeckung vergleichen, indem Sie Simulink Coverage während des SIL-Testing (Software-in-the-Loop) verwenden oder Sie können Simulink Code Inspector™ einsetzen.

Abschließend können Sie die MISRA-Compliance mit Polyspace Bug Finder™ überprüfen. Die MISRA-Überprüfung und die Codeabdeckungsanalyse sind besonders dann hilfreich, wenn Ihr Projekt eine Mischung aus generierter und manuell codierter Software enthält. Um noch strenger zu testen, können Sie mit Polyspace Code Prover™ die Abwesenheit von Laufzeitfehlern (wie beispielsweise der Division durch null) nachweisen.

Das IEC Certification Kit unterstützt die Tool-Qualifikation mit Zertifikaten und Berichten vom TÜV SÜD für Polyspace^®-Produkte.

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

ISO 26262 empfiehlt für ASILs C und D dringend ein Back-to-Back-Testing. Außerdem wird angemerkt, wie wichtig das Testen in einer repräsentativen Zielhardwareumgebung ist, und es wird betont, dass Sie die Unterschiede zwischen der Test- und der Hardwareumgebung beachten müssen:

Unterschiede zwischen der Testumgebung und der Zielumgebung können im Quellcode oder im Objektcode entstehen, beispielsweise aufgrund unterschiedlicher Bitbreiten von Datenwörtern und Adresswörtern der Prozessoren.

Wie jedoch jeder Informatiker wissen sollte [6], gibt es viele Ursachen für potenzielle numerische Unterschiede zwischen Plattformen, vor allem bei Gleitkommadaten. Einige Probleme fangen klein an, aber summieren sich und wachsen, vor allem in Feedback-Kontrollsystemen. Daher sind in ISO 26262 mehrere In-the-Loop-Methoden für das Back-to-Back-Testing aufgeführt:

Das Unit Testing für Software kann in unterschiedlichen Umgebungen durchgeführt werden, wie beispielsweise den folgenden:

– Model-in-the-Loop-Tests,
– Software-in-the-Loop-Tests,
– Prozessor-in-the-Loop-Tests und
– Hardware-in-the-Loop-Tests.

Simulink Test automatisiert das In-the-Loop-Testen, einschließlich SIL und PIL mit Embedded Coder und HIL mit Simulink Real-Time™. Zusätzlich bietet es Berichte zum Bestehen/Nichtbestehen mit Metriken für die Abdeckung von Simulink Coverage.

Tool-Qualifikation

ISO 26262-8 beschreibt zusätzliche Prozesse, einschließlich Versionskontrolle, Konfigurationsmanagement und Dokumentation. Unterstützt werden diese Prozesse durch Simulink Projects, die Ermittlung von Modellunterschieden und die Modellzusammenführung in Simulink bzw. Simulink Report Generator™.

Der Standard umfasst auch Leitlinien zur Tool-Qualifikation. Er gestattet es Tool-Anbietern nicht, ihre Tools selbst zu qualifizieren, sondern schreibt vor, dass Benutzer die Tools für spezifische Projekte qualifizieren. Das IEC Certification Kit bietet effektiv eine Vorqualifikation von Tools, indem es typische Anwendungsfälle, Referenz-Workflows, Tool-Klassifizierungsanalysen, eine Softwaretool-Dokumentation, Tool-Qualifikationsberichte und Validierungstests bereitstellt.

Der TÜV SÜD prüft die Toolentwicklungs-, Qualitätssicherungs- und Fehlermeldungsprozesse von MathWorks und zertifiziert die Ergebnisse bei jedem Produktrelease. Das IEC Certification Kit enthält diese Zertifikate und Berichte vom TÜV SÜD, die auf der Notwendigkeit beruhen, einen geeigneten Workflow für die Verifikation und Validierung zu befolgen. Das Kit bietet Referenz-Workflows, die auf typischen Anwendungsfällen für Tools basieren, wie dem in diesem Artikel beschriebenen.

Das Kit bietet detailliertere Informationen, einschließlich einer Zuordnung der Zielvorgaben von ISO 26262 zu den Unterstützungsmöglichkeiten von Simulink (Abbildung 7).

In der zweiten Auflage der ISO 26262, die im Dezember 2018 veröffentlicht wurde, ist vermerkt, dass Simulink und Stateflow als Notation für das Design von Softwarearchitekturen und -einheiten sowie als Grundlage für die automatische Codegenerierung geeignet sind (Abbildung 8). 

Beachten Sie, dass die Verwendung qualifizierter Tools nicht die Sicherheit der betreffenden Software oder des betreffenden Systems garantiert.