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

Maßnahmen nach IEC61508 Control of random hardware failures electric: monitoring of relay contacts, idle current principle, ... electronic: redundant HW, automatic checks, ... processing units: self-tests, dynamic comparison memory: multi-bit redundancy, checksums, ... ... Avoidance of systematic failures project management: organisational model, regulations and measures, ... separation, diverse HW, ... structured specifications, formal methods, ... Techniques and measures for achieving software safety integrity

Techniken für Zuverlässigkeit 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!)

Fehlerarten SW-Fehler: diversitäre Entwicklung (teuer!) HW-Fehler, z.B. Speicher, Leitungen, Prozessoren… Byzantinische und nichtbyzantinische Fehler Fail-Operational, Fail-Soft, Fail-Stop

Was soll man duplizieren? C A A Parallel A B Seriell Ventilausfall auf: Wasser fliesst ab Ventilausfall zu: Ablauf blockiert sicher gegen einzelnen Ausfall

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

Verallgemeinerung

Dynamische Redundanz Vorteile Nachteile geringerer Ressourcenverbrauch Möglichkeit der Nutzung der Reserven Nachteile Verzögerung beim Umschalten Standby-Komponenten

Aufgaben der FT-Komponenten Fehlerdiagnose (Selbstdiagnose / Fremddiagnose) Ist ein Fehler aufgetreten?  Fehlermodell! 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)

Stand der Praxis Sensorik, Aktuatorik Verkabelung, Bussysteme 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)

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

Fehlertolerante System-on-chip Eine CPU rechnet, die andere überwacht (selbstprüfendes Paar) Synchronisation? Problem Abfangen von „äußeren“ Fehlern Common-cause-Fehler (z.B. thermisch) Trend Network-on-Chip Selbstorganisation, sanfte Degradierung

Fehlerakkumulation

Beispiele Inertialnavigation Patriot vs. Scud (Raketen-Abfangsystem) Sensordrift muss mittels GPS korrigiert werden Patriot vs. Scud (Raketen-Abfangsystem) Desert Storm, 25.2.1991 20% targeting inaccuracy after continuous operation for 8 hours Army officials presumed that Patriot users were not running the systems for longer than 8 hours at a time Alpha battery had been in continuous operation for over 100 consecutive hours, and the resulting inaccuracy resulting from the software bug was roughly 0.34 seconds fix: do a more accurate integer to real conversion of the time value http://sydney.edu.au/engineering/it/~alum/patriot_bug.html