9.12.2005 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof....

9.12.2005

Software-Engineering IIEingebettete Systeme, Softwarequalität, Projektmanagement

Prof. Dr. Holger SchlingloffInstitut für Informatik der Humboldt Universität

und

Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik

http://www.hu-berlin.de/index.html

Folie 2H. Schlingloff, Software-Engineering II 9.12.2005

Übersicht

• 1. Eingebettete Systeme 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)


Thanks for the pictures: © Sergio Montenegro, FIRST


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)


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?


Warum Fehlertoleranz?

Steuerungscomputer

SensorenAktuatoren

Technischer Prozeß


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 Systemim 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


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 Ausfalldichtez(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


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


Fehlerarten

•SW-Fehler: diversitäre Entwicklung (teuer!)

•HW-Fehler, z.B. Speicher, Leitungen, Prozessoren…

•Byzantinische und nichtbyzantinische Fehler

•Fail-Operational, Fail-Soft, Fail-Stop


A CB

Seriell

A

Parallel

Was soll man duplizieren?

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


Fehlerakkumulation

9.12.2005 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof....

Documents

Transcript of 9.12.2005 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof....