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 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme Spam-Mail von gestern
Folie 3 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme 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 4 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme RAMS(S) Dependability Verlässlichkeit Availability Verfügbarkeit Reliability Zuverlässigkeit Safety Sicherheit Mean Time to Failure (MTTF) Mittlere Laufzeit vor Ausfall Mean Time To Repair (MTTR) Risikobehandlung: erkennen, eliminieren, reduzieren, Folgen minimieren Maintainability Wartbarkeit Instandhaltbarkeit Security Sicherheit
Folie 5 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme Verfügbarkeit (Availability) Maß für die durchschnittliche Erbringung der Funktionalität Kenngrößen MTTF = Mean Time to Failure MTTR = Mean Time To Repair Availability = MTTF / (MTTF + MTTR) Verfügbarkeit und Sicherheit sind oft gegensätzliche Ziele! Ein Auto, das niemals fährt, ist sicher: es geht keine Gefahr von ihm aus, es ist aber nicht brauchbar Ein Auto, das immer fahren kann, auch wenn es auseinanderfällt, hat die höchste Verfügbarkeit, ist aber nicht sicher
Folie 6 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme Maintainability Reparatur nach Ausfall Entwicklung von Konzepten zur Optimierung von Instandsetzungsprozessen unter Berücksichtigung der Wartungstiefe, Zeit, Kosten und Ressourcen Vorausschauende Wartung Entwicklung von vorbeugenden und planbaren Instandhaltungsmaßnahmen, z.B. durch Austausch von Verschleißteilen, um eine möglichst hohe technische Zuverlässigkeit und Verfügbarkeit zu erreichen Die Instandhaltbarkeitsanalyse setzt auf den Ergebnissen der Zuverlässigkeitsanalysen (FMEA, FMECA) auf und berücksichtigt diagnosespezifische Aussagen DIN 31051, 06/2003 – Grundlagen der Instandhaltung EN 13306, 09/2001 – Begriffe der Instandhaltung MIL-STD 470 – Maintainability Engineering
Folie 7 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme Safety (Betriebssicherheit) Freiheit von unvertretbaren Risiken (IEC61508) keine Gefährdung von Leib und Leben oder der Umwelt ISO 8402: Sicherheit = Zustand, in dem das Risiko eines Personen- oder Sachschadens auf einen annehmbaren Wert begrenzt ist - was heißt „annehmbar“ ? Ein System heißt sicherheitskritisch, wenn es beim Ausfall großen Schaden verursachen kann funktionale Sicherheit korrekte Funktion der sicherheitsbezogenen (Sub-) Systeme und externer Einrichtungen zur Risikominderung (im Gegensatz zu z.B. Brandschutz) sicherer Zustand: keine Gefährdung durch das Gerät (aber ggf. auch keine Funktion; fail-safe, fail-stop)
Folie 8 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme Security (Angriffssicherheit) Schutz gegen böswillig verursachte Fehler bzw. Ausfälle Wiki: Während „Safety“ den Schutz der Umgebung vor einem Objekt, also eine Art Isolation beschreibt, handelt es sich bei „Security“ um den Schutz des Objektes vor der Umgebung (?) Informationssicherheit Vertraulichkeit Datenintegrität Authentizität, Zurechenbarkeit, Nichtabstreitbarkeit, Nachweisbarkeit z.B. Trojaner im Auto durch CD-Spieler eingeschleust kann CAN-Nachrichten absetzen
Folie 9 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme Ausfallrate Ausfallrate: Wahrscheinlichkeit, dass sich ein Ausfall pro Zeiteinheit in einem Intervall [t,t+ ] ereignet, gegeben Ausfallfreiheit bis zu t F(t+ )-F(t) / *R(t) Häufigkeit, mit der sich Ausfälle in einem Intervall ereignen Hazard-Rate: bedingte Ausfalldichte z(t) = f(t) / R(t) Grenzwert der Ausfallrate für kleine Intervalle Steuerung mit Control Loop: Wahrscheinlichkeit mindestens eines Versagens in n Läufen: 1-(1-p) n p: Wahrscheinlichkeit des Versagens in einem Programmlauf (1-p): Wahrscheinlichkeit des Nichtversagens (1-p) n : Wahrscheinlichkeit des Nichtversagens in n paarweise unabhängigen Läufen
Folie 10 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme Techniken Erhöhung der Zuverlässigkeit durch Redundanz identische Replikation oder diversitäre Entwicklung statische oder dynamische Redundanz Statische Redundanz - Alle Ressourcen ständig im Betrieb - Im Fehlerfall direktes Umschalten Dynamische Redundanz - Stand-by, Aktivierung erst im Fehlerfall - Ggf. Fremdnutzung der Ressource (kritisch!)
Folie 11 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme Fehlerarten SW-Fehler: diversitäre Entwicklung (teuer!) HW-Fehler, z.B. Speicher, Leitungen, Prozessoren… Byzantinische und nichtbyzantinische Fehler Fail-Operational, Fail-Soft, Fail-Stop
Folie 12 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme ACB Seriell A Parallel Was soll man duplizieren? Ventilausfall auf: Wasser fliesst ab Ventilausfall zu: Ablauf blockiert sicher gegen einzelnen Ausfall
Folie 13 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
Folie 14 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
Folie 15 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme Triple Modular Redundancy (TMR) Unabhängiges Voting Externe Komponente oder logisch getrennt Software-Voting: getrennte Speicher, geschütztes Betriebssystem 2-aus-3 Mehrheitsentscheid single fault fail operational, double fault fail silent (erster Ausfall kann toleriert, zweiter erkannt werden) bei 4-fach Replikation können byzantinische Fehler behoben werden
Folie 16 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme Verallgemeinerung
Folie 17 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
Folie 18 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme Dynamische Redundanz Vorteile geringerer Ressourcenverbrauch Möglichkeit der Nutzung der Reserven Nachteile Verzögerung beim Umschalten Standby-Komponenten
Folie 19 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme Aufgaben der FT-Komponenten Fehlerdiagnose (Selbstdiagnose / Fremddiagnose) Ist ein Fehler aufgetreten? Welche Komponente ist fehlerhaft? Protokollierung Rekonfiguration Erbringung der Funktion mit den intakten Komponenten Umschalten bzw. Ausgliedern / Neustarten Recovery Reparatur bzw. Wiedereingliedern Rückwärts (Rollback, Recovery Points) Vorwärts (Wiederaufsatzpunkte)
Folie 20 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme Stand der Praxis Sensorik, Aktuatorik z.B. Lenkwinkelgeber (Bosch), Bremsmotoren Verkabelung, Bussysteme z.B. TTP/C, FlexRay Controller, Hardware redundante integrierte modulare Controller (IMCs) Zukunftsmusik: fehlertolerante Prozessoren, SoC Software diversitäre Entwicklungen bislang nur für wenige Systeme bekannt (Fly-by-wire)
Folie 21 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme fehlertolerante Mehrprozessorarchitekturen Lock-step versus loosely-synchronized Lock-step effizienter, loosely-synchronized sicherer Sicherung der Datenintegrität mittels CRC-Speicher Prototypen verfügbar, Serie nicht in Sicht Quelle: Baleani, Ferrari, Mangeruca, SangiovanniVincentell, Peri, Pezzini
Folie 22 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme Fehlerakkumulation
Folie 23 H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme