Ein ISO 26262-Workflow für automatisierte Fahranwendungen mit MATLAB: Richtlinien und bewährte Vorgehensweisen

Von Lars Rosqvist, MathWorks

Die Verwendung von Simulink® und Stateflow® zur ISO 26262-Softwareentwicklung hat sich für elektronische Steuerungseinheiten in Fahrzeugen bewährt. Es gibt einen wachsenden Trend, insbesondere bei Anwendungen für automatisiertes Fahren, Softwaredesigns mit MATLAB®-Funktionen sowie Simulink-Blöcken und Stateflow-Diagrammen zu implementieren. Dieser Artikel beschreibt bewährte Vorgehensweisen für einen MATLAB-orientierten Workflow zur Verifizierung der Einhaltung von ISO 26262-Softwarestandards [1]. Diese bewährten Vorgehensweisen ergänzen den ISO 26262 Referenz-Workflow mit Model-Based Design, wie im IEC Certification Kit erläutert.

Empfohlenes Modellierungsmuster

In diesem Artikel wird ein Softwareentwicklungsmuster verwendet, bei dem ein Simulink-Modell einen MATLAB-Funktionsblock (Abbildung 1) umfasst. Das oberste Simulink-Modell überträgt alle Konfigurationseinstellungen für die Codegenerierung. Der MATLAB-Funktionsblock ruft externe MATLAB-Funktionen auf.

Abbildung 1: Modellierungsmuster mit externem MATLAB-Code.

Dieses Modellierungsmuster profitiert von allen für Simulink-Modelle verfügbaren Verifizierungs- und Validierungstools und ermöglicht dabei die Implementierung der Funktionalität mit der MATLAB-Sprache [2]. Es profitiert auch von den umfangreichen Fähigkeiten in MATLAB. Beispielsweise wird die ADAS-Entwicklung typischerweise mit MATLAB implementiert, weil komplexe mathematische Funktionalität knapp und elegant ausgedrückt werden kann.

MATLAB ISO 26262 Referenz-Workflow: Übersicht

Wie oben erwähnt, beruht der in diesem Artikel beschriebene Workflow auf dem ISO 26262 Referenz-Workflow im IEC Certification Kit (Abbildung 2).

Abbildung 2: Im IEC Certification Kit angegebene Verifizierungs- und Validierungsmaßnahmen.

Der auf MATLAB basierende Workflow beinhaltet zusätzliche Empfehlungen für folgende Verifizierungs- und Validierungsmaßnahmen:

  • Erstellung von Anforderungen und Verifizierung der Architektur
  • Statische Modellanalyse
  • MIL-Testen und SIL- oder PIL-Back-to-Back-Testen
  • Statische Codeanalyse
  • Dokumentation

Erstellung von Anforderungen und Verifizierung der Architektur

Für ISO 26262 ist es erforderlich, nachzuweisen, dass alle Anforderungen umgesetzt und getestet wurden.

Im ISO 26262 Referenz-Workflow wird dieser Beleg durch die in Abbildung 3 hervorgehobenen Maßnahmen zur Verifizierung der Architektur und die Erstellung der Anforderungen erbracht.

Abbildung 3: Maßnahmen zum Verknüpfen von Anforderungen.

Verknüpfen von Anforderungen mit MATLAB-Code

Mit Simulink Requirements™ können Anforderungen mit Codezeilen in MATLAB-Funktionen auf dieselbe Weise verknüpft werden, wie Anforderungen mit Simulink-Blöcken verknüpft werden. Der Unterschied besteht jedoch darin, dass die vorhandene Überprüfung auf fehlende Anforderungen keinen externen MATLAB-Code überprüft. Es wird daher empfohlen, eine Model Advisor-Überprüfung zu implementieren, die nach MATLAB-Containern sucht, die nicht mit einer Anforderung verknüpft sind. Ein Container ist typischerweise die externe MATLAB-Datei oder eine MATLAB-Funktion, je nach Größe der Datei.

BEWÄHRTES VERFAHREN für den MATLAB-Workflow

Es empfiehlt sich, Model Advisor-Überprüfungen zu implementieren, um nach MATLAB-Containern zu suchen, die nicht mit Anforderungen verknüpft sind.

Statische Modellanalyse

Jede Komponente im Implementierungsmodell muss auf Lesbarkeit, Verständlichkeit und Testbarkeit überprüft werden (Abbildung 4). Mit Simulink Check™ wird bewertet, ob das Modell die Hochintegritätsrichtlinien von ISO 26262 und MathWorks einhält.

Abbildung 4: Im IEC Certification Kit angegebene Maßnahmen zur statischen Modellanalyse.

Sprachteilmenge

Beim Programmieren in MATLAB können Funktionen verschiedener Toolboxen verwendet werden. Da MATLAB eine leistungsstarke Sprache mit hohem Abstraktionsgrad ist, können mit nur wenigen Zeilen Code aufwändige Funktionalität entwickelt werden. Manchmal kann eine einzelne MATLAB-Codezeile zu vielen Zeilen C Code führen, was die Verifizierung der vollständigen Abdeckung des generierten Codes erschweren kann. Anwender müssen sich sicher sein, dass die zu implementierende Funktionalität testbar ist. ISO 26262 verlangt die Verwendung einer Sprachteilmenge (Tabelle 1 in ISO 26262), die auf der Art der verwendeten Funktionen basiert.

Es ist empfehlenswert, dass Anwender die Anforderung der Sprachteilmenge folgendermaßen erfüllen:

  • Die verwendeten MATLAB-Funktionen sollten beurteilt und es sollte sichergestellt werden, dass sie keinen hohen Verifizierungsaufwand erfordern. Eine Model Advisor-Überprüfung kann hinzugefügt werden; sie überprüft, ob nicht empfohlene Funktionen verwendet werden.
  • Nicht empfohlene MATLAB-Funktionen sollten durch einfachere Implementierungen ersetzt werden. Diese einfacheren Funktionen lassen sich leichter verfolgen und testen.

BEWÄHRTES VERFAHREN für den MATLAB-Workflow

Beim Überprüfen von Modellen sollten Anwender auf MATLAB-Operationen oder -Funktionen, die viel C Code generieren, achten und diese nach Möglichkeit durch andere Funktionen ersetzen. Eine Model Advisor-Überprüfung kann hinzugefügt werden, die Nutzer bei Verwendung nicht empfohlener Funktionen warnt.

Können die Funktionen nicht ersetzt werden, müssen sie separat getestet werden.

  • Die Funktion sollte mit separaten Einheitentests mit hoher Abdeckung verifiziert werden. Bei Erreichung der Abdeckung sollten Nutzer die Verwendung dieser Funktionen durch Referenzieren der externen Einheitentests begründen.

BEWÄHRTES VERFAHREN für den MATLAB-Workflow

Werden MATLAB-Operationen oder -Funktionen ermittelt, die viel C Code generieren und nicht ersetzbar sind, sollten die Funktionen extern mit Einheitentests getestet werden. Die Begründungen sollten in Zusammenhang mit dem Verwendungsort der Funktionen verfasst und mit dem Speicherort der Testergebnisse verknüpft werden.

Strenge Festlegung von Datentypen

Für ISO 26262 müssen alle Variablen stark typisiert sein. Model Advisor überprüft Simulink-Modelle auf stark typisierte Blöcke, einschließlich der Schnittstelle zum MATLAB-Funktionsblock, überprüft jedoch keine externen MATLAB-Funktionen. Um dem entgegenzuwirken, ist es notwendig, eine Überprüfung zu schreiben, um zu verifizieren, dass alle MATLAB-Funktionen stark typisiert sind. Es ist von besonderer Wichtigkeit, Datentyp und Datendimension zu überprüfen.

BEWÄHRTES VERFAHREN für den MATLAB-Workflow

Anwender sollten eine Model Advisor-Überprüfung hinzufügen, um sicherzustellen, dass alle Variablen in ihrem MATLAB-Code stark typisiert sind.

MIL-Testen und SIL- oder PIL-Back-to-Back-Testen

Mit Back-to-Back- (Äquivalenz-) Tests kann der Nachweis erbracht werden, dass der generierte Code sich so wie das Modell verhält, wie von ISO 26262 Tabelle 7, Methoden zur Verifizierung von Softwareeinheiten, empfohlen. Anwender sollten Objektcode Processor-in-the-Loop- (PIL-) Tests verwenden und bei generiertem C Code Software-in-the-Loop- (SIL-) Tests (Abbildung 5). Die Testfälle sollten dieselben sein wie in den Model-in-the-Loop- (MIL-) Tests. SIL kann zur Einheitenverifizierung verwendet werden. Bei Integrationstests muss mit PIL die gesamte Entwicklungstoolkette verifiziert werden.

Abbildung 5: Im IEC Certification Kit angegebene Maßnahmen zur Modellverifizierung.

Verhinderung ungewollter Funktionalität

Um zu beweisen, dass bei der Codegenerierung keine ungewollte Funktionalität dazukam, sollte die Testabdeckung während Modell- und Codetests gemessen werden. Die Testabdeckung erfolgt typischerweise mit Back-to-Back-Tests mit Simulink Coverage™. Abdeckung wird gemäß ISO 26262 dazu verwendet, um die Vollständigkeit der Verifizierung auszuwerten und zu belegen, dass die Ziele für den Einheitentest erreicht wurden.

Gemäß ISO 26262 muss Code mit fehlender Abdeckung überarbeitet und begründet werden. Beim Entwickeln von Simulink-Blöcken können die Begründungen mit dem Modell verbunden werden. Das bedeutet, dass die Begründungen zwischen den Verifizierungsläufen beibehalten werden. Diese Option ist nicht für externe MATLAB-Funktionen verfügbar. Um eine fehlende Abdeckung für eine MATLAB-Funktion zu begründen, fügen Nutzer dem Code einen Abdeckungsfilter hinzu und verbinden ihn entweder mit dem Test-Harness oder der Testdatei in Simulink Test™. Es ist empfehlenswert, die Abdeckungsfilterdatei mit der Testdatei zu verbinden (Abbildung 6).

Abbildung 6: Mit der Testdatei verbundener Abdeckungsfilter.

BEWÄHRTES VERFAHREN für den MATLAB-Workflow

Begründungen fehlender Abdeckung in externem MATLAB-Code sollten über einen mit der Testdatei verbundenen Begründungsfilter verfolgt werden.

Statische Codeanalyse

Wie im ISO 26262-Standard angegeben, beinhalten statische Analysen Maßnahmen wie das Durchsuchen des Quellcodetexts oder des Modells auf Muster, die bekannten Fehlern entsprechen, oder auf die Einhaltung von Modellierungs- oder Codierungsrichtlinien. Statische Codeanalysen werden am generierten Code ausgeführt (Abbildung 7).

Abbildung 7: Im IEC Certification Kit angegebene Maßnahmen zur statischen Codeanalyse.

MISRA C-Konformität

Um die MISRA® C-Konformität für von MATLAB generierten Code zu beurteilen, sollten Nutzer ein Tool zur statischen Codeanalyse wie Polyspace Bug Finder™ verwenden, um nicht MISRA C-konformen Code zu finden, und die Ergebnisse manuell untersuchen. Stammt der nicht konforme Code von einer integrierten MATLAB-Funktion, gibt es zwei Möglichkeiten:

  • die integrierte MATLAB-Funktion durch eine umgeschriebene Funktion zu ersetzen oder
  • eine Begründung für die MISRA C-Warnung zu schreiben.

Es ist ratsam, die Funktion nach Möglichkeit zu ersetzen. Um sicherzustellen, dass die ersetzte Funktion nicht von anderen Entwicklern verwendet wird, sollte eine Model Advisor-Überprüfung für nicht empfohlene Funktionen implementiert werden.

BEWÄHRTES VERFAHREN für den MATLAB-Workflow

Beim Überprüfen von Berichten statischer Codeanalysen sollte überprüft werden, ob MISRA-Warnungen von integrierten MATLAB-Funktionen stammen. Können diese Funktionen ersetzt werden,  sollte eine Model Advisor-Überprüfung hinzugefügt werden, die bei Verwendung nicht empfohlener Funktionen warnt. Andernfalls sollte das Problem im Bericht der statischen Codeanalyse begründet werden.

Dokumentation

Im abschließenden Sicherheitsnachweis, der die ISO 26262-Konformität belegt, müssen Anwender jeden Schritt des Verifizierungsablaufs dokumentieren, von den Anforderungen bis hin zur Verifizierung. Die Dokumentation sollte Entwurfsbeschreibungen der Funktionalität beinhalten. Abbildung 8 hebt einige der Maßnahmen hervor, die in der Entwurfsbeschreibung enthalten sein müssen.

Abbildung 8: Maßnahmen, die in der Entwurfsdokumentation enthalten sein müssen.

Beschreibung des Systemdesigns

Simulink Report Generator™ beinhaltet eine vordefinierte Vorlage für Systementwurfsberichte. Diese Vorlage reicht normalerweise zum Dokumentieren von in Simulink entwickelten Komponenten, aber nicht von externen MATLAB-Funktionen aus, weil sie nicht in der Systementwurfsbeschreibung enthalten sind. Daher empfiehlt es sich, die Vorlage individuell anzupassen, sodass sie auch externen MATLAB-Code umfasst.

BEWÄHRTES VERFAHREN für den MATLAB-Workflow

Die Vorlage zur Systementwurfsbeschreibung sollte individuell angepasst werden, damit sie auch externen MATLAB-Code umfasst.

SOTIF-Betrachtungen

In komplexen Systemen wie ADAS verhält sich eine Funktion u. U. wie vorgesehen, verursacht aber dennoch risikoreiches Verhalten. Unter Anleitung des ISO/PAS 21448 SOTIF-Standards (Sicherheit der vorgesehenen Funktionalität) kann diese Problematik angegangen werden, indem zusätzliche Verifizierungs- und Validierungsmaßnahmen in das Model-Based Design integriert werden. Empfehlenswert ist es, randomisierte Operationsbedingungstests hinzuzufügen, um die Tests zu erweitern und auch unbekannte Anwendungsfälle einzuschließen. Diese Zufallstests sollten das Verhalten des Implementierungsmodells und des integrierten Objektcodes im Vergleich zu den Systemanforderungen verifizieren.

Das IEC Certification Kit unterstützt SOTIF. Hinsichtlich SOTIF gibt es keine großen Unterschiede zwischen Simulink- und MATLAB-Workflows. Das aktualisierte IEC Certification Kit beinhaltet Informationen über die Nutzung der Automated Driving Toolbox bei Systemtests.

Zusammenfassung

Bei der ISO-konformen Softwareentwicklung gibt es keine großen Unterschiede zwischen einer vollständig Simulink-basierten Entwicklung und einem eher MATLAB-orientierten Workflow. Der Hauptunterschied liegt in der Notwendigkeit, durch das Implementieren individuell angepasster Model Advisor-Überprüfungen nicht empfohlene Funktionen zu vermeiden. Diese zusätzlichen Überprüfungen stellen zusammen mit vorhandenen ISO 26262-Überprüfungen in Simulink Check sicher, dass die MATLAB-Implementierung einen für Hochintegritätsanwendungen geeigneten Code generiert. Die anderen Herausforderungen bei der Verwendung eines MATLAB-orientierten Workflows für ISO 26262 können mit einfachen Behelfslösungen wie Begründungsfiltern oder dem Verlinken von Anforderungen mit mehreren Ebenen des Modells gemeistert werden.

[1] Die Empfehlungen in diesem Artikel basieren auf MATLAB R2020a. Bei Verwendung eines anderen Release wenden Sie sich bitte an Ihren MathWorks-Mitarbeiter, um mehr über seine Fähigkeiten zur Verwendung von MATLAB und Simulink für ISO 26262 zu erfahren.

[2] Entwickler entscheiden sich manchmal für MATLAB statt Simulink, weil sie der Meinung sind, dass Simulink kein diff und merge unterstützt. Arbeiten Anwender in Simulink, können sie diff und merge mittels integrierter Tools behandeln. Verwendet ihr Team ein verteiltes Versionskontrollsystem like Git, können sie mit dreifachem Zusammenfügen eventuelle Konflikte lösen.

Über den Autor

Lars Rosqvist ist Senior Technical Consultant bei MathWorks. Er unterstützt Kunden verschiedenster Branchen, die mit Model-Based Design und MATLAB arbeiten. Er ist von TÜV SÜD als Experte für Funktionale Sicherheit zertifiziert und unterstützt Kunden seit vielen Jahren bei der ISO 26262-Zertifizierung. Vor dem Wechsel zu MathWorks arbeitete er in der Automobilindustrie als Softwareentwickler für Klimasteuerungssysteme. Rosqvist besitzt einen Masterabschluss in Angewandter Physik und Elektrotechnik von der Technischen Universität Linköping.

Veröffentlicht 2020