Software in sicherheitsrelevanten Systemen

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

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

Inhalt Motivation RAMS/Normen SCADE/modellbasierte Entwicklung Qualifizierung von Entwicklungswerkzeugen Sommersemester 2009 SW in sicherheitsrelevanten Systemen

1. Motivation Zusammenstoß zweier S-Bahnen im Bahnhof Flughafen Hannover-Langenhagen, Der Zusammenstoß der beiden S-Bahnen kann als Untersuchungsbericht vom auf den Seiten vom Eisenbahnbundesamt (EBA) heruntergeladen werden. Dort sind auch noch weitere Unfallberichte zu finden. Ein etwas bekannteres Unglück ist beispielsweise die Entgleisung von Brühl. Sommersemester 2009 SW in sicherheitsrelevanten Systemen

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

Weiche Sommersemester 2009 SW 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 Erste Experimente mit der Indusi wurden bereits in den 20er Jahren durchgeführt. Seit den 30er Jahren ist die Indusi bereits flächendeckend in Deutschland verbaut und verwendet worden. Inzwischen wurden die Funktionalitäten erweitert; noch heute finden Weiterentwicklungen an dieser Art der Zugsicherung statt (PZB 90) Sommersemester 2009 SW 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. Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Übertragungsprinzip Indusi
Die genauen physikalischen Zusammenhänge – wie Anordnung der Kondensatoren, Übertragung der unterschiedlichen Frequenzen, etc. – sind dem Selbststudium überlassen. Sommersemester 2009 SW 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 Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Französische Alternative zur Indusi
Krokodil (1920er Jahre) Signalbegriff wird als positive oder negative Spannung dargestellt (+/- 20 V) Krokodile wurden bereits in den 20er Jahren als Zugsicherungskomponente entwickelt. Krokodil und Bürste führen einen galvanischen Kontakt aus, bei dem die am Krokodil anliegende Spannung auf das Fahrzeug übertragen wird und dort ausgelesen/weiterverarbeitet werden kann. Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Alternativen zur Indusi
Eurobalisen komplexere Datenübertragung möglich (mehrere Bytes) Eurobalisen werden in der Regel wenigstens paarweise verlegt. Eine einzelne Balise besitzt in der Regel eine eindeutige Kennung. Anhand der Kennungen kann ein Zug seine aktuelle Position auf der Strecke (Kilometerstein) überprüfen bzw. mit anderen Informationen (Wegimpulsgebern, Radar) abgleichen. Anhand der eindeutigen Kennungen kann beispielsweise auch die Fahrtrichtung ermittelt werden (Aufsteigende Kennung, absteigende Kennung). Balisen können aktiv oder passiv sein. Aktive Balisen haben einen variablen Nachrichtenanteil. In diesem kann beispielsweise der Signalbegriff (Fahrt, Halt, Halt-Erwarten, …) übertragen werden. An diese Balisen ist ein Kabel angeschlossen. Passive Balisen können nur die darin gespeicherten Daten übertragen. Sie dienen als reine Kilometersteine bzw. zur Übertragung fixer Streckendaten (Beginn einer Langsamfahrzone oder ähnliches). Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Live-Demo Zugsicherung (am Beispiel der belgischen Bahn)
Sommersemester 2009 SW 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! Sommersemester 2009 SW in sicherheitsrelevanten Systemen

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

Unfallfolgen 16 Personen verletzt DM Sachschaden Wiederinbetriebnahme der Strecke erst am , 04:00 Uhr, einen Tag später Sommersemester 2009 SW 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 Sommersemester 2009 SW 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! Sommersemester 2009 SW 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 Sommersemester 2009 SW 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! Aus der Tatsache, dass es offenbar kein Einzelfall ist, dass ein Triebfahrzeugführer eine Zwangsbremsung nicht dem Halt zeigenden Signal zuordnet, lässt sich eine Schwäche im System Indusi und der Mensch-Maschine-Kommunikation feststellen. Unsere System sollten so erstellt sein, dass keinerlei Missverständnisse in der Anwendung/Benutzung möglich sind. Dies ist natürlich nicht immer vollständig machbar, aber erkannte Schwächen sollten auch entsprechend behandelt bzw. behoben werden. Die derzeitige Ausprägung der Architektur ist natürlich nur mit hohem Aufwand änderbar. Das Fahrerdisplay besteht aus reiner Hardware (Lampen, Schalter, Knöpfe). Der Einbau einer zusätzlichen Signalisierungslampe bedeutet mechanischen Aufwand am Bedienpult, das Verlegen von Kabeln, und den Anschluss und Überwachung der Funktion. Dies muss natürlich in allen Triebköpfen auf dem vorderen und hintern Fahrerstand durchgeführt werden. Der Aufwand dafür ist doch sehr hoch, so dass Schwächen unter Umständen nicht leicht behebbar sind. Aufgabe der Sicherungstechnik ist also auch, änderbare Systeme zu entwerfen. Bei Realisierung mit Hilfe eines Computerdisplays als Bedienpult, wäre die Information der Bremsursache – die ist ja im Fahrzeuggerät bereits bekannt – ohne zusätzliche Änderungen an der Hardware einfach möglich. Diese Funktionalität könnte über ein SW-Update einfach eingespielt werden. Es wird auch zukünftig nicht gelingen ein perfektes, unmissverständliches und von allen Missinterpretationen freies System zu entwickeln. Wichtig ist demnach also auch, dass erkannte Fehler schnell ausgebaut/behoben werden können. Wartbarkeit und Änderbarkeit sind also entscheidende Faktoren für die Langlebigkeit eines System – vor allem eines Systems welches Sicherheitsverantwortung trägt! Sommersemester 2009 SW in sicherheitsrelevanten Systemen

zweites Beispiel – Genthin 1939
: 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 Sommersemester 2009 SW 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 Sommersemester 2009 SW 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 Sommersemester 2009 SW 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) Sommersemester 2009 SW 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) Sommersemester 2009 SW 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 Das Unglück von Genthin zeigt sehr deutlich, dass die Realität mehr Abläufe hervorbringt, als es die menschliche Vorstellungskraft vorhersehen kann. Nicht alles ist vorhersehbar oder planbar und somit abwendbar. Abläufe Regeln und Verfahren in der Eisenbahnsicherungstechnik beruhen häufig aus schlechten Erfahrungen bzw. aus Unfällen. Dies ist nicht nur bei der Eisenbahn so, sondern zieht sich wie ein roter Faden durch die Menschengeschichte. Die konsequente Vermeidung von erkannten Problemsituation – beispielsweise durch Einbau von geeigneten Sicherungsmaßnahmen – ist eine Grundregel bei der Entwicklung sicherheitsrelevanter Systeme. Der Konsequente Einbau von Sicherungstechnik hätte beispielsweise auch das Transrapid-Unglück verhindert. Die notwendigen Sicherungsmaßnahmen wäre zum Zeitpunkt des Unglücks bekannt und bereits als Produkt verfügbar. Lediglich die Anpassung an die Transrapid-Strecke wurde nicht durchgeführt; aus welchen Gründen auch immer. Sommersemester 2009 SW 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! Genthin hätte nach dem damaligen Stand der Technik verhindert werden können. Es zeigt deutlich, dass Ausnahmen – beispielsweise das Weglassen einer Sicherungstechnik – nur sehr bewusst ausgeführt werden sollten. Sommersemester 2009 SW 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? Sommersemester 2009 SW 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. Sommersemester 2009 SW in sicherheitsrelevanten Systemen

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

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. Sommersemester 2009 SW 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 Für die Entwicklung von HW muss natürlich auch ein Prozess eingehalten werden, der von der Entwicklung von Software abweicht. Mehr dazu wird in dem Abschnitt über Fehlererkennung von HW deutlich. Darüber hinaus müssen Störeinflusse wie EMV (elektromagnetische Verträglichkeit), Rüttel-Schüttel und Klima betrachtet werden. Ein Beispiel für sicherheitsrelevante Betriebskonzepte haben wir bereits bei der Fehlinterpretation der Zwangsbremsung durch die Indusi kennengelernt. Selbst wenn die technische Umsetzung fehlerfrei ist, kann dennoch eine Gefährdung aus dem Gesamtablauf heraus entstehen. Ein weiteres Beispiel hierfür sind Halbschranken, die beispielsweise zu lange geschlossen sind. Es ergibt sich hieraus die Gefahr, dass wartende Menschen aufgrund der langen Verzögerung die Halbschranken einfach passieren. Solches Verhalten gilt es bei Betriebskonzepten näher zu betrachen. Wir wollen dies nicht in dieser VL vertiefen. Dennoch spielt es eine sehr wichtige Rolle für die Gesamt-Sicherheit eines Systems. Sommersemester 2009 SW 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. Der Begriff System ist in der Literatur sehr unterschiedlich definiert, so dass es ratsam ist, eine Definition von System zu verabreden, die innerhalb eines Kontext verwendet wird. Sommersemester 2009 SW 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. Sommersemester 2009 SW 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 Diese Sichtweise führt zu klarer Defintion der Inputs, Outputs und der zu erstellenden Funktion zwischen Inputs und Outputs. Diese Sichtweise für die Entwicklung von Software sehr hilfreich. Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Definition System Ganz wichtig für den Einsatz eines Systems ist auch die Beschreibung der Umgebung, in der das System seine Aufgabe erfüllen soll. Es müssen gewissermaßen Anforderungen an die Umgebung definiert werden, damit das System selbst die ihm gestellten Aufgaben erfüllen kann. Setzt man beispielsweise einen Mikrocontroller mit Ethernetschnittstelle in ein Fahrzeug mit CAN-Bus ein, wird man vermutlich Schwierigkeiten mit der Erfüllung der Funktion durch diesen Mikrocontroller haben. Oftmals sind diese Fehler jedoch sehr viel difiziler. ABER: Sehr viele Fehler entstehen durch unklare Formulierung der Anforderungen an die Umgebung und den Einsatz eines an sich funktionierenden – sprich in anderem Umfeld erprobten – Systems in einer anderen Umgebung. Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Definition System 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? Sommersemester 2009 SW in sicherheitsrelevanten Systemen

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

Lageplan Siemens AG Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Definition RAMSS Analogie Auto: R= Wahrscheinlichkeit, dass der Wagen in einem definierten Zeitintervall nicht versagt (z. B. von der Zulassung bis zur ersten Inspektion), basiert auf der Häufigkeit von Ausfällen bei reparierbaren Systeme und ergibt Anforderungen für Inspektionen A = Zeitanteil, in dem der Wagen benutzbar ist – also funktionsfähig vor dem Haus steht oder betrieben wird; abträglich ist die Dauer von Inspektionen und Reparaturen M = Alle Wartungsaspekte, z. B. Strategie (regelmäßige Inspektionen) als auch Dauer der Reparatur, Vorhandensein von Ersatzteilen, Zugang zu Verschleißteilen etc. Safety = Verkehrssicherheit, beim Auto z. B. Funktion von Bremsen, Sicherheitssysteme, z. B. Airbags Security = Sicherheit gegenüber Missbrauch oder Zugriff (Schließsystem, Wegfahrsperre, Alarmanlage etc.) Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Zusammenhang zwischen RAM, S und S
Allgemeine Darstellung, wie eine Gefährdung entstehen kann betriebliche Gefährdung durch ODER-Gatter auf Normalbetrieb, Rückfall und Sabotage zurückführen: Sabotage - Security ! Normalbetrieb: Sicherungssystem verhindert, dass ein menschlicher Fehler gefährlich wird - Doppelausfall notwendig (UND-Gatter) Technisches Versagen aufgrund von zufälligen Fehlern oder systematischen Fehlern - Safety-Problem Rückfallebene: Soweit möglich noch vereinfachte technische Unterstützung, wenn diese versagt führt ein menschlicher Fehler zur Gefährdung - Verfügbarkeitsproblem RAM (Prioritäts-Und-Gatter) Es zeigt sich, dass Verfügbarkeit immer kritischer wird, da aus bekannten Risikoableitungen und Erfahrungen klar wird, dass das Risiko des Betriebs im Bereich der Rückfallebene erheblich ansteigt. Beispiel Stellwerk: Der sichere Zustand in einem Stellwerk ist das Anhalten aller Züge und das Abschalten des Systems. Dem entsprechend kann man die Software so gestallten, dass wenn ein nicht definierten Zustand an irgendeiner Stelle eintritt, dass gesamte System abgeschaltet wird. Damit gehen automatisch alle Signale auf Halt und die Züge werden gestoppt. In der Regel sind Bahnbetreiber aber auch am Betrieb, d. h. an der Beförderung von Fahrgästen interessiert. Nach dem Abschalten der System übernimmt also er Mensch die Verantwortung für den Betrieb. Der Mensch hat aber in der Regel eine geringere Zuverlässigkeit – sprich das menschliche Versagen ist vorprogrammiert. CENELEC betrachtet daher auch RAMS in der Norm EN50126 Aber was ist mit der Betrachtung der Sicherheit, wie wir sie bisher kennen ? Sommersemester 2009 SW 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. Formal bestimmt bisher die Mü8004 die Sicherheit eines Bahnsystems. Gegenüber Mü8004 findet aber ein Paradigmenwechsel statt: s. oben Vgl. Die Grundbegriffe mit CENELEC: Im Prinzip tauchen dieselben Begriffe auf, aber das Ergebnis ist anders: sicher/nicht sicher bei Mü, risikoorientiert bei CENELEC Nach CENELEC heißt Sicherheit Freisein von inakzeptablen Risiken. Dies ist mit dem Sicherheitsbegriff nach Mü8004 nicht argumentierbar. Die Mü8004 ist ein Regelwerk, das Konstruktionsregeln aufstellt: Nachteil ist die Behinderung von innovativen Lösungen CENELEC-Normen geben einen abstrakten Rahmen vor und sind selbst Stand der Technik. Z. B.: Risikoanalyse nach Norm, um das Sicherheitsniveau festzulegen Problem bei beiden Sicherheitsparadigmen: Fehlerfreiheit zu Beanspruchungsbeginn. Wie nachzuweisen? Nur durch Abnahme und Tests, bei Mü8004 im Sicherheitsparadigma, bei CENELEC in Qualitätsanforderungen und als Basis für Sicherheitsnachweis gefordert Sommersemester 2009 SW in sicherheitsrelevanten Systemen

MILITARY-STANDARD MIL-STD-882 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. Software System Safety Handbook (MIL-STD) 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. MIL-STD – Military Standard Analogie zu Vorgaben des amerikanischen DoD (department of defense) Sommersemester 2009 SW 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? Zuviel „Wasser unter dem Kiel“ heißt, dass die Produkte möglicherweise zu teuer sind. Zuwenig „Wasser unter dem Kiel“ bedeutet Sicherheitsprobleme. Sommersemester 2009 SW 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 Falls der Unfall „Eschede“ aufgrund z. B. Eines Stellwerksfehlers zurückzuführen wäre, wäre das Vertrauen in unsere Produkte so stark erschüttert, dass wir wahrscheinlich vom Markt verschwinden würden. MTTH: mean time to hazard Beispiel: Sicherheitsanforderungen MTTH=1 Mio. Jahre hieße, dass man ein Vielfaches davon an Betriebs- oder Testerfahrung nachweisen müsste, z. B. 5 Mio. Jahre: d. H. Man teste 1 Einheit 5 Mio. Jahre, 5 Mio. Einheiten 1 Jahr oder usw. Dies ist nicht praktikabel. Deswegen muss der Sicherheitsnachweis auf Modellrechnungen und entspr. Annahmen beruhen. D. H. Die Sicherheit kann nur plausibel gemacht werden, aber nicht „bewiesen“. Sommersemester 2009 SW 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 Für die Sicherheit eines Systems (Software + Hardware) ist es wichtig, dass zufällige Fehler der Hardware erkannt werden können und geeignete Maßnahmen zur Kompensation des Fehlers eingeleitet werden können. Das Erkennen zufälliger Fehler hat natürlich Grenzen, da nicht gegen alle Fehler eine Reaktion möglich ist. Das Unglück von Eschede durch den gebrochenen Radreifen hätte nach dem Auftreten nur noch zufällig durch eine menschliche Interaktion verhindert werden können. Um so wichtiger sind die Einhaltung der Wartungsintervalle, in denen der Verschleiss der Hardware überprüft wird und Verschleissteile vor dem Auftreten von Defekten ausgetauscht werden. Der Fehler lag also im nicht rechtzeitigen Erkennen der Verschleißgrenze. Ein ähnliches Beispiel ist der Bruch einer Tragfläche beim Flugzeug. Tritt der Fehler auf, gibt es keine Möglichkeit der Kompensation mehr; ein Absturz in unvermeidlich. Deshalb müssen diese Teile regelmäßig überprüft werden, damit der zufällige Fehler gar nicht erst auftritt. Bei Computer-Hardware ist die Vorhersage, wann ein Defekt auftritt wesentlich schwieriger zu beantworten. Verschleißgrenzen sind in diesen elektronischen Bauteilen nicht messbar oder erkennbar. Dennoch muss eine Fehlfunktion aufgrund von Hardwarefehlern im laufenden Betrieb erkannt und somit vermieden werden. Systematische Fehler hingegen sind schon immer da gewesen und lassen sich somit im laufenden Betrieb auch nicht als solche erkennen. Es gibt schließlich kein alternatives Normverhalten, gegen das referenziert werden könnte, da das Verhalten aufgrund des systematischen Fehlers schon immer so gewesen ist. Ähnlich wie beim erreichen der Verschleißgrenzen von Hardware wie beispielsweise Radreifen oder Tragflächen müssen systematische Fehler bereits vor Inbetriebnahme erkannt und beseitigt werden. Alles was vorab nicht erkannt wurde, lässt sich nur durch „glückliche Fügungen“ kompensieren. Sommersemester 2009 SW 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 Software verschleißt nicht. Demnach besitzt Software nur systematische Fehler. Systematische Fehler lassen sich nur im Vorfeld der Inbetriebnahme erkennen und beseitigen – abgesehen von einigen Ansätzen, bei denen dieselbe Funktion unabhängig voneinander mehrfach implementiert wird und die Ergebnisse im laufenden Betrieb ständig miteinander verglichen werden. Aber auch bei diesen Ansätzen muss die Funktion jeder Einzelimplementierung im Vorfeld gegenüber systematischen Fehlern geprüft werden. Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Rechnerarchitektur 1oo1D
Das Ausführen der Sicherheitsfunktion bedeutet das Einnehmen des sicheren Zustands – bei der Eisenbahn bedeutet das beispielsweise das Anhalten aller Züge eines bestimmten Bereiches. Bei einem Flugzeug in der Luft ist die Frage nach dem sicheren Zustand schon schwieriger zu beantworten. Wenn kein sicherer Zustand existiert oder definiert werden kann, ist diese Architektur kein geeigneter Kandidat für diesen Einsatzzweck. Die Diagnosekomponente überprüft die Ausgaben des Kanals ständig auf Plausibilität. Falls die Ausgabe nicht schlüssig sind, wird die Ausgabe abgeschaltet und die Sicherheitsfunktion ausgeführt. Die Diagnosekomponente kann beispielsweise eine Referenzimplementierung sein oder auch nur ein Plausibilitätscheck, der die Ausgaben auf Konsistenz prüft. Im letzteren Fall muss dann sichergestellt werden, dass eine defekte Hardware keine konsistenten Daten mehr liefern kann. Darüber hinaus muss der Einfluss der defekten Hardware auf die Funktion der Diagnose ausgschlossen werden können. Ansonsten könnte beispielsweise ein Hardwaredefekt eine falsce Ausgabe verursachen und derselbe Defekt führt dazu, dass die Diagnose diesen Fehler nicht als solchen erkennt. Kanal und Diagnose müssen also hinreichend unabhängig sein. Dieses Verfahren steht und fällt mit der Unabhängigkeit von Kanal und Diagnose. Eine Unabhängigkeit kann nur dann angenommen werden, wenn Kanal und Diagnose hinreichend unterschiedliche Aufgaben haben und die für die Berechnung der jeweiligen Funktionen eingesetzte Hardware ebenfalls hinreichend unabhängig sind. Sommersemester 2009 SW 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 Das Erkennen eines HW-Fehlers kann in dieser Varianten einige Zeit in Anspruch nehmen. Das Verfahren ist also nur dann einsetzbar, wenn für die Einnahme des sicheren Zustand genügend Zeit zur Verfügung steht. Der Vorteil dieser Variante ist die vergleichsweise günstige Ausführung, da nur eine Diagnoseeinheit hinzugefügt werden muss. Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Rechnerarchitektur 1oo2
Bei dieser Variante können zufällige Fehler der HW erkannt werden. Allerdings ist es nicht möglich, den fehlerhaften Kanal als solchen zu erkennen. Es kann lediglich eine Abweichung festgestellt werden. Auf dieser Basis muss bereits die Sicherheitsfunktion ausgeführt werden (oder-Gatter hinter den Vergleichern – falls ein Vergleicher eine Abweichung findet, wird SF ausgführt). Nachteilig bei dieser Variante ist, dass die beiden Kanäle synchron in der Ausführung gehalten werden müssen. Tritt ein Zeitversatz von einem Kanal zum anderen auf, so müssen die Ergebnisse zwangsläufig von einander abweichen, da die Berechnungen in unterschiedlichen Phasen sind. Eine Abschaltung aufgrund dieser Timing-Probleme muss natürlich vermieden werden. Das Verfahren ist natürlich anfällig für common cause Fehler. Beispielsweise wenn die Stromversorgung eine kurzfristige Überspannung liefert, so können durch diese Überspannung beide Kanäle denselben elektrischen Defekt bekommen. In diesem Fall könnte trotz HW-Fehlers keine Abweichung zwischen den Kanälen festgestellt werden. Common cause muss also auch hier im Vorfeld betrachtet und vermieden werden (systematischer Fehler bei Nichteinhaltung). Absolute Sicherheit wird es auch bei diesen Ansätzen nicht geben können! Sommersemester 2009 SW 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 Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Eine Variante des 1oo2-Ansatzes, die nicht ganz so „sensibel“ bezüglich der Ausführung der Sicherheitsfunktion ist; diese wird nämlich erst dann automatisch ausgeführt, wenn beide Kanäle eine Abweichung feststellen (Und-Gatter vor SF). Hat nur ein Vergleicher eine Abweichung ist jedoch auch hier nicht klar, welcher Kanal jetzt die „richtigen“ Daten hat. Deshalb muss eine Warnung ausgegeben werden und der Mensch hat die Entscheidungspflicht und Verantwortung – und natürlich auch die Möglichkeit durch Ausführung der Sicherheitsfunktion zur sicheren Seite zu entscheiden. Gegenüber 1oo2 ist dieser Ansatz vermutlich verfügbarer (System steht länger zur Verfügung). Ob die Funktion deswegen auch richtig (zuverlässig – nicht versagt) ausgeführt wird, steht auf einem anderen Blatt. Sommersemester 2009 SW 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 Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Rechnerarchitektur 1oo2D
Will man nach dem Erkennen eines HW-Fehlers noch sicher weiter arbeiten, kann diese Architektur eingesetzt werden. Durch die Verwendung der Diagnose-Einheiten kann der fehlerhafte Kanal als solches erkannt werden und mit dem anderen Kanal noch weiter gearbeitet werden. Dieses System ist sicherlich verfügbarer. als die vorhergehenden, da nach dem ersten Defekt weiter gearbeitet werden kann. Außerdem ist es noch zuverlässiger, da über die Auswahl des richtigen Kanals die Funktion auch noch korrekt ausgeführt wird. Nachteilig ist aber der HW-Aufwand. Außerdem gelten dieselben Einschränkungen wie bei 1oo1D bezüglich der Unabhängigkeit. Sommersemester 2009 SW 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 Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Voter ist ein Vergleicher der Ausgaben der jeweiligen Kanäle. Tritt eine Abweichung in einem Kanal auf, so wird aufgrund der Gleichheit der anderen Kanäle angenommen, dass dieser Kanal fehlerhaft ist. Fehlerhaft erkannte Kanäle werden abgeschaltet und der Betrieb kann zweikanalig weiterlaufen. Erst beim nächsten Fehler (Abweichung des Vergleichs im Voter) muss die Sicherheitsfunktion ausgeführt werden. Denn dann kann nicht mehr entschieden werden, welcher der beiden letzten Kanäle noch korrekt arbeitet. Verfügbarkeit hoch, da nach erstem Fehler weitergearbeitet werden kann. Unabhängigkeit gegenüber 1oo1D-Problematik hier weiter reduziert. Standard bei Stellwerken der höchsten Sicherheitsanforderungsstufe. Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Eigenschaften von 2oo3 Verdreifachung der HW Fehlerhafter Kanal kann erkannt werden Weiterarbeiten nach erstem Fehler möglich Synchronisation noch schwieriger Sommersemester 2009 SW 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! Sommersemester 2009 SW 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 Sommersemester 2009 SW 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 Quelle: EN 50128 Sommersemester 2009 SW 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 Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Fishbone Analysis zur Identifikation von Gründen für Softwarefehler
Gewichtung variiert von Quelle zu Quelle. Fischgräte ist nicht vollständig 50128 betrachtet keinen der unteren drei Punkte Prof. Pomberger/Uni Linz (9. SWI-Tag): maßgeblich für den Projekterfolg sind primär menschliche Faktoren (Management) Quelle: A Software Fault Prevention Approach in Coding and Root Cause Analysis Weider D. Yu Sommersemester 2009 SW in sicherheitsrelevanten Systemen

CENELEC nach 50129 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. Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Sicherheitsanforderungsstufen für Software (SSAS)
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 unterschiedlichen SSAS innerhalb eines Systems Rückwirkungsfreiheit z.B. System mit verschiedenen Rechnern. (Kapitel 9.4.9) Achtung mit COTS (Kapitel 9.4.5). Auch hier ist bei unterschiedlichen SSIL die Rückwirkungsfreiheit zu betrachten und zu begründen. Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Software und Sicherheit
SW-Anforderungen SW Architektur und Design SW Implementierung und Test SW-Abnahme / Zulassung In diesem Ablauf (aus EN50128, Bild 2) wird deutlich, dass die Sicherheit in die Software hineingebracht wird, indem im Rahmen der Sicherheitsvorgaben aus der System-Spezifikation eine sorgfältige Zuordnung der sicherheitsrelevanten Funktionen zu Aufgaben der Software durchgeführt wird. Das Ergebnis findet sich in der Software-Anforderungsspezifikation. Nach qualitativ hochwertigem Design und Analyse- und Testschritten, kann die Software-Abnahme und zu guter Letzt die Zulassung erfolgen. Die Norm hört hier jedoch nicht auf, sondern bringt auch Vorgaben zu Projektierung und auch Wartung in der Betriebsphase. Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Eingliederung der EN50128 CENELEC-Normen Eisenbahnsystem
Eisenbahnsignalsystem EN 50129 Teil SW aus herausgenommen. Bei Beauftragungen ist dabei, auch wenn nur oder steht. Aber: wenn nicht oder 50129, dann ist nicht automatisch die drin, nur weil es sich um Bahntechnik handelt. ACHTUNG: Es kann vertragliche Vereinbarungen geben, die einen bestimmten SIL der verabreden, obwohl keinerlei sicherheitsrelevante Anforderungen an die SW bestehen, vielleicht auch noch nicht einmal eine Bahnanwendung vorliegt. In diesem Fall ist die als Q-Norm zu betrachten. (Vergleichbar einer Q-Metrik, Erläuterung später bei den Tabellen) Teilsystem Software EN 50128 Sommersemester 2009 SW 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) Zusammenfassung aus Kapitel 1 der EN 50128 PES: programmierbare elektronische Systeme Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Aufbau der Norm Normativer Textteil Normativer Anhang A Informativer Anhang B Normativer Text Kapitel Anhang A Aufbau der Norm. Verweise nicht klar ersichtlich. Anhang A verweist auf normativen Text (clause ist Kapitel) und Anhang A (unter Ref. D.x für detailed table) und Anhang B (unter Ref. B.x). der normative Text muss erfüllt werden. Anhang A steht drin, was erfüllt werden muss. Anhang A besteht aus einem allgemeinen und einem detaillierten Teil Anhang B ist informativ Referenzen (B.nn) Auswahllisten zu Methoden, Maßnahmen und Tools Anhang B Informationen zu Methoden und Tools Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Beispiel 1: Normativer Textteil
8 Software-Anforderungsspezifikation 8.1 Ziele 8.1.1 Beschreiben 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. 8.1.2 Beschreibung der Software-Anforderungstestspezifikation. 8.2 Eingangsdokumente 1) System-Anforderungsspezifikation ... 8.3 Ausgangsdokumente 1) Software-Anforderungsspezifikation 2) Software-Anforderungstestspezifikation 8.4 Anforderungen 8.4.1 Die 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: ... Gliederung für Phasen bzw. Vorgänge so wie hier dargestellt Ziele Eingangsdokumente Ausgangsdokumente Anforderungen jeweils ca. 2 Seiten im Normtext, AUSNAHME: Qualitätsmanagement und konfigurierbare Systeme Blauer Text: Verweis auf Anhang A Der gesamte Text ist verbindlich – unabhängig vom SSIL Verbindliche Phasen sind in Tabelle A.1 festgelegt (nur bei SSIL 0 nicht alle) ISO/IEC 9126: Q-Norm mit Metriken (Erheben und Auswählen von Daten für Metriken, Grundlagen, nur Teil 1 von vier Teilen ist in der gültigen Version bisher verfügbar, aber es existiert auch noch eine ältere zurückgezogene Version) Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Beispiel 1 aus Anhang A NR: abgeraten -: keine Aussage R: empfohlen HR: dringend empfohlen M: verbindlich Referenzspalte (Detailtabellen aus Anhang A oder Anhang B) und „SIL“-Spalten Forderungen erläutern für den Fall, dass mehrere HRs auftauchen (siehe auch Feld mit Bemerkungen) Wie sieht Anhang A aus, wo sind die Verweise zum normativen Text und Anhang B Was muss man machen um welchen SIL zu erreichen? Forderungen: Auswahlkriterien (siehe 2.) Es können auch andere Methoden verwendet werden, die zu argumentieren sind HIER: Eigentlich ist die eine Norm, die ein Maß (SIL 0 bis SIL 4) für den Softwareentwicklungsprozess definiert (keine Metrik, da SIL 4 nicht doppelt so gut ist wie SIL 2). Folge: Hieran kann man einen Softwareentwicklungsprozess messen und beurteilen (sind zwei Meter Höhe erreicht oder gerissen) Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Beispiel 1 aus Anhang B B.14 Entscheidungstabellen (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. Was unter Ziel steht taugt dazu, die Argumentation für eine alternative Maßnahme zu erbringen Was steht in Anhang B: Erklärung oder Information zu den Anforderungen aus Text und Anhang A. Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Beispiel 2 aus Anhang A Beispiel: verschiedene Programmiersprachen und ihre Anwendung: 1-6 Hochsprachen, 5 ist nicht anerkannt (Hackersprache), aber Siemens hat EBA überzeugt (genehmigtes Subset) IEC 61508/7: C wird HR mit subset, coding standard und static analysis tools Sprachen 1-3: Bei SIL 1/2 HR, bei SIL 3/4 nur R? Was wird benötigt? -> nächste Folie Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Beispiel 2 aus Anhang A (Fortsetzung)
Zu 1. Warum erst bei einer Untermenge? Warum steht HR nicht gleich da? (B.62: Rekursion ist zu vermeiden) Zu 2. Wie hebt man die Empfehlungsstufe an? Zu 4. Wie soll die Programmiersprache übereinstimmen? Geht das überhaupt „Ein Basic-Programmierer schreibt in jeder Sprache Basic“ (Basic ist durch jede andere Programmiersprache ersetzbar) Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Für die, die es ganz genau wissen wollen (gibt immer einige, da hat man es dann schriftlich) ES GIBT EINE ZWEITE FOLIE ALS FORTSETZUNG! Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Für die, die es ganz genau wissen wollen (gibt immer einige, da hat man es dann schriftlich) DIESES IST DIE ZWEITE FOLIE ALS FORTSETZUNG! Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Prozeß Phase Ablauf der Entwicklung Eckpunkte: V-Modell Zu jedem Entstehungsschritt ein überprüfender Schritt Neu: SW-Wartung Auf PEACC/PEACC+ verweisen Anmerkung zu PEACC+: PEACC+ wird als CENELEC-konform angenommen. Ein konkreter Nachweis existiert nicht. Ein Tailoring verkompliziert einen allgemeinen Nachweis nur und befreit ein Projekt nicht vom Nachweis , dass CENELEC-konform entwickelt wird. PEACC+ ist so strukturiert, dass davon ausgegangen wird, dass der normative Textteil immer durch den Prozess erfüllt wird, die Instanziierungen des Projektes sich also nur im Methodenteil unterscheiden und nur der noch nachgewiesen werden muss... Verbesserungsvorschlag hiervor: Kapitel über Q-Maßnahmen und Zusammenhang zwischen Q und S. Ergebnisse Ver Val Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Prozeß Phase Ergebnisse 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-Integrationsphase ____________________________ Software-Integrationstestbericht Software/Hardware-Integrationsphase ______________________________________ Software/Hardware-Integrationstestbericht Software-Validierung _________________________ Software-Validationsbericht Software-Begutachtungsphase _______________________________ Software-Gutachten Software-Anforderungsspezifikationphase Software-Anforderungsspezifikation Software-Anforderungstestspezifikation Software-Anforderungsverifikationsbericht System-Anforderungsspezifikation System-Sicherheitsanforderungsspezifikation System-Architekturbeschreibung System-Sicherheitsplan Software-Modultestphase ______________________ Software-Modultestbericht Software-Wartungsphase ___________________________________ Software-Wartungsaufzeichnungen Software-Wartungsprotokoll Phase Einblick in die einzelnen Phasen Eckpunkte: Vorgaben aus System Spezifikation der gesamten Software Architektur (Betriebssystem, Treiber, Anwendersoftware) Design= Zerlegung/Verfeinerung der Architekturelemente -> pro Architekturelement -wie z.B. Anwendersoftware- ein Design Pro Design Zerlegung in Module (-> n Module) Implementierung In jeder Phase Testspezifikationen Verifikation Validation Modul- und Hardware-/Softwareintegrationstest durch Entwickler Neu: SW-Wartung Auf PEACC/PEACC+ verweisen Ergebnisse Ver Val Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Prozeß Ver Val Phase Einblick in die einzelnen Phasen und Verifikation und Validierung In jeder Phase Testspezifikationen Verifikation Validation Modul- und Hardware-/Softwareintegrationstest durch Entwickler Neu: SW-Wartung Problem: Korrektheit der Anforderungsspezifikation! => Vielleicht der Validierer? Auf PEACC/PEACC+ verweisen Ergebnisse Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Dokumente / Ergebnisse
Definitionen / Anforderungen zu den Phasen des Lebenszyklus‘ (Textteil) Vorgaben von Maßnahmen und Tools (Anhang A) Vorgaben zu Reviews (Verifikation) Verfolgbarkeit der Anforderungen Wichtige Punkte für die Entwicklungsphasen Punkt 1: ab Kapitel 8 (SW Requirements Specification) der Norm strenge Anforderungen an Phasenablauf und Ergebnisdokumente Punkt 2: Annex A ist unbedingt zu berücksichtigen Punkt 3: im Kapitel 11 (SW-verification and -testing) der Norm gibt es strenge Anforderungen an die Durchführung und Dokumentation (inhaltlich) für Reviews und Tests Punkt 4: mehrfach wird die Verfolgbarkeit der Anforderungen von der Norm verlangt PEACC+: Methodenratgeber Dr. Bachmann hat eine Festlegung getroffen. Das vorgestellte Benummerungsschema ist eine Notation, ersetzt aber keine Methodik, dazu gehört auch eine Vorgehensweise, ist im Methodenratgeber aber enthalten (Keine Aussage zur Qualität) Verbesserungsvorschlag hierfür: Ersetzen durch Satz Traceability-Folien (Arten und Verfolgbarkeit, Methodik zum Requirements Capturing) Sommersemester 2009 SW 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 SIL 0: einer darf gemäß Norm DI, Ver, Val sein, aber nicht nach ISO 9000 „persönliche“ Unabhängigkeit des Validierers bei sicherheitsrelevanter SW außerdem Projektunabhängigkeit des Validierers bei SIL  3 Firmenunabhängigkeit des Gutachters oder Anerkannter Fachbetrieb (z.B. EBA) mit besonderen Auflagen an die Gutachter Unabhängigkeiten der Ver‘s, Val‘s und Gut‘s in Abhängigkeit der nachzuweisenden SILs. Gutachter vom EBA anerkannt Kompetenznachweis als Dokument erforderlich Verbesserungsvorschlag hierfür: zusätzliche Folie mit Zuweisung von Kompetenzen zu den vorgesehenen Rollen Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Aufgaben und Rollen Zuordnung der Rollen zu den Aufgaben ab Kapitel 8 in dieser Normtext-Tabelle dargestellt. Sehr hilfreich bei Unklarheiten Verifizierer und Tester in Kap 11 beschrieben Aber über Test ist auch in Kap 10 und 12 was gesagt. Wer macht das? DI Sommersemester 2009 SW 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. 1998 Wird richtig entwickelt Ist das Richtige entwickelt worden? Validation: Analyse und Testen zur Demonstration, daß das Produkt in allen Belangen seine spezifizierten Anforderungen erfüllt. Draft EN50128, Feb. 1998 Gelbe Wolken sind hier wichtig Aber auch wichtig ist die Sichtweise (Verifikation ist Sichtweise des Herstellers, Validation Sichtweise des Kunden) ACHTUNG: In anderen Branchen können die Begriffe andere Bedeutungen haben. Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Anwendungsspezifisch konfigurierbare Systeme
Bild aus einem U-Boot (Quelle: Ingolf Siegmund) Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Anwendungsspezifisch konfigurierbare Systeme
Entwicklung des Systems: Produkt Projektierung der Anlage: Projekt Projektierungsdaten sind sicherheitsrelevant. (Zug vorwärts/rückwärts) Anknüpfen an das V-Modell, Ähnlichkeiten erwähnen Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Begutachtung 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. Vorgaben der Maßnahmen zur Begutachtung (Anhang A) Entwicklungsbegleitende Begutachtung Zustimmung zum SW-Validierungsplan Zustimmung zu den Maßnahmen (Anhang A) der Entwicklung Zusätzliche Verifikations-/Validationsschritte Check gegen Requirements, Erfüllen der Funktion ggf. aber auch mehr individuelle Absprachen mit Gutachter sind möglich, stehen aber auch im Gutachten => immer die Zulassung im Blick behalten und das Notwendige im Sinne der Zulassung einer Anlage oder eines generischen Systems tun => Systemgrenzen und Nachweiskonzept frühzeitig festlegen 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. Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Begutachtung im Entwicklungsprozeß
Begutachten Begutachten Begutachten Zustimmung Begutachten ab SIL 3 Begutachten ab SIL 3 Begutachten ab SIL 3 Begutachten ab SIL 3 ggf. auslassen von dem Entwicklungsprozess als solchen bis hin zu den einzelnen Phasenergebnissen Begutachten ab SIL 3 Verifikation Validierung Begutachten Begutachten Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Zusammenfassung EN 50128 Vorgaben für den Entwicklungsprozeß Festlegung von Maßnahmen und Tools Anforderungen an Dokumente Unabhängige Stellen Grundidee: Wo stehe ich? Wo will ich hin? Wie erreiche ich mein Ziel? Wie überwache ich, dass die ersten drei Punkte immer noch gültig sind („KVP“) - und alles auditierbar und nachprüfbar dokumentiert. Daraus folgt z.B.: Rollen definieren notwendige Kompetenzen definieren Leute entsprechend ihrer Rolle und Kompetenz einsetzen normativer Textteil: alle Punkte müssen erfüllt sein Norm nur die Mindestanforderung Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Modellbasierte Entwicklung

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

Modelltransformation

PIM und PSM bestimmen sich über Kontext

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

M3-Ebene: Sommersemester 2009 SW 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 Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Automatendefinition in 3 Ebenen
{} 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))) Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Automatendefinition in 3 Ebenen

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

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

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

M0: Programmausführung mit Instanzen/Daten Sommersemester 2009 SW 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 Sommersemester 2009 SW in sicherheitsrelevanten Systemen

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

SCADE Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Grundlagen der SCADE-Modellierung
SCADE-Modellierung beschreibt: SW-Regelkreisen und Signalverarbeitung (Differenzengleichungen) Endliche Zustandsmaschinen (Hierarchie, Parallelismus) Synchron getaktetes Modell Sommersemester 2009 SW 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 Sommersemester 2009 SW in sicherheitsrelevanten Systemen

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

Synchrones Zeitmodell
Zeit wird zu einer logischen Größe i6 o7 o5 o1 o2 o6 o4 o3 i7 i5 i4 i3 i1 i2 Logische Zeit i6 o7 o5 o1 o2 o6 o4 o3 i7 i5 i4 i3 i1 i2 Implementationszeit WCET = garantiert keine Überlappung WCET: Worst Case Execution Time Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Überblick über die SCADE-Syntax
Daten Starke Typisierung (bool, int, real, array, structure) Nur statische Datentypen Datenfluss Beschreibung Boole’sche 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 Sommersemester 2009 SW 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; Sommersemester 2009 SW in sicherheitsrelevanten Systemen

SCADE Semantik Ein Datenfluss ist eine unendliche Folge von Datenwerten Cycle 1 2 3 4 5 Cond false true not(cond) 3.14 I 14 13 11 12 16 I 17.14 16.14 14.14 15.14 19.14 fby(I; 2; 0) Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Gleichungen Syntaktische Gleichungen definieren Datenflüsse: fib, aux: nat; fib = fby(aux, 1, 0) aux = fby(aux + fib, 1, 1); Cycle 1 2 3 4 5 aux fib aux + fib 8 Sommersemester 2009 SW 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) Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Zustandsmaschinen Count: int last = 0; Sommersemester 2009 SW 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; Sommersemester 2009 SW 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 Sommersemester 2009 SW 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) v = (map SumScalar <<3>>) (t,u); SumArray([1,2,3],[2,4,0])  [3,6,3]); Sommersemester 2009 SW in sicherheitsrelevanten Systemen

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

Qualitätssicherung von Entwicklungswerkzeugen

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 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 Sommersemester 2009 SW 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. Deterministisches Fehlerverhalten: Fehler treten immer dann auf, wenn die Voraussetzungen für den Fehler erfüllt sind. In der Regel sind die Fehler an vielen Stellen in der Software vorhanden. Wird ein solcher Fehler an einer einzigen Stelle in der Qualitätssicherung gefunden und behoben, sind alle Fehler dieser Klasse aus dem Produkt verschwunden. Ein einziger Testfall zum Finden aller Fehler dieser Fehlerklasse! Stochastisches Fehlerverhalten: unterschiedliche Fehler treten an unterschiedlichen Stellen in der Software auf. Für jeden Fehler braucht man einen eigenen Testfallen zum Finden. In der Praxis (Gutachtersicht) werden Werkzeuge oft mit demselben Aufwand erstellt, wie das sicherheitsrelevante System! Der eigentliche Zweck des Werkzeugs geht dabei oft verloren. Manchmal wird der Einsatz von Werkzeugen dadurch verhindert -> Werkzeuge sind in der Regel aber besser als manuelle Tätigkeiten! Sommersemester 2009 SW 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 Sommersemester 2009 SW 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 Sommersemester 2009 SW 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 Sommersemester 2009 SW 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 es bleibt theoretische Restfehlerwahrscheinlichkeit doppelter Aufwand sehr gut in der Praxis Sommersemester 2009 SW 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. Sommersemester 2009 SW 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 Sommersemester 2009 SW 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 Sommersemester 2009 SW 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) Sommersemester 2009 SW 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 Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Formale Verifikation in SCADE

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 Sommersemester 2009 SW 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 Sommersemester 2009 SW 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 Linear Nicht linear 5 * X + Y X * Y + 1 Z / 2 - W Z / T - 5 (T%3) * 2 W % P * 3 Mathematische Funktionen (sin, cos, sqrt) und Potenzen gehen nicht! Sommersemester 2009 SW in sicherheitsrelevanten Systemen

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

Einige abgeleitete temporale Operatoren
AtLeastNTick: wird immer dann true, wenn Input1 n-mal hintereinander true war; false sonst Sommersemester 2009 SW 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 Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Übersetzung SCADE in Aussagenlogik
Automaten durch Datenflussbeschreibung ersetzen Alle fby(…, n,…) durch fby(…,1, …) ersetzen Hilfvariablen einführen, so dass nur noch fby(xi, 1, …) vorkommt  Jetzt gibt es nur noch, Logik, Arithmetik, fby(xi, 1, …) SCADE-Knoten node anObserver (x1, …, xn) returns (Prop: bool) wird übersetzt zu Boole’scher Funktionen f(i, x1, ..., xn, pre(x1), …, pre(xn)) Induktionsbeweis mit Stålmarks Algorithmus: Beweise f(true, x1, ..., xn, pre(x1), …, pre(xn)) f(false, x1, …, xn, pre(x1), ..., pre(xn))  f(false, y1, …, yn, x1, …, xn) Sommersemester 2009 SW 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 Boole‘sche Funktion – Gleichen werden zu logishen Äquivalenzen) Sommersemester 2009 SW in sicherheitsrelevanten Systemen

Software in sicherheitsrelevanten Systemen

Ähnliche Präsentationen

Präsentation zum Thema: "Software in sicherheitsrelevanten Systemen"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Software in sicherheitsrelevanten Systemen

Ähnliche Präsentationen

Präsentation zum Thema: "Software in sicherheitsrelevanten Systemen"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback