Commit 5ac3e53b authored by Matthias Lange's avatar Matthias Lange
Browse files

Korrektur eigene Kapitel

parent 7948166d
\section{Deadlockauflösung durch Serveranwendung}
\sectionauthor{Matthias Lange}
In Kapitel \ref{sec:deadl} wurde ein Verfahren vorgestellt, mit welchem sich Deadlocks in unserem Gleisnetz unter Angabe der Positions- und Zielparameter der Züge on-the-fly auflösen lassen. Aus bestimmten Anlässen, war es nicht mehr möglich, die Anwendung in das IXL zu integrieren. Dennoch wurden bereits einige Überlegungen getroffen, wie eine Integration der Anwendung in das IXL aussehen könnte.
In Kapitel \ref{sec:deadl} wurde ein Verfahren vorgestellt, mit welchem sich Deadlocks in unserem Gleisnetz unter Angabe der Positions- und Zielparameter der Züge on-the-fly auflösen lassen. Aus bestimmten Anlässen war es nicht mehr möglich, die Anwendung in das IXL zu integrieren. Dennoch wurden bereits einige Überlegungen getroffen, wie eine Integration der Anwendung in das IXL aussehen könnte.
Zunächst muss dafür ein weiterer Controller zum IXL hinzugefügt werden, der sogenannte Deadlock-Controller. Dieser übernimmt die Aufgabe, einen Deadlock auf dem Gleisnetz zu erkennen. Denn wenn man nicht weiß, wann ein Deadlock auftritt, kann auch keine Lösung für einen Deadlock angefragt werden.
......@@ -33,7 +33,7 @@ Die Übertragung der Daten erfolgt dabei über ein TCP/IP Protokoll. Der Server
\caption{Kommunikation zwischen IXL und Server}\label{fig:ixl_server_comm}
\end{figure}
Für die Auflösung mehrerer Deadlocks wird in der Serveranwendung eine asynchrone Nutzung ermöglicht: Für jeden aufzulösenden Deadlock werden Kindprozesse gestartet, die jeweils eine Lösung für den Deadlock berechnen. Der Hauptprozess hört hingegen weiter auf eingehende Anfragen vom IXL. Sobald ein Kindprozess eine Lösung berechnet hat, wird diese an das IXl verschickt und der Kindprozess beendet sich. Durch diese Implementierung ist es möglich, beliebig viele Deadlocks gleichzeitig aufzulösen, wohingegen es in der bisherigen Implementierung nur möglich ist, einen Deadlock zur selben Zeit aufzulösen.
Für die Auflösung mehrerer Deadlocks wird in der Serveranwendung eine asynchrone Nutzung ermöglicht: Für jeden aufzulösenden Deadlock werden Kindprozesse gestartet, die jeweils eine Lösung für den Deadlock berechnen. Der Hauptprozess hört hingegen weiter auf eingehende Anfragen vom IXL. Sobald ein Kindprozess eine Lösung berechnet hat, wird diese an das IXL verschickt und der Kindprozess beendet sich. Durch diese Implementierung ist es möglich, beliebig viele Deadlocks gleichzeitig aufzulösen, wohingegen es in der bisherigen Implementierung nur möglich ist, einen Deadlock zur selben Zeit aufzulösen.
Nun stellt sich die Frage, wie der Deadlock-Controller eigentlich einen Deadlock erkennt. Dafür kann man sich \autoref{fig:dl_act} ansehen, die den groben Ablauf des Deadlock-Controllers als Aktivitätsdiagramm aufzeigt.
......@@ -67,7 +67,7 @@ Sobald Züge in zwei Richtungen auf dem Gleisnetz fahren, kommt es unweigerlich
\caption{blocking_routes-Funktion des Deadlock-Controllers}
\end{figure}
Beim Erhalten einer Auflösung für einen Deadlock vom Server verarbeitet das IXL die erhaltenen Daten zunächst, um anschließend die Routen in der richtigen Reihenfolge für die richtigen Züge freizugeben. Dafür wird aus dem Ablauf der Deadlockauflösung, die vom Server gesendet werden, zunächst die Priorität der Routen heraus gefiltert, indem bestimmt wird, welcher Zug wann fahren muss. Anschließend werden die Routen bestimmt, die die Züge fahren müssen, um den Deadlock entsprechend aufzulösen. Die Priorität der Routen und die Routen selber werden dann in einem letzten Schritt zusammengefügt. Schließlich werden dann die Sub-Controller in der Reihenfolge der Priorität von dem entsprechenden Zug gestartet.
Beim Erhalten einer Auflösung für einen Deadlock vom Server verarbeitet das IXL die erhaltenen Daten zunächst, um anschließend die Routen in der richtigen Reihenfolge für die richtigen Züge freizugeben. Dafür wird aus dem Ablauf der Deadlockauflösung, die vom Server gesendet werden, zunächst die Priorität der Routen herausgefiltert, indem bestimmt wird, welcher Zug wann fahren muss. Anschließend werden die Routen bestimmt, die die Züge fahren müssen, um den Deadlock entsprechend aufzulösen. Die Priorität der Routen und die Routen selber werden dann in einem letzten Schritt zusammengefügt. Schließlich werden dann die Sub-Controller in der Reihenfolge der Priorität von dem entsprechenden Zug gestartet.
\begin{figure}[H]
\centering
......
\sectionauthor{Jan Leuschner, Matthias Lange}
Das Ziel des Projektes Teamod war es die autonome Zugsteuerung, die schon im Bachelorprojekt bestand, um Sicherheitskomponenten und modellbasierte Tests zu erweitern. Auch Schwächen, die sich im Verlauf des Bachelorprojekts im Stellwerk gezeigt haben, sollten behoben werden.
Das System wurde erfolgreich um einen Safetymonitor erweitert, der die Geschwindigkeit der Züge mittels in LTL aufgestellter Sicherheitsformeln überprüft. Weiterhin berechnet diesr für jeden Zug einen Safety-Envelope, sodass die Züge kollisionsfrei das Schienennetz befahren können. Leider konnte der Safetymonitor nicht am echten System ausprobiert werden, da die Universität, und somit auch der Projektraum, aufgrund von Covid-19 gesperrt war.
Das Ziel des Projektes TEAMOD war es, die autonome Zugsteuerung, die schon im Bachelorprojekt bestand, um Sicherheitskomponenten und modellbasierte Tests zu erweitern. Auch Schwächen, die sich im Verlauf des Bachelorprojekts im Stellwerk gezeigt haben, sollten behoben werden.
Das System wurde erfolgreich um einen Safetymonitor erweitert, der die Geschwindigkeit der Züge mittels in LTL aufgestellter Sicherheitsformeln überprüft. Weiterhin berechnet dieser für jeden Zug einen Safety-Envelope, sodass die Züge kollisionsfrei das Schienennetz befahren können. Leider konnte der Safetymonitor nicht am echten System ausprobiert werden, da die Universität, und somit auch der Projektraum, aufgrund von Covid-19 gesperrt war.
Weiterhin erfolgreich war die Erweiterung des Stellwerks um verschiedene Funktionalitäten:
\begin{itemize}
\item Züge können nun in beide Richtungen fahren, wodurch das Streckennetz effizienter genutzt wird.
......@@ -9,9 +9,9 @@ Weiterhin erfolgreich war die Erweiterung des Stellwerks um verschiedene Funktio
\item Deadlocks mit drei Zügen werden im laufenden System erkannt und mittels Priorisierung und Ausweichrouten aufgelöst, damit jeder Zug sein Ziel letztendlich erreichen kann.
\end{itemize}
Eine Implementierung für vier Züge war ebenfalls angedacht, allerdings konnten die Überlegungen dazu, aus zeitlicher Sicht, nicht mehr umgesetzt werden. Bei vier Zügen treten unter anderem deutlich komplexere Deadlocksituationen auf, die aufgelöst werden müssten. Außerdem gäbe es deutlich weniger Platz auf dem Gleisnetz um Ausweichrouten für Züge zu finden.
Eine Implementierung für vier Züge war ebenfalls angedacht, allerdings konnten die Überlegungen dazu, aus zeitlicher Sicht, nicht mehr umgesetzt werden. Bei vier Zügen treten unter anderem deutlich komplexere Deadlocksituationen auf, die aufgelöst werden müssten. Außerdem gäbe es deutlich weniger Platz auf dem Gleisnetz, um Ausweichrouten für Züge zu finden.
Aufgrund dieser Herausforderungen ist es leider nicht gelungen das Stellwerk mittels modellbasierter Tests ausführlich zu testen. Stattdessen wurde es durch manuelle Läufe getestet.
Darüber hinaus wurde das nicht sehr triviale Deadlockproblem erfolgreich theoretisch analysiert und verstanden. Auch ein Algorithmus, der die aktuelle Konstellation der Züge übermittelt bekommt und daraufhin für jeden einen Pfad zu seinem Ziel ausrechnet, wurde entwickelt. Dieser ist sogar als Serveranwendung vorhanden, sodass das Stellwerk potentiell seine Deadlockauflösung extern anfragen kann. Leider hat die Zeit nicht gereicht, die Serveranwendung mit dem Stellwerk zu verbinden, sodass es ein zukünftiges Projektziel darstellt.
Zusätzlich hat das Teamod-Team einen Praktikanten während der Projektzeit erfolgreich betreut und zusammen mit diesem ein kurzes Video gedreht. Dieses Video zeigt die autonome Zugsteuerung im aktiven Betrieb und wie diese auf ihre Sicherheitsbedingungen geprüft wird.
Zusätzlich hat das TEAMOD-Team einen Praktikanten während der Projektzeit erfolgreich betreut und zusammen mit diesem ein kurzes Video gedreht. Dieses Video zeigt die autonome Zugsteuerung im aktiven Betrieb und wie diese auf ihre Sicherheitsbedingungen geprüft wird.
Letztendlich lässt sich zusammenfassen, dass der Großteil der gesetzten Ziele für das Projekt erreicht wurden und sich im Laufe des Projekt noch neue Aufgaben ergeben haben. Diese sind in Kapitel \ref{ausblick} zu finden.
\ No newline at end of file
......@@ -132,9 +132,9 @@ Falls jedoch die Verklemmungssituation immer noch besteht oder sich eine neue ge
\section{Passagier- und Güterzüge} \label{passagier-gueterzug}
\sectionauthor{Matthias Lange}
Um diese Bahnanwendung so weit wie möglich dem realen Bahnverkehr anzupassen, haben wurde eine Unterscheidung zwischen Passagier- und Güterzügen eingebaut. Im Bachelorprojekt haben sich Züge immer ein zufälliges Ziel auf dem Gleisnetz gesucht und eine Anfrage an das IXL gesendet, welches dem jeweiligen Zug dann unter Berücksichtigung seiner aktuellen Position eine gegebene Route ausgerechnet und die entsprechenden Streckenabschnitte, sobald diese durch keinen anderen Zug belegt sind, für den jeweiligen Zug freigegeben hat. Dieses Verhalten entspricht im realen Leben dem eines Güterzuges. Dieser hat keinen festgelegten Fahrplan den dieser Abfahren muss, sondern wird an einem Ort beladen und muss dann zu einem Zielort gelangen, wo seine Ware wieder entladen wird. Somit gibt es schon für Güterzuge eine valide Implementierung in der Bahnanwendung, wodurch das Verhalten von Passagierzügen und der Korrelation mit Güterzügen implementiert werden muss.
Um die Bahnanwendung so weit wie möglich dem realen Bahnverkehr anzupassen, wurde eine Unterscheidung zwischen Passagier- und Güterzügen eingebaut. Im Bachelorprojekt haben sich Züge immer ein zufälliges Ziel auf dem Gleisnetz gesucht und eine Anfrage an das IXL gesendet, welches dem jeweiligen Zug dann, unter Berücksichtigung seiner aktuellen Position, eine gegebene Route ausgerechnet und die entsprechenden Streckenabschnitte, sobald diese durch keinen anderen Zug belegt sind, für den jeweiligen Zug freigegeben hat. Dieses Verhalten entspricht im realen Leben dem eines Güterzuges. Dieser hat keinen festgelegten Fahrplan, den dieser Abfahren muss, sondern wird an einem Ort beladen und muss dann zu einem Zielort gelangen, wo seine Ware wieder entladen wird. Somit gibt es für Güterzuge schon eine valide Implementierung in der Bahnanwendung, wodurch nur noch das Verhalten von Passagierzügen und der Korrelation mit Güterzügen implementiert werden muss.
Passagierzüge wollen im Gegensatz zu Güterzügen einen bestimmten Fahrplan abfahren, den diese immer wiederholen und auch möglichst Zeitgenau abfahren möchten. Um dies zu realisieren, müssen Züge beim Starten und beim Registrieren im IXL angeben, ob es sich um einen Güter- oder Passagierzug handelt. Je nachdem, um welche Art von Zug es sich handelt, wird eine andere Routine beim Wählen der Route ausgeführt. Bei Güterzügen wird wie bisher ein zufälliges Ziel an das IXL gesendet. Bei Passagierzügen hingegen wird ein Fahrplan, der für den jeweiligen Zug im TCC hinterlegt sein muss, eingelesen und die Züge geben das jeweils nächste Ziel im Fahrplan an das IXL weiter. Im Fahrplan ist neben dem Ziel, welches der Zug als nächstes Anfahren soll, auch eine Zeit in Sekunden angegeben, die besagt nach welcher Zeit der Zug das nächste Ziel anfahren sollte. Erreicht ein Zug sein Ziel vor Ablauf der Zeit, wartet der Zug am Ziel solange, bis die Zeit abgelaufen ist und sucht sich erst dann das nächste Ziel im Fahrplan aus. Ansonsten bleibt der Zug nur kurz stehen, um Passagieren das Umsteigen zu ermöglichen, und fährt dann direkt weiter.
Passagierzüge wollen im Gegensatz zu Güterzügen einen bestimmten Fahrplan abfahren, den diese immer wiederholen und auch möglichst Zeitgenau abfahren möchten. Um dies zu realisieren, müssen Züge beim Starten und beim Registrieren im IXL angeben, ob es sich um einen Güter- oder Passagierzug handelt. Je nachdem, um welche Art von Zug es sich handelt, wird eine andere Routine beim Wählen der Route ausgeführt. Bei Güterzügen wird wie bisher ein zufälliges Ziel an das IXL gesendet. Bei Passagierzügen hingegen wird ein Fahrplan, der für den jeweiligen Zug im TCC hinterlegt sein muss, eingelesen und die Züge geben das jeweils nächste Ziel im Fahrplan an das IXL weiter. Im Fahrplan ist neben dem Ziel, welches der Zug als nächstes Anfahren soll, auch eine Zeit in Sekunden angegeben, die besagt, nach welcher Zeit der Zug das nächste Ziel anfahren sollte. Erreicht ein Zug sein Ziel vor Ablauf der Zeit, wartet der Zug am Ziel solange, bis die Zeit abgelaufen ist und sucht sich erst dann das nächste Ziel im Fahrplan aus. Ansonsten bleibt der Zug nur kurz stehen, um Passagieren das Umsteigen zu ermöglichen, und fährt dann direkt weiter.
%\begin{table}[H]
% \centering
......
......@@ -328,7 +328,7 @@ Für die Logik des Stellwerkes wurden die einzelnen Routen als Variablen modelli
\subsubsection{Dekomposition}
Da die Modellierung des gesamten Gleisnetzes in einem ersten Anlauf zu einer State-Explosion geführt hat, wurde mithilfe mehrerer Verfahren zur Dekomposition durch sogenannte \glqq Cuts\grqq{} von Anne E. Haxthausen et al. das Gleisnetz in mehrere Abschnitte unterteilt. Die Idee dahinter ist, den Zustandsraum für die Modellierung so zu verringern, dass es zu keiner State-Explosion mehr kommt, ohne die Eigenschaften des gesamten Modells zu verletzen. Es werden also alle Teilgleisnetze einzeln auf Fehler überprüft und es kann bewiesen werden, dass wenn alle Teilgleisnetze die Spezifikationen erfüllen, auch das ganze Gleisnetz die Spezifikationen erfüllt.
Für die Modellierung der Bahnanwendung wurden insgesamt drei Verfahren zur Dekomposition von Anne E. Haxthausen et al. in Betracht gezogen: Der Border Cut \cite{Macedo2017}, der Linear Cut \cite{Macedo2016} und der Horizontal Cut \cite{Fantechi2017}. Beim Border Cut hat sich jedoch schon früh gezeigt, dass die Anforderungen, um diesen auf unser Gleisnetz anzuwenden, nicht erfüllt sind und dieser somit im Projekt TEAMOD keine Anwendung findet. Dementsprechend wurden für die Aufteilung des Gleisnetzes nur der linear und der horizontal Cut angewendet. Daraus sind insgesamt 8 Teilnetzwerke entstanden, deren Aufteilung aus Abbildung \ref{fig:hcuts} ersichtlich werden. Die gelben Linien markieren dabei eine Trennung durch den Linear Cut und orange Linien eine Trennung durch den Horizontal Cut.
Für die Modellierung der Bahnanwendung wurden insgesamt drei Verfahren zur Dekomposition von Anne E. Haxthausen et al. in Betracht gezogen: Der Border Cut \cite{Macedo2017}, der Linear Cut \cite{Macedo2016} und der Horizontal Cut \cite{Fantechi2017}. Beim Border Cut hat sich jedoch schon früh gezeigt, dass die Anforderungen, um diesen auf unser Gleisnetz anzuwenden, nicht erfüllt sind und dieser somit im Projekt TEAMOD keine Anwendung findet. Dementsprechend wurden für die Aufteilung des Gleisnetzes nur der linear und der horizontal Cut angewendet. Daraus sind insgesamt 8 Teilnetzwerke entstanden, deren Aufteilung aus Abbildung \ref{fig:hcuts} ersichtlich wird. Die gelben Linien markieren dabei eine Trennung durch den Linear Cut und orange Linien eine Trennung durch den Horizontal Cut.
\begin{figure}[H]
\centering
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment