PZB-Entwicklung mit Simulator für den Simulator

[BigBenjy 455]

Hallo zusammen,

 

heute möchte ich fahrzeugübergreifend von der Entwicklung der PZB berichten. Bisher war ja nur in den PlusPack-Fahrzeugen die vereinfachte PZB verbaut, dann kamen die S-Bahnen dazu... nun war also nachzuholen, dass ein vollwertiges und robust funktionierendes System entsteht. Das ist eisenbahnerisch und funktional eigentlich keine Raketentechnologie, aber mit allen Feinheiten und Modi ja durchaus komplex.

 

Wobei die Frage im Raum steht: was ist davon überhaupt zeigenswert? Im Grunde ist die PZB doch genau das gleiche wie bei anderen Addon-Herstellern, deren Fahrzeuge ihr schon habt – einmal vorausgesetzt, dass die Umsetzung funktioniert wie sie soll. Also einfach nur "Kraft mal Weg"... oder

 

Das Ziel: Ein Modul für alle

 

Das gewünschte Ziel mag das gleiche sein, aber die Wege dahin können sich natürlich unterscheiden. Aus Sicht des Informatikers in mir wird's hier dann doch wieder spannend – und genau davon will ich heute erzählen.

 

Zunächst ist da eine Designentscheidung: Für unser ohnehin modulares Skriptsystem wollte ich genau EIN Modul für die PZB haben, egal welche Bauart im Fahrzeug umzusetzen ist. Also auch innerhalb dieses Funktionsmoduls nochmal einigermaßen strukturiert mehrere Bauformen mitdenken. Andere Bauarten (bspw. alte Indusi I54 oder I60), andere PZB90-Softwareversion (der Beiname V1.2 wird ja nicht umsonst mitgeschleppt), anderes Ausgabemedium... alles Derivate dessen, was wir als Sammelbegriff "PZB" kennen. Ich wollte keinen Dschungel von Versions-Dateien starten, sondern alles gebündelt zusammenfassen.

 

Fun Fact am rande: Man könnte also während der Laufzeit des Spiels zwischen I60 und PZB90 umschalten… wenn das denn einen tieferen Sinn ergäbe...

 

Dieses eine Skript-Modul wird also sowohl in die Dosto-Steuerwagen als auch die TRAXX3 kommen. Die unterscheiden sich bspw. in der Ausgabe: Während der 760er-Steuerwagen noch klassische Glühbirnchen-Leuchtmelder hat, gibt's in TRAXX 3 schon ein Display für das MFD. Und die dort verbaute PZB in Ausführung EBICAB500 kommt mit anderem Start-Hochlauf und zusätzlichen Leuchtmeldern und Ausgaben.

 

Die Testfrage

 

Während die Umsetzung der Überwachungslogik v.a. eine Frage des sauberen Programmierens ist, stand hier noch eine ganz andere Frage im Raum: Wie soll das alles getestet werden?

 

Allein die Ril-Vorschrift der DB enthält zahlreiche Beispielfälle, bis hin zu überlagerten Beeinflussungen, um Besonderheiten darzustellen. Muss ich jetzt für jeden Testfall ein passendes Szenario bauen und immer das genau passende Fahrprofil abfahren, um zu schauen, dass alle Testfälle passen?

 

Nee, das kann's nicht sein! 

 

Exkurs: Wie's die Profis machen

 

Inspiriert von der echten Fahrzeugherstellung wurde die Idee des PZB-Sims geboren.

 

In der Realität gehen die Hersteller mehr und mehr dazu über, Fahrzeugfunktionen vorab und nicht erst auf dem Fahrzeug selbst zu testen. Da werden die dann später in die Fahrzeuge einzubauenden Steckkarten 1:1 schon vor/parallel während dem Fahrzeugbau entwickelt und schon mit der "echten" Fahrzeugsoftware bespielt. Was es braucht, ist also ein "virtuelles" Fahrzeug, in das die Platinen eingesteckt werden können. Soweit, so bekanntes business as usual.

 

Das passiert zunehmend systematisch und es werden ganze Fahrzeuge in Hardware-Dummies nachgebildet. Dafür werden die wichtigsten Systeme auf einem "Rechnerschrank" (kann man sich wie einen Serverschrank mit Einschüben vorstellen) aufgebaut und dann die jeweiligen Steckkarten eingebaut und passend mit den Bus-Systemen verdrahtet. So kann je nach Verdrahtung eine unterschiedliche Fahrzeugkonfiguration (bspw. 3- oder 4-teiliger Triebzug, verschiedene Anzahl angetriebener Drehgestelle, mit zweitem Antriebssystem...) oder Mehrfachtraktionen simuliert werden, während vielleicht gerade die ersten Wagenkästen in der Fertigung sind.

 

Der PZB-Simulator

 

Auf unseren TSC-Fall adaptiert bedeutet das: Ich habe ebenfalls in der TSC-Skriptsprache Lua einen "Adapter" gebaut, der das Funktionsmodul fürs TSC-Fahrzeug aufnehmen kann und alle abgefragten Spiel-Funktionen emuliert bereitstellt und die nötigen Abfragen bearbeiten kann (bspw. Log-Ausgabe, Leuchtmelder setzen, Fahrzeugvariable setzen...).

 

Es läuft dann also in Lua im Grunde ein "PZB-Simulator", der Spielzeit, Fahrgeschwindigkeit und PZB-Taster-Eingaben/Magnet-Beeinflussungen nach festgelegten Mustern vorgibt, damit das PZB-Modul "penetriert" und in jedem Zeitschritt die relevanten Werte (Beeinflussung, Leuchtmelder, Zwangsbremsung) mitschreibt.

 

Der Name "Simulator" ist in meinen Augen eigentlich zu hoch gestochen für das, was an Code dahintersteht. Aber das Prinzip ist halt genau das gleiche: Ohne den TrainSim zu fahren, werden Tests auf exakt dem Skriptmodul ausgeführt, das später im TSC genutzt wird.

 

Der Kniff dabei: Ein ummantelndes Programm muss dem Skript-Modul (das eigentlich für den TSC gestaltet ist) also vorgaukeln, es würde ein Spiel laufen, das dieses Modul ansteuert. Also hab ich in aller Kürze ein System aufgesetzt, das einen bestimmten Zeitablauf durchspielt und dabei eine bestimmte (Ziel-)Fahrgeschwindigkeit des Fahrzeugs sowie mögliche Beeinflussungen durch Magnete vorgibt. Was in jedem Zeitschritt passiert, wird mitgeschrieben. Die zeitlichen Abläufe (Fahrprofil, Magnet-Beeinflussungen, Taster-Bedienung) sind dann noch ein einem kompakten Format zusammengefasst worden, so dass sich einfach zwischen verschiedenen Testfällen umschalten lässt.

 

Die Ausgabe: CSV und Diagramme

 

Die Ausgaben werden in zwei CSV-Dateien geschrieben: ein Datenfile und die Log-Ausgaben (bspw. welche Textfenster-Ausgaben angesteuert werden). Es entsteht v.a. im Datenfile eine riesige Tabelle mit Daten, weil für jeden Zeitschritt Zustand der Überwachung(en), Leuchtmelderstatus etc. mitgeschrieben werden.

 

Das Ganze gibt's weg- und zeitbasiert, um wahlweise in beiden Modi auswerten zu können. Es ergibt sich'ne „kompakte“ Darstellung aller Abläufe in einer Tabelle von 36 mal bis zu mehreren hundert Einträgen... 

 

Die will ich natürlich auch nicht einfach so lesen müssen – passenderweise ist es eine CSV-Datei, deren Inhalte sich mit wenigen Klicks in Excel übernehmen lassen. Was also noch fehlte, ist die grafische Aufbereitung der Ergebnisse.

 

Das passiert in einem ziemlich umfangreichen Diagramm. Das wird aber nur einmal eingerichtet und bereitet dann beliebige Abläufe optisch auf. Zugegeben: Für die Perfektionierung der Ausgabegrafik werden beim Mitschreiben im Sim schon ein paar Ausgabe-Werte nach der Berechnung zusätzlich "frisiert", um bspw. Zustands-Darstellungen innerhalb des Diagramms zu verschieben.

 

Beispiele aus dem PZB-Sim

 

Schauen wir uns mal so ein Diagramm an:

 

Schon im ersten Bild ist ordentlich was los: Man sieht den Geschwindigkeitsverlauf (grüne Linie), die Überwachungskurve (gelb/orange), die verschiedenen Magnetbeeinflussungen, die aktivierten Leuchtmelder (blaue Segmente unten) und ggf. laufende Überwachungszustände oberhalb des Diagramms codiert. Nach der Leuchtmelderdisko (Prüfprogramm beim Start) startet das Fahrzeug bei 0 km/h und beschleunigt. Es setzt das Startprogramm mit Wechselblinken und 45km/h-Überwachung ein. Der virtuelle Tf befreit sich und erreicht die Zielgeschwindigkeit von 80 km/h. Die PZB-Überwachung bleibt im grünen Bereich – alles läuft sauber durch, auch die im Hintergrund für 550m laufende Prüfung auf Beeinflussung bleibt ohne Folgen.

 

Was passiert, wenn man die Befreiung vergisst?

 

 

Hier sieht man den gleichen Ablauf, nur wurde die Befreiungstaste nicht rechtzeitig betätigt. Das rote Kreuz markiert den Zeitpunkt der Zwangsbremsung – die Geschwindigkeit bricht ein, die Überwachungskurve springt um, und diverse Warnmelder aktivieren sich. Genau so, wie's sein soll.

Wegbasierte Darstellung

 

Sicher etwas gewöhnungsbedürftig ist die wegbasierte Darstellung. Bei wechselnden Geschwindigkeiten ändert sich scheinbar das Tempo des Wechselblinkens – das ist aber nur ein Artefakt der wegbasierten Darstellung. Hier wird ein Bahnhofshalt mit ASig-Beeinflussung bei Annäherung auf Hp0 gezeigt - nach dem Passieren des 500 Hz-Magneten folgt kein 2000er mehr, weil wir davon ausgehen, dass das Asig dann umschaltete. In diesem Fall fährt der Tf nach dem Halt den restriktiven Modus noch eine Weile bis zum Ablauf der 500er-Überwachung aus (das ASig steht scheinbar ein ganzes Stück hinter dem Bahnsteig…) und befreit sich dann, da keine weitere Beeinflussung folgt. Keine Zwangsbremsung.

Überlagerungsfälle: Ein Blick unter die Haube

 

 

Besonders spannend sind die Überlagerungsfälle, die sich teils auch mit verschiedenen Lehrheften abgleichen lassen. Hier werden zwei Überwachungs-Kontexte gemeinsam beachtet – ein Blick unter die Haube zeigt, wie die PZB mehrere Kontext-Slots belegt, die parallel überwacht werden. Die erste 1000Hz-Beeinflussung kommt von der Vorbeifahrt an einem Vorsignal auf ein Hp2 mit Zs3 „3“, weshalb später ein 500er folgt. Doch noch davor wird ein zweiter 1000Hz-Magnet passiert (der zu einem Lf-Signal gehört). Die Überwachung wird für nochmal 1250m aktiv. Man sieht im Diagramm, wie verschiedene Überwachungszustände sich zeitweise überlagern und die PZB jeweils die restriktivste Vorgabe durchsetzt. Nach Ablauf der 500Hz-Überwachung  greift dann sofort die im Hintergrund weiterlaufende 1000Hz-Überwachung wieder.

Overkill oder effiziente Entwicklung?

 

Klingt irgendwie nach ganz schön abgehobenem Overkill für so eine Spielesimulations-Fahrzeugentwicklung, oder?  Dabei will ich eigentlich nur halbwegs effizient Software entwickeln... Trotz der zusätzlichen Testumgebung, die zu entwickeln war, bin ich mir sehr sicher, dass ich unterm Strich reichlich Aufwand (und Nerven) sparen konnte, weil auf die Masse der Testfälle (die ja auch wiederholt werden müssen, wenn sich Fehler zeigen..) sich das ganze gelohnt hat!

 

„In echt" würde man jetzt mit Systematik Testfälle aufsetzen (diese bestenfalls genauso automatisiert ablaufen und die Ergebnisse kontrollieren lassen), die Simulatorausgaben sammeln (das Ganze später auf dem echten Fahrzeug genau so nochmal wiederholen) und mit den Ergebnissen zum Gutachter für die Fahrzeugsoftware-Zulassung gehen. 

 

Über die Abnahme dürft ihr dann aber selbst mal nach Addon-Release entscheiden. 

 

Viele Grüße,
Benjamin

 

[BigBenjy 455]

Hi zusammen,

 

an dieser Stelle noch zwei kurze Videoschnipsel verschiedener Fahrzeuge aus der Entwicklung: wir sehen die Aktivierung der PZB im Dosto-Steuerwagen der Bauart 760 ganz klassisch mit Glühlämpchen-Leuchtmeldern im MFD-Tableau, deren Prüflauf sie nach und nach aufleuchten lässt.

 

Anders startet die PZB bei der BR 147: die Leuchtmelder sind virtuell und im MFD-Bildschirm integriert und es startet ein Prüflauf, bei dem zunächst alle PZB-Leuchtmelder 3 sec lang blinken und dann zwei Zwangsbremsungen ausgelöst werden (bei denen zwei unterschiedliche Wirkwege geprüft werden). Dabei zeigt sich auch gleich die Besonderheit, dass es in der Ebicab-Integration der PZB zusätzliche Leuchtmelder gibt sowie Text-Ausgaben zum aktuellen Zustand - beide sind auch im Simulator umgesetzt.

 

So unterschiedlich können PZB-Startsequenzen aussehen.  Beide sind hier noch unvertont zu sehen, es kommen im ersten Fall noch die PZB-Tröte und bei der BR 147 die Sprachausgaben dazu.

 

Viele Grüße,
Benjamin