Abschlussbericht Praktikum Realzeitsysteme … · Durch diese intelligentere Steuerung kann...

Carl von Ossietzky Universitat OldenburgStudiengang Informatik

Abschlussbericht Praktikum RealzeitsystemeSommersemester 2006

von

Tilman Brock, Dominik Denker, Niels Hapke, Tobias Hesselmann,Kai Hylla, Melvin Isken, Jonas Jacobi, Frank Jellinghaus, Anke Lederer,

Sven Linker, Florian Marwede, Felix Jonathan Oppermann,Jan-David Quesel und Kiril Schroder

am 31. Oktober 2006

INHALTSVERZEICHNIS i

Inhaltsverzeichnis

1 Einleitung 1

2 Lok 32.1 Anforderungen Design . . . . . . . . . . . . . . . . . . . . . . 32.2 Design: Konstruktion . . . . . . . . . . . . . . . . . . . . . . . 3

2.2.1 Ubersetzungen . . . . . . . . . . . . . . . . . . . . . . 42.2.2 Rotationssensoren . . . . . . . . . . . . . . . . . . . . . 42.2.3 Lichtsensoren . . . . . . . . . . . . . . . . . . . . . . . 52.2.4 Technische Daten . . . . . . . . . . . . . . . . . . . . . 5

2.3 Anforderungen Programmierung . . . . . . . . . . . . . . . . . 62.4 Programmierung . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Radio Block Controller 123.1 Kollisionsfreiheit der Loks . . . . . . . . . . . . . . . . . . . . 12

3.1.1 Request . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.2 Release . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.3 Anfragenabarbeitung . . . . . . . . . . . . . . . . . . . 133.1.4 Streckenmodellierung . . . . . . . . . . . . . . . . . . . 14

3.2 Schrankenkontrolle . . . . . . . . . . . . . . . . . . . . . . . . 143.2.1 Aufbau der Schranke . . . . . . . . . . . . . . . . . . . 143.2.2 Probleme und Vorsichtsmaßnahmen . . . . . . . . . . . 153.2.3 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Verifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.1 Loks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.2 RBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.3 Fahrplan . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.4 Funktionsverifikation . . . . . . . . . . . . . . . . . . . 21

4 Strecke 234.1 Strecke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Vorgaben der Aufgabenstellung . . . . . . . . . . . . . 234.1.2 Konzeption . . . . . . . . . . . . . . . . . . . . . . . . 234.1.3 Bereitstellung . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Barcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Fahrplan 285.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 285.2 Aufbau des Programmes . . . . . . . . . . . . . . . . . . . . . 285.3 Grafische Benutzeroberflache . . . . . . . . . . . . . . . . . . . 28

INHALTSVERZEICHNIS ii

5.4 Fahrplanverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 315.4.1 Verwaltung des Streckennetzes (route network) . . . . 315.4.2 Verwaltung des Verkehrzustandes (train status) . . . 335.4.3 Verwaltung der Fahrplane (schedule) . . . . . . . . . 335.4.4 Wegberechnung (routing) . . . . . . . . . . . . . . . . 33

5.5 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.6 Einrichten des Programms in Eclipse . . . . . . . . . . . . . . 35

6 Kommunikation 376.1 Anforderungen und Bestehendes . . . . . . . . . . . . . . . . . 37

6.1.1 LNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.2.1 Sicherungsschicht . . . . . . . . . . . . . . . . . . . . . 386.2.2 Anwendungsschicht . . . . . . . . . . . . . . . . . . . . 396.2.3 Verwendete Pakete . . . . . . . . . . . . . . . . . . . . 39

6.3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . 416.3.1 Implementierung auf der RCX-Seite . . . . . . . . . . . 416.3.2 Implementierung auf PC-Seite . . . . . . . . . . . . . . 43

6.4 Verifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7 Fazit 46

1 EINLEITUNG 1

1 Einleitung

Die Abschlussaufgabe fur das Praktikum Realzeitsysteme besteht darin, ei-ne Fallstudie fur einen Teil des Standards “European Train Control Sy-stem(ETCS)” durchzufuhren. Hierbei handelt es sich um ein Zugsicherungs-system, welches mittelfristig im Hochgeschwindigkeitsverkehr und langfristigim gesamten europaischen Schienenverkehr eingesetzt werden soll. Nebender Zugsteuerung soll das ETCS auch die Zugsicherung im gesamten eu-ropaischen Raum zusammenfassen, wodurch zum einen die Kosten fur dieInstandhaltung und den Betrieb von ortsfesten Anlagen eingespart werdenund zum anderen eine hohere Interoperabilitat geschaffen wird. Durch dieseintelligentere Steuerung kann letztlich die Streckenkapazitat besser genutztwerden.

In dem hier abgehandelten Teil wird ein sogenannter Radio Block Con-troller(RBC) die Rolle der steuernden Einheit ubernehmen, indem es an dieZuge Fahrerlaubnisse fur die Einfahrt in gewisse Streckenabschnitte vergibt.Diese stellen kritische Abschnitte dar, die jeweils nur ein Zug zur gleichenZeit betreten darf. Die Strecke wird durch einen Linienplan simuliert, wobeidiese Linien die befahrbaren Gleise symbolisieren. Durch die Verwendungvon Lichtsensoren konnen die Zuge diesen Linien folgen, doch zur Steuerungbedarf es noch einer Positionsbestimmung. Hierzu werden zweierlei Systemeverwendet: Zum einen wird mit Hilfe eines Rotationssensors der zuruckgelegteWeg ermittelt – wegen der geringen Genauigkeit ist dieses nicht fur die ab-solute, sondern nur fur die zu bestimmten Eichpunkten relative Positionsbe-stimmung geeignet. Zum anderen werden sogenannte Barcodes aufgestellt,die eben diese Eichpunkte darstellen, an denen die absolute Position abgele-sen werden kann.

Da es sich um eine recht komplexe Aufgabe handelt, wurde sie in Teil-bereiche untergliedert, die jeweils von einer Kleingruppe zu bearbeiten war.In Abbildung 1 wird das Zusammenwirken der Teilbereiche dargestellt. Imfolgenden sind die einzelnen Teilbereiche kurz erlautert, eine detaillierte Be-schreibung erfolgt in den jeweiligen Kapiteln.

Lok Diese Gruppe ist fur den Bau und die Programmierung der Loko-motiven zustandig. Sie muss die Odometrie (Positionserkennung) und denWeichenfahralgorithmus, das Reservieren von Streckenabschnitten und demSichern der Bahnubergange zustandig implementieren. Sie ist auch fur dieIntegration des C-Codes, der auf den RCXen laufen soll, zustandig.

1 EINLEITUNG 2

Kommunikation

RBC

FahrplanLok

Strecke

Abbildung 1: Aufgabenverteilung

RBC Der RBC soll auf einem eigenen RCX laufen, der an der Strecke liegt.Der RBC muss sich merken welcher Zug welchen Teil der Strecke belegt undentsprechend Fahrtrechte an die Zuge vergeben. Er muss den wechselseitigenAusschluss sicherstellen (inklusive Verifikation in u einem Model-Checker)und Auffahrunfalle verhindern. Es soll außerdem einen Bahnubergang geben,der von dieser Gruppe in Lego gebaut wird und von dem RBC gesichert wird.

Strecke Diese Gruppe plant die gesamte Strecke und ist insbesondere furden Ausdruck zust”andig. Uber die Strecke mussen in regelmaßigen AbstandenBalisen (Barcodes) verteilt werden. Der Code zum Auslesen der Barcodesmuss ebenfalls von dieser Gruppe entwickelt werden. Hierbei kann auf dieErgebnisse des letzten Praktikums zuruckgegriffen werden. Die Strecke sollmehrere mehrgleisige Bahnhofe enthalten, Abstellgleise und Verbindungs-gleise, die in verschiedenen Richtungen befahren werden konnen, und einenBahnubergang geben.

Fahrplan Diese Gruppe entwirft die PC-Software, die die Fahrplane fur dieZuge generiert. Es soll eine grafische Benutzungsoberflache geben. Die gene-rierten Fahrplane sollen Deadlock-Freiheit, optimale Auslastung und kurzesteWege garantieren.

Kommunikation Diese Gruppe entwirft das Kommunikationsprotokoll in-klusive der Nachrichtenformate. Sie stellt Methoden zum Senden und Emp-fangen der Nachrichten fur RCX und PC bereit. Das Protokoll soll mit Up-paal verifiziert werden.

2 LOK 3

2 Lok

Die Aufgabe der Gruppe”Lok“ bestand darin, die Loks zu entwerfen, mit

Lego Mindstorms zu bauen und die Low-Level-Fahralgorithmen zu implemen-tieren. Vorgesehen sind drei Lokomotivmodelle, auf jedem werden die Fahral-gorithmen laufen. Zur Verfugung standen uns vier Mindstorm-Invention-Systeme mit drei RCX (Basiseinheiten), als Betriebssystem fur die RCXbenutzen wir nicht das originale Lego-Betriebssystem, sondern BrickOS, dasmit angepasstem C-Code programmiert werden kann.

2.1 Anforderungen Design

• Es sollen mehrere Loks gleichzeitig nebeneinander auf die Strecke pas-sen (in Bahnhofen, Abstellgleisen, etc.).

• Die Loks mussen einer ca. 2cm breiten Linie, die die Strecke / Schienemarkiert, folgen konnen.

• Die Loks mussen bei Weichen die Seite der Linie, die verfolgt wird,wechseln konnen.

• Die Loks mussen Barcodes an der Strecke scannen konnen.

• Der Kurvenradius muss eng genug sein, um 360-Grad-Schleifen (aller-dings nicht auf der Stelle) durchfahren zu konnen.

• Die Loks mussen uber ihren Infrarotsensor kommunizieren konnen (darfnicht verdeckt sein).

2.2 Design: Konstruktion

Zunachst wurden mehrere Lokomotiven-Modelle entwickelt und gebaut. Da-bei gab es bereits einige Probleme zu beachten, hauptsachlich bezuglich derFahreigenschaften der Loks. Die Modelle sollten im großen und ganzen auchlokomotivahnlich aussehen, was einige Einschrankungen hinsichtlich Designund Technik mit sich brachte.

Auch das Streckendesign spielte naturlich eine Rolle, da von den Abstan-den, Positionen, Kurvenradien u.a. abhing, welche genauen Daten die Lokshaben mussten. Im folgenden sind einige Konstruktionen abgebildet.

Alle Konstruktionen haben gemein, dass sie zwei Rader zum Antrieb be-nutzen. So wird ein kleiner Drehradius erziehlt. Als Vorderrad wird ein dreh-bares kleines Rad (unter dem Chassis versteckt) genutzt, damit die Loks sichmoglichst leicht drehen konnen.

2 LOK 4

Abbildung 2: Design 1, Seite Abbildung 3: Design 2

Abbildung 4: Design 3 Abbildung 5: Design 4

2.2.1 Ubersetzungen

Wert wurde auch auf eine anforderungsgerechte Uber-/Untersetzung der Mo-torleistung gesetzt (Kraft-Geschwindigkeit), genauso wie auf ausreichend fei-ne Auflosung des Rotationssensors zur Messung der gefahrenen Strecke. Zu-dem sollte die Geschwindigkeit nicht zu hoch sein, damit das Linetrackingund etwaige Fehlerkorrekturen moglich sind.

Die Ubersetzung der Motoren auf das Fahrwerk betragt 1:5, entsprechendeinem Zahnrad mit 8 Zahnen auf eins mit 40 Zahnen. Damit wurde eine aus-reichende Geschwindigkeit erzielt, genauso genug Kraft, um sogar noch einenAnhanger zu ziehen. Diese Moglichkeit wollten wir uns offen halten, um sieje nach Fortschritt des Projekts noch einzubauen.

2.2.2 Rotationssensoren

Die Auflosung des Rotationssensors wurde mit 3,52 Einheiten pro Zentimeterimplementiert, basierend auf einer druchgefuhrten Messung. Die Auflosungist fur alle Modelle gleich.

2 LOK 5

Abbildung 6: Die fertigen Loks, vonvorne

Abbildung 7: Die fertigen Loks, vonhinten

2.2.3 Lichtsensoren

Die Lichtsensoren liefern alle unterschiedliche Werte bei gleichen Bedingun-gen, so dass eine jeweilige Messung notig war, um die Werte zu bestimmen.In unserem Code ist das durch variable Gestaltung der Parameter leicht furjede Lok anpassbar, ohne den Code selbst andern zu mussen.

Codeausschnitt:

#i f ENGINE==1g eng ineConf ig . d i s t an c eS c a l e r =3.515 f ;g eng ineConf ig . min grey=0x21 ;g eng ineConf ig . max grey=0x2d ;#endif#i f ENGINE==2g eng ineConf ig . d i s t an c eS c a l e r =3.515 f ;g eng ineConf ig . min grey=0x23 ;g eng ineConf ig . max grey=0x28 ;#endif. . .

2.2.4 Technische Daten

Ebenso musste auf das Fahrwerk geachtet werden, da die bestmogliche Wen-digkeit erreicht werden sollte, um die Streckengestaltung moglichst wenigeinzuschranken. Das machte dann auch eine Kooperation mit der Strecken-planungsgruppe notig, um Streckenabstande, Barcodepositionen u.a. abzu-gleichen.

Folgende Werte sind fur unsere Loks spezifiziert (Tabelle 1):

Diese Werte sind bei jeder Lok gleich, um gleiche Fahreigenschaften zu er-halten. Das Außere ist frei gestaltbar und aus diesem Grunde bei jeder Lok

2 LOK 6

Radgrosse: 4,5 cm (Durchmesser)Radabstand: 8 cmBodenfreiheit: 0,5 cmLinetracker: 5,5 cm vor Antriebsachse, mittigBarcodeleser: 4 cm vor Antriebsachse, 4 cm rechts von Mittelachse

Tabelle 1: Feste Spezifikationen der Loks

leicht unterschiedlich. In ausfuhrlichen Fahrtests haben die Loks ihre Eignungunter Beweis gestellt.

Folgende Maße (Tabelle 2) sind in etwa einzuhalten, damit sich die Loksauf der Strecke nicht ins Gehege kommen. Die Hohe ist dafur naturlich nichtrelevant, allerdings wurde zwischenzeitlich angedacht, Kabel fur Schrankeninnerhalb der Strecke per Oberleitung nach innen zu fuhren, dafur ware dannauch die Hohe der Loks entscheidend gewesen.

Lange: ca. 18 cm (ohne Vorbau)Breite: ca. 12 cmHohe: ca. 13 cm

Tabelle 2: Grobe Maße der Loks

2.3 Anforderungen Programmierung

• Die Programmierung sollte ereignisgesteuert reagieren konnen.

• Es sollte so wenig Speicher wie moglich verwendet werden.

• Der Linetracker muss eine Seite der Linie tracken (verfolgen), nicht dieLinie selbst (Seitenwechsel bei Weichen).

• Die zuruckgelegte Strecke muss gemessen werden und entsprechend inreale Maße umgerechnet werden

• Unterschiedliche Messwerte fur gleiche Bedingungen (besonders bei Licht-sensoren) sollten moglichst leicht einbeziehbar sein

• Die Lok muss mit dem RBC (Radio Block Controller, ahnlich einer

”Streckenaufsicht“) um Streckenrechte verhandeln

• Die Lok muss einen empfangenen Fahrplan abarbeiten und neue Planeempfangen konnen.

2 LOK 7

2.4 Programmierung

Im Anschluss bzw. parallel galt es den Algorithmus zur Steuerung der Lokszu entwerfen. Diese und auch alle weiteren Funktionen wurden als Threadsimplementiert. Das ganze Modell der Software ist ereignisgesteuert.

Das beinhaltete zunachst einen Trackingalgorithmus zu programmierenum der Strecke folgen zu konnen, mit der Moglichkeit die Trackingseite zuwechseln, um bei Weichen die richtige Richtung einzuschlagen. Dazu wur-de der Algorithmus programmiert

”grau“ zu tracken, d. h., der Lichtsensor

ist die ganze Zeit auf der Kante zwischen dem weißen Hintergrund und derschwarzen Linie. Das vereinfacht den oben erwahnten Seitenwechsel bei Wei-chen deutlich. Diese Logik wird in der Methoden

”TrackingTask(void)“ und

”switchToNewTrackingSide()“ implementiert.

Hier ein Ausschnitt aus dem TrackingTask, mit den wesentlichen Funk-tionen, aber nur fur das Tracking auf der linken Seite, die rechte Seite funk-tioniert analog.

TrackingTask(int argc, char ∗∗argv) {wakeup t event;

ds active(&SENSOR LINETRACK);g engineConfig.updatingEngine=FALSE;g engineConfig.stopTracking=FALSE;

while(g engineConfig.stopTracking==FALSE) {motor right dir(fwd);motor left dir(fwd);motor right speed(g engineConfig.speed);motor left speed(g engineConfig.speed);event = wait event(grey lost, TIMEOUT(TRACKING TIMEOUT));if (event==EVT ENGINE NUMBER UP REQ) {

updateEngine();}else if (event==EVT TIMEOUT) {

//ignore timeouts}else if (event==EVT LIGHT WHITE) {

switch(g engineConfig.curTrackingSide) {case LEFT:

motor left speed(g engineConfig.speed);motor right speed(g engineConfig.brakePower);motor right dir(brake);event = wait event(white lost, MAX TIMEOUT);if (event==EVT ENGINE NUMBER UP REQ) {

updateEngine();

2 LOK 8

}break;

case RIGHT:...

}else if (event==EVT LIGHT BLACK) {switch(g engineConfig.curTrackingSide) {

case LEFT:motor left speed(g engineConfig.brakePower);motor left dir(brake);motor right speed(g engineConfig.speed);event = wait event(black lost, MAX TIMEOUT);if (event==EVT ENGINE NUMBER UP REQ) {

updateEngine();}break;

case RIGHT:...

Desweiteren musste mit Hilfe des Rotationssensors die Moglichkeit ge-schaffen werden, die bisher gefahrene Strecke zu messen. Wir haben unshier auf die Messgroße Zentimeter geeinigt. Die gelieferten Werte musstendementsprechend umgerechnet werden. Siehe auch “Konstruktion“. Die Me-thoden hierfur sind

”getRotationValue(volatile unsigned sensor)“ und

”di-

stance2rotation(distance t distance)“.Da nicht alle (Licht-)Sensoren die exakt gleichen Werte liefern, wurde es

ermoglicht, fur jede Lok die Sensoreigenschaften als Parameter anzugebenum den Code schnell bzw. automatisch anzupassen. Das geschieht mittelsKompilerparamertern (siehe Abschnitt Lichtsensoren 2.2.3).

Der Code um die Barcodes auszulesen wurde von der Streckenplanungs-gruppe in Abstimmung mit uns entwickelt und von uns integriert. Der gele-sene Barcode wird mit der gewunschten Strecke abgeglichen, um die Positionder Lok zu eichen.

Ein weiterer Teil war die Implementierung der Logik, um neue Streckenab-schnitte anzufragen, aktuelle zu besetzen und alte wieder freizugeben. Hierzuhatten wir uns in der ganzen Gruppe auf eine Kommunikationsstruktur ge-einigt, die mit den entsprechenden Funktionen eingearbeitet wurde.

Im folgenden die Initialisierungssequenz mit Registrierung der notigenHandler.

//init the com−task

2 LOK 9

if (com start() != 0) {return 0;

}

//register the handler for receiving grants.com install grant segment handler(&grantReceivedHandler);

//register the handler for receiving schedule entries.com install schedule receive handler(&scheduleReceiveHandler);

//initiate the rotation sensor.ds active(&SENSOR ROTATION);ds rotation on(&SENSOR ROTATION);ds rotation set(&SENSOR ROTATION, 0);

//start the tracking task.trackingTask = execi(&TrackingTask, 0, NULL, 20,

DEFAULT STACK SIZE∗2);if (trackingTask==−1) {

return −1;}

// start the scanner tastexeci(&barcode scanner, 0, NULL, PRIO NORMAL,

DEFAULT STACK SIZE);

Fur den Fahrplan wurde ein gemeinsames Format entwickelt, das vonder Fahrplangruppe erzeugt, von der Kommunikationsgruppe ubertagen undvon uns abgearbeitet wird. Die einzelnen Angaben werden in einem Arraygespeichert und dann abgearbeitet.

Im folgenden ein kurzer Ausschnitt aus einem Fahrplan:

tmpSchedule[0].distance = 30; //First segmenttmpSchedule[0].eventType = 0; //SegmenttmpSchedule[0].data = 0; //Segment 0tmpSchedule[0].trackLeft = 1; //Track lefttmpSchedule[0].speed = 0xF;

tmpSchedule[1].distance = 35; //after 35 cm startstmpSchedule[1].eventType = 0; //a segmenttmpSchedule[1].data = 3; //with id 3tmpSchedule[1].trackLeft = 1; //which schould be traked on the right sidetmpSchedule[1].speed = 0xF;

Grant/Release fur Segmente wurden implementiert, um dem RBC die

2 LOK 10

Moglchkeit zu geben, das Streckengeschehen zu uberwachen bzw. zu verhin-dern, dass Zuge aufeinander auffahren und die Schranken am Bahnubergangrechtzeitig geschlossen werden. Fur jedes neue Segment, dass eine Lok be-treten mochte, fragt sie beim RBC nach (Request) ob sie die Erlaubnis hat,dieses Segment zu betreten. Wenn freie Fahrt moglich ist, sendet der RBC einGrant zuruck. Die Lok fahrt dann in das Segment ein und gibt das vorletzteSegement (das jetzt definitiv von ihr verlassen wurde) wieder frei.

Im Code:

//warte auf erlaubnisif (hasGrantForSegment(g engineConfig.curSchedule[

g engineConfig.curSchedulePosition].data)==FALSE) {setSpeed(0);wait event(segment granted,

g engineConfig.curSchedule[g engineConfig.curSchedulePosition].data);}g engineConfig.releaseLastSegmentDist = getAbsolutDistance() +

g engineConfig.engineLength;g engineConfig.releaseLastSegment=TRUE;

Abbildung 8: Die vorlaufigen Loksauf der Teststrecke

Abbildung 9: Die fertigen Loks aufder fertigen Strecke

2 LOK 11

Abbildung 10: Der BahnubergangAbbildung 11: Lok 2 mit Beleuch-tung

Abbildung 12: Lok 2 mit Beleuch-tung, von hinten

Abbildung 13: Abschlussvorfuhrung

3 RADIO BLOCK CONTROLLER 12

3 Radio Block Controller

Die Aufgabe der Gruppe”Radio Block Controller“ (RBC) bestand zum einen

darin, bei der Befahrung der Strecke durch die Loks eine Kollisionsfreiheitzu gewahrleisten, und zum anderen, eine Bahnschranke zu erstellen und an-zusteuern. Des Weiteren sollte die korrekte und sichere Funktionsweise desRBCs mit Hilfe von Uppaal, einer Software zur Verifikation von Realzeit-systemen, verifiziert werden (http://www.uppaal.com/).

Fur diese Aufgaben standen ein RCX, Motoren, diverse Lego-Bausteineund unterschiedliche Sensoren zur Verfugung. Als Betriebssystem fur denRCX wurde BrickOS eingesetzt und die Implementierung der einzelnenFunktionen erfolgte in C.

3.1 Kollisionsfreiheit der Loks

Um die Kollisionsfreiheit der Loks zu gewahrleisten, mussen sich der RBCund alle auf der Fahrstrecke befindlichen Loks synchronisieren:

Die Fahrstrecke ist in sogenannte Segmente unterteilt, welche kritischeAbschnitte darstellen. Beispielsweise sind der Bereich vor einer Verzweigung,die Verzweigung selbst und der Bereich nach der Verzweigung solche Segmen-te. In diesen darf sich nur eine Lok gleichzeitig befinden. Die Synchronisierungbesteht nun darin Segmente zu reservieren (3.1.1) und wieder freizugeben(3.1.2).

Die mogliche Gefahr eines totalen Stillstandes (deadlock) wird dabeiim Vorfeld durch eine geeignete Erstellung der Fahrplane entscharft. Dieswird in Kapitel 5 naher erlautert.

3.1.1 Request

Die Segmentreservierung erfolgt auf folgende Art und Weise:

1. Bevor die Lok in das nachste Segment einfahrt, fragt sie beim RBCnach, ob sie in dieses einfahren darf. Dazu schickt sie eine spezielle An-frage an den RBC, in der die Informationen zur Identifikation der Lokund dem erwunschten Segment enthalten sind, der sogenannte Request.

2. Der RBC uberpruft, ob das angefragte Segment frei ist.

3. Wenn das Segment von keiner weiteren Lok blockiert ist, so sendetder RBC eine Freigabe an die Lok, den sogenannten Grant. Wenn dasSegment besetzt sein sollte, wird zu einem spateren Zeitpunkt nochmalsversucht den Request abzuarbeiten. Dies wiederholt sich so lange bis

http://www.uppaal.com/


sich keine Lok mehr im Segment befindet, und eine Freigabe an die Lokgesendet werden kann.

4. Wenn die Lok die Freigabe erhalten hat, darf sie das entsprechendeSegment befahren. Falls die Lok sich unmittelbar am Segment befindetund noch keine Freigabe erhalten hat, muss sie anhalten und solangewarten, bis sie eine Freigabe erhalt. Ein erneutes Senden eines Requestswird nicht durchgefuhrt.

Auch die Initialisierung der Loks beim RBC erfolgt uber einen Request.Eine Lok muss zu Beginn ihr Startsegment beim RBC anfordern, da ihm die-ses im Vorfeld nicht bekannt ist. Das hat den Vorteil, dass der RBC keinerleiSchnittstellen zu der Erstellung des Fahrplans benotigt.

3.1.2 Release

Zur Synchronisierung gehort nicht nur das Sichern von bestimmten Abschnit-ten, sondern auch das Freigeben. Die Freigabe von Segmenten ist notwendig,damit auch andere Loks ein bereits gesichtertes Segment befahren durfen,welches nicht mehr benotigt wird. Theoretisch kann der RBC diese Freiga-be auch selbststandig durchfuhren, jedoch konnen die Loks unterschiedlicheLangen aufweisen, welche dem RBC nicht bekannt sind. Deshalb wird dieFreigabe von Segmenten von den Loks initiiert. Dazu senden sie eine spezi-elle Nachricht an den RBC, welche die Informationen zur Identifikation derLok und das freizugebende Segment enthalten, den sogenannten Release.

3.1.3 Anfragenabarbeitung

Die innere Organisation des RBCs zur Handhabung dieser Segment-Sicher-ungen und -Freigaben wird durch eine modifizierte FIFO-Warteschlange(First In First Out) realisiert. Alle Anfragen werden chronologisch ih-res Einganges abgearbeitet (FIFO-Prinzip) und nach der Abarbeitung einerAnfrage wird diese aus der Warteschlange geloscht. Wenn jedoch zu einemRequest keine Freigabe erfolgen kann, weil z.B. das angeforderte Segmentnoch belegt ist, so bleibt dieser Request in der Warteschlange und wirdubersprungen. Wenn die Warteschlange einmal durchlaufen wurde und sichdort nur noch ubersprungene Anfragen befinden, wird ein erneuter Durchlaufangestoßen, der ebenfalls nach dem FIFO-Prinzip arbeitet usw.

Dabei kann das Problem auftreten, dass ein Request sehr lange in derWarteschlange verweilt und im schlimmsten Fall nie wieder zur Abarbeitungherangezogen wird. Das kann passieren, wenn fur ihn bei einem Durchlaufder Warteschlange keine Freigabe erfolgen kann und im folgenden laufend


neue Anfragen in die Warteschlange eingefugt werden, so dass der aktuelleDurchlauf nie beendet wird. Ubertragen auf das Projekt ist dieses Problemnur theoretischer Natur, da die geringe Anzahl der Loks nur eine geringeAnzahl von Anfragen innerhalb eines bestimmten Zeitabschnitts erwartenlasst. Wenn die Anzahl der Loks signifikant steigt und/oder alle Segmentesehr klein werden, so dass laufend mit neuen Anfragen zu rechnen ist, solltedie Abarbeitung der Warteschlange erneut auf ihre Funktionalitat uberpruftund ggf. modifiziert werden.

Ein weiteres Problem kann beim gleichzeitigen Einfugen und Loschenvon Anfragen in bzw. aus der Warteschlange entstehen. Daher wird die War-teschlange mit einem Semaphor als Sicherungsmechanismus implementiert,wobei die gesamte Warteschlange als ein Betriebsmittel gesehen wird, auf dasnur ein Prozess zur gleichen Zeit zugreifen darf.

3.1.4 Streckenmodellierung

Die Fahrstrecke ist durch ein Bit-Array modelliert. Die Lange dieses Arraysentspricht der Anzahl der Segmente der Fahrstrecke. Initial sind alle Bitsauf 0 gesetzt, welches bedeutet, dass keine Lok sich in irgendeinem Segmentbefindet. Bei einem Request wird uberpruft, ob das entsprechende Bit furdas angefragte Segment noch 0 ist. Wenn ja, wird eine Freigabe erteilt unddas Bit auf 1 gesetzt. Eine 1 steht hierbei sowohl fur besetzt als auch furreserviert bzw. gesichert. Ein Release hat zur Folge, dass das entsprechendeBit auf 0 gesetzt wird – das Segment ist ab jetzt wieder frei.

3.2 Schrankenkontrolle

Die Schrankenkontrolle beinhaltet das Hoch- bzw. Herunterfahren der Bahn-schranke, die Uberprufung, ob der gewunschte Zustand erreicht wurde, unddie Sicherstellung, dass eine Lok erst bei einer geschlossenen Bahnschran-ke den Schrankenabschnitt passieren darf. Damit die Kontrolle der Schran-ke nicht die Funktionalitat des RBCs bezuglich der Kollisionsfreiheit beein-trachtigt, lauft diese in einem eigenen Thread.

3.2.1 Aufbau der Schranke

In Abbildung 14 ist der Aufbau der Schranke zu sehen. Der massive Korperder Schranke dient der Stabilisierung. Der lange Schrankenarm soll die Bahn-strecke kreuzenden Fahrzeuge (wie z.B. Autos, Radfahrer, etc.) an einer Uber-querung hindern. Am gegenuberliegenden Ende des Schrankenarms (wei-ße Markierung mit schwarzem Rand) ist eine glatte Beruhrungsoberflache


angebracht. Diese dient dazu die seitlich angebrachten Beruhrungssensoren(violette dick gestrichelte Markierungen) zu betatigen, welche so angebrachtsind, dass sie jeweils beim Hochpunkt und beim Tiefpunkt der Schranke ge-druckt werden. Durch Auswertung der Beruhrungssensoren kann uberpruftwerden, ob die jeweilige Schranke sich im gewunschten Zustand befindet unddahingehend entsprechend reagiert werden. Erreicht eine Schranke z.B. denangestrebten Tiefpunkt und wird auch der entsprechende Sensor beruhrt, sowird der Motor dieser Schranke abgeschaltet und die Schranke bleibt stehen.

An einer der beiden Schranken ist zusatzlich eine rot-leuchtende Lam-pe angebracht, die beim Herunterfahren der Schranke angeschaltet und erstbeim Hochfahren wieder ausgeschaltet wird. Diese ist ein zusatzlicher op-tischer Reiz fur kreuzende Fahrzeuge und dient ebenso dazu, das Schran-kenmodell realistischer zu machen. Leider stand aufgrund der begrenztenRessourcen nur eine Lampe zur Verfugung.

Abbildung 14: Design der Schranke

3.2.2 Probleme und Vorsichtsmaßnahmen

Ein Problem ergab sich bei der Weiterverarbeitung der Sensorwerte. Da zweiSchranken mit jeweils zwei Beruhrungssensoren angesteuert werden mussten,der RBC aber nur drei Eingabebereiche fur Sensoren besitzt, musste einEingabebereich doppelt belegt werden. Um Kollisionen zu vermeiden wurdedie Doppelbelegung so gewahlt, dass der Sensor bei der ersten Schranke nur


beim Herunterfahren und bei der anderen Schranke nur beim Hochfahrenaktiviert werden kann. In Tabelle 3 wird das verdeutlicht. Die erste Schranke(A) aktiviert Sensor 2 beim Hochfahren und Sensor 1 beim Herunterfahren.Die zweite Schranke (B) aktiviert Sensor 2 beim Herunterfahren und Sensor3 beim Hochfahren.

Sensor 1 Sensor 2 Sensor 3oben A Bunten A B

Tabelle 3: Belegung der Sensoren beim RBC

Eine Vorsichtsmaßnahme wurde getroffen um beim fehlerhaften Uber-steuern der Schranke (z.B. die Schranke halt beim Runterfahren nicht anund wurde sich in den Boden bohren) keine Bauteile in ihrer Funktionalitatzu beeintrachtigen. Im Inneren der Schranke wurde ein Zahnrad mit Kraftbe-grenzung eingebaut (weißes Bauteil in Abbildung 15), was den beschriebenenVorgang verhindert. Diese Vorsichtsmaßnahme erwies sich insbesondere beiden ersten noch fehlerhaften Ansteuerungstests als gerechtfertigt.

Abbildung 15: Das Innere der Schranke


3.2.3 Funktionsweise

Die Schranke befindet sich an einem festen Platz an einem moglichst geradenAbschnitt der Strecke. Initial ist die Schranke offen, der Schrankenarm be-findet sich also oben. Die Schranke darf dabei in keinem ihrer Zustande dieFortbewegungsmoglichkeit der Loks beeintrachtigen. Der Platz der Schrankewird dabei als ein ganzes Segment angesehen, dessen Nummer dem RBC imVorfeld bekannt sein muss.

Wenn eine Lok das Segment der Schranke anfordert, wird zunachst wiebisher uberpruft, ob das Segment frei ist. Sollte es frei sein, wird zunachstdie Schranke heruntergefahren und erst nachdem diese geschlossen ist, wirdeine Freigabe an die entsprechende Lok gesendet. So kann keine Lok beihochgefahrener Bahnschranke das Segment durchfahren und fahrlassig ande-re Verkehrsteilnehmer (Autos, Passanten, etc.) gefahrden.

3.3 Verifikation

Die korrekte Funktionsweise des RBCs wurde mit Hilfe von Uppaal (Ver-sion 3.6 Beta 3 (rev.1762), April 2006) verifiziert. Die Automaten wurdenso angelegt, dass sie theoretisch mit einer beliebigen Anzahl von Loks undeiner beliebig großen Strecke verifiziert werden konnen. Jedoch wurde da-durch der Rechenaufwand exponentiell ansteigen und gar zu einem Abbruchder Verifikation fuhren wegen des zu großen Speicherbedarfs. Um die Veri-fikation trotzdem zu ermoglichen wurde lediglich eine kleinere Anzahl vonLoks und Segmenten betrachtet, was in diesem Fall zulassig ist, da sich dieProblemstellung auf diese Konstellation abstrahieren lasst.

Dafur mussten einige Teilbereiche der Realitat, namentlich die Loks, derRBC und der Fahrplan, nachgebildet werden, welche nun im folgenden de-taillierter erlautert werden.

3.3.1 Loks

Um die Loks nachzubilden, wurde eine Vorlage (Template) erzeugt (sieheAbbildung 16). In den Deklarationen fur das System (System declarati-ons) konnen mit dieser Vorlage beliebig viele Loks erzeugt werden, wobei jedezusatzliche Lok den Verifikationsprozess verlangsamt. Eine neue Lok benotigtbei der Initialisierung eine Identifikationsnummer und ein Startsegment, wel-che innerhalb des jeweiligen Wertebereichs frei gewahlt werden konnen. DieIdentifikationsnummer muss eindeutig sein, das Startsegment kann doppeltvergeben werden, was aber nicht der Realitat entsprechen wurde.


grant_received

release_segment driving

request_segment

initial

i : int[0,segment_count-1]current_segment == next_segment

next_segment:= i

segment_counter<2segment_counter:=segment_counter+1,current_segment:=grant_segment[id]

current_segment != next_segment

segment_counter > 1entry.segment:=current_segment,entry.type:=RELEASE,add_input(entry),current_segment:=grant_segment[id]

entry.segment := next_segment,entry.type := REQUEST,add_input(entry)

grant_segment[id] == next_segmentgrant?

next_segment := start,add_input(entry)

Abbildung 16: Nachbildung der Loks in Uppaal

3.3.2 RBC

Der RBC wurde wie in Abbildung 17 zu sehen ist modelliert. Dabei wurdebei der Warteschlange des RBCs, die in Kapitel 3.1.3 erlautert wurde, eineVereinfachung vorgenommen, die aber die selbe Funktionalitat bereitstellt.Die Vereinfachung erlaubte eine schnelle und uberschaubare Modellierung.

Die modellierte Warteschlange besteht lediglich aus doppelt so vielen Ele-menten wie Loks eingesetzt werden. Jede Lok hat dabei zu jedem beliebigenZeitpunkt maximal einen Release und/oder einen Request beim RBC zurBearbeitung vorliegen. Tabelle 4 zeigt die Warteschlange beispielhaft. Lok 1hat derzeit sowohl einen Request als auch einen Release in der Warteschlange(hier angedeutet durch ein +). Lok 2 hat zu dem gegebenen Zeitpunkt kei-nerlei Anfragen an den RBC gestellt und Lok 3 hat einen Request gesendet.Eine Lok kann in der Realitat nur ein Segment zur Zeit anfordern (Request),da sie erst auf eine Freigabe des RBCs warten muss bevor sie das nachsteSegment anfordern kann. Beim Release konnen in Realitat theoretisch meh-rere von einer einzigen Lok auf einmal in der Warteschlange vorliegen. Dadiese aber in der Regel vom RBC sofort abgearbeitet werden konnen befindetsich de facto zumeist nur ein Release von einer Lok zur Zeit dort.


do_releasedo_request

idleinitial

entry.valid == false

grant!

segment_state == FREEoccupy_segment(entry.segment),delete_input(entry),init_grant(entry)

release_segment(entry.segment),delete_input(entry)

segment_state == OCCUPIED

entry.valid == true &&entry.type == RELEASE

entry.valid == true &&entry.type == REQUEST

segment_state := get_segment_state(entry.segment)

entry := get_next_queue_element()

Abbildung 17: Nachbildung des RBCs in Uppaal

Lok 1 Lok 2 Lok 3 ...Request + + ...Release + ...

Tabelle 4: Modellierte Warteschlange des RBCs


3.3.3 Fahrplan

Um den Fahrplan nachzubilden wurden die Segmente, in die eine Lok alsnachstes einfahren mochte, mit Hilfe eines Randomisierers ermittelt. Dies istmoglich, weil der RBC keinerlei Informationen uber den konkreten Aufbauder Strecke besitzt (z.B. dass Segment 2 auf Segment 1 folgt) und diese auchnicht benotigt. Es wurde sichergestellt, dass eine Lok, die sich in einem be-stimmten Segment x befindet, dasselbe Segment nicht sofort erneut befahrenkann. Ein erneutes Befahren des Segmentes x ist, nachdem ein anderes Seg-ment zuvor befahren wurde, jedoch problemlos moglich. Dieses Verhaltenentspricht der Realitat.

current_segment == next_segmentnext_segment:= random()i:int[0,segment_count-1]

current_segment == next_segment

next_segment:= i

Abbildung 18: Zwei unterschiedliche Randomisierer

Es wurden zwei unterschiedliche Randomisierer eingebaut (siehe Abbil-dung 18). Der erste Randomisierer (links im Bild) erfolgt uber eine von Up-paal zur Verfugung gestellte Funktionalitat. Dabei wird an der entsprechen-den Kante des Automaten ein select mit einem vorgegebenen Wertebereichfestgelegt und jedesmal wenn die Kante aktiv ist, wird ein zufalliger Wertaus dem Bereich erzeugt und in der Variablen i gespeichert, mit der dannweiter verfahren werden kann (die zweite Zeile). Im Gegensatz zum zweitenRandomisierer wird hierbei die zufallige Zahl nicht deterministisch erzeugt.

Der zweite Randomisierer (rechts im Bild) wurde durch eine Funktionrealisiert und kann uber den Aufruf random() aufgerufen werden. Dort wirdmittels der Folge

randomzahl := (a ∗ randomzahl + b)%m

eine Pseudo-Zufallszahl erzeugt, die je nach Wahl der Konstanten a, b, m

und des Initialwertes randomzahl deterministisch erzeugt wird (siehe Tabelle5 fur die verwendete Belegung).

randomzahl a b m0 3 7 #Segmentanzahl

Tabelle 5: Konstantenbelegung des Randomisierers random()


Der Randomisierer select hat den Vorteil, dass der gesamte Wertebe-reich, also die gesamte Strecke, abgedeckt wird und somit jedes Segment ange-fordert werden kann. Wahrenddessen kann es beim Randomisierer random(),je nach Wahl der Konstanten und des Initialwertes, durchaus Werte geben,die niemals erzeugt werden. Allerdings ist random() schneller bei der Verifi-kation, wie im nachfolgenden Abschnitt gezeigt wird.

3.3.4 Funktionsverifikation

Bei der Verifikation der korrekten Funktionsweise des RBCs sollte uberpruftwerden, ob der RBC die Kollisionsfreiheit der Loks gewahrleistet. Um daszu ermitteln wurde getestet, ob sich zwei Loks zu irgendeinem Zeitpunktgleichzeitig in ein und demselben Segment befinden konnen. Dafur wurde aufeinen lokinternen Parameter namens current segment zuruckgegriffen, derspeichert, in welchem Segment die jeweilige Lok sich gerade aktuell befindet.Mit folgender Anfrage lasst sich das gewunschte Verhalten verifizieren:

E<>lok1.current segment == lok0.current segment

Hierbei wird uberpruft, ob es irgendeine Moglichkeit gibt (E<>), dass sich zweiunterschiedliche Loks (lok1 und lok0) zu irgendeinem Zeitpunkt im selbenSegment (lok1.current segment == lok0.current segment) befinden.

Hierbei ist es ausreichend die Eigenschaft fur zwei Loks zu verifizieren.Verifiziert man mit drei Loks, muss paarweise das jeweilige Verhaltnis von A↔ B und A↔ C und B↔ C betrachtet werden. Die Menge aller Verhaltnisse,die zwischen zwei Loks bestehen kann, ist in der Modellwelt fest. Die Hin-zunahme weiterer Loks fuhrt zu temporaren Einschrankungen, keinesfalls je-doch zu neuen Verhaltnissen. Somit ist die Menge der moglichen Verhaltnissefur alle Paare gleich, wodurch sich das Problem auf die Betrachtung eines ein-zelnen Paares reduzieren lasst. Hierbei ist es unerheblich welches betrachtetwird.

Getestet wurde zunachst mit dem Randomisierer select. Da dieser abernur fur zwei Loks und eine geringe Segmentanzahl in vertretbarer Zeit einErgebnis lieferte, wurde der Randomisierer random() fur weitere Tests hin-zugezogen. Durch alle Tests konnte verifiziert werden, dass sich zu keinemZeitpunkt zwei unterschiedliche Loks in ein und demselben Segment befin-den konnen. In Tabelle 6 sind die Einstellungen und Verifkationszeiten inAbhangigkeit vom Randomisierer zusammengefasst.


Randomisierer Anzahl Segmente Anzahl Loks Verifikationszeit [s]select 6 2 15select 7 2 44select 8 2 >120random() 40 2 1random() 50 2 >120random() 10 3 17random() 11 3 >120

Tabelle 6: Einstellungen der Randomisierer fur die Verifikation

4 STRECKE 23

4 Strecke

Die Aufgaben der Gruppe”Strecke“ waren neben der Konzeption, des Dru-

ckes und der Bereitstellung der Strecke, die Konzeption der Barcodes und dieErstellung eines Barcode-Lese-Programmes. Die Barcodes sollten als Balisenzur Positionsbestimmung dienen und in regelmaßigen Abstanden uber dieStrecke verteilt werden.

4.1 Strecke

Dieser Abschnitt ist wie folgt gegliedert: Unter Vorgaben werden die Anfor-derungen sowohl der offiziellen Aufgabenstellung als auch der Fahrplangrup-pe beschrieben. Anschließend wird unter Konzeption erlautert, wie wir dieVorgaben umgesetzt haben. Schließlich werden unter Bereitstellung relevanteInformationen zu Druck und ahnlichem gegeben.

4.1.1 Vorgaben der Aufgabenstellung

Die Strecke selbst hatte nur die Vorgaben, mehrere mehrgleisige Bahnhofe,Abstell- und Verbindungsgleise, die in verschiedenen Richtungen befahrenwerden konnen, und einen Bahnubergang zu enthalten. Durch die Anforde-rungen der Fahrplangruppe (es soll moglich sein, deadlock-frei Fahrplane furdrei gleichzeitig fahrende Loks zu generieren, siehe 5.1), mussten ausreichendAusweichmoglichkeiten auf der Strecke vorhanden sein.

4.1.2 Konzeption

Die Gesamtmaße der Strecke standen schon fruhzeitig fest und orientiertensich an der Umsetzung des Holonic Manufacturing Systems [prr04], die Ab-schlussaufgabe eines fruheren Praktikums Realzeitsysteme. Maßgebend wa-ren dort 3 Tische, welche auch uns zur Verfugung standen, die zusammengeschoben eine Flache von 240 cm x 170 cm bieten.Die am Anfang der Konzeptionsphase vorgeschlagenen, sich an Kreisen ori-entierenden Strecken wurden schnell verworfen, da die Fahrplangruppe beisolchen keine Deadlock-Freiheit garantieren konnte.

Das Ergebnis ist daher wie unter Abbildung 19 zu sehen ist, eine lang-gezogene, mit 3 Bahnhofen versehene Strecke. An beiden Enden und in derMitte stehen Schlaufen zum Wenden zur Verfugung. Die mittleren Schlaufenkonnen auch als Abstellgleis genutzt werden. Auf der Strecke zwischen demmittleren und unteren Bahnhof ist außerdem eine Uberholspur integriert,zwischen dem oberen und mittleren Bahnhof der geforderte Bahnubergang

4 STRECKE 24

Abbildung 19: Der komplette Streckenplan mit Barcode Nummern

4 STRECKE 25

(in Abbildung 19 nur schematisch dargestellt).Der schwarze Halbkreis in der oberen rechten Ecke dient zur Kalibrierungder Lichtsensoren von den Loks.Als Schwierigkeit bei der Erstellung der Strecke stellte sich der geringe Platz-bedarf heraus. Ausladende Kurven wurden verworfen, um Platz fur parallelliegende Streckenabschnitte zu schaffen. Nebeneinander liegende Gleise mus-sten einen Mindestabstand von 16 cm aufweisen, der einen Zusammenprallvon zwei parallel fahrenden Zugen verhinderte. Desweiteren mussten auchWeichen einen Mindestabstand zueinander haben, um der Lok den Seiten-wechsel des Fuhrungsstreifens zu ermoglichen.Nach der Konzeption der Strecke wurden die Positionen der schon erwahntenBarcodes bestimmt. Um ein einwandfreies Lesen der Barcodes zu ermog-lichen, konnten diese nur an geraden Streckenabschnitten angebracht werden.Es wurde zudem darauf geachtet, dass eine Lok beim Befahren der Streckein jedem Fall mehrere Barcodes uberquert. Jede Verbindung zwischen zweiBahnhofen hat mindestens eine Barcode. Die Lok erhalt somit mehrere Mog-lichkeiten der Positionsbestimmung.

4.1.3 Bereitstellung

Beim Drucken der Strecke stellten sich unterschiedliche Probleme. Da dieStrecke moglichst selten geklebt werden sollte, und aufgrund der Große beieinem Ausdruck auf DINA4- oder DINA3-formatigem Papier sehr viele Kle-bestellen entstehen wurden, wurde der Druck auf einem Plotter des Hoch-schulrechenzentrums durchgefuhrt. Hieraus ergaben sich jedoch weitere Pro-bleme, da die Papierbahnen, auf denen gedruckt wurde, uber 2 Meter langwaren. Diese Bahnen der Lange nach zu schneiden, ist an der Universitatnicht moglich, weshalb wir dies bei der Ostendorf GmbH durchfuhren ließen.Ruckblickend ist festzustellen, dass die zu langen Papierbahnen nur zu er-hohtem Aufwand und Kosten fuhrten. Deshalb empfehlen wir bei weite-ren Druckvorhaben, die Papierlange auf die Schneidemoglichkeiten der Uni-versitat abzustimmen. Schließlich wurden die bedruckten Papierbahnen derStrecke verklebt und die Barcodes auf den vorher festgelegten Positionenangebracht.

4.2 Barcodes

Die Idee des Barcode-Lesers und der zugrundeliegende Algorithmus orien-tierte sich an dem Realzeitpraktikum 2004 [prr04]. Von hier wurde auch dieAuflistung der Barcodes als der Fibunacci-Systematik folgenden Baumstruk-tur ubernommen (siehe dazu auch die Abbildung [prr04, S. 63]).

4 STRECKE 26

Aufgrund der veranderten Rahmenbedingungen fur den Barcode-Lesermusste der Algorithmus jedoch noch angepasst werden, um die Stabilitat desLesers zu erhohen. Die Anderungen betreffen das Erkennen der verschiede-nen Grautone, wie im Folgenden noch beschrieben wird.

Der Leser befindet sich solange in einem Wartezustand, bis er den An-fang eines Barcodes erkennt, also bis der Lichtsensor einen Wert liefert, dernicht mehr als “weiß” erkannt wird. Anschließend wird der Barcode durch dieMethode scanBarcode eingelesen und mittels eines Konstantenfeldes ausge-wertet. Das Kernstuck des Algorithmus ist hierbei scanBarcode.

int scanBarcode() {

wakeup_t event = 0;

int scannedCode = 0;

lastColor = white ;

scannedCodeSegments = 0;

while(!(event==BARCODE_READ) && !shutdown_requested()) {

event = wait_event(colorChange,0);

if (event == COLOR_CHANGED)

{

scannedCodeSegments++;

scannedCode = 3*scannedCode + lastColor;

lastColor = actualColor;

}

}

return scannedCode;

}

In der Schleife wird bei jedem Farbwechsel der Wert des Barcodes neu be-rechnet, bis wieder “weiß” gelesen wird, was das Ende eines Barcodes re-prasentiert. Die Berechnung selbst wurde wiederum aus dem letzten Prakti-kum ubernommen. Die Farberkennung hingegen wurde verandert, indem ein“Hystereseprinzip” implementiert wurde. Dies bedeutet, dass jedem Farb-wert zwei Grenzwerte zugewiesen wurden, ein unterer Grenzwert Gl fur die“Annaherung von oben” und ein oberer Gh fur die “Annaherung von un-ten”. Eine “Annaherung von unten” bedeutet hierbei, dass die Helligkeit sichsteigert und vorher ein “dunklerer” Wert erkannt wurde. Bei einem solchenWechsel wird erst dann der helle Farbton erkannt, wenn der obere GrenzwertGh uberschritten wurde. Damit wird verhindert, dass die gemessene Farbe ander Grenzflache zweier Farbtone zwischen diesen beiden schwankt, sondernsolange die erste Farbe ergibt, bis sichergestellt ist, dass ein Ubergang erfolgt

4 STRECKE 27

ist.

Fur die Implementierung war zu beachten, dass ein oberer Grenzwerteinen niedrigeren Wert besitzt als der entsprechende untere Grenzwert, da dieSensorwerte unbearbeitet (raw) ausgewertet werden, weshalb die Messwertebei einem Wechsel von einem dunklen Farbton zu einem hellen fallen. Wei-terhin mussten aufgrund von Abweichungen der Messwerte der verschiedenenSensoren die Grenzwerte fur jede Lok neu bestimmt werden.

Die Hauptschwierigkeit lag jedoch darin, dass die Sensorengrenzwerte sichveranderten, je nachdem, ob die Motoren der Lok gerade in Betrieb warenoder nicht. Dies wurde erst spat erkannt und so blieb lange ein Ratsel, warumbei Stillstand sorgfaltig ermittelte Werte beim Praxistest im Betrieb dannzu fehlerhaften Barcodes fuhrten. Nach der Erkennung und Losung diesesProblems (durch Ermittlung der Grenzwerte bei laufenden Motoren) gab esbei Grenzwertbestimmung keinerlei Schwierigkeiten mehr.

5 FAHRPLAN 28

5 Fahrplan

Die Fahrplan-Applikation wird zum einen verwendet, um Fahrplane fur dieLoks zu erstellen und zu berechnen, und zum anderen, um zur Laufzeit Kom-mandos zu den Loks zu ubertragen und den Verlauf der Fahrt zu uberwachen.

5.1 Anforderungen

Die Anforderungen an die Fahrplan-Gruppe sind wie folgt definiert: Es solleine Anwendung erstellt werden, die uber eine grafische Benutzeroberflachedie Erstellung von Fahrplanen fur die Zuge erlaubt. Die erstellten Fahrplanesollen Folgendes garantieren:

• Deadlockfreiheit

• optimale Auslastung

• kurzeste Wege

Die Fahrplane sollen dann zu den Zugen via IR-Interface transferiert werden.

5.2 Aufbau des Programmes

Die Fahrplan-Applikation gliedert sich in drei Komponenten: Die grafischeBenutzeroberflache, die Berechnung des Fahrplanes, und einen Controller, derzur Laufzeit Kommandolisten zu den Loks schickt. Zur Kommunikation mitden Loks wird auf die Schnittstelle der Kommunikationsgruppe 6 zugegriffen.Im Folgenden wird nun jede dieser Komponenten beschrieben.

5.3 Grafische Benutzeroberflache

Die intuitiv bedienbare, grafische Benutzeroberflache der Fahrplan-Applikationermoglicht es dem Benutzer, durch ein Point’n’Click Interface einen Fahrplanzu erstellen, sowie den Verlauf der Fahrten zu kontrollieren. Die GUI wurdevollstandig in Java 5.0 unter Eclipse 3.2 implementiert. Es handelt sich dabeium eine reine SWT-Applikation.

Abbildung 20 zeigt die laufende Fahrplan-Applikation. Um einen Fahr-plan zu erstellen, geht man wie folgt vor: Zunachst wird im Train Selectorein Zug ausgewahlt, fur den ein Fahrplan erstellt werden soll. Anschließendwerden nun im Route Planner die Stationen in der Reihenfolge angeklickt,in der sie angefahren werden sollen. Die Stationen tauchen dann im TrainSchedule auf der rechten Seite tabellarisch sortiert auf. Falls ein Aufenthalt

5 FAHRPLAN 29

Abbildung 20: Grafische Benutzeroberflache des Fahrplanes

in einer Station gewunscht wird, so ist dies moglich, in dem man die entspre-chende Tabellenzeile doppelklickt. In dem nun erscheinenden Fenster kanndie Wartezeit in Sekunden definiert werden, welche sich nach Bestatigungebenfalls im Train Schedule wiederfindet. Sobald ein Fahrplan fur einen Zugkomplett definiert ist, kann uber die Schedule Controls das Kommando zumAbfahren (

”Start Train“) erteilt werden, welches uber die Kommunikations-

schnittstelle (siehe 6) transferiert wird. Analog verfahrt man mit den anderenZugen. Falls ein anderer Fahrplan gewunscht wird, besteht die Moglichkeit,uber die entsprechenden Knopfe in den Schedule Controls Schedule ControlsFahrplane fur einzelne oder alle Zuge zu loschen.

Zur Uberwachung des Fahrtverlaufs wurden verschiedene Monitore in dieGUI implementiert. Zum einen kann der Kommunikationskanal im TrainCommunication Bereich uberwacht werden, wo samtliche REQUESTS, GRANTSund RELEASES, die zwischen Lok und RBC ausgetauscht werden, angezeigtwerden (siehe auch 6. Zum anderen wurde im Bereich Debug Log ein Textfeldimplementiert, in welchem Debug Nachrichten aller beteiligten Komponentenausgegeben werden konnen.

Desweiteren wurde ein Thread implementiert, der in regelmaßigen Inter-vallen (500ms) von der Prolog-Komponente die aktuelle Position der Zuge

5 FAHRPLAN 30

Abbildung 21: Anzeige der Lokpositionen im Fahrplan

erfragt, und diese grafisch im Routeplanner darstellt (siehe Abb. 21).Da die Berechnungskomponente des Fahrplanes ausgelagert ist (siehe Ab-

schnitt 5.4, muss die GUI in der Lage sein, Prolog-Pradikate aufzurufen undden Output der Berechnungs-Komponente zu parsen. Dazu verwenden wirdie Java-Library JPL (Java-Prolog Library), welche mit SWI-Prolog geliefertwird.

Der Aufruf der Prolog-Komponente geschieht durch SWT-Listener, dieinnerhalb der GUI definiert sind. Klickt der Benutzer beispielsweise auf einFeld innerhalb des Routeplanners, so wird der Berechnungs-Komponente dieneu hinzugekommene Station direkt mitgeteilt und zur Laufzeit die Route desZuges angepasst. Ebenso verhalt es sich mit der Definition von Aufenthalten,dem Loschen des Fahrplanes, etc.

5 FAHRPLAN 31

5.4 Fahrplanverwaltung

Alle Berechnungs- und Verwaltungsfunktionen der Fahrplananwendung sindals seperates Modul in SWI-Prolog implementiert. Die Wahl fiel auf Prologals Implementierungssprache, da sich Prolog besonders fur die Umsetzungvom Problemlosungsaufgaben eignet und sich die fur die Wegberechnung ver-wendeten Algorithmen besonders einfach in Prolog umsetzen lassen. Da dieProlog-Komponenten in unserer Anwendung interpretiert ausgefuhrt wird,ergab sich mit der leichten Anderbarkeit des Systems ein weiterer Vorteil.Die Algorithmen ließen sich in der Entwicklungsphase schnell an veranderteBedurfnisse anpassen. Auch eine Adaption auf veranderte Streckennetze soll-te verhaltnismaßig einfach umzusetzen sein.

Die Fahrplanverwaltung ubernimmt zwei Hauptaufgaben. Zum einen mussenInformationen zum zugrundeliegenden Streckennetz und dem aktuellen Zu-stand des Systems verwaltet werden. Dies erfolgt vorrangig durch die Moduleroute network, train status und schedule. Zum anderen erfolgt die Be-rechnung der Fahranweisungen durch die Fahrplanverwaltung. Die Wegbere-chung erfolgt durch das Modul routing. Die Module main und interface

erfullen vor allem Kontrolerfunktionalitaten und stellen die Kommunikati-on mit den in Java implementierten Komponenten sicher. Die wichtigstenFunktionen sollen im Folgenden kurz seperat vorgestellt werden.

5.4.1 Verwaltung des Streckennetzes (route network)

Alle weiteren Komponenten der Fahrplanberechnung benotigen Informatio-nen uber das verwendete Streckennetz.

Diese Informationen sind in der Datei route network.pl abgelegt undmussen nur bei einer Anderung an der Strecke angepasst werden. Die dy-namischen Informationen zum Zustand der Zuge werden durch das Modultrain status verwaltet.

Das Streckennetz ist in Form von Prolog-Fakten reprasentiert. Die Dar-stellung verwendet dabei gedachte Wegpunkte auf der Strecke und definiertErreichbarkeiten zweischen diesen Punkten. Die Wegpunkte liegen dabei inder Regel an Blockgrenzen, so dass jede Verbindung zwischen zwei Wegpunk-ten genau einem Blockabschnitt zugeordnet werden kann. Die schließlich andie Lokomotive ubermittelte Kommandoliste enthalt nur noch die Blockab-schnitte. Die Wegpunkte und Kanten werden nur intern durch die Fahrplan-verwaltung verwendet.

Die Datei route network.pl enthalt vorrangig eine Auflistung der moglichenVerbindungen zwischen den gedachten Wegpunkten. Jede Kante die eine sol-che Verbindung reprasentiert wird durch einen Prolog-Fakt angegeben. Die

5 FAHRPLAN 32

Fakten vom Typ edge besitzt dabei folgende Parameter:

ID Eine eindeutige ID fur jede Kante des Streckennetzes. Die ID kann einbeliebiges Prolog-Atom sein.

Segment Zuordung zu dem Blockabschnitt in dem diese Kante liegt. JedeKante kann nur in einem Block liegen. Dieser Block muss angefordertwerden, wenn ein Zug die Kante verwenden will. Die Blocknummerwird in die Komandoliste des Zuges ubernommen.

Startpunkt Der Startpunkt wird durch einen Wegpunkt und die Fahrtrich-tung (position(Wegpunkt, Richtung)) definiert.

Endpunkt Der Endpunkt wird analog zum Startpunkt definiert.

Seite Gibt die Seite an, auf der der Zug tracken muss, wahrend er die angege-ben Strecke zurucklegt. Durch die Trackingseite wird bestimmt welcherAst von Weichen genutzt wird.

Lange Gibt die Lange der durch die Kante reprasentierten Strecke an. DieLange muss dabei nicht zwingend einer Kante mit den gleichen Weg-punkten in die entgegengesetzte Richtung entsprechen. Die Lange wirdin Zentimentern angegeben.

Geschwindigkeit Gibt die fur dir reprasentierte Strecke zu fahrende Ge-schwindigkeit an. Die Geschwindigkeit wird direkt durch die von derLokgruppe definierten Fahrstufen angegeben.

Neben der Definition des eigentlichen Streckennetzes uber Fakten vomTyp edge konnen bestimmten Wegpunkte Stationen zugeordnet werden. NurWegpunkte, die einer Station zugeordnet sind, konnen Start- oder Endpunkteeiner Komandoliste bilden und nur an diesen konnen Zuge willentlich halten.Die Zuordnung erfolgt uber Fakten vom Typ part of station mit folgendenParametern:

Station Eine eindeutige ID der Station

Wegpunkt und Richtung Durch einen Fakt vom Typ position wird derWegpunkt und die Fahrtrichtung bestimmt.

5 FAHRPLAN 33

5.4.2 Verwaltung des Verkehrzustandes (train status)

Neben dem Streckennetz muss das System auch den aktuellen Zustand derZuge und ihre Position auf der Strecke kennen. Die einzige Ruckmeldung bil-det dabei das Erreichen von bestimmten Blockabschnitten durch die Zuge.Die Fahrplanverwaltung muss also die aktuelle Komandoliste kennen, umaus diesen Ruckmeldungen auf die Positionen der Zuge schließen zu konnen.Daruber hinaus muss verwaltet werden, ob die Zuge bereits eine Komman-doliste abarbeiten, oder ob neue Kommandos berechnet werden mussen.

5.4.3 Verwaltung der Fahrplane (schedule)

Als weitere dynamische Information muss das System die Fahrplane der Zugeverwalten. Ein Fahrplan umfasst eine Liste mit den noch abzufahrendenBahnhofen und den Wartezeiten an diesen Stationen. Genaue Abfahrt- undAnkunftzeiten sind in den Fahrplanen nicht festgelegt, da die Fahrplane derZuge jederzeit verandert werden konnen sollen und sich feste Zeiten somitohnehin haufig andern mussten. Der Fahrplan gibt also nur vor, in welcheReihenfolge die Bahnhofe angefahren werden. Es konnen jederzeit weitereStationen hinzugefugt werden oder ein bereits gestarteter Fahrplan kann ver-worfen werden. Erreichte Stationen werden automatisch aus dem Fahrplanentfernt.

Die Kommunikation mit der graphischen Benutzeroberflache erfolgt uberdie Pradikate add station und cancel schedule. Durch add station kannein weiters Ziel am Ende des Fahrplans hinzugefugt werden. Das Pradikaterwartet drei Parameter. Der erste Prameter gibt die ID des Zuges an, furden die Station hinzugefugt werden soll. Durch den zweiten Parameter wirdeine Station bestimmt. Der letzer Parameter gibt die Mindestwartezeit in Se-kunden an, die der Zug an der Station verbleiben soll. Das Pradikat cancel -

schedule verwirft den Fahrplan fur einen ubergebenen Zug. Wird eine Stati-on bereits angesetuert, so fahrt der Zug bis zu dieser weiter und wartet dortauf weitere Anweisungen.

5.4.4 Wegberechnung (routing)

Die Wegberechnung bestimmt einen Weg, uber den ein gegebener Zug einebestimmte Station erreichen kann, sofern ein solcher Weg exisitiert. In be-stimmten Fallen wird auch ein moglicher Weg nicht zuruckgegeben, da eineVerwendung weniger sinnvoll erscheint. Die ist z. B. der Fall, wenn der gefun-dene Weg erheblich langer ist als der kurzeste ohne Verkehr mogliche Weg. Indiesem Fall ist es meist gunstiger auf das Freiwerden eines direkteren Wegeszu warten.

5 FAHRPLAN 34

Von den anderen Modulen der Fahrplanverwaltung wird ausschließlichdas Pradikat get path/3 verwendet. Dem Pradikat mussen eine Zug-ID undein Zielbahnhof ubergeben werden. Es wird der kurzeste Weg, den der Zugnehmen kann, berechnet und uber BestPath zuruckgegeben. Liegt auf demWeg zum Zielbahnhof ein weitere Bahnhof, so wird nur der Weg zu die-sem zuruckgegegben und der Weg muss von dort erneut bbestimmt werden.Durch die erneute Berechnung ist es moglich Veranderungen in der Situationzu berucksichtigen. Existiert kein Weg, oder ist eine Verwendung eines beste-henden Weges als weniger sinnvoll erkannt worden, so schlagt das Pradikatfehl. Der berechnete Weg ist jeweils das Optimum in der aktuellen Situation.

Bei der Bestimmung des Weges werden eine Reihe von Heuristiken ange-wendet. Die Berechnung erfolgt dabei fur jedes Bahnsteiggleis des Zielbahn-hofs separat. Fur jedes Gleis wird, wie weiter unten vorgestellt, der kurzesteWeg bestimmt. Zusatzlich wird, sofern vorhanden, der gunstigste Weg vondiesem Gleis zum nachsten Zielbahnhof bestimmt, ohne die Positionen deranderen Zuge zu berucksichtigen. Aus allen Wegen wird derjenige ausgewahlt,bei dem die Summe der Kosten dieser beiden Teilstrecken minimal ist. Durchdie Berucksichtigung des Weges zum nachsten Bahnhof wird vermieden einGleis auszuwahlen, von dem der nachste Bahnhof nicht direkt zu erreichenist. Als Referenz wird zunachst der optimale Weg zum Zielbahnhof berechnet,der moglich ware, wenn keine Gleise durch andere Zuge blockiert sind.

Die Bestimmung des als nachstes vom Zug zuruckzulegenden Weges kannauf die folgenden Arten geschehen:

• Zunachst wird versucht einen Weg bis zum Zielbahnhof unter Beruck-sichtigung der Verkehrssituation zu bestimmen. Ist dies moglich und dieKosten uberschreiten nicht das eineinhalbfache der theoretisch kurzestenStrecke, so wird der Weg bis zur ersten Station auf dieser Streckezuruckgegeben.

• Konnte kein Weg bis zum Ziel gefunden werden, so wird die erste Stati-on auf dem theoretisch optimalen Weg gesucht und versucht einen Wegzu dieser zu finden, der bei der aktuellen Verkehrssystuation moglichist. Uberschreiten die Kosten diese Weges zusammen mit den optimalenWegkosten von dieser Station zum Zielbahnhof nicht das eineinhalbfa-che der theoretisch kurzesten Strecke, so wird dieser Weg zuruckgegeben.

In beiden Fallen muss beim Erreichen der Zwischenstation, falls eine solchevorhanden ist, erneut ein Weg bis zum Zielbahnhof errechnet werden.

Das Pradikat zur Wegberechnung ist bewusst sehr flexibel ausgelegt,um es fur alle oben beschrieben Aufgaben einsetzen zu konnen. Durch das

5 FAHRPLAN 35

Pradikat kann der kurzeste Weg zwischen einem Startpunkt und einem Ziel-punkt bestimmt werden. Statt einem Zielpunkt kann auch eine Liste moglicherZielpunkte ubergeben werden, aus der dann der auf dem kurzesten Weg zuerreichende Punkt ausgewahlt wird. Die Wegberechnung bedient sich derStreckendefinition aus route network.pl. Um durch andere Zuge blokierteAbschnitte in die Berechnung einbeziehen zu konnen, kann eine Liste mitblockierten Abschnitten ubergeben werden. Die Eintrage umfassen dabei je-weils ein Blockabschnitt und die Fahrtrichtung fur den dieser blockiert ist.

Zur Berechnung der Route wird der Dijkstra-Algorithmus verwendet (sie-he auch [Wik06]). Dieser Algorithmus hat den Vorteil immer die Berechnungdes optimalen Weges im Sinne der Kostenfunktion zu finden. Der Laufzeit-aufwand ist bei einer optimalen Implementierung mit O(n · log n+m), wobeifur m die Zahl der Konten und n die Zahl der Kanten sei, verhaltnismaßig ge-ring. Gerade das gunstige Laufzeitverhalten ist hier wichtig, da auch bereitsein einfaches Streckennetz eine große Kanten und Knotenzahl besitzt. Zumanderen muss die Wegberechnung haufig mit unterschiedlichen Parameterndurchgefuhrt werden, so dass der Einfluss auf die Gesamtlaufzeit hoch ist.

5.5 Controller

In der Klasse ScheduleManager wird die Ubertragung der Fahrplane geregelt.Dies funktioniert derart, dass alle 500ms fur jede Lok eine Anfrage an diePrologEngine gestellt wird, ob ein neuer Fahrplan vorhanden ist und wenndies der Fall ist, wird der Fahrplan uber die Kommunikationsschnittstelle andie entsprechende Lok versand. Außerdem werden im gleichen Zeitintervalldie Positionen der einzelnen Loks abgefragt und in der GUI aktualisiert.

Die Klasse Communication wird von der Fahrplansoftware als Schnittstel-le zur Kommunikation mit den Loks/RBC genutzt und stellt alle benotigtenKommunikationsmethoden bereit. Die Klasse selbst nutzt fur die Kommuni-kation wiederum das PCComInterface.

Die Klasse PrologEngine kapselt die Prologanbindung. Sie ubernimmtalle Initialisierungsaufgaben und stellt fur alle benotigten Anfragen einfacheJava Methoden zur Verfugung, die vom Rest des Programms anstelle derPrologaufrufe genutzt werden.

5.6 Einrichten des Programms in Eclipse

Das Fahrplanprogramm hat mehrere Abhangigkeiten, die zur korrekten Funk-tion benotigt werden. Dies sind im Einzelnen:

• JFace in der Version ≥ 3.2.0

5 FAHRPLAN 36

• SWT in der Version ≥ 3.2.0

• SWI Prolog mit JPL ≥ 5.6.8

Die ersten beiden Bibliotheken sind Bestandteil von Eclipse 3.2.1 SWI Prologmuss gesondert installiert werden - bei einer Standardinstallation sind dieJava-Bindings (JPL) mit enthalten.2

Um die genannten Abhangigkeiten korrekt dem Eclipse-Projekt hinzu-zufugen, mussen einige kleinere Hurden uberwunden werden, die im Folgen-den beschrieben sind.

JFace Fur JFace muss einfach nur das entsprechende JAR-File in den Build-Path des Projektes aufgenommen werden. Dies geschieht uber Project→Properties→BuildPath→Libraries→Add External JAR.

SWT Das Hinzufugen von SWT gestaltet sich etwas schwieriger, da hierauch noch die native-Bibliotheken fur die jeweilige Plattform spezifi-ziert werden mussen. Als erstes muss jedoch auch hier wie bei JFacedas JAR-File zum BuildPath hinzugefugt werden. Wenn das geschehenist, mussen die natives der Plattform spezifiziert werden. Das SWT-Jarfile enthalt diese zwar, doch es ist nicht moglich sie dort auch inner-halb von Eclipse als natives anzugeben. Dazu muss das SWT-Jarfileentpackt werden. Wenn das geschehen ist, muss der Ordner, der dieentpackten Dateien enthalt als Native library location angeben werden(Project→Properties→BuildPath→Libraries→swt→Native li-brary location→Edit).

JPL Nach der Installation von SWI-Prolog liegt eine Datei names JPL.jar imentsprechenden Installationsverzeichnis unter lib/JPL.jar. Diese Dateimuss ebenfalls zum BuildPath hinzugefugt werden. Nachdem das ge-schehen ist, mussen auch hierfur natives spezifiziert werden. Diese lie-gen im Normalfall unter <Prologverzeichnis>/lib/<Plattformname>.

1http://www.eclipse.org2http://www.swi-prolog.org

http://www.eclipse.org

http://www.swi-prolog.org

6 KOMMUNIKATION 37

6 Kommunikation

Die Aufgabe der Gruppe Kommunikation bestand darin, eine Kommunika-tionsschnittstelle fur die Fahrzeuge, den RBC und den Fahrplanrechner zurVerfugung zu stellen. Da die gesamte Implementierung der RCXen unterbrickOS laufen sollte, wurde die Kommunikationsschnittstelle unter Zuhilfe-nahme der von brickOS bereitgestellten Mittel durchgefuhrt.

6.1 Anforderungen und Bestehendes

Die verschiedenen Kommunikationspartner sollen verschiedene Nachrichtenverschicken konnen. Im Einzelnen sind dies:

Lok Request, Release

RBC Grant

PC Versenden einer Kommandoliste

Die Kommunikationsteilnehmer mussen generell andere Nachrichten empfan-gen als sie versenden. Im Einzelnen sind dies:

Lok Kommandoliste, Grant

RBC Request, Release

PC alle

Der PC schneidet zu Debug-Zwecken jegliche Kommunikation mit. Weiterhinwerden die neuen Kommandolisten nach aktuellem Systemzustand generiert,naheres dazu in Abschnitt 5.

6.1.1 LNP

Unter brickOS existieren zwei Netzwerkschichten, die Integritatsschicht unddie logische Schicht [Ash]. Die Integritatsschicht kummert sich um die feh-lerfreie Ubertragung von Paketen und den Zugriff auf das Medium, wahrenddie logische Schicht fur die Adressierung verantwortlich ist. LNP stellt dabeinur sicher, das das Paket unverfalscht ankommt, falls es uberhaupt ankommt(ahnlich wie bei UDP).

6 KOMMUNIKATION 38

LNPLogical Layer Data Link Layer

Application Layer

LNP Integrity Layer

Abbildung 22: Die Schichten der Kommunikation

6.2 Design

Auf die vorhandene LNP-Architektur setzen wir zwei weitere Netzwerkschich-ten: die Sicherungsschicht (Data Link Layer) und die Anwendungsschicht(Application Layer). Dabei nutzen wir nur die LNP-Integritatsschicht (Inte-grity Layer), die logische Schicht (Logical Layer) ist nur der Vollstandigkeithalber aufgefuhrt. Das resultierende Schichtengefuge ist in Abbildung 22 er-sichtlich.

6.2.1 Sicherungsschicht

Die Sicherungsschicht stellt sicher, das die Pakete auch beim Empfangerankommen. Dazu verwenden wir ein Go-Back-N-ARQ[Kow02]. Jedes Paketmuss explizit oder implizit vom Kommunikationspartner bestatigt werden.Bestatigungen fur ein Paket bestatigen alle vorher empfangenen Pakete mit.Wenn ein Paket nicht innerhalb einer bestimmten Zeitspanne bestatigt wird,wird ab diesem Paket neu ubertragen. In Testlaufen zeigte sich, das es rela-tiv haufig dazu kam, das Pakete neu gesendet werden mussten, weil sie nichtinnerhalb des erlaubten Zeitfensters bestatigt wurden. Die Sicherungsschichterfullt ihre Aufgabe in diesem Bereich zur vollen Zufriedenheit.

6 KOMMUNIKATION 39

6.2.2 Anwendungsschicht

Auf der Anwendungsschicht bietet die Kommunikationsschnittstelle Funktio-nalitat zum Ubertragen von Fahrplanen, Grants, Requests und Releases. Einegenaue Erklarung von Request, Grant und Release findet sich im Glossar abSeite 48. Dabei werden die eingehenden Pakete der Anwendungsschicht inPakete der unterliegenden Schicht umgewandelt und dann dieser zur weite-ren Verarbeitung ubergeben. In umgekehrter Richtung werden die ankom-menden Pakete der Sicherungsschicht – sobald sie korrekt und vollstandigangenommen wurden – in Pakete der Anwendungsschicht ubersetzt und andie entsprechend registrierten Handler weitergegeben.

6.2.3 Verwendete Pakete

SicherungsschichtUnsere Sicherungsschicht verwendet folgenden Packetaufbau:

0 2 5 6 7 15 n

+------+----+-----+-----+--------+------+

+ From + To + RST + ACK + SeqNum + Data +

+------+----+-----+-----+--------+------+

In From und To wird kodiert, von wem das Paket kommt und fur wen esbestimmt ist. Ist RST=1 so wird die Verbindung reinitialisiert3. Ist ACK=1,dann bestatigt dieses Paket alle Pakete mit einer Nummer, die kleiner alsdie ubertragene Sequenznummer ist. SeqNum tragt die Sequenznummer desPaketes, die als ein Byte kodiert ist. Fur die kleiner -Relation ist zu beachten,dass es Uberlaufe bei den Sequenzummern gibt. Die Relation kleiner istdefiniert durch

a < b :⇔ (seq(b)− seq(a) > 0)

mit seq(x) entspricht der Sequenznummer des Pakets x.Die Nutzdaten eines Paketes sind entweder leer (wenn das Paket ein

Bestatigungspaket mit ACK=1 ist) oder haben eine der beiden im Folgendenbeschriebenen Strukturen der Anwendungsschicht.

Anwendungsschicht

Ein Packet der Anwendungsschicht beginnt immer mit einem Byte Ty-pangabe. Die moglichen Pakettypen werden durch die Kommunikationsbi-bliothek definiert, wobei com_ptype_debug und com_ptype_location nichtverwendet werden.

3dieses Feature wurde nicht mehr implementiert, da sich die Notwendigkeit nicht ergab

6 KOMMUNIKATION 40

enum com_packet_types {

com_ptype_request, // engine requests segment

com_ptype_release, // engine releases segment

com_ptype_grant, // rbc grants segment

com_ptype_schedule, // pc transmits schedule

com_ptype_debug, // debugging

com_ptype_location, // engine transmits position

}

Ein Kommandolisteneintrag besteht aus der Distanz, an der ein Ereig-nis eintreten soll, einen Ereignistypen (0 fur Segmentbeginn, 1 fur Balise),eine Angabe, ob auf der linken Seite getrackt werden soll (1 fur links, 0 furrechts), die Segment- oder Balisennummer (in ´data) und der Geschwindig-keit, die nach dem Eintreten des Ereignisses gefahren werden soll. 4 weitereBit sind ungenutzt und fur spatere Verwendung reserviert. Momentan werdensie ignoriert.

0 7

+------------------------------+

+ Typ +

+------------------------------+

8 15

+------------------------------+

+ Distance +

+------------------------------+

16 17 18 23

+-----------+-----------+------+

+ eventType + trackLeft + data +

+-----------+-----------+------+

16 20 24

+---------------+--------------+

+ speed + reserved +

+---------------+--------------+

Ist ein Paket kein Kommandolisteneintrag, so ist es ein Request, ein Re-lease oder ein Grant. Handelt es sich um ein Request oder ein Release so wirdlediglich die Segmentnummer ubertragen.

0 2 7

+--------------------+

+ Typ +

+--------------------+

6 KOMMUNIKATION 41

8 15

+--------------------+

+ segmentNumber +

+--------------------+

Ein Grant besteht aus einer Zug-ID und einer Segmentnummer. Die Zug-ID wird hierbei im Paket mit ubertragen, damit die Fahrplananwendung aufdem PC festellen kann, welcher Zug das Segment zugeteilt bekommen hat.

0 2 7

+--------------------+

+ Typ +

+--------------------+

8 15

+---------+----------+

+ trainID + reserved +

+---------+----------+

16 23

+--------------------+

+ segmentNumber +

+--------------------+

6.3 Implementierung

Ursprunglich sollten die Schnittstellen auf PC- und auf RCX-Seite in C imple-mentiert werden. Nachdem es jedoch massive Probleme mit dem Zusammen-spiel der in Java geschriebenen Fahrplananwendung und der C-Implemen-tierung der Kommunikationsschnittstelle gab (speziell bei der Zusammenar-beit von pthreads, Signals und der Java-VM), haben wir uns entschiedendie PC-Seite der Kommunikation in Java zu reimplementieren. Die low-level-Infrarotubertragung haben wir dabei vom Realzeitsystemepraktikum 2004ubernommen und angepasst.

6.3.1 Implementierung auf der RCX-Seite

RCXseitig ist die Kommunikationsschnittstelle auf Callback-Funktionen auf-gebaut. Dabei konnen die Module, die die Kommunikationsschnittstelle be-nutzen, Callback-Funktionen registrieren, die dann beim Auftreten eines ent-sprechendes Ereignisses aufgerufen werden. Zum Senden von Paketen bietenwir auf der Anwendungsschicht pro moglichem Sendewunsch eine Funktionan, die das Versenden komfortabel ermoglicht. Diese Funktionen blockieren

6 KOMMUNIKATION 42

nicht, so dass sie aus beinahe beliebigen Threads aufgerufen werden konnen.Einzige Voraussetzung fur den Thread ist, dass er nicht terminiert, denn an-dernfalls wurde jeglicher Speicher (auch solcher, der inzwischen zu unsererSendewarteschlage gehort), der in diesem Thread allokiert wurde, freigege-ben.

Pro Kommunikationspartner fuhren wir einen struct, der einen Pointerauf den Kopf der Sendeliste (die zu senden Pakete), einen Pointer auf daserste gesendete, unbestatigte Paket, die aktuelle Fenstergroße, die aktuelleSende- und Empfangssequenznummern sowie Semaphoren zur Absicherungdes konkurrierenden Zugriffs auf einige dieser Variablen beinhaltet.

Auf den Loks laufen jeweils vier Threads, zwei Sendethreads (jeweils zumSenden an den RBC und an den PC), ein Empfangsthread und ein Threadzum Fullen der Empfangswarteschlange. Auf dem RBC werden statt zweivier Sendethreads benotigt (zum Senden an jede Lok und an den PC).

Eingehende Daten werden von der LNP Library per Interrupt ubergeben.Unser Interrupt-Handler kopiert die empfangenen Daten in einen Puffer, derdann von einem Thread mit hoher Prioritat geleert wird. Die Daten werdenvon diesem Thread in die Empfangswarteschlange eingefugt. Dieser Threadist notwendig, da innerhalb von Interrupt-Handlern kein malloc ausgefuhrtwerden darf. Sollten Pakete eintreffen, bevor der Puffer wieder sauber ist, sowerden diese einfach verworfen.

Der Empfangsthread arbeitet die Empfangswarteschlange ab. Er verarbei-tet hierbei sowohl Paketbestatigungen als auch empfangene Daten. Im Falleeiner Paketbestatigung wird gepruft, ob diese ein bisher unbestatigtes Paketbestatigt. Ist dies der Fall, gelten alle Pakete, die eine Sequenznummer echtkleiner als die Sequenznummer der Bestatigung haben, als bestatigt und wer-den aus der Sendewarteschlange entfernt. Hierbei wird auch die Fenstergroße(siehe unten) entsprechend aktualisiert. Handelt es sich um ein Datenpaket,so wird gepruft, ob es sich um das nachste erwartete handelt. Ist dies derFall, wird es bestatigt und die Callback-Routine der Anwendungsschicht auf-gerufen. Ist es nicht das erwartete Paket, so wird uberpruft, ob es sich umein irrtumlich wiederholtes Paket handelt. Sofern dies der Fall ist, wird esebenfalls bestatigt (mit der Sequenznummer des nachsten erwarteten Pakets,so dass der Kommunikationspartner weiß, welches Paket er als nachstes zusenden hat. Sollte das Paket jetzt noch nicht behandelt worden sein wird esverworfen.

Die Sendethreads uberwachen jeweils ihre zugeteilte Sendequeue und sen-den Pakete, bis die Fenstergroße erschopft, oder keine ausstehenden Paketemehr vorhanden sind. Das Warten auf die Veranderung der Fenstergroße oderdas Einreihen neuer Pakete ist verbunden mit einem Timeout. Wird diesererreicht, so wird ein Go-Back-N ausgefuhrt. D.h. es werden alle Pakete, die

6 KOMMUNIKATION 43

schon gesendet, jedoch bislang nicht bestatigt wurden, nocheinmal gesendet.

6.3.2 Implementierung auf PC-Seite

Auf PC-Seite ist das Kommunikationsprotokoll, wie schon erwahnt, in Ja-va implementiert. Dabei wurde die Objektorientierung von Java ausgenutzt,um eine intuitive Schnittstelle zu bieten und die Wartbarkeit des Codes zuerhohen. Anstatt der in C ublichen Callback-Funktionen, verwenden wir inJava das Observer Pattern. Die Datenstrukturen haben wir so angepasst, dassdie Klassen fur die Pakete ihren Inhalt aus einem Byte-Array extrahieren,sowie in ein Byte-Array kodieren konnen. Zur Synchronisation der Threadsbenutzen wir u.a. Konstrukte aus dem in Java 1.5 hinzugekommenen Packagejava.util.concurrent.

Einer der elementaren Unterschiede in der Implementierung ist, dass dasGo-Back-N-ARQ nicht uber eine als Variable gespeicherte Fenstergroße im-plementiert ist, sondern uber ein Array, das so viele Pakete wie die maximaleFenstergroße betragt, halten kann. Dieses Array wird als Schieberegister ver-wendet, wobei nur solche Pakete herausgeschoben werden, die schon bestatigtwurden. Es werden immer nur Pakete gesendet, die einen Platz in diesem Re-gister haben. So wird sichergestellt, dass die Fenstergroße eingehalten wird.Auf der PC-Seite werden die Kommandolisten erstellt und versendet. Dievon der Fahrplananwendung generierten Kommandolisten werden als Arrayan die Loks gesendet. Hierbei wird zunachst ein Paket gesendet, das ein miteinem 16-Bit nicht vorzeichenbehafteten Integer die Lange des Arrays angibt.Danach werden in moglichst großen Paketen die Array-Elemente versendet.Das Array wird auf RCX-Seite wieder rekonstruiert und als komplette Kom-mandoliste an den entsprechenden dort registrierten Handler ubergeben.

Ein weiterer Unterschied ist die Behandlung von Bestatigungspaketen(ACKs): Wahrend auf der RCX die Bestatigungen blockierend gesendet wer-den, existiert auf dem PC eine Ack-Warteschlange und ein diese Schlangeverwaltender AckThread fur jeden Kommunikationspartner. Der AckThreadsendet immer das zuletzt in die Warteschlange eingefugte Ack. Damit wirdverhindert, das große Mengen von durch das Netzwerkpotokoll eigentlichnicht benotigten Acks versendet werden. Die Einfuhrung der AckThreadsauf PC-Seite brachte eine signifikante Geschwindigkeitserhohung der Kom-munikation.

6.4 Verifikation

Um sicherzustellen, dass es keine Deadlocks zwischen unseren Threads gibt,haben wir ein abstraktes Modell unserer Implementierung erstellt. Wir haben

6 KOMMUNIKATION 44

den Kontrollfluss der Threads – relevant sind hierbei der Empfangs- und derHauptthread, sowie die Sendethreads, und hierbei ihre Zugriffe auf Semapho-ren – in das Modell aufgenommen. Die Semaphoren wurden mit boolschenVariablen umgesetzt, da wir sie im Code stehts mit 1 initialisieren. Die Ab-bildungen 23, 24 und 25 zeigen die auf Semaphorenzugriffe reduzierten Kon-trollflussgraphen. Mithilfe dieses Modells konnten wir die Deadlockfreiheitunserer Threads verifizieren.

windowSizeSem = false

!windowSizeSem

windowSizeSem = true

sendListSem = false

!sendQueueCountSem

sendQueueCountSem = true

sendQueueCountSem = false

!sendQueueCountSem


!sendListSem

sendListSem = true

sendListSem = false!sendListSem

sendListSem = true

windowSizeSem = false

!windowSizeSemwindowSizeSem = true

Abbildung 23: Semaphorenmodell des Empfangsthreads

sendListSem = false

!sendListSem

sendListSem = true

windowSizeSem = false!windowSizeSem

windowSizeSem = true sendListSem = false

sendListSem = false windowSizeSem = false

!windowSizeSem

windowSizeSem = true

!sendListSem

sendListSem = true

Abbildung 24: Semaphorenmodell des Sendethreads

6 KOMMUNIKATION 45

sendListSem = false

!sendListSem

sendListSem = true

sendQueueCountSem = false

!sendQueueCountSem


Abbildung 25: Semaphorenmodell des Hauptthreads

7 FAZIT 46

7 Fazit

Die im Praktikum zu bewaltigende Aufgabe erwies sich in vielen Punktenals schwieriger zu losen als erwartet. Ein sicherer Bahnbetrieb stellt hoheAnforderungen an das zu seiner Steuerung verwendete System. Neben derKomplexitat des nachzubildenen Systems fuhrte auch die modellhafte Um-setzung zu weiteren Problemen. Der zur Verfugung stehende Platz begrenz-te die moglichen Streckenfuhrungen, so dass hier einige Kompromisse eige-gangen werden mussten, um ein fur die Wegberechnung interessantes aberdennoch auch praktikabel nutzbares Streckennetz zu entwerfen. Auch dieKommunikation zwischen den verwendeten LEGO-Controllern konnte denAnforderungen nur knapp gerecht werden.

Die ursprunglichen Anforderungen an die Fahrplangruppe erwiesen sichsogar als in der Zeit nicht umsetzbar. Eine Deadlock-Freiheit fur beliebigeStreckennetze bei der gleichzeitigen Moglichkeit dynamischer Anderungender Fahrplane zu garantieren, war nicht erreichbar. Die hierbei zu losendenFragestellungen ubertrafen die Anforderungen des Praktikums. Die Reali-sierung wurde erst durch eine Festlegung bestimmter Einschrankungen desStreckennetze moglich. Beispielsweise mussen alle Stationen uber eine aus-reichende Zahl an Gleisen verfugen, um eine Begegnung aller Zuge an derStation zu ermoglichen. Die vereinfachte Aufgabe konnte in der Folge ohnegroßere Probleme umgesetzt werden.

Die Sicherung der Kommunikation hat einige Zeit benotigt; die Idee so-wohl auf RCX als auch auf PC Seite direkt die LNP Library zu benut-zen, stellte sich als sehr aufwendig heraus, weshalb wir fur die Implemen-tierung auf PC Seite auf Java und Ansatze des Vorgangerpraktikums um-geschwenkt sind. Die Implementierung in Java ermoglichte objektorientier-te Modellierung und ließ uns die Probleme mit den verschiedenen Paralle-litatsimplementierungen uber Java-Threads in der Fahrplan-GUI, pthreadsin unserer Implementierung, sowie Signals in der Java-VM und der lnplib

losen. Hilfreich fur das Testen war auch ein Interpreter fur die Pakete, die perInfrarot versendet wurden. Letztlich konnte eine gut funktionierende Versionunserer Kommunikationsprotokolle auf beiden Seiten implementiert werden.

Die Entwicklung des Barcode-Leser-Konzeptes war nicht sonderlich schwie-rig, da auf den Erfahrungen des vorangegangenen Realzeitsystemepraktikumsaufgebaut werden konnte und nur einige Anpassungen notwendig waren. Je-doch gestaltete sich die Umsetzung in die Praxis dadurch schwierig, dassdie Lichtsensoren der RCX sehr empfindlich waren und z.B. bei laufendemMotorenbetrieb andere Grenzwerte hatten als bei Stillstand – so dauerte esverhaltnismaßig lange, bis die RCX im Praxistest zuverlassig die Barcodeserkannt haben.

7 FAZIT 47

Der Bau der Loks ging relativ schnell und problemlos vonstatten. Zwarwurden diverse Designs entwickelt und getestet, die Umbauarbeiten gestal-teten sich aber nicht als all zu schwierig. Wie immer blieben ein paar Pro-visorien in den endgultigen Loks erhalten, so dass noch einige wenige kon-struktionelle Schwachpunkte in den Loks vorhanden sind. Diese konnte manaber durch kleine Umbauarbeiten aber noch beseitigen. Das Grundgerust derProgrammierung zu erstellen, war ebenfalls kein großes Problem, der Line-tracker arbeitete sehr schnell und zuverlassig. Schwierigkeiten gab es eherim Detail, so dass bis zum Schluss noch Anderungen vorgenommen werdenmussten, um das System lauffahig zu machen. Besonders das Fahrplan- undKollisionsmanagement war hier ein Knackpunkt.

Trotz der auftretenden Probleme konnte die Aufgabe letztendlich Dankdem Einsatz aller Beteiligten erfolgreich umgesetzt werden. Sehr zum Erfolgtrug auch die hervorragende Betreuung durch Jochen Hoenicke und AndreasSchafer bei, die auch oft bereit waren, bis in die Nacht mit uns gemeinsamLosungen zu diskutieren und umzusetzen.

7 FAZIT 48

Glossar

FIFO First In First Out

RBC Radio Block Controller

RCX Robotic Command Explorer, die programmierbaren Herzstcke der Lego-Roboter

Request Eine Anfrage einer Lok beim RBC nach der Einfahrfreigabe in einbestimmtes Segment

Grant Die Erlaubnis des RBC fr eine bestimmte Lok in ein bestimmtesSegment einzufahren

Release Mitteilung der Lok, das ein bestimmtes Segment jetzt nicht mehrdurch diese Lok belegt ist

Kommandoliste Eine Liste von Ereignissen (lesen von Balise, einfahren inSegment), die nacheinander durch die Lok abgefahren werden muss.

Balise Ein “Kilometerstein”, der in der Kommandoliste einer Lok auftau-chen kann. An einer Balise resynchronisiert die Lok ihre intern erwar-tete Position mit der aktuellen Position.

LITERATUR 49

Literatur

[Ash] Ash, Mike: LNP Howto. http://legos.sourceforge.net/

HOWTO/x405.html. Letzer Zugriff am 17.08.2006.

[Kow02] Kowalk, Wolfgang: Rechnernetze Onlineskript — Abschnitt“Kontinuierliches ARQ”. http://einstein.informatik.

uni-oldenburg.de/rechnernetze/kontinui.htm, Marz 2002.Letzer Zugriff am 23.08.2006.

[prr04] Abschlussbericht Praktikum Realzeitsysteme. 2004.

[Wik06] Wikipedia: Dijkstras-Algorithmus – Wikipedia, die freie En-zyklopadie. http://de.wikipedia.org/wiki/Dijkstras_

Algorithmus, 2006. Letzter Zugriff am 14. Oktober 2006.

http://legos.sourceforge.net/HOWTO/x405.html

http://legos.sourceforge.net/HOWTO/x405.html

http://einstein.informatik.uni-oldenburg.de/rechnernetze/kontinui.htm

http://einstein.informatik.uni-oldenburg.de/rechnernetze/kontinui.htm

http://de.wikipedia.org/wiki/Dijkstras_Algorithmus

http://de.wikipedia.org/wiki/Dijkstras_Algorithmus

Abschlussbericht Praktikum Realzeitsysteme … · Durch diese intelligentere Steuerung kann...

Documents

Transcript of Abschlussbericht Praktikum Realzeitsysteme … · Durch diese intelligentere Steuerung kann...