Dr. Hans-Werner Wiesbrock ZeSys e.V.

Slides:



Advertisements
Ähnliche Präsentationen
Lexikon der Qualität Begriffe in Verbindung mit Qualität und ISO9000 finden sie auch im Lexikon der Qualität erläutert (
Advertisements

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.
Integrations- und Funktionstests im Rahmen des V-Modelles
Das V - Modell - Überblick
Vorgehensmodell & Wasserfallmodell in der Programmierung
Phasen und ihre Workflows
Prof. Dr. Liggesmeyer, 1 Software Engineering: Dependability Prof. Dr.-Ing. Peter Liggesmeyer.
Kapitel 11 Deadlocks RW-Systemarchitekur Kap. 11.
Gedanken zur Redundanz - ein Einführungsvortrag -
Qualitätssicherung von Software (SWQS)
Vorlesung Gesamtbanksteuerung Operationelle Risiken
Kooperierende autonome Fahrzeuge
FMEA Fehler-Möglichkeits- und Einfluß-Analyse Design- und Prozeß-FMEA
Objektorientierter Entwurf (OOD) Teil 3: Qualitätsmodell
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
Systeme 1 Kapitel 7 Deadlocks WS 2009/10.
Prozessqualität: Ansätze und Ziele
Software „Unter Software versteht man die Gesamtheit oder auch einen Teil der Programme für Rechensysteme. Diese Programme ermöglichen zusammen mit den.
Prozessqualität: Ansätze und Ziele
Was ist und wie prüft man Qualität
Prozessqualität und Produktqualität
Erfahrungen aus Tests komplexer Systeme
Risikoanalyse in der Kerntechnik
Prüfung von SW-Komponenten – Überblick
ISO - Normen Inhalt Qualität im SE Der ISO 9000-Ansatz
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
Zertifizierung von Software: CMM oder ISO 9000
Capability Maturity Model
Qualität von Software Qualität ist nicht messbar, sondern nur über die Erfüllung von Anforderungen zu definieren Die Erfüllung von Anforderungen ist oft.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme MuSofT LE 3.1-4V - Modell Überblick V-Modell Regelungen, die die Gesamtheit aller Aktivitäten,
Controlling, Analyse und Verbesserung (Teil 1)
Testen, Analysieren und Verifizieren von Software
Dokumentationsanforderungen
Rational Unified Process (RUP) - Definitionen
Prozeßstruktur des ISO 9001/9004 Prozeßmodells
Vortrag 11: Reengineering - Refactoring
Professionelles Projektmanagement in der Praxis
PG 520 Intelligence Service – gezielte Informationen aus dem Internet
Die Bank von morgen - eine neue Welt für IT und Kunden? 23. Oktober 2001.
Tino Reindanz - FSU Jena Seminar Aktive Datenbanken – SS 2007 Folie 1 Seminar Aktive Datenbanken Rule Development Rule Development for Active Database.
Vorgehensmodelle: Schwergewichtige Modelle
Spezifikation von Anforderungen
Das Wasserfallmodell - Überblick
Software Engineering SS 2009
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Weitere Vorgehensmodelle Der Rational Unified Process RUP –bei IBM.
Versicherung / Restrisiko
Universität zu Köln Historisch-Kulturwissenschaftliche Informationsverarbeitung Softwaretechnologie II (Teil I): Simulation und 3D Programmierung Prof.
Beweissysteme Hartmut Klauck Universität Frankfurt WS 06/
Information und Kommunikation
IT-Projektmanagement SS 2013 Prof. Dr. Herrad Schmidt
Software-Technik „Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige.
Wilhelm Klein, März 2010 Entwickeln mit Methode Projekt Manager Projektplanung Steuerung und Kontrolle Bereitstellung (Hardware und Software) Qualitätssicherung.
Spice Info-Point 2008 Urs Frei.
© &.com Part Average Analysis PAA Rev. 2.0 / Grundlage der Methodik P AA.
Mind-Manager/FreeMind & CONSIDEO MODELER
Rational Unified Process
Software Engineering Grundlagen
deterministisches chaos
Unified Process Historisch-Kulturwissenschaftliche Informationsverarbeitung Übung: Planung von Softwareprojekten Dozent: Christoph Stollwerk WS 2014/2015.
Software in sicherheitsrelevanten Systemen
Universität zu Köln Historisch-Kulturwissenschaftliche Informationsverarbeitung Softwaretechnologie II (Teil I): Simulation und 3D Programmierung Prof.
Qualitätsmanagement nach ISO 9001:2000 in der Zahnarztpraxis
Vs61 6 Fehlertoleranz. vs62 Zuverlässigkeit (reliability) Sicherheit vor FehlernSicherheit vor Angriffen (safety)(security) WS/SS xySystemsicherheit SS.
Projektmanagement und Softwarequalität
Eldar Dedic HA061 bbw - Hochschule
Planung und Umsetzung von QM im Rahmen des Projektmanagements
 Präsentation transkript:

Dr. Hans-Werner Wiesbrock ZeSys e.V. Zentrum zur Förderung eingebetteter Systeme e.V. Qualitätssicherung von Software Fehleranalysen PHA (Prophylactic hazard analalysis) FTA (Failure Tree Analysis) FMEA (Failure Mode and Effects Analysis) Dr. Hans-Werner Wiesbrock ZeSys e.V.

Inhalt Beispiel PHA (Prophylaktische Hazard Analysis) FTA (Failure Tree Analysis) FMEA (Failure Mode & Effect Analysis) Risiko Analyse und SW 1 2 3 4 5

Inhalt Beispiel PHA (Prophylaktische Hazard Analysis) FTA (Failure Tree Analysis) FMEA (Failure Mode & Effect Analysis) Risiko Analyse und SW 1 2 3 4 5

Beispiel:Herzunterstützungssystem EXCOR® ein lebensrettendes Herzunterstützungssystem für Kinder und Erwachsene die an Herzinsuffizienz leiden. Das System besitzt zwei Pumpen, die das Blut in die beiden Herzkammern pumpt, um den Druck zu erhöhen. Software regelt die Motoren, die den Pumpdruck erzeugen. Abhängig von Patientendaten, Druckbedingungen wird der Blutfluss eingestellt und der systolische (oben) und diastolische (unten) Druck überwacht. Neues System: Umschaltventil soll Betrieb auch bei Ausfall einer Pumpe ermöglichen, wechselseitiges Pumpen.

Zuverlässigkeit Versagen des Systems kann Todesfolgen haben! Wie kann man das System sicher entwickeln? Besser, sicherer? Jede Branche, Automotive, Avionik, Medizintechnik,… hat seine eigene Normen und Vorschriften, Techniken,… jede Firma seine bevorzugten Methoden. Es gibt trotzdem gemeinsame Grundideen, Verfahrensweise und einige davon sollen hier vorgestellt werden. Leitende Frage: Wie lässt sich systematisch die Zuverlässigkeit eines Produkt verbessern? Was bedeutet Zuverlässigkeit? Sicher? Was bedeutet es für die Software? SW verletzt nicht selber, aber das fälschlich angesteuerte Relais kann tödlich wirken!

Ausschnitt: Medizintechnik Normen und Vorschriften und ihre Abhängigkeiten! ISO 13485 „Medizinprodukte-Qualitätsmanagementsysteme-Anforderungen für regulatorische Zwecke“ verlangt Risikoanalyse

Inhalt Beispiel PHA (Prophylaktische Hazard Analysis) FTA (Failure Tree Analysis) FMEA (Failure Mode & Effect Analysis) Risiko Analyse und SW 1 2 3 4 5

PHA (Prophylaktische Hazard Analysis) Fehler im Herzunterstützungssystem können Todesfolgen haben Schaden Als Schaden definiert ISO 14971 „physische Verletzung oder Schädigung der Gesundheit von Menschen oder Schädigung von Gütern oder der Umwelt“ Gefährdung Eine Gefährdung ist eine potenzielle Schadensquelle. Als Gefährdungssituation bezeichnet man die „Umstände, unter denen Menschen, Güter oder die Umwelt einer oder mehrerer Gefährdungen ausgesetzt Beispiel: Kronleuchter hängt in einem abschließbaren Zimmer In der vorläufigen Gefährdungsanalyse werden mögliche Gefährdungen identifiziert.

PHA (Prophylaktische Hazard Analysis) Es ist vorrangig erfahrungsbasiert und wenig systematisch: Branchen spezifische Checklisten Produkt spezifische Checklisten Erfahrungsberichte Feldrückmeldungen …. Gefährdungen beim Herzunterstützungssystem: Ausfall der Pumpen Stromschlag Leckage der Schläuche …

Inhalt Beispiel PHA (Prophylaktische Hazard Analysis) FTA (Failure Tree Analysis) FMEA (Failure Mode & Effect Analysis) Risiko Analyse und SW 1 2 3 4 5

FTA (Failure Tree Analysis) Wie kann es zu den Schäden kommen? FTA (Fehlerbaumanalyse) Deduktives Verfahren, sucht Ursachen für Ausfälle,… Top-Down Analyse -> System Ansatz

FTA (Failure Tree Analysis) 60er Jahre: Luft- und Raumfahrt Mitte der 70er Jahre: Kerntechnik Ende der 70er Jahre: Automobilindustrie Anfang der 90er Jahre: weitere technische und nichttechnische Bereiche Eine PHA identifiziert die potenziellen Gefährdungen, eine Fehlerbaumanalyse zielt auf die Ursachen ab und damit, diese Gefährdungen in ihrem Schadensfall zu verhindern. Was muss passieren? In welcher Zusammenspiel? -> boolesche Verknüpfung von unglücklichen Ereignissen! Ihr Vorgehen ist Top-Down, eine Baum Zerlegung boolesch verknüpfter Ausfälle! Beispiel: Fehler in der Software können zu erheblichen Schäden führen! Eine falsche Regelung der Pumpen kann zum Aufheizen des Blutes führen! Diese Ursachenkette zu erkennen ist eine Aufgabe der FTA!

FTA einer Eingebetteten Blutpumpe Thrombose Die Pumpen erwärmen sich zu stark & || Erhitzen des Blutes wird nicht erkannt Pumpen werden zu stark angetrieben Falsche Drücke werden erzeugt Blut erwärmt sich zu stark Verklumpen des Blutes

FTA und Entwicklungsprozess Die verschiedenen Phasen sind miteinander eng verschränkt! Top-Down Ansatz: Man benötigt Kenntnisse der Architektur! Andererseits: Um Gefährdungen zu vermeiden, sollten bestimmte Architekturen verwendet werden! HW/SW- Entwurf Architektur System- anfor- derungen Analyse von System- Anforde- rungen, RAN SW/HW- rungen Modelltest, Modell- analyse PH erstellen Architektur entwerfen Risiko Analyse Konsolidierung und Freigabe Entwicklungsphasen Unit-Test

Inhalt Beispiel PHA (Prophylaktische Hazard Analysis) FTA (Failure Tree Analysis) FMEA (Failure Mode & Effect Analysis) Risiko Analyse und SW 1 2 3 4 5

Risiko Mindernde Maßnahmen Beispiele: Redundanzen, zwei Akkus anstelle eines Trennung, Eingabe/Ausgabe läuft auf anderem Prozessor als die Regelung Besondere Vorkehrungen, spezielle Buchsen für Schläuche … Risiko Risiko ist definiert (ISO 14791) als Produkt der Wahrscheinlichkeit des Auftretens mit dem damit verbundenen Schaden. Zuverlässigkeit qualitativ Grad der Fähigkeit einer Betrachtungseinheit, die geforderte Leistung während einer vorgegebenen Zeitspanne zu erbringen Fähigkeit eines Systems, für eine gegebene Zeit korrekt zu arbeiten

Stochastische Zuverlässigkeit Zuverlässigkeit / Verfügbarkeit quantitativ Wahrscheinlichkeit, System zu gegebenem Zeitpunkt in funktionstüchtigem Zustand anzutreffen R(t) = P[kein Ausfall im Intervall 0..t] = 1- Wahrscheinlichkeit mindestens eines Ausfalls im Beobachtungszeitraum Beispiel: Todesfall des Patienten, p= 10-6 per anno => Risiko Schwerer Schaden * 10-6 per anno 106 Todesfälle, p = 10-12 per anno => gleiches Risiko !?! Zulässiges Risiko wird Produkt spezifisch definiert -> Einstufung in Risikoklassen Begriff Beschreibung Häufigkeit Gelegentlich Kann bei Bestimmungsgemäßem Gebrauch vorkommen 10-2 < p < 1 Unwahrscheinlich 10-8 < p < 10-6

FMEA (Failure Mode & Effect Analysis) Unterschiede zwischen SW und HW: # der Ausfälle t SW HW Produktionsfehler Verschleiß Wie können wir Risiken messen? Schaden = Kosten, Verlustrechnung,…, aber Ausfallwahrscheinlichkeit? Beispiel: Stromausfall beim Herzunterstützungssystem

FMEA (Failure Mode & Effect Analysis) Induktives Verfahren, Wirkungsanalyse von Fehlverhalten Fehlerfortpflanzung Analysen sind auf Komponentenebene herunter zu brechen! Werkzeug ESSaRel (IESE) Risikoprioritätszahl = A * E * B A = P(Auftreten): Eintrittswahrscheinlichkeit E = P(Entdeckung): Wahrscheinlichkeit, dass Fehler sich auswirkt bevor er entdeckt und beseitigt werden kann B = Bedeutung: Gewicht der Folgen, Schaden

FMEA (Failure Mode & Effect Analysis) Zerlegung des Systems in berechenbare Teile: Blätter dürfen nicht abhängig voneinander sein (Cut sets) Ausfallswahrscheinlichkeiten müssen bestimmt werden können Abstrakte Fehlerfortpflanzung muss berechenbar sein PH erstellen Architektur entwerfen Risiko Analyse und Freigabe Konsolidierung Entwicklungsphasen Betrachte alle möglichen Wege durch den FMEA Baum, von der Wurzel bis zu den Blättern, und berechne für diese die Risikoprioritätszahl. Die Gesamtsumme ergibt ein Maß für das verbliebene Risiko! Es gibt riesige Datenbanken über die Ausfallwahrscheinlichkeit von HW Bauteilen!

Inhalt Beispiel PHA (Prophylaktische Hazard Analysis) FTA (Failure Tree Analysis) FMEA (Failure Mode & Effect Analysis) Risiko Analyse und SW 1 2 3 4 5

FMEA und SW? Unterschiede zwischen SW und HW: # der Ausfälle t SW HW Produktionsfehler Verschleiß SW Systeme verhalten sich ‚deterministisch‘, Fehler sind reproduzierbar! Fehler werden am Anfang gemacht Spezifikationsfehler Implementierungsfehler … Ausfallwahrscheinlichkeit von SW? Möglicher Ansatz: Hazard-Rate proportional zur Anzahl enthaltener Fehler

Fehlerwahrscheinlichkeit in SW? Entdeckte Fehleranzahl 100 200 300 Effektive Testzeit [PT] 10 50 150 μ(t) 210 μ(t) – Anzahl beobachteter Fehler Annahme: Zuwachs pro Zeiteinheit proportional b zur Anzahl nicht entdeckter Fehler μ(t) ≈ a ( 1 – exp(- b t ) ) , a = Gesamtfehlerzahl λ0 = a b = Initial-Ausfallrate, λ(t) = λ0 exp(-bt) Ausfallrate zur Zeit t Maximum-Likelihood => Parameter a,b => Schätzung benötigte Testzeit für vorgegebene Ausfallrate

Fehlerwahrscheinlichkeit in SW? Sichere SW = höhere Qualität der SW => Anwendung verschiedener QS Techniken Simulation der Anforderungen Konzeptmodell Diversitäre Programmierung Effektives Testen Erfüllung von Testabdeckungskriterien Einsatz von Testmodelle Einsatz von Verifikationstechniken (setzt Architektonische Vorbedingungen voraus) Modell Checking Theorem Proving

Wie Risiken der SW Absichern? Architektonisch: Verwende sichere Architektur Muster Trennung von Zuständigkeiten Zentrale Steuerung komplexer Abläufe Robustes Design (Fehlerbehandlungen) … trenne über HW sicherheitsrelevante und andere SW Prozess: Definiere und installiere QM Prozess Entwickle nach definiertem Prozess CMMI Capability Maturity Model Integration (Automotive) SPICE Software Process Improvement and Capability Determination

Automotive SPICE – Capability Dimension Process Dimension: RM, Design,… TP, Wartung Capability Dimension Optimising Predictable Established Managed Performed Incomplete 1 2 3 4 5 CL5 CL4 CL3 CL2 CL1 CL0 P1 P2 P3 .......... Pn Klassifikation nach der Systemstruktur / Stichwörter zu den einzelnen Prozessen

Zusammenfassung Eingebettete Systeme können Gefahrenquellen bilden Müssen zuverlässig sein (s. Definition der Zuverlässigkeit) Risiko ist zu vermeiden (s. Risiko, Risikoanalyse, PHA, FTA, FMEA) Entwicklungsprozess ist darauf abzustimmen (s. Verschränkung von RM, Architektur und RAN ) Bei SW greift eine FTA, nicht aber eine FMEA (s. Fehlerwahrscheinlichkeit in SW) Prozess Vorgaben (s. SPICE, CMMI,…)

Literatur Dpunkt.verlag 2010 Peter Löw, Roland Pabst, Erwin Petry Funktionale Sicherheit Dpunkt.verlag 2010 Christian Johner, Matthias Hölzer-Klüpfel, Sven Wittorf Basiswissen Medizinische Software dpunkt.verlag 2011