Simulationsbasierte Systemtests – ein Schlüssel für die Digitalisierung des Bahnsystems

Anforderungen an eine Simulationsumgebung für vollautomatisierte Schienenfahrzeuge

Aufgrund begrenzter Ressourcen, wie zum Beispiel der Verfügbarkeit und Anzahl an Teststrecken, und der hohen einzuhaltenden Sicherheitsstandards ist das Testen unter realen Bedingungen sehr komplex, zeitaufwändig und kostspielig. Aus diesen Gründen ist es das Ziel, möglichst viele Entwicklungs-, Verifizierungs- und Validierungsprozesse in einer simulierten Umgebung durchzuführen.

Testprojekte zum fahrerlosen Fahren im Automatisierungsgrad GoA 4 sind dabei besonders aufwändig. Hierbei muss eine Vielzahl an Szenarien berücksichtigt und durchgetestet werden. Damit das in einer realistischen Zeitspanne umgesetzt werden kann, muss für ein ATO GoA 4-Projekt ein Schienenfahrzeug in seiner Einsatzumgebung simuliert werden. Die Simulation und die dafür verwendeten Werkzeuge müssen für den Test sicherheitskritischer Funktionen qualifiziert werden. Zukünftig können dadurch möglichst viele Tests aus dem Feld in das Labor verlagert werden.  

Ein ATO GoA4-System in einem Schienenfahrzeug übernimmt alle Aktionen des Triebfahrzeugführers. Dazu zählen im Wesentlichen das Auf- und Abrüsten des Triebfahrzeugs, die Überwachung des Fahrgastwechsels und das Fahren inklusive der Streckenbeobachtung während der Fahrt. Auch das Reagieren auf außerordentliche Situationen muss dabei abgedeckt werden. Dazu gehören unerwartete Objekte im Gleisbereich (u. a. Bäume, Personen, Tiere), kritische Wetterbedingungen (z. B. Überflutung der Gleise) und gefährliche Störungen am Zug (z. B. Brand).

Wesentliche Subsysteme eines solchen vollautomatisierten ATO GoA4-Systems sind das ATO Onboard, also die Automatisierung der eigentlichen Fahrfunktion (anfahren, beschleunigen, bremsen, halten) und die Umfeldwahrnehmung bzw. das Perception-System (PER). Letzteres basiert auf den Daten komplexer Sensorsysteme, bestehend aus Kameras, Radaren und LiDARen. Ein weiteres Subsystem ist das Incident Prevention Management System (IPM), welches basierend auf den durch das Perception-System erkannten Objekten beurteilt, ob eine reguläre oder irreguläre Situation besteht und ggf. eine Reaktion auslöst.

Diese Subsysteme sind in der Regel mit der Leittechnik des Triebfahrzeuges, auch bekannt als Train Control Management System (kurz TCMS), dem Onboard-Zugsicherungssystem (CCS) und weiteren Systemen verbunden und interagieren mit der physischen Zugeinheit (Physical Train Unit, PTU), siehe Abbildung 1.

Um zu prüfen, wie die Simulationsumgebung für den Test eines ATO GoA4-Systems aussehen kann, wurde eine Kooperation mit der dSPACE GmbH aufgesetzt, die in dem Feld über mehr als 30 Jahre Erfahrung verfügt. In einem ersten Schritt wurde ein Proof of Concept durchgeführt. Dabei lag der Fokus auf dem Test des neuen Subsystems IPM. Für den Proof of Concept wurde von der Deutschen Bahn ein vereinfachtes IPM-Modell bereitgestellt, welches in die dSPACE Simulationsumgebung eingebettet wurde, sodass ein geschlossener Regelkreis entstand (Closed-Loop) und es mit der dSPACE Werkzeugkette in Betrieb genommen werden konnte. Dazu müssen alle anderen erforderlichen Subsysteme wie das Perception-System und weitere angeschlossene relevante Onboard-System (z.B. Bremse /Antrieb/CCS Onboard) sowie die Zugdynamik und die Zugumgebung (PTU) simuliert werden.

Erstellung der Simulationsumgebung

Zunächst wurde ein Simulationsmodell benötigt, das eine geeignete Darstellung der Zugdynamik bietet und dabei den Aufbau verschiedener Zugverbände berücksichtigt. Ziel war es, ein generisches Zugdynamikmodell zu implementieren, das sich vorerst auf die Längsdynamik konzentriert. Hierzu wurde auf das dSPACE-Produkt „Automotive Simulation Models“ (ASM) zurückgegriffen. An dem ASM-Fahrdynamikmodell von dSPACE wurden bahnspezifische Modellanpassungen vorgenommen.  

Das Fahrdynamikmodell wurde mithilfe von ModelDesk, einem weiteren dSPACE Produkt, parametrisiert. Für den Proof of Concept wurde es so parametrisiert, dass es einer Baureihe 423 der Deutschen Bahn AG mit vier Wagen entspricht.

Durch den Import von bahnspezifischen Objekten wie Schienen, Oberleitungsmasten und Lichtsignalen wurde die grundlegende Straßenvisualisierung gegen eine bahnähnliche Umgebung ausgetauscht. Zu Demonstrationszwecken wurde außerdem ein Bahnschienennetz aus OpenStreetMap in ModelDesk importiert. Da das dSPACE Konvertierungswerkzeug jedoch für den Import von Straßennetzen und deren Objekten ausgelegt ist, mussten einige bahnspezifische Elemente wie Schienen, Oberleitungen und Bahnsteige manuell hinzugefügt werden. Geplant ist, dass diese Daten zukünftig aus dem Digital Register, einer „Single source of truth“ für Infrastrukturdaten eingelesen werden, welches ebenfalls von der Digitalen Schiene Deutschland entwickelt wird. Für die Visualisierung wurde zuerst MotionDesk eingesetzt (siehe auch Abbildung 2).

Der nächste Schritt war die Integration des vereinfachten IPM-Controllers der Deutschen Bahn, um einen geschlossenen Regelkreis mit dem ASM-Modell zu bilden. Der IPM-Controller wurde durch ein simuliertes Perception-System angesprochen. Zur Vereinfachung wurden hierfür die von den ASM-Ground-Truth-Sensormodellen bereitgestellten Objektlisten verwendet. Basierend auf den erkannten Objekten bestimmt der IPM-Controller, ob der Zug auf die Objekte reagieren muss. Die gewünschte Reaktion wie zum Beispiel das Auslösen von Warnsignalen oder das Ausführen einer Betriebs- oder Schnellbremsung wurde zurück an das ASM-Zugdynamikmodell übermittelt, welches diese Reaktion ausführte. Eine schematische Darstellung des Regelkreises ist in Abbildung 3 abgebildet.

Evaluierung der Simulation

Um die Eignung der erstellten Simulationsumgebung und der zugehörigen dSPACE Werkzeugkette für die Digitale Schiene Deutschland zu testen, wurden zwei verschiedene Anwendungsfälle erstellt:

Der erste Anwendungsfall beinhaltet eine Situation, in der ein Reh die Gleise überquert. Das Reh wird mit Hilfe der 3D-Ground-Truth-Sensoren als ein sich bewegendes Tierobjekt identifiziert und an den IPM-Controller übergeben. IPM reagiert auf das Objekt im Bereich des Gleisbetts, indem es das Signalhorn betätigt sowie ein optisches Warnsignal und die Schnellbremse (Emergency brake, EB) betätigt. Verlässt das Reh den Gleisbereich und wird nicht mehr erkannt, nimmt der Zug den regulären Betrieb wieder auf. Der zweite erfolgreich entwickelte Anwendungsfall beinhaltet folgende Situation: Ein Zug bewegt sich auf einen Bahnübergang zu. Ein Auto steht auf den Gleisen. Dieses Szenario ist in Abbildung 4 dargestellt.

Wie in der Abbildung oben links werden bei der Annäherung an den Bahnübergang mehrere Objekte erkannt. Dabei scheinen sich nur zwei Objekte (durch grüne Rechtecke in der Abbildung oben markiert) im Weg des Zugs zu befinden und werden vom IPM-Controller als sicherheitskritisch eingestuft (Abbildung links in der Mitte). Die Reaktion darauf ist eine optische Warnung per Scheinwerfer sowie eine Signalhornwarnung mit Betriebsbremse (Service Brake, SB). Ist ein Anhalten mit der Betriebsbremse aufgrund des zu geringen Abstandes zum Fahrzeug nicht mehr möglich, wird durch den IPM-Controller die Schnellbremse (Emergency Brake, EB) aktiviert. Aufgrund des verkürzten verbleibenden sicheren Anhaltewegs löst der IPM-Controller in diesem Fall die Schnellbremse (EB), das optische Warnsignal (WSO) sowie das akustische Warnsignal (WSA) aus (siehe auch Tabelle rechts oben in Abbildung 4). Der Zug kann in diesem Anwendungsfall gerade noch rechtzeitig bremsen.

Diese beiden simulierten Anwendungsfälle lieferten wichtige Erkenntnisse bezüglich der Sensorpositionierung und der Objekterkennung. Die Sensoren der Umfeldwahrnehmung erstellen Objektlisten mit allen Objekten in ihrem kegelförmigen Beobachtungsbereich, die an das IPM-Modell weitergegeben werden. Wenn jedoch ein sicherheitskritisches Objekt aus dem Beobachtungsbereich (den Kegel) der Sensoren verschwand, obwohl es noch im Gefahrenbereich ist, fiel in der Simulation auf, dass das einfache IPM-Modell in diesem Fall unerwünscht bereits zum Normalbetrieb zurückkehrte. Als Konsequenz mussten sowohl die Sensorpositionierung (für eine bessere dauerhafte Abdeckung) als auch die zu einfache Regelstrategie, die nicht die Beobachtungshistorie einschloss, überdacht und verbessert werden. Dieses Beispiel zeigt, dass Simulation wesentlich dazu beitragen kann, den System- bzw. Reglerentwurf frühzeitig zu valideren und somit die Kosten für eine Fehlerkorrektur gering zu halten.

Herausforderungen und Ausblick

Der Proof of Concept zeigt, dass es möglich ist, die aus dem Automotive-Umfeld stammende dSPACE Werkzeugkette anzupassen und eine Simulationsumgebung aufzubauen, die für kommende Systemtests geeignet sind. Da der Proof of Concept die Erwartungen beider Seiten erfüllt hat, planen die DB InfraGO AG und dSPACE eine Vertiefung der Zusammenarbeit durch eine gemeinsame Erweiterung der implementierten Bahnsimulationsumgebung.

Unter anderem wurde MotionDesk bereits durch das neue Werkzeug AURELION ersetzt. Erste Ergebnisse der Migration sind in Abbildung 5 dargestellt. AURELION ermöglicht eine realistischere Umgebungsvisualisierung und eine physikalisch realistische Sensorsimulation für Kamera-, Lidar und RADAR Sensoren. Diese wird erforderlich, falls das Perception-System ebenfalls Teil des im Labor zu prüfenden Systems wird. Dann müssten Sensoreffekte wie Ablenkung und Mehrwegeausbreitung bei Radarsensoren oder Punktwolkenverteilungen und Bewegungsverzerrungseffekte bei Lidarsensoren berücksichtigt werden.

Als nächster großer Schritt ist geplant, die Simulationsumgebung für Software- und Hardware-Tests des ATO GoA4-Systems im Rahmen des diesjährig gestarteten Automated-Train-Projektes einzusetzen.

Autoren:

Dr. Dirk Spenneberg, DB InfraGO AG

Niklas Kersting, dSPACE GmbH

Roa Al-Hashimi, DB InfraGO AG

Ein ausführlicher Beitrag dazu ist im Fachmagazin „Deine Bahn“ (11/2023) erschienen.
Link zum Artikel