Durchgängige Realisierung von Steuergerätesoftware

Transkript

1 Durchgängige Realisierung von Steuergerätesoftware nach ISO Durch die zunehmende Anwendung der Norm ISO werden Anforderungen an die Entwicklung und Absicherung von E/E-Systemen klar definiert. In diesem Artikel beschreibt Vector eine kostensenkende und durchgängige Methodik und Werkzeugumgebung zur Autosar-konformen Umsetzung der ISO bei der Entwicklung von Steuergerätesoftware. Im Besonderen wird der Bezug auf die Sicherheitsziele und -anforderungen durchgängig dargestellt. Dabei unterstützt die Autosar-Basissoftware auch Mixed-ASIL-Systeme, die das kostenintensive Anheben von Systemfunktionen mit niedrigerem ASIL auf einen höheren ASIL vermeiden. 330

2 AutorEN Dipl.-iNf. Steffen Keul ist Produkt-Management-Ingenieur für Autosar bei der Vector Informatik GmbH in Stuttgart. Dr. Eduard Metzker ist Senior Produkt-Management- Ingenieur für Systems-Engineering- Werkzeuge bei der Vector Informatik GmbH in Stuttgart. Dr. Dieter Lederer ist Partner und Geschäftsführer der Vector Consulting Services GmbH in Stuttgart. Nachweis der Sicherheitsziele Um die vollständige Abdeckung der Sicherheitsziele nach ISO [1, 2] zu gewährleisten, muss die Durchgängigkeit der Sicherheitsanforderungen bis hin zu einzelnen Software-Arbeitsprodukten wie Code-Module oder Testfälle nachgewiesen und dokumentiert werden. In den folgenden Abschnitten werden die Vorteile einer durchgängigen Werkzeugunterstützung für die System- und Softwareentwicklung nach ISO dargestellt. Als technisches Beispiel zur Veranschaulichung dient ein Spurhalteassistent (Lane Departure Warning, LDW). Item-definition Ziel ist es, das zu betrachtende System ein- und von seiner Umgebung abzugrenzen und damit die nachfolgenden Arbeitsschritte auf einen definierten technischen Fokus einzuschränken. Dazu wird das zu entwickelnde System auf Basis von kundenerlebbaren Funktionen und deren Interaktion untereinander sowie mit der Systemumgebung beschrieben. Ergänzt wird dies durch die Definition von Betriebssituationen und Betriebsarten, die für das System relevant sind. Damit ist die Grundlage für die nachfolgenden Arbeitsschritte gelegt. Ziel ist es, sämtliche Systemfunktionen zu betrachten und die Risiken zu bestimmen, die durch potenzielle Fehlfunktionen des Systems eintreten können. Die identifizierten Risiken werden zunächst anhand der Betriebssituationen und Betriebsarten, in denen sie sich ereignen können, beschrieben. Dann werden sie klassifiziert hinsichtlich ihrer Eintrittswahrscheinlichkeit, des Schweregrads ihrer Auswirkung und der Möglichkeit, das Risiko so zu kontrollieren, dass schädliche Auswirkungen gemindert werden. Daraus folgt dann unmittelbar der ASIL (Automotive Safety Integrity Level) der jeweiligen Systemfunktion. Für alle kritischen Systemfunktionen, das heißt solche mit mindestens einem ASIL A, müssen nun Sicherheitsziele definiert werden, mit deren Erfüllung das jeweilige Risiko soweit gemindert wird, dass keine unvertretbaren Auswirkungen mehr von ihm ausgehen. Ein durchgängiges Systems-Engineering-Werkzeug wie Vectors PREEvision stellt hierfür eine Umgebung zur Verfügung, mit der eine Gefahren- und Risikoanalyse komfortabel durchgeführt wird, zum Beispiel in Form einer tabellarischen Darstellung, 1. Dabei können Betriebssituationen und Betriebsarten vordefiniert und damit standardisiert sowie eine automatisierte ASIL-Bestimmung genutzt werden. Gefahren- und Risikoanalyse Als nächster Schritt schließt sich die Gefahren- und Risikoanalyse an. Diese ist im Teil 3 der ISO beschrieben. Funktionales Sicherheitskonzept Bei der Erstellung des funktionalen Sicherheitskonzepts werden die Sicher- 1 Gefahren- und Risikoanalyse 05I Jahrgang 331

3 2 Funktionales Sicherheitskonzept heitsziele mittels funktionaler Sicherheitsanforderungen verfeinert und den Systemfunktionen zugeordnet, die diese Anforderungen erfüllen sollen. Durch diese Vorgehensweise entsteht sukzessive das funktionale Sicherheitskonzept, das unabhängig von der späteren Realisierung der Funktionen in Hardware beziehungsweise Software ist. 2 zeigt, welche Systemfunktionen zur Erreichung der entsprechenden Sicherheitsziele Beiträge leisten müssen. Dahinter liegen die entsprechenden Sicherheitsanforderungen. Technisches Sicherheitskonzept Bei der Erstellung des technischen Sicherheitskonzepts werden die funktionalen Sicherheitsanforderungen in technische Sicherheitsanforderungen verfeinert und die Systemfunktionen den Elementen der technischen Systemarchitektur zugeordnet, 3. In einem frühen Stadium der Entwicklung genügt hier eine Zuordnung zu den Komponenten des Systems, während im späteren Stadium das weitere Herunterbrechen auf die Realisierung in Hardwarebeziehungsweise Softwareelementen erfolgt. c zeigt einen Ausschnitt aus dem Komponentennetzwerk, das für das LDW-System relevant ist. Den beteiligten Komponenten sind Sicherheitsfunktionen und -anforderungen zugeordnet. Durch automatisierte Konsistenzchecks ist sofort erkennbar, wo beispielsweise der ASIL der zu realisierenden Systemfunktion und die bisherige Qualifizierung der Komponenten nicht kongruent zu einander sind, c (rot umrandete Komponenten). Ist in der Entwicklung eine Verfeinerung bis hin zu den zu realisierenden Softwareelementen erfolgt, kann die so entstandene Softwarearchitektur auf der Basis einer Autosar-konformen Beschreibung mit anderen Werkzeugen ausgetauscht und weiterentwickelt werden. Somit besteht auch über Werkzeuggrenzen hinweg Durchgängigkeit und Nachverfolgbarkeit. Sicherheitsanalysen Zur Überprüfung des technischen Sicherheitskonzepts werden Sicherheitsanalysen wie FMEA oder FTA durchgeführt. Ziel dieser Analysen ist es, mögliche Schwachstellen im Sicherheitskonzept zu identifizieren und diese über 3 Technisches Sicherheitskonzept 332

4 geeignete Verbesserungen zu eliminieren. Hier wird erneut der Vorteil eines durchgängigen Werkzeugs erkennbar: Die FMEA wird auf den vorhandenen systembeschreibenden Daten durchgeführt und daraus folgende Maßnahmen werden direkt den Systemkomponenten/ -elementen zugeordnet. Damit erübrigt es sich, die Systemstruktur in einem separaten FMEA-Werkzeug nachzubilden, was sowohl zur Erhöhung des Aufwands als auch zu potenziellen Inkonsistenzen und Lücken bei der Nachverfolgbarkeit führt. Sicherheitsnachweis Ziel des Sicherheitsnachweises (Safety Case) ist es, zusammenfassend und nachvollziehbar darzustellen, dass das System so entwickelt wurde, dass es frei von nicht akzeptablen Risiken ist. Hier wird wiederum der Vorteil der in den vorangegangenen Kapiteln vorgestellten durchgängigen Werkzeugunterstützung sichtbar: Alle für den Safety Case benötigten Informationen liegen vor, sind konsistent und können quasi auf Knopfdruck abgerufen und in Form eines Berichts ausgegeben werden und zwar zu jedem beliebigen Zeitpunkt während der Entwicklung. Realisierung von Mixed-asil- Systemen mittels Autosar Betrachtet man das oben dargestellte technische Sicherheitskonzept für eine LDW, so zeigt sich folgende Herausforderung: Sollen auf einer Systemkomponente Anteile von Systemfunktionen mit unterschiedlichem ASIL implementiert werden, zum Beispiel für die Komponente Driver Assistance, c, so muss diese Komponente bei Abwesenheit weiterer Maßnahmen entsprechend dem höchsten ASIL entwickelt werden. Das möchte man jedoch in der Praxis vermeiden, da damit erhöhte Aufwände und Kosten einhergehen. Als Lösung bietet es sich hier an, Funktionsanteile mit unterschiedlichem ASIL mittels Mechanismen des Autosar- Betriebssystems so nebeneinander zu betreiben, dass diese sich nicht gegenseitig störend beeinflussen. Man spricht hier von der sogenannten Rückwirkungsfreiheit, die dann nachzuweisen ist. Dieser Nachweis muss drei Anforderungen erfüllen, die im folgenden Abschnitt beschrieben werden. UmsetzuNG der Rückwirkungsfreiheit Die Umsetzung dieser Rückwirkungsfreiheit kann mittels dreier Module in der Autosar-Basissoftware erreicht werden, die die folgenden Anforderungen erfüllen: Korrektes zeitliches Verhalten der Software: Zur Prüfung des korrekten zeitlichen Verhaltens dient der Watchdog- Manager : Der Anwender definiert Kontrollpunkt und ruft in der Anwendungssoftware bei Erreichen eines Kontrollpunkts eine Funktion auf. Bei Nichterreichen eines s innerhalb der erlaubten Zeit oder bei Ausführung einer inkorrekten Reihenfolge von s wird ein Neustart des Systems ausgelöst. Korrekte Kommunikation: Zum Nachweis der korrekten Kommunikation zwischen Software-Komponenten wird die End-to-end-Absicherung eingesetzt. Mittels Übertragung und Prüfung von Checksummen und Sequenznummern zusätzlich zu jeder Signalgruppe, werden verfälschte oder fehlende Nachrichten erkannt. Vermeidung fehlerhafter Speicherzugriffe: Dies wird durch das Autosar- Betriebssystem zur Laufzeit des Systems mittels einer Hardware-MPU (Memory Protection Unit) erzwungen. Dazu wird die Software in verschiedene Betriebssystemanwendungen, sogenannte OS-Applications, partitioniert und jeder OS-Application nur solche Software-Komponenten zugeteilt, für die bekannt ist, dass das Risiko einer gegenseitigen Beeinflussung akzeptabel gering ist. Die Hardware- MPU erkennt und verhindert nicht autorisierte Zugriffe aus einer Betriebssystemanwendungen heraus auf den Speicherbereich einer anderen OS-Application. Kontext-Wechsel versus Ko - existenz von sw-komponenten Die Partitionierung in separate OS-Applications ermöglicht die Realisierung eines Mixed-ASIL-Systems, also der sicheren Verwendung von Software-Elementen mit verschieden hohen ASIL auf einer gemeinsamen Hardware-Plattform. Bei häufiger Kommunikation zwischen verschiedenen OS-Applications fallen durch dafür erforderliche Kontextwechsel allerdings höhere Laufzeitkosten an. Um dem 05I Jahrgang

5 SWC Safe SWC Applikation Safe SWC SWC SWC Microsar RTE Watchdog Microsar OS SafeContext Microsar SYS Safe Watchdog Manager Microsar DIAG Microsar AMD XCP Microsar MEM Microsar CAN Microsar COM Microsar LIN Microsar FR Microsar IP Microsar MOST Microsar IO Complex Drivers Microsar CAL Microsar EXT Mikrocontroller Sicherheitsmechanismus Sicherheitsrelevante Funktion Nicht sicherheitsrelevante Funktion Autosar- Basissoftware 4 Autosar-Architektur mit Sicherheitsmechanismen entgegen zu steuern, kann alternativ eine sichere Koexistenz von Softwarekomponenten innerhalb der gleichen OS-Application angestrebt werden. Insbesondere für Basissoftware-Komponenten kann die Koexistenz eine Verbesserung der Performanz einbringen. Eine Methode zum Nachweis der Rückwirkungsfreiheit bezüglich Speicherzugriffe der Basissoftware durch einen Code- Checker ist in [3] dargestellt. Verfügbarkeit Vector Informatik bietet mit Microsar SafeContext als erster Hersteller ein bis zur höchsten Sicherheitsintegrität (ASIL D) zertifiziertes Autosar-Betriebssystem an, das die sichere Verwaltung von Kontexten und damit Speicherschutz für Mixed-ASIL-Systeme realisiert. Ergänzt wird das Betriebssystem durch die ebenfalls bis ASIL D zertifizierten Mechanismen SafeWatchdog und SafeCom der TTTech Automotive GmbH. Die sind für die Sicherstellung des korrekten zeitlichen Verhaltens beziehungsweise der korrekten Kommunikation von Software-Komponenten erforderlich. 4 zeigt eine Übersicht dieser Mechanismen in der Autosar-Architektur. Die einzelnen Mechanismen werden als Safety Elements out of Context (SEooC) 334 zur Verfügung gestellt. Für die Sicherheitsziele der SEooC wurden ausreichend allgemeine Annahmen getroffen und in Safety-Manuals detailliert spezifiziert. Ein Anwender kann somit die nach ISO vorgeschriebene Prüfung der Annahmen anhand seiner eigenen Anforderungen durch führen und die Mechanismen in sein Sicherheitskonzept integrieren. Von der Software-Architektur zum Code Wie im Abschnitt Technisches Sicherheitskonzept dargestellt, kann aus dem Werkzeug PREEvision für jedes Steuergerät die spezifische Autosar-ECU-Konfiguration generiert werden. Darauf basierend kann mit einem weiteren Werkzeug, wie dem DaVinci Configurator, eine konsistente und optimierte Konfiguration der Autosar-Basissoftware erstellt sowie der Programmcode der Autosar-RTE wie auch optional Vorlagen für das Implementieren der Software- Komponenten generiert werden. Das Eionbinden der Anwender-Software erfolgt schließlich in der üblichen Entwicklungsumgebung de Nutzers oder durch Integration von Code, der aus anderen Quellen stammt. Damit steht am Ende des Entwicklungsprozesses eine vollständige Implementierung der Steuergerätesoftware inklusive konfigurierter Autosar-Basissoftware und RTE zur Verfügung, die strikt und nachverfolgbar auf den eingangs bestimmten Risiken und Sicherheitszielen aufbaut. Fazit Eine durchgängigen Werkzeugumgebung zur Entwicklung von Autosar-konformer Steuergerätesoftware nach ISO ist einer nicht durchgängigen Werkzeugumgebung klar überlegen. Folglich werden sich auf Sicht der nächsten fünf Jahre durchgängige Werkzeugumgebungen in der Automobilindustrie deutlich mehr durchsetzen als das heute der Fall ist. Literaturhinweise [1] ISO 26262, Road vehicles Functional safety, Parts 1-9, 2011 und Part 10, 2012 [2] Lederer, D.; Ebert, C.: Funktionale Sicherheit Das Gesamtsystem Fahrzeug. In: Hanser automotive 10 (2008), S [3] Heling, G.; Rein, J.; Markl, P.: Koexistenz von sicherer und nicht-sicherer Software auf einem Steuergerät. In ATZelektronik 7, S7 (2012), S Download des Beitrags Read the english e-magazine order your test issue now: springervieweg-service@springer.com