Modellbasierte Software- Entwicklung eingebetteter Systeme

Transkript

1 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

2 Folie 2 Fragen! Was versteht man unter funktionaler Sicherheit? Definition Fehler? Sortieren und übersetzen Sie: failure, defect, mistake, error, fault, incident, accident, deficit, bug, glitch zufällige versus systematische Fehler: Unterschied? Problematik? Fehlerklassifikationen? Ursachen- versus Schuldanalyse? letztendliche Fehlerursache? Was beschreiben Sicherheitsnormen? Wie ist der Sicherheitslebenszyklus nach IEC 61508? Definition der Begriffe Risiko und Sicherheit? Probleme der Risikoanalyse? Was versteht man unter ALARP?

3 Folie 3 6.2: Sicherheitsnormen IEC "Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbar elektronischer Systeme Daraus abgeleitet Bahntechnik: CENELEC EN Automobiltechnik: ISO Medizintechnik: IEC Maschinen und Anlagen: IEC Chemische Prozessindustrie: IEC Separat entwickelt Luftfahrt: DO 178C plus Addenda

4 Folie 4 Funktionale Sicherheit Schutz gegen Gefahren, die von einer gestörten oder fehlerhaften Funktion ausgehen Sicherheit einer Anlage bzw. Anwendung ist von der sicheren Funktion der Überwachungseinrichtungen bestimmt; Funktionale Sicherheit ist gegeben, wenn jedes Risiko über Schutzeinrichtungen abgesichert ist Sicherheit muss beim normalen Betrieb gewährleistet sein und darf beim Ausfall einzelner Komponenten nicht verloren gehen Sicherer Zustand? Nachweise: FMEA, FTA,... (nächste Woche) Numerische Betrachtungen zum Restrisiko!

5 Folie 5 Iterativer Sicherheitsprozess

6 Folie 6 Aufbau der IEC Veröffentlicht 1998, revidiert 2010 steigende Bedeutung in der Industrie (insbesondere Spezialisierungen) Teil 1: Allgemeine Anforderungen Teil 2: Anforderungen an sicherheitsbezogene e/e/pe Systeme Teil 3: Anforderungen an Software Teil 4: Begriffe und Abkürzungen Teil 5: Beispiele zur Ermittlung der Stufe der Sicherheitsintegrität Teil 6: Anwendungsrichtlinien Teil 7: Übersicht über Techniken und Maßnahmen Normativ Informativ zentraler Begriff: Sicherheitsanforderungsstufe (SAS, engl.: SIL Safety Integrity Level) alle Anforderungen sind SIL-abhängig

7 Folie 7 Merkmale der betrachtet alle Phasen im Lebenszyklus eines Produkts, ganzheitliche Betrachtung Anforderungen zur funktionalen Sicherheit: Vermeidung systematischer Fehler (QM) Beherrschung systematischer Fehler / Ausfälle Beherrschung zufälliger Ausfälle Dokumentation Fehlerwahrscheinlichkeit und Zuverlässigkeit Management der funktionalen Sicherheit

8 Folie 8 zurück zur 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

9 Folie 9 quantitative Abschätzung Eintrittswahrscheinlichkeitsklassen Schadensauswirkungsklassen

10 Folie 10 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

11 Folie 11 Schadensart und -Häufigkeit

12 Folie 12 Sicherheitsanforderungsstufen SIL: Safety Integrity Level System-SIL wird bestimmt durch RAMS-Analyse (Reliability, Availability, Maintainability, Safety) Software-SIL folgt System-SIL

13 Folie 13 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 (EN 50128) 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.ä.

14 Folie 14 Abwendbarkeit

15 Folie 15 Risikograph nach IEC 61508

16 Folie 16 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. Trennung von sicherheitsgerichteten und nicht sicherheitsrelevanten Forderungen! Architekturprinzip! Einfluss auf die SW-Architektur

17 Folie 17 Beispiel

18 Folie 18 ASIL ISO (automotive) definiert automotive Sicherheitsanforderungstufen (ASIL) A-D Bedrohungs- und Risikoanalyse besteht aus 3 Schritten Situationsanalyse und Identifikation der Bedrohungen - Identifikation der möglichen, unerwünschten Verhalten die zu einer Gefährdung führen können Klassifikation der Bedrohungen - Bestimmung der Schwere (severity S), der Dauer (exposure E) und der Interventionsmöglichkeit (controllability C) jeder Bedrohung ASIL Festlegung - Sicherheitsanforderungsstufe wird nach Tabelle festgelegt - Maßnahmen werden abgeleitet

19 Situationsanalyse Ziel: Bestimmung aller relevanten operationalen Situationen und Betriebsmodi in denen eine Bedrohung durch Fehlfunktionen des Fahrzeugs eintreten kann potentielle, nicht tatsächliche Vorkommnisse Beispiele für Situationen Fahren innerhalb geschlossener Ortschaften Fahren auf regennasser Autobahn... Beispiele für Bedrohungen Ungewolltes Auslösen des Airbags Airbag funktionsuntüchtig ohne Fahrerbenachrichtigung Bremse versagt vollständig Abstandswarnsystem fällt aus H. Schlingloff, SS2014 modellbasierte Software-Entwicklung eingebetteter Systeme Folie 19

20 Folie 20 ASIL Faktoren Graphik thanks to M. Soden, IKV

21 Folie 21 ASIL Tabelle

22 Folie 22 Beispiel

23 Folie 23 alternative Einschätzung

24 Folie 24 Beispiel

25 Folie Maßnahmen

26 Folie 26 Wichtigkeit der Maßnahmen

27 Folie 27 Wirksamkeit der Maßnahmen

28 Folie 28 Maßnahmen in den Lebensphasen

29 Folie 29 V-Modell nach 61508

30 Folie 30 Ablauf der Phasen

31 Folie 31 Beispiel: SW-Architektur

32 Folie 32 Forderungen an den Entwicklungsprozess

33 Folie 33 Maßnahmen (1) HW

34 Folie 34

35 Folie 35 Maßnahmen (2) SW

36 Folie 36

37 Folie 37 Annex: Auswahl von Verfahren und Techniken

38 Folie 38

39 Folie 39

40 Folie 40 Betriebsbewährtheit Bootstrapping-Problematik!

41 Folie 41 Coding Rules

42 Folie 42

43 Folie 43 noch: Codierregeln

44 Folie Dokumentationsanforderungen

45 Folie 45 Allgemeine Anforderungen

46 Folie 46 Dokumentenstruktur

47 Folie 47 Anforderungen an Dokumente Für jedes Dokument gibt es detaillierte Anforderungen in Bezug auf den Inhalt Struktur ist firmenspezifisch! Beispiel: Requirements

48 Folie 48 IEC Software safety lifecycle requirements 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 may be suitably customised for the particular needs of the project or organisation 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 The software safety requirements specification shall specify and document any safetyrelated or relevant constraints between the hardware and the software 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

49 Folie 49 Software design and development 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.

50 Folie 50 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, )

51 Folie 51 weiterer Aufbau der Forderungen 7 Software safety lifecycle requirements General Software safety requirements specification Software safety validation planning Software design and development Programmable electronics integration (hardware and software) Software operation and modification procedures Software safety validation Software modification Software verification Anforderungsklassen M = mandatory HR = highly recommended R = recommended -- = no recommendation NR= not recommended