Software in sicherheitsrelevanten Systemen

Software in sicherheitsrelevanten Systemen
Ralf Pinger / Stefan Gerken Sommersemester 2013

Kapitel 1 - Was sind Sicherheit und Verfügbarkeit?
Inhaltsübersicht Motivation Definitionen systematische und zufällige Fehler Ralf Pinger / Stefan Gerken

1.1 Motivation – Der 1. Vorfall
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. Ralf Pinger / Stefan Gerken

Erlaubnis zur Einfahrt erlaubte Geschwindigkeit …
1.1 Motivation – Die Bahn Das Signal dient zur Informations-übermittlung an den Zug und über-mittelt z.B. Erlaubnis zur Einfahrt erlaubte Geschwindigkeit … Ralf Pinger / Stefan Gerken

1.1 Motivation – Die Bahn Die Weiche 21.03.2017
Ralf Pinger / Stefan Gerken

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 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) Oben: Montage am Drehgestell Ralf Pinger / Stefan Gerken

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. Unterschied zwischen Indusi und PZB: Äpfel und Birnen, da PZB die Abkürzung für punktförmige Zugbeeinflussung ist und die Indusi eine von vielen Möglichkeiten darstellt. Andere wäre ZUB121, ZUB123 (Dänemark) oder sogar ETCS Level 1 ohne Infill (jeweils steigender Informationsgehalt der Telegramme) Ralf Pinger / Stefan Gerken

1.1 Motivation – Die Bahn Beispielstrecke
1000 Hz –Langsam fahren bzw. Halt zeigendes Signal (Hp0) wird in ca. 1000 m erreicht 500 Hz – ca. 250 m vor den Hauptsignalen (Hp0) 2000 Hz –an Hauptsignalen (Hp0). Sofortige Zwangsbremsung bei Überfahren. Ralf Pinger / Stefan Gerken

Wirkprinzip der PZB/Indusi
1.1 Motivation – Die Bahn Wirkprinzip der PZB/Indusi Die genauen physikalischen Zusammenhänge – wie Anordnung der Kondensatoren, Übertragung der unterschiedlichen Frequenzen, etc. – sind dem Selbststudium überlassen. Generelles Prinzip: Am Triebfahrzeug befindet sich auf der rechten Seite ein Fahrzeugmagnet mit drei Schwingkreisen, die vom Fahrzeuggerät mit je einer der drei Frequenzen 500, 1000 und 2000 Hz gespeist wird. In jedem Strompfad befindet sich ein in Grundstellung angezogenes Impulsrelais. Am Gleis liegen so genannte Gleismagneten, die ebenfalls einen oder mehrere auf obige Frequenzen abgestimmte Schwingkreise enthalten. Diese sind in Grundstellung aktiv. Beim Befahren kommt es durch Resonanzwirkungen zu einem Stromabfall in der Sendespule, das betreffende Impulsrelais fällt ab. Dies wird registriert und verarbeitet. Sollen Schwingkreise wegen Fahrtstellung des betreffenden Signals unwirksam sein, werden sie bei Flügel- bzw. Lichtsignalen durch Relaiskontakte kurzgeschlossen und damit soweit verstimmt, dass keine Beeinflussung des Fahrzeuggerätes erfolgt. Ralf Pinger / Stefan Gerken

Die „Nachrichten“ der PZB/Indusi lauten:
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 2000-Hz-Magnet Ist am Hauptsignal Zwangsbremsung falls Halt-Signal Die Informationen der einzelnen Schwingkreisfrequenzen sind: 1000 Hz − Vor Langsamfahrstellen, Vorsignalen, Überwachungssignalen (Schaltung ab Vziel < 100 km/h); Langsam fahren bzw. Halt zeigendes Signal wird in ca. 1000 m erreicht 500 Hz − Vor Langsamfahrstellen / 250 m vor den Hauptsignalen (Schaltung ab Vziel <= 30 km/h); Langsam fahren mit bis zu 30 km/h bzw. Halt zeigendes Signal wird in ca. 250 m erreicht 2000 Hz − Fahrsperre, an Hauptsignalen in Haltstellung (Hp0). Sofortige Zwangsbremsung bei Überfahren. Ralf Pinger / Stefan Gerken

Französische Alternative zur Indusi Krokodil (1920er Jahre)
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) 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. Ralf Pinger / Stefan Gerken

Europäische Alternative zur Indusi
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 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 gibt es als Festdatenbalisen oder als schaltbare Balisen. Schaltbare Balisen haben einen variablen Nachrichtenanteil. In diesem kann beispielsweise der Signalbegriff (Fahrt, Halt, Halt-Erwarten, …) in Abhängigkeit von der aktuellen Streckensituation übertragen werden. An diese Balisen ist ein Kabel angeschlossen. Festdatenbalisen können nur die darin gespeicherten Daten übertragen. Sie dienen als reine Kilometersteine bzw. zur Übertragung fixer Streckendaten (Beginn einer Langsamfahrstrecke oder ähnliches). Eurobalisen sind immer passive Elemente, die ihre Energie zum Senden vom Fahrzeug induziert bekommen. Ralf Pinger / Stefan Gerken

Punktförmige Zugsicherung Live-Demo TBL1+
1.1 Motivation – Die Bahn Punktförmige Zugsicherung Live-Demo TBL1+ (TBL1+ ist ein Zugsicherungssystem der belgischen Bahn) Ralf Pinger / Stefan Gerken

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! Der Zusammenstoß der beiden S-Bahnen kann als Untersuchungsbericht von den Seiten des Eisenbahnbundesamts(EBA) heruntergeladen werden. Dort sind auch noch weitere Unfallberichte zu finden. Ein etwas bekannteres Unglück ist beispielsweise die Entgleisung von Brühl. Ralf Pinger / Stefan Gerken

Ausgangssituation beim Zusammenstoß zweier S-Bahnen im Bahnhof Flughafen Hannover-Langenhagen, 5711 stand ab 09:53 Uhr abfahrbereit vor dem Ausfahrsignal, geplante Abfahrt war 10:10 Uhr 5712 hat 7 Minuten Verspätung, erwartete Ankunftszeit war 10:11 Uhr 5712 erhält Erlaubnis zur Einfahrt in den 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! (Nachteil von PZB gegenüber LZB: keine dauernde Beeinflussung sondern nur an den Signalstandorten) Noch im Tunnel stoßen 5711 und 5712 frontal zusammen! Ralf Pinger / Stefan Gerken

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

Unfallfolgen: 16 Personen verletzt DM Sachschaden Wiederinbetriebnahme der Strecke erst am , 04:00 Uhr, einen ganzen Tag später Ralf Pinger / Stefan Gerken

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

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

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

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! 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-Schnittstelle feststellen. Unsere Systeme 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. Zusätzlich ist zu beachten, dass bei Unternehmen wie der DB der Betriebsrat ein Mitspracherecht bei der Einrichtung von Arbeitsplätzen und zugehöriger Schulung der Triebfahrzeugführer besitzt, was für die Änderung zusätzliche organisatorischen Aufwand bedeutet. Aufgabe der Sicherungstechnik ist also auch, leicht anpassbare Systeme zu entwerfen. Bei Realisierung mit Hilfe eines Computerdisplays als Bedienpult, wäre die Information der Bremsursache – die ja im Fahrzeuggerät bereits bekannt ist – ohne zusätzliche Änderungen an der Hardware einfach möglich. Diese Funktionalität könnte über ein SW-Update einfach eingespielt werden. Problematisch könnte bei einem Computerdisplay allerdings das Thema der Sicherheit werden. Hier sind zusätzliche Betrachtungen erforderlich, so wie das auch im Bereich der Luftfahrt geschieht. 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 und die Ergonomie frühzeitig untersucht wird. Ergonomie, Wartbarkeit und Änderbarkeit sind also entscheidende Faktoren für die Langlebigkeit eines System – vor allem eines Systems welches Sicherheitsverantwortung trägt! Ralf Pinger / Stefan Gerken

1.1 Motivation – Systemkomplexität
Ralf Pinger / Stefan Gerken

1.1 Motivation – Der Vorfall in Genthin 1939
Betriebliche Randbedingungen : 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 Ralf Pinger / Stefan Gerken

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

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

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

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

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 und Zufälle 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 waren zum Zeitpunkt des Unglücks bekannt und bereits als Produkt verfügbar. Die Anpassung an die Transrapid-Strecke wurde nicht durchgeführt. Grundprinzip: Die Verwendung eines technischen Systems darf das allgemeine Lebensrisiko nicht signifikant erhöhen. Ralf Pinger / Stefan Gerken

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

Einfluss von Software auf Unfälle
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? Ralf Pinger / Stefan Gerken

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 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), Mechanik (Rüttel-Schüttel), chemische Einflüsse 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 betrachten. Wir wollen dies nicht in dieser VL vertiefen (Vorlesung gibt es im IfEV bei Prof. Jens Braband). Dennoch spielt es eine sehr wichtige Rolle für die Gesamtsicherheit eines Systems. Ralf Pinger / Stefan Gerken

RAMSS 1.2 Definitionen 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, SSL im Internet etc.) Ralf Pinger / Stefan Gerken

Zusammenhänge RAMSS und Gefährdung
1.2 Definitionen Zusammenhänge RAMSS und Gefährdung 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. Dementsprechend 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 neigt jedoch zu Fehlern – 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 ? Ralf Pinger / Stefan Gerken

Die Domäne als Biotop 1.2 Definitionen
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) Ralf Pinger / Stefan Gerken

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

1.2 Definitionen – Gefährdung, Gefahr
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. Ralf Pinger / Stefan Gerken

Risiko (EN 50126) 1.2 Definitionen – Risiko Vereinfacht:
Die Wahrscheinlichkeit des Auftretens einer Gefahr, die einen Schaden verursacht, sowie der Schweregrad eines Schadens Vereinfacht: Risiko = Schadensausmaß * Schadenshäufigkeit Die Formel ist ohne Rücksicht auf Einheiten aufgestellt Die Häufigkeit ist in der CENELEC eine Rate und keine Wahrscheinlichkeit (im Gegensatz zur IEC 61508) Ralf Pinger / Stefan Gerken

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) MTBF ist die Abkürzung für das englische Mean Time Between Failures, zu deutsch die mittlere Betriebsdauer zwischen Ausfällen. Sie gilt für Einheiten, die instandgesetzt werden; Betriebsdauer meint die Betriebszeit zwischen zwei aufeinanderfolgenden Ausfällen einer instand zu setzenden Einheit. Die Definition nach IEC (191) lautet: Der Erwartungswert der Betriebsdauer zwischen zwei aufeinanderfolgenden Ausfällen. Für Einheiten die nicht instandgesetzt werden, ist der Erwartungswert (Mittelwert) der Verteilung von Lebensdauern die mittlere Lebensdauer MTTF (engl. mean time to failure). Umgangssprachlich werden die Begriffe oft synonym verwendet (in diesem Fall hat sich das Backronym „mean time before failure“ eingebürgert). mean distance between failure (plural mean distance between failures) abbreviated as MDBF (rail transport, road transport) A measure of reliability that expresses the average distance travelled by a type of lorry, bus, rolling stock, etc, before preventative or reparative maintenance is required. Ralf Pinger / Stefan Gerken

1.2 Definitionen – Zuverlässigkeit
ggf, ist die Zeit zwischen Ausfällen auch die Zeit zwischen den fallenden Flanken, da in diesem Fall die Reparaturzeiten dazu zählen. Hier ist auf die jeweilige Definition zu achten. Hier wird es so betrachtet wie oben definiert Ralf Pinger / Stefan Gerken

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 Die Verfügbarkeit A des Systems kann durch Aufteilung in geplante Nichtverfügbarkeit (Instandhaltung): 1 – AM, ungeplante Nichtverfügbarkeit (Reparatur): 1 – AR festgelegt werden. Es folgt daraus: A = [(1 – AM) + (1 – AR)] und A = MUT/(MUT + MDT); 0 ≤ A ≤ 1 Dabei ist: MUT = Mean Up Time, oder substituiert durch MTBF, MTBSF usw.; MDT = Mean Down Time, oder substituiert durch MTTM, MTTR usw.; MUT und MDT sind für die spezifische Verfügbarkeit A(.) zu definieren, z. B. für die Verfügbarkeit AS des „sicheren Systems“ (MUT = MTBSF). Die sich aus der Einsatzzeit (z. B. 1 Jahr) ergebende „down time“ d(T) ist somit: d(T) = (1 – A) * T Ralf Pinger / Stefan Gerken

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) Auch Wartbarkeit genannt Ralf Pinger / Stefan Gerken

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

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. Der Begriff System ist in der Literatur sehr unterschiedlich definiert, so dass es ratsam ist, eine Definition von System zu verabreden, die innerhalb eines Kontexts verwendet wird. Ralf Pinger / Stefan Gerken

System 1.2 Definitionen – 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. Ralf Pinger / Stefan Gerken

System - Eigenschaften
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 Der Begriff System ist in der Literatur sehr unterschiedlich definiert, so dass es ratsam ist, eine Definition von System zu verabreden, die innerhalb eines Kontextes verwendet wird. Ralf Pinger / Stefan Gerken

System - Eigenschaften
1.2 Definitionen System - Eigenschaften 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 diffiziler. 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. (Populäres Beispiel: der Unfall der Ariane 5) Legende: SSt = Schnittstelle Ralf Pinger / Stefan Gerken

System – Checkliste 1.2 Definitionen
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? Man kann auch versuchen über Eigenschaften eine Definition zu erlangen. Diese Checkliste soll genau dazu dienen, die minimalen Eigenschaften eines (Sub-)Systems darzustellen. Zur Systemdefinition gehören unter anderem auch Anforderungen an Performance, Ressourcen, Timing, Sicherheit, Verfügbarkeit, Bedienkonzepte, Benutzergruppen und deren Kompetenzen, Dokumentation Ralf Pinger / Stefan Gerken

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 Falls der Unfall „Eschede“ zum Beispiel auf einen Stellwerksfehler zurückzuführen wäre, wäre das Vertrauen in die Produkte des Herstellers so stark erschüttert, dass er wahrscheinlich vom Markt verschwinden würde. 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: Das heißt, man testet 1 Einheit 5 Mio. Jahre, 5 Mio. Einheiten 1 Jahr usw. Dies ist nicht praktikabel. Deswegen muss der Sicherheitsnachweis auf Modellrechnungen und entsprechenden Annahmen beruhen. Das heißt, die Sicherheit kann nur plausibel gemacht werden, aber nicht „bewiesen“. Ralf Pinger / Stefan Gerken

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? Zuviel „Wasser unter dem Kiel“ heißt, dass die Produkte möglicherweise zu teuer sind. Zuwenig „Wasser unter dem Kiel“ bedeutet Sicherheitsprobleme. Ralf Pinger / Stefan Gerken

1.3 Anforderungen und Sicherheitsanforderungen
Abbildung aus EN50129 Ralf Pinger / Stefan Gerken

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 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 Verschleiß der Hardware überprüft wird und Verschleißteile 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 ist in der Regel unvermeidlich. Deshalb müssen diese Teile regelmäßig überprüft werden, damit der Fehler durch Verschleiß gar nicht erst auftritt (vorbeugende Wartung). 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 – die Ausfälle gelten aufgrund der physikalischen Natur von Halbleitern als exponentialverteilt, eine gemeinhin als gedächtnislos bekannte Verteilungsfunktion. 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. Ralf Pinger / Stefan Gerken

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? Fehlerhafte Dimensionierung kann zum Beispiel ein Problem mit den Anforderungen sein, wenn man etwas für mitteleuropäische Temperaturen dimensioniert, die Elektronik dann aber in der Sahara einsetzt. Ralf Pinger / Stefan Gerken

Folgerung: Hardware physische Fehler möglich systematische Fehler möglich Software physische Fehler nicht möglich 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. Ralf Pinger / Stefan Gerken

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

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