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

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.

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).

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.

Verknüpfen von Anforderungen mit MATLAB-Code

Mit Requirements Toolbox™ 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.

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.

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.
  

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.

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.

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.

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).

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).

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.

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.

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.