Sicherheitskonzepte aus Luft- und Raumfahrt landen in der Automobilindustrie

Werkzeuglandschaft

In Luft- und Raumfahrt gibt es einen wichtigen Standard, ARINC 653, der speziell entwickelt wurde, um diese Art von Unabhängigkeit im Rahmen von Integrated Modular Avionics (IMA) zu gewährleisten. Ein zertifiziertes ARINC-653-kompatibles Betriebssystem bietet sogenannte Partitions, die sowohl zeitlich als auch räumlich voneinander getrennt sind. Eine klar definierte API steuert alle Interaktionen zwischen ihnen, sodass mehrere Anwendungen einen einzelnen Prozessor und Speicher sicher gemeinsam nutzen können, mit der Gewähr, dass die Anwendungen sich nicht gegenseitig stören. Es gibt kommerzielle Echtzeit-Betriebssysteme, die ARINC 653 unterstützen, und an deren Anpassung an den FFI-Anforderungen der ISO 26262 bereits gearbeitet wird.

Ein weiteres Beispiel für die zunehmende Überlappung zwischen Qualitätskonzepten der Luft- und Raumfahrtsoftware und ISO 26262 bietet der Bereich der Structural Coverage Analysis von eingebettetem Code. In DO-178B und C gibt es strukturelle Anforderungen der Coverage als Teil der anforderungsbasierten Prüfung sicherheitskritischer Bauteile. Diese Structural Coverage Requirements werden strenger, wenn die Kritikalität der Komponente steigt. Die höchste strukturelle Coverage bietet "MC/DC" (Modified Condition/Decision Coverage). ISO 26262 hat dieses Level auch für die kritischsten Softwarekomponenten in der Automobilindustrie übernommen. Wegen der langfristigen Bedeutung der MC/DC Coverage Analysis in der Softwareentwicklung für die Luft- und Raumfahrt gibt es viele Werkzeuge, die die MC/DC Coverage messen können und Programmierern helfen, das erforderliche Maß an Abdeckung zu erreichen. Diese werden nun für die Autoindustrie wichtig, da sich ISO 26262 hier zunehmend verbreitet.

Die Anpassung von Tools der Luft- und Raumfahrt für die Automobilindustrie und umgekehrt erfordert mehrere Tools, die eine hochintegrierte, modellbasierte Softwareentwicklung unterstützen. Den Kern des Toolsets bildet ein automatischer Codegenerator, der normalerweise von einem Simulink-/Stateflow-Modell ausgeht, dem man vertrauen kann, dass es die Sicherheitseigenschaften des Modells im generierten Code bewahrt. In DO-178C-Begriffen sollte der Codegenerator auf dem Tool Qualification Level 1 (TQL-1) qualifizierbar sein. Dadurch eignet er sich für die Generierung von Code, der Teil eines DO-178C-Level-A-Systems (die kritischsten) sein wird. Das Tool sollte auch für den Einsatz auf ASIL-D-Systemen nach ISO 26262 zertifiziert sein. Der generierte Quellcode sollte in einer sicheren Sprachuntermenge wie SPARK oder MISRA-C geschrieben sein.

Der Verifizierungsprozess für einen derartigen Codegenerator, der bei TQL-1 für DO-178C qualifizierbar ist, ist im Wesentlichen derselbe wie der für jede Laufzeitkomponente, die Teil eines Level-A-Systems ist. Da der Codegenerator deutlich größer als typische Laufzeitkomponenten und auch ganz anders strukturiert ist, wird ein Ansatz benötigt, um ihn hinsichtlich seiner Anforderungen zu verifizieren. Wie viele Werkzeuge, die hochwertigen Code erzeugen, arbeitet der Codegenerator in mehreren Phasen, wobei jede Phase den Output der früheren übernimmt und den ursprünglichen Input so schrittweise in den endgültigen Output umwandelt.

Manuelles Unit-Testing jeder Phase eines solchen Werkzeugs kann mühsam sein, denn die Input- oder Output-Formate sind oft spezielle Baumstrukturen. Und es gibt nur wenige praktikable Werkzeuge für das Erstellen oder den Vergleich der Unit-Tests. Statt für jede Phase des Codegenerators individuelle Unit-Tests zu erstellen, lässt sich das sogenannte Integrated Unit Testing verwenden. Hier werden End-to-End-Integrationstests durchgeführt, wobei der Input ein Modell in der ursprünglichen Modellierungssprache ist und der Output des generierten Codes in der Programmiersprache erfolgt, die beide Werkzeuge für die Erstellung und Überprüfung verwenden.

Beim Integrated Unit Testing kann ein Modell als Input verwendet werden.

Ein solcher Test erfolgt mit einer instrumentierten Version des Tools. Die Instrumentierung umfasst eine Folge sogenannter Monitors und Oracles, die nach bestimmten Input-Mustern in einer Phase suchen und verifizieren, dass der Output dieser Phase mit dem übereinstimmt, was das "Orakel" auf der Grundlage des Inputs und der Low-Level-Werkzeuganforderungen voraussagt.

Das Integrated Unit Testing gilt als vollständig, wenn jedes Muster des Inputs – entsprechend jedem einzelnen Fall in den Low-Level-Tool-Anforderungen – vom Monitor für jede Phase erkannt wird und wenn der Output mit den Vorhersagen des Orakels und den Anforderungen übereinstimmt. Mit diesem Testansatz lässt sich ein komplexes Mehrphasen-Transformationswerkzeug hinsichtlich des Vertrauensniveaus, das das jeweils kritischste System erfordert, verifizieren.

Ein qualifizierbarer Codegenerator reduziert die Kosten einer Verwendung modellbasierter Entwicklung für kritische Systeme, aber es gibt noch viele andere Werkzeuge, die erforderlich sind, um die Sicherheit eines modellbasierten Systems zu gewährleisten. Daher sollte der automatische Codegenerator mit einem qualifizierbaren statischen Analyse-Tool verbunden werden, um mögliche Laufzeitfehler im Modell zu finden – beispielsweise Division durch Null. Dasselbe gilt für einen Modell-Level-Debugger, der das Processor-in-the-Loop-Debugging ermöglicht, oder auch für Back-to-Back-Tests, die nach ISO 26262 für modellbasierte Systeme vorgesehen sind.

Der Modell-Level-Debugger sollte Programmierern gleichzeitig Ansichten des ursprünglichen Modells in grafischer Darstellung und den generierten Code liefern, der auf dem Zielsystem oder einem Emulator läuft, und zwar mit Traceability-Links, die das Hin- und Herspringen zwischen einem Block im Modell und den entsprechende Zeilen im Code ermöglichen. Das Toolset sollte über verschiedene Cross-Compiler, einschließlich der auf ein ARINC-653-kompatibles RTOS (Real-Time Operating System) ausgerichteten, einen Zielemulator und ein Tool für die MC/DC Structural Coverage Analysis verfügen.