Modellbasierte Software-Entwicklung eingebetteter Systeme

Slides:



Advertisements
Ähnliche Präsentationen
Messen Sie jede auftretende Störung
Advertisements

Lexikon der Qualität Begriffe in Verbindung mit Qualität und ISO9000 finden sie auch im Lexikon der Qualität erläutert (
Risiko-Management im Projekt
Qualität „Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener.
Phasen und ihre Workflows
1 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand – Ergänzung FP Copyright: Dr. Klaus Röber Modul Ergänzungen zur.
RFID - Die Akte antwortet
Prof. Dr. Liggesmeyer, 1 Software Engineering: Dependability Prof. Dr.-Ing. Peter Liggesmeyer.
Eingebettete Systeme Qualität und Produktivität
Modellbasierte Software-Entwicklung eingebetteter Systeme
Modellbasierte Software-Entwicklung eingebetteter Systeme
Prof. Dr. Holger Schlingloff
Eingebettete Systeme Qualität und Produktivität
Qualitätssicherung von Software (SWQS)
Qualitätssicherung von Software (SWQS)
Qualitätssicherung von Software
Eingebettete Systeme Qualität und Produktivität
Das „Vorgehensmodell“
Software in sicherheitsrelevanten Systemen
Vorlesung Gesamtbanksteuerung Operationelle Risiken
Projektumfeld Gesellschaftliche Strömungen Strukturen/ Gliederung
Eingebettete Systeme Qualität und Produktivität
Qualitätssicherung von Software Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FIRST.
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.
Modellbasierte Software-Entwicklung eingebetteter Systeme
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.
On a Buzzword: Hierachical Structure David Parnas.
Ausnahmen HS Merseburg (FH) WS 06/07.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme MuSofT LE Capability Maturity Model Tailoring Tailoring bedeutet ungefähr: Maßschneidern.
Erfahrungen aus Tests komplexer Systeme
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.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Aufgaben des Testens Vergleich des Verhaltens einer Software mit den an sie gestellten.
Beispiel: Wasserfallmodell als einfaches Phasenmodell
Deklaratives Debugging (Seminar Software Engineering) Tim Sender Deklaratives Debugging Seminar Software Engineering.
2.5. Mikrocontroller-Komponenten
Vortrag 11: Reengineering - Refactoring
Software Risk Evaluation Method (SRE)
Von Molekülen zu Systemen
Eigenschaften der OLS-Schätzer
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Objektmodellierung Objekte und Klassen Ein Objekt ist ein Exemplar.
Spezifikation von Anforderungen
Das Wasserfallmodell - Überblick
Software Engineering SS 2009
Ausgleichungsrechnung I
Ausgleichungsrechnung II
Telecooperation/RBG Technische Universität Darmstadt Copyrighted material; for TUD student use only Grundlagen der Informatik I Thema 16: Ausnahmebehandlung.
5 Software-Qualität 5.1 Qualität 5.2 Taxonomie der Software-Qualitäten.
Modellbildung und Simulation
Petrinetze 1. Einführung Informatik : wesentlich Modellierung von
Modellbasierte Software-Entwicklung eingebetteter Systeme
Modellbasierte Software-Entwicklung eingebetteter Systeme
Von Unternehmen und Unternehmern
Statistik – Regression - Korrelation
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
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 Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Risikomanagement in Projekten
Projektmanagement und Softwarequalität
Verantwortung für Fehler: Über den richtigen Umgang Vortrag von Prof. Dr. Carmen Kaminsky Sozialphilosophie; FH-Köln.
 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 offene Kommunikationssysteme FOKUS

Fragen? Welche Hardwarekomponenten enthält eine Embedded Plattform? Unterschied Mikroprozessor – Mikrocontroller – System-on-Chip? Besonderheiten von embedded CPUs? Stromsparkonzepte? Besonderheiten vom Speicher für eingebettete Systeme? Welche Arten von Sensoren kennen Sie? Wie werden intelligente Sensoren mit der CPU verbunden? Was versteht man unter PWM?

Kap. 6: Sicherheit Funktionale Sicherheit (FuSi) der Teil der Sicherheit eines Systems, der von der korrekten Funktion der sicherheitsbezogenen (Sub-)Systeme und externer Einrichtungen zur Risikominderung abhängt nicht erfasst: nichtfunktionale Eigenschaften, z.B. Brandschutz Diverse Normen und Richtlinien IEC 61508 "Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbar elektronischer Systeme“ viele daraus abgeleitete Normen Maßnahmen zur Vermeidung, Erkennung und Beherrschung von Fehlern Maßnahmen während der Entwicklung Absicherung des laufenden Betriebs

Ursache, Wirkung und Folge Standardwerk zur Terminologie: J.C. Laprie, A. Avizienis, H. Kopetz: Dependability: Basic Concepts and Terminology. Springer-Verlag (englisch, deutsch, französisch) Irrtum (error) Ursache  Fehlzustand (fault) Wirkung  Ausfall (failure) Folge Ausfall kann Ursache für weiteren Fehler sein!

Fehlerursachen Fehlerursache (cause): direkter oder indirekter Vorgänger in der Wirkfolge ein Fehler hat meist viele Ursachen Fehlerursache = Anerkannte oder angenommene Ursache für einen Fehler. Ereignis, das vermieden oder toleriert werden sollte. Auswirkung des Ausfalls eines anderen Systems, das mit dem betrachteten System zusammengewirkt hat oder zusammenwirkt, auf das betrachtete System letztlich ist jeder Fehler auf das menschliche Unvermögen zurückzuführen, die Gesamtheit aller Wirkzusammenhänge zu verstehen. Beispiel: Materialbruch  Materialforschung Beispiel: Ariane 5  Flugbahneinfluss Irrtum (error), Fehlhandlung (mistake)

Fehlzustände Fehlzustände treten auf, wenn ein System auf Grund äußerer Einflüsse oder selbsttätig in einen ungewollten Zustand übergeht Fehlzustand = Teil des Systemzustands, der dafür verantwortlich ist, dass ein Ausfall auftritt. Offenbarung einer Fehlerursache im System Möglichkeit des Fehlzustands ist immer schon im System vorhanden, der Fehlzustand wird durch den ausführenden Prozess nur aktiviert Beispiel: Division durch 0 in Zeile 739 Beispiel: Bit kippt auf Grund von alpha-Strahlung Fehlzustand (fault), Defekt (defect)

Fehlerauswirkung Fehlverhalten ist die Konsequenz aus einem Fehlzustand. Wenn ein System einen Defekt enthält, führt das meist früher oder später zu einem teilweisen oder totalen Ausfall. Beispiel: kaputtes Zahnrad  Getriebeschaden Beispiel: ungeschützte Gleitpunktkonvertierung  … Ausfall = Abweichung der erbrachten Leistung von der in der Spezifikation geforderten Leistung. Übergang von korrekter Leistungserbringung zu fehlerhafter Leistungserbringung. Ausfall und Versagen sind weitgehend synonym (failure) Ausfall eher für Komponenten, Versagen eher für Gesamtsysteme Im Sinne der Hierarchie ist der Ausfall einer Komponente die Ursache für das Versagen des Systems

Fehlerarten oftmals unterscheidet man zwischen zufälligen Fehlern und Auftreten nur statistisch vorhersagbar, z.B. Bitflip auf Grund von Strahlung und systematischen Fehlern in der Systematik (Art der Zusammensetzung des Systems) begründet, z.B. Bitflip auf Grund eines Programmierfehlers Diese Unterscheidung ist grob vereinfachend bzw. unscharf! Was ist z.B., wenn ein Bitflip eine Exception wirft, die nicht gefangen wird?

Klassifikation von Fehlern (1) Intention (Art) zufälliger Fehler = zufällig auftretender oder erzeugter Fehler (z.B. Kommafehler) absichtlicher Fehler = in böswilliger Absicht erzeugter Fehler (z.B. Backdoor) „zufällig“ bedeutet hier nicht „stochastisch auftretend“, sondern „ohne Absicht“ Idee, phänomenologischer Ursprung physikalischer Fehler = Fehler aufgrund eines physikalischen Phänomens (z.B. Materialbruch) logischer Fehler = auf menschlicher Unzulänglichkeit basierende Fehlerursache, Denkfehler (z.B. Feldindex)

Klassifikation von Fehlern (2) Raum externer Fehler = von der Beeinflussung des Systems durch seine physikalische Umgebung oder vom Zusammenwirken mit seiner menschlichen Umgebung hervorgerufene Fehlerursache interner Fehler = Teil des Systemzustandes, der bei Aufruf durch eine Rechenaktivität einen Fehler hervorruft Zeit, Entstehungsphase Betriebsfehler = während der Nutzung des Systems auftretender Fehler Entwurfsfehler, Konstruktionsfehler = während der Entwicklung oder der Modifikation oder der Erstellung der Betriebsprozeduren entstandener Fehler

Klassifikation von Fehlern (3) Dauer permanente Fehler = Anwesenheit ist nicht von einer punktuellen Bedingung abhängig Temporäre oder transiente Fehler = nur während einer bestimmten Zeit vorhanden Unterscheidung reversibel (reparierbar) oder nicht! temporäre interne Fehler werden auch intermittierende Fehler genannt „Benutzerfehler“ oder „Bedienfehler“ ist demnach zufälliger, logischer, externer, temporärer Betriebsfehler wichtig: Ursachen- statt Schuldanalyse! jeder Fehler kann als permanenter Entwurfsfehler verstanden werden

Klassifikation von Ausfällen Wert- oder Zeitausfälle verfrüht oder verspätet konsistent oder inkonsistent kritisch oder unkritisch Stillstand oder Livelock Auslassungsausfälle, Totalausfälle …

IEC 61508: Sicherheits-Lebenszyklus Analyse der Bedrohung durch das EUC Ableitung von Sicherheits-anforderungen Planung und Realisierung von Sicherheits-mechanismen Validierung und Betrieb der Systeme

IEC 61508 Prozess (System)

IEC 61508 Prozess (Software)

Gefährdungs- und Risikoanalyse Gefährdung: potentielle Schadensquelle Risiko: Verbindung / Kombination der Auftretenswahrscheinlichkeit eines Schadens und des zugehörigen Schadensausmaßes Auftretenswahrscheinlichkeit: der Parameter des Risikos, der Auskunft über die Wahrscheinlichkeit gibt, mit der eine identifizierte Gefährdung bzw. ihre Ursache in der Praxis tatsächlich auftreten könnte. Eintrittswahrscheinlichkeit Entdeckungswahrscheinlichkeit Möglichkeit zur Gefahrenabwendung Schadensausmaß: quantitatives Maß für die möglichen Folgen / Konsequenzen einer Gefährdung Sicherheit: Freiheit von nicht akzeptablen Risiken Risiko = Eintrittswahrscheinlichkeit * Schadensausmaß

Risikoanalyse Risiko = Eintrittswahrscheinlichkeit * Schadensausmaß z.B. Aktienkursverlust Problem bei sehr kleinen und sehr großen Zahlen sehr großer Schaden bei sehr geringer Wahrscheinlichkeit Problem der numerischen Einschätzung Kosten bei Personenschaden? Wahrscheinlichkeit von Katastrophen? akzeptabeles Risiko? abhängig vom persönlichen Einfluss

ALARP ALARP-Prinzip: „As Low As Reasonably Possible“ Wenn ein Risiko mit vertretbarem Aufwand reduziert werden kann, sollte dies getan werden Oft auch: Wenn das Risiko nicht reduziert werden kann, muss der Nutzen des Systems (Nutzungsdauer * Gewinn) den Schaden übersteigen “Cost per life saved”

Automobil- versus Luftfahrtsicherheit Katastrophen werden subjektiv höher gewichtet

Planes, Trains and Automobiles E. Schnieder: 4. Bieleschweig Workshop, 14.-15.9.04: NEUE UND HERKÖMMLICHE MAßE ZUR QUANTIFIZIERUNG DES RISIKOS IM EISENBAHNVERKEHR Quelle: http://www.ifev.bau.tu-bs.de/Workshops_Tagungen/Bieleschweig/bieleschweig4/pdf/Bieleschweig4_Folien_Schnieder.pdf