Technisches Gebiet
-
Von der Erfindung ist ein Verfahren zum Betreiben eines Zugleitsystems umfasst. Ferner ist von der Erfindung eine streckenseitige Rechenumgebung eines spurgeführten Verkehrsnetzes umfasst. Ferner ist von der Erfindung ein spurgeführtes Fahrzeug mit einer fahrzeugseitigen Rechenumgebung umfasst. Ferner ist von der Erfindung Computerprogrammprodukt, enthaltend Programmbefehle, umfasst. Ferner ist von der Erfindung Computerlesbares Speichermedium, enthaltend Daten, umfasst.
Technischer Hintergrund
-
Die Fahrzeitrechnung für Zugleitsysteme basiert in an sich bekannter Weise auf der Lösung von Bewegungsgleichungen durch eine Recheninstanz, die auch als Solver bezeichnet wird, wobei die eingesetzten Parameter im realen Zugbetrieb nur unzureichend genau bekannt sind (Zugwiderstände, Masse, Drehmassen, Windgeschwindigkeit, Windrichtung sind veränderliche Größen und abhängig von Betriebsbedingungen wie Wetter, Verschleiß und Beladungszustand). Die Parameter werden daher mit Näherungsformeln berechnet oder es werden Mittelwerte angenommen.
-
Das Hauptziel eines Zugleitsystems (im Folgenden auch als Traffic Management System oder kurz TMS bezeichnet) besteht darin, einen störungsfreien Fahrplan zu entwerfen, um Konflikte in Form von Zugverspätungen zu minimieren. Die nach dem Stand der Technik vorgeschlagenen typischen Optimierungsziele beinhalten die Minimierung der durchschnittlichen Verspätung oder der kumulierten Verspätung zum Beispiel durch Minimierung von konvexen Funktionen der Zugverspätungen. Modelle zur Darstellung machbarer Lösungen basieren auf der Beobachtung, dass durch die Betrachtung der Züge als Aufträge (im Folgenden auch als Jobs bezeichnet) und der Streckenressourcen statt Maschinen. Damit ist das Zugabfertigungsproblem dem Problem der Planung in einer Fertigungsstätte (im Folgenden als Shop bezeichnet) ähnlich. Das heißt, dass die Belegungszeit eines Zuges auf der Ressource der Streckenabschnitt der Bearbeitungszeit eines Auftrags auf einer Maschine entspricht (im Folgenden als Flexible-Job-Shop-Problem oder kurz als FJSP bezeichnet), für das gemäß dem Stand der Technik Solver eingesetzt werden (vgl. z. B.
Leonardo Lamorgese et al., "Train Dispatching", Springer, 2018). Allerdings gibt es einige bahnspezifische Aspekte des FJSP, die berücksichtigt werden müssen. Zum Beispiel kann ein Zug, der das Ende einer Ressource erreicht hat, nicht in die nachfolgende Ressource einfahren, wenn diese belegt ist, somit können durch Fahrplanänderungen zur Lösung von Konflikten Folgekonflikte entstehen, die die nach dem geänderten Fahrplan agierenden Züge wiederum verspäten. In der Fahrplantheorie ist dies als Blockierungsbedingung bekannt.
-
Aktuell wird eine Prognose für die Fahrzeit eines Zuges auf einer Strecke von Ort A nach Ort B in einem TMS durch einen Solver wie folgt berechnet:
- Es wird das aktuelle Geschwindigkeitsprofil für die maximal mögliche Geschwindigkeit ermittelt von A nach B.
- Es wird ein Widerstandsprofil für die Strecke berechnet (Gradienten, Kurven, Tunnel).
- Es wird für das Fahrzeug die Kraft-Geschwindigkeits-Kennlinie berücksichtigt.
- Für die Wagen des Fahrzeugs werden Widerstandsparameter angenommen, wobei diese sich um den Faktor 10 unterscheiden können zwischen Gutläufer und Schlechtläufer.
- Basierend auf den oberen Parametern wird die Bewegungs-Differentialgleichung gelöst entweder als Integral von a(t)=F/m für den Gesamtverlauf oder als F(v) beim Beschleunigen und getrennt für konstante Fahrt und Bremsvorgang. Damit wird eine minimale technische Fahrzeit ermittelt.
-
Diese Vorgehensweise hat folgende Nachteile.
- Die Fahrzeitrechnung (Prognose) innerhalb des TMS dauert relative lange (Rechenzeiten im Minutenbereich), ist komplex und basiert auf vielen Annahmen. Diese Annahmen müssen auf jeden Anwendungsfall angepasst werden, um eine Ähnlichkeit mit dem realen Verkehr zu haben.
- Es werden eine Vielzahl von Parametern benötigt (beispielsweise Zug-Kennlinien).
- Viele Parameter müssen geschätzt bzw. gemittelt werden. Für die Jahresplanung wird zum Beispiel ein "mittel"-guter Zug mit bestimmter Formation von Wagen angenommen.
- Die Fahrzeitrechnung ist relativ komplex, die Software-Applikation damit verhältnismäßig aufwändig. Die Gefahr besteht, dass komplexe Verkehrssituationen nicht in hinreichend kurzer Zeit optimiert werden können.
-
Zur Realisierung von durch TMS vorgegebenen Fahrplänen werden im Zugverkehr in bekannter Weise Verfahren zum automatisierten Zugbetrieb (im Folgenden auch Automated Train Operation oder kurz ATO genannt) eingesetzt und durch Verfahren zur automatischen Zugkontrolle (im Folgenden auch Automatic Train Control oder kurz ATC genannt) abgesichert. Die ATC realisiert hierbei automatische Funktionen im Zugbetrieb, die sicherheitsrelevant sind. Beispielsweise die Zwangsbremsung des Fahrzeugs, wenn ein Sicherheitsrisiko ermittelt wird. Die ATO dient der Optimierung des Zugbetriebs hinsichtlich Fahrzeiten sowie Energieverbrauch des Fahrzeugs. Diese Funktionen sind nicht sicherheitsrelevant, da die Modifikation von Fahrzeiten und Energieverbrauch keine Sicherheitsrisiken auslösen. Sowohl die ATO als auch die ATC bedürfen einer Kooperation von fahrzeugseitigen (im folgenden auch onboard oder kurz OB genannt) Recheninstanzen, bestehend aus Hardwarekomponenten und Softwarekomponenten sowie streckenseitigen (im Folgenden auch trackside oder kurz TS genannt) Recheninstanzen, bestehend aus Hardwarekomponenten und Softwarekomponenten.
-
Die Anforderungen an die Zertifizierung sicherheitsrelevanter Anwendungen beispielsweise in der Bahntechnik sind sehr hoch. Gemäß der internationalen Norm IEC 61508 beziehungsweise spezifisch für den Bahnbereich gemäß der europäischen Norm EN 50129 werden für Sicherheitsfunktionen vier Sicherheits-Integritätslevel oder Englisch Safety Integrity Level (SIL) beziehungsweise Sicherheits-Anforderungsstufen für die geforderte funktionale Sicherheit (Safety) unterschieden. Hierbei stellt der Sicherheits-Integritätslevel 4 die höchste und der Sicherheits-Integritätslevel 1 die niedrigste Stufe der Sicherheits-Integrität dar. Der jeweilige Sicherheits-Integritätslevel beeinflusst das Vertrauensintervall eines Messwertes dahingehend, dass das Vertrauensintervall umso kleiner ist, je höher der Sicherheits-Integritätslevel ist, der seitens der jeweiligen Vorrichtung zu erfüllen ist. Die Dimension der funktionalen Sicherheit der verschiedenen Sicherheits-Integritätslevel lässt sich anschaulich mit der zu erwartenden Häufigkeit eines Ausfalls des sicherheitsrelevanten Systems MTBF (Mean Time Between Failures) beschreiben, wobei dies in Jahren (a) angegeben wird. Diese liegt bei SIL-1 im Bereich von 10 ... 100 a, bei SIL-2 im Bereich von 100 ... 1000 a, bei SIL-3 im Bereich von 1000 ... 10000 a, und bei SIL-4 im Bereich von 10000 ... 100000 a.
-
Das TMS berechnet mittels eines Solvers ausgehend von einem Regelfahrplan, der die interagierenden Fahrzeuge in einem spurgeführten Verkehrsverbund berücksichtigt, einen individuellen Sollfahrplan für ein beispielsweise von einer Störung betroffenes Fahrzeug. Bei der ATO-OB ist vorgesehen, dass diese für einen übertragenen Sollfahrplan eine Prognose berechnet. Dies erfolgt basierend auf genauer Kenntnis des Fahrzeugs und dessen Umgebung (Widerstände, Masse, Drehmassen, Außentemperatur etc.), wobei die genannten Kennwerte im Fahrzeug beispielsweise durch Sensoren erfasst werden können.
-
Aus dem erläuterten Stand der Technik ergibt sich das Problem, dass mit einem TMS möglichst realitätsnahe aktualisierte Fahrpläne in möglichst kurzer Rechenzeit erstellt werden sollen, die als realisierbare Sollfahrpläne mit hoher Wahrscheinlichkeit störungsfrei umgesetzt können werden sollen.
Zusammenfassung der Erfindung
-
Die Aufgabe der Erfindung besteht darin, die beschriebenen Probleme im Stand der Technik zu beheben. Insbesondere ist es Aufgabe, dass ein Verfahren zum Betreiben eines Zugleitsystems, bei dem eine streckenseitige Rechenumgebung und auf einem Fahrzeug eine fahrzeugseitige Rechenumgebung zum Einsatz kommen, derart weiterzubilden, dass die Berechnung eines aktualisierten Fahrplans aus einem Regelfahrplan die real verfügbaren Fahrzeitreserven möglichst weitgehend ausschöpfen kann und dabei möglichst schnell ein realisierbares Ergebnis in Form des aktualisierten Fahrplans liefert. Weiterhin ist es Aufgabe der Erfindung, ein Fahrzeug, ein Computerprogrammprodukt und ein computerlesbares Speichermedium anzugeben, mit dem das verbesserte Verfahren durchführbar ist.
-
Beschrieben wird gemäß einem ersten Aspekt der Erfindung Verfahren zum Betreiben eines Zugleitsystems, bei dem
- a) eine streckenseitige Rechenumgebung und eine fahrzeugseitige Rechenumgebung zum Einsatz kommen, wobei in der streckenseitigen Rechenumgebung und in der fahrzeugseitigen Rechenumgebung eine Planungsebene und eine Ausführungsebene für auszuführende Sollfahrpläne realisiert sind, wobei im Einzelnen
- b) auf der Planungsebene eine erste Recheninstanz unter Berücksichtigung von Sollparametern des aktuell auszuführenden Sollfahrplans und von sich aus Istparametern eines realisierbaren Istfahrplans ergebenen Konflikten zur Lösung der Konflikte einen aktualisierten Fahrplan berechnet,
- c) danach auf der Ausführungsebene eine zweite Recheninstanz eine Nachricht, die den aktualisierten Fahrplan als aktuell auszuführenden Sollfahrplan vorgibt, von der ersten Recheninstanz empfängt.
-
Die steckenseitige Rechenumgebung und die fahrzeugseitige Rechenumgebung sind getrennt voneinander organisiert, da sich die Fahrzeuge, die an der Verwirklichung des auszuführenden Sollfahrplans beteiligt sind und somit gemeinsam die fahrzeugseitige Rechenumgebung bilden, in dem spurgeführten Verkehrsnetz bewegen müssen. Genau genommen bildet jedes Fahrzeug, welches sich in dem Verkehrsnetz bewegt, einen selbständigen Teil der fahrzeugseitigen Rechenumgebung mit jeweils mindestens einer Recheninstanz aus. Die streckenseitige Rechenumgebung kann dabei für mehrere Fahrzeuge gleichzeitig eingesetzt werden. Bei der Ausführung des Verfahrens werden sowohl Rechenressourcen der fahrzeugseitigen Rechenumgebung als auch Rechenressourcen der streckenseitigen Rechenumgebung genutzt, wie im Folgenden genauer ausgeführt wird. Dabei ist es notwendig, die in den Rechenumgebungen ablaufende Software in Form von geeigneten Programmmodulen auf die fahrzeug seitige Rechenumgebung und die streckenseitige Rechenumgebung aufzuteilen.
-
Die Nachricht, die den aktualisierten Fahrplan betrifft, wird durch mindestens eine Recheninstanz empfangen und steuerungstechnisch (streckenseitig sowie fahrzeugseitig) derart umgesetzt, dass das Fahrzeug unter Berücksichtigung der geltenden Sicherheitsvorgaben den aus dem aktualisierten Fahrplan resultierenden Sollfahrplan einhalten kann. Die Sicherheitsvorgaben werden bei der Berechnung des aktualisierten Fahrplans in der ersten Recheninstanz berücksichtigt, damit der aktualisierte Fahrplan nach Übermittlung an das Fahrzeug (zumindest mit hoher Wahrscheinlichkeit) auch umsetzbar ist.
-
Unter einem auszuführenden Sollfahrplan versteht man im Rahmen dieser Erfindungsbeschreibung einen Sollfahrplan, der gerade in Ausführung ist oder mit deren Ausführung sofort begonnen werden soll (auch aktuell auszuführender Sollfahrplan bezeichnet) bzw. einen Sollfahrplan, der in Zukunft ausgeführt werden soll. Dabei kann die zukünftige Ausführung des auszuführenden Sollfahrplans auch optional sein.
-
Unter einem realisierbaren Istfahrplan ist ein Fahrplan zu verstehen, der auftretende Konflikte zumindest teilweise löst (d.h. Verspätungen auflöst oder zumindest verringert). Allerdings wird dieser Istfahrplan bei Auftreten eines Konfliktes zunächst ohne eine Optimierung direkt aus dem auszuführenden Sollfahrplan abgeleitet. Es wird somit lediglich steuerungstechnisch auf die gerade auftretenden Konflikte reagiert, wodurch gewöhnlich Verspätungen der betroffenen Fahrzeuge entstehen. Als Beispiel ist zu nennen, dass ein Fahrzeug nicht planmäßig in einen Gleisabschnitt einfahren wird, der aufgrund einer Verzögerung durch ein vorausfahrendes Fahrzeug, welches diesen Gleisabschnitt bereits hätte verlassen müssen, noch blockiert wird. Als realisierbare Istfahrpläne sollen allerdings auch Fahrpläne bezeichnet werden, die bereits einen gewissen Grad an Optimierung hinsichtlich des Auftretens von Konflikten erreicht haben, deren weiteres Optimierungspotenzial jedoch noch ungewiss ist und deren weiteres Optimierungspotenzial noch gehoben werden soll. In diesem Sinne wird jeder aktualisierte Fahrplan als realisierbarer Istfahrplan behandelt, unabhängig davon, wie gut die Optimierung gelungen ist. Im Rahmen dieser Erfindungsbeschreibung kann ein realisierbarer Istfahrplan immer dann als ein (aktuell) auszuführender Sollfahrplan verwendet werden, wenn ein Optimierungsprozess abgeschlossen werden soll.
-
Rechnergestützt oder computerimplementiert ist eine Vorrichtung, wenn diese eine Rechenumgebung aufweist, oder ein Verfahren, wenn eine Rechenumgebung mindestens einen Verfahrensschritt des Verfahrens ausführt.
-
Eine Rechenumgebung ist eine IT-Infrastruktur, bestehend aus Funktionskomponenten wie Prozessoren, Speichereinheiten, Programmen und aus mit den Programmen zu verarbeitenden Daten, die zur Ausführung mindestens einer Applikation, die eine Aufgabe zu erfüllen hat, verwendet werden. Weitere Funktionskomponenten können aus Sensoren und Aktuatoren bestehen, welche eine Interaktion der Rechenumgebung mit der Außenwelt ermöglichen. Die IT-Infrastruktur kann auch als Netzwerk der genannten Funktionskomponenten organisiert sein.
-
Recheninstanzen bilden innerhalb einer Rechenumgebung oder mehrerer Rechenumgebungen funktionale Einheiten aus, die Applikationen (gegeben beispielsweise durch eine Anzahl von Programmmodulen) zugeordnet werden können und diese ausführen können. Diese funktionalen Einheiten bilden bei der Ausführung der Applikation physikalisch (beispielsweise Computer, Prozessor) und/oder virtuell (beispielsweise Programmmodul) in sich geschlossene Systeme.
-
Computer sind aus mehreren Funktionskomponenten bestehende elektronische Geräte mit Datenverarbeitungseigenschaften. Computer können beispielsweise Clients, Server, Handheld-Computer, Kommunikationsgeräte und andere elektronische Geräte zur Datenverarbeitung sein, die Prozessoren und Speichereinheiten aufweisen können und über Schnittstellen auch zu einem Netzwerk zusammengeschlossen sein können.
-
Prozessoren können beispielsweise Wandler, Sensoren zur Erzeugung von Messsignalen oder elektronische Schaltungen sein. Bei einem Prozessor kann es sich um einen Hauptprozessor (engl. Central Processing Unit, CPU), einen Mikroprozessor, einen Mikrocontroller, oder einen digitalen Signalprozessor, möglicherweise in Kombination mit einer Speichereinheit zum Speichern von Programmbefehlen und Daten handeln. Auch kann unter einem Prozessor ein virtualisierter Prozessor oder eine Soft-CPU verstanden werden.
-
Speichereinheiten können auf computerlesbaren Speichern in Form von Arbeitsspeichern (engl. Random-Access Memory, RAM) oder Datenspeichern (Festplatte oder Datenträger) ausgeführt sein.
-
Programmmodule sind einzelne Software-Funktionseinheiten, die einen erfindungsgemäßen Programmablauf von Verfahrensschritten ermöglichen. Diese Software-Funktionseinheiten können in einem einzigen Computerprogramm oder in mehreren miteinander kommunizierenden Computerprogrammen verwirklicht sein. Die hierbei realisierten Schnittstellen können softwaretechnisch innerhalb eines einzigen Prozessors umgesetzt sein oder hardwaretechnisch, wenn mehrere Prozessoren zum Einsatz kommen.
-
Schnittstellen können hardwaretechnisch, beispielsweise kabelgebunden oder als Funkverbindung, oder softwaretechnisch, beispielsweise als Interaktion zwischen einzelnen Programmmodulen eines oder mehrerer Computerprogramme, realisiert sein und dienen einem Austausch von Daten vorzugsweise in Form von digitalen Datensätzen oder analogen Signalen.
-
Zur Vermeidung von Missverständnissen sei an dieser Stelle angemerkt, dass einzelne Anspruchsmerkmale mit kleinen lateinischen Buchstaben durchnummeriert werden, ohne dass dabei Rücksicht auf die Anspruchsnummerierung genommen wird. Dies bedeutet, dass jeder Buchstabe im gesamten Anspruchssatz nur einmal vorkommt, was eine eindeutige Adressierung der betreffenden Anspruchsmerkmale ohne Nennung der Anspruchsnummer ermöglicht. Deswegen kommt der Reihenfolge der Buchstaben jedoch keine Bedeutung zu.
-
Erfindungsgemäß ist vorgesehen, dass
- d) in der ersten Recheninstanz eine erste Routine und zeitlich parallel zur ersten Routine eine zweite Routine ablaufen, zu deren Durchführen
- e) in der ersten Routine immer, wenn ein neuer realisierbarer Istfahrplan vorliegt, ein vorläufiger aktualisierter Fahrplan mit einem ersten Solver nach dem Verfahrensschritt b) berechnet wird, ohne Folgekonflikte in dem vorläufigen aktualisierten Fahrplan zu berücksichtigen (d.h., ohne bei einer Entscheidung zu einzelnen Konfliktlösungen bei der Mikrosimulation die resultierenden Folgekonflikte zu berücksichtigen), wobei der vorläufige aktualisierte Fahrplan als realisierbarer Istfahrplan an die zweite Routine übergeben wird,
- f) in der zweiten Routine immer, wenn ein realisierbarer Istfahrplan von der ersten Routine übergeben wurde, ein optimierter aktualisierter Fahrplan mit einem zweiten Solver nach dem Verfahrensschritt b) berechnet wird, wobei Folgekonflikte in dem optimierten aktualisierten Fahrplan berücksichtigt werden und wobei, solange ein Abbruchkriterium gemäß dem Schritt
- g) nicht erfüllt ist, der optimierte aktualisierte Fahrplan als realisierbarer Istfahrplan an die erste Routine übergeben wird,
- g) sobald das Abbruchkriterium erfüllt ist, der in den Schritten e) und f) zuletzt berechnete aktualisierte Fahrplan für den Schritt c) verwendet wird, wobei als Abbruchkriterium zumindest eine erste Bedingung berücksichtigt wird, dass gemäß dem Schritt f) im Vergleich zum zuletzt berechneten vorläufigen aktualisierten Fahrplan kein abweichender optimierter aktualisierter Fahrplan berechnet werden kann.
-
Erfindungsgemäß ist also vorgesehen, dass zur Lösung von Konflikten in einem Regelfahrplan, der gleichzeitig einen realisierbaren Istfahrplan darstellt (solange noch keine Konflikte aufgetreten sind), ein vergleichsweise schnell rechnender erster Solver verwendet wird, der dadurch, dass dieser nur basierend auf bestehenden Konflikten (hiermit sind die bereits eingetretenen oder direkt absehbaren Konflikte zu verstehen, die sich aus den Istparametern ergeben, es wird also auf lokaler Betrachtung der Konflikte gerechnet) rechnet, in kürzester Zeit eine Lösung für die bestehenden Konflikte berechnen kann. Diese Berechnung wird im Rahmen dieser Erfindungsbeschreibung als Mikrosimulation bezeichnet und das Ergebnis als vorläufiger aktualisierter Fahrplan bezeichnet, weil dieser aktualisierte Fahrplan gewöhnlich nicht alle absehbaren Konflikte (d. h. auch die sich durch Durchführung des vorläufigen aktualisierten Fahrplans ergebenden Folgekonflikte) optimieren kann. Das Mikrosimulation löst zwar alle Konflikte. Nur dadurch, dass bei jeder Entscheidung die Folgekonflikte ignoriert werden, sind die Lösungen normalerweise nicht optimal aus der globalen Sicht. Da der vorläufige aktualisierte Fahrplan dafür aber in kürzester Zeit zur Verfügung steht, kann dieser den bestehenden Regelfahrplan auch ersetzen, wodurch ohne technisch relevante Zeitverzögerungen auf die im ersetzten Regelfahrplan bestehenden Konflikte reagiert werden kann (hierzu im Folgenden mehr).
-
In diesem Zusammenhang wird als Regelfahrplan derjenige Fahrplan verstanden, der durch den Bahnbetreiber standardmäßig, also ohne Vorliegen jeglicher Konflikte vorgegeben wird und insofern schon vor Betriebsbeginn der betreffenden Fahrzeuge bekannt ist. Unter dem realisierbaren Istfahrplan ist nach einer Anpassung des Regelfahrplans der aktualisierte Fahrplan zu verstehen, welcher den Regelfahrplan ersetzt, um Konflikte zu lösen oder zumindest deren Auswirkungen in Form von Zugverspätungen möglichst zu minimieren. Mit anderen Worten wird das Verfahren, sobald der Regelfahrplan aktualisiert wurde, auch auf den aktualisierten Fahrplan angewendet, wenn weitere Konflikte auftreten.
-
Zu berücksichtigen ist aber, dass der betreffende vorläufige aktualisierte Fahrplan durch die individuellen Fahrzeuge normalerweise nicht vollständig technisch umsetzbar ist. Während die streckenseitige Rechenumgebung das TMS umsetzen kann, indem die Funktionalität eines Abgleiches zwischen dem Regelfahrplan und dem Istfahrplan und darauf aufbauend die Erstellung eines aktualisierten Fahrplans unter Berücksichtigung aller im Verkehrsnetz befindlichen Fahrzeuge und steckenseitiger Limitierungen (z. B. zulässige Zugfolgezeiten oder -abstände, die maximal zulässige Streckengeschwindigkeit) ausgefüllt wird, kann beispielsweise die fahrzeugseitige Rechenumgebung aktuelle Messwerte berücksichtigen, die in dem Fahrzeug aufgrund der Anforderungen an dessen Funktionalität ohnehin ermittelt werden müssen, die Möglichkeiten für das Fahrzeug aber physikalisch limitieren (z. B. das maximale Beschleunigungsvermögen, die fahrzeugbezogene zulässige Höchstgeschwindigkeit und das maximale Bremsvermögen). Diese Messwerte erlauben auch Rückschlüsse auf limitierende Faktoren für die Umsetzung des für das betreffende Fahrzeug geltenden Sollfahrplans, der aus dem aktualisierten Fahrplan abgeleitet wird.
-
Konflikte sind im Rahmen dieser Erfindungsbeschreibung folgendermaßen definiert.
- Ein Konflikt ist die Situation, in der mehr als ein Zug einen Streckenabschnitt betrieblich befahren könnten, aber nur ein Zug erlaubt ist. Alle anderen müssen warten, bis der Streckenabschnitt für sie frei wird.
- Wartezeiten und Verspätungen sind die Auswirkungen von Konflikten - Konfliktfolgen, die minimiert werden.
-
Folgekonflikte entstehen dadurch, dass sich die Fahrzeuge bei der Umsetzung ihres individuell ermittelten vorläufigen aktualisierten Fahrplans als Sollfahrplan gegenseitig beeinflussen würden. Hierdurch würden neue Wartezeiten entstehen, die erfindungsgemäß vermieden werden sollen. Darüber hinaus können als Folgekonflikte auch andere Beschränkungen definiert werden, wie z. B. eine früheste Abfahrtszeit von bestimmten Ressourcen (Bahnsteighalte) oder eine maximale Fahrtzeit zwischen zwei Ressourcen, die nützlich sein können, um sicherzustellen, dass ein Zug nicht zu lange braucht, um den nächsten Bahnhof zu erreichen. Daher kann das Optimierungsproblem für den Fahrplan als ein FJSP mit Blockierungs- und Warteverbotsbeschränkungen betrachtet werden. Sobald Streckenführungen für jeden Zug durch den ersten Solver festgelegt sind, kann diese Art von Problem effektiv durch eine disjunkte Lösung formuliert werden, die mit dem zweiten Solver aufgefunden werden kann. Dieser Vorgang wird im Folgenden als Makrosimulation bezeichnet. Dabei werden zur Realisierung schnellerer Berechnungszeiten die bei der Mikrosimulation berücksichtigten Limitierungen bei der Erstellung des optimierten aktualisiereten Fahrplans außer Acht gelassen.
-
Durch die Vereinfachung des FJSP in der zweiten Routine wird der optimierte aktualisierte Fahrplan zwar in stark verkürzter Rechenzeit gefunden, jedoch können erneut Konflikte auftreten, wenn der optimierte aktualisierte Fahrplan durch einzelne Fahrzeuge nicht umgesetzt werden kann. Daher wird der optimierte aktualisierte Fahrplan wieder in die erste Routine zurückgegeben, damit im Rahmen der Mikrosimulation verbliebene und insbesondere neu entstandene Konflikte erkannt werden können.
-
Der mehrmalige Wechsel zwischen der ersten Routine und der zweiten Routine wird insgesamt zu einer immer weiteren Verbesserung sowohl des vorläufigen aktuellen Fahrplans als auch des optimierten aktualisierten Fahrplans führen. Damit der Prozess gestoppt werden kann, wird mindestens eine Abbruchbedingung definiert. Hier wird zumindest geprüft, ob im Rahmen der zweiten Routine eine weitere Optimierung nicht mehr erreicht werden konnte. Dies ist der späteste sinnvolle Zeitpunkt, die Berechnung mittels der ersten Routine und der zweiten Routine abzubrechen und den dann gültigen aktuellen Fahrplan, bei dem es sich um dem in der letzten vorhergehenden ersten Routine berechneten vorläufigen aktualisierten Fahrplan handelt (denn eine weitere Optimierung war ja nicht möglich), als aktuell auszuführenden Sollfahrplan vorzugeben. D. h., dass dieser neue Sollfahrplan für den ab diesem Zeitpunkt durchzuführenden Verkehr in der betreffenden Bahninfrastruktur gültig ist. Mit anderen Worten erfolgt eine Optimierung wird in zwei Routinen iterativ, während sich die beiden Routinen gegenseitig beeinflussen:
Erste Routine: Es gibt einen einfachen schnellen Konfliktlöser (erster Solver), der integriert mit einer synchronen mikroskopischen Simulation schnell einzelne Konflikte löst; dabei entscheidet er über Fahrwege und Zugreihenfolgen. Dabei ignoriert er die Folgekonflikte (sie sind zum Zeitpunkt der Lösung noch unbekannt) und ist daher schnell (~ 300 ms pro Lauf). Die Lösung wird an die zweite Routine übergeben.
-
Zweite Routine: Aus den gelösten Konflikten mit Folgekonflikten wird ein Flexible-Job-Shop-Problem (FJSP) basierend auf Konflikten (nicht Infrastruktur wie gemäß dem Stand der Technik bekannt) formuliert und im Rahmen einer makroskopischen Simulation gelöst. Die korrigierten Konflikte werden in die erste Routine übergeben und erzwungen. Ein Konflikt ist eine "Maschine" in FJSP, betreffende Züge im Konflikt sind "Jobs" des FJSP. Verspätungsübertragungen zwischen Konflikten als Fahrzeiten aus der Mikrosimulation sind Transport-Zeiten im FJSP. Alternative Wege der Züge (alternative Konflikte auf diesen Wegen) sind der "Flexible"-Teil von FJSP (Flexible bedeutet im klassischen Verständnis, ein Job könnte auf mehreren alternativen Maschinen bearbeitet werden)
-
Im Laufe der Iterationen werden Konflikte im FJSP angereichert von vorherigen Läufen, so dass das FJSP mit der Zeit alle wichtigen Aspekte (Konflikte und deren Abhängigkeiten) der aktuellen Situation beinhaltet.
-
Es ist realistisch, dass der erste Lauf von erstem Solver (microskopische Simulation) eine Lösung unter 1 Sekunde berechnet, die ca. 90 % Konflikte optimal löst. Diese Lösung kann direkt umgesetzt werden. Die Iterationen gemeinsam mit dem FJSP werden realistischerweise 10- bis 20-mal durchlaufen innerhalb von 5 bis 10 Minuten, wobei jeder Zyklus 10 bis 20 Sekunden benötigt und eine neue (normalerweise) bessere Lösung produziert. Sogenannte MILP-Löser (MILP steht für Mixed-Integer Linear Programming oder Gemischt-Ganzzahliges Lineares Programmieren) nutzen Multicore-Prozessoren sehr effizient, so dass sie gut skalieren im Bereich 1 bis 64 cores.
-
Abschätzung für eine reale Lösung: Bei einem Land wie Norwegen, wurden in einem modellhaften Probelauf beim Laden eines Fahrplans auf die Infrastruktur mit vielen Abweichungen mit dem ersten Solver ca. 1300 Konflikte gelöst. Die meisten waren Einzelkonflikte ohne Folgekonflikte. Es ergaben sich 110 unabhängige, Folgekonflikte berücksichtigende Konfliktbäume mit dem größten Konfliktbaum von ca. 300 Konflikten. Alle Bäume ließen sich unabhängig mit dem zweiten Solver lösen. Die meisten Bäume (108 von 110) hatten 2 bis 4 Konflikte - diese ließen sich mit MILP geschlossen in Millisekunden lösen. Somit ergab sich für ein wichtiges FJSP eine Größe von ca. 300 binären Variablen. Die Aufgabe solcher Größe wurde zuverlässig schnell (in weniger als 1 Minute) und "gut" genug gelöst durch aktuelle MILP-Löser: CBC (opensource), CPLEX, Gurobi (kommerziell).
-
Bei dem Stand der Technik hätte dasselbe System bei einer ganzheitlichen Lösung durch einen einzigen Solver eine bedeutend höhere Komplexität. Bei einer Infrastruktur-basierten Formulierung hätte das FJSP eine Größe von mehr als 500.000 Variablen. Probleme dieser Größenordnung eigenen sich nicht für die Echtzeitlösung (nur für die Fahrplanerstellung im Voraus).
-
Beschrieben wird gemäß einem weiteren Aspekt der Erfindung eine streckenseitige Rechenumgebung eines spurgeführten Verkehrsnetzes, aufweisend mindestens eine Recheninstanz. Gemäß diesem Aspekt ist erfindungsgemäß vorgesehen, dass die streckenseitige Rechenumgebung eingerichtet ist, ein Verfahren wie vorstehend beschrieben auszuführen.
-
Beschrieben wird gemäß einem weiteren Aspekt der Erfindung ein spurgeführtes Fahrzeug mit einer fahrzeugseitigen Rechenumgebung, aufweisend mindestens eine Recheninstanz. Gemäß diesem Aspekt ist erfindungsgemäß vorgesehen, dass die fahrzeugseitige Rechenumgebung eingerichtet ist, ein Verfahren wie vorstehend beschrieben auszuführen. Die mit diesen Aspekten der Erfindung verbundenen Vorteile sind vorstehend bereits erläutert worden, wobei auf diese Vorteile verwiesen wird.
-
Beschrieben wird gemäß einem weiteren Aspekt der Erfindung ein Computerprogrammprodukt, enthaltend Programmbefehle, die gemeinsam durch eine streckenseitige Rechenumgebung eines spurgebundenen Verkehrsnetzes und eine fahrzeugseitige Rechenumgebung eines in dem Verkehrsnetz betriebenen spurgeführten Fahrzeugs ausführbar sind. Gemäß diesem Aspekt ist erfindungsgemäß vorgesehen, dass das Verfahren wie vorstehend beschrieben ausgeführt wird.
-
Gemäß der Erfindung wird somit ein Programmmodule enthaltendes Computerprogrammprodukt mit Programmbefehlen beschrieben, wobei die Programmmodule in derselben Recheninstanz oder mehreren Recheninstanzen der Rechenumgebung laufen können. Mittels des Computerprogrammproduktes, das ein Computerprogramm oder mehrere Computerprogramme umfassen kann, sind jeweils das erfindungsgemäße Verfahren und/oder dessen Ausführungsbeispiele ausführbar und mit der Ausführung werden die vorstehend beschriebenen Vorteile erreicht.
-
Beschrieben wird gemäß einem weiteren Aspekt der Erfindung ein computerlesbares Speichermedium, enthaltend Daten, welche als Datensätze vom Speichermedium gespeichert werden. Gemäß diesem Aspekt ist erfindungsgemäß vorgesehen, dass die Datensätze das vorstehend beschriebene Computerprogrammprodukt nach dem letzten voranstehenden Anspruch ausführbar machen.
-
Darüber hinaus wird somit eine Bereitstellungsvorrichtung zum Speichern und/oder Bereitstellen des Computerprogramms in Form eines computerlesbaren Speichermediums beschrieben. Die Bereitstellungsvorrichtung ist beispielsweise eine Speichereinheit, die das Computerprogramm speichert und zum Abruf bereitstellt. Alternativ oder zusätzlich ist die Bereitstellungsvorrichtung ein Netzwerkdienst, ein Computersystem, ein Serversystem, insbesondere ein verteiltes, beispielsweise cloudbasiertes Computersystem oder virtuelles Rechnersystem, welches das Computerprogramm auf einem computerlesbaren Speichermedium speichert und vorzugsweise in Form eines Datenstroms bereitstellt.
-
Die Bereitstellung erfolgt in Form von Programmmodule beschreibenden Programmdatensätzen als Datei, insbesondere als Downloaddatei, oder als Datenstrom, insbesondere als Downloaddatenstrom, des Computerprogrammproduktes. Das Computerprogrammprodukt wird beispielsweise unter Verwendung der Bereitstellungsvorrichtung in eine Rechenumgebung übertragen, sodass das erfindungsgemäße Verfahren in einer Recheninstanz oder mehreren Recheninstanzen dieser Rechenumgebung zur Ausführung gebracht werden kann.
Ausgestaltungen der Erfindung
-
Weiterbildungen der Erfindung beschreibende Varianten werden nachfolgend ohne Beschränkung des grundlegenden Gedankens der Erfindung erläutert.
-
Gemäß einer Variante sind die oben erklärten Aspekte der Erfindung dadurch bestimmt, dass,
- h) sobald ein vorläufiger aktualisierter Fahrplan fertiggestellt ist, dieser für den Schritt c) gemäß verwendet wird,
- i) so lange, bis der Schritt g) durchgeführt wird.
-
Das Merkmal h) bedeutet in diesem Zusammenhang, dass der vorläufige aktualisierte Fahrplan unmittelbar nach seiner Erstellung für den weiteren Ablauf des Verfahrens gemäß dem Verfahrensschritt c) verwendet wird. Dies impliziert, dass der vorläufige aktualisierte Fahrplan, welcher noch nicht die Folgekonflikte berücksichtigt, direkt als Grundlage für die nachfolgende Steuerung der Fahrzeuge zugrundegelegt wird, um eine schnelle Verbesserung zu ermöglichen, bevor ein optimierter aktualisierter Fahrplan bereitsteht.
-
Das Merkmal i) bedeutet hier und vorzugsweise, dass das Verfahren vorsieht, dass der vorläufige aktualisierte Fahrplan so lange verwendet wird, bis das in Anspruch 1 definierte Abbruchkriterium gemäß dem Schritt g) erfüllt ist. Dies stellt sicher, dass, solange keine endgültige Lösung vorliegt, der vorläufige aktualisierte Fahrplan den Betrieb der Fahrzeuge hinsichtlich auftretender Verspätungen zumindest einmalig schon teilweise verbessert, bis die endgültige Lösung gefunden wurde. Eine alternative Ausführungsform könnte in einem Szenario bestehen, in dem der vorläufige aktualisierte Fahrplan regelmäßig überprüft und bei Bedarf aktualisiert wird, um weiterhin einen möglichst optimalen Betrieb zu gewährleisten, bis das Abbruchkriterium eine endgültige Lösung signalisiert.
-
Gemäß einer Variante sind die oben erklärten Aspekte der Erfindung dadurch bestimmt, dass als Abbruchkriterium auch eine zweite Bedingung berücksichtigt wird, die darin besteht, dass eine vorgegebene Rechenzeit überschritten wird, wobei nur eine der besagten Bedingungen eintreten muss, damit das Abbruchkriterium als erfüllt betrachtet wird.
-
Gemäß einer Variante sind die oben erklärten Aspekte der Erfindung dadurch bestimmt, dass als Abbruchkriterium auch eine dritte Bedingung berücksichtigt wird, dass eine vorgegebene Zahl an Durchführungen der zweiten Routine und/oder eine vorgegebene Zahl an Durchführungen der ersten Routine nicht überschritten werden darf, wobei nur eine der besagten Bedingungen eintreten muss, damit das Abbruchkriterium als erfüllt betrachtet wird.
-
Das Merkmal "Abbruchkriterium" bedeutet hier, dass eine Grenze oder ein spezifischer Punkt bestimmt wird, zu dem die laufenden Berechnungen zur Planung und Optimierung von Fahrplänen eingestellt und der aktuelle Stand der Fahrplanberechnungen übernommen wird. In diesem Zusammenhang stellt das Abbruchkriterium sicher, dass das System effizient und rechtzeitig reagieren kann, um in Echtzeit eigesetzt zu werden.
-
Dass eine "vorgegebene Rechenzeit überschritten wird" bedeutet hier, dass die Berechnungen unterbrochen werden, sobald eine vordefinierte maximale Rechenzeit überschritten wird. Diese vordefinierte Rechenzeit ist eine festgelegte Dauer, die gewährleisten soll, dass die Berechnungen innerhalb eines bestimmten Zeitrahmens abgeschlossen werden, um eine rechtzeitige und effiziente Entscheidungsfindung zu ermöglichen.
-
Der Ausdruck "wobei nur eine der besagten Bedingungen eintreten muss, damit das Abbruchkriterium als erfüllt betrachtet wird" bedeutet hier, dass das Abbruchkriterium bereits dann erfüllt ist, wenn entweder die erste oder die zweite (oder die dritte, wenn vorhanden) Bedingung eingetreten ist. Das System benötigt demnach nicht alle Bedingungen, um das Abbruchkriterium als erfüllt zu betrachten.
-
In einer alternativen Ausführungsform könnte die "vorgegebene Rechenzeit" dynamisch und basierend auf unterschiedlichen Parametern wie der aktuellen Verkehrssituation oder der Systemauslastung angepasst werden. Eine weitere alternative Ausführungsform könnte vorsehen, dass anstelle einer strikten zeitlichen Grenze, eine rechenzeitabhängige Leistungsbewertung angewendet wird, bei der nach einer gewissen Rechenzeit das aktuelle Ergebnis bewertet wird und bei Erreichen einer vorbestimmten Ergebnisqualität die Berechnungen ebenfalls gestoppt werden. Diese Alternativen gewährleisten eine flexible Anpassung an verschiedene realitätsnahe Szenarien.
-
Gemäß einer Variante sind die oben erklärten Aspekte der Erfindung dadurch bestimmt, dass
j) in dem Schritt e) als Istparameter ein realisierbares Fahrprofil mindestens eines Fahrzeugs, das den vorläufigen aktualisierten Fahrplan umsetzen soll, berücksichtigt wird.
-
Ein Vorteil dieser Variante besteht darin, dass im Rahmen der Mikrosimulation Aspekte berücksichtigt werden können, die im Rahmen der Makrosimulation unberücksichtigt bleiben. Innerhalb der Mikrosimulation kann das reale Verhalten der Fahrzeuge wegen der geringen Komplexität des Teilproblems jeder Mikrosimulation berücksichtigt werden, da die Rechenzeiten dadurch nur unwesentlich ansteigen.
-
In den Fällen, wo der individuelle Sollfahrplan modifiziert werden muss und vorhandene Fahrzeitreserven ausgenutzt werden sollen, wird die minimal mögliche Fahrzeit eines Fahrzeugs zu einem interessierenden Timing Point benötigt. Hierfür kann die ATO-Onboard durch einen simulierten Sollfahrplan dazu genutzt werden, schnell eine genaue Prognose in Form eines Fahrprofils (auch Journey Profile genannt, siehe unten) zu berechnen, ohne größere Auswirkungen auf den Betrieb.
-
Bei dem Betrieb der ATO wird auf dem Fahrzeug eine energieoptimierte Trajektorie (hierbei kann es sich um ein Geschwindigkeitsprofil handeln, wobei die Geschwindigkeit in Abhängigkeit von der verstreichenden Fahrzeit oder dem zurückzulegenden Fahrweg des Fahrzeugs bestimmt ist, im Folgenden allgemein auch als Fahrprofil bezeichnet) berechnet. Diese benötigt ein möglichst genaues Modell des Fahrzeugs und seines Verhaltens (beispielsweise Widerstands-/Antriebskoeffizienten), die außerhalb des Fahrzeugs nur geschätzt werden können. Realitätsnahe Modellparameter werden aber üblicherweise während der Fahrt durch die regelungstechnische Beobachtung onboard ermittelt. Sobald diese zur Verfügung stehen, können diese erfindungsgemäß dann auch zur Berechnung einer vergleichsweise genauen und aktuell für das Fahrzeug geltenden Fahrzeit für den simlierten individuellen Sollfahrplan verwendet werden. Es handelt sich somit um Parameter, die im berechneten zuletzt berechneten aktualisierten Fahrplan zu Einsatz kommen sollen. Die genannten Parametersätze können Teil einer Datenbank sein, welche auch regelmäßig aktualisiert oder individualisiert werden kann.
-
Eine erfolgreiche Berechnung eines Fahrprofils bei den genannten Bedingungen gilt als Bestätigung, dass der erste Solver und die ATO TS auf jeden Fall Parametersätze umsetzen können, welche für den zuletzt erstellten aktualisierten Fahrplan gewählt wurden. Dies ist für die meisten Fahrsituationen gegeben. Für realisierbare Istfahrpläne, die aus der zweiten Routine in die erste Routine übergeben wurden, kann sich aber nachträglich ergeben, dass diese durch das betreffende Fahrzeug nicht umgesetzt werden können, da eine diesbezügliche Prüfung erfindungsgemäß in der zweiten Routine nicht stattgefunden hat. Das als Test unter den genannten Bedingungen berechnete Fahrprofil wird dann durch die ATO-OB erfindungsgemäß nicht länger verwendet, weil es lediglich zur Bestätigung der fahrzeugseitig verfügbaren Reserven berechnet wurde. Es wird abgelöst, indem ein realistisches Szenario für den aktuellen Fahrplan durch den ersten Solver zugrundegelegt und ein daraus berechneter Sollfahrplan an die ATO-OB gesendet wird. Dies berechnet dadurch sofort einen neues Fahrprofil, welches die tatsächlichen Erfordernisse für den (vorläufigen) aktualisierten Fahrplan erfüllt.
-
Der Vorteil der Bestätigung durch die ATO OB liegt darin, dass diese die augenblicklich geltenden realen Bedingungen für das betreffende Fahrzeug berücksichtigen kann und somit weniger kritische Szenarien mit sehr hoher Wahrscheinlichkeit als Fahrprofil umgesetzt werden können. Anschließend kann der erste Solver bei erforderlichen Fahrplanänderungen Parametersätze auswählen, die die real vorliegenden Fahrplankonflikte lösen und durch die ATO OB zur Berechnung tatsächlich verwendeter Fahrprofile mit sehr hoher Wahrscheinlichkeit erfolgreich verwendet werden können. Die hierzu erforderlichen Rechenzeiten können durch Vermeidung von Rekursionen daher vorteilhaft noch geringer ausfallen, wodurch das Verfahren effizienter angewendet werden kann.
-
Die ATO-OB und die ATO-TS können durch eine sog. SS-126 Schnittstelle verbunden sein (benannt nach UNISIG Standard für ATO over ETCS Subset 126). Die SS126-Schnittstelle beinhaltet einen Rückkanal, indem die ATO-OB als Antwort auf den Sollfahrplan eine Vorhersage zu den Timing Points, kurz TP, zurücksendet. Als Timing Points werden Orte in dem Streckenprofil bezeichnet, für die eine bestimmter Zeitpunkt spezifiziert ist, zu dem sich das Fahrzeug an dem betreffenden Ort befindet. Der Zeitpunkt kann eine Ankunftszeit (arrival time) oder eine Abfahrtszeit (departure time) sein, dann handelt es sich um einen sogenannten Stopping Point, oder ein Zeitpunkt der Vorbeifahrt (passing time), dann handelt es sich um einen sogenannten Passing Point. Diese Begrifflichkeiten stehen im Einklang mit dem UNISIG Standard für ATO over ETCS, beispielsweise Subset-125.
-
Die Schnittstelle SS126 sieht zwar vor, dass der ATO OB, also der fahrzeugseitige Teil der ATO, eine Prognose berechnen und an die ATO TS übertragen kann, aber die Nutzung von ATO OB seitens TMS als eine genaue Fahrzeitberechnung vor der Erstellung eines neuen individuellen Sollfahrplans für das Fahrzeug ist bisher nicht umgesetzt. Aktuell wird diese Information standardkonform nur (nachträglich) als Rückfallebene eingesetzt, falls das TMS einen nicht realisierbaren Sollfahrplan an das Fahrzeug übergibt.
-
Gemäß einer Variante sind die oben erklärten Aspekte der Erfindung dadurch bestimmt, dass
- k) in dem Schritt e) gemäß Anspruch 1 eine Nachricht, die einen den vorläufigen aktualisierten Fahrplan verwirklichenden, für das Fahrzeug individuellen Sollfahrplan betrifft, in die fahrzeugseitige Rechenumgebung gesendet wird,
- l) danach eine dritte Recheninstanz in der fahrzeugseitigen Rechenumgebung unter Berücksichtigung des individuellen Sollfahrplans ein individuelles Fahrprofil erzeugt und eine das Fahrprofil betreffende Nachricht an die streckenseitge Rechenumgebung sendet,
- m) in der streckenseitigen Rechenumgebung geprüft wird, ob das Fahrprofil den vorläufigen aktualisierten Fahrplan verwirklichen kann,
- n) wenn das Fahrprofil den vorläufigen aktualisierten Fahrplan nicht verwirklichen kann, der Schritt e) wiederholt wird, wobei das individuelle Fahrprofil als realisierbares Fahrprofil in dem Schritt j) verwendet wird.
-
Bei Konfliktlösungen gibt es Fälle, in denen minimale technische Fahrzeiten benötigt werden, um bestimmte Szenarien zu berechnen. Die ATO-OB sendet eine Antwort normalerweise innerhalb von 3 - 5 Sekunden. Falls der Zug dabei steht, kann seine Stehzeit für die Fahrzeit-Ermittlung genutzt werden ohne "Nebenwirkungen", dass das in der Testprozedur erzeugte Fahrprofil durch die ATO-OB umgesetzt wird. Falls der Zug fährt, würde der Zug die 3 - 5 Sekunden nach dem Erhalt des im Rahmen der Testprozedur erzeugten Fahrprofils zum Beispiel maximal beschleunigen (falls die V-Max noch nicht erreicht ist) und dabei zusätzliche Energie verbrauchen. Dieser Energieverbrauch wird aber im Interesse einer Fahrplanoptimierung nach dem erfindungsgemäßen Verfahren hingenommen, da bei der Fahrplanoptimierung ein größeres Potenzial für Energieeinsparungen gehoben werden kann und überdies Verspätungen minimiert werden können.
Exemplarische Ausführungsbeispiele der Zeichnung
-
Weitere Einzelheiten der Erfindung werden nachfolgend anhand der Zeichnung beschrieben. Gleiche oder sich entsprechende Zeichnungselemente sind in den einzelnen Figuren jeweils mit den gleichen Bezugszeichen versehen und werden nur insoweit mehrfach erläutert, wie sich Unterschiede zwischen den einzelnen Figuren ergeben. Bei den im Folgenden erläuterten Ausführungsbeispielen handelt es sich um bevorzugte Ausführungsformen der Erfindung. Bei den Ausführungsbeispielen stellen die beschriebenen Komponenten der Ausführungsformen jeweils einzelne, unabhängig voneinander zu betrachtende Varianten der Erfindung dar, welche die Erfindung jeweils auch unabhängig voneinander weiterbilden und damit auch einzeln oder in einer anderen als der gezeigten Kombination als Bestandteil der Erfindung anzusehen sind. Des Weiteren sind die beschriebenen Komponenten auch mit den vorstehend beschriebenen Varianten der Erfindung kombinierbar.
- Figur 1 zeigt ein Ausführungsbeispiel der erfindungsgemäßen Vorrichtungen, also der streckenseitigen Rechenumgebung und des spurgeführten Fahrzeugs, mit ihren Wirkzusammenhängen zwischen den zum Einsatz kommenden Funktionskomponenten schematisch.
- Figur 2 zeigt ein Ausführungsbeispiel einer Rechenumgebung für die Vorrichtungen gemäß Figur 1 als Blockschaltbild der einzelnen Funktionskomponenten und der zwischen diesen ausgebildeten Schnittstellen, wobei einzelne Recheninstanzen Programmmodule ausführen, die jeweils in einem oder mehreren der beispielhaft dargestellten Computer ablaufen können und wobei die gezeigten Schnittstellen demgemäß softwaretechnisch in einem Computer oder hardwaretechnisch zwischen verschiedenen Computern ausgeführt sein können.
- Figur 3 zeigt eine schematische Darstellung des Zusammenwirkens von Programmmodulen bzw. Recheninstanzen jeweils in der streckenseitigen Rechenumgebung und der fahrzeugseitigen Rechenumgebung, wobei die Fahrpläne und das Fahrprofil durch einen ersten Solver und einen zweiten Solver berechnet bzw. modifiziert werden.
- Figur 4 zeigt ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens als Flussdiagramm, wobei die gezeigten Verfahrensschritte einzeln oder in Gruppen durch Programmmodule verwirklicht sein können und wobei die Recheninstanzen und Schnittstellen gemäß Figur 2 beispielhaft angedeutet sind.
Detaillierte Beschreibung der Ausführungsbeispiele
-
Die Figur 1 zeigt eine exemplarisch dargestellte Umgebung, in der ein Zugbetrieb gesteuert und erfolgen kann. Ein Streckennetz ist exemplarisch durch ein Gleis GL dargestellt, auf dem sich ein Fahrzeug FZ befindet. Am Gleis GL sind im Folgenden noch näher erläuterte Streckenelemente STE vorgesehen, die eine Streckenseitige Infrastruktur bilden. Das Fahrzeug FZ, ein Stellwerk STW und eine Leitzentrale LZ bilden exemplarisch jeweils eine fahrzeugseitige Einheit (weitere nicht dargestellte Fahrzeuge FZ würden andere fahrzeugseitige Einheiten bilden) und eine streckenseitige Einheit. Mit Blick auf den Ablauf des Verfahrens, der rechnergestützt abläuft, werden diese Einheiten auch als fahrzeugseitige Rechenumgebung RUOB und streckenseitige Rechenumgebung RUTS bezeichnet.
-
Eine streckenseitige Rechenumgebung RUTS sowie eine fahrzeugseitige Rechenumgebung RUOB, in denen das erfindungsgemäße Verfahren abläuft, kann einer gemeinsamen Betrachtung von Figur 1 und Figur 2 entnommen werden. Die zum Einsatz kommenden Recheninstanzen und Funktionskomponenten interagieren durch Schnittstellen miteinander. Durch eine erste Schnittstelle S1 sind ein Fahrzeug FZ und ein Stellwerk STW über Antennen AT miteinander verbunden. Durch eine zweite Schnittstelle S2 sind eine Leitzentrale LZ und das Fahrzeug FZ über Antennen AT miteinander verbunden. Durch eine dritte Schnittstelle S3 sind das Fahrzeug FZ und ein Satellit zwecks Ortung mittels GNNS (z. B. GPS) miteinander verbunden. Durch eine vierte Schnittstelle S4 sind die Leitzentrale LZ und das Stellwerk STW miteinander verbunden. Mit anderen Worten sind die Leitzentrale LZ, das Stellwerk STW und das Fahrzeug FZ über Luftschnittstellen miteinander vernetzt und das Fahrzeug FZ kann sich mittels Satellitenunterstützung orten.
-
Das Stellwerk STW weist überdies Verbindungen zu diversen Streckenelementen STE auf, um eine Steuerung der streckenseitigen Infrastruktur durchführen zu können. Dies wird exemplarisch durch die folgenden Komponenten angedeutet (reale streckenseitige Infrastrukturen weisen selbstverständlich weitaus mehr Streckenelemente STE und auch zusätzlich andere Streckenelemente STE auf). Durch eine fünfte Schnittstelle S5 sind das Stellwerk STW und ein Achszähler AZ miteinander verbunden. Durch eine sechste Schnittstelle S6 sind das Stellwerk STW und eine Balise BL miteinander verbunden. Durch eine siebente Schnittstelle S7 sind das Stellwerk STW und ein Controller CTL mit einem nicht dargestellten Prozessor eines Lichtsignals SG miteinander verbunden. Durch eine achte Schnittstelle S8 sind das Stellwerk STW und ein Weichenantrieb WA mit einem nicht dargestellten Prozessor für eine Weiche W miteinander verbunden.
-
Gemäß Figur 2 sind die jeweils Recheninstanzen bildenden Computer näher dargestellt. Das Fahrzeug FZ, die Leitzentrale LZ, das Stellwerk STW und ein Streckenelement STE, welches beispielsweise der Achszähler AZ, die Balise BL, der Controller CTL oder der Weichenantrieb WA gemäß Figur 1 oder auch ein anderes Streckenelement STE sein kann, sind in Figur zwei jeweils schematisch als Kasten dargestellt, die jeweils mindestens einen Computer enthalten. Selbstverständlich können die Aufgaben in den einzelnen Einheiten auch jeweils durch mehrere interagierende Computer bearbeitet werden. Bei einem ersten Computer CP1 ist ein erster Prozessor PR1 mit einer ersten Speichereinheit SE1 durch eine elfte Schnittstelle S11 verbunden. Überdies ist exemplarisch ein Sensor SN (zum Beispiel ein Tachometer) in dem Fahrzeug FZ dargestellt, der über eine zehnte Schnittstelle S10 mit dem ersten Prozessor PR1 verbunden ist. In gleicher Weise können weiteren nicht dargestellte Sensoren SN zum Einsatz kommen. Bei einem zweiten Computer CP2 ist ein zweiter Prozessor PR2 mit einer zweiten Speichereinheit SE2 durch eine zwölfte Schnittstelle S12 verbunden. Bei einem dritten Computer CP3 ist ein dritter Prozessor PR3 mit einer dritten Speichereinheit SE3 durch eine 13. Schnittstelle S13 verbunden. Bei einem vierten Computer CP4 ist ein vierter Prozessor PR4 mit einer vierten Speichereinheit SE4 durch eine 14. Schnittstelle S14 verbunden. Ist im Rahmen dieser Erfindungsbeschreibung nur von Computern, Prozessoren, Speichereinheiten oder Schnittstellen die Rede, beziehen sich die Angaben allgemein auf alle der vorstehend im Einzelnen benannten Computer, Prozessoren, Speichereinheiten und weiteren Funktionskomponenten, die verbunden durch die Schnittstellen zur Bildung der besagten Rechenumgebungen beitragen.
-
In Figur 3 ist das Zusammenwirken einzelner Komponenten eines Zugleitsystems TMS unter Berücksichtigung der geltenden Fahrpläne und Fahrprofile FP dargestellt. Unterschieden wird, wie bereits erläutert, zwischen der streckenseitigen Rechenumgebung RUTS und der fahrzeugseitigen Rechenumgebung RUOB. Zum Einsatz kommen auf einer Planungsebene PLE in einer ersten Recheninstanz RI1 ein erster Solver SOV1 und ein zweiter Solver SOV2, die als Rechenprogramme eine Optimierung von Fahrplänen unter verschiedenen Gesichtspunkten durchführen. Diese haben Zugriff auf realisierbare Istfahrpläne FPI, die auf Grund von realen Störungen für das Verkehrsnetz gelten (allerdings nicht optimiert sind in Bezug auf beispielsweise eine kumulierte Verspätungszeit der an der Realisierung des realisierbaren Istfahrplans FPI beteiligten Fahrzeuge FZ) oder die durch den ersten Solver SOV1 in einer ersten Routine R1 oder den zweiten Solver SOV2 in einer zweiten Routine R2 (vgl. Figur 4) mit einem gewissen Grad beispielsweise der eben genannten Optimierung erstellt wurden. Für den aktuellen realisierbaren Istfahrplan gilt, dass dieser in dem Fahrzeug FZ, dessen fahrzeugseitige Rechenumgebung RUOB dargestellt ist, vorläufig als Sollfahrplan zum Einsatz kommen kann, auch wenn dieser noch nicht endgültig optimiert ist. In jedem Fall stehen dem ersten Solver SOV1 Daten über den realisierbaren Istfahrplan FPI zur Verfügung, der den tatsächlichen Ablauf im Verkehrsnetz beschreibt und beispielsweise aufgrund von Verspätungen oder anderen Störungen von dem Regelfahrplan FPR abweicht, ohne eine Optimierung durchlaufen zu haben. Mit diesem realisierbaren Istfahrplan FPI wird das Optimierungsverfahren gemäß der ersten Routine R1 und der zweiten Routine R2 gestartet.
-
Der erste Solver SOV1 kann basierend auf eine Analyse der Abweichungen zwischen dem Regelfahrplan FPR und einem realisierbaren Istfahrplan FPI, bei dem die Konflikte noch gar nicht gelöst sind (vor dem Starten der ersten Routine R1 und der zweiten Routine R2) oder noch nicht optimal gelöst sind (während des parallelen Durchlaufens der ersten Routine R1 und der zweiten Routine R2 vor Eintreten einer Abbruchbedingung) mittels einer mikroskopischen Simulation einen aktualisierten Fahrplan FPA berechnen, der auf Konflikte reagiert, die sich durch die festgestellten Abweichungen ergeben. Es wird angestrebt, die Störungen zu kompensieren und den aktualisierten Fahrplan FPA möglichst weit (also mit Blick auf die aufgetretenen und absehbaren Konflikte, nicht jedoch die sich daraus ergebenden Folgekonflikte) wieder an den Regelfahrplan FPR anzunähern, d. h. Verspätungen der an der Realisierung des Regelfahrplans FPR beteiligten Fahrzeuge FZ zu minimieren. Der vorläufige aktualisierte Fahrplan FPA kann als neuer realisierbarer Istfahrplan FPI an die erste Routine R1 übergeben werden.
-
Der zweite Solver SOV2 kann nun eine makroskopische Simulation durchführen, um den aktuellen realisierbaren Istfahrplan FPI, weiter zu optimieren. Hierbei liegt der Fokus auf den im realisierbaren Istfahrplan FPI nicht optimal gelösten Konflikten und Folgekonflikten. Der hierdurch entstehende aktualisierte Fahrplan FPA kann als neuer realisierbarer Istfahrplan FPI an die erste Routine R1 übergeben werden. Die in Figur 3 dargestellte Rekursion gilt somit für den ersten Solver SOV1 und den zweiten Solver SOV2, die dabei im Wechsel zum Einsatz kommen, um den realisierbaren Istfahrplan durch jeweilige Erzeugung aktualisierter Fahrpläne (vorläufig/optimiert) iterativ zu verbessern, bis eine Abbruchbedingung eingetreten ist (hierzu im Folgenden noch mehr).
-
Eine zweite Recheninstanz RI2 in einer Ausführungsebene AFE setzt die ATO-TS um. Hier wird streckenseitig gemeinsam mit einer dritten Recheninstanz RI3 im Fahrzeug FZ, die die ATO-OB umsetzt, auf der Grundlage des aktuellen realisierbaren Istfahrplans FPI, vorzugsweise dem nach Vorliegen der Abbruchbedingung, auf Grundlage des vorliegenden realisierbaren Istfahrplans FPI ein Sollfahrplan FPS berechnet und als Fahrprofil FP umgesetzt. Dieser Sollfahrplan FPS beinhaltet eine weitere Optimierung hinsichtlich des Energieverbrauchs des betreffenden Fahrzeugs FZ im Rahmen der Möglichkeiten des vorgegebenen realisierbaren Istfahrplans FPI. Im Beispiel gemäß Figur 3 erfolgt die Erzeugung des Sollfahrplans FPS in der ATO-TS und die Erzeugung des Fahrprofils FP in der ATO-OB, jedoch kann auch eine andere Arbeitsteilung zwischen der zweiten Recheninstanz RI2 und der dritten Recheninstanz RI3 umgesetzt werden. Im Ausführungsbeispiel gemäß Figur 3 gibt die dritte Recheninstanz RI3 das Fahrprofil FP auch an die zweite Recheninstanz RI2 zurück.
-
Als vierte Recheninstanz RI4 kommt die ATC-TS und als fünfte Recheninstanz RI5 die ATC-OB zum Einsatz. Im Zusammenspiel der vierten Recheninstanz RI4 mit der fünften Recheninstanz RI5 erfolgt eine sicherheitsrelevante Steuerung des Fahrzeugs FZ im Streckennetz. Dabei überprüft die fünfte Recheninstanz RI5 auch die Steuervorgaben der dritten Recheninstanz RI3. Sobald sich eine Verletzung der Sicherheitsvorgaben ergibt, greift die fünfte Recheninstanz RI5 ein, wobei die Steuerfunktionen der fünften Recheninstanz RI5 vor denjenigen der dritten Recheninstanz RI3 Vorrang haben.
-
Die erläuterte Ausführungsebene AFE kann während des Durchlaufens der ersten Routine R1 und zweiten Routine R2 auch zur Bewertung eines realisierbaren Istfahrplans verwendet werden, um dessen Umsetzbarkeit in der Ausführungsebene AFE zu überprüfen. Dies wird erfindungsgemäß vorzugsweise mit einem realisierbaren Istfahrplan durchgeführt, der durch den ersten Solver SOV1 erstellt wurde. Dieser kann auf der Ebene der Mikrosimulation in Zusammenarbeit mit dem betreffenden Fahrzeug FZ, auf Realisierbarkeit und insbesondere auch auf das Optimierungspotenzial hinsichtlich des Energieverbrauchs überprüft werden. Dadurch fließt das letztgenannte Optimierungspotenzial beispielsweise bereits in die erste Routine R1 mit ein, so dass der aus der parallelen Durchführung der ersten Routine R1 und der zweite Routine R2 resultierende aktualisierte Fahrplan FPA, der in den endgültigen realisierbaren ist Fahrplan umgesetzt wird, enthalten ist.
-
Zum Zwecke der Überprüfung eines durch den ersten Solver SOV1 erstellten aktualisierten Fahrplans FPA als realisierbaren Istfahrplan FPI in der Ausführungsebene AFE kann dieser optional nur für kurze Zeit in der Ausführungsebene AFE eingesetzt werden. Da es sich um einen realisierbaren Istfahrplan FPI handelt, ist dies unter den Gesichtspunkten der Funktionssicherheit unbedenklich. Die Überprüfung kann nach Vorliegen eines Bewertungsergebnisses abgebrochen werden, sodass die Umsetzung eines vorläufigen realisierbaren Istfahrplans FPI als Sollfahrplan in der Ausführungsebene AFE keine oder zumindest nur geringe Auswirkungen auf die tatsächliche Steuerung des Fahrzeugs FZ hat. Eine Überprüfung ist allerdings für eine Anwendung des erfindungsgemäßen Verfahrens nicht zwingend erforderlich.
-
Im Folgenden soll das erfindungsgemäße Verfahren beispielhaft, wie im Flussdiagramm gemäß Figur 4 dargestellt, schrittweise erläutert werden. Rechnergestützte Schritte erfolgen in den nicht näher dargestellten Prozessoren. Soweit hierbei die Schnittstellen gemäß Figur 1 und 2 genutzt werden, sind diese auch in Figur 4 gekennzeichnet.
-
In einem ersten Schritt 1 erfolgt der Start des Verfahrens sowohl in der streckenseitigen Rechenumgebung als auch in der fahrzeugseitigen Rechenumgebung RUOB (kurz: START).
-
In einem zweiten Schritt 2 erfolgt eine Abfrage, ob der Istfahrplan FPI dem Regelfahrplan FPR noch entspricht. (kurz: FPR=FPI?). Dies ist so lange der Fall, wie der Zugverkehr ungestört abläuft. Dies bedeutet, dass keine Verspätungen oder Zugausfälle auftreten. Andernfalls weicht der Istfahrplan FPI vom Sollfahrplan FPS ab. Wenn noch keine Abweichungen festgestellt werden können, wird die genannte Abfrage rekursiv wiederholt. Wird jedoch eine Abweichung festgestellt, geht es mit dem dritten Schritt 3 weiter.
-
In einem dritten Schritt 3 erfolgt eine Durchführung der ersten Routineim R1 ersten Solver SOV1 (kurz: EXE-R1). Bei dieser Routine wird ein aktualisierter Fahrplan FPA erstellt, der nachfolgend im vierten Schritt vier durch die zweite Routine R2 (zweiter Solver SOV2) weiterbearbeitet wird.
-
Optional kann ein ermittelter aktualisierter Fahrplan FPA als Sollfahrplan an die fahrzeugseitige Rechenumgebung RUOB übergeben werden, um in der Ausführungsebene AFE eine Optimierung hinsichtlich des Energieverbrauches durchzuführen (wie oben beschrieben). Auch eine Überprüfung, ob das betreffende Fahrzeug FZ bei der Ausführung des Istfahrplans FPI an seine physikalischen Grenzen stößt, kann in diesem Zusammenhang testweise erfolgen. Dann geht es weiter mit dem fünften Schritt 5, sonst mit dem vierten Schritt 4.
-
In einem vierten Schritt 4 erfolgt eine Durchführung der zweiten Routine R2 im zweiten Solver SOV2 (kurz: EXE-R2). Bei dieser Routine wird ein aktualisierter Fahrplan FPA erstellt, bei dem auch Folgekonflikte berücksichtigt werden.
-
In einem fünften Schritt 5 erfolgt eine Abfrage, ob ein Abbruchkriterium vorliegt, das eine Voraussetzung dafür bildet, die Ausführung der ersten Routine R1 sowie der zweiten Routine R2 abzubrechen (kurz ABB?). Das Abbruchkriterium kann zumindest die Bedingung enthalten, dass bei der Ausführung der zweiten Routine R2 keine Verbesserung des aktualisierten Fahrplans FPA im Vergleich zu dem als realisierbaren Istfahrplan FPI durch die erste Routine R1 übergebenen aktualisierten Fahrplan FPA mehr möglich war. Ist dies der Fall geht es weiter mit dem fünften Schritt 5. Ist dies nicht der Fall erfolgt eine Rekursion zum dritten Schritt 3.
-
In einem sechsten Schritt 6 erfolgt im Fahrzeug FZ die Erstellung eines Fahrprofils FP, d. h. Geschwindigkeitsverlauf über die noch zurückliegende Wegstrecke oder die noch verbleibende Fahrzeit bis mindestens zum nächsten Timing Point (kurz: FP). Bei der Erstellung des Fahrprofils FP werden in nicht dargestellter Weise sensorische Messwerte, die im Fahrzeug FZ erzeugt wurden, berücksichtigt.
-
In einem siebenten Schritt 7 erfolgt in der streckenseitigen Rechenumgebung übergreifend eine Prüfung, ob alle Fahrprofile der vom realisierbaren Istfahrplan betroffenen Fahrzeuge insbesondere unter Gesichtspunkten einer Energieoptimierung umsetzbar sind. Das Prüfungsergebnis kann in nicht näher dargestellter Weise in die erste Routine (Schritt 3) einfließen, um ein weiteres Optimierungspotenzial zu heben, solange die erste Routine und die zweite Routine noch parallel laufen.
-
In einem achten Schritt 8 erfolgt die Umsetzung des für das Fahrzeug FZ gerade geltenden Fahrprofils FP (kurz: EXE-FP). Dies hängt damit zusammen, dass die fahrzeugseitige Rechenumgebung RUOB nicht zwischen realisierbaren Istfahrplänen FPI gemäß dem dritten Schritt 3 und dem fünften Schritt 5 unterscheiden kann. Da die Grundlage in jedem Fall ein realisierbarer Istfahrplan ist, der evtl nur noch nicht abschließend optimiert ist, ist dies unbedenklich.
-
In einem elften Schritt 11 erfolgt nun die Umsetzung des im letzten Schritt berechneten Fahrprofils FP (kurz: EXE-FP). Hierbei handelt es sich um jenes Fahrprofil FP, mit dem der aktuelle Sollfahrplan eingehalten werden kann.
-
In einem 13. Schritt 13 erfolgt eine Abfrage, ob das Verfahren in der fahrzeugseitigen Rechenumgebung RUOB gestoppt werden soll, beispielsweise wegen Betriebsende (kurz: STP?). Wenn dies nicht der Fall ist, erfolgt eine Rekursion zum sechsten Schritt 6, sonst endet das Verfahren in der fahrzeugseitigen Rechenumgebung.
-
In einem 14. Schritt 14 erfolgt parallel zum 13. Schritt 13 eine Abfrage, ob das Verfahren in der streckenseitigen Rechenumgebung RUTS gestoppt werden soll (kurz: STP?). Ist dies der Fall, wird das Verfahren gestoppt. Ist dies jedoch nicht der Fall erfolgt eine Rekursion zum zweiten Schritt 2, um sicherzustellen, dass bei erneuten Fahrplanabweichungen das Verfahren zur Erstellung eines simulierten aktualisierten Fahrplans SFPA wiederholt wird.
-
In einem 15. Schritt 15 erfolgt ein Beenden des Verfahrens (kurz: STOP).
Bezugszeichenliste
-
- AFE
- Ausführungsebene
- AT
- Antenne
- AZ
- Achszähler
- BL
- Balise
- CP1
- erster Computer
- CP2
- zweiter Computer
- CP3
- dritter Computer
- CP4
- vierter Computer
- CTL
- Controller
- FP
- Fahrprofil
- FPA
- aktualisierter Fahrplan
- FPI
- Istfahrplan
- FPR
- Regelfahrplan
- FPS
- Sollfahrplan
- FZ
- Fahrzeug
- GL
- Gleis
- LZ
- Leitzentrale
- PLE
- Planungsebene
- PR1
- erster Prozessor
- PR2
- zweiter Prozessor
- PR3
- dritter Prozessor
- PR4
- vierter Prozessor
- R1
- erste Routine
- R2
- zweite Routine
- RI1
- erste Recheninstanz
- RI2
- zweite Recheninstanz
- RI3
- dritte Recheninstanz
- RI4
- vierte Recheninstanz
- RI5
- fünfte Recheninstanz
- RUOB
- fahrzeugseitige Rechenumgebung
- RUTS
- streckenseitige Rechenumgebung
- S1
- erste Schnittstelle
- S10
- zehnte Schnittstelle
- S11
- elfte Schnittstelle
- S12
- zwölfte Schnittstelle
- S13
- 13. Schnittstelle
- S14
- 14. Schnittstelle
- S2
- zweite Schnittstelle
- S3
- dritte Schnittstelle
- S4
- vierte Schnittstelle
- S5
- fünfte Schnittstelle
- S6
- sechste Schnittstelle
- S7
- siebente Schnittstelle
- S8
- achte Schnittstelle
- SE1
- erste Speichereinheit
- SE2
- zweite Speichereinheit
- SE3
- dritte Speichereinheit
- SE4
- vierte Speichereinheit
- SFPA
- simulierter aktualisierter Fahrplan
- SG
- Lichtsignal
- SN
- Sensor
- SOV1
- erster Solver
- SOV2
- zweiter Solver
- STE
- Streckenelement
- STW
- Stellwerk
- TMS
- Zugleitsystems
- W
- Weiche
- WA
- Weichenantrieb