Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2013

Software in sicherheitsrelevanten Systemen

Ralf Pinger / Stefan Gerken

Sommersemester 2013

Software in sicherheitsrelevanten SystemenSommersemester 2013

Model basedDevelopment

Model basedTesting

Modeltrans-formation

Applicationmodel

Test model

Code (executable)


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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



1.1 Motivation – Die Bahn

Das Signal dient zur Informations-übermittlung an den Zug und über-mittelt z.B.

Erlaubnis zur Einfahrterlaubte Geschwindigkeit…



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




Die Weiche



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




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.



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




Beispielstrecke

1000 m Mind. 200 m

450 m

1000 Hz 2000 Hz500 Hz



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




Wirkprinzip der PZB/Indusi



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




Französische Alternative zur Indusi

Krokodil (1920er Jahre) Signalbegriff wird als positive

oder negative Spannung dargestellt(Spannung ca. +/- 20 V)



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




Europäische Alternative zur Indusi

Eurobalisen Übertragung von Datenpaketen möglich

(mehrere Bytes) Übertragung von Fahrprofilen möglich Verbesserte Ortung möglich



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




Punktförmige Zugsicherung

Live-Demo TBL1+

(TBL1+ ist ein Zugsicherungssystem der belgischen Bahn)



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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!



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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!



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



1.1 Motivation – Systemkomplexität



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




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!



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




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)



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




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!



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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?



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



1.2 Definitionen

RAMSSCenter

ofCompetence

Reliability

RAvailability

A

Maintainability

MSafety

S

Security

S

TOP



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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)



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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.



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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.



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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)



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



1.2 Definitionen – Zuverlässigkeit



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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.


A = MUT/(MUT + MDT); 0 ≤ A ≤ 1 mit MUT = Mean Up Time MDT = Mean Down Time



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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)]


Mean Down Time (MDT) Mean Time Between Maintenance (MTBM) Mean Distance Between Maintenance (MDBM) Mean Time To Repair (MTTR)



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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.



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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.



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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.



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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?



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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?



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



1.3 Anforderungen und Sicherheitsanforderungen

Sicherheitsanforderungen



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis



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?



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




Folgerung:

Hardware

physische Fehler möglich systematische Fehler möglich

Software

physische Fehler nicht möglich systematische Fehler möglich



Model basedTesting


Applicationmodel

Test model

Code (executable)



Analysis




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

Documents

Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2013