Grundlagen

Mögliche Fehler

• v.V_F01_EmergencyBrake = L_YES: Notbremse funktioniert nicht.
• v.V_F02_TrainRadioReceiver = L_Loss: Nachrichten an den Zug gehen verloren.
• v.V_F02_TrainRadioReceiver = L_FalseReport: Nachrichten an den Zug entstehen ohne gesendet zu werden.
• v.V_F03_CrossingMotor = L_OutOfControl: Motor wird ohne Auslöser aktiviert.
• v.V_F03_CrossingMotor = L_DoNotWork: Motor funktioniert nicht.
• v.V_F04_OpeningSensor = L_YES: OpeningSensor gibt fälschlicher Weise an, dass Zug über ihn hinweggefahren.
• v.V_F05_TrainOdometer = L_YES: Odometer wähnt sich an falschem Ort.
• v.V_F06_CommunicationMedium = L_Loss: Nachricht an Bahnübergang geht verloren.
• v.V_F06_CommunicationMedium = L_FalseReport: Bahnübergang bekommt falsche Nachricht die nicht gesendet wurde.

Gefährdung

DEFINE hazard := v.V_Angle != 0 & v.V_Position <= 0 & v.V_Position >= -9;

D.h. die Schranke ist nicht geschlossen und der Zug ist auf dem Bahnübergang.

Durchführung

Im Rahmen der DCCA wurde geprüft unter welchen Fehlerkombinationen die Gefährdung nicht auftritt, also welche Fehlerkombinationen sicher sind. In folgender Tabelle ist in den Spalten das Fehlerauftreten eingetragen. Kein Eintrag bedeutet dabei, dass der Fehler nicht auftritt. Die Spalte ganz rechts gibt an, ob die Fehlerkombination in der Zeile sicher ist. Alle nicht aufgeführten Kombinationen sind ebenfalls nicht sicher. Dies wurde allerdings nicht durch Formel geprüft, sondern geht aus der Monotonie der Sicherheitseigenschaft hervor.

EmergencyBrake	TrainRadioReceiver	CrossingMotor	OpeningSensor	TrainOdometer	CommunicationMedium	Safe
						true
Yes						true
	Loss					true
	FalseReport					true
		OutOfControl				false
		DoNotWork				true
			Yes			false
				Yes		false
					Loss	true
					FalseReport	false
Yes	Loss					false
Yes	FalseReport					true
Yes		DoNotWork				false
Yes					Loss	false
	Loss & FalseReport					true
	Loss	DoNotWork				true
	Loss				Loss	true
	FalseReport	DoNotWork				false
	FalseReport				Loss	false
		DoNotWork			Loss	true
	Loss	DoNotWork			Loss	true

Single Point of Failure sind folglich:

• CrossingMotor = OutOfControl (Dieser Fehler steht exemplarisch dafür, dass eine Komponente das Bahnübergangs sehr ungewöhnliche Fehlermuster aufweist. Ein ähnlicher Fehler entsteht, wenn der Timer zu schnell zählt und die Schranke dadurch zu früh aufmacht.)

Szenario: Der Motor entscheidet zu einer beliebigen Zeit einfach zu öffnen.

• OpeningSensor = Yes

Szenario: Der Opening Sensor gibt willkürlich das Signal zum Öffnen der Schranke, obwohl der Zug den SP noch nicht passiert hat.

• TrainOdometer = Yes

Szenario: Das Odometer liefert eine falsche Position, wodurch nicht genügend Zeit bleibt, um die Schranken zu schließen oder eine Notbremsung einzuleiten bzw. noch rechtzeitig zu bremsen.

• CommunicationMedium = FalseReport

Szenario: Durch die Modellierung, dass auf dem Kommunikationskanal immer nur eine Nachricht vorliegen kann, kann der Programmgraph im Zustand "MSG_Response" verweilen, während der Zug einen Request zum Schließen der Schranke sendet (entspricht im Endeffekt einen Message-Loss). Daraufhin wird die Schranke nicht geschlossen, aber dennoch eine positive Response-Nachricht geschickt.

Unsichere Fehlerkombinationen aus zwei Fehlern:

• EmergencyBrake = Yes und TrainRadioReceiver = Loss

Szenario Die Notbremse wird ausgelöst, weil durch den defekten TrainRadioReceiver die Antwort vom Bahnübergang nicht empfangen wird. Die Bremse verringert zunächst die Geschwindigkeit, geht aber dann kaputt. Durch die langsamere Geschwindigkeit entsteht am Bahnübergang ein Timeout, die Schranke wird wieder geöffnet und der Zug fährt durch

• EmergencyBrake = Yes und CrossingMotor = DoNotWork

Szenario: Der Schrankenmotor kann die Schranke nicht schließen. Da am BEP kein positiver Response vorliegt muss eine Notbremsung eingeleitet werden; die Bremse zeigt jedoch keine Wirkung.

• EmergencyBrake = Yes und CommunicationMedium = Loss

Szenario: Die Anfrage zum Schließen wird verworfen. Da am BEP kein positiver Response vorliegt muss eine Notbremsung eingeleitet werden; die Bremse zeigt jedoch keine Wirkung.

• TrainRadioReceiver = FalseReport und CrossingMotor = DoNotWork

Szenario: Die Schranke kann nicht geschlossen werden; dennoch meldet der Empfänger am Zug, er habe eine positive Antwort von der Schranke erhalten.

• TrainRadioReceiver = FalseReport und CommunicationMedium = Loss

Szenario: Die Anfrage des Zuges wird verworfen (geht im Kommunikationskanal verloren); dennoch meldet der Empfänger am Zug, er habe eine positive Antwort von der Schranke erhalten.

Erkenntnisse aus der DCCA

Die Single-Point-of-Failure der DCCA wurden in ähnlicher Form auch in der FTA erkannt. So war bereits in der FTA klar, dass das Odometer eine falsche Position liefern könnte, was letzten Endes zum Hazard führt. Der False-Report des Kommunikations-Medium (aus der DCCA) ist im übertragenen Sinne der "Ja"-Sager, wie wir ihn in der FTA definiert haben.

Bei den Two-Point-Failures ist die "Ausbeute" durch die DCCA schon größer. Fehler wie das Verlieren der Nachrichten wurden in der FTA noch nicht genauer unter die Lupe genommen und kamen erst bei der Modellierung der darauf zugreifenden Komponenten auf.

Im Hinblick auf eine defekte Notbremse wurden ebenfalls Kombinationen mit einer weiteren Störung vergessen. Zwar wurde der Fehler "Schrankenmotor und Notbremse gestört" durch die FTA identifiziert, doch wurden keinerlei Verbindungen zwischen den Kommunikationskomponeten und der Notbremse untersucht. Daher wurden bei der FTA einige Two-Point-Failures vergessen, die die DCCA zum Vorschein brachte.