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
Folie 2 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?
Folie 3 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
Folie 4 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.
Folie 5 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
Folie 6 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
Folie 7 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
Folie 8 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
Folie 9 Modellüberdeckungsanalyse
Folie 10 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
Folie 11 Kap. 6.2 Fehlertoleranz Thanks for the pictures: Prof. Sergio Montenegro, U Würzburg
Folie 12 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
Folie 13 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?
Folie 14 Warum Fehlertoleranz? Steuerungscomputer Aktuatoren Sensoren Technischer Prozeß
Folie 15
Folie 16 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
Folie 17 RAMS(S) Dependability Verlässlichkeit Mean Time to Failure (MTTF) Mittlere Laufzeit vor Ausfall Reliability Zuverlässigkeit Availability Verfügbarkeit Mean Time To Repair (MTTR) Maintainability Wartbarkeit Instandhaltbarkeit Safety Sicherheit Security Sicherheit Risikobehandlung: erkennen, eliminieren, reduzieren, Folgen minimieren