Post on 31-Dec-2015
description
6.1.2006
Software-Engineering IIEingebettete Systeme, Softwarequalität, Projektmanagement
Prof. Dr. Holger SchlingloffInstitut für Informatik der Humboldt Universität
und
Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik
Folie 2H. Schlingloff, Software-Engineering II 6.1.2006
Übersicht
1. Eingebettete Systeme1.1. Definitionen1.2. Anforderungsanalyse1.3. Modellierung1.4. Architektur1.5. Automotive Software Engineering
2. Software-Qualität2.1 Definitionen und Standards2.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)
Folie 3H. Schlingloff, Software-Engineering II 6.1.2006
Sicherheits-Lebenszyklus
• Analyse der Bedrohung durch das EUC
• Ableitung von Sicherheitsanforderungen
• Planung und Realisierung von Sicherheitsmechanismen
• Validierung und Betrieb der Systeme
Folie 4H. Schlingloff, Software-Engineering II 6.1.2006
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ß
Folie 6H. Schlingloff, Software-Engineering II 6.1.2006
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
Folie 7H. Schlingloff, Software-Engineering II 6.1.2006
Automobil- versus Luftfahrtsicherheit
• Katastrophen werden subjektiv höher gewichtet
Folie 8H. Schlingloff, Software-Engineering II 6.1.2006
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
Folie 9H. Schlingloff, Software-Engineering II 6.1.2006
quantitative Abschätzung
• Eintrittswahrscheinlichkeitsklassen
• Schadensauswirkungsklassen
Folie 10H. Schlingloff, Software-Engineering II 6.1.2006
Risikomatrix
I: UnakzeptabelII:Unerwünscht; nur tolerierbar falls Risikoverminderung nicht
oder nicht mit vertretbarem Aufwand möglichIII: Tolerierbar falls die Kosten die Verbesserungen übersteigenIV: Akzeptierbar, sollte möglicherweise überwacht werden
Folie 11H. Schlingloff, Software-Engineering II 6.1.2006
Sicherheitsanforderungsstufen
•SIL: Safety Integrity Level
Folie 12H. Schlingloff, Software-Engineering II 6.1.2006
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.
Folie 13H. Schlingloff, Software-Engineering II 6.1.2006
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 safety-related 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
Folie 14H. Schlingloff, Software-Engineering II 6.1.2006
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.
Folie 15H. Schlingloff, Software-Engineering II 6.1.2006
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, …“)
Folie 20H. Schlingloff, Software-Engineering II 6.1.2006
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
Folie 21H. Schlingloff, Software-Engineering II 6.1.2006
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