1 / 18

Modellbasierte Software-Entwicklung eingebetteter Systeme

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

blaine
Download Presentation

Modellbasierte Software-Entwicklung eingebetteter Systeme

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. A A B C A Parallel Seriell Was soll man duplizieren? Ventilausfall auf: Wasser fliesst ab Ventilausfall zu: Ablauf blockiert sicher gegen einzelnen Ausfall

  6. 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

  7. Verallgemeinerung

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

  9. 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)

  10. 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)

  11. 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

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

  13. Fehlerakkumulation

  14. Beispiele • Inertialnavigation • 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

More Related