1 / 54

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. 1.1 Motivation – Der 1. Vorfall.

kamin
Download Presentation

Software in sicherheitsrelevanten Systemen

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2013

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

  3. 1.1 Motivation – Der 1. Vorfall • Zusammenstoß zweier S-Bahnen im Bahnhof Flughafen Hannover-Langenhagen, 29.06.2000 Ralf Pinger / Stefan Gerken

  4. 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

  5. 1.1 Motivation – Die Bahn • Die Weiche Ralf Pinger / Stefan Gerken

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

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

  8. 1.1 Motivation – Die Bahn • Beispielstrecke Ralf Pinger / Stefan Gerken

  9. 1.1 Motivation – Die Bahn • Wirkprinzip der PZB/Indusi Ralf Pinger / Stefan Gerken

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

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

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

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

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

  15. 1.1 Motivation – Fortsetzung des 1. Vorfalls • Ausgangssituation beim Zusammenstoß zweier S-Bahnen im Bahnhof Flughafen Hannover-Langenhagen, 29.06.2000 Ralf Pinger / Stefan Gerken

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

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

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

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

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

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

  22. 1.1 Motivation – Systemkomplexität Ralf Pinger / Stefan Gerken

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

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

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

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

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

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

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

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

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

  32. 1.2 Definitionen • RAMSS Ralf Pinger / Stefan Gerken

  33. 1.2 Definitionen • Zusammenhänge RAMSS und Gefährdung Ralf Pinger / Stefan Gerken

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

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

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

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

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

  39. 1.2 Definitionen – Zuverlässigkeit Ralf Pinger / Stefan Gerken

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

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

  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 reasonablelevel of assurance that software will execute within the system context with an acceptable level of safety risk. Ralf Pinger / Stefan Gerken

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

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

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

  46. 1.2 Definitionen • System - Eigenschaften Ralf Pinger / Stefan Gerken

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

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

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

  50. 1.3 Anforderungen und Sicherheitsanforderungen • Sicherheitsanforderungen Ralf Pinger / Stefan Gerken

More Related