Risiko = Eintrittswahrscheinlichkeit

Software-Engineering II
Eingebettete Systeme, Softwarequalität, Projektmanagement
Prof. Dr. Holger Schlingloff
Institut für Informatik der Humboldt Universität
und
Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik
6.1.2006
Übersicht
1. Eingebettete Systeme
1.1. Definitionen
1.2. Anforderungsanalyse
1.3. Modellierung
1.4. Architektur
1.5. Automotive Software Engineering
2. Software-Qualität
2.1 Definitionen und Standards
2.2 Funktionstest
 Überdeckungsmaße, Integrations- und Abnahmetest,
Spezifikationsformalismen, Verifikation und Modellprüfung, Metriken,
Reviews, Qualitätsstandards (CMM/I)
Hinweise
 Mi. 11.1., Fr. 13.1. MBEES (Vorlesung entfällt)
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 2
Sicherheits-Lebenszyklus
• Analyse der Bedrohung
•
•
•
durch das EUC
Ableitung von
Sicherheitsanforderungen
Planung und Realisierung
von
Sicherheitsmechanismen
Validierung und Betrieb
der Systeme
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 3
Gefährdungs- und Risikoanalyse
• Gefährdung: potentielle Schadensquelle
• Risiko: Verbindung / Kombination der Auftretenswahrscheinlichkeit
eines Schadens und des zugehörigen Schadensausmaßes
Risiko = Eintrittswahrscheinlichkeit * Schadensausmaß
• 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
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 4
IEC 61508 Prozess
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 5
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?
• 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
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 6
Automobil- versus Luftfahrtsicherheit
• Katastrophen werden subjektiv höher gewichtet
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 7
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
H. Schlingloff, Software-Engineering II
Quelle: http://www.ifev.bau.tu-bs.de/Workshops_Tagungen/Bieleschweig/bieleschweig4/pdf/Bieleschweig4_Folien_Schnieder.pdf
6.1.2006
Folie 8
quantitative Abschätzung
• Eintrittswahrscheinlichkeitsklassen
• Schadensauswirkungsklassen
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 9
Risikomatrix
I: Unakzeptabel
II:Unerwünscht; nur tolerierbar falls Risikoverminderung nicht
oder nicht mit vertretbarem Aufwand möglich
III: Tolerierbar falls die Kosten die Verbesserungen übersteigen
IV: Akzeptierbar, sollte möglicherweise überwacht werden
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 10
Sicherheitsanforderungsstufen
• SIL: Safety Integrity Level
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 11
Beispiel
• Sicherheitsanforderung:
 When the hinged cover is lifted by 5 mm or more,
the motor shall be de-energised and the brake
activated so that the blade is stopped within 1
second. The safety integrity level of this safety
function shall be SIL2.
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 12
IEC Software safety lifecycle requirements
• 7.1.2.1 A safety lifecycle for the development of software shall be
selected and specified during safety planning
 NOTE – A safety lifecycle model which satisfies the requirements of clause 7
of IEC 61508-1 may be suitably customised for the particular needs of the
project or organisation
• 7.2.2.2 The specification of the requirements for software safety shall be
derived from the specified safety requirements of the E/E/PE safetyrelated system, and any requirements of safety planning (see clause 6).
This information shall be made available to the software developer.
• 7.2.2.8 The software safety requirements specification shall specify and
document any safetyrelated or relevant constraints between the hardware
and the software.
• 7.3.2.1 Planning shall be carried out to specify the steps, both procedural
and technical, that will be used to demonstrate that the software satisfies
its safety requirements
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 13
Software design and development
• 7.4.2.2 In accordance with the required safety integrity level,
the design method chosen shall possess features that
facilitate:
a) abstraction, modularity and other features which control complexity;
b) the expression of:
–
–
–
–
–
–
–
functionality,
information flow between components,
sequencing and time related information,
timing constraints,
concurrency,
data structures and their properties,
design assumptions and their dependencies;
c) comprehension by developers and others who need to understand the
design;
d) verification and validation.
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 14
Softwarearchitektur-Forderungen
• muss explizit dargestellt werden
• muss in den Entwicklungszyklus eingebunden sein
• muss zu den einzelnen Komponenten Erklärungen
liefern
 neu, reimplementiert, verifiziert, sicherheitsrelevant etc.
• muss alle Schnittstellen enthalten
• muss beschreiben wie die Datenintegrität gesichert
•
•
wird
muss Integrationstests spezifizieren
kann werkzeugunterstützt verwaltet werden
(„To the extent required by the safety integrity level, …“)
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 15
weiterer Aufbau der Forderungen
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 16
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 17
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 18
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 19
Fault Tree Analysis
(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
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 20
Vorgehensweise
•
•
•
•
Wurzelknoten = Fehlerfall, unerwünschtes Ereignis
Kinder = Ursachen bzw. Teile des Fehlers
Verknüpfung mit booleschen Operatoren (oder, und, nicht)
Abbruch bei „elementaren Ereignissen“ die nicht weiter
analysiert werden
• Angemessener Detaillierungsgrad!
 Größen in der Praxis: 10-1000 Knoten
• Einheitliche Nomenklatur!
• Dekomposition nicht nur nach strukturellen Kriterien!
• Möglichkeit der numerischen Bewertung (bottom-up)
• Wahrscheinlichkeiten aus Erfahrungswerten oder
Analogieschlüssen
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 21
Beispiel
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 22
http://www.bqr.com/BQR-2005-1.pdf
H. Schlingloff, Software-Engineering II
6.1.2006
Folie 23