Commit cba30c31 authored by Tobias Wegner's avatar Tobias Wegner
Browse files

chap 8.1, 8.4, 10, 11

parent 892833f6
......@@ -35,7 +35,7 @@ Die Übertragung der Daten erfolgt dabei über ein TCP/IP Protokoll. Der Server
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 uns möglich, beliebig viele Deadlocks gleichzeitig aufzulösen, wohingegen es uns 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 Abbildung \ref{fig:dl_act} ansehen, die den groben Ablauf des Deadlock-Controllers als Aktivitätsdiagramm aufzeigt.
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.
\begin{figure}[H]
\centering
......@@ -51,7 +51,7 @@ Man sieht, dass der Deadlock-Controller in einer Endlosschleife immer wieder üb
\caption{check_for_deadlock-Funktion des Deadlock-Controllers}
\end{figure}
Ein Zyklus entsteht dabei immer dann, wenn die angefragten Routen eine Runde im Gleisnetz bilden, sodass jeder Zug auf den Startpunkt eines anderen Zuges fahren möchte, und somit kein Zug fahren kann. Diese Art von Deadlock tritt nur bei Zügen auf, die in dieselbe Richtung fahren. Weiterhin können diese Deadlocks in unserem Gleisnetz zusammen mit den erstellten Routen frühestens bei drei gleichzeitig angefragten Routen in dieselbe Richtung entstehen. Die angefragten Routen werden dabei in einem Array \glqq requested\_routes\grqq{} im Stellwerk gespeichert.
Ein Zyklus entsteht dabei immer dann, wenn die angefragten Routen eine Runde im Gleisnetz bilden, sodass jeder Zug auf den Startpunkt eines anderen Zuges fahren möchte, und somit kein Zug fahren kann. Diese Art von Deadlock tritt nur bei Zügen auf, die in dieselbe Richtung fahren. Weiterhin können diese Deadlocks in unserem Gleisnetz zusammen mit den erstellten Routen frühestens bei drei gleichzeitig angefragten Routen in dieselbe Richtung entstehen. Die angefragten Routen werden dabei in einem Array \texttt{requested\_routes} im Stellwerk gespeichert.
\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 Bachelorprojekt im Stellwerk gezeigt haben, sollten behoben werden.
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 er 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}
......@@ -11,7 +11,7 @@ Weiterhin erfolgreich war die Erweiterung des Stellwerks um verschiedene Funktio
Eine Implementierung für vier Züge war ebenfalls angedacht, allerdings konnten wir unsere Überlegungen dazu nicht mehr umsetzen. 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 Algoritmus, 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.
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.
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
Model-Checking ist eine fundamentale Methode, um formal die Korrektheit eines Modells in Bezug zu einer gegebenen Spezifikation zu testen. So kann ein Modell eines Systems gegen eine bestimmte Spezifikation getestet werden, die entweder vom Modell erfüllt wird oder nicht. Dadurch kann nachgewiesen werden, ob das Modell einer Software schon die zu erreichenden Sicherheitseigenschaften erfüllt. Für weitere Tests, wie Model-Based-Testing und dafür benötigte Test-Case-Generation, ist das Model-Checking als Grundlage notwendig.
Model Checking ist eine fundamentale Methode, um formal die Korrektheit eines Modells in Bezug zu einer gegebenen Spezifikation zu testen. So kann ein Modell eines Systems gegen eine bestimmte Spezifikation getestet werden, die entweder vom Modell erfüllt wird oder nicht. Dadurch kann nachgewiesen werden, ob das Modell einer Software schon die zu erreichenden Sicherheitseigenschaften erfüllt. Für weitere Tests, wie Model-Based-Testing und dafür benötigte Test-Case-Generation, ist das Model-Checking als Grundlage notwendig.
Das Modell des Safetymonitors soll hierbei im Folgenden betrachtet und geprüft werden. Es wird hierbei darauf Wert gelegt, dass auf Livelock- und Deadlock-Eigenschaften geprüft wird. Dabei ist die zentrale Fragestellung, ob das Modell, wie es in Abbildung \ref{fig:ltl_check} zu sehen ist, in jeder Situation alle Worker-Threads ausführen kann und somit jede LTL-Formel getestet werden kann.
\begin{figure}[H]
......@@ -17,8 +17,9 @@ label=list:semacsp,
firstline=4,
lastline=27]{monitor.csp}
Initial befindet sich der Semaphor mit dem MAX\_WORKER Wert im Zustand SEMA\_HEAD. In diesem Zustand darf dieser nur entweder ganz auf down mit sem\_down\_max oder mit sem\_down einfach dekrementiert werden. Mit sem\_down\_max gelangt dieser in den Zustand SEMA\_BOTTOM und darf dann nur noch mit sem\_up\_max nach ganz oben oder mit sem\_up um einen Wert erhöht werden. sem\_down\_max beziehungsweise sem\_up\_max werden hierbei immer nur von dem Aggregator und sem\_up beziehungsweise sem\_down von den jeweiligen Worker-Threads ausgeführt.\newline
Zudem gibt es einen Zustand SEMA\_NON\_MAX, der den Zustand des Semaphor-Zählers zwischen HEAD und BOTTOM darstellt. Wird im Zustand SEMA\_HEAD ein sem\_down ausgeführt, so wird in den Zustand SEMA\_DOWN gewechselt. Dann wird entschieden, ob der Zähler-Wert schon der Minimalwert ist (Wechsel in SEMA\_BOTTOM) oder nicht (Wechsel in SEMA\_NON\_MAX). Im Zustand SEMA\_UP beziehungsweise SEMA\_DOWN wird das Erreichen des Maximalwertes und damit der Wechsel in SEMA\_HEAD beziehungsweise SEMA\_BOTTOM über das guarded-command-Pattern realisiert, wie in Zeile 18, 20, 22 und 24 zu sehen. Ist diese erfüllt, so wird der Zähler des Semaphors entweder um eins erhöht (SEMA\_UP) oder um eins verringert (SEMA\_DOWN). Im Zustand SEMA\_NON\_MAX darf dann nur noch entweder sem\_up beziehungsweise sem\_down ausgeführt werden.
Initial befindet sich der Semaphor mit dem \texttt{MAX\_WORKER} Wert im Zustand \texttt{SEMA\_HEAD}. In diesem Zustand darf dieser nur entweder ganz auf down mit \texttt{sem\_down\_max} oder mit \texttt{sem\_down} einfach dekrementiert werden. Mit \texttt{sem\_down\_max} gelangt dieser in den Zustand \texttt{SEMA\_BOTTOM} und darf dann nur noch mit \texttt{sem\_up\_max} nach ganz oben oder mit \texttt{sem\_up} um einen Wert erhöht werden. \texttt{sem\_down\_max} beziehungsweise \texttt{sem\_up\_max} werden hierbei immer nur von dem Aggregator und \texttt{sem\_up} beziehungsweise \texttt{sem\_down} von den jeweiligen Worker-Threads ausgeführt.\newline
Zudem gibt es einen Zustand \texttt{SEMA\_NON\_MAX}, der den Zustand des Semaphor-Zählers zwischen HEAD und BOTTOM darstellt. Wird im Zustand \texttt{SEMA\_HEAD} ein \texttt{sem\_down} ausgeführt, so wird in den Zustand \texttt{SEMA\_DOWN} gewechselt. Dann wird entschieden, ob der Zähler-Wert schon der Minimalwert ist (Wechsel in \texttt{SEMA\_BOTTOM}) oder nicht (Wechsel in \texttt{SEMA\_NON\_MAX}). Im Zustand \texttt{SEMA\_UP} beziehungsweise \texttt{SEMA\_DOWN} wird das Erreichen des Maximalwertes und damit der Wechsel in \texttt{SEMA\_HEAD} beziehungsweise \texttt{SEMA\_BOTTOM} über das guarded-command-Pattern realisiert, wie in Zeile 18, 20, 22 und 24 zu sehen. Ist diese erfüllt, so wird der Zähler des Semaphors entweder um eins erhöht (\texttt{SEMA\_UP}) oder um eins verringert (\texttt{SEMA\_DOWN}). Im Zustand \texttt{SEMA\_NON\_MAX} darf dann nur noch entweder \texttt{sem\_up} beziehungsweise \texttt{sem\_down} ausgeführt werden.
\subsubsection{Aggregator}
Der Aggregator hat im System die Aufgabe, Nachrichten zu empfangen und diese dann zu interpretieren. Anschließend aktualisiert dieser den digitalen Zwilling und gibt den Semaphor frei. Weiterhin wird ein Mutex für jeden Worker entsperrt, die nun LTL-Formeln des aktualisierten digitalen Zwillings prüfen sollen. Listing \ref{list:aggregatorcsp} zeigt die Implementierung in CSP.\newline
......@@ -29,11 +30,13 @@ label=list:aggregatorcsp,
firstline=36,
lastline=60]{monitor.csp}
Dieser ist initial im Zustand AGGREGATOR und wartet über aggregator\_msg auf Nachrichten vom IXL oder der Märklin-Station. Danach setzt dieser das Semaphor auf sem\_down\_max, damit der Zugang zum kritischen Bereich für alle Worker-Threads verschlossen bleibt. Anschließend wird entweder der digitale Zwilling vom IXL oder von der Märklin-Anlage aktualisiert. Daraufhin wird der Semaphor wieder mit sem\_up\_max freigegeben und die Mutexe der jeweiligen Worker-Threads mit start\_ltl\_check freigegeben, sodass diese beginnen, die notwendigen LTL-Formeln des zuvor aktualisierten Zwillings zu prüfen. Danach gelangt der Aggregator wieder in den Initialzustand.
Dieser ist initial im Zustand \texttt{AGGREGATOR} und wartet über \texttt{aggregator\_msg} auf Nachrichten vom IXL oder der Märklin-Station. Danach setzt dieser das Semaphor auf \texttt{sem\_down\_max}, damit der Zugang zum kritischen Bereich für alle Worker-Threads verschlossen bleibt. Anschließend wird entweder der digitale Zwilling vom IXL oder von der Märklin-Anlage aktualisiert. Daraufhin wird der Semaphor wieder mit \texttt{sem\_up\_max} freigegeben und die Mutexe der jeweiligen Worker-Threads mit \texttt{start\_ltl\_check} freigegeben, sodass diese beginnen, die notwendigen LTL-Formeln des zuvor aktualisierten Zwillings zu prüfen. Danach gelangt der Aggregator wieder in den Initialzustand.
\newpage
\subsubsection{Worker-Threads}
Jeder Worker-Thread ist für das Prüfen einer bestimmten LTL-Formel zuständig. Jeder Worker-Thread wartet nur auf den Aggregator, dass dieser ein Start-Signal in Form eines MUTEX\_UNLOCK (start\_ltl\_check) gibt, um den LTL-Check zu starten. Listing \ref{list:workercsp} zeigt die Implementierung in CSP.
Jeder Worker-Thread ist für das Prüfen einer bestimmten LTL-Formel zuständig. Jeder Worker-Thread wartet nur auf den Aggregator, dass dieser ein Start-Signal in Form eines \texttt{MUTEX\_UNLOCK} (\texttt{start\_ltl\_check}) gibt, um den LTL-Check zu starten. Listing \ref{list:workercsp} zeigt die Implementierung in CSP.
\lstinputlisting[
caption={CSP-Implementation eines Worker-Threads},
......@@ -43,7 +46,8 @@ lastline=78]{monitor.csp}
Jeder Worker-Prozess in CSP ist mit einem Wert parametrisiert. Dieser Wert ist die ID des jeweiligen Worker-Threads.
Zu Beginn ist jeder Worker-Thread im Zustand WORKER(i). Dieser wartet dann so lange, bis das Startsignal für diesen Worker in Form eines MUTEX\_UNLOCK (start\_ltl\_check) vom Aggregator gesendet wird. Danach dekrementiert jeder Worker-Thread den Semaphor um eins und beginnt mit dem Homing-Algorithmus. Anschließend wird der Semaphor wieder inkrementiert und wechselt in den Initialzustand.
Zu Beginn ist jeder Worker-Thread im Zustand \texttt{WORKER(i)}. Dieser wartet dann so lange, bis das Startsignal für diesen Worker in Form eines \texttt{MUTEX\_UNLOCK} (\texttt{start\_ltl\_check}) vom Aggregator gesendet wird. Danach dekrementiert jeder Worker-Thread den Semaphor um eins und beginnt mit dem Homing-Algorithmus. Anschließend wird der Semaphor wieder inkrementiert und wechselt in den Initialzustand.
\subsubsection{Das Safety-Monitor System}
Zum Testen wird in CSP nun aus diesen drei Elementen (Semaphor, Aggregator und Worker) das Gesamtsystem gebaut. Listing \ref{list:systemcsp} zeigt die Implementierung.
......@@ -53,10 +57,11 @@ caption={CSP-Safety-Monitor System},
label=list:systemcsp,
firstline=81,
lastline=98]{monitor.csp}
Workers sind alle für das System notwendigen Worker-Threads in paralleler Ausführung ohne Synchronisation aufeinander. Der Safetymonitor besteht aus dem Aggregator und den Workern, die vom Aggregator über start\_ltl\_check aktiviert werden. Das Finale System ist dann der Safetymonitor, der mit dem Semaphor über alle Semaphor-Events verbunden ist.
Dieses System (SYSTEM\_SAFETY\_MONITOR) bildet das Modell, welches getestet werden soll.
\texttt{Workers} sind alle für das System notwendigen Worker-Threads in paralleler Ausführung ohne Synchronisation aufeinander. Der Safetymonitor besteht aus dem Aggregator und den Workern, die vom Aggregator über \texttt{start\_ltl\_check} aktiviert werden. Das Finale System ist dann der Safetymonitor, der mit dem Semaphor über alle Semaphor-Events verbunden ist.
Dieses System (\texttt{SYSTEM\_SAFETY\_MONITOR}) bildet das Modell, welches getestet werden soll.
\subsubsection{Tests}
......@@ -77,7 +82,7 @@ lastline=107]{monitor.csp}
% Hier ergebnisse
Um nun zu prüfen, ob der Aggregator immer den digitalen Zwilling aktualisieren kann, wird geprüft, ob das Semaphore immer auf sem\_up\_max und dann auf sem\_down\_max gesetzt werden kann. Falls dies einmal nicht möglich ist, schlägt dieser Test fehl. Listing \ref{list:systemcspaggregator} zeigt diesen Test.\newline
Um nun zu prüfen, ob der Aggregator immer den digitalen Zwilling aktualisieren kann, wird geprüft, ob das Semaphore immer auf \texttt{sem\_up\_max} und dann auf \texttt{sem\_down\_max} gesetzt werden kann. Falls dies einmal nicht möglich ist, schlägt dieser Test fehl. Listing \ref{list:systemcspaggregator} zeigt diesen Test.\newline
\lstinputlisting[
caption={CSP-Safety-Monitor System: Aggregator Test},
......@@ -87,7 +92,8 @@ lastline=116]{monitor.csp}
% Hier ergebnisse
Danach soll jeweils gezeigt werden, dass auf jeden Fall jeder Worker-Thread zum Ende kommt, das heißt, dass jeder Worker-Thread die eigene LTL-Formel prüfen kann, bis er zu einem Ergebnis kommt.\\
Das soll getestet werden, indem geprüft wird, ob für jeden Worker das Event worker\_do\_homing erzeugt wird. Dabei wird auf Trace-Verfeinerung geprüft, also ob der vom Modell erzeugte Trace dem der Spezifikation entspricht. Die Traces TRACE\_MAERKLIN und TRACE\_IXL beschreiben hier alle auftretenden Events auf dem Kanal worker\_do\_homing, die von den jeweiligen Worker-Threads erzeugt werden können.\newline
Das soll getestet werden, indem geprüft wird, ob für jeden Worker das Event \texttt{worker\_do\_homing} erzeugt wird. Dabei wird auf Trace-Verfeinerung geprüft, also ob der vom Modell erzeugte Trace dem der Spezifikation entspricht. Die Traces \texttt{TRACE\_MAERKLIN} und \texttt{TRACE\_IXL} beschreiben hier alle auftretenden Events auf dem Kanal \texttt{worker\_do\_homing}, die von den jeweiligen Worker-Threads erzeugt werden können.\newline
\newpage
\lstinputlisting[
caption={CSP-Safety-Monitor System: Worker Test},
......
Eine zentrale Aufgabe des Safetymonitors ist es, die Empfangenen Daten per LTL zu prüfen und bei Verletzung einen Notstopp auszulösen. Somit ist es unumgänglich diese Funktion genauer zu testen. Da sich die LTLs hauptsächlich auf die Geschwindigkeit des TCC in Bezug auf seine Streckenabschnitte beziehen, wird das im folgenden Modell spezifizierte Verhalten getestet.
Eine zentrale Aufgabe des Safetymonitors ist es, die Empfangenen Daten per LTL zu prüfen und bei Verletzung einen Notstopp auszulösen. Somit ist es unumgänglich diese Funktion genauer zu testen. Da sich die LTL hauptsächlich auf die Geschwindigkeit des TCC in Bezug auf seine Streckenabschnitte beziehen, wird das im folgenden Modell spezifizierte Verhalten getestet.
\begin{figure}[H]
\includegraphics[width=\linewidth]{safety_monitor/test/assets/tcc_speed_fsm_not_complete.PNG}
\caption{Modell des Geschwindigkeitsverhalten des TCC in Bezug auf Streckenabschnitte}
......
......@@ -404,9 +404,9 @@ Weitere Informationen können aus der Bachelorarbeit \glqq IXL Modelchecking mit
\sectionauthor{Jan Leuschner}
\input{safety_monitor/test/hm_test.tex}
\subsection{Deadlockanalyse bei der autonomen Bahnsteuerung} \label{sec:deadl-test}
\subsection{Deadlockanalyse der autonomen Bahnsteuerung} \label{sec:deadl-test}
\sectionauthor{Jan R. Kropp}
Die Korrektheit des Algorithmus wurde bereits in \ref{sec:deadl} behandelt.\\
Die Korrektheit des Algorithmus wurde bereits in \autoref{sec:deadl} behandelt.\\
Nun folgen die manuellen Tests, welche durch Eingabe unterschiedlicher Startparameter erzeugt wurden, um
eine korrekte Implementierung zu gewährleisten. Wir haben uns für manuelles Testen entschieden, da die Frage nach dem kürzesten Pfad zu einer bestimmter Zielsituation auf unserem Gleisnetz leichter von einem Menschen als einer Maschine überprüft werden kann. \newline
......@@ -420,7 +420,7 @@ Zuerst wurde eine ungültige Eingabe getätigt, in der zwar alle Startpositionen
Dadurch läuft der Algorithmus alle möglichen Knotenkonstellationen ab und stoppt erst, sobald alle Knotenkonstellationen
berechnet wurden.
Er gibt hierbei eine leere Route zurück und die Anzahl an berechneten Knotenkonstellationen wird ausgegeben.
Beispielsweise hat die Eingabe der Positionen 100 101 102 103 155 101 102 103 folgendes Ergebnis erzielt (Beachte, dass
Beispielsweise hat die Eingabe der Positionen 100 101 102 103 155 101 102 103 folgendes Ergebnis erzielt (zu beachten gilt, dass
nur Zahlen zwischen 0-255 korrekt funktionieren, da Traintupel aus Platzgründen versucht, jede Position in ein Byte zu platzieren,
was dazu führt, das Zahlen außerhalb dieses Bereiches als andere Zahlen gespeichert werden und Fehler verursachen.):
\begin{figure}[H]
......@@ -429,7 +429,7 @@ was dazu führt, das Zahlen außerhalb dieses Bereiches als andere Zahlen gespei
\caption{Durchlauf aller möglichen Knotenkombinationen}
\label{fig:deadl-test1}
\end{figure}
Wie bereits in \ref{sec:deadl} erwähnt, ist die Anzahl an Knoten 1585080. Dies sind alle Knoten, die auf einem Gleisnetz mit 37 Knoten und vier Zügen erstellt werden können, ohne das zwei Züge auf dem selben Feld stehen. Dies entspricht der Rechnung:
Wie bereits in \autoref{sec:deadl} erwähnt, ist die Anzahl an Knoten 1585080. Dies sind alle Knoten, die auf einem Gleisnetz mit 37 Knoten und vier Zügen erstellt werden können, ohne das zwei Züge auf dem selben Feld stehen. Dies entspricht der Rechnung:
$37*36*35*34 =1585080$
......@@ -454,7 +454,7 @@ Die Eingabe der Parameter 100, 101, 102, 103, 0, 0, 0, 205 führt zur folgender
In der ersten Zeile ist der Befehl des Aufrufs zu sehen. In der zweiten Zeile wird angemerkt, dass der Workthread seine Berechnungen angefangen hat.
In der nächsten Zeile wird der aktuelle Thread spezifiziert.
Das Ergebnis steht in der 5. Zeile. Die vierte Zeile zeigt an, dass ein Thread fertig ist mit Rechnen.
Das Ergebnis steht in der 5. Zeile. Die vierte Zeile zeigt an, dass ein Thread fertig ist.
Auch mit mehreren Zielen funktioniert der Algorithmus wie erwartet. Beispiel: 100, 218, 103, 221, 207, 200, 107, 210
\begin{figure}[H]
......@@ -492,7 +492,7 @@ und für Ziel besteht nur aus 0.
\end{figure}
\subsubsection{Fehlverhalten}
Wie bereits zum Eingang dieses Abschnittes erwähnt, führt ein unmögliches Ziel dazu, dass alle möglichen Knotenkombinationen berechnet werden müssen. Außerdem führen Zahlen außerhalb des Bereichs von 0-255 zu Fehlern, da sie als Zahl zwischen 0-255 interpretiert werden. Dies führt dazu, dass Zahlen außerhalb des Bereichs als Zahl modulo 256 interpretiert werden, was zu einem falschen Verhalten führt.
Wie bereits zum Eingang dieses Abschnittes erwähnt, führt ein unmögliches Ziel dazu, dass alle möglichen Knotenkombinationen berechnet werden müssen. Außerdem führen Zahlen außerhalb des Bereichs von 0-255 zu Fehlern, da sie als Zahl modulo 256 interpretiert werden.
Bei falscher Anzahl an Parametern gibt der Algorithmus nichts aus.
\begin{figure}[H]
......
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