Software in sicherheitsrelevanten Systemen

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

2. Stundenzahl: 2V + 1Ü Vorlesung:Do. 08:00 - 09:30 Uhr in IZ 161 Do, 07.05.08 Do, 14.05.09 Do, 28.05.09 Blockveranstaltung Exkursionswoche 02. - 05.06.2009 Do, 11.06.09 Do, 25.06.09 Do, 02.07.09 Do, 09.07.09 Block: VL + UE vom 02.06. – 05.06. (Ex-Woche): Di 02.06.: 8:00 - 16:00 Mi 03.06.: 8:00 - 16:00 Do 04.06.: 8:00 - 16:00 Fr 05.06.: 8:00 - 11:30 Inhalt: praktischer Umgang mit SCADE Schulung erfolgt durch Esterel Sprechstunde: nach Vereinbarung Prüfung: nach Vereinbarung Kontakt: Ralf.Pinger@siemens.com Organisatorisches SW in sicherheitsrelevanten Systemen

3. Inhalt • Motivation • RAMS/Normen • SCADE/modellbasierte Entwicklung • Qualifizierung von Entwicklungswerkzeugen SW in sicherheitsrelevanten Systemen

4. 1. Motivation • Zusammenstoß zweier S-Bahnen im Bahnhof Flughafen Hannover-Langenhagen, 29.06.00 SW in sicherheitsrelevanten Systemen

5. Signal • übermittelt Erlaubnis zur Einfahrt • übermittelt erlaubte Geschwindigkeit SW in sicherheitsrelevanten Systemen

6. Weiche SW in sicherheitsrelevanten Systemen

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

8. Funktionen der PZB/Indusi • Die Wachsamkeitsprüfung überwacht, dass der Triebfahrzeugführer (Tf) beim Passieren eines Halt ankündenden Signals die Aufnahme des Signalbegriffs durch eine Tastenbedienung bestätigt. • Die Bremswegüberwachung überwacht den Bremsvorgang vor einem Halt zeigenden Signal. Dies erfolgt fahrzeugseitig durch diskrete Prüfpunkte (bei Altsystemen) oder kontinuierliche Überwachungskurven. • Die Fahrsperre löst beim Passieren eines Halt zeigenden Signals eine Zwangsbremsung aus. SW in sicherheitsrelevanten Systemen

9. Übertragungsprinzip Indusi SW in sicherheitsrelevanten Systemen

10. Sicherungsstufen PZB/Indusi • 500-Hz-Magnete 250 bis 150 m vor Hauptsignalen, die besondere Gefahrenpunkte decken.-> falls zu schnell dann Zwangsbremsung (ZB) • 1000-Hz-Magnet am Vorsignal bzw. Überwachungssignal eines Bahnübergangs-> Wachsamkeitstaste innerhalb 4 s, sonst ZB-> falls zu schnell dann ZB • 2000-Hz-Magnet am Hauptsignal-> immer ZB SW in sicherheitsrelevanten Systemen

11. Französische Alternative zur Indusi • Krokodil (1920er Jahre) • Signalbegriff wird als positive oder negative Spannung dargestellt (+/- 20 V) SW in sicherheitsrelevanten Systemen

12. Alternativen zur Indusi • Eurobalisen • komplexere Datenübertragung möglich (mehrere Bytes) SW in sicherheitsrelevanten Systemen

13. Live-Demo Zugsicherung(am Beispiel der belgischen Bahn) SW in sicherheitsrelevanten Systemen

14. Randbedingungen • 5711 stand ab 09:53 Uhr abfahrbereit vor Ausfahrsignal, geplante Abfahrt 10:10 Uhr • 5712 hat 7 Minuten Verspätung, erwartete Ankunftszeit 10:11 Uhr • 5712 erhält Erlaubnis zur Einfahrt in Bahnhof • 5711 steht vor Halt zeigendem Signal! SW in sicherheitsrelevanten Systemen

15. Ausgangssituation SW in sicherheitsrelevanten Systemen

16. Was ist passiert? • 5711 startet um 10:10 Uhr • Ausfahrsignal für 5711 stand auf Halt • Indusi erzeugt Zwangsbremsung für 5711 • Tf von 5711 drückt Freitaste und fährt wieder los! • 5711 fährt die Einfahrweiche auf • 5712 war zu diesem Zeitpunkt schon an seinem Einfahrsignal vorbei -> keine ZB mehr möglich! • Noch im Tunnel stoßen 5711 und 5712 frontal zusammen! SW in sicherheitsrelevanten Systemen

17. Unfallfolgen • 16 Personen verletzt • 3.600.000 DM Sachschaden • Wiederinbetriebnahme der Strecke erst am 30.06.00, 04:00 Uhr, einen Tag später SW in sicherheitsrelevanten Systemen

18. Fazit • keine kausale Beteiligung technischer Komponenten/Einrichtungen • 5711 erhielt Zwangsbremsung • Ursache:unerlaubte Weiterfahrt von 5711 • Auszug aus Regelwerk: „Ist ein Zug an einem Halt zeigenden Hauptsignal (...) unzulässig vorbeigefahren, ist nach dem Anhalten der Fahrdienstleiter sofort zu verständigen. Dies gilt auch bei einer Zwangsbremsung durch PZB an einem Hauptsignal (...), das eine Fahrtstellung (...) zeigt.“ Menschliches Versagen als Ursache SW in sicherheitsrelevanten Systemen

19. Fazit 2 • System hat die Fehlhandlung des Triebfahrzeugführers erkannt und hat eingegriffen • nach erfolgter technischer Reaktion übernimmt der Mensch wieder die Verantwortung! • offenbar hat der Mensch die Zwangsbremsung nicht dem Hauptsignal zugeordnet! SW in sicherheitsrelevanten Systemen

20. 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 SW in sicherheitsrelevanten Systemen

21. menschliches Versagen? • Ist das menschliche Versagen vorprogrammiert? • 22 aktenkundige Fälle zwischen 1994 und 2000: Tf fährt nach Zwangsbremsung durch Indusi unerlaubt weiter! • Forderung nach optischer Signalisierung bei „ZB durch Indusi“ Systeme müssen von Menschen beherrscht werden können! SW in sicherheitsrelevanten Systemen

22. SW in sicherheitsrelevanten Systemen

23. zweites Beispiel – Genthin 1939 • 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 SW in sicherheitsrelevanten Systemen

24. Unglück von Genthin • D 180 Berlin Neunkirchen (Saar) folgt D10 • D 180 lief auf und wurde mehrfach „gestutzt“ (Vorsignal auf Halt, Hauptsignal dann aber auf Fahrt) • Lokführer von D 180 „übersieht“ im Nebel Halt zeigendes Vorsignal und Hauptsignal bei Belicke • Fahrdienstleiter gibt Haltsignale und benachrichtigt Schrankenbude 89 und Stellwerkswärter in Genthin Ost SW in sicherheitsrelevanten Systemen

25. Fahrt nach Genthin • D 180 sieht nun nur noch „Fahrt“-Signale – die von D 10! • Wärter in Schrankenbude 89 schwenkt Kreiselsignal („Halt“), Knallkapseln konnte er nicht mehr auslegen • Lokführer sieht den Wärter nicht, da dieser zu tief steht • Wärter in Genthin Ost könnte D 180 noch stoppen – er hat höhere Position SW in sicherheitsrelevanten Systemen

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

27. Unfall Folgen • D 180 fährt mit 100 km/h auf den im Bahnhof stehenden D 10 auf • 186 Menschen sterben • 106 Menschen verletzt Größte Eisenbahnkatastrophe in Deutschland • weiterer Unfall in derselben Nacht mit 101 Toten, 28 Verletzten) SW in sicherheitsrelevanten Systemen

28. 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 SW in sicherheitsrelevanten Systemen

29. Ursachen 2 • Indusi bereits in den 20er Jahren erprobt • 1939 war die Indusi schon weit verbreitet • Strecke war mit Indusi-Spulen ausgestattet • Einrichtung an der Lok von D 180 fehlte, da zur Reparatur! • Aufgrund von Lokmangel (Kriegszeiten) wurde die Lok trotzdem eingesetzt! menschliches Versagen? • Zwangsbremsung hätte Zugunglück verhindert! • Lokführer bekam 3 Jahre Gefängnis! SW in sicherheitsrelevanten Systemen

30. 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? SW in sicherheitsrelevanten Systemen

31. Beispiele für SW-Fehlverhalten Kincardine in Ontario, Kanada, Schwerer Reaktorunfall 1990 ausgelöst durch einen Softwarefehler: Beim Austausch eines abgebrannten Brennelementes geriet die computer-gesteuerte Umlademaschine in einen unkontrollierten Zustand. Als sie sich 40 cm über dem Schachtdeckel befand, wurden durch einen falschen Befehl im Code des Computers, der die Umlademaschine kontrollierte, zugleich alle 4 Bremsen des Hebezuges gelöst und das schwere Gerät fiel auf die Schachtabdeckung. Die Folge war der Austritt von 12.000 I hoch-radioaktivem schweren Wasser aus dem Leck, das in den Brennstoff-behälter geschlagen worden war. SW in sicherheitsrelevanten Systemen

32. Beispiele für SW-Fehlverhalten Thule, Grönland, 1960 In der US-Frühwarnstation wird höchste Alarmstufe ausgelöst. Durch einen Computerfehler wurde der Mondaufgang als "Nuklearangriff" gewertet. Ähnliche Fehler waren in der Folgezeit des Öfteren die Ursache für die Menschheit bedrohende Fehlalarme (in einem Fall wurden Wildgänse als einfliegende Formationen von Atomsprengköpfen missdeutet). SW in sicherheitsrelevanten Systemen

33. Beispiele für SW-Fehlverhalten Die Objektiv-Linsen der Weltraum-sonde "Hubble" wichen nach einem computergesteuerten Schliff um einige zehntel Millimeter von der optimalen Krümmung ab. Der Fehler lag in der Programmierung der Schleifmaschine. Das Teleskop war daher nach dem Start in den Weltraum nur sehr einge-schränkt zu gebrauchen, lieferte zum großen Teil unscharfe Bilder. Ihm musste in einer Rettungsaktion, die Unsummen verschlang, im Weltraum eine 'Brille' verpasst werden, um die optimale scharfe Leistung wiederzugewinnen. Nur so konnte der Erfolg des gesamten Systems noch gerettet werden. SW in sicherheitsrelevanten Systemen

34. Software für sicherheitsrelevante Systeme • Wie entwickelt man Software, die in sicherheitsrelevanten Systemen ausgeführt wird? • Nicht Inhalt dieser VL: • Entwicklung der Hardware • Entwurf sicherheitsrelevanter Betriebskonzepte SW in sicherheitsrelevanten Systemen

35. Definition System Ein Beispiel: • system: set of sub-systems or elements which interact according to a design • sub-system: portion of a system which fulfils a specialisedfunction. • function: A mode of action or activity by which a product fulfils its purpose. • element: a part of a product that has been determined to be a basic unit or building block. An element may be simple or complex. • Problem: Die Definition von Begriffen wie System oder Funktion ist willkürlich, ... und wahrscheinlich wird niemals eine universelle Definition gelingen. SW in sicherheitsrelevanten Systemen

36. Definition System Aber: Die Hauptaufgabe ist die Entwicklung hinreichend gefährdungsfreier Produkte. Die Sicherheit sollte nicht davon abhängen, ob eine Funktion von einem „System” oder „Element” erbracht wird. • Der Benutzer muss das zu betrachtende „System” klar und eindeutig definieren. SW in sicherheitsrelevanten Systemen

37. Definition System Ein (Sub-)System zeichnet sich dadurch aus, • dass es sich von der Umgebung abgrenzen lässt (also Systemgrenze und Schnittstellen bekannt sind), und • dass es eine wohldefinierte (beabsichtigte) Funktion erbringen soll SW in sicherheitsrelevanten Systemen

38. Definition System SW in sicherheitsrelevanten Systemen

39. Definition System • Checkliste: • Ist die Systemgrenze klar definiert? • Sind an der Systemgrenze die Schnittstellen definiert? • Sind die Ein- und Ausgaben auf diesen Schnittstellen definiert? • Ist die Aufgabe, die das System erfüllen soll, klar definiert? • Sind die Einsatzszenarien bekannt und dokumentiert? • Ist die Systemstruktur bzw. Systemarchitektur dargestellt? • Sind die einzelnen Architekturelemente definiert? • Ist ihr Zusammenwirken eindeutig definiert? SW in sicherheitsrelevanten Systemen

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

41. Lageplan Siemens AG SW in sicherheitsrelevanten Systemen

42. Definition RAMSS SW in sicherheitsrelevanten Systemen

43. Zusammenhang zwischen RAM, S und S SW in sicherheitsrelevanten Systemen

44. Definitionen von Sicherheit Sicherheit nach Mü8004: “Die Fähigkeit einer Sicherungsanlage, bei • bestimmungsgemäßem Einsatz, • ordnungsgemäßer Instandhaltung und • vorschriftsmäßiger Handhabung während einer vorgegebenen Brauchbarkeitsdauer Gefährdungen durch Funktionsversagen in dem Umfang, der nach dem Stand der Technik erforderlich ist, auch dann zu verhindern, wenn Bauelementeausfälle und Störungen in der zu Beanspruchungsbeginn als fehlerfrei angesehenen Sicherungsanlage eintreten.”  D. h. eine Anlage ist (im Sinne der Mü8004) sicher oder nicht. Sicherheit nach CENELEC: Freiheit von nicht akzeptierten Risiken. SW in sicherheitsrelevanten Systemen

45. MILITARY-STANDARD • MIL-STD-882 • System Safety: The application of engineering and management principles, criteria, and techniques to optimize all aspects of safety within the constraints of operational effectiveness, time, and cost throughout all phases of the system life cycle. • Software System Safety Handbook (MIL-STD) • Purpose: Provide management and engineering guidelines to achieve a reasonablelevel of assurance that software will execute within the system context with an acceptable level of safety risk. SW in sicherheitsrelevanten Systemen

46. Sicherheit: Probleme • Wie sicher sind die Komponenten bzw. Anlagen? • Wie sicher müssen die Komponenten bzw. Anlagen sein? • Wie kann die Sicherheit glaubhaft gemacht werden? • Warum ist die eingesetzte SW/HW frei von systematischen Fehlern? SW in sicherheitsrelevanten Systemen

47. Was bedeutet RAMSS für Eisenbahnsignaltechnik? • Zwingend notwendige Produkteigenschaften, ohne Nachweis sind die Produkte nicht marktfähig • Funktionsversagen kann katastrophale Folgen haben (Unfälle) • Mangelnde Verfügbarkeit wird pönalisiert • Das behauptete Sicherheitsniveau ist weder durch Gebrauch noch Test positiv nachweisbar • Security wird bisher als Problem unterschätzt SW in sicherheitsrelevanten Systemen

48. Klassifikation von Fehlern • Zufällige Fehler • Hardwarefehler als Folge von Alterung • Verschleiß • ausgefallene Transistoren • Systematische Fehler • mangelhafter Entwurf • Programmierfehler • mangelhafte Auslegung der Hardware • Unterscheidung • systematische Fehler treten nach Beseitigung nicht mehr auf • zufällige Fehler können sich jederzeit wiederholen Übergang kann fließend sein: Unterdimensionierter Kühlkörper eines Transistors SW in sicherheitsrelevanten Systemen

49. Klassifikation von Fehlern 2 • Hardware: zufällige und systematische Fehler • Software:nur systematische Fehler möglich! • In dieser VL:Entwicklung von Software, die für die Ausführung auf einer Hardware gedacht ist, die sich für die Ausführung von Sicherheits-Funktionen eignet. • geeignete Hardware: Erkennen von zufälligen Fehlern!Anschließend: Sicheren Zustand einnehmen SW in sicherheitsrelevanten Systemen

50. Rechnerarchitektur 1oo1D SW in sicherheitsrelevanten Systemen