Modellbasierte Software-Entwicklung eingebetteter Systeme

Präsentation zum Thema: "Modellbasierte Software-Entwicklung eingebetteter Systeme"—  Präsentation transkript:

1 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

2 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

3 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!)

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

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

6

7

8 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

9 Verallgemeinerung

10

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

12 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)

13 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)

14 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

15 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

16 Fehlerakkumulation

17

18 Beispiele Inertialnavigation Patriot vs. Scud (Raketen-Abfangsystem)
Sensordrift muss mittels GPS korrigiert werden Patriot vs. Scud (Raketen-Abfangsystem) Desert Storm, 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