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

Der Einsatz von Simulink^® und Stateflow^® für ISO^® 26262-basierte Softwareentwicklung für Kfz-Steuergeräte ist gut etabliert. Insbesondere bei automatisierten Fahranwendungen besteht ein wachsender Trend zur Implementierung von Softwaredesigns mit MATLAB^®-Funktionen sowie Simulink-Blöcken und Stateflow-Diagrammen. Dieser Artikel bietet bewährte Praktiken für die Verwendung eines MATLAB-zentrierten Workflows zur Überprüfung der Konformität mit den Softwarestandards ISO 26262 [1]. Diese bewährten Methoden ergänzen den ISO 26262 Referenz-Workflow mit Model-Based Design, dargestellt in IEC Certification Kit.

Empfohlenes Modellierungsmuster

In diesem Artikel verwenden wir ein Softwareentwicklungsmuster, in dem ein Simulink-Modell einen MATLAB-Funktionsblock enthält (Abbildung 1). Das Simulink-Modell der obersten Ebene enthält alle Konfigurationseinstellungen für die Codegenerierung. Der MATLAB-Funktionsblock ruft externe MATLAB-Funktionen auf.

Dieses Modellierungsmuster nutzt alle für Simulink-Modelle verfügbaren Verifizierungs- und Validierungstools und ermöglicht gleichzeitig die Implementierung von Funktionen in der MATLAB-Sprache. [2]. Darüber hinaus nutzt es die umfangreichen Möglichkeiten von MATLAB. Beispielsweise wird die ADAS-Entwicklung typischerweise mit MATLAB implementiert, da komplexe mathematische Funktionen auf prägnante und elegante Weise ausgedrückt werden können.

Es gibt alternative Möglichkeiten, MATLAB [3] in einer sicherheitskritischen Produktentwicklungsumgebung, zu verwenden, die in diesem Artikel nicht erwähnt werden.

MATLAB ISO 26262 Referenz-Workflow: Übersicht

Wie bereits erwähnt, basiert der in diesem Artikel beschriebene Arbeitsablauf auf dem ISO 26262-Referenzarbeitsablauf im IEC Certification Kit (Abbildung 2).

Der MATLAB-basierte Workflow enthält zusätzliche Empfehlungen für die folgenden Verifizierungs- und Validierungsaktivitäten:

• Erstellung von Anforderungen und Überprüfung der Architektur
• Statische Modellanalyse
• MIL-Tests und SIL- oder PIL-Back-to-Back-Tests
• Statische Codeanalyse
• Dokumentation

Erstellung von Anforderungen und Überprüfung der Architektur

Die ISO 26262 verlangt den Nachweis, dass alle Anforderungen umgesetzt und getestet wurden. Im Referenz-Workflow der ISO 26262 liefern die in Abbildung 3 hervorgehobenen Aktivitäten zur Architekturüberprüfung und Anforderungserstellung diesen Nachweis.

Verknüpfen von Anforderungen mit MATLAB-Code

Mithilfe der Requirements Toolbox™ können Sie Anforderungen mit Codezeilen in MATLAB-Funktionen auf die gleiche Weise verknüpfen, wie Sie Anforderungen mit Simulink-Blöcken verknüpfen. Der Unterschied besteht darin, dass bei der vorhandenen Prüfung auf fehlende Anforderungen kein externer MATLAB Code geprüft wird. Es wird empfohlen, eine Model Advisor-Prüfung zu implementieren, die nach MATLAB Containern sucht, die nicht mit einer Anforderung verknüpft sind. Ein Container ist normalerweise eine externe MATLAB Datei oder eine MATLAB Funktion, abhängig von der Größe der Datei.

Statische Modellanalyse

Jede Komponente im Implementierungsmodell muss auf Lesbarkeit, Verständlichkeit und Testbarkeit überprüft werden (Abbildung 4). Simulink Check™ wird verwendet, um die Konformität des Modells mit ISO 26262 und den MathWorks-Richtlinien für Systeme mit hoher Integrität zu bewerten.

Sprachuntergruppe

Beim Programmieren in MATLAB können Funktionen aus mehreren unterschiedlichen Toolboxen zum Einsatz kommen. Da MATLAB eine leistungsstarke Sprache mit einem hohen Abstraktionsgrad ist, können Sie mit wenigen Codezeilen komplizierte Funktionen entwickeln. In manchen Fällen kann eine einzige Zeile MATLAB Code viele Zeilen C-Code ergeben, wodurch die vollständige Überprüfung des generierten Codes schwierig wird. Sie müssen wissen, dass die von Ihnen implementierte Funktionalität testbar ist. ISO 26262 schreibt die Verwendung einer Sprachuntermenge (Tabelle 1 in ISO 26262) basierend auf der Art der von Ihnen verwendeten Funktionen vor.

Wir empfehlen Ihnen, die folgenden Schritte auszuführen, um die Anforderung an die Sprachuntermenge zu erfüllen:

• Bewerten Sie die verwendeten MATLAB Funktionen, um sicherzustellen, dass keine davon einen hohen Verifizierungsaufwand erfordert. Mit Model Advisor kann die Verwendung nicht empfohlener Funktionen aufgrund der Codekomplexität ermittelt werden.
• Ersetzen Sie nicht empfohlene MATLAB-Funktionen durch einfachere Implementierungen. Diese einfacheren Funktionen lassen sich leichter verfolgen und testen.

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

• Überprüfen Sie die Funktion durch separate Unit-Tests mit hoher Abdeckung. Wenn die Abdeckung erreicht ist, begründen Sie die Verwendung dieser Funktionen durch Verweisen auf die externen Komponententests.

Starke Datentypisierung

ISO 26262 erfordert, dass alle Variablen stark typisiert sind. Model Advisor prüft Simulink-Modelle auf stark typisierte Blöcke, einschließlich der Schnittstelle zum MATLAB-Funktionsblock, prüft jedoch keine externen MATLAB-Funktionen. Um dieses Hindernis zu überwinden, schreiben Sie eine Prüfung, um sicherzustellen, dass alle MATLAB Funktionen stark typisiert sind. Besonders wichtig ist die Prüfung von Datentyp und Datendimension.

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

Back-to-back- (Gleichwertigkeits-)Tests ermöglichen Ihnen den Nachweis, dass sich der generierte Code genauso verhält wie das Modell, wie in ISO 26262, Tabelle 7, Methoden zur Software-Unit-Verifizierung, empfohlen. Verwenden Sie für den Objektcode Processor-in-the-Loop-Tests (PIL) und für den generierten C-Code Software-in-the-Loop-Tests (SIL) (Abbildung 5). Die Testfälle sollten dieselben sein, die in Model-in-the-Loop-Tests (MIL) verwendet werden. Verwenden Sie zur Unit-Überprüfung SIL. Für Integrationstests empfiehlt es sich, diese auch auf der Zielhardware auszuführen, um die gesamte Entwicklungs-Toolchain zu überprüfen.

Vermeidung unbeabsichtigter Funktionalität

Um zu beweisen, dass bei der Codegenerierung keine unbeabsichtigte Funktionalität hinzugefügt wurde, messen Sie die Test-Abdeckung sowohl während der Modell- als auch der Code-Tests. Die Test-Abdeckung erfolgt typischerweise durch Back-to-Back-Tests mit Simulink Coverage™. Die Abdeckung wird gemäß ISO 26262 verwendet, um die Vollständigkeit der Verifizierung zu bewerten und den Nachweis zu erbringen, dass die Ziele der Komponententests erreicht wurden.

Gemäß ISO 26262 muss Code mit fehlender Abdeckung überprüft und begründet werden. Bei der Entwicklung mit Simulink-Blöcken können die Begründungen mit dem Modell verknüpft werden, sodass die Begründungen zwischen den Verifizierungsläufen erhalten bleiben. Diese Option ist für externe MATLAB Funktionen nicht verfügbar. Um eine fehlende Abdeckung für eine MATLAB Funktion zu begründen, fügen Sie dem Code einen Abdeckungsfilter hinzu und verbinden Sie ihn dann entweder mit dem Test-Harness oder der Testdatei in Simulink Test™. Wir empfehlen, die Abdeckungsfilterdatei mit der Testdatei zu verbinden (Abbildung 6).

Statische Codeanalyse

Gemäß der Norm ISO 26262 umfassen statische Analysen Aktivitäten wie die Suche im Quellcodetext oder im Modell nach Mustern, die mit bekannten Fehlern übereinstimmen, oder nach der Einhaltung von Modellierungs- oder Codierungsrichtlinien. Am generierten Code werden statische Codeanalysen durchgeführt (Abbildung 7).

MISRA C-Konformität

Zur Beurteilung von MISRA^® C-Konformität für aus MATLAB generierten Code verwenden Sie ein statisches Code-Analysetool wie Polyspace Bug Finder™, um nicht MISRA C-konformen Code zu erkennen und die Ergebnisse manuell zu untersuchen. Wenn der nicht konforme Code von einer integrierten MATLAB Funktion stammt, haben Sie zwei Möglichkeiten:

• Ersetzen Sie die integrierte MATLAB-Funktion durch eine neu geschriebene Funktion
• Schreiben Sie eine Begründung für die MISRA C-Warnung

Unsere Empfehlung ist, die Funktion, wenn möglich, zu ersetzen. Um sicherzustellen, dass die ersetzte Funktion nicht von anderen Entwicklern verwendet wird, implementieren Sie eine Model Advisor-Prüfung auf nicht empfohlene Funktionen.

Dokumentation

Im abschließenden Sicherheitsnachweis, der die Konformität mit ISO 26262 belegt, müssen Sie jeden Schritt des Verifizierungsprozesses dokumentieren, von den Anforderungen bis zur Verifizierung. Die Dokumentation sollte Entwurfsbeschreibungen der Funktionalität enthalten. Abbildung 8 hebt einige der Aktivitäten hervor, die in der Entwurfsbeschreibung enthalten sein müssen.

Beschreibung des Systemdesigns

Simulink Report Generator™ enthält eine vordefinierte Vorlage für Systemdesignberichte. Diese Vorlage ist normalerweise ausreichend für die Dokumentation einer in Simulink entwickelten Komponente, jedoch nicht für die Dokumentation externer MATLAB Funktionen, da diese nicht in der standardmäßigen Systemdesignbeschreibung enthalten sind. Wir empfehlen daher, die Vorlage anzupassen, um den externen MATLAB Code einzubinden.

SOTIF-Überlegungen

In komplexen Systemen wie ADAS kann sich eine Funktion wie beabsichtigt verhalten, aber dennoch gefährliches Verhalten verursachen. Unter Anleitung des ISO 21448-Standards zur Sicherheit der beabsichtigten Funktionalität (SOTIF) können Sie dieses Problem lösen, indem Sie zusätzliche Verifizierungs- und Validierungsaktivitäten in das modellbasierte Design integrieren. Wir empfehlen, randomisierte Betriebszustandstests hinzuzufügen, um die Tests zu erweitern und unbekannte Anwendungsfälle einzubeziehen. Diese Stichprobentests sollen das Verhalten des Implementierungsmodells und des integrierten Objektcodes im Vergleich zu den Systemanforderungen überprüfen.

Das IEC Certification Kit umfasst Unterstützung für SOTIF. Wenn es um SOTIF geht, gibt es keine großen Unterschiede zwischen Simulink und MATLAB Workflows. Das aktualisierte IEC-Zertifizierungskit enthält Informationen zur Verwendung der Automated Driving Toolbox™ für Systemtests.

Zusammenfassung