Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2014
Software in sicherheitsrelevanten Systemen
Ralf Pinger / Stefan Gerken
Sommersemester 2014
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 2
Kapitel 1 - Was sind Sicherheit und Verfügbarkeit?
Inhaltsübersicht
1. Motivation2. Definitionen3. systematische und zufällige Fehler
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 3
1.1 Motivation – Der 1. Vorfall
Zusammenstoß zweier S-Bahnen im Bahnhof Flughafen Hannover-Langenhagen, 29.06.2000
Bahnhof Flughafen
S-Bahn 5712 (verspätet)S-Bahn 5711
PZB - Indusi
Signal
Weiche
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 4
1.1 Motivation – Die Bahn
Das Signal dient zur Informations-übermittlung an den Zug und über-mittelt z.B.
Erlaubnis zur Einfahrterlaubte Geschwindigkeit…
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 5
1.1 Motivation – Die Bahn
Die Weiche
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 6
1.1 Motivation – Die Bahn
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
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 7
1.1 Motivation – Die Bahn
Funktionen der 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.
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 8
1.1 Motivation – Die Bahn
Beispielstrecke
1000 m Mind. 200 m
450 m
1000 Hz 2000 Hz500 Hz
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 9
1.1 Motivation – Die Bahn
Wirkprinzip der PZB/Indusi
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 10
1.1 Motivation – Die Bahn
Die „Nachrichten“ der PZB/Indusi lauten:
• 500-Hz-Magnete
• Ist 250 bis 150 m vor Hauptsignalen, die besondere Gefahrenpunkte decken.
• falls zu schnell, erfolgt Zwangsbremsung
• 1000-Hz-Magnet
• Ist am Vorsignal bzw. Überwachungssignal eines Bahnübergangs
• Wachsamkeitstaste innerhalb 4 s betätigen, sonst Zwangsbremsung
• falls zu schnell, erfolgt Zwangsbremsung
• 2000-Hz-Magnet
• Ist am Hauptsignal
• Zwangsbremsung falls Halt-Signal
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 11
1.1 Motivation – Die Bahn
Französische Alternative zur Indusi
Krokodil (1920er Jahre) Signalbegriff wird als positive
oder negative Spannung dargestellt(Spannung ca. +/- 20 V)
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 12
1.1 Motivation – Die Bahn
Europäische Alternative zur Indusi
Eurobalisen Übertragung von Datenpaketen möglich
(mehrere Bytes) Übertragung von Fahrprofilen möglich Verbesserte Ortung möglich
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 13
1.1 Motivation – Die Bahn
Punktförmige Zugsicherung
Live-Demo TBL1+
(TBL1+ ist ein Zugsicherungssystem der belgischen Bahn)
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 14
1.1 Motivation – Fortsetzung des 1. Vorfalls
Was geschah
S-Bahn 5711 stand ab 09:53 Uhr abfahrbereit vor Ausfahrsignal, geplante Abfahrt 10:10 Uhr
S-Bahn 5712 hat 7 Minuten Verspätung, erwartete Ankunftszeit 10:11 Uhr
S-Bahn 5712 erhält Erlaubnis zur Einfahrt in Bahnhof
S-Bahn 5711 steht vor Halt zeigendem Signal!
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 15
1.1 Motivation – Fortsetzung des 1. Vorfalls
Ausgangssituation beim Zusammenstoß zweier S-Bahnen im Bahnhof Flughafen Hannover-Langenhagen, 29.06.2000
Bahnhof Flughafen
S-Bahn 5712 (verspätet)S-Bahn 5711
PZB - Indusi
Signal
Weiche
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 16
1.1 Motivation – Fortsetzung des 1. Vorfalls
Was ist passiert?
• S-Bahn 5711 startet um 10:10 Uhr
• Ausfahrsignal für S-Bahn 5711 stand auf Halt
• Indusi erzeugt Zwangsbremsung für S-Bahn 5711
• Triebfahrzeugführer von S-Bahn 5711 drückt Freitaste und fährt wieder los!
• S-Bahn 5711 fährt die Einfahrweiche auf
• S-Bahn 5712 war zu diesem Zeitpunkt schon an seinem Einfahrsignal vorbei
• -> keine ZB mehr möglich!
• Noch im Tunnel stoßen S-Bahnen 5711 und 5712 frontal zusammen
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 17
1.1 Motivation – Fortsetzung des 1. Vorfalls
Unfallfolgen:
• 16 Personen verletzt
• 3.600.000 DM Sachschaden
• Wiederinbetriebnahme der Strecke erst am 30.06.00, 04:00 Uhr, einen ganzen Tag später
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 18
1.1 Motivation – Fortsetzung des 1. Vorfalls
Fazit:
• keine kausale Beteiligung technischer Komponenten/Einrichtungen
• S-Bahn 5711 erhielt Zwangsbremsung
• Ursache:unerlaubte Weiterfahrt von S-Bahn 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
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 19
1.1 Motivation – Fortsetzung des 1. Vorfalls
Weiteres Fazit:
• Das Sicherungssystem hat die Fehlhandlung des Triebfahrzeugführers erkannt
• Das Sicherungssystem hat eingegriffen
• nach erfolgter technischer Reaktion übernimmt der Mensch wieder die Verantwortung
• offenbar hat der Mensch die Zwangsbremsung nicht dem Hauptsignal zugeordnet
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 20
1.1 Motivation – Fortsetzung des 1. Vorfalls
Mögliche 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
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 21
1.1 Motivation – Systemkomplexität
Ist menschliches Versagen als Unfallursache 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 und nicht umgekehrt!
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 22
1.1 Motivation – Systemkomplexität
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 23
1.1 Motivation – Der Vorfall in Genthin 1939
Betriebliche Randbedingungen
22.12.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
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 24
1.1 Motivation – Der Vorfall in Genthin 1939
Der Ablauf
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
D 180 sieht nun nur noch „Fahrt“-Signale – die von D 10!
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 25
1.1 Motivation – Der Vorfall in Genthin 1939
Der Ablauf
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
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 26
1.1 Motivation – Der Vorfall in Genthin 1939
Das Verhängnis 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)
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 27
1.1 Motivation – Der Vorfall in Genthin 1939
Die Unfallfolgen
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
Zufall oder nicht?
weiterer Unfall in derselben Nacht mit 101 Toten, 28 Verletzten
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 28
1.1 Motivation – Der Vorfall in Genthin 1939
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
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 29
1.1 Motivation – Der Vorfall in Genthin 1939
Hätte Genthin verhindert werden können?
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!
Urteil:
Lokführer wurde zu 3 Jahren Gefängnis verurteilt!
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 30
1.1 Motivation
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?
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 31
1.1 Motivation – Die Vorlesung
Wie entwickelt man Software, die in sicherheitsrelevanten Systemen ausgeführt wird?
Nicht Inhalt dieser Vorlesung:
Entwicklung sicherer Hardware
Entwurf sicherheitsrelevanter Betriebskonzepte
Ergonomie sicherheitsrelevanter HMI
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 32
1.2 Definitionen
RAMSSCenter
ofCompetence
Reliability
RAvailability
A
Maintainability
MSafety
S
Security
S
TOP
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 33
1.2 Definitionen
Zusammenhänge RAMSS und GefährdungGefährdungim Betrieb
Techniknicht
verfügbar
Menschliches Versagen
Menschlicher Fehler
Rückfallebene
TechnischeÜberwachung
versagt
ZufälligeAusfälle/Störungen
Systematische Fehler
Hier wird in der Regelangenom m en, dass der Menschkeine S icherheitsverantwortung
hat
Anforderung: Hazard Rate HR(alt: wrong side failure rate)
Anforderung: S IL
Anforderung: Verfügbarkeit AAnforderung an die m enschliche
Zuverlässigkeit
BetrieblicheGefährdung
Subsystem -gefährdung
Normalbetrieb
Sabotage/Vorsatz
Zugriffskontrolle/ -schutz
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 34
1.2 Definitionen
Die Domäne als Biotop
Jede Domäne hat eigene Begriffe, die sich in Details unterscheiden
Jede Domäne hat eigene Vorgehensweisen, die sich im Detail unterscheiden
Jede Domäne hat das Ziel der funktionalen Sicherheit
Die Verfahren und Vorgehensweisen ähneln sich, so dass das Verständnis von RAMSS übertragbar ist, die Methoden aber im Detail anders gewichtet und angewendet werden. Damit ist aber nicht zwangsläufig eine andere Wirksamkeit verbunden
Hier also Definitionen der Bahntechnik (CENELEC)
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 35
1.2 Definitionen – Sicherheit
Sicherheit (EN 50126)
Das Nichtvorhandensein eines unzulässigen Schadensrisikos (kurz: Freiheit von nicht akzeptablen Risiken)
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.
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 36
1.2 Definitionen – Gefährdung, Gefahr
Gefährdung
Keine explizite Definition in der Norm
Sprachlich: Eine gefährliche Situation
Gefahr (EN 50126)
Eine physikalische Situation, die potentiell einen Schaden für den Menschen beinhaltet.
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 37
1.2 Definitionen – Risiko
Risiko (EN 50126)
Die Wahrscheinlichkeit des Auftretens einer Gefahr, die einen Schaden verursacht, sowie der Schweregrad eines Schadens
Vereinfacht:
Risiko = Schadensausmaß * Schadenshäufigkeit
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 38
1.2 Definitionen – Zuverlässigkeit
Zuverlässigkeit (EN 50126)
Die Wahrscheinlichkeit dafür, dass eine Einheit ihre geforderte Funktion unter gegebenen Bedingungen für eine gegebene Zeitspanne (t1, t2) erfüllen kann. [IEC 60050(191)]
Mögliche Anforderung:
Mean Time Between Failure (MTBF) Mean Time To Failure (MTTF) Mean Up Time (MUT) Mean Distance Between Failure (MDBF)
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 39
1.2 Definitionen – Zuverlässigkeit
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 40
1.2 Definitionen – Verfügbarkeit
Verfügbarkeit (EN 50126)
Die Fähigkeit eines Produkts, in einem Zustand zu sein, in dem es unter vorgegebenen Bedingungen zu einem vorgegebenen Zeitpunkt oder während einer vorgegebenen Zeitspanne eine geforderte Funktion erfüllen kann unter der Voraussetzung, dass die geforderten äußeren Hilfsmittel bereitstehen.
Mögliche Anforderung:
A = MUT/(MUT + MDT); 0 ≤ A ≤ 1 mit MUT = Mean Up Time MDT = Mean Down Time
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 41
1.2 Definitionen – Instandhaltbarkeit
Instandhaltbarkeit (EN 50126)
Die Wahrscheinlichkeit, dass für eine Komponente unter gegebenen Einsatzbedingungen eine bestimmte Instandhaltungsmaßnahme innerhalb einer festgelegten Zeitspanne ausgeführt werden kann, wenn die Instandhaltung unter festgelegten Bedingungen erfolgt und festgelegte Verfahren und Hilfsmittel eingesetzt werden. [IEC 60050(191)]
Mögliche Anforderung:
Mean Down Time (MDT) Mean Time Between Maintenance (MTBM) Mean Distance Between Maintenance (MDBM) Mean Time To Repair (MTTR)
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 42
1.2 Definitionen – System Safety
Anderes Beispiel - MIL-STD-882C
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.
Purpose of Software System Safety Handbook (MIL-STD)
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.
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 43
1.2 Definitionen – System
EN50129: System ist: Eine Menge von Teilsystemen, die entsprechend einem
Entwurf zusammenwirken. Teilsystem ist: Ein Teil eines Systems, der eine spezielle Funktion erfüllt Element ist: ein Teil eines Produktes, der als Grundeinheit oder
Grundbaustein bestimmt wurde. Ein Element kann einfach oder komplex sein.
MIL Std 882 C System: A composite, at any level of complexity, of personnel,
procedures, materials, tools, equipment, facilities, and software. The elements of this composite entity are used together in the intended operational or support environment to perform a given task or achieve a specific purpose, support, or mission requirement.
Subsystem: An element of a system that, in itself may constitute a system.
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 44
1.2 Definitionen – System
System
ISO 9000 Systembegriff bezieht sich auf die Wechselwirkung von Prozessen
Problem: Die Definition von Begriffen wie System oder Funktion ist willkürlich,
... und wahrscheinlich wird niemals eine universelle Definition gelingen.
ABER: Die Sicherheit darf nicht davon abhängen, ob eine Funktion von einem „System” oder „Element” erbracht wird oder gar nur von einer Definition.
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 45
1.2 Definitionen
System - Eigenschaften
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.
Daraus folgt:
Der Benutzer muss das zu betrachtende „System” klar und eindeutig definieren.
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
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 46
1.2 Definitionen
System - Eigenschaften
Subsystem
Relevantes Universum
Anlage
System
System
Subsystem Subsystem
Systemelemente
HW-Komponenten
SW-Komponenten
SSt
SSt
SSt
SSt
SSt
SSt
SSt
SSt
SSt
SSt
SSt
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 47
1.2 Definitionen
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 beziehungsweise Systemarchitektur dargestellt?
Sind die einzelnen Architekturelemente definiert?
Ist ihr Zusammenwirken eindeutig definiert?
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 48
1.3 RAMSS für Systeme/Produkte
Was bedeutet RAMSS für Eisenbahnsignaltechnik?
Zwingend notwendige Produkteigenschaften, ohne deren Nachweis die Produkte nicht marktfähig sind
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
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 49
1.3 Sicherheit von Systemen/Produkten
Wann ist etwas sicher?
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 Fehlern?
Auf welche Betrachtungseinheit bezieht sich die Sicherheit?
Was ist überhaupt ein Fehler?
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 50
1.3 Anforderungen und Sicherheitsanforderungen
Sicherheitsanforderungen
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 51
1.3 Systematische und physische (zufällige) Fehler
Klassifikation von Fehlern
Physische (zufällige) Fehler Hardwarefehler als Folge von Alterung Verschleiß ausgefallene Transistoren
Ursache: Physik
Systematische Fehler mangelhafter Entwurf Programmierfehler fehlerhafte Dimensionierung der Hardware
Ursache: Mensch
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 52
1.3 systematische und physische Fehler
Klassifikation von Fehlern
Unterscheidung
systematische Fehler treten nach Beseitigung nicht mehr auf physische Fehler können sich jederzeit wiederholen
Übergang kann fließend sein:
Unterdimensionierter Kühlkörper eines Transistors
Aber: eigentlich ist das ein systematisches Problem
Mögliche Ursache?
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 53
1.3 systematische und physische Fehler
Folgerung:
Hardware
physische Fehler möglich systematische Fehler möglich
Software
physische Fehler nicht möglich systematische Fehler möglich
Software in sicherheitsrelevanten SystemenSommersemester 2014
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel
Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
11.04.23 Ralf Pinger / Stefan GerkenPage 54
1.3 systematische und physische Fehler
Für diese Vorlesung folgt daraus:
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.
Vermeiden von systematischen Fehlern in der Software
Für sicherheitsrelevante Hardware folgt daraus:
Erkennen von physischen Fehlern Beherrschen von physischen Fehlern (falls vorhanden einen sicheren
Zustand einnehmen) Vermeiden von systematischen Fehlern Wohldefiniertes Verhalten (und auch dokumentiert) Nicht Inhalt dieser Vorlesung