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

3 RAMS(S) Dependability Mean Time to Failure (MTTF) Verlässlichkeit
Mittlere Laufzeit vor Ausfall Reliability Zuverlässigkeit Availability Verfügbarkeit Mean Time To Repair (MTTR) Maintainability Wartbarkeit Instandhaltbarkeit Safety Sicherheit Risikobehandlung: erkennen, eliminieren, reduzieren, Folgen minimieren Security Sicherheit

4 Verfügbarkeit Maß für die durchschnittliche Erbringung der Funktionalität Kenngrößen MTTF = Mean Time to Failure MTTR = Mean Time To Repair Availability = MTTF / (MTTF + MTTR) Verfügbarkeit und Sicherheit sind oft gegensätzliche Ziele! Ein Auto, das niemals fährt, ist sicher: es geht keine Gefahr von ihm aus, es ist aber nicht brauchbar Ein Auto, das immer fahren kann, auch wenn es auseinanderfällt, hat die höchste Verfügbarkeit, ist aber nicht sicher

5 Maintainability Reparatur nach Ausfall Vorausschauende Wartung
Entwicklung von Konzepten zur Optimierung von Instandsetzungsprozessen unter Berücksichtigung der Wartungstiefe, Zeit, Kosten und Ressourcen Vorausschauende Wartung Entwicklung von vorbeugenden und planbaren Instandhaltungsmaßnahmen, z.B. durch Austausch von Verschleißteilen, um eine möglichst hohe technische Zuverlässigkeit und Verfügbarkeit zu erreichen Die Instandhaltbarkeitsanalyse setzt auf den Ergebnissen der Zuverlässigkeitsanalysen (FMEA, FMECA) auf und berücksichtigt diagnosespezifische Aussagen DIN 31051, 06/2003 – Grundlagen der Instandhaltung EN 13306, 09/2001 – Begriffe der Instandhaltung MIL-STD 470 – Maintainability Engineering

6 Safety (Betriebssicherheit)
Freiheit von unvertretbaren Risiken (IEC61508) keine Gefährdung von Leib und Leben oder der Umwelt ISO 8402: Sicherheit = Zustand, in dem das Risiko eines Personen- oder Sachschadens auf einen annehmbaren Wert begrenzt ist was heißt „annehmbar“ ? Ein System heißt sicherheitskritisch, wenn es beim Ausfall großen Schaden verursachen kann funktionale Sicherheit korrekte Funktion der sicherheitsbezogenen (Sub-) Systeme und externer Einrichtungen zur Risikominderung (im Gegensatz zu z.B. Brandschutz) sicherer Zustand: keine Gefährdung durch das Gerät (aber ggf. auch keine Funktion; fail-safe, fail-stop)

7 Security (Angriffssicherheit)
Schutz gegen böswillig verursachte Fehler bzw. Ausfälle Wiki: Während „Safety“ den Schutz der Umgebung vor einem Objekt, also eine Art Isolation beschreibt, handelt es sich bei „Security“ um den Schutz des Objektes vor der Umgebung (?) Informationssicherheit Vertraulichkeit Datenintegrität Authentizität, Zurechenbarkeit, Nichtabstreitbarkeit, Nachweisbarkeit z.B. Trojaner im Auto durch CD-Spieler eingeschleust kann CAN-Nachrichten absetzen

8 Risikoanalyse systematisches Verfahren zur Bewertung der von einem Objekt ausgehenden Gefährdung Quantitative Ermittlung von Ausfall- und Gefährdungswahrscheinlichkeiten Ausgangspunkt bei der sicherheitsgerichteten Entwicklung von Systemen daraus wird die Sicherheitkritikalität (SIL, ASIL) des geplanten Systems abgeleitet Schritte Gefährdungsidentifizierung und –analyse Ursachenanalyse (FTA) Auswirkungsanalyse (FMEA)

9 Grundannahme „Equipment under Control“ (EUC) stellt immanente Gefährdung der Umgebung dar korrekte Steuerung allein garantiert keine Sicherheit Steuerung und Sicherung müssen getrennt betrachtet werden (z.B. separate Kabel)

10 Risikobegriffe Risikominderung durch verschiedene Technologien möglich; von IEC61508 wird nur E/E/PE betrachtet

11 Fehlerbaumanalyse (Fault tree analysis, FTA; DIN 25424)
entwickelt 1961 von H.A. Watson, Bell Labs Bewertung eines Raketen-Abschuss-Systems für SW und eingebettete Systeme erweitert Systematische Suche nach Fehlerursachen Elimination von singulären Schwachstellen Top-down, von der Wurzel zu den Blättern Jede Ebene im Baum zeigt den selben Sachverhalt, jedoch mit verschiedenen Detaillierungsgraden Wurzel repräsentiert Bedrohung, Blätter repräsentieren atomare Fehler (Ereignisse) Innere Knoten sind Abstraktionen von Ereignismengen

12 Vorgehensweise Top-Down-Analyse
Verfeinerung der Wirkzusammenhänge beginnend mit unerwünschtem Ereignis DIN: Nichtverfügbarkeit einer Einheit = Wahrscheinlichkeit des Ausfalls zu einem Zeitpunkt (Verteilungsfunktion F(t)) Analyse von Systemfunktionen Umgebungsbedingungen Hilfsquellen Komponenten Organisation

13

14 Berechnung Für boolesche Verknüpfungen
Und: F(t)=F1(t) * F2(t) Oder: F(t)=F1 (t) + F2(t) - F1 (t)*F2 (t) Nicht: F(t)=1 - F´(t) Unabhängigkeit von Ereignissen beachten! Jedem Blatt im Fehlerbaum wird Risiko und Wahrscheinlichkeit zugeordnet Risiko bedeutet finanzieller/materieller Verlust Wahrscheinlichkeit ggf. als Funktion der Zeit  Bottom-up-Berechnung nach vorstehenden Regeln ergibt Prioritätenliste der Risiken

15 FMEA Failure Mode and Effects Analysis
Identifikation potentieller Fehler und Auswirkungen Quantifikation der Risiken Entscheidungshilfen, Verbesserungsmaßnahmen Bottom-Up, „von den Fehlern zu den Ausfällen“ „Probably the most commonly used analysis technique in embedded system design“ Produkt- und Prozess-Sicht System- oder Produkt-FMEA systematische Analyse der möglichen Funktionsfehler Berechnung der funktionalen Zusammenhänge der Komponenten Prozess-FMEA Analyse möglicher Fehler im Herstellungsprozess Berücksichtigung der beteiligten Akteure

16 Wie wird bewertet? Analyse jeder Komponente Vorgehensweise
mögliche Fehler Ursachen für den Fehler verbundenes Risiko (Auswirkungen) Vorgehensweise 1. Abgrenzen der Betrachtungseinheit (Systemstruktur) 2. Funktionsanalyse Zusammenhänge den einzelnen Elementen aufzeigen Funktionskritische Merkmale erkennen 3. Fehleranalyse 4. Risikobewertung 5. Verbesserungsmaßnahmen

17 Bewertung Risikoprioritätszahl = A * E * B Richtlinie
A = P(Auftreten): Eintrittswahrscheinlichkeit E = P(Entdeckung): Wahrscheinlichkeit, dass Fehler sich auswirkt bevor er entdeckt und beseitigt werden kann B = Bedeutung: Gewicht der Folgen Richtlinie RPZ > 0,01: unbedingt Maßnahmen festlegen und umsetzen 0,004 < RPZ < 0,01: gegebenenfalls Maßnahmen festlegen und umsetzen RPZ < 0,004: mit Restrisiko leben

18 Beispiel Funktion/ Komponente Fehler Folgen Ursachen Prüfung A E B RPZ
Netzkabel Isolation beschädigt Stromschlag äußere Einwirkung Sichtkontrolle 0,2 0,1 0,4 0,008 Kind zieht am Kabel Verletzung Spieltrieb Bedienungsanleitung 0,5 0,7 0,07 Kabelbruch Geräteausfall mech. Belastung Funktionstest 0,3 0,003 nach P. Vetsch, Rheintal Handelsgesellschaft, Mauren

19 FMECA Erweiterte FMEA mit der Analyse der Fehlergefährlichkeit (Failure Mode, Effects and Criticality Analysis) Die Schwere des Fehlers wird quantitativ bestimmt Verlust in € bzw. Schadenshöhe

20 Gefährdungsanalyse (Hazard Analysis)
Bestimmung der Sicherheitkritikalität (SIL, ASIL) aus der Risikoanalyse Gefährdungsklassen, z.B. in MIL-STD-882B: Category 1: Catastrophic: may cause death or system loss Category 2: Critical: may cause severe injury, severe occupational illness, or major system damage Category 3: Marginal: may cause minor injury, minor occupational illness, or minor system damage Category 4: Negligible: will not result in injury, occupational illness, or system damage

21 Gefärdungswahrscheinlichkeit
Frequent: Likely to occur frequently to an individual item, continuously experienced throughout the fleet or inventory Probable: Will occur several times during the life of an individual item, frequently throughout the fleet or inventory Occasional: Likely to occur sometime during the life of an individual item, several times throughout the fleet or inventory Remote: Unlikely to occur but possible during the life of an individual item; unlikely but reasonably expected to occur in a fleet or inventory Improbable: Extremely unlikely to occur to an individual item; possible for a fleet or inventory Impossible: Cannot occur to an item or in fleet or inventory

22 Schadensart und -Häufigkeit

23 Beispiel: Cenelec SIL SIL = safety integrity level
System-SIL wird bestimmt durch RAMS-Analyse gemäß EN50126 (Reliability, Availability, Maintainability, Safety)

24 Bestimmung der Software-SIL
Software-SIL richtet sich nach System-SIL „… werden auf Basis der Risikostufe für den Einsatz der Software im System entschieden…“ Im Allgemeinen ist Software-SIL gleich der System-SIL „Without further precautions, the software safety integrity level shall be, as a minimum, identical to the system safety integrity level.“ Ausnahmen möglich, falls zusätzliche Sicherungsmaßnahmen eingeführt werden „if mechanisms exist to prevent the failure of a software module from causing the system to go to an unsafe state, the software safety integrity level of the module may be reduced“ Beispiel: HW-Watchdog, Voter o.ä.