Software in sicherheitsrelevanten Systemen

1. Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2014

2. Kapitel 6 - Software für sicherheitsrelevante Systeme • Inhaltsübersicht • CENELEC • EN 50128 – eine Gebrauchsanleitung • Anforderungen • SW-Entwicklungsmethoden • SW-Test • Qualität • Qualitätssicherung von Entwicklungswerkzeugen Ralf Pinger / Stefan Gerken

3. 6.1 CENELEC • CENELEC ist das Europäische Normungskomitee für Elektrotechnik (Comité Européen de Normalisation Électrotechnique). • In der CENELEC sind die nationalen Normungskomitees von vielen europäischen Staaten vertreten (z.B. DKE - Deutsche Kommission Elektrotechnik, Elektronik, Informationstechnik im DIN und VDE). • In diesen Staaten werden nationale Normen durch CENELEC-Normen sukzessive ersetzt. • Die CENELEC hat unter anderem Normen zur funktionalen Sicherheit im Bahnbereich veröffentlicht Ralf Pinger / Stefan Gerken

4. 6.1 CENELEC – Struktur der Bahnnormen Ralf Pinger / Stefan Gerken

5. 6.1 CENELEC – Lebenszyklus nach EN 50126 Für jede Phase werden definiert • Ziele • Input (Dokumente) • Anforderungen • Output (Dokumente) • Verifikationsaufgaben Der Lebenszyklus umfaßt wesentlich mehr als nur die Entwicklung und beinhaltet Aufgaben für Hersteller und Betreiber! Bild: EN 50126 Ralf Pinger / Stefan Gerken

6. 6.1 CENELEC- Obligatorische Anforderungen CENELEC EN 50126 ist seit 1.4.2000 in allen CENELEC- Mitgliedsländern als nationale Norm in Kraft gesetzt. • Klar definierte Verantwortlichkeit für RAMS-Aufgaben • Kompetenznachweise • Ausarbeitung und Durchführung eines RAM Programms • Ausarbeitung und Durchführung eines Sicherheitsplans • Implementierung eines EN 50126 und ISO 900x konformen Geschäftsprozesses • Effektives Konfigurationsmanagement für RAMS-Aufgaben Ralf Pinger / Stefan Gerken

7. 6.2 EN 50128 – eine Gebrauchsanleitung • Normen sind keine Gesetze und haben nur Empfehlungscharakter • Haben einen definierten Sprachgebrauch (hier DIN) Ralf Pinger / Stefan Gerken

8. 6.2 EN 50128 – Anwendungsbereich • Verfahren und technische Anforderungen für die Entwicklung von programmierbaren elektronischen Systemen • gesamter Bereich der Sicherheitsanwendungen • gilt für jegliche sicherheitsrelevante Software, die in Eisenbahnsteuerungs- und -überwachungssystemen verwendet wird, einschließlich: • Anwendungsprogrammierung; • Betriebssysteme; • unterstützende Werkzeuge; • Firmware. • Anwendungsprogrammierung schließt Programmierung in Hochsprache, Maschinensprache und speziellen Anwendungssprachen ein (z. B.: ladderlogic bei speicherprogrammierbaren Steuerungen). • gilt auch für Änderungen und Erweiterungen an bestehender Software Ralf Pinger / Stefan Gerken

9. 6.2 EN 50128 – Aufbau der Norm • Normativer Textteil • Normative Anhänge A, B • Informativer Anhang C, D Anhang A Auswahl von Methoden und Techniken Normativer Text Kapitel Referenzen (D.nn) Anhang D Anhang B Anhang C Schlüsselrollen und Verantwortlichkeiten Zusammenfassung der Dokumentenkontrolle Informationen zu Methoden / Techniken Ralf Pinger / Stefan Gerken

10. 6.2 EN 50128 – Beispiel 1: Normativer Textteil • 7.2 Software-Anforderungen • 7.2.1 Ziele • 7.2.1.1 Beschreibung eines vollständigen Satzes von Anforderungen an die Software, der alle System- und Sicherheitsanforderungenerfüllt, und einen umfassenden Satz von Dokumenten für jede spätere Phase bereitstellt. • 7.2.1.2 Beschreibung der Gesamtsoftware-Testspezifikation. • 7.2.2 Eingangsdokumente • System-Anforderungsspezifikation … • 7.2.3 Ausgangsdokumente • Software-Anforderungsspezifikation... • 7.2.4 Anforderungen • 7.2.4.1 Eine Software-Anforderungsspezifikation muss unter der Verantwortung des Anforderungsmanagers auf der Grundlage der Eingangsdokumente nach 7.2.2 erstellt werden. Die Anforderungen in 7.2.4.2 bis 7.2.4.15 beziehen sich auf die Software-Anforderungsspezifikation. • 7.2.4.2 Die Software-Anforderungsspezifikation muss die geforderten Eigenschaften der zu entwickelnden Software darstellen. Diese Eigenschaften, die alle in der Normenreihe ISO/IEC 9126 (mit Ausnahme der Sicherheit) definiert sind, müssen einschließen:… • 7.2.4.3 Der Software-Sicherheits-Integritätslevel muss nach der Definition in Abschnitt 4 abgeleitet und in der Software-Anforderungsspezifikation festgehalten werden. Ralf Pinger / Stefan Gerken

11. 6.2 EN 50128 – SIL • SILheißt Sicherheitsanforderungsstufe • 5 SIL-Stufen • 0 = nichtsichere Anwendungen • 1 = niedrigste Anforderungsstufe • 4 = höchste Anforderungsstufe • 2 Klassen für sichere Anwendungen • (1,2) und (3,4) • Maßnahmen sind notwendig bei unter-schiedlichen SSAS innerhalb eines Systems Ralf Pinger / Stefan Gerken

12. 6.2 EN 50128 – Beispiel 1 aus Anhang A Ralf Pinger / Stefan Gerken

13. 6.2 EN 50128 – Beispiel 1 aus Anhang D • D.13 Entscheidungstabellen (Wahrheitstabellen) (en: Decision Tables (Truth Tables)) • Ziel Erstellen einer klaren und zusammenhängenden Spezifikation und Analyse komplexer logischer Kombinationen und Beziehungen. Beschreibung Diese verwandten Verfahren benutzen zweidimensionale Tabellen zur Kurzdarstellung logischer Beziehungen zwischen boolschen Programmvariablen. Durch die Kürze und die tabellarische Form eignen sich beide Verfahren zur Analyse komplexer logischer Kombinationen, ausgedrückt in codierter Form. Beide Verfahren können ausführt werden, falls sie als Spezifikation benutzt werden. Ralf Pinger / Stefan Gerken

14. 6.2 EN 50128 – Beispiel 2 aus Anhang A Quelle: EN 50128 Ralf Pinger / Stefan Gerken

15. 6.2 EN 50128 – Beispiel 2 aus Anhang A (Fortsetzung) Quelle: EN 50128 Ralf Pinger / Stefan Gerken

16. 6.2 EN 50128 – Beispiel 2 aus Anhang D Quelle: EN 50128 Ralf Pinger / Stefan Gerken

17. 6.2 EN 50128 – Beispiel 2 aus Anhang D (Fortsetzung) • Fortsetzung D.54 Quelle: EN 50128 Ralf Pinger / Stefan Gerken

18. 6.2 EN 50128 Quelle: EN 50128 Ralf Pinger / Stefan Gerken

19. 6.2 EN 50128 – Prozess Ver Val Phase Ergebnisse Quelle: EN 50128 Ralf Pinger / Stefan Gerken

20. 6.2 EN 50128 – Verifikation und Validierung Verifikation: Untersuchungsprozess mit anschließender, auf Nachweisen beruhender Beurteilung, dass die Ergebnisse (Prozess, Dokumentation, Software oder Anwendung) einer bestimmten Entwicklungsphase die Anforderungen dieser Phase hinsichtlich Vollständigkeit, Richtigkeit und Konsistenz erfüllt DIN EN 50128, März 2012 Wird richtig entwickelt Ist das Richtige entwickelt worden? Validierung: Analyseprozess gefolgt von einer auf Nachweisen beruhenden Beurteilung, ob ein Objekt (z. B. Prozess, Dokumentation, Software oder Anwendung) den Bedarf des Nutzers erfüllt, insbesondere bezüglich Sicherheit und Qualität, sowie mit einem Schwerpunkt auf die betriebliche Eignung für den Verwendungszweck in der vorgesehenen Betriebsumgebung DIN EN 50128, März 2012 Ralf Pinger / Stefan Gerken

21. 6.2 EN 50128 – Dokumente / Ergebnisse • Definitionen / Anforderungen zu den Phasen des Lebenszyklus‘ (Textteil) • Vorgaben von Maßnahmen und Tools (Anhang A) • Vorgaben zu Kompetenzprofilen (Anhang B) • Vorgaben zu Reviews (Verifikation) • Verfolgbarkeit der Anforderungen Ralf Pinger / Stefan Gerken

22. 6.2 EN 50128 – Rollen und Unabhängigkeiten Anerkannter Fachbetrieb: Der Gutachter kann auch der entwickelnden Firma unterstellt sein, wenn eine ausreichende Unabhängigkeit zur entwickelnden Abteilung gewährleistet ist Voraussetzung: Anerkennung durch Zulassungsbehörde wie z.B. EBA Quelle: EN 50128 Ralf Pinger / Stefan Gerken

23. 6.2 EN 50128 – Aufgaben und Rollen Quelle: EN 50128 Ralf Pinger / Stefan Gerken

24. 6.2 EN 50128 – Zusammenfassung • Vorgaben für den Entwicklungsprozess • Festlegung von Maßnahmen und Tools • Anforderungen an Dokumente • Unabhängige Stellen Ralf Pinger / Stefan Gerken

25. 6.3 Anforderungen – Inhaltsübersicht • Inhaltsübersicht • Anforderungsmanagement • Ermittlung von Anforderungen • Rapid Prototyping • Verfolgung von Anforderungen • Identifikation von Anforderungen • Umsetzung von Anforderungen • Nachweis von Anforderungen Ralf Pinger / Stefan Gerken

26. 6.3 Anforderungen – Ziele der EN 50128 • Beschreibung eines vollständigen Satzes von Anforderungen an die Software, der alle System- und Sicherheitsanforderungen erfüllt, und einen umfassenden Satz von Dokumenten für jede spätere Phase bereitstellt. • In dem durch den Software-Sicherheits-Integritätslevel festgelegten Umfang muss die Software-Anforderungsspezifikation so formuliert und strukturiert werden, dass sie vollständig, klar, genau, eindeutig, verifizierbar, testbar, wartbar und umsetzbar ist und auf alle Eingangsdokumente rückverfolgbar. • Beschreibung der Gesamtsoftware-Testspezifikation. Ralf Pinger / Stefan Gerken

27. 6.3.1 Anforderungsmanagement – Motivation • fehlende oder falsche Anforderungen • haben Auswirkungen auf das gesamte Produkt • werden üblicherweise erst bei Inbetriebnahme oder später erkannt • gefährden die erfolgreiche Abnahme des Produkts • können Auswirkungen auf die gesamte Architektur haben •  Änderungen sind entsprechend kostspielig • Anforderungsmanagement • ist eine Managementaufgabe • zielt auf Effizienz • zielt auf Fehlerarmut • ordnet das Chaos Ralf Pinger / Stefan Gerken

28. 6.3.2 Ermittlung von Anforderungen • Ziel der Anforderungsermittlung: • Erkennen der Anforderungen des Kunden • Das bedeutet: • Definition der Systemgrenzen • Definition der Schnittstellen • Definition der zu erbringenden Systemfunktionen • Definition der Umgebungsbedingungen • Definition der zu unterstützenden Kundenprozesse • Definition der gesetzlichen Rahmenbedingungen • Definition der wirtschaftlichen Rahmenbedingungen • … Ralf Pinger / Stefan Gerken

29. 6.3.2 Ermittlung von Anforderungen • Häufige Probleme • Mensch • Sprache (Domäne vs. SW-Experte) • Divergierende Meinungen von Stakeholdern • Motivation zur Unterstützung • Organisationen • Produktstrategie • Verfügbarkeit von Stakeholdern • Fachlicher Inhalt • Kritikalität des Systems • Systemumfang • Unterschiedliche Detaillierung von Anforderungen • Nicht funktionale Anforderungen • Methoden • Und vieles mehr Ralf Pinger / Stefan Gerken

30. 6.3.2 Ermittlung von Anforderungen • Bewertung der Anforderungen: • Korrektheit • Vollständigkeit • Machbarkeit • Bewertung, ob Kundenanforderung • Wichtigkeit • Kosten Ralf Pinger / Stefan Gerken

31. 6.3.3 Rapid Prototyping • Rapid Prototyping • kommt eigentlich aus dem Maschinenbau • beschreibt den schnellen Musterbau • ist als Software Engineering Methode adaptiert worden • wird in Verbindung mit agilen Vorgehensweisen eingesetzt • kann auch zur Anforderungsermittlung eingesetzt werden Ralf Pinger / Stefan Gerken

32. 6.3.3 Rapid Prototyping • Vorteile • ausführbares Anforderungsmodell macht das System „erlebbar“ • Ausführbares Testmodell als Diskussionsgrundlage mit dem Kunden dienen • Anforderungsmodell kann als Testmodell verwendet werden • Nachteile • Anforderungsmodell orientiert sich an einer Spezifikation oder Kundengesprächen • Anforderungsmodell ist nicht architekturgetrieben • Anforderungsmodell erzeugt den Eindruck doppelter Entwicklung Ralf Pinger / Stefan Gerken

33. 6.3.3 Vom Rapid Prototype zum Design-Modell Ralf Pinger / Stefan Gerken

34. Analyse-Modell: schneller Prototyp keine vollständige Durchdringung der Anforderungen notwendig Anforderungsfehler werden frühzeitig offenbart Schnelle Anpassbarkeit an Kundenänderungen (agil) Ausprägungen: Wegwerfprototyp … Refaktorisierung bis zum Produkt Design-Modell: Verständlichkeit/Wartbarkeit Einfache Lösungen entstehen in der Regel nicht im ersten Ansatz! Hohe Durchdringung der Anforderungen notwendig Architektur muss weitgehend bekannt sein Ausprägungen: (Neu-) Entwicklung … Refaktorisiert aus Analyse-Modell 6.3.3 Analyse-/Design-Modell Ralf Pinger / Stefan Gerken

35. 6.3.4 Verfolgung von Anforderungen • Ziele sind Identifikation von: • Verfeinerungen • Realisierungen • Wechselwirkungen • Nachweisen • Nebenwirkungen der Identifikation: • Änderungsauswirkungsanalyse • Regressionstests • Fehleranalyse • Kostenabschätzung für Änderungen Ralf Pinger / Stefan Gerken

36. 6.3.5 Identifikation von Anforderungen • Anforderung bedarf • einer eindeutigen Bezeichnung (z. B. Text, Nummer, Identifikator) • eines vereinbarten Zwecks, z. B. • define • refine • implement • test • safety • RAM • motive • annotation • version • um die Verfolgbarkeit und Nachvollziehbarkeit zu gewährleisten Ralf Pinger / Stefan Gerken

37. 6.3.6 Umsetzung von Anforderungen • Arten der Umsetzung • Artefakte • Modellierung • Programmierung • Dokumente • Verfeinerung der Anforderungen durch neue Anforderungen • Umsetzen nicht-funktionaler Anforderungen durch Prozesse Ralf Pinger / Stefan Gerken

38. 6.3.7 Nachweis von Anforderungen • Zielgruppen: • Kunde • Gutachter • Zulassungsbehörde • Methoden: • Analyse • Sicherheitsnachweise • RAM-Nachweise • Qualitätsnachweise • Test • Testberichte Ralf Pinger / Stefan Gerken

39. 6.4 SW-Entwicklungsmethoden – Inhaltsübersicht • Inhaltsübersicht • Konventionelle Entwicklungsmethoden • Halb-formale Entwicklungsmethoden • Formale Entwicklungsmethoden • Modellbasiertes Software-Engineering Ralf Pinger / Stefan Gerken

40. 6.4 SW-Entwicklungsmethoden – Ziele der EN 50128 • SW-Architektur & SW-Entwurf und Design • Entwickeln einer Software-Architektur • Überprüfen der Anforderungen an die System-Architektur • Feststellen und Bewerten, der Wechselwirkungen zwischen Hardware und Software • Auswahl eines Entwurfsverfahrens • Entwurf und Implementierung von Software • Software, die analysierbar, testbar, verifizierbar und wartbar ist • Auswahl eines für die geforderte Software-Sicherheitsanforderungsstufe angemessenen Satzes von Werkzeugen • Durchführung der Softwareintegration Ralf Pinger / Stefan Gerken

41. 6.4.1 Konventionelle Entwicklungsmethoden – Beispiele • Konventionelle Entwicklungsmethoden • VHIDT – Vom Hirn in die Tastatur • Strukturierte Verfahren (laut EN 50128) • JSD - Jackson System Development • MASCOT - Modular Approach to Software Construction, Operation and Test • SADT - Structured Analysis and Design Technique • SDL • SSADM • Yourdon - Real-time Yourdon • Modulares Vorgehen • Entwurfs- und Codierstandards • Streng typisierte Programmiersprache • Strukturierte Programmierung • Objektorientierte Programmierung Ralf Pinger / Stefan Gerken

42. 6.4.2 Modellierung – Beispiele • Methoden der Modellierung aus der EN 50128 • Datenmodellierung • Datenflussdiagramme • Kontrollflussdiagramme • Endliche Zustandsmaschinen/Zustandsübergangsdiagramme • Zeit-Petri-Netze • Entscheidungs-/Wahrheitstabellen • Formale Methoden • Leistungsmodellierung • Strukturdiagramme • Ablaufdiagramme Ralf Pinger / Stefan Gerken

43. 6.4.3 Formale Entwicklungsmethoden – Beispiele • Formale Entwicklungsmethoden aus der EN 50128 • CSP - Communicating Sequential Processes • CCS - Calculus of Communicating Systems • HOL - Higher Order Logic • LOTOS - Language for Temporal Ordering Specification • OBJ – ist eine algebraische Spezifikationssprache • Temporal Logic • VDM - Vienna Development Method • Z • B • Model Checking Ralf Pinger / Stefan Gerken

44. 6.4.4 Modellbasiertes Software-Engineering – Ursprünge • Erste Ansätze in den 80er Jahren mit den CASE-Tools • Modellierungselemente waren: SA/SD • Es gab viele Erfolge mit CASE-Tools • Qualitätsverbesserung • Bessere Beherrschung der Komplexität • Mehr Abstraktion  mehr Plattformunabhängigkeit • Die CASE-Tools hatten aber auch noch einige Unzulänglichkeiten • Roundtrip-Engineering nicht möglich • Formale Verifikation noch nicht ausgereift • Tool-Entwicklung war nicht fortschrittlich genug • Modellelemente waren für viele Probleme nicht ausreichend Ralf Pinger / Stefan Gerken

45. 6.4.4 Modellbasiertes Software-Engineering – Erläuterung • Modellbasierte Entwicklung definiert: • n Hierarchieebenen • auf jeder Ebene eine (formale, domänenspezifische) abstrakte Sprache • Transformationen zwischen den Hierarchieebenen • möglichst weitgehende Automatisierung der Transformationen Ralf Pinger / Stefan Gerken

46. 6.4.4 Modellbasiertes Software-Engineering • 29 .text • 30 0027 90 .p2align 2,,3 • 31 .globl main • 32 .type main,@function • 33 main: • 34 0028 55 pushl %ebp • 35 0029 89E5 movl %esp, %ebp • 36 002b 83EC08 subl $8, %esp • 37 002e 83E4F0 andl $-16, %esp • 38 0031 83EC0C subl $12, %esp • 39 0034 680E0000 pushl $.LC1 39 00 • 40 0039 C7050000 movl $3, a 40 00000300 • 41 0043 E8FCFFFF call puts 41 FF • 42 0048 C7042404 movl $4, (%esp) Ralf Pinger / Stefan Gerken

47. 6.4.4 Modellbasiertes Software-Engineering • void Step(void) { • input.AktuelleZeit.timeX = GetTickCount() - starttime;tbl_display.hour = timeinfo->tm_hour;tbl_display.min = timeinfo->tm_min; • if ((stepcount > 1000) && (output.StarteDailyTest)) { • input.DailyTestResult.vorhanden = kcg_true; input.DailyTestResult.Result = DT_ok_TBL1p_Types; • } • writeSSS(&input); • do{ stepcount = stepcount + 1; TBL1p_MainMixer(&input, &output); output2display();} while(!output.HabeFertig); • } Ralf Pinger / Stefan Gerken

48. 6.4.4 Modellbasiertes Software-Engineering Ralf Pinger / Stefan Gerken

49. 6.4.4 Modellbasiertes Software-Engineering – Motivation • Logisch funktionale Inhalte auf hoher Abstraktionsebene • Unabhängig von konkreter Hardwareplattform  lange Produktlebenszyklen • Effizienzsteigerung in der Entwicklung • Frühzeitige Fehleroffenbarung • stärkere Verknüpfung von Implementierung und Dokumentation • Qualitätssteigerung • Einsatz von Analysewerkzeugen (z. B. Model Checker)  Nachweis von Eigenschaften • Unterstützung der Zertifizierung von Systemen Ralf Pinger / Stefan Gerken

50. 6.4.4 Modellbasiertes Software-Engineering – Abgrenzung • Eigenschaften der modellbasierten Entwicklung (1) • Verwendung von Modellen zur Softwareentwicklung um die Abstraktion zu erhöhen • Verwendung von Generatoren/Transformatoren bei der Softwareentwicklung • Auch teilweise Automatisierung möglich (je nach fachlicher Anforderung zwischen 20% und 100%) • Die erste Abstraktionsebene wird vollständig manuell erzeugt • Ziel ist die Steigerung der Softwarequalität bzw. -effizienz • Schlagwort „Automation durch Formalisierung“ in frühen Entwicklungsphasen • Definitionen MDA, MDSD, MDSE nicht einheitlich und weichen je nach Literaturquelle voneinander ab Ralf Pinger / Stefan Gerken