Modellbasierte Software-Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für offene Kommunikationssysteme FOKUS

Wiederholung in Fragen? Was versteht man unter SIL? Wie bestimmt man SIL eines Systems? Unterschied SIL – ASIL? Wofür steht 61508? Was ist Risiko? Wie funktioniert Risikobegrenzung? Beispiele für Maßnahmen?

DO-178 C (2011-12) Luftfahrt-Standard vergleichbar zu EN 50128 “Software Considerations in Airborne Systems and Equipment Certification” Design Assurance Level (DAL) A – E A – Catastrophic, B – Hazardous, C – Major, D – Minor, E - No Safety Effect (Achtung: A ist höchste Sicherheitsstufe) Inhalt Software Life Cycle Software Planning Processes Software Development Processes Software Verification Processes Configuration Management, Quality Assurance, Certification Beispiele auf P12, P13

Supplemente DO-330 Software Tool Qualification Considerations DO-331 Model-Based Development and Verification DO-332 Object-Oriented Technology DO-333 Formal Methods DO-331 ist die erste Norm, die den Gebrauch modellbasierter Entwicklungsmethoden explizit erlaubt und reglementiert (vorher: Spezialfall allgemeiner Entwicklungsmethodik) Aussagen zur Codegenerierung, Coverage, Verifikation usw.

DO-331 Definition Modell: “abstrakte Repräsentation einer Menge von Softwareaspekten, die verwendet wird um den Software-Entwicklungs- oder –verifikationsprozess zu unterstützen” graphische oder textuelle Modellierungsnotation enthält Anforderungen an die Software direkt für Analyse und Auswertung verwendbar Verwndung von Modellen im Entwicklungszyklus Formalisierung von Anforderungen Codegenerierung, Testgenerierung Analyse, Simulation und (partielle) Verifikation Aufbau gemäß DO 178 C Änderung falls durch modellbasierte Entwicklung erforderlich

Spezifikations- und Designmodelle Spezifikationsmodell Formalisierung abstrakter Anforderungen, eindeutige Beschreibung der Software-Funktionalität, keine Implementierungsdetails Designmodell Beschreibung von internen Datenstrukturen, Daten- und Kontrollfluss; Spezifikation von Architektur und Implementierung Ein Modell kann nicht gleichzeitig Spezifikations- und Designmodell sein jedes Modell muss als Spezifikations- oder Designmodell gekennzeichnet werden Auswirkungen auf Verwendung und Modellvalidierung “it may be difficult to separate system and software life cycle data”

Beispiel für DO-331 Anforderungen Erforderliche Informationen im Lebenszyklus Systemanforderungen Sicherheitsanforderungen ... (8 Punkte) Zusätzlich erforderliche Daten für Modelle Verlinkung zu Anforderungen Modell-Konfigurationsmöglichkeiten Modellierungssprachenbeschreibung Modellelementbibliothek Modellschnittstellenbeschreibung Modellentwicklungsumgebungsbeschreibung Systemverfikationsdaten zur Modellvalidierung

Simulationsumgebung muss ggf. qualifiziert werden Analyse der Fähigkeiten und Grenzen welche Fehler können bzw. können nicht gefunden werden welche Teile tragen bei bzw. sind nur informativ Kennzeichnung der Realisierung von Anforderungen im Modell Bi-direktionale Traceability Konformität zu Modellierungsstandards Simulation zum Nachweis der Vollständigkeit und Korrektheit der Anforderungen erlaubt “Verifikationsfälle” statt “Testfälle” Nachweis der Übereinstimmung von Anforderungen und Modell

Modellüberdeckungsanalyse

Simulation und Test Modellsimulation ergänzt den Test aber: ersetzt nicht Test und strukturelle Codeüberdeckung! “partially satisfy ... testing objectives”, z.B. Robustheit, High-Level-Anforderungen, Softwarestruktur Simulation statt Test von generiertem Code Unterschied Simulations- und Zielplattform muss dargestellt werden Nachweis, dass Fehler bereits im Modell gefunden werden zusätzliche Test auf der Zielplattform sind immer erforderlich

Kap. 6.2 Fehlertoleranz Thanks for the pictures: © Prof. Sergio Montenegro, U Würzburg

Redundanz und Fehlertoleranz Redundanz: Das Vorhandensein mehrerer Möglichkeiten, um eine gegebene Funktion zu erbringen Strukturelle Redundanz Vervielfältigung von Komponenten baugleich oder alternative Entwürfe (Replikation / Diversität) Zeitliche Redundanz Zusätzliche Zeit für wiederholte Ausführungen (Retry) Funktionale Redundanz zusätzliche, unterstützende Komponenten Test, Konfiguration, Sensoren Informationsredundanz Zusätzliche Informationen Prüfbits, zusätzliche Zeiger, Zähler

Fehlertoleranz Fehlertoleranz: Die Fähigkeit eines Systems, trotz aufgetretener Fehler die vorgesehene Funktion zu erbringen Ziel: Verringerung der Ausfallwahrscheinlichkeit durch Redundanz Komponentenausfälle müssen unabhängige Ereignisse sein („single faults“) Einzelne Komponente hat Ausfallwahrscheinlichkeit p; Gesamtausfallwahrscheinlichkeit? Notwendiger Replikationsgrad für geforderte Verfügbarkeit?

Warum Fehlertoleranz? Steuerungscomputer Aktuatoren Sensoren Technischer Prozeß

FT-Kenngrößen Zuverlässigkeit (reliability) Grad der Fähigkeit einer Betrachtungseinheit, die geforderte Leistung während einer vorgegebenen Zeitspanne zu erbringen Wahrscheinlichkeit der Abwesenheit von Ausfällen über dem Beobachtungszeitraum gleichzusetzen mit Überlebenswahrscheinlichkeit R(t)=Wahrscheinlichkeit, dass das System im Zeitraum [0,t] fehlerfrei ist; oft R(t)=e-t Ausfallwahrscheinlichkeit F(t) = Wahrscheinlichkeit (mindestens) eines Ausfalls im Beobachtungszeitraum; F(t) = 1 - R(t) Verfügbarkeit (availability) Maß für die Wahrscheinlichkeit, dass die geforderte Leistung zu einem Zeitpunkt erbracht werden kann A(t) = Wahrscheinlichkeit, dass das System zum Zeitpunkt t intakt ist (MTBF / (MTBF+MTTR)) Verlässlichkeit (dependability) Maß für das gerechtfertigte Vertrauen in die Leistung eines Systems

RAMS(S) Dependability Mean Time to Failure (MTTF) Verlässlichkeit Mittlere Laufzeit vor Ausfall Reliability Zuverlässigkeit Availability Verfügbarkeit Mean Time To Repair (MTTR) Maintainability Wartbarkeit Instandhaltbarkeit Safety Sicherheit Risikobehandlung: erkennen, eliminieren, reduzieren, Folgen minimieren Security Sicherheit