Sichere Werkzeuge. Wie aus Bild 1 ersichtlich, wird schnell klar, für sichere Systeme! l ENGINEERING TOOLS

Transkript

1 34lA UTOMOTIVE l ENGINEERING TOOLS QUALIFIZIERUNG UND ZERTIFIZIERUNG VON SOFTWARE-ENTWICKLUNGSWERKZEUGEN Sichere Werkzeuge für sichere Systeme! Werkzeugunterstützte Entwicklung spielt in der funktionalen Sicherheit und IT-Sicherheit eine entscheidende Rolle, wird doch bei höheren Sicherheitsintegritätsstufen (SIL3) oder Evaluationsstufen (EAL3) die Anforderung hinsichtlich der Verwendung von Werkzeugen in den Phasen des Lebenszyklus in den einschlägigen Normen eindeutig adressiert. Korrektheit, Integrität und Verfügbarkeit der Werkzeuge sind daher die außerordentlichen Anforderungen an die Werkzeuge und eine Herausforderung für die Anwender. Wie aus Bild 1 ersichtlich, wird schnell klar, dass man nicht nur ein Werkzeug benötigt, sondern eine Werkzeugkette, ausgehend von der Anforderungsspezifikation bis zur Verifikation und Validierung. Die Werkzeuge sind aber nicht nur für die Erstellung der Software oder für die Nachweisführung der Korrektheit und Funktionalität von Bedeutung, sondern ebenso für das Projektmanagement, die Verwaltung der Versionen der Software aber auch für die Nachverfolgung der Anforderungen. Zu jeder Phase des Lebenszyklusses lassen sich somit Werkzeuge zuordnen, z. B. Spezifikationswerkzeuge, Generatoren für Quellcode, Compiler, Werkzeuge für die Verifikation, die Dokumentation und die Testdurchführung. Da man nicht von einem monolithischen Werkzeug ausgehen kann, besteht die Gefahr, wenn keine vertrauenswürdige Schnittstelle zwischen den Werkzeugen existiert, dass bei dem Austausch von Daten zwischen den Phasen und den Werkzeugen Verluste von Informationen auftreten können, die die Konsistenz und auch die Information über die Semantik und den Kontext des Systems gefährden können. Deshalb muss die Vertrauenswürdigkeit der Werkzeuge mindestens so hoch sein, wie es für die Entwicklung, Prüfung und Zertifizierung des sicherheitskritischen Systems erforderlich ist. Aber wie kann diese Vertrauenswürdigkeit gewonnen oder gezeigt werden? Mehr und mehr kommt die Anforderung für den Einsatz modellbasierte Softwareentwicklung für sicherheitskritische softwarebasierte Systeme. Modellbasierte Entwicklung bietet den Vorteil, dass viele Personen das System auf hohem Abstraktionsniveau diskutieren können, ohne Details über die konkrete Umsetzung in Hardware und/oder Software wissen zu müssen. Als Konsequenz benötigen wir ausreichend Vertrauen in die Korrektheit der Werkzeuge und deren Ergebnisse, wenn wir Werkzeuge zur Automatisierung von Abläufen in der Entwicklung sicherheitskritischer Systeme einsetzen wollen. Zudem besteht eine Lücke bezüglich des Beweisers. Wie können wir sicher sein, dass die Regelbasis

2 (Axiome, Theoreme etc.) korrekt ist und keine Tautologien oder fehlerhaften Axiome oder Theoreme enthalten sind. Somit haben Werkzeuge einen starken Einfluss auf die funktionale Sicherheit in allen Phasen des Lebenszyklusses. Werkzeuge lassen sich in folgende Gebiete kategorisieren: Verifikationswerkzeuge wie Codechecker (z. B. Lint) oder statische Verifikation (z. B. Polyspace), sondern es kommen auch dynamische Tests und Simulation zum Einsatz. Doch wie kann in der Kette der Werkzeuge sichergestellt werden, dass wir auf deren Ergebnisse vertrauen können, die Semantik erhalten geblieben ist und die Ausführung des sicherheitskritischen Systems in Echtzeit in den erforderlichen Zeitschranken verläuft? Wie können wir bei automatisch generierter Dokumentation sicherstellen, dass das implementierte System mit der Dokumentation übereinstimmt? Bild 1: Sicherheitsintegrität in Software und der Lebenszyklus in der Entwicklung (IEC , siehe Bild 2). Nachfolgend werden die normativen Anforderungen disku- tiert und verschiedene Ansätze für die Validierung, Zertifizierung und Qualifizierung von Werkzeugen aufgezeigt und abschließend eine Zusammenfassung der Ergebnisse gegeben. Dokumentation, Modellierung/Spezifikation, Generierung, Compilierung, Verifikation, Validation/Test und Management Zunehmend finden Werkzeuge zur Automatisierung der Verifikations- und Validierungstätigkeiten großes Interesse, da im Bereich der funktionalen Sicherheit ein hoher Aufwand für die Nachweisführung der funktionalen Sicherheit erforderlich ist. So beschränken sich die Werkzeuge nicht nur auf statische INNOVATIONEN VON TOSHIBA TRAGEN ZU IMMER SCHNELLEREM FORTSCHRITT IN DER KFZ-TECHNIK BEI. ENGINEERING TOOLSl AUTOMOTIVE Die Entwicklung in der Kfz-Elektronik schreitet immer schneller voran - und auch Toshiba leistet dazu einen wichtigen Beitrag. Unsere Bauteile reduzieren den Stromverbrauch, senken Energiekosten, erhöhen die Sicherheit - und minimieren die Umweltbelastung. Unsere Grafik-Controller aus der Capricorn-Reihe und unsere modernen TFT-Displays ermöglichen zum Beispiel eine flexible Aufteilung der Anzeigefläche auf dem Display zur Hervorhebung der Informationen, die für den Fahrer in der jeweiligen Fahrsituation relevant sind, und erhöhen damit die Fahrsicherheit. Unsere LEDs und LED-Treiber-ICs verbessern die Energieeffizienz des Fahrlichts. Und wir entwickeln ständig neue ICs - wie z.b. MP3-Decoder und Audio-Verstärker, die zu einer entspannten Reise beitragen. Weil wir auf unserer Reise zur Innovation das Reiseerlebnis auch für andere verbessern wollen. Besuchen Sie uns noch heute auf l35 Normative Anforderungen Alle relevanten internationalen Standards, die Anforderungen an die Softwareentwicklung für sicherheitsgerichtete Systeme beinhalten, stellen Anforderungen an das Vertrauensniveau für Softwareentwicklungswerkzeuge. Bild 2 gibt eine Übersicht über diese Normen. Die internationale generische Norm zur Funktionalen Sicherheit ist die IEC In Teil 3 dieses Standards werden die Anforderungen an die Software sicherheitsgerichteter Systeme adressiert. Darüberhinaus gibt es zahlreiche applikationsspezifische Normen für die Bereiche Medizinprodukte, Sicherheit von Maschinen, Gasmesstechnik, Bahn- und Automobilanwendungen, die von der IEC abgeleitet wurden und zum Teil deren Anforderungen präzisieren. Der Vollständigkeit halber sind in der Übersicht die ISO/IEC (Soft-

3 36lA UTOMOTIVE l ENGINEERING TOOLS ware-lebenszyklus) sowie die ISO/IEC (SPICE) enthalten. Diese Normen beinhalten zwar keine spezifischen Anforderungen für sicherheitsgerichtete Systeme bzw. deren Entwicklungsprozesse, sind aber auch im Safety- Umfeld Stand der Technik und bilden häufig die Basis für die Implementierung von geeigneten Prozessen. Im Folgenden werden die Anforderungen an Softwarewerkzeuge in den Normen IEC und ISO DIS analysiert, da diese Normen im Automobilumfeld ihre Anwendung finden. IEC und ISO Nach IEC wird die Verwendung von betriebsbewährten oder zertifizierten Werkzeugen im Grunde unabhängig von der Risikobewertung des Zielsystems gefordert. Dieser Nachweis ist prinzipiell für jedes verwendete Softwarewerkzeug zu erbringen. Grundsätzlich ist es für den Werkzeuganwender schwierig, den Nachweis der Betriebsbewährtheit zu erbringen, da ein einzelner Anwender im Regelfall nicht über die notwendige Fülle an Betriebserfahrungen mit einer speziellen Version in unterschiedlichem Kontext verfügt. Die Zertifizierung eines Werkzeuges ist in den meisten Fällen nur auf Initiative des Werkzeugherstellers selbst sinnvoll, da nur dieser in der Regel über das entsprechende interne Know-how verfügt. Im Moment gibt es erhebliche Schwierigkeiten diesen Passus der Norm in vollem Umfang zu erfüllen, da nur sehr wenige zertifizierte Werkzeuge am Markt verfügbar sind. Momentan befindet sich die IEC in Überarbeitung. Die IEC Ed.2 wird die Anforderungen an die Softwareentwicklungswerkzeuge präzisieren und vor allem eine Differenzierung der Werkzeuge bzgl. Ihrer Kritikalität für das Zielsystem und der Verifikationsmaßnahmen im Projekt, ähnlich der ISO 26262, beinhalten. Nachdem frühere Entwürfe der ISO eine pauschale Klassifizierung der Softwarewerkzeuge in Entwicklungswerkzeuge, Testwerkzeuge und Begleitwerkzeuge (ähnlich Bild 2: Überblick über (Software-) Normen für sicherheitsgerichtete Systeme. der DO 178B) vorgesehen und mit Anforderungen an die Werkzeugqualifizierung verbunden haben, sind nach ISO DIS alle eingesetzten Werkzeuge projektspezifisch zu bewerten und ggf. zu qualifizieren. Bild 3 zeigt die Bestimmung des Vertrauensgrades eines Werkzeuges (Tool Confidence Level, TCL). Der TCL ermittelt sich aus den Größen Tool Impact (TI) und Tool Error Detection (TD). TI=1 bedeutet, dass ein Werkzeugfehler den Werkzeug-Output sicherheitsrelevant verfälschen kann. TD=1 bedeutet, dass diese Fehler mit hoher Wahrscheinlichkeit durch Verifikationsmaßnahmen aufgedeckt werden können. TD=4 bedeutet nur eine zufällige Aufdeckungswahrscheinlichkeit. Aus einem TCL=1 resultieren keine Anforderungen an Qualifizierungsmaßnahmen (wie Betriebsbewährtheit, Validierung, Bewertung des Entwicklungsprozesses oder Entwicklung nach einem Sicherheitsstandard). Für alle anderen TCLs sind Qualifizierungsmaßnahmen in Abhängigkeit der Risikoeinstufung des Zielsystems vorzunehmen. Ansätze für Qualifizierung und Zertifizierung von Werkzeugen Prinzipiell gibt es verschiedene Qualifizierungsansätze die Vertrauenswürdigkeit von Softwarewerkzeugen nachzuweisen: Fitness for Purpose Entwicklung des Werkzeuges nach einem Sicherheitsstandard (z.b. IEC und 3, DO 178B) Formale Verifikation Verwendung diversitärer Werkzeuge ( N-out-of-M- Architektur) Wird ein Qualifizierungsansatz projektübergreifend und anwenderunabhängig durchgeführt, ist eine Zertifizierung des Werkzeuges durch den TÜV Süd prinzipiell möglich. Die Entwicklung eines Softwarewerkzeuges nach einem Sicherheitsstandard ist in der Regel sehr aufwendig. Die-

4 ses Vorgehen wird beispielsweise im Luftfahrtbereich angewendet (z. B. Esterel SCADE KCG). Formale Verifikation von Werkzeugen, also ein mathematischer Beweis, wird im Security-Umfeld genutzt. Für den Automobilbereich sind bereits Werkzeuge mit einer Fitness for Purpose -Zertifizierung verfügbar (z. B. Dspace TargetLink und Mathworks embedded coder). Ein weiterer vielversprechender Ansatz ist die MooN -Architektur der Werkzeugkette. Deshalb werden die beiden letztgenannten Methoden im Folgenden im Detail betrachtet. Fitness for Purpose Fitness for Purpose bedeutet, dass ein entsprechend zertifiziertes Softwarewerkzeug prinzipiell unter definierten Rahmenbedingungen, den sogenannten conditions of use, für den Einsatz bei der Entwicklung von sicherheitsgerichteten Systemen geeignet ist. Ziel einer solchen Zertifizierung ist es, den Werkzeuganwendern einen generischen und projektunabhängigen Eignungsnachweis zur Verfügung zu stellen. Die Fitness for Purpose -Zertifizierung wird von einem unabhängigen Prüfinstitut im Auftrag des Werkzeugherstellers durchgeführt. Die Kriterien für eine solche Zertifizierung setzen sich aus folgenden Aspekten zusammen: Entwicklungsprozess inkl. Modifikationsprozess: Der Prozess sollte in Anlehnung an einen geeigneten Softwareentwicklungsprozess-Standard definiert werden. Produktvalidierung: Das Produkt muss hinreichend getestet sein. Dies kann z. B. durch Definition einer angemessenen Validierungssuite erfolgen. Prozess für geeignetes Fehlermeldewesen (bug reporting, bug tracking) und Umgang mit gemeldeten Werkzeugfehlern (customer information), Referenzworkflow: Bei komplexen Werkzeugen wie z. B. Codegeneratoren ist es sinnvoll, dem Anwender eine Verwendungsempfehlung zur Verfügung zu stellen. Dieser Referenzworkflow ist dann Bestandteil der Zertifizierung und definiert u. a. eine geeignete Teststrategie des Werkzeug-Outputs. Die Gewichtung dieser Kriterien im Zertifizierungsprozess ist produktabhängig. ENGINEERING TOOLSl AUTOMOTIVE l37 Bild 3: Bestimmung des Vertrauensgrades eines Werkzeuges nach ISO DIS N-out-of-M-Architektur Neben den bereits dargestellten Strategien der Toolqualifizierung gibt es alternativ den Ansatz einer N-out-of-M Architektur. In Bild 4 ist dieser Ansatz mit einer triple modular redundancy (TMR) Struktur, also einer 2oo3-Architektur dargestellt. Dabei wird die Multiversionen-Technik des N- Version-Programming genutzt, wobei alle realisierten Kanäle (Versionen) diversitär entwickelt werden, um die gleichen grundlegenden Anforderungen zu erfüllen. Eine Beherrschung zufälliger Fehler und eine Reduktion verbleibender systematischer Fehler wird dabei möglich. Die Korrektheitsentscheidung wird durch Mehrheitsentscheid aller beteiligter Kanäle mit einem Voter getroffen. Der Ansatz kann zusätzlich mit Softwareredundanz, Informationsredundanz und Zeitredundanz kombiniert werden. Die Diversität in den verwendeten Tools, Modellierungssprachen, Programmiersprachen und Entwicklungswerkzeugen im gesamten Entwicklungsprozess ist das Hauptargument für ein Erkennen der systematischen und zufälligen Fehler in der NooM-Architektur: In diversitär entwickelten Kanälen wird das Vorliegen gleicher systematischer Fehler (common cause failure) als weniger wahrscheinlich als das Vorliegen unterschiedlicher systematischer Fehler angesehen (N-Versionen-Annahme). Damit kann der Aufwand für Toolqualifizierung reduziert werden. Die diversitären Kanäle können als Referenzimplementierung des Back To Back Testing-Ansatzes interpretiert werden. Neue fehlertolerante Architekturen mit diversitär-codierten Kanälen wie zum Beispiel Safely Embedded Software (SES) [4, 5, 6] des LaS3 nutzen Komparatoren anstelle Voter für Fehlerkennung des Targetsystems. Moderne Multi-Core Controller Architekturen ermöglichen die Verteilung der verschiedenen diversitären Kanäle der NooM-Architektur auf die verschiedenen Verarbeitungseinheiten (Cores). Eine Variante des diskutierten Architekturansatzes nutzt die Diversität der verschiedenen Kanäle nur während der Verifikations- und Validations-Phase im Lebenszyklus des sicherheitskritischen Systems. Dabei können die Kanäle aus Simulation(en) und dem Targetsystem gebildet werden: SW-IL

5 38lA UTOMOTIVE l ENGINEERING TOOLS Bild 4: Die Triple Modular Redundancy (TMR) Struktur wird hier nach der Multiversionen-Technik (N-Version Programming) entwickelt. Dabei verfolgt der erste Ansatz die TMR-Nutzung zur Verifikation und Validation. Der zweite Ansatz hat auch auf dem Target eine TMR-Architektur. In beiden Fällen wird ein 2oo3-Voting realisiert. (Software in the Loop) oder HIL (Hardware in the Loop). Das Targetsystem wird gegen diversitäre Simulationen getestet, wobei das simulierte System auf Basis diversitärer Spezifikationen, diversitärer Modelle, diversitärer Entwicklungsteams und diversitärer Entwicklungswerkzeuge erstellt werden kann. Problematisch kann in dieser Variante das Zeitverhalten der Simulation werden, da sich die Antwortzeiten der Simulation vom Targetsystem unterscheiden können. Wissen über nebenläufige Tasks, Multi-Tasking und ereignisbasierte Kommunikation auf dem Targetsystem wird zur Bewertung der Verifikation und Validation nötig. Die N-Versionen-Annahme wurde von Leveson 1990 [7] kritisch gewürdigt. Das Forschungsprojekt DynaS3 untersucht die N-Versionen-Annahme im Kontext heutiger Entwicklungsprozesse. Ausblick Internationale Normen wie die IEC 61508, ISO/IEC (SPICE) und ISO/IEC definieren erste Anforderungen an die Qualifikation und Zertifizierung von Werkzeugen. Domänenspezifische Standards wie die ISO DIS geben leicht unterschiedliche Argumentationen bezüglich der Qualifizierung von Werkzeugen. Wenn wir dies berücksichtigen, dann ist es möglich, Strategien für die Qualifizierung und Zertifizierung von Werkzeugen zusammenzufassen: Zertifizierung des Entwicklungs- und Implementierungsprozesses des Werkzeuges z. B. nach IEC/DIN Teil 1 und 3 Formale Verifikation: Nachweis der Richtigkeit des Software-Werkzeuges unter Verwendung mathematischer Beweisverfahren Fitness for Purpose -Zertifizierung: Werkzeug ist fit for intended purpose Bewertung des SW-Entwicklungsprozesses für die Werkzeugentwicklung (in Anlehnung an einen Sicherheitsstandard) Bewertung des Bug-Tracking- und Chance-Prozesses Geeigneter Referenzworkflow für die Projektebene Die N-out-of-M-Architektur wird mit diversitären Entwicklungswerkzeugen entwickelt. Damit wird auf der einen Seite eine Reduktion der Qualifizierung- und Zertifizierungsaufwände für die Werkzeuge möglich, auf der anderen Seite erfordert die komplexere N-out-of-M-Architektur selbst höhere Zertifizierungsaufwände im Rahmen eines Safety-Assessments. (oe) Literatur [1] A. Bärwald, H. Hauff, J. Mottok, Qualification and Certification of Development Tools for Safety-Critical Applications, Tagungsband dependability@siemens 2009

6 [2] A. Bärwald, M. Beine, Sichere Codegenerierung, Hanser Automotive 1/2010 [3] H. Hauff, Erfüllung von funktionalen und nichtfunktionalen Anforderungen in eingebetteten Systemen durch modellbasierte Software-Entwicklung, Tagungsband Workshop Entwicklung zuverlässiger Software-Systeme am 18. Juni 2009 in Regensburg [4] J. Mottok, F. Schiller, F., T. Völkl, T. Zeitler, A Concept for a Safe Realization of a State Machine in Embedded Automotive Applications, Computer Safety, Reliability, and Security 26th International Conference, SAFECOMP 2007, Proceedings, LNCS 4680, Springer-Verlag GmbH; S ,ISBN [5] J. Mottok, MISRA C++:2008 and Safely Embedded Software A Safety Framework for C++, Automotive Safety & Security, Stuttgart, 2008 [6] M. Steindl, J. Mottok, H. Meier, F. Schiller, M. Fruechtl, Migration of SES to FPGA Based Architectural Concepts, Softwaretechnik Trends, Gesellschaft für Informatik, 2009 [7] S. S. Brilliant, J. C. Knight, N.Leveson, Analysis of Faults in an N-Version Software Experiment, IEEE Transaction on Software Engineering, Vol.16, No.2, February 1990 MERAN für IBM Rational DOORS Berner & Mattner Systemtechnik hat mit MERAN ein neues Werkzeug als Erweiterung zu IBM Rational DOORS im Angebot. Die Kombination einer modellbasierten Anforderungsanalyse mit ENGINEERING TOOLSl AUTOMOTIVE einem leistungsfähigen Variantenmanagement für Anforderungsspezifikationen erleichtert die Beherrschung der Produktvielfalt in der Analyse- und Spezifikationsphase. Der Einsatz von MERAN minimiert damit deutlich das Risiko von kostenintensiven Analyse- und Spezifikationsfehlern in der Systementwicklung mit mehreren Varianten. Weitere Qualitäts- und Effizienzsteigerungen können durch die optionale modellbasierte Spezifikationsmethode erzielt werden. Die Werkzeugkombination setzt bereits in den frühen Analyse- und Spezifikationsphasen des Entwicklungsprozesses von Fahrzeugfunktionen l39 Harald Hauff ist seit 2007 an der Universität Passau als wissenschaftlicher Mitarbeiter tätig, außerdem führt er seit 2007 das eigene Ingenieurbüro EDOH in der Nähe von München. Herr Hauff ist als ehemaliger Mitarbeiter des Bundesamtes für Sicherheit in der Informationstechnik (BSI) und des TÜV SÜD Automotive GmbH Experte im Bereich der IT-Sicherheit und funktionalen Sicherheit. Andreas Bärwald ist Gruppenleiter Funktionale Sicherheit Software und Halbleiter im Safety-Competence Center Elektronik Sicherheit der TÜV SÜD Automotive GmbH in München. andreas.baerwald@tuev-sued.de Prof. Dr. Jürgen Mottok lehrt Informatik an der Hochschule Regensburg. Seine Lehrgebiete sind Software Engineering, Programmiersprachen, Betriebssysteme und Functional Safety. juergen.mottok@e-technik.fh-regensburg.de TÜV Süd an. Die Übertragbarkeit von Änderungen über ganze Produktfamilien sowie die automatische Anpassung an produktspezifische Fahrzeugvarianten werden maßgeblich erleichtert. Die angebotene Kombination aus modellbasierter Anforderungsanalyse und leistungsfähigem Variantenmanagement eröffnet erhebliche Nutzen- und Kosteneinsparpotenziale bei der Erstellung, Aktualisierung und Analyse von funktionalen Anforderungsspezifikationen. Berner &