Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Sommersemester 2009SW in sicherheitsrelevanten Systemen Software in sicherheitsrelevanten Systemen Ralf Pinger Sommersemester 2009.

Ähnliche Präsentationen


Präsentation zum Thema: "Sommersemester 2009SW in sicherheitsrelevanten Systemen Software in sicherheitsrelevanten Systemen Ralf Pinger Sommersemester 2009."—  Präsentation transkript:

1

2 Sommersemester 2009SW in sicherheitsrelevanten Systemen Software in sicherheitsrelevanten Systemen Ralf Pinger Sommersemester 2009

3 SW in sicherheitsrelevanten Systemen Organisatorisches Stundenzahl: 2V + 1Ü Vorlesung: Do. 08: :30 Uhr in IZ 161 –Do, –Do, –Do, –Blockveranstaltung Exkursionswoche –Do, –Do, –Do, –Do, Block: VL + UE vom – (Ex-Woche): –Di :8: :00 –Mi : 8: :00 –Do :8: :00 –Fr :8: :30 –Inhalt: praktischer Umgang mit SCADE –Schulung erfolgt durch Esterel Sprechstunde: nach Vereinbarung Prüfung: nach Vereinbarung Kontakt:

4 Sommersemester 2009SW in sicherheitsrelevanten Systemen Inhalt 1.Motivation 2.RAMS/Normen 3.SCADE/modellbasierte Entwicklung 4.Qualifizierung von Entwicklungswerkzeugen

5 Sommersemester 2009SW in sicherheitsrelevanten Systemen 1. Motivation Zusammenstoß zweier S-Bahnen im Bahnhof Flughafen Hannover-Langenhagen,

6 Sommersemester 2009SW in sicherheitsrelevanten Systemen Signal übermittelt Erlaubnis zur Einfahrt übermittelt erlaubte Geschwindigkeit

7 Sommersemester 2009SW in sicherheitsrelevanten Systemen Weiche

8 Sommersemester 2009SW in sicherheitsrelevanten Systemen PZB – Indusi Punktförmige Zugbeeinflussung - PZB (induktive Zugsicherung) Vermeidung von Gefährdungen und Unfällen durch Zwangsbremsung Übertragung der Signalstellung an der Strecke auf das Fahrzeug punktförmig, da nur an bestimmten Punkten eine Beeinflussung stattfinden kann PZB lediglich Unterstützung des Fahrers

9 Sommersemester 2009SW in sicherheitsrelevanten Systemen Funktionen der PZB/Indusi Die Wachsamkeitsprüfung überwacht, dass der Triebfahrzeugführer (Tf) beim Passieren eines Halt ankündenden Signals die Aufnahme des Signalbegriffs durch eine Tastenbedienung bestätigt. Die Bremswegüberwachung überwacht den Bremsvorgang vor einem Halt zeigenden Signal. Dies erfolgt fahrzeugseitig durch diskrete Prüfpunkte (bei Altsystemen) oder kontinuierliche Überwachungskurven. Die Fahrsperre löst beim Passieren eines Halt zeigenden Signals eine Zwangsbremsung aus.

10 Sommersemester 2009SW in sicherheitsrelevanten Systemen Übertragungsprinzip Indusi

11 Sommersemester 2009SW in sicherheitsrelevanten Systemen Sicherungsstufen PZB/Indusi 500-Hz-Magnete 250 bis 150 m vor Hauptsignalen, die besondere Gefahrenpunkte decken. -> falls zu schnell dann Zwangsbremsung (ZB) 1000-Hz-Magnet am Vorsignal bzw. Überwachungssignal eines Bahnübergangs -> Wachsamkeitstaste innerhalb 4 s, sonst ZB -> falls zu schnell dann ZB 2000-Hz-Magnet am Hauptsignal -> immer ZB

12 Sommersemester 2009SW in sicherheitsrelevanten Systemen Französische Alternative zur Indusi Krokodil (1920er Jahre) Signalbegriff wird als positive oder negative Spannung dargestellt (+/- 20 V)

13 Sommersemester 2009SW in sicherheitsrelevanten Systemen Alternativen zur Indusi Eurobalisen komplexere Datenübertragung möglich (mehrere Bytes)

14 Sommersemester 2009SW in sicherheitsrelevanten Systemen Live-Demo Zugsicherung (am Beispiel der belgischen Bahn)

15 Sommersemester 2009SW in sicherheitsrelevanten Systemen Randbedingungen 5711 stand ab 09:53 Uhr abfahrbereit vor Ausfahrsignal, geplante Abfahrt 10:10 Uhr 5712 hat 7 Minuten Verspätung, erwartete Ankunftszeit 10:11 Uhr 5712 erhält Erlaubnis zur Einfahrt in Bahnhof 5711 steht vor Halt zeigendem Signal!

16 Sommersemester 2009SW in sicherheitsrelevanten Systemen Ausgangssituation

17 Sommersemester 2009SW in sicherheitsrelevanten Systemen Was ist passiert? 5711 startet um 10:10 Uhr Ausfahrsignal für 5711 stand auf Halt Indusi erzeugt Zwangsbremsung für 5711 Tf von 5711 drückt Freitaste und fährt wieder los! 5711 fährt die Einfahrweiche auf 5712 war zu diesem Zeitpunkt schon an seinem Einfahrsignal vorbei -> keine ZB mehr möglich! Noch im Tunnel stoßen 5711 und 5712 frontal zusammen!

18 Sommersemester 2009SW in sicherheitsrelevanten Systemen Unfallfolgen 16 Personen verletzt DM Sachschaden Wiederinbetriebnahme der Strecke erst am , 04:00 Uhr, einen Tag später

19 Sommersemester 2009SW in sicherheitsrelevanten Systemen Fazit keine kausale Beteiligung technischer Komponenten/Einrichtungen 5711 erhielt Zwangsbremsung Ursache: unerlaubte Weiterfahrt von 5711 Auszug aus Regelwerk: Ist ein Zug an einem Halt zeigenden Hauptsignal (...) unzulässig vorbeigefahren, ist nach dem Anhalten der Fahrdienstleiter sofort zu verständigen. Dies gilt auch bei einer Zwangsbremsung durch PZB an einem Hauptsignal (...), das eine Fahrtstellung (...) zeigt. Menschliches Versagen als Ursache

20 Sommersemester 2009SW in sicherheitsrelevanten Systemen Fazit 2 System hat die Fehlhandlung des Triebfahrzeugführers erkannt und hat eingegriffen nach erfolgter technischer Reaktion übernimmt der Mensch wieder die Verantwortung! offenbar hat der Mensch die Zwangsbremsung nicht dem Hauptsignal zugeordnet!

21 Sommersemester 2009SW in sicherheitsrelevanten Systemen Gründe für Zwangsbremsung Indusi am Halt-Signal (Indusi) Sicherheitsfahrschalter (Sifa) – Totmannknopf Zurückrollen des Zuges Störung im Fahrzeuggerät Zwangsbremsung unbekannter Ursache

22 Sommersemester 2009SW in sicherheitsrelevanten Systemen menschliches Versagen? Ist das menschliche Versagen vorprogrammiert? 22 aktenkundige Fälle zwischen 1994 und 2000: Tf fährt nach Zwangsbremsung durch Indusi unerlaubt weiter! Forderung nach optischer Signalisierung bei ZB durch Indusi Systeme müssen von Menschen beherrscht werden können!

23 Sommersemester 2009SW in sicherheitsrelevanten Systemen

24 Sommersemester 2009SW in sicherheitsrelevanten Systemen zweites Beispiel – Genthin : D10 Berlin – Köln fährt in Brandenburg Reichsbahn mit 12 Minuten Verspätung ab (viele Reisende, lange Zeit für Aus- und Einsteigen) D10 muss bei Kade halten, da sich im Abschnitt davor (Genthin) noch der Militärzug 176 befindet D10 hat damit 27 Minuten Verspätung

25 Sommersemester 2009SW in sicherheitsrelevanten Systemen Unglück von Genthin D 180 Berlin Neunkirchen (Saar) folgt D10 D 180 lief auf und wurde mehrfach gestutzt (Vorsignal auf Halt, Hauptsignal dann aber auf Fahrt) Lokführer von D 180 übersieht im Nebel Halt zeigendes Vorsignal und Hauptsignal bei Belicke Fahrdienstleiter gibt Haltsignale und benachrichtigt Schrankenbude 89 und Stellwerkswärter in Genthin Ost

26 Sommersemester 2009SW in sicherheitsrelevanten Systemen Fahrt nach Genthin D 180 sieht nun nur noch Fahrt-Signale – die von D 10! Wärter in Schrankenbude 89 schwenkt Kreiselsignal (Halt), Knallkapseln konnte er nicht mehr auslegen Lokführer sieht den Wärter nicht, da dieser zu tief steht Wärter in Genthin Ost könnte D 180 noch stoppen – er hat höhere Position

27 Sommersemester 2009SW in sicherheitsrelevanten Systemen In Genthin Ost Stellwerkswärter reagiert überstürzt auf Meldung vom Blockwärter Belicke Gibt Schutzhaltesignal mit elektrischer Signallampe (kreisförmig schwingend) Er vergisst die Signale auf Halt zu stellen D 10 sieht die Warnlampe, die für D 180 bestimmt war D 10 leitet Schnellbremsung ein D 180 hat Fahrt-frei nach Genthin (von D10)

28 Sommersemester 2009SW in sicherheitsrelevanten Systemen Unfall Folgen D 180 fährt mit 100 km/h auf den im Bahnhof stehenden D 10 auf 186 Menschen sterben 106 Menschen verletzt Größte Eisenbahnkatastrophe in Deutschland weiterer Unfall in derselben Nacht mit 101 Toten, 28 Verletzten)

29 Sommersemester 2009SW in sicherheitsrelevanten Systemen Ursachen menschliches Versagen des Lokführers von D 180 (Halt-Signal übersehen) menschliches Versagen des Stellwerkwärter Genthin Ost – Verwechselung von D 10 mit D 180, keine Signal-Halt-Stellung Kette von menschlichen Fehlleistungen führte zum Unfall

30 Sommersemester 2009SW in sicherheitsrelevanten Systemen Ursachen 2 Indusi bereits in den 20er Jahren erprobt 1939 war die Indusi schon weit verbreitet Strecke war mit Indusi-Spulen ausgestattet Einrichtung an der Lok von D 180 fehlte, da zur Reparatur! Aufgrund von Lokmangel (Kriegszeiten) wurde die Lok trotzdem eingesetzt! menschliches Versagen? Zwangsbremsung hätte Zugunglück verhindert! Lokführer bekam 3 Jahre Gefängnis!

31 Sommersemester 2009SW in sicherheitsrelevanten Systemen Einfluss von Software auf Unfälle reine Software-Fehler können ebenfalls Ursachen für Katastrophen sein Beispielsweise Fehlfunktion im Fahrzeuggerät -> keine Bremsung Funktioniert die Software beim automatischen Fahren? Kann man überlappende Fahrstraßen im Stellwerk einstellen?

32 Sommersemester 2009SW in sicherheitsrelevanten Systemen Beispiele für SW-Fehlverhalten Kincardine in Ontario, Kanada, Schwerer Reaktorunfall 1990 ausgelöst durch einen Softwarefehler: Beim Austausch eines abgebrannten Brennelementes geriet die computer-gesteuerte Umlademaschine in einen unkontrollierten Zustand. Als sie sich 40 cm über dem Schachtdeckel befand, wurden durch einen falschen Befehl im Code des Computers, der die Umlademaschine kontrollierte, zugleich alle 4 Bremsen des Hebezuges gelöst und das schwere Gerät fiel auf die Schachtabdeckung. Die Folge war der Austritt von I hoch-radioaktivem schweren Wasser aus dem Leck, das in den Brennstoff- behälter geschlagen worden war.

33 Sommersemester 2009SW in sicherheitsrelevanten Systemen Beispiele für SW-Fehlverhalten Thule, Grönland, 1960 In der US-Frühwarnstation wird höchste Alarmstufe ausgelöst. Durch einen Computerfehler wurde der Mondaufgang als "Nuklearangriff" gewertet. Ähnliche Fehler waren in der Folgezeit des Öfteren die Ursache für die Menschheit bedrohende Fehlalarme (in einem Fall wurden Wildgänse als einfliegende Formationen von Atomsprengköpfen missdeutet).

34 Sommersemester 2009SW in sicherheitsrelevanten Systemen Beispiele für SW-Fehlverhalten Die Objektiv-Linsen der Weltraum- sonde "Hubble" wichen nach einem computergesteuerten Schliff um einige zehntel Millimeter von der optimalen Krümmung ab. Der Fehler lag in der Programmierung der Schleifmaschine. Das Teleskop war daher nach dem Start in den Weltraum nur sehr einge- schränkt zu gebrauchen, lieferte zum großen Teil unscharfe Bilder. Ihm musste in einer Rettungsaktion, die Unsummen verschlang, im Weltraum eine 'Brille' verpasst werden, um die optimale scharfe Leistung wiederzugewinnen. Nur so konnte der Erfolg des gesamten Systems noch gerettet werden.

35 Sommersemester 2009SW in sicherheitsrelevanten Systemen Software für sicherheitsrelevante Systeme Wie entwickelt man Software, die in sicherheitsrelevanten Systemen ausgeführt wird? Nicht Inhalt dieser VL: –Entwicklung der Hardware –Entwurf sicherheitsrelevanter Betriebskonzepte

36 Sommersemester 2009SW in sicherheitsrelevanten Systemen Definition System Ein Beispiel: system: set of sub-systems or elements which interact according to a design sub-system: portion of a system which fulfils a specialised function. function: A mode of action or activity by which a product fulfils its purpose. element: a part of a product that has been determined to be a basic unit or building block. An element may be simple or complex. Problem: Die Definition von Begriffen wie System oder Funktion ist willkürlich,... und wahrscheinlich wird niemals eine universelle Definition gelingen.

37 Sommersemester 2009SW in sicherheitsrelevanten Systemen Definition System Aber: Die Hauptaufgabe ist die Entwicklung hinreichend gefährdungsfreier Produkte. Die Sicherheit sollte nicht davon abhängen, ob eine Funktion von einem System oder Element erbracht wird. Der Benutzer muss das zu betrachtende System klar und eindeutig definieren.

38 Sommersemester 2009SW in sicherheitsrelevanten Systemen Definition System Ein (Sub-)System zeichnet sich dadurch aus, dass es sich von der Umgebung abgrenzen lässt (also Systemgrenze und Schnittstellen bekannt sind), und dass es eine wohldefinierte (beabsichtigte) Funktion erbringen soll

39 Sommersemester 2009SW in sicherheitsrelevanten Systemen Definition System

40 Sommersemester 2009SW in sicherheitsrelevanten Systemen Checkliste: Ist die Systemgrenze klar definiert? Sind an der Systemgrenze die Schnittstellen definiert? Sind die Ein- und Ausgaben auf diesen Schnittstellen definiert? Ist die Aufgabe, die das System erfüllen soll, klar definiert? Sind die Einsatzszenarien bekannt und dokumentiert? Ist die Systemstruktur bzw. Systemarchitektur dargestellt? Sind die einzelnen Architekturelemente definiert? Ist ihr Zusammenwirken eindeutig definiert? Definition System

41 Sommersemester 2009SW in sicherheitsrelevanten Systemen SCADE-Schulung Zeit: , 9:00 Uhr – 17:00 Uhr Ort: Siemens AG, Ackerstraße 22 Raum: Gebäude 37, Raum bitte melden beim Eingang Ost, der Raum ist im Erdgeschoss rechts den Gang hinunter und dann auf der linken Seite

42 Sommersemester 2009SW in sicherheitsrelevanten Systemen Lageplan Siemens AG

43 Sommersemester 2009SW in sicherheitsrelevanten Systemen Definition RAMSS

44 Sommersemester 2009SW in sicherheitsrelevanten Systemen Zusammenhang zwischen RAM, S und S

45 Sommersemester 2009SW in sicherheitsrelevanten Systemen Definitionen von Sicherheit Sicherheit nach Mü8004: Die Fähigkeit einer Sicherungsanlage, bei bestimmungsgemäßem Einsatz, ordnungsgemäßer Instandhaltung und vorschriftsmäßiger Handhabung während einer vorgegebenen Brauchbarkeitsdauer Gefährdungen durch Funktionsversagen in dem Umfang, der nach dem Stand der Technik erforderlich ist, auch dann zu verhindern, wenn Bauelementeausfälle und Störungen in der zu Beanspruchungsbeginn als fehlerfrei angesehenen Sicherungsanlage eintreten. D. h. eine Anlage ist (im Sinne der Mü8004) sicher oder nicht. Sicherheit nach CENELEC: Freiheit von nicht akzeptierten Risiken.

46 Sommersemester 2009SW in sicherheitsrelevanten Systemen MILITARY-STANDARD m MIL-STD-882 m System Safety: The application of engineering and management principles, criteria, and techniques to optimize all aspects of safety within the constraints of operational effectiveness, time, and cost throughout all phases of the system life cycle. m Software System Safety Handbook (MIL-STD) m Purpose: Provide management and engineering guidelines to achieve a reasonable level of assurance that software will execute within the system context with an acceptable level of safety risk.

47 Sommersemester 2009SW in sicherheitsrelevanten Systemen Sicherheit: Probleme Wie sicher sind die Komponenten bzw. Anlagen? Wie sicher müssen die Komponenten bzw. Anlagen sein? Wie kann die Sicherheit glaubhaft gemacht werden? Warum ist die eingesetzte SW/HW frei von systematischen Fehlern?

48 Sommersemester 2009SW in sicherheitsrelevanten Systemen Was bedeutet RAMSS für Eisenbahnsignaltechnik? Zwingend notwendige Produkteigenschaften, ohne Nachweis sind die Produkte nicht marktfähig Funktionsversagen kann katastrophale Folgen haben (Unfälle) Mangelnde Verfügbarkeit wird pönalisiert Das behauptete Sicherheitsniveau ist weder durch Gebrauch noch Test positiv nachweisbar Security wird bisher als Problem unterschätzt

49 Sommersemester 2009SW in sicherheitsrelevanten Systemen Klassifikation von Fehlern Zufällige Fehler –Hardwarefehler als Folge von Alterung –Verschleiß –ausgefallene Transistoren Systematische Fehler –mangelhafter Entwurf –Programmierfehler –mangelhafte Auslegung der Hardware Unterscheidung –systematische Fehler treten nach Beseitigung nicht mehr auf –zufällige Fehler können sich jederzeit wiederholen Übergang kann fließend sein: Unterdimensionierter Kühlkörper eines Transistors

50 Sommersemester 2009SW in sicherheitsrelevanten Systemen Klassifikation von Fehlern 2 Hardware: zufällige und systematische Fehler Software: nur systematische Fehler möglich! In dieser VL: Entwicklung von Software, die für die Ausführung auf einer Hardware gedacht ist, die sich für die Ausführung von Sicherheits-Funktionen eignet. geeignete Hardware: Erkennen von zufälligen Fehlern! Anschließend: Sicheren Zustand einnehmen

51 Sommersemester 2009SW in sicherheitsrelevanten Systemen Rechnerarchitektur 1oo1D

52 Sommersemester 2009SW in sicherheitsrelevanten Systemen Eigenschaften von 1oo1D Diagnosekomponente ist eine Selbstprüfung Falls ein Fehler erkannt wird, erfolgt die Ausführung einer Sicherheitsfunktion (z. B. Abschalten, eingeschränkte Funktion, etc) Fehlerhafte Ausgaben werden nicht sofort unwirksam (Diagnose muss erst arbeiten!) Gemeinsame HW für Haupt- und Prüfprogramm: Was passiert wenn beide gleichermaßen versagen? Common Cause (gleiche Ursache für denselben Fehler) Überprüfung kann auch auf evtl. vorhanden Ausgabebaugruppen verlagert werden Geringe Kosten der HW

53 Sommersemester 2009SW in sicherheitsrelevanten Systemen Rechnerarchitektur 1oo2

54 Sommersemester 2009SW in sicherheitsrelevanten Systemen Eigenschaften von 1oo2 Verdoppelung der HW zufälliger Fehler einer HW-Komponente kann erkannt werden fehlerhafte Ausgaben werden unterdrückt Sicherheitsfunktion muss bei Abweichung ausgeführt werden Kanäle müssen synchron gehalten werden Reduktion von common cause Fehlern

55 Sommersemester 2009SW in sicherheitsrelevanten Systemen Rechnerarchitektur 2oo2

56 Sommersemester 2009SW in sicherheitsrelevanten Systemen Eigenschaften von 2oo2 ähnlich 1oo2 fehlerhafte Ausgaben werden unterdrückt Sicherheitsfunktion wird erst beim Erkennen eines Fehlers in beiden Vergleichern ausgeführt! Weiterlaufen mit einem Kanal theoretisch möglich Es kann nicht erkannt werden, welcher Kanal den Fehler hat! Warnung notwendig, da nicht klar ob mit fehlerhaften Daten gearbeitet wird Kanäle müssen synchron gehalten werden Reduktion von common cause Fehlern

57 Sommersemester 2009SW in sicherheitsrelevanten Systemen Rechnerarchitektur 1oo2D

58 Sommersemester 2009SW in sicherheitsrelevanten Systemen Eigenschaften von 1oo2D Verdoppelung von 1oo1D Erkennen des fehlerhaften Kanals unter Einschränkungen von 1oo1D fehlerhafte Ausgaben werden unterdrückt fehlerhaften Kanal abschalten, weiterarbeiten nach erstem Fehler möglich Kanäle müssen synchron gehalten werden

59 Sommersemester 2009SW in sicherheitsrelevanten Systemen Rechnerarchitektur 2oo3

60 Sommersemester 2009SW in sicherheitsrelevanten Systemen Eigenschaften von 2oo3 Verdreifachung der HW Fehlerhafter Kanal kann erkannt werden Weiterarbeiten nach erstem Fehler möglich Synchronisation noch schwieriger

61 Sommersemester 2009SW in sicherheitsrelevanten Systemen Rechnerarchitektur XooY genannten Prinzipien sind nur Beispiele und können beliebig erweitert bzw. verändert werden Notwendigkeit der einzusetzenden Architektur sollte aus einer Risiko-Analyse abgeleitet werden Vollständige Zweikanaligkeit verringert common cause Ausfälle Hohes Maß an Ausfalloffenbarung durch Zwei- bzw. Mehrkanaligkeit möglich Durch HW-Vergleicher extrem schnelle Ausfalloffenbarung möglich Durch Symmetrie und HW-Synchronisation sieht der Programmierer in der Regel nur einen Kanal Unabhängiges Abschalten durch Vergleicher möglich Natürlich können auch die Übertragungsmedien mehrkanalig ausgelegt werden!

62 Sommersemester 2009SW in sicherheitsrelevanten Systemen Allgemeines zu Mehrkanaligkeit Probleme: –Enge Synchronisation und dichte Nachbarschaft der Kanäle machen das System empfindlich für common cause Einflüsse: – Einflüsse über die Peripherie – Einflüsse über die Stromversorgung – Elektromagnetische Felder – Temperatur (von außen, aber auch durch Nachbarkanal) Gegenmaßnahmen –Sichere Trennung der Peripherie vom Rechnerkern –Hoch überwachte Stromversorgung –Hochwirksame Schirmung

63 Sommersemester 2009SW in sicherheitsrelevanten Systemen Definition Software Intellektuelle Schöpfung, die Programme, Verfahren, Regeln und alle dazugehörige Dokumentation umfasst, die zum Betrieb eines Systems gehören. Anmerkung: Software ist unabhängig vom verwendeten Transportmedium englische Übersetzung intellectual creation comprising the programs, procedures, rules and any associated documentation pertaining to the operation of a system. NOTE: Software is independent of the media used for transport m Quelle: EN 50128

64 Sommersemester 2009SW in sicherheitsrelevanten Systemen Fehler in Software Software hat keine zufälligen Fehler, nur systematische Fehler! Gibt es nichttriviale fehlerfreie Software? RAMS-Eigenschaften von Software sind nicht quantifizierbar! -> im Gegensatz zu Hardware

65 Sommersemester 2009SW in sicherheitsrelevanten Systemen Fishbone Analysis zur Identifikation von Gründen für Softwarefehler Quelle: A Software Fault Prevention Approach in Coding and Root Cause Analysis Weider D. Yu

66 Sommersemester 2009SW in sicherheitsrelevanten Systemen CENELEC nach Da es nicht möglich ist, die Sicherheit gegen systematische Fehler mit quantitativen Methoden zu bestimmen, werden Sicherheitsanforderungsstufen verwendet, innerhalb derer Methoden, Werkzeuge und Techniken gruppiert werden, die – wenn sie richtig angewendet werden – ein angemessenes Maß an Vertrauen in die Realisierung eines Systems liefern, das die vorgegebene Sicherheitsanforderungsstufe erfüllt.

67 Sommersemester 2009SW in sicherheitsrelevanten Systemen Sicherheitsanforderungsstufen für Software (SSAS) q SSAS = SIL der Systemfunktionen m 5 SIL-Stufen Þ 0 = nichtsichere Anwendungen Þ 1 = niedrigste Anforderungsstufe Þ 4 = höchste Anforderungsstufe m 2 Klassen für sichere Anwendungen à (1,2) und (3,4) q Maßnahmen sind notwendig bei unterschiedlichen SSAS innerhalb eines Systems

68 Sommersemester 2009SW in sicherheitsrelevanten Systemen Software und Sicherheit SW-Anforderungen SW Architektur und Design SW Implementierung und Test SW-Abnahme / Zulassung

69 Sommersemester 2009SW in sicherheitsrelevanten Systemen Eingliederung der EN50128 CENELEC-Normen Eisenbahnsystem Eisenbahnsignalsystem Teilsystem Software EN EN EN EN 50128

70 Sommersemester 2009SW in sicherheitsrelevanten Systemen Anwendungsbereich Verfahren und technische Anforderungen für die Entwicklung gesamter Bereich der Sicherheitsanwendungen gilt für jegliche Software, die bei der Entwicklung und Realisierung von 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.: ladder logic bei speicherprogrammierbaren Steuerungen). gilt nicht rückwirkend (Ausnahme Wartung bei umfangreichen Änderungen)

71 Sommersemester 2009SW in sicherheitsrelevanten Systemen Aufbau der Norm q Normativer Textteil q Normativer Anhang A q Informativer Anhang B Normativer Text Anhang B Anhang A Auswahllisten zu Methoden, Maßnahmen und Tools Informationen zu Methoden und Tools Kapitel Referenzen (B.nn)

72 Sommersemester 2009SW in sicherheitsrelevanten Systemen Beispiel 1: Normativer Textteil 8 Software-Anforderungsspezifikation 8.1Ziele 8.1.1Beschreiben eines Dokumentes, das einen vollständigen Satz von Anforderungen an die Software definiert, der alle Systemanforderungen in dem durch die Software-Sicherheitsanforderungsstufe festgelegten Umfang erfüllt. Es soll ein derart umfassendes Dokument für jeden Software-Ingenieur sein, daß es für ihn nicht erforderlich ist, zum Thema Anforderungen in irgendeinem anderen Dokument nachzusehen Beschreibung der Software-Anforderungstestspezifikation. 8.2Eingangsdokumente 1)System-Anforderungsspezifikation Ausgangsdokumente 1)Software-Anforderungsspezifikation 2)Software-Anforderungstestspezifikation 8.4Anforderungen 8.4.1Die Software-Anforderungsspezifikation muß die erforderlichen Eigenschaften der zu entwickelnden Software zum Ausdruck bringen und nicht die Verfahren, sie zu entwickeln. Diese Eigenschaften, die alle (außer der Sicherheit) in ISO/IEC 9126 definiert sind, müssen einschließen:...

73 Sommersemester 2009SW in sicherheitsrelevanten Systemen Beispiel 1 aus Anhang A

74 Sommersemester 2009SW in sicherheitsrelevanten Systemen Beispiel 1 aus Anhang B B.14Entscheidungstabellen (Wahrheitstabellen) (en: Decision Tables (Truth Tables)) (zu Abschnitt 14 und D.7) 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 booleschen 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.

75 Sommersemester 2009SW in sicherheitsrelevanten Systemen Beispiel 2 aus Anhang A

76 Sommersemester 2009SW in sicherheitsrelevanten Systemen Beispiel 2 aus Anhang A (Fortsetzung)

77 Sommersemester 2009SW in sicherheitsrelevanten Systemen Beispiel 2 aus Anhang A (Fortsetzung)

78 Sommersemester 2009SW in sicherheitsrelevanten Systemen Beispiel 2 aus Anhang A (Fortsetzung)

79 Sommersemester 2009SW in sicherheitsrelevanten Systemen Prozeß Ergebnisse Phase Ver Val

80 Sommersemester 2009SW in sicherheitsrelevanten Systemen Prozeß Ergebnisse Phase Ver Val System-Anforderungsspezifikation System-Sicherheitsanforderungsspezifikation System-Architekturbeschreibung System-Sicherheitsplan Software- Anforderungsspezifikationphase Software-Anforderungsspezifikation Software-Anforderungstestspezifikation Software- Anforderungsverifikationsbericht Software-Planungsphase Software-Entwicklungsplan Software-Qualitätssicherungsplan Software-Konfigurationsmgm.-Plan Software-Verifikationsplan Software-Integrationsplan Software/Hardware-Integrationsplan Software-Validationsplan Software-Wartungsplan Software Architektur & Entwurfsphase Software-Architekturspezifikation Software-Entwurfsspezifikation Software-Entwurfstestspezifikation _______________________________________________ Software-Architektur und -Entwurfsverifikationsbericht Software-Modulentwufsphase Software-Modulentwufsspezifikation Software-Modultestspezifikation _______________________________ Software-Modulverifikationsbericht Software-Modultestphase ______________________ Software-Modultestbericht Software-Integrationsphase ____________________________ Software-Integrationstestbericht Software/Hardware-Integrationsphase ______________________________________ Software/Hardware-Integrationstestbericht Software-Validierung _________________________ Software-Validationsbericht Software-Begutachtungsphase _______________________________ Software-Gutachten Software-Wartungsphase ___________________________________ Software-Wartungsaufzeichnungen Software-Wartungsprotokoll

81 Sommersemester 2009SW in sicherheitsrelevanten Systemen Prozeß Ergebnisse Phase Ver Val

82 Sommersemester 2009SW in sicherheitsrelevanten Systemen Dokumente / Ergebnisse m Definitionen / Anforderungen zu den Phasen des Lebenszyklus (Textteil) m Vorgaben von Maßnahmen und Tools (Anhang A) m Vorgaben zu Reviews (Verifikation) m Verfolgbarkeit der Anforderungen

83 Sommersemester 2009SW in sicherheitsrelevanten Systemen 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

84 Sommersemester 2009SW in sicherheitsrelevanten Systemen Aufgaben und Rollen

85 Sommersemester 2009SW in sicherheitsrelevanten Systemen Verifikation und Validation Verifikation: Analyse und Testen um festzustellen, ob das Ausgangsprodukt jeder Phase des Lebenszyklus die Anforderungen aus der vorhergehenden Phase erfüllt. Draft EN50128, Feb Validation: Analyse und Testen zur Demonstration, daß das Produkt in allen Belangen seine spezifizierten Anforderungen erfüllt. Draft EN50128, Feb Wird richtig entwickelt Ist das Richtige entwickelt worden?

86 Sommersemester 2009SW in sicherheitsrelevanten Systemen Anwendungsspezifisch konfigurierbare Systeme

87 Sommersemester 2009SW in sicherheitsrelevanten Systemen Anwendungsspezifisch konfigurierbare Systeme

88 Sommersemester 2009SW in sicherheitsrelevanten Systemen Begutachtung m Vorgaben der Maßnahmen zur Begutachtung (Anhang A) m Entwicklungsbegleitende Begutachtung m Zustimmung zum SW-Validierungsplan m Zustimmung zu den Maßnahmen (Anhang A) der Entwicklung m Zusätzliche Verifikations-/Validationsschritte Analyseprozeß zur Feststellung, ob die Entwurfsinstanz und der Validierer ein Produkt zustande gebracht haben, das die spezifizierten Anforderungen erfüllt und um zu beurteilen, ob das Produkt für seinen gedachten Anwendungszweck geeignet ist. To evaluate that the lifecycle processes and products resulting are such that the software is of the defined software safety integrity level and is fit for its intended use.

89 Sommersemester 2009SW in sicherheitsrelevanten Systemen Begutachtung im Entwicklungsprozeß Verifikation Validierung Zustimmung Begutachten Begutachten ab SIL 3 Begutachten Begutachten ab SIL 3 Begutachten Begutachten ab SIL 3 Begutachten

90 Sommersemester 2009SW in sicherheitsrelevanten Systemen Zusammenfassung EN m Vorgaben für den Entwicklungsprozeß m Festlegung von Maßnahmen und Tools m Anforderungen an Dokumente m Unabhängige Stellen

91 Sommersemester 2009SW in sicherheitsrelevanten Systemen Modellbasierte Entwicklung

92 Sommersemester 2009SW in sicherheitsrelevanten Systemen Ursprünge der modellbasierten Entwicklung 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

93 Sommersemester 2009SW in sicherheitsrelevanten Systemen Was ist modellbasierte Entwicklung? Modellbasierte Entwicklung definiert: n Hierarchieebenen auf jeder Ebene eine (formale, domänenspezifische) abstrakte Sprache Transformationen zwischen den Hierarchieebenen möglichst weitgehende Automatisierung der Transformationen

94 Sommersemester 2009SW in sicherheitsrelevanten Systemen Motivation für modellbasierte Entwicklung 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 Analysewerkzeuge (z.B. Model Checker) Nachweis von Sicherheitseigenschaften Unterstützung der Zertifizierung von Systemen

95 Sommersemester 2009SW in sicherheitsrelevanten Systemen Begriff MDA und Abgrenzung (1) Eigenschaften der modellbasierten Entwicklung (MDA - model driven architecture) sind: –Verwendung von Modellen zur Softwareentwicklung zur Abstraktion –Verwendung von Generatoren/Transformatoren zur Softwareentwicklung –Auch teilweise Automatisierung möglich (je nach fachlicher Anforderung zwischen 20% und 100%) –Die erst Abstraktionsebene wird vollständig manuell erzeugt –Ziel ist die Steigerung der Softwarequalität –Schlagwort Automation durch Formalisierung in frühen Entwicklungsphasen –Definitionen MDA, MDSD, MDSE nicht einheitlich und weichen je nach Literaturquelle voneinander ab

96 Sommersemester 2009SW in sicherheitsrelevanten Systemen Begriff MDA und Abgrenzung (2) –Die Modelltransformation erzeugt Modelle zur manuellen Weiterbearbeitung –MDA erfordert anwendungsspezifische Frameworks –MDA erfordert plattformspezifische Generatoren –MDA kann - abhängig von der Vollständigkeit der Codegenerierung – auch änderungsunfreundlich sein –MDA sagt nichts über den Abstraktionsgrad von Plattformen aus –Plattformen können aufeinander aufbauen. –Logische Fortsetzung des Abstraktionsgedankens bei der Entwicklung – manuelle Drahtverbindung, Maschinencode, Assembler, Programmiersprache, Modellierungssprache

97 Sommersemester 2009SW in sicherheitsrelevanten Systemen MDA und OMG –Ein Gesamtmodell wird in mehrere Schichten unterteilt: Computation Independent Model (CIM) für die umgangssprachliche Beschreibung Platform Independent Model (PIM) für die Geschäftsprozesse Platform Specific Model (PSM) für die Architektur und Services Codemodell für die Zielplattform

98 Sommersemester 2009SW in sicherheitsrelevanten Systemen

99 Sommersemester 2009SW in sicherheitsrelevanten Systemen Modelltransformation

100 Sommersemester 2009SW in sicherheitsrelevanten Systemen PIM und PSM bestimmen sich über Kontext

101 Sommersemester 2009SW in sicherheitsrelevanten Systemen Ausführbare Modelle Modelle, die durch die Verwendung eines Code-Generators direkt ausgeführt bzw. interpretiert werden können. Voraussetzung: – Sprache zur Beschreibung von Algorithmen – Strukturen für die Ausführung (Simulationsumgebung) Ziel: vollständig ausführbare PIMs – Komplette Entwicklung auf Modellebene – Ausführung des Modells zum Testen – weitgehende Generierung des Codes Sehr gute Komponenten-Architektur – MDA erfordert immer noch DENKARBEIT

102 Sommersemester 2009SW in sicherheitsrelevanten Systemen MDA und UML –Ein MDA-Modell ist eine abstrakte Repräsentation von Struktur, Funktion oder Verhalten eines Systems –Ein MDA-Modell wird in der Regel in UML beschrieben –UML-Diagramme sind nicht per se MDA-Modelle –Die Semantik der MDA-Modelle wird durch die Verwendung einer entsprechenden Modellierungssprache formal definiert –Es werden UML-Profile und entsprechende Transformationsregeln zwischen MDA-Modell und plattformspezifischem Modell eindeutig definiert

103 Sommersemester 2009SW in sicherheitsrelevanten Systemen MOF – Meta Object Facility OMG standard stellt Framework für das Management von Metadaten zur Verfügung Unterstützt die Entwicklung modell- /metadatenbasierter Entwicklung diverse UML-Profile verwenden MOF XMI verwendet ebenfalls MOF

104 Sommersemester 2009SW in sicherheitsrelevanten Systemen 4 MOF-Ebenen M0-Ebene - Konkret (Ausgeprägte Daten) M1-Ebene - Modelle (z. B. logische Daten-, Prozess- oder UML- bzw. Objekt-Modelle, die die Daten der M0-Ebene definieren) M2-Ebene - Sprachebene (Definieren, wie die Sprache über den Modellen von M1 aufgebaut und strukturiert sind) M3-Ebene - Meta-Sprache (Abstrakte Ebene, die zur Definition der M2-Ebene herangezogen wird)

105 Sommersemester 2009SW in sicherheitsrelevanten Systemen

106 Sommersemester 2009SW in sicherheitsrelevanten Systemen M3-Ebene:

107 Sommersemester 2009SW in sicherheitsrelevanten Systemen Wie viele Ebenen definiert MOF? 4 Ebenen sind nur ein Beispiel Grundlagen sind Klasse und Instanz MOF definiert die Möglichkeit von einer Instanz zu ihrem Metaobjekt zu navigieren Somit kann mit Hilfe von MOF jede beliebige Anzahl von Ebenen definiert werden Mindestens zwei Ebenen

108 Sommersemester 2009SW in sicherheitsrelevanten Systemen Automatendefinition in 3 Ebenen M2: {} Mengenlehre aus Mathematik -> Funktionen x Kartesischen Produkt M1: A = (Z, E, A, F) Z = {z1, …, zn) E = {e1, …, en) A = {a1, …, an) F: ZxE -> ZxA M0: A = ({1,2,3}, {tr}, {a, b, c}, ((1,tr) -> (2,a), (2,tr) -> (3,b), (3,tr) -> (1,c)))

109 Sommersemester 2009SW in sicherheitsrelevanten Systemen Automatendefinition in 3 Ebenen M2: M1: M0:

110 Sommersemester 2009SW in sicherheitsrelevanten Systemen Programmiersprachen in 4 Ebenen M3 M3 - Definition der BNF (Backus-Naur-Form) Definition= Endezeichen ; Logisches Oder| Option[... ] Optionale Wiederholung{... } Gruppierung(... ) Terminal- und Nichtterminalsymbole usw.

111 Sommersemester 2009SW in sicherheitsrelevanten Systemen Programmiersprachen in 4 Ebenen M2 M2: Syntax der Programmiersprache in BNF Programm = 'PROGRAM' Bezeichner 'BEGIN' { Zuweisung [";"] } 'END' "." ; Bezeichner = Buchstabe { ( Buchstabe | Ziffer ) } ; Zahl = [ "-" ] Ziffer { Ziffer } ; String = '"' { AlleZeichen '"'} '"' ; Zuweisung = Bezeichner ":=" ( Zahl | Bezeichner | String ) ;

112 Sommersemester 2009SW in sicherheitsrelevanten Systemen Programmiersprachen in 4 Ebenen M1 M1: Programm PROGRAM DEMO1 BEGIN A0:=3; B:=45; H:= ; C:=A; D123:=B34A; ESEL:=GIRAFFE; TEXTZEILE:="Hallo, Welt!"; END.

113 Sommersemester 2009SW in sicherheitsrelevanten Systemen Programmiersprachen in 4 Ebenen M0 M0: Programmausführung mit Instanzen/Daten

114 Sommersemester 2009SW in sicherheitsrelevanten Systemen Meta-Programmierung Meta-Modellierung Definition von Domänen-Spezifischen Sprachen (DSL) Modelltransformation Sprachumfang wird auf das Nötigste beschränkt Schneller zu lernen als manche UML-Profile Definition MARTE-Profile über 600 Seiten! Guter Programmierzugang für Nicht-Informatiker Wichtig für interdisziplinäre Entwicklung Sprache nicht zu einfach wählen, Abstraktionskonzepte nicht vergessen! Qualitätssicherung der Modelltransformationen

115 Sommersemester 2009SW in sicherheitsrelevanten Systemen Werkzeuge zur Meta- Programmierung/-Modellierung TOPCASED (Toolkit in Open Source for Critical Applications & Systems Development) EMF (Eclipse Modeling Framework) MetaEdit

116 Sommersemester 2009SW in sicherheitsrelevanten Systemen SCADE

117 Sommersemester 2009SW in sicherheitsrelevanten Systemen Grundlagen der SCADE-Modellierung SCADE-Modellierung beschreibt: SW-Regelkreisen und Signalverarbeitung (Differenzengleichungen) Endliche Zustandsmaschinen (Hierarchie, Parallelismus) Synchron getaktetes Modell

118 Sommersemester 2009SW in sicherheitsrelevanten Systemen Grundlagen synchroner Programmierung Gut geeignet für Regelungen und Endliche Automaten Eingaben lesen Reaktion berechnen Ausgaben schreiben Synchron = 0-Delay innerhalb eines Taktes für Kontrollfluss Signalfluss Vorteile: I/O und Berechnungen sind sauber getrennt einfaches Semantik, die auf Datenflüssen (Streams) beruht

119 Sommersemester 2009SW in sicherheitsrelevanten Systemen Synchrone Hypothese Wenn der Raum klein genug ist, können Sängerin und Publikum die Schallgeschwindigkeit vernachlässigen. Spezifizieren mit 0-Delay Implementieren mit vohersagbarem Delay

120 Sommersemester 2009SW in sicherheitsrelevanten Systemen Synchrones Zeitmodell Zeit wird zu einer logischen Größe Logische Zeit Implementationszeit i6 o7o5o1o2o6o4o3 i7i5i4i3i1i2 i6 o7o5o1o2o6o4o3 i7i5i4i3i1i2 WCET = garantiert keine Überlappung WCET: Worst Case Execution Time

121 Sommersemester 2009SW in sicherheitsrelevanten Systemen Überblick über die SCADE-Syntax Daten –Starke Typisierung (bool, int, real, array, structure) –Nur statische Datentypen Datenfluss Beschreibung –Boolesche Logik (not, and, or, etc.) –Arithmetik (+, -, *, /, mod, etc.) –Auswahl (if … then … else …; switch case) –Keine Schleifen – aber Map / Fold über Felder –Temporale Operatoren: Zugriff auf vorherige Datenflusswerte (fby=followed by) Safe state machines –Synchrone Automaten –Hierarchie –Parallelismus

122 Sommersemester 2009SW in sicherheitsrelevanten Systemen Scade Syntax - Datentypen Grundtypen: bool, int, real, char Nutzerdefinierte Typen Aufzählungstypen type COLORS = enum {RED, GREEN, BLUE}; Strukturen type Sensor = {valid: bool; value: real;}; Arrays type RealArray = real^5; type ElevatorButtons = int^(FLOORS); Typen der Zielsprache type imported CanMessage;

123 Sommersemester 2009SW in sicherheitsrelevanten Systemen SCADE Semantik Ein Datenfluss ist eine unendliche Folge von Datenwerten Cycle12345 Condfalsetrue falsetrue not(cond)truefalse truefalse 3.14 I I fby(I; 2; 0)

124 Sommersemester 2009SW in sicherheitsrelevanten Systemen Gleichungen Syntaktische Gleichungen definieren Datenflüsse: fib, aux: nat; fib = fby(aux, 1, 0) aux = fby(aux + fib, 1, 1); Cycle aux11235 fib01123 aux + fib12358

125 Sommersemester 2009SW in sicherheitsrelevanten Systemen Ein einfacher Zähler node Counter (Reset: bool) returns (Count: int) Count = if Reset then 0 else 1 + fby(Count,1,0)

126 Sommersemester 2009SW in sicherheitsrelevanten Systemen Zustandsmaschinen Count: int last = 0;

127 Sommersemester 2009SW in sicherheitsrelevanten Systemen Der last Operator Wenn Up aktiv ist Count = last 'Count + 1; Wenn Down aktiv ist Count = last 'Count – 1; last 'Count ist immer der letzte Wert von Count im gesamten Skope dieses Datenflusses Wenn STAND_BY aktiv ist, behält Count seinen vorherigen Wert Die Initialisierung von Count geschieht aufgrund der Deklaration Count: int last = 0;

128 Sommersemester 2009SW in sicherheitsrelevanten Systemen Parameter Polymorphismus node toggle_sample (a, b: int) returns (c: int) var flag: bool let flag = fby(not flag, 1, true); c = if flag then a else b tel monomorphic node toggle_sample (a, b: 'T) returns (c: 'T) var flag: bool let flag = fby(not flag, 1, true); c = if flag then a else b tel polymorphic

129 Sommersemester 2009SW in sicherheitsrelevanten Systemen Array Map Operator (Beispiel: Elementweise Summe) node SumScalar (a,b: int) returns (c: int) let c = a + b; tel node SumArray(t,u: int^3) returns (v: int^3) let v = (map SumScalar >) (t,u); tel SumArray([1,2,3],[2,4,0]) [3,6,3]);

130 Sommersemester 2009SW in sicherheitsrelevanten Systemen Array Fold Operator (Beispiel: akkumulierte Summe) node AccumulatedSum(t: int^5) returns (v: int) let v = (fold SumScalar >) (t); tel AccumulatedSum([1,2,3,4,5]) 15;

131 Sommersemester 2009SW in sicherheitsrelevanten Systemen Qualitätssicherung von Entwicklungswerkzeugen

132 Sommersemester 2009SW in sicherheitsrelevanten Systemen Was sagt die CENELEC-Norm? CENELEC-Norm gilt auch für unterstützende Werkzeuge angemessener Satz an Werkzeugen soll eingesetzt werden. Automatische Testwerkzeuge und integrierte Entwicklungswerkzeuge werden empfohlen. Werkzeuge und Hilfsmittel sollten zum frühest möglichen Termin verfügbar sein. Software-Werkzeuge müssen für den Zweck geeignet sein. In der Praxis: Werkzeuge mit Validierung, Begutachtung und Zulassung! Werkzeuge ohne Nachweis der Qualifizierung Und alles was dazwischen ist Neue Version der EN klassifiziert Werkzeuge: –T1: Kein direkter oder indirekter Einfluss auf Code: Editoren, Requirements Management Tools –T2: Verifikations- und Testwerkzeuge: Fehler im Tool erzeugen keine Fehler im Produkt, aber er bleibt evtl. unentdeckt –T3: Output hat direkten oder indirekten Einfluss auf das sicherheitsrelevante System Werkzeuge werden in Zukunft normativ stärker betrachtet

133 Sommersemester 2009SW in sicherheitsrelevanten Systemen Qualifizierung von Werkzeugen? Automatisierung manueller Tätigkeiten Werkzeug besitzt deterministisches Fehlerverhalten Mensch besitzt stochastisches Fehlerverhalten Nachgelagerte Qualitätssicherung zum Fehlerfinden -> keine Qualifizierung von Werkzeugen notwendig! Einsparen von Qualitätssicherungsschritten: -> Qualifizierung von Werkzeugen notwendig! Es gibt auch Werkzeuge, die weit über die Möglichkeiten manueller Tätigkeiten hinaus gehen: –Compiler, –Model Checker, –färbende einrückende Editoren, –Debugger, etc.

134 Sommersemester 2009SW in sicherheitsrelevanten Systemen Qualifizierung am Beispiel v. Generatoren/Compilern Generator durch Validierungssuite Vorwärts- Rückwärts mit Vergleich 2 mal diversitär Vorwärts mit Vergleich Test der Applikation mit Abdeckungsmessung auf Bytecode/Assembler-Ebene Generierung der Testfälle aus dem Modell mit Abdeckungsmessung Generierung der Testfälle aus einem Testmodell anschließende Abdeckungsmessung Formal beweisbare Übersetzung

135 Sommersemester 2009SW in sicherheitsrelevanten Systemen Validierungssuite Validierungssuite: Sammlung von Testfällen (ausführlich) Bei Unvollständigkeit der Sammlung bleiben ungetestete Situationen übrig. Testendekriterien bleiben genauso entscheidend wie bei den Tests des sicherheitsrelevanten Systems Validierungssuite muss nicht besser sein als ein Test eines sicherheitsrelevanten Systems gängige Praxis bei der Validierung von Compilern

136 Sommersemester 2009SW in sicherheitsrelevanten Systemen zweimal diversitär Vorwärts mit Vergleich Setzen G1 und G2 auf denselben Spezifikationen auf? Können G1 und G2 wirklich unabhängig sein? diversitäre Auslegung des Vergleichers? In der Luftfahrt wird diversitäre Vorwärtsentwicklung im first und second level eingesetzt doppelter Transformationsaufwand (Kosten) Validierung der Ergebnisse bei jeder Übersetzung -> keine fehlenden Testfälle

137 Sommersemester 2009SW in sicherheitsrelevanten Systemen Vorwärts- Rückwärts mit Vergleich Diversität durch unterschiedliche Aufgaben besser gegeben Vergleich diversitär? Falls Transformation nicht eineindeutig ist, kann M nicht wiederhergestellt werden. Evtl. zusätzliche Hilfen notwendig, damit M aus dem Code herstellbar ist. Vergleicher kann mit Intelligenz ausgestattet werden (Äquivalenzvergleich) Validierung mit jeder Übersetzung. Fehler in V mit anschließender Fehlerverschleierung in R relativ unwahrscheinlich -> sehr gute Fehleroffenbarung

138 Sommersemester 2009SW in sicherheitsrelevanten Systemen Testfälle aus Modell mit Abdeckungsmessung Generierte Testfälle nur für die Korrektheit des Generators (Gen) Abdeckungsmessung soll die Güte der erzeugten Testfälle dokumentieren und nachweisen (optional). Validierung mit jeder Übersetzung und Testausführung -> keine offenen Testfälle Keine Funktionstests des Modells, die müssen noch gesondert formuliert und durchgeführt werden.

139 Sommersemester 2009SW in sicherheitsrelevanten Systemen Abdeckungsmessung auf generiertem Code Generierte Code wird mit Testfällen aus der Validierung abgedeckt keine offene Funktionalität im Code vorhanden, da Testabdeckung gemacht Test der Generierung wird mit den ohnehin notwendigen Funktionstests kombiniert -> Einsparung intensiver Generator- Tests Abdeckungsmessungen können sehr aufwändig sein, bei sehr viel generiertem Code Abdeckungsmessungen können manuelle Argumentation für nicht abgedeckte Testfälle haben -> aufwändig

140 Sommersemester 2009SW in sicherheitsrelevanten Systemen Testmodell mit Abdeckungsmessung ähnlich voriges Beispiel, allerdings werden die Testfälle aus einem separaten Testmodell erzeugt. impliziter Funktionstest des Systems korrekte Generierung wird über die korrekte Testausführung nachgewiesen doppelter Modellierungsaufwand (Modell + Testmodell) Abdeckungsmessung weist Güte der generierten Testfälle nach Abgleich zwischen Modell und Testmodell kann anhand der Abdeckungsmessungen schwierig sein

141 Sommersemester 2009SW in sicherheitsrelevanten Systemen Formal beweisbare Übersetzung Korrektheit der Übersetzung anhand eines formalen Nachweises auf der Ebenen der Sprachdefinitionen Formale Semantik der Sprachen notwendig Evtl. aufwändige Nachweise notwendig bisher noch keine industrielle Anwendung in der Breite möglich (Forschungsgegenstand)

142 Sommersemester 2009SW in sicherheitsrelevanten Systemen Qualifizierung in der Praxis Werkzeuge mit Validierung, Begutachtung und Zulassung! Werkzeuge ohne Nachweis der Qualifizierung Und alles was dazwischen ist In der Überarbeitung der CENELEC werden Werkzeuge differenzierter betrachtet: –T1: Kein direkter oder indirekter Einfluss auf Code: Editoren, Requirements Management Tools –T2: Verifikations- und Testwerkzeuge: Fehler im Tool erzeugen keine Fehler im Produkt, aber er bleibt evtl. unentdeckt –T3: Output hat direkten oder indirekten Einfluss auf das sicherheitsrelevante System Werkzeuge werden in Zukunft normativ stärker betrachtet

143 Sommersemester 2009SW in sicherheitsrelevanten Systemen Formale Verifikation in SCADE

144 Sommersemester 2009SW in sicherheitsrelevanten Systemen Model Checking von SCADE-Modellen Durchführung: Verknüpfung mit synchronem Observer Anwendung liefert Testscenario bzw. Nachweis Grundlage Stalmarcks Algorithmus (Prover Technologies Übersetzung SCADE Aussagenlogik + (Presburger) Arithmetik Model Checking und Zertifizierung

145 Sommersemester 2009SW in sicherheitsrelevanten Systemen Synchrone Observer Idee von Model Checking Eigenschaften werden als Observer in SCADE formuliert: Design Verifier prüft, ob die einzige Ausgabe des Observers immer true ist. Beispiel: SW-Komponente eines Achszählers

146 Sommersemester 2009SW in sicherheitsrelevanten Systemen Formulierung von Eigenschaften Aussagenlogik: logische Operatoren and, or, implies, … Temporale Operatoren von SCADE: fby, pre und daraus abgeleitete Lineare Arithmetik (auch Presburger Arithmetik): Integer: Multiplikation mit höchstens einer Variable Real: Multiplikation und Division mit höchstens einer Variable LinearNicht linear 5 * X + YX * Y + 1 Z / 2 - WZ / T - 5 (T%3) * 2W % P * 3 Mathematische Funktionen (sin, cos, sqrt) und Potenzen gehen nicht!

147 Sommersemester 2009SW in sicherheitsrelevanten Systemen Einige abgeleitete temporale Operatoren AlwaysAfterFirstCond: gleicht Input1 sobald Cond einmal true wird; vorher immer true

148 Sommersemester 2009SW in sicherheitsrelevanten Systemen Einige abgeleitete temporale Operatoren AtLeastNTick: wird immer dann true, wenn Input1 n-mal hintereinander true war; false sonst

149 Sommersemester 2009SW in sicherheitsrelevanten Systemen Algorithmische Grundlagen des Model Checkers Hersteller: Prover Technologies Lösungsalgorithmen für das SAT-Problem; z.B. Davis- Putnam-Logemann-Loveland-(= DPLL-)Algorithmus Entscheidungsalgorithmen für Datengleichungen Constraint solver Stålmarks Algorithmus: Eingabe: Aussagenlogische Formel Ausgabe Entweder: Beweis im Dilemma-Beweissystem dass die Formel Tautologie ist; Oder: Belegung der Variablen, die die Formel false macht

150 Sommersemester 2009SW in sicherheitsrelevanten Systemen Übersetzung SCADE in Aussagenlogik 1.Automaten durch Datenflussbeschreibung ersetzen 2.Alle fby(…, n,…) durch fby(…,1, …) ersetzen 3.Hilfvariablen einführen, so dass nur noch fby(xi, 1, …) vorkommt Jetzt gibt es nur noch, Logik, Arithmetik, fby(xi, 1, …) 4.SCADE-Knoten node anObserver (x1, …, xn) returns (Prop: bool) wird übersetzt zu Boolescher Funktionen f(i, x1,..., xn, pre(x1), …, pre(xn)) 5.Induktionsbeweis mit Stålmarks Algorithmus: Beweise a)f(true, x1,..., xn, pre(x1), …, pre(xn)) b)f(false, x1, …, xn, pre(x1),..., pre(xn)) f(false, y1, …, yn, x1, …, xn)

151 Sommersemester 2009SW in sicherheitsrelevanten Systemen Beispiel node risingedge(x: bool) returns (y: bool); y = x and fby(not(x), 1, false); (Hilfvariable einführen) z = not(x); y = x and fby(z, 1, false); (Übersetzung in Boolesche Funktion – Gleichen werden zu logishen Äquivalenzen)


Herunterladen ppt "Sommersemester 2009SW in sicherheitsrelevanten Systemen Software in sicherheitsrelevanten Systemen Ralf Pinger Sommersemester 2009."

Ähnliche Präsentationen


Google-Anzeigen