Modellbasierte Entwicklung und Automatische Code-Generierung für sicherheitskritische Anwendungen Dipl.-Math. Michael Beine Product Management dSPACE GmbH Technologiepark 25 33100 Paderborn [email protected] Abstract: Modellbasierte Entwicklung und automatische Seriencode-Generierung haben in den vergangenen Jahren insbesondere in der Automobilindustrie weite Verbreitung gefunden. Die Automobilindustrie begegnet mit Hilfe dieser Methoden den steigenden Anforderungen, der gestiegenen Komplexität und den kürzeren Entwicklungszeiten. Gleichzeitig werden mehr und mehr sicherheitsrelevante Systeme in heutigen Fahrzeugen verbaut. Zu nennen sind hier Systeme wie ACC, ESP, Aktivlenkung oder Integriertes Chassismanagement, die durch direkten Lenk- und/oder Bremseingriff sowie eine dynamische Verteilung der Antriebsmomente auf das Fahrzeug einwirken. Um eine einheitliche und allgemein anerkannte Vorgehensweise für die Entwicklung sicherheitsrelevanter Systeme zu etablieren, wird derzeit eine automobilspezifische Sicherheitsnorm, die ISO 26262, von Automobilherstellern, Zulieferern und Dienstleistern weltweit erarbeitet. Schon heute orientieren sich Automobilhersteller und Zulieferer an dem aktuellen Committee Draft der ISO 26262, der im Sommer 2008 verabschiedet worden ist.

1 Neuer Sicherheitsstandard Kraftfahrzeugen

für

elektronische

Systeme

in

Die Norm ISO 26262 [1] ist eine Adaption der IEC 61508 [2], der bisher in der Automobilindustrie angewandten Norm zur Entwicklung sicherheitsrelevanter Anwendungen, an die spezifischen Gegebenheiten im Automobilbereich. Ihre Anwendung soll die funktionale Sicherheit eines elektronischen Systems im Kraftfahrzeug gewährleisten. Die offizielle Verabschiedung der ISO 26262 ist zwar erst für 2011 geplant, jedoch soll sie noch im Laufe des Jahres 2009 als Draft International Standard veröffentlicht werden. Die ISO 26262 wird aus insgesamt 9 Teilen bestehen. Sie definiert vier Sicherheitsanforderungsstufen, so genannte Automotive Safety Integrity Level, kurz ASIL, von A bis D, wobei D die höchste Sicherheitsstufe ist. Auf Basis einer Gefahrenanalyse und Risikoabschätzung sind zunächst entsprechende ASIL für die zu entwickelnden Systeme zu bestimmen. Diese Einstufungen müssen anschließend in allen nachfolgenden Phasen des Sicherheits-Lebenszyklus berücksichtigt werden

Im Gegensatz zur IEC 61508, die in den 1990er Jahren erarbeitet und herausgegeben worden ist, als modellbasiertes Entwicklungsvorgehen in der Industrie wenig verbreitet war, geht die ISO 26262 konkret auf das Thema der modellbasierten Entwicklung ein. So werden im Anhang zu Teil 6, Produktentwicklung: Softwareebene, in einem separaten Abschnitt Grundlagen und Charakteristiken der modellbasierten Entwicklung beschrieben und es wird auf Unterschiede zwischen der modellbasierten und codebasierten Entwicklung hingewiesen. Relevant für die modellbasierte Softwareentwicklung sind insbesondere dieser Teil 6 sowie Abschnitte aus dem Teil 8, Unterstützende Prozesse, zum Beispiel die Abschnitte zu Verifikation oder Qualifizierung von Softwaretools.

2 Modellbasierte Softwareentwicklung nach ISO 26262 Bevor die eigentliche Softwareentwicklung starten kann, sind zunächst die Entwicklungsaktivitäten der einzelnen Phasen, namentlich Design, Implementierung, Test und Integration zu planen sowie dem ASIL entsprechende prozessunterstützende Methoden und Maßnahmen zu bestimmen. Zu nennen sind hier insbesondere die Auswahl von einzusetzenden Werkzeugen sowie von entsprechenden Modellierungsund Codierungsrichtlinien. Einsatz von Modellierungs- und Codierungsrichtlinien Durch die Verwendung von Modellierungs- und Codierungsrichtlinien soll beispielsweise sichergestellt werden, dass sichere Sprachsubsets, etablierte DesignPattern, eindeutige grafische Repräsentationen und defensive Implementierung verwendet werden. Ferner sollen Namenskonventionen festgelegt und eingehalten sowie bekannte und potentielle Fehler in Entwicklungswerkzeugen ausgeschlossen werden. ISO 26262 stellt fest, dass ohne etwaige Richtlinien die für eine geeignete Modellierungs- und Programmiersprache zu erfüllenden Kriterien oftmals nicht erfüllt werden. ISO 26262 empfiehlt vor diesem Hintergrund, Modellierungs- und Codierungsrichtlinien heranzuziehen, um Kriterien, die nicht ausreichend von der Modellierungs- und Programmiersprache abgedeckt werden, zu erfüllen. Für die in der Automobilindustrie weit verbreitete und im Folgenden als Beispiel betrachtete grafische Entwicklungsumgebung Simulink®/TargetLink existieren mit den von der MISRA erstellten Modellierungsrichtlinien für die Anwendung von TargetLink entsprechende Richtlinien [3], die explizit einen Fokus auf funktionale Sicherheit legen. Darüber hinaus gibt es auf Modellebene mit den MAAB-Richtlinien [4] und den TargetLink-Modellierungsrichtlinien [5] weitere etablierte Richtliniendokumente. Für die gewöhnlich eingesetzte Programmiersprache C werden in der ISO 26262 explizit die MISRA C-2004 Richtlinien [6] als geeignete Codierungsrichtlinie erwähnt. Den Anwendern steht ein MISRA C-2004 Compliance-Dokument für den von TargetLink erzeugten Code zur Verfügung.

Nachverfolgbarkeit Ebenfalls von Anfang an zu bedenken, ist eine Unterstützung für die Nachverfolgbarkeit über alle Phasen der Produktentwicklung hinweg: von den Anforderungen in textueller Form über das modellbasierte Design bis hin zur Implementierung auf Codeebene sowie für das für alle ASIL geforderte anforderungsbasierte Testen. Von zentraler Bedeutung ist die Möglichkeit, Anforderungen in das Modell und vom Modell aus nachverfolgen zu können. Das Requirements Management Interface [7] erlaubt die Erstellung von bidirektionalen Links zwischen Anforderungsmanagement-Werkzeugen wie DOORS und dem Simulink/TargetLink-Modell. Der eingesetzte Code-Generator muss die Nachverfolgbarkeit vom Modell bis auf Codeebene unterstützen. Dies geschieht zum Beispiel durch die Erzeugung von Code im HTML-Format mit entsprechenden Hyperlinks zwischen Code und Modell und/oder direkten Links zum Anforderungsmanagement-Werkzeug oder auch durch das direkte Navigieren aus dem Modell zu den entsprechenden Stellen im Code. Software-Architektur-Design Die Erstellung eines Architektur-Modells, das alle Software-Komponenten und deren Schnittstellen und Interaktionen beschreibt, erfüllt die Forderung nach einer semiformalen Beschreibung der Software-Architektur für alle ASILs. Durch die Möglichkeit Architektur-Modelle hierarchisch und modular aufzubauen, lassen sich allgemeine zu berücksichtigende Designaspekte wie Wartbarkeit, Modularität und Kapselung, Komplexität und Testbarkeit berücksichtigen. Statische Aspekte wie die konsistente Beschreibung von Schnittstellen und Signalpfaden und auch dynamische Aspekte wie Abarbeitungsreihenfolgen können dann, wie in der ISO 26262 gefordert, mit Hilfe eines solchen Modells anhand von Modellreviews, durch Simulation und weitere Analysen effizient verifiziert werden. Entsprechende Software-ArchitekturModelle lassen sich in speziellen Systementwurfswerkzeugen wie SystemDesk [8] oder auch direkt in Simulink erstellen. Software Unit Design und Implementierung Basierend auf dem Software-Architektur-Modell lässt sich das Design der einzelnen Software Units in Form von separaten Software-Komponenten-Modellen entwickeln und gleichzeitig dokumentieren. Die Implementierung der Software Units erfolgt durch automatische Codegenerierung direkt aus den Software-Komponenten-Modellen sowie durch Übersetzung des erzeugten Sourcecodes in Objectcode. Vor Erzeugung des Sourcecodes sind die Komponenten-Modelle um sämtliche für die Implementierung notwendigen Informationen angereichert worden und werden dann häufig auch als Implementierungsmodelle bezeichnet. Die Implementierungsmodelle sind damit zugleich die Software-Unit-Design-Spezifikation. Für Design und Implementierung der Software Units ist die Anwendung und Einhaltung der bereits erwähnten und im Vorfeld festgelegten Modellierungs- und Codierungsrichtlinien von zentraler Bedeutung. Um sicherzustellen und nachzuweisen, dass Richtlinien angewandt wurden, empfiehlt sich der Einsatz von Richtliniencheckern. Diese sind in der Lage, auch größere Modelle und umfangreichen Sourcecode effizient auf Richtlinienkonformität zu prüfen und können schon früh entwicklungsbegleitend eingesetzt werden.

Der Model Examiner [9] als ein Werkzeug zur Überprüfung von Modellierungsrichtlinien für Simulink/Stateflow- und TargetLink-Modelle stellt nicht nur Checks zur Überprüfung der bereits erwähnten MISRA-TargetLink-, MAAB- und TargetLink-Modellierungsrichtlinien bereit, sondern bietet auch Checks, die auf das Nicht-Vorhandensein von bekannten Werkzeugproblemen prüfen. Modell- und Code-Reviews Für die Absicherung des Designs sowohl der Software-Architektur als auch der Software Units und der Implementierung spielen Reviews eine wichtige Rolle. Die ISO 26262 unterscheidet hier zwischen Inspections und Walkthroughs. Modellierungswerkzeug und Code-Generator können auch diesen Prozess unterstützen. Automatisch erzeugte Reports beispielsweise können nicht nur die Modellstruktur, sondern auch Implementierungsinformationen wie Datentypen, Skalierungen, Variablenklassen und auch Simulationsergebnisse für typische Anwendungsfälle wie Start-up oder Initialisierungsverhalten enthalten. Mit Hyperlinks ins Modell hinterlegter Code oder die Möglichkeit, auch vom Modell direkt in den Code navigieren zu können, unterstützen den direkten Review von Modell und Code. Von besonderer Bedeutung sind in diesem Zusammenhang eine gute Lesbarkeit und ausführliche Kommentierung des automatisch erzeugten Codes. Software Unit Testing Im anschließenden Test der Software Units ist nachzuweisen, dass die Software Unit genau der Software-Unit-Spezifikation entspricht und keine unerwünschten Funktionen enthält. Hierzu sind sowohl funktionale als auch strukturelle Tests durchzuführen sowie der Ressourcenbedarf zu messen. An dieser Stelle bietet sich die Durchführung von Back-to-Back-Tests zwischen Simulationsmodell und automatisch erzeugtem Code an; die Durchführung wird für alle ASILs explizit von der ISO 26262 empfohlen. Generell bilden die Simulationsmöglichkeiten im Umfeld der modellbasierten SoftwareEntwicklung auch zum Testen eine ideale Plattform. Ein Werkzeug wie TargetLink erlaubt nicht nur die direkte Simulation und somit den direkten Test der Software-UnitSpezifikation (Model-in-the-Loop), sondern auch die Ausführung des erzeugten Codes direkt auf dem Host-PC (Software-in-the-Loop), sowie die Ausführung auf dem im Projekt verwendeten Zielprozessor (Processor-in-the-Loop). PIL-Tests sind zum Beispiel nötig, um im Rahmen des Software-Unit-Tests geforderte Ressourcen-Bedarfsnachweise wie Laufzeitmessungen zu erbringen, da nur in diesem Modus der Target Compiler und die Target Hardware im Spiel sind. Wesentlicher Aspekt für die Durchführung von funktionalen Tests ist die Herleitung und Erstellung von entsprechenden Testvektoren. Simulink selbst bietet umfangreiche Möglichkeiten zur Definition von Stimuli-Signalen über spezielle SignalgeneratorBlöcke oder das Einbringen von Stimuli-Signalen über den MATLAB Workspace. Externe Testwerkzeuge, die die Ableitung von Testvektoren aus den Anforderungen, die Ausführung von Tests in den oben angeführten Simulationsmodi MIL, SIL, PIL und die Dokumentation der Testergebnisse unterstützen, stehen dem Anwender zur Verfügung [10, 11, 12].

Abbildung 1: Simulationsmodi und Back-to-Back-Tests

Zusätzlich zum Test der Funktion fordert die ISO 26262 dem jeweiligen ASIL entsprechende Nachweise, dass sowohl das Modell als auch der Code hinreichend strukturell abgedeckt sind. Auch für diese Aufgabe steht dem Simulink/TargetLinkAnwender entsprechende Werkzeugunterstützung zur Verfügung [13, 14, 15, 16]. Software-Integration und –Test Bei der modellbasierten Entwicklung erfolgt die Software-Integration durch die Integration der Komponenten-Modelle auf Modellebene. Hierzu wird das im SoftwareArchitektur-Design erstellte Software-Architektur-Modell verwendet. Aus diesem Integrationsmodell kann Code für die Verschaltung der einzelnen KomponentenModelle erzeugt werden. Der in der Software-Unit-Testphase bereits abgesicherte Code für die einzelnen Komponenten-Modelle muss hingegen nicht neu erzeugt werden. Auf Basis des Integrationsmodells kann nun der Software-Integrationstest durchgeführt werden. ISO 26262 empfiehlt die gleichen Methoden wie für den Software-Unit-Test: funktionale Tests, strukturelle Tests, Messung des Ressourcenbedarfs sowie Back-toBack-Tests zwischen Simulationsmodell und Code. Diese Tests lassen sich analog zum Software-Unit-Test mit den gleichen Werkzeugen durchführen.

3 Toolqualifizierung In Teil 8 „Supporting Processes“ befasst sich die ISO 26262 unter anderem mit dem Thema Toolqualifizierung. Eine der ersten Fragen, die sich dem Anwender bei der Verwendung von modellbasierter Entwicklung und automatischer Code-Generierung für die Entwicklung sicherheitskritischer Systeme stellt, ist die der Werkzeugqualifizierung. Ziele einer Qualifizierung von Werkzeugen sind die Vertrauenssteigerung in das Werkzeug und der Eignungsnachweis für die Verwendung in sicherheitskritischen Entwicklungsprojekten. Darüber hinaus soll durch den Einsatz qualifizierter Werkzeuge

der Aufwand für die Überprüfung der Ergebnisse reduziert werden. Vor diesem Hintergrund führt die ISO 26262 unterschiedliche Methoden und Möglichkeiten zur Qualifizierung von Werkzeugen an. Verwendung nicht qualifizierter Werkzeuge möglich Andererseits sieht die ISO 26262 explizit auch die Möglichkeit vor, nicht qualifizierte Werkzeuge für die Entwicklung sicherheitskritischer Software einzusetzen. Dies ist heute gängige Praxis für Entwicklungswerkzeuge wie Compiler, Linker und CodeGeneratoren. ISO 26262 stellt dazu – quasi analog zur DO-178B [17] im Luftfahrtbereich – fest, dass die Qualifizierung eines Werkzeuges nur dann gefordert ist, wenn die Ergebnisse des Werkzeuges nicht vollständig überprüft werden. In diesem Sinne werden nichtqualifizierte Code-Generatoren erfolgreich für die Entwicklung von sicherheitskritischen Systemen in der Automobilindustrie und in der Luftfahrt eingesetzt [18, 19]. Wesentliche Vorteile bei der Verwendung von nicht qualifizierten Werkzeugen sind zum einen die Möglichkeiten, kurzfristig Patch-Versionen zur Fehlerbehebung sowie Versionen mit neuer Funktionalität einsetzen zu können, ohne auf eine Nachqualifizierung dieser neuen Versionen warten zu müssen, und zum anderen die Tatsache, dass keine zusätzlichen Werkzeugkosten (qualifizierte Werkzeuge können signifikant teurer sein als nicht qualifizierte) und keine Extra-Qualifizierungskosten anfallen [20]. Qualifizierung durch Validierung Eine explizit in der ISO 26262 erwähnte Methode ist die Qualifizierung von Entwicklungswerkzeugen anhand einer Validierungssuite. Diese Methode ist von dem deutschen Arbeitskreis „Autocoder Validation Suite“, kurz AVS, einem Arbeitskreis, der von deutschen Automobilherstellern, Zulieferern, dem TÜV Rheinland und dSPACE im Herbst 2004 ins Leben gerufen wurde, näher definiert und von BMW erfolgreich angewandt worden. BMW hat mit Hilfe einer Validierungssuite TargetLink für die Verwendung in sicherheitskritischen (ASIL D) Projekten qualifiziert. Die ersten Entwicklungsprojekte, die auf diese Weise qualifizierte TargetLink-Versionen eingesetzt haben, sind erfolgreich abgeschlossen und die so entwickelten Steuergeräte in homologierten Fahrzeugen im Einsatz [21, 22]. BMW hat dazu eine Testumgebung aufbauen und entwickeln lassen, die ausreichend Testfälle enthält, um TargetLink anhand der vom TÜV definierten Anforderungen zu qualifizieren. Der initiale Aufwand für die Erstellung einer solchen Validation Suite ist recht hoch, jedoch lassen sich mit relativ geringem Aufwand weitere Qualifizierungen erstellen, zum Beispiel für neue Versionen oder Kombinationen aus Compiler, Linker und Code-Generator. Dies ist wichtig, da der verfolgte Ansatz eine Revalidierung erfordert, sobald sich die zu validierende Werkzeugkette, bestehend aus Code-Generator, Compiler und Linker ändert, zum Beispiel wenn eine neue Werkzeugversion eingesetzt werden soll, Änderungen an der Konfiguration der eingesetzten Werkzeuge vorgenommen werden sollen oder auch wenn ein anderer Zielprozessor zum Einsatz kommt.

Abbildung 2: Prinzip der Validierungssuite: Stimuli-Signale werden auf das Modell (MILSimulation) und den erzeugten Code (PIL-Simulation) angewandt und die Simulationsergebnisse verglichen.

Qualifizierung Ja oder Nein? Qualifizierung kann als offizielle Bescheinigung dafür angesehen werden, dass ein Werkzeug für die Entwicklung sicherheitskritischer Software geeignet ist. Eine Werkzeugqualifizierung kann auf unterschiedliche Art und Weise erfolgen, z.B. auf Basis einer erfolgreichen Validierung, und erhöht gewöhnlich das Vertrauen in den Einsatz des Werkzeuges im sicherheitskritischen Projekt. Jedoch darf eine Qualifizierung nicht missverstanden werden als Nachweis oder Garantie dafür, dass ein Werkzeug fehlerfrei ist. Letztendlich liegt es im Ermessen des Anwenders bzw. der Projektverantwortlichen, entweder auf qualifizierte Werkzeuge zu setzen oder nicht qualifizierte Werkzeuge zu verwenden und den Schwerpunkt damit auf die Verifikation im Projekt zu legen. Beide Ansätze haben Vorteile, sind erfolgreich praktiziert worden und werden auch aktuell in der Automobilindustrie verfolgt.

4 Zusammenfassung Modellbasierte Softwareentwicklung und automatische Code-Generierung sind geeignet für die Entwicklung von sicherheitsrelevanten Anwendungen. Die bei der Entwicklung solch sicherheitsrelevanter Anwendungen nach ISO 26262 zusätzlich zu beachtenden Anforderungen an die eingesetzten Methoden, Prozesse und Werkzeuge lassen sich insbesondere auch bei der und durch die Verwendung modellbasierter Methoden erfüllen. Dem Anwender zur Verfügung stehende Methoden und Werkzeuge wurden vorgestellt und die Frage nach der Qualifizierung eingesetzter Werkzeuge diskutiert.

Literaturverzeichnis [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21]

Road vehicles – Functional Safety, International Organization for Standardization, ISO 26262 (Committee Draft), 2008 Functional Safety of Electrical/Electronic/Programmable Electronic Safety Related Systems, IEC 61508, 1998 MISRA AC TL: Modelling style guidelines for the application of TargetLink in the context of automatic code generation, 2007, Version 1.0 MathWorks Automotive Advisory Board, Control Algorithm Modeling, Guidelines using MATLAB®, Simulink®, and Stateflow®, Version 2.0, 2007 Modeling Guidelines for MATLAB/Simulink/Stateflow and TargetLink Version 2.1, dSPACE GmbH, 2008 MISRA-C: 2004 Guidelines for the use of the C Language in critical systems, MIRA, 2004 Tracing Requirements to Designs, Tests, and Generated Code, http://www.mathworks.com/products/simverification SystemDesk, http://www.dspace.com/ww/de/gmb/home/products/sw/system_architecture_software/sy stemdesk.cfm Model Examiner: Automatic Compliance Checks for Simulink and TargetLink models, http://www.model-engineers.com/our-products/model-examiner.html EmbeddedTester, http://www.osc-es.de/ Reactis, http://www.reactive-systems.com/ MTest classic, http://www.mtest-classic.com/ Analyzing Model Coverage, http://www.mathworks.com/products/simverification Code Coverage Analysis, http://www.dspace.de/ww/en/pub/home/products/sw/pcgs/code_coverage.cfm CTC++, http://www.verifysoft.com/de.html IBM Test Real-Time www.ibm.com/developerworks/rational/products/testrealtime RTCA/DO-178B Software Considerations in Airborne Systems and Equipment Certification, RTCA Inc., 1. Dez. 1992. Tauber, Hermann (ATENA Engineering GmbH); Jungmann, Michael (MTU Aero Engines GmbH): TargetLink for Safety-Critical Systems. dSPACE NEWS 3/2003 Nord-Micro: Höchste Sicherheit, dSPACE Magazin 1/2009. Beine, Michael; Jungman, Michael: Automatische Code-Generierung für sicherheitskritische Systeme. Automotive Electronics (Sonderheft ATZ/MTZ), Sep 2003. Schneider, Stefan-Alexander; Lovric, Tomislav; Mai, Pierre R.: The Validation Suite Approach to Safety Qualification of Tools. Automotive Safety and Security, Stuttgart, November 2008.

[22]

Billig, Christian; Boedrich, Harald; Brack, Juergen; Hoell, Bertram; Holle, Michael; Kimmich, Frank (2008): Die Dynamic Performance Control von BMW. ATZ, 11/2008.