Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik 9.12.2005

Übersicht 1. Eingebettete Systeme Hinweise 1.1. Definitionen 1.2. Anforderungsanalyse 1.3. Modellierung 1.4. Architektur Hard- und Software-Aufbau Fehlertoleranz Echtzeitbetriebssysteme, Scheduling? Hardware/Software Codesign? Produktlinienentwicklung? 1.5. Automotive Software Engineering Hinweise Mi. 21.12. keine Vorlesung mehr! Mi. 4. 1. ist normale Vorlesung Fr. 6. 1. findet ebenfalls statt Mi. 11.1., Fr. 13.1. MBEES (Vorlesung entfällt) 9.12.2005

Thanks for the pictures: © Sergio Montenegro, FIRST 9.12.2005

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) Funktionale Redundanz zusätzliche, unterstützende Komponenten Test, Konfiguration, Sensoren Informationsredundanz Zusätzliche Informationen Prüfbits, zusätzliche Zeiger, Zähler Zeitliche Redundanz Zusätzliche Zeit für wiederholte Ausführungen (Retry) 9.12.2005

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? 9.12.2005

Warum Fehlertoleranz? Steuerungscomputer Aktuatoren Sensoren Technischer Prozeß 9.12.2005

9.12.2005

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 9.12.2005

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 9.12.2005

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

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

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

9.12.2005

9.12.2005

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

Verallgemeinerung 9.12.2005

9.12.2005

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

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

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

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 9.12.2005

Fehlerakkumulation 9.12.2005

9.12.2005

9.12.2005