Modellbasierte Software-Entwicklung eingebetteter Systeme

Slides:



Advertisements
Ähnliche Präsentationen
1 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand – Ergänzung FP Copyright: Dr. Klaus Röber Modul Ergänzungen zur.
Advertisements

Definition [1]: Sei S eine endliche Menge und sei p eine Abbildung von S in die positiven reellen Zahlen Für einen Teilmenge ES von S sei p definiert.
Software in sicherheitsrelevanten Systemen
Eingebettete Systeme Qualität und Produktivität
Modellbasierte Software-Entwicklung eingebetteter Systeme
Modellbasierte Software-Entwicklung eingebetteter Systeme
Eingebettete Systeme Qualität und Produktivität
Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Prof. Dr. Holger Schlingloff
Dr. Hans-Werner Wiesbrock ZeSys e.V.
Qualitätssicherung von Software (SWQS)
Qualitätssicherung von Software (SWQS)
Modellbasierte Software-Entwicklung eingebetteter Systeme
Qualitätssicherung von Software
Eingebettete Systeme Qualität und Produktivität
Eingebettete Systeme Qualität und Produktivität
Mörgeli + mörgeli consulting engineering m+m/am, AA ESI, Erweitertes Management Summary, (Version 3, – Datenschutz für Publikation)
Kooperierende autonome Fahrzeuge
FMEA Fehler-Möglichkeits- und Einfluß-Analyse Design- und Prozeß-FMEA
Schwachstellenanalyse in Netzen
Eingebettete Systeme Qualität und Produktivität
Modellbasierte Software-Entwicklung eingebetteter Systeme
Qualitätssicherung von Software
Prof. Dr. Holger Schlingloff
Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Prof. Dr. Holger Schlingloff
Prof. Dr. Holger Schlingloff
Qualitätssicherung von Software Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FIRST.
Qualitätssicherung von Software
Qualitätssicherung von Software
Eingebettete Systeme Qualität und Produktivität
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Spezifikation, Verifikation, Testtheorie Prof. Dr. Holger Schlingloff Institut für Informatik und Fraunhofer FIRST.
Prof. Dr. Holger Schlingloff
Risikoanalyse in der Kerntechnik
Was ist Qualität ? Qualität von Produkten oder Dienstleistungen ist das Gesamtergebnis aller Aktivitäten in jeder Phase des gesamten Leistungsprozesses.
Es gibt viele Arten von Risiken
Controlling, Analyse und Verbesserung (Teil 1)
WS Algorithmentheorie 08 – Dynamische Programmierung (2) Matrixkettenprodukt Prof. Dr. Th. Ottmann.
Vorlesung: 1 Betriebssysteme 2007 Prof. Dr. G. Hellberg Studiengang Informatik FHDW Vorlesung: Betriebssysteme Hochverfügbarkeit (Einführung) 3. Quartal.
Vorlesung: 1 Betriebssysteme 2008 Prof. Dr. G. Hellberg Studiengang Mechatronik FHDW Vorlesung: Betriebssysteme Hochverfügbarkeit (Einführung) 2. Quartal.
Software Risk Evaluation Method (SRE)
Kontrollfragen zu Kapitel 1
Vorgehensmodelle: Schwergewichtige Modelle
Software Engineering SS 2009
EBAV® (Experience Based Asset Valuation)
Auslegung eines Vorschubantriebes
1 Hugo Straumann, CT-SSM 17. Juni 2002 Security Risk Radar Hugo Straumann Methode Pilot Positionierung.
UML-Kurzüberblick Peter Brusten.
Instandhaltung ist ein Thema für das Topmanagement: von der reaktiven Fehlerbehebung zum Wertschöpfungsfaktor Tobias Zaers.
1 Dr. Carlheinrich Heiland Universität Hamburg - Die Computersimulation verändert als Schlüsseltechnologie die Arbeitsweise in Planung.
Zertifizierung Mario Grotschar 23. Mai 2007.
Mag. (FH) Patrick Fritz Methode FMEA erstellt von
Gefahren- und Risikobewertung für Bedarfsplanung im Feuerwehrwesen
Modellbasierte Software-Entwicklung eingebetteter Systeme
Modellbasierte Software-Entwicklung eingebetteter Systeme
Software Engineering Grundlagen
Qualitätssicherung von Software Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FIRST.
Software in sicherheitsrelevanten Systemen
Modellbasierte Software-Entwicklung eingebetteter Systeme
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Modellbasierte Software-Entwicklung eingebetteter Systeme
OOSE nach Jacobson Sebastian Pohl/ST7 Betreuer: Prof. Dr. Kahlbrandt.
Projektantrag für die Umsetzung von ITIL
Projektantrag für die Umsetzung von ISO :2011 Untertitel oder Sprecher.
Montagagetechnik Band 2
RISIKOANALYSE Ressourcendokumente
 Präsentation transkript:

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

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

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

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

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

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)

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

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)

Grundannahme http://www.csr.ncl.ac.uk/FELIX_Web/4B.IEC%2061508%20Intro.pdf „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)

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

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

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

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

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

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

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

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

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

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

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

Schadensart und -Häufigkeit

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

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