Software in sicherheitsrelevanten Systemen

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

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 Ralf Pinger / Stefan Gerken

6. 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

7. 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

8. 6.2 EN 50128 – aktueller Stand der Normung • Aktuell EN 50128 06/2011 veröffentlicht • Die Überarbeitung der EN 50126 ist in Vorbereitung • Die neue EN 50126 soll die EN 50128 als eigenen Teil enthalten Ralf Pinger / Stefan Gerken

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

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

11. 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

12. 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

13. 6.2 EN 50128 – SSAS • SSAS heiß Softwaresicherheitsanforderungsstufe (SIL) • SSAS = SIL der Systemfunktionen • 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

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

15. 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

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

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

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

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

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

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

22. 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

23. 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

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

25. 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

26. 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

27. 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

28. 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

29. 6.3.1 Anforderungsmanagement • Management etymologisch: • manage • 1560s, probably from Italian maneggiare "to handle," especially "to control a horse," from Latin manus "hand". Influenced by French manège "horsemanship" (earliest English sense was of handling horses), which also was from the Italian. Extended to other objects or business from 1570s. Slang sense of "get by" first recorded 1650s. • management • 1598, "act of managing," from manage. Meaning "governing body" (originally of a theater) is from 1739. Manager is 1588 in the sense of "one who manages;" specific sense of "one who conducts a house of business or public institution" is from 1705. Quelle: http://www.etymonline.com Ralf Pinger / Stefan Gerken

30. 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

31. 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

32. 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

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

34. 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

35. 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

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

37. 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

38. 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

39. 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

40. 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

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

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

43. 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

44. 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

45. 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

46. 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

47. 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

48. 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

49. 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

50. 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