Home

TRACS Abschlussbericht - FB3 - Uni Bremen

Contents

1. Abbildung 7 52 Gesamtes Testgleisnetz Die Abschnitte die sich in dem Testgleisnetz in roten K sten befinden sollen von einem Steuerungssystem verwaltet werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 264 RR Sensor TG Sensor Signal Abbildung 7 53 Teststrecke 1 Der komplizierteste Gleisabschnitt der Gesamtstrecke Hohe Anzahl von Elementen zu dem viele verschiedene Typen Hierbei handelt es sich um eine Abbildung der Domsheide HB Doppelweiche Fi RR Sensor TG Sensor Signal Abbildung 7 54 Teststrecke 2 Zweitkomplizierteste Strecke In Richtung S d Nord ist eine Weiche vorhanden die ein Auswahl links rechts geradeaus erm glicht Dies geschieht durch eine Zusammenkopp lung von zwei einfachen direkt hintereinander positionierten Weichen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 265 RR Sensor TG Sensor Signal Abbildung 7 55 Teststrecke 3 Einfache Kreuzung ohne Abbiegem glichkeit RR Sensor Signal TG Sensor Abbildung 7 56 Teststrecke 4 Einfache Kreuzung mit Links Rechts Abbiegesm glichkeiten Auf diesen Teststrecken sind alle typischen Bauformen des Gleisnetzes dargestellt Die Gleisnetzabschnitte 1 und 2 sind als Grundlage f r die Unit Tests benutzt worden Nach der Beschreibung im TND Format und bersetzung durch den Compiler dienten diese als die Anf
2. te D 5 D 5 o e na r amp Od we amp acs RB 2 D O DERO s SOMO r _ or L sf an N Ol Karte k Ol Karte E we ee ar e N Abbildung 7 61 Schema des System Integrationstests 7 7 8 2 Sommersemester 2004 In diesem Semester sollten die Arbeitspakete die im vorangegangenen Semester geplant worden sind erf llt werden Leider war das aus verschiedenen Gr nden nicht m glich Eine Ursache daf r war dass die Entwickler kein Produkt das testbereit w re geliefert haben auch keine Alpha Version und zus tzlich auch nur eine vorl ufige f r die Tests nicht ausreichende Spezifikation vorlag Eine andere Ursache lag bei der falschen Planung und Arbeitsaufteilung 7 7 8 3 Wintersemester 2004 2005 Nachdem sich einige Projektteilnehmer nach der Benotung ihrer Arbeit in dem vorigen Semester verabschiedet haben ist die Testgruppe mit einer Besatzung von einem Mann verblieben Das System war immer noch nicht testbereit Man versuchte dann die Test gruppe immer irgendwo anders einsetzen wo momentan etwas zu tun war Die Gruppe beteiligte sich bei der Bestimmung der Systemgrenzen hat Auskunft ber in der Branche verf gbare Hardware eingeholt und infolgedessen sind auch Beispielgleisnetze entstan den Das alles waren aber Arbeiten die praktisch nichts mit den eigentlichen Tests zu tun hatten Theoretisch war es auch ni
3. 53 6 4 Validierung der TND Hardwarebeschreibung 54 6 5 Verifikation der Projektierungsdaten 2 2222 55 6 6 Test der Steuerungssoftware 2 2 o a ee 56 6 7 Test der Treiberbibliothek 2 Soe Ye a a a 57 6 8 Test des fertigen Steuerungssystems ooa e a a eae 58 7 Beschreibung der Komponenten 59 7 1 Tram Network Description TND aoaaa aaa nn 59 Tel PUT Gl 1 4 ia N ra a el 59 7 1 2 Beschreibungssprache TND 2 2 2 2 222 60 7 1 3 Sprachdefinition der TND 2 22 2 8 3 2 Sb Er Jess ade 62 TA Schnittstellen as 21 a a Se ee ER Es Sun SSS 79 7 1 5 Fortentwicklung der TND va w 2 2 0 0 ne a re 80 RAO Belegen 2 va By 6A oe en een En ey eye 80 7 2 Netzeraph und TND Erzeugung 2 22 nat dena death 82 128 Uperbliek econ Anan athe Wi eee saa ea kee ay a 82 722 GADSysten y eiaa ack Gus eek ie 82 T23 Arbeitspakete T rera air Ja we BO eh Mader 84 7 2 4 Benutzerhandbuch DXF CAD nach TND Konverter 104 12 9 Reflexion 4 00 zus a er re een er A 117 INHALTSVERZEICHNIS 3 7 3 7 4 7 5 7 6 T T 7 8 TND Builder zuende ee oh 123 Bl berblick i wt a Ra ES RE SS este bien 123 7 3 2 Funktionsbeschreibung o a eo ee ee AG Ra Se eS SS 123 Taa installation na nf Pa ed COS tae Gf Sy eS Da a De a 129 7 3 4 Implementierung 2 sn DE ah ba Byes wine 130 19 9 Bellen Aa a al 5 ee ato RU a the dion Ar Ate at 133 Compilere tri 2 Rony epee Woe ar ete Ss
4. Abbildung 5 2 Entwicklungsprozess Diese Komponenten werden f r den Erstellungsprozess ben tigt Der Steuerinterpre ter die Treiber und der TND Compiler werden auf Grundlage einer Spezifikation des Steuerungssystems implemetiert Diese Systemspezifikation besteht aus SI Spezifikation Treiber Spezifikation und Definition des Projektierungsdatenformats Zur Erstellung der Systemspezifikation werden die Systemanforderungen das Weltmodell und die TND Definitionen ben tigt Taffou Happi Deng Zhou Ruben Rothaupt berarbeitet von Andreas Kemnade 5 4 Erstellungsprozess Die Notwendigkeit eines klar definierten Erstellungsprozesses ergibt sich aus dem Ent wicklungprozess denn nur dadurch k nnen auch die Verifikationsma nahmen automa tisch durchgef hrt werden Anhand der Abbildung 5 3 auf der n chsten Seite wird der Ansatz zur Erstellung einer kundengleisnetzspezifischen Steuerungssoftware die auf ei ner Zielmaschine l uft aufgezeigt Der gesamte Erstellungsprozess besteht aus folgenden Schritten e bertragung der jeweilligen Gleiznetzdarstellung in die TND KAPITEL 5 ENTWICKLUNGSPROZESS 48 Tracs f rbare Steuerungssoftware f ein 01 10 2005 bers endbares Produkt normale Elipse nicht wiederwendbare Daten ye TN A TND Netzwerk konvertieren 2 Beschreibung 9 Projektierungs daten Trans gt Versch T in TND speciation of Tan TND HW H
5. retval 0 return retval KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 287 7 7 5 2 5 Zusammenfassung Die so implementierten Teile der RD Testprozedur mussten dann noch zusammengefiigt werden Der grobe Ablauf der Testprozedur ist dabei so dass zun chst die Projek tierungsdaten mit Hilfe der in 7 7 5 1 auf Seite 268 hergestellten Funktionen eingelesen werden um dann daraus wie oben gezeigt die konkreten Testf lle zu ermitteln Danach wird in einer Endlosschleife jeweils eine Testbelegung hergestellt an SUT und Orakel bergeben dann die von diesen gelieferten Outputs vergleichen wobei Gleichheit ein bestandener Ungleichheit ein nicht bestandener Test ist Anschlie end wird die n chste Testbelegung erzeugt usw bis alle Belegungen durchlaufen sind Dar berhinaus wurden noch einige f r den Bediener komfortable jedoch nicht essentielle Dinge eingebaut So kann der Bediener zwei Flags setzen die die Menge der Text Ausgabe w hrend des Testlaufs von quasi nichts bis v llige berflutung einstellbar machen Dar ber hinaus kann auch eine einzelne Testbelegung durch Setzen spezifischer seeds eingestellt und einzeln getestet werden um z B einen bestimmten gescheiterten Test noch einmal mit mehr Ausgaben laufen lassen zu k nnen Eine n here Beschreibung f r den Bediener findet sich im Kapitel 7 7 6 auf Seite 298 Arne Stahlbock 7 7 5 3 Route Controller An dieser Stelle wird die Implementierung der Tes
6. Linux RT Tester L AMs Generator AMs Checker Shared Memory Projektierungsdaten Abbildung 7 58 Schema der Software Integrationstests Folgende Komponenten sind zum Test notwendig e Steuerungssoftware mit Projektierungsdaten e PC Rechner Betriebssystem Testsoftware Ein Konzept f r einen Software Integrationstest ist ausf hrlich in dem Kapitel 7 7 7 auf Seite 303 beschrieben Marcin Dysarz 7 7 5 Test Implementierung Die wesentliche Arbeit bei der Implementierung der Tests bestand aus folgenden Ar beitspaketen e Implementierung des Einlesens der Projektierungsdaten e Implementierung der Testprozeduren f r den Route Dispatcher e Implementierung der Testprozeduren fiir den Route Controller e Implementierung der Testprozeduren fiir den Safety Monitor KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 268 Die Implementierung des Einlesens der Projektierungsdaten war dabei die Vorausset zung f r die automatische Generierung der Testf lle Implementiert wurden f r die zu testenden Komponenten jeweils ein Testgenerator der auf Basis der Projektierungsdaten Kombinationen von Eingabedaten nicht alle theore tisch m glichen das w rde in der Ausf hrung zu lange dauern aber eine sinnvolle Untermenge davon herstellt und diese einerseits an das SUT bergibt andererseits auch an ein Testorakel Das Orakel wurde gem der Spezifikation der zu testenden Komponente
7. if read_int file intbuf 0 printf FS ID d n intbuf pdata gt rc_data i free_sig_pos j id intbuf sidata gt rc_data i gt free_sig_pos j id intbuf else return 1 if read_uint16 file uint16buf 0 printf FS Input d n uint16buf KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 276 pdata gt rc_data i free_sig_pos j input uint16buf sidata gt rc_data i gt free_sig_pos j input uint16buf else return 1 if read_uinti6 file uinti6buf 0 printf FS InputMask d n uint16buf pdata gt rc_data i free_sig_pos j input_mask xuint16buf sidata gt rc_data i gt free_sig_pos j input_mask xuint16buf else return 1 if read_uinti6 file uinti6buf 0 printf FS Output d n uinti16buf pdata gt rc_data i free_sig_pos j output uint16buf sidata gt rc_data i gt free_sig_pos j output uint16buf else return 1 if read_uinti6 file uinti6buf 0 printf FS OutputMask d n uint16buf pdata gt rc_data i free_sig_pos j output_mask uint16buf sidata gt rc_data i gt free_sig_pos j output_mask uint16buf else return 1 terminate list sidata gt rc_data i gt free_sig_pos shm_count id 1 Esse KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 277 An dieser Stelle brechen wir die Darstellung ab da das System klar sein d rfte Die in dieser Funktion verwendeten Hilfsfunktion
8. lt ROUTEID gt lt ROUTEID gt lt ptconfblock gt lt confdef gt Vor dem PtConfBlock steht das Wort point conflicts welches den Block identifi ziert Der gesamte Block von beliebig vielen Konfliktdefinitionen wird mit geschweiften Klammern umrahmt Jede Konfliktdefinition beginnt mit einem Routenbezeichner hin ter dem ein Doppelpunkt steht Anschlie end werden alle Routen angegeben die in einem harten Konflikt stehen Es muss mindestens eine Konfliktroute angegeben und mehrere Routen durch Kommata getrennt werden Der PtConfBlock enth lt einen Teil der Informationen der Route Conflict Table Hier werden die harten Konflikte beschrieben in den Tabellen sind diese mit schwarz aus gef llten Punkten markiert Diese harten Konflikte treten auf wenn sich mindestens zwei verschiedene Routen an einer Weiche trennen Diese Routen werden also aus der gleichen Richtung angefahren und trennen sich dann Da die Weiche nur eine Stellung gleichzeitig einnehmen kann und ein Umstellen w hrend der Durchfahrt eines Zuges h chst dramatische Folgen h tte d rfen zwei in einem harten Konflikt stehende Routen nicht gleichzeitig freigeschaltet werden Die Angabe der Konflikte erfolgt doppelt bei jeder der an einem Konflikt beteiligten Routen ist die zweite Konfliktroute angegeben Dies soll dem Zweck dienen alle zu einer Route auftretenden Konflikte schnell auffinden zu k nnen bei einer lediglich einseiti gen Angabe m sste der kom
9. QCad zielt auf Hobby Anwender gelegentliche Anwender und Leute die keine CAD Ausbildung haben Mus04 Dieses Anwenderprofil ist f r TRACS durchaus zutreffend Zur Bedienung Die meisten Funktionen von QCad k nnen ber das Men erreicht werden F r CAD spezifische Funktionen kann es bequemer sein die Werkzeugleiste links im Hauptfenster zu verwenden Die Werkzeugleiste zeigt jeweils diejenigen Funktionen an welche zur Zeit am meisten Sinn machen Mus04 Das Format der Ausgabedatei von QCad ist DXF Dieses Format ist auch unter Auto CAD CAD Software der Firma Autodesk verf gbar Wegen der durchaus hohen Ver breitung von AutoCAD sollten Kompatibilit tsprobleme mit diesem Format minimiert sein 7 2 2 3 DXF Format Das DXF Format ist eine etikettierte Datendarstellung aller Informationen die in einer CAD Zeichung enthalten sind Praktisch k nnen alle spezifischen Informationen in einer Zeichnungsdatei im DXF Format dargestellt werden bersetzt aus Aut03 Genauer gesagt gibt es immer Zeilenpaare von denen die erste Zeile einen ein bis dreistelligen Zahlencode enth lt welcher im globalen Zusammenhang einen bestimm ten Parameter darstellt In der zweiten Zeile ist der Wert dieses Parameters vermerkt Abh ngig von der Art des Zeichenelements kann der Code einmal den einen und ein KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 84 anderes Mal einen anderen Zweck erfiillen Eine DXF Datei ist in mehrere
10. Vortrag von Herrn L bbers zum RBL rechnergesteuertes Betriebsleitsys tem Die Ziele des RBL Einsatzes sind klar umrissen Durch die Verbesserung der P nktlichkeit soll eine schnellere Bef rderung errreicht werden was f r den Kunden eine Vereinfachung der Nutzung des ffentlichen PersonenNahVerkehrs PNV f r den Mitarbeiter eine Erleichterung am Arbeitsplatz und f r den Betrieb eine Kosten reduzierung durch mehr Effizienz bedeutet Alle Fahrzeuge liefern viermal pro Minute ihre aktuelle Position anhand der berpr ft wird ob der Fahrplan eingehalten wird Die Daten werden ber die digitalen Anzeigetafeln an bislang noch nicht allen Stra enbahn haltestellen an die Kunden weitergeleitet Sie wissen zumindest wieviele Minuten die KAPITEL 2 DIE DOMANE 32 Bahn von ihrer jetzigen Position aus normalerweise braucht Au erdem werden Fahr zeuge angewiesen auf andere zu warten sobald nur noch alle zwanzig Minuten gefahren wird Anschlusssicherung Die Daten werden auch statistisch ausgewertet um l nger fristige Entwicklungen zu beobachten Einen direkten Eingriff soll die Video berwachung an zentralen Haltestellen erm glichen Hohe Auslastung wird durch Einsatzwagen auf gefangen Bereits genannt wurde die Automatisierung im Fahrzeug selber der Fahrer mu nicht mehr die Haltestellenanzeige Entwertersteuerung Au enbeschilderung und Lichtsignalansteuerung bernehmen Auch das Funksystem l uft ber das RBL Es gibt Einzelr
11. set_queue i gen_queues i si_queues Hier bekommen verschiedene set Funktionen jeweils den zugeh rigen gen Wert ber geben Sie nehmen dann die diesem Wert zugeordnete Umsetzung auf die tats chlichen Eingabewerte vor An dieser Stelle d rfte es reichen lediglich ein Beispiel f r eine set Funktion zu geben void set_rst int seed int i for i 0 i lt pdata gt rd_data gt max_routes i rst i seed pow 2 i 2 0 RST_INAKTIV RST_AKTIV si_rst i seed pow 2 i 2 0 RST_INAKTIV RST_AKTIV if debug KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 281 printf Setting state for route d to f d n i si_rstli rst und si_rst sind dabei die an Orakel bzw SUT zu bergebenden Variablen die hier belegt werden F r die hier gezeigte Funktion ist die Umsetzung von seed auf die Belegung noch relativ simpel es gibt da auch noch ganz andere Dinge Es muss nun noch gezeigt werden wie man zu den textttmax Werten gelangt diese sind n mlich teilweise von dem vorliegenden Gleisnetz abh ngig So ist zum Beispiel die Anzahl der Routen im Netz bestimmend daf r wie viele RST Belegungen es geben kann allein dadurch dass die RST f r jede Route ein Feld hat Die Anzahl der Routen in einer Queue bestimmt die Anzahl der Belegungen f r diese Queue usw Das sowie das Anlegen einiger Datenstrukturen z B ben tigen wir auch eine Zuordnung von Queue nach Route n w hrend in
12. 41 J 42 43 44 45 Wenn die Pr fung des Hardware Elements erfolgreich war so folgt die Berechnung des neuen TrackElements der neuen Richtung und der neuen Position Zun chst wird das Hardware Element auf dem sich die Tram nun befindet in Linkable gecastet dass dies ohne Fehlerm glichkeit geht ist durch Zeile 11 garantiert Ein Objekt der Klasse Linkable hat die Methode getNextTE die das n chste TrackElement zur ck gibt und als Parameter das alte TrackElement erwartet Dann wird in Zeile 18 gepr ft ob die Linkable Hardware die die Tram gerade berf hrt bei dem TrackElement als Border 0 oder Border 1 eingetragen ist Die Richtung eines TrackElements ist anhand seiner beiden Border definiert die Bewegung von Border 0 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 381 nach Border 1 ist als positiv definiert die andere als negativ s Skizze 7 80 auf Seite 379 Richtung als gt dargestellt Entsprechend des R ckgabewerts von te getBorders wird die neue Richtung auf true oder false gesetzt Zeilen 19 und 21 Abh ngig von der neuen Richtung wird dann die neue Position auf dem TrackElement entschieden Bewegt sich die Tram auf dem neuen TrackElement positiv so setzt sie bei dem TrackElement an Stelle 1 an andernfalls an Stelle L nge 2 Zeilen 23 27 Die Berechnung der neuen Position befindet sich in einem try catch Block der dann zum Tragen kommt wenn die Bahn am Ende des Gleisnetzes angekommen sein soll
13. 46 pos 0 47 else 48 pos te getLength 1 49 50 checkStop te pos dir steps dist iter 2 51 catch NetworkEndException ne 52 logger info Previewing network end or 53 turnout in undefined position 54 55 Hier erfolgt nun die weitere Vorausschau Befindet sich die Bahn in einer geringeren Ent fernung zum n chsten Linkable Element als sie vorausschauen muss so ist es erforder lich dar ber hinauszuschauen Es wird dann eine neue Position der Bahn berechnet und zwar diejenige die sie einnehmen w rde wenn sie gerade das n chste Linkable Element erreicht h tte also Kopf direkt darauf Der letzte Parameter true in getNextTE bewirkt hierbei dass die Positionsberechnung nur im Voraus erfolgt und nicht wie beim tats chli chen Weiterfahren Wirkungen auf die berfahrenen Hardware Elemente ausge bt wer den Sensorausl sungen Weichen passiv schalten Anschlie end wird die Methode mit dieser neuen Kopfposition einer entsprechend verringerten Vorausschau Weite und der n chsten Iterationstiefe aufgerufen Wenn die Vorausschau bis zum Ende des Netzwerkes reicht muss nat rlich nicht weiter gesehen werden 56 else 57 failure Unknown type of hardware in preview 58 59 60 if getMustStop 2 1 amp amp 61 getHeadDir 62 getHeadPos getHeadElement getLength 2 63 getHeadPos 1 64 logger info Tram getId must stop in front of 65
14. 7 3 2 10 Einschr nkungen bei Routendefinitionen Ein wichtiger Teil des TND Builders sind die Routendefinitionen Bei einer Routendefi nition muss der Benutzer folgende Punkte beachten e In einem Gleisnetz d rfen nicht zwei Routen denselben Namen haben und jeder Routenname muss mit r beginnen e Jede Route muss einen Request Sensor haben KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 128 FI TND C gleisnetz_2tnd elejajele f Interlocking table Route Conflict Table SOUS Oooaaor OOOO OROORO Oooo Oeooddci SOOO iS Abbildung 7 26 Routenkonflikttabelle e Jede Route muss ein Eingangssignal haben und die Go Richtung muss festgelegt werden e Jede Route muss einen Eingangssensor und einen Ausgangssensor haben e F r jede Route m ssen die f r die Route ben tigten Weichenstellungen definiert werden Dabei m ssen die Weichenstellungen in der Reihenfolge definiert werden in der die Weichen befahren werden Zudem werden nur Weichen ber cksichtigt die nicht passiv sind e Passive Weichen und Kreuzungen tauchen nicht in der Routendefinition auf e Wenn der Request Sensor und das Eingangssignal nicht zusammenpassen wird eine Fehlermeldung angezeigt e Wenn Request Sensor Eingangssensor die zu der Route geh renden Weichen und der Ausgangssensor nicht in der richtigen Reihenfolge befahre
15. Im Folgenden wird die Modellierung des Signalverhaltens beschrieben 7 6 4 3 1 Allgemeines Signalverhalten In dem Modul signal wird das Verhalten beschrieben das f r alle Signale gleich ist Als Parameter werden vier Bedingungen bergeben die angeben ob eine Anforderung existiert das entsprechende Signal auf STOP geradeaus nach links oder nach rechts zu schalten KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 218 Die Variable state repr sentiert den aktuellen Zustand des Signals und kann die Werte STOP STRAIGHT RIGHT und LEFT annehmen Der Initialzustand eines Signals ist STOP Ist nun eine Bedingungen zum Umschalten des Signals erfiillt nimmt dieses den ent sprechenden Zustand an Ansonsten beh lt das Signal seinen vorherigen Zustand bei MODULE signal stop_req straight_req left_req right_req VAR state STOP STRAIGHT RIGHT LEFT ASSIGN init state STOP next state case stop_req STOP straight_req STRAIGHT left_req LEFT right_req RIGHT 1 state esac 7 6 4 3 2 Initialisierung der Variablen F r alle in einem Gleisnetz enthaltenen Signale werden Variablen erstellt Dazu wird jeweils das Modul signal aufgerufen und als Parameter werden die Bedingungen bergeben die angeben wann das Signal den jeweiligen Zustand annehmen soll Auch hier ist nur das Anfordern von Signalstellungen m glich die der jeweilige Signaltyp auch erlaubt s3014 signal s3014_stop s3014_straight s3014_left none
16. Sensor und erweitert diesen um die Eigen schaft dass es m glich ist festzustellen ob sich eine Tram auf dem Sensor befindet StateDirectionSensor StateDirectionSensor erbt und erweitert somit den StateSensor Dieser Sensor kann zus tzlich die Richtung feststellen in die sich die Tram bewegt oder in die sich die letzte Tram bewegt hat ToggleSensor ToggleSensor erbt direkt von Sensor Bei berfahrt dieses Sensors schal tet ein ToggleBit um ToggleDirectionSensor LoggleDirectionSensor erweitert ToggleSensor um die M glichkeit der Richtungserkennung vgl StateDirectionSensor Linkable Linkable stellt eine gemeinsame Schnittstelle f r die Klassen dar die im Gleisnetz die Gleisst cke TrackElements miteinander verbinden linken Sourceable Sourceable ist ein Interface das von den Hardwareklassen implementiert wird die potentielle Einfahrten in das Gleisnetz darstellen Dies sind Mark und Sensor Simulator Simulator bildet die Einheit die die anderen Klassen steuert berwacht und abfragt Er kennt alle anderen Klassen startet den Steuerinterpreter und bietet zentrale Methoden an die aufgerufen werden wenn in der Simulation ein Fehler auftritt TrackElement TrackElement simuliert ein Gleisstiick was sich zwischen zwei Hardware Elementen befindet So ein Gleisst ck hat eine bestimmte L nge und kennt die beiden E
17. s2 7000 3000 0 s3 2800 2000 0 s4 500 5000 0 k1 5000 4800 0 k2 5000 3200 0 k3 3000 3200 0 k4 3000 4800 0 x1 3000 1500 0 Die Koordinaten sind sicher nicht ma stabsgetreu KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 68 7 1 3 2 4 SigPropBlock lt SIGNAL_PROPERTIES gt lt sigpropdef gt lt SIGID gt lt WAIT_STRAIGHT gt lt WAIT_LEFT gt lt WAIT_RIGHT gt lt RR_STRAIGHT gt lt RR_LEFT gt lt RR_RIGHT gt lt SWITCHTIME gt lt POSINT gt lt sigpropblock gt lt sigpropdef gt Dieser Block enth lt zu jedem im DefBlock aufgef hrten Signal eine n here Eigenschafts beschreibung Er beginnt mit dem Schl sselwort signal properties gefolgt von einer in geschweifte Klammern eingeschlossenen beliebigen Anzahl von Eigenschaftsbeschrei bungen Diese wiederum bestehen aus einem Signalbezeichner gefolgt von einem Dop pelpunkt auf den eine Reihe Schl sselworte folgen kann und am Ende das Schl sselwort switchtime mit einer positiven Ganzzahl folgen muss Die einzelne Eigenschaftsbe schreibung endet mit einem Semikolon Bedeutung Jedes der optional vorkommenden Token wie WAITSTRAIGHT etc gibt an ob ein Si gnal ber die entsprechende Anzeigem glichkeit verf gt Kommt ein Token vor ist die entsprechende Anzeigem glichkeit am Signal vorhanden ansonsten nicht Verpflichtend ist die Switchtime in Millisekunden anzugeben Beispiel signal propert
18. s3013 signal s3013_stop s3013_straight none s3013_right s3015 signal s3015_stop s3015_straight none s3015_right 7 6 4 3 3 Bedingungen zum Stellen der Signale F r jedes Signal existieren Be dingungen wann es einen bestimmten Zustand annehmen soll Wenn eine Route die die entsprechende Signalstellung ben tigt im Zustand ACTIVE ist und alle Weichen die zu dieser Route geh ren bereits richtig gestellt wurden ist die Bedingung zum Schalten des Signals erf llt Es m ssen erst alle Weichen so gestellt sein wie es f r die jeweilige Route definiert wurde bevor durchs Stellen der Signale die Route freigegeben werden darf In dem Beispiel soll das Signal s3014 geradeaus gestellt werden wenn die Route r2 im Zustand ACTIVE und die Weiche w1022 geradeaus gestellt ist und nach links wenn die Route r3 im Zustand ACTIVE und die Weiche w1022 nach links gestellt ist Wenn eine Route zu der das Signal geh rt wieder gesperrt werden soll muss das be treffende Signal auf STOP gestellt werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 219 So soll das Signal s3014 in dem Beispiel auf STOP gestellt werden wenn entweder die Route r2 oder die Route r3 wieder gesperrt werden soll Die entsprechenden Bedingun gen wann eine Route gesperrt werden soll werden weiter unten angegeben s3014_stop case r2_lock_cond r3_lock_cond 1 0 esac s3014_straight 1 0 esac s3014_left case r3 state ACTIVE amp w10
19. signal while missingSteps steps are pending 66 stop true KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 385 67 missingSteps 0 68 69 return stop 70 3 Ist die Vorausschau gem der gew nschten Weite abgeschlossen diese Weite ist in einer Konstanten der Tram Klasse abgelegt gelangt der Programmablauf an diese Stelle es wird nun gepr ft ob am aktuell n chsten Linkable Element ein Stop Signal zu beachten ist indem der in mustStop abgelegte Wert abgefragt wird Falls dem so ist und die Bahn an der Position ist an der sie stehen bleiben muss liefert die Methode true zur ck so dass die Methode die checkStop aufgerufen hat die Bahn anhalten kann Zu beachten ist noch dass f r die korrekte Funktion jedes Mal wenn die Bahn ein Linkable Element berf hrt mustStop per Ganzzahldivision durch 2 dividiert wird da ja die in der Bitmap gespeicherten Werte die wie beschrieben ein Signal am n chsten bern chsten usw Linkable Element referenzieren entsprechend verschoben werden m ssen 7 8 5 2 3 Auffahren amp Kollisions berpr fung der Tram Prinzipiell gibt es drei Arten der Kollision e eine Bahn f hrt auf das Ende einer vorausfahrenden Bahn auf e Bahnen sto en mit dem Kopf frontal zusammen e eine Bahn f hrt einer anderen in die Seite Der erste Fall soll nicht durch den SI sondern durch den Fahrer verhindert werden Insofern muss der Simulator bevor er die Bahn tats chlich fortbewegt
20. wi switchtime 500 w2 passive fallback straight switchtime 500 w3 passive switchtime 800 w4 passive switchtime 800 7 1 3 2 6 SlipswitchBlock lt slipswitchblock gt lt SLIP_SWITCHES gt lt slipswitchdef gt lt slipswitchdef gt lt CROSSID gt lt POINTID gt lt POINTID gt lt POINTID gt lt POINTID gt lt SWITCHTIME gt lt POSINT gt Dieser Block wird durch das Schliisselwort slip switches eingeleitet gefolgt von einer in geschweifte Klammern eingeschlossenen beliebigen Anzahl von Kreuzungsweichen Definitionen Eine solche beginnt mit einem Kreuzungsbezeichner der nach einem Dop pelpunkt von zwei oder vier durch Komma getrennten Weichenbezeichnern gefolgt wird bevor wiederum ein Doppelpunkt das Schl sselwort switchtime eine positive Ganz zahl und ein abschlie endes Semikolon folgt Zu verstehen ist eine einzelne Kreuzungsweichen Definition so dass hier eine Kreuzung mit zwei oder vier Teilweichen so gekoppelt ist dass sie ein einzelnes Element eine Kreuzungsweiche bildet das nur von einer Bahn gleichzeitig befahren werden kann Ei ne solche Kreuzungsweiche hat dann auch eine gemeinsame Schaltzeit Sollten f r die Teilweichen unterschiedliche Schaltzeiten vorliegen so ist hier die h chste von ihnen zu nennen nach dieser Zeit muss das gesamte Element auf jeden Fall geschaltet haben Ein Beispiel muss an dieser Stelle entfallen da im Beispielnetz kein solches Element
21. Abbildung 7 24 Routeninformationen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 127 7 3 2 8 Weichenkonflikttabelle Anhand der Routendefinitionen wird die Weichenkonflikttabelle automatisch generiert Wenn zwei Routen die gleiche Weiche befahren sollen besteht ein Weichenkonflikt zwi schen diesen beiden Routen Eine ausf hrliche Erkl rung dazu ist in der Beschreibung des point conflicts Blocks im Abschnitt 7 1 3 2 12 auf Seite 75 zu finden Die Abbil dung 7 25 zeigt ein Beispiel einer Weichenkonflikttabelle TND C gleisnetz_2 tnd man also R i e Point Conflict Table Route Conflict T Route routs owe me el mn en oe route15 route16 a un i 5 ii q a E m fi route1 E sE I mc y O El Li route13 oO e E 9 0O EI Ei 7 route1 EI 0O I 9 0 v O route29 Oo oO oO OF MM L H i route14 ra wy m tft I SET HE EEE Abbildung 7 25 Weichenkonflikttabelle 7 3 2 9 Routenkonflikttabelle Zus tzlich zu der automatisch generierten Weichenkonflikttabelle muss der Nutzer auch alle Routenkonflikte in einem Gleisnetz identifizieren die zu Kollisionen zwischen Bah nen f hren k nnen Diese Konflikte zwischen je zwei Routen werden in der Tabelle durch ein Kreuz markiert Eine ausf hrliche Erkl rung dazu ist in der Beschreibung des conflicts Blocks im Abschnitt 7 1 3 2 13 auf Seite 76 zu finden Die Abbildung 7 26 auf der n chsten Seite zeigt ein Beispiel einer Routenkonflikttabelle
22. Anhand des gegebenen Gleisnetzes werden die Verschlusstabellen erstellt In den Verschlusstabellen werden Routeninformationen f r das jeweilige Gleisnetz defi niert e Dom nenspezifische Beschreibungssprache DSL Es wird eine DSL Domain Specific Language entwickelt Eine DSL ist eine Spra che die die Begriffe und Konzepte ihres Anwendungsgebietes verwendet Die ent wickelte DSL wird als TND Tram Network Description bezeichnet Sie enth lt eine Beschreibung des Gleisnetzes eine Beschreibung der geplanten Routen sowie eine Beschreibung der verwendeten Hardware 38 KAPITEL 4 DER LOSUNGSANSATZ 39 lt Gleisnetz gt e per Hand A N Routenpl ne CAD Daten Verschlusstabellen Konflikttabellen Abbildung 4 1 Herk mmlicher Ansatz bei der Entwicklung von Gleisnetzsteuerungssys temen e Compiler Ein Compiler erzeugt aus der TND bin re Projektierungsdaten welche vom Steu erinterpreter effizient verarbeitet werden k nnen e Steuerungssoftware Die eigentliche Steuerungsaufgabe bernimmt eine Softwarekomponente die in terpretativ auf Grundlage der Projektierungsdaten arbeitet TRA e Verifikation Die Sicherheit der Projektierungsdaten wird mit Hilfe von Model Checking ber pr ft e Test KAPITEL 4 DER LOSUNGSANSATZ 40 Gleisnetz gt Poren per Hand a IN Routenpl ne CAD Daten Verschlusstabellen Konflikttabellen Simulation Model Checking Com
23. denklichen Parameter und Typ eines Gleisnetzelements hier eine Erfassungsm glichkeit vorhanden sein muss und die Objekte dieser Klasse f r jedes Element in einem Gleisnetz genutzt wird F r jede Eigenschaft existiert also ein Attribut eine Methode zum Setzen dieses Attri buts Set Methode und eine Methode um die Daten dieses Attributes wieder auslesen zu k nnen Get Methode Au erdem sind einige konstante Parameter definiert dessen Werte in einzelnen Attribu ten abgespeichert werden k nnen wenn diese f r den entsprechenden Element Zustand und Typ zutreffend sind wie zum Beispiel der Typ einer Weiche 7 2 3 2 8 NGElementList java Die zuvor genannten NGElement Objekte werden zur einfacheren Abarbeitung in ArrayLists gespeichert Die Klasse NGElementList java stellt solche ArrayLists und entsprechende Methoden zur Bearbeitung derselben bereit Die NGElementList Objekte dienen letzlich auch als eine Art Sortier Container aus denen sp ter beim Erzeugen die Gleisnetzelemente nach globalen Typen sortiert ausge lesen werden k nnen Das detaillierte Klassendiagramm Abb 7 9 zeigt die in dieser Klasse verwendeten Me thoden und Attribute Im Gegensatz zu NGElement java ist die Anzahl der Attribute und Methoden hier berschaubar da hier letzlich nur andere Objekte gesammelt werden 7 2 3 2 9 NGLines java Neben den Elementen eines Gleisnetzes wie zum Beispiel Weichen oder Signalen gibt es auch noch die Verbindungsst cke dieser El
24. ponente 3 verantwortlich Dadurch kann der Benutzer die Routen einfach und bequem definieren und die Eingabe wird visualisiert Hier werden alle wichtigen GUI Komponenten kurz erkl rt e trMainFrame trMainFrame ist das Hauptfenster des Programms und enth lt eine Toolbar und ein Menue Er kann mehrere tr NDInternalFrame gleichzeitig beinhalten KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 133 e trTNDLoadFrame trINDLoadFrame sammelt Informationen die zum Einlesen der TND ben tigt werden Dazu muss eine TND Datei angegeben werden Die Hardware Class Datei und die Driver Class Datei sind optional Das Format von Hardware Class Datei und Driver Class Datei ist im Abschnitt 7 5 4 7 auf Seite 199 zu finden e trTNDInternalFrame trINDInternalFrame ist f r eine TND Datei zust ndig Er beinhaltet mehrere Tabpanels Jedes Tabpanel zeigt einen Teil der TND Datei und kann in folgende Kategorien eingeteilt werden Hardware Definition Tab x Weichen Tab Signale Tab x Sensoren Tab x Cross Tab x Mark Tab x HW Class Tab Driver Class Tab Verschlusstabellen Tab x Route Definition Tab x Weichen Konflikt Tab x Routen Konflikt Tab e trRouteDialog trRouteDialog ist ein Dialog der f r Routendefinitionen und Routendarstellun gen zust ndig ist Deng Zhou 7 3 5 Reflexion In diesem Abschnitt wird zun chst dargestellt was in den einzelnen Semestern erreicht wurde und dann erfolgt ein Ausblick auf die
25. te Dort gibt es kein neues TrackElement mehr getNextTE wirft in diesem Fall eine NetworkEndException Tritt eine solche auf wird zun chst gepr ft ob das nun erreich te Ende ein totes Ende ist dorthin d rfte eine Bahn nicht geleitet werden weswegen in dem Fall eine Fehlersituation eingetreten ist Handelt es sich aber um eine Ausfahrt so wird gepr ft ob der Kopf bereits das Netz verlassen hat wenn ja so muss nun auch das Ende der Bahn das Netz verlassen womit sie v llig das Netz verlassen h tte das wird in vanish gespeichert Andernfalls ist es erst der Kopf welcher verschwindet so dass die zugeh rige Variable gesetzt wird Zur Erinnerung Wenn der Kopf verschwunden ist die Berechnung aber f r den Kopf vorgenommen werden soll gelangt der Programmlauf nicht an diese Stelle Damit ist die Berechnung der neuen Position auf dem neuen TrackElement abgeschlos sen 46 if head headVanish 47 dirArr 0 dir 48 posArr 0 pos 49 teArr 0 te 50 51 if this justEmerged amp amp head 52 1 Linkable te getBorders dir 0 1 53 this justEmerged false 54 55 return l 56 J 57 Zum Schluss werden die errechneten Werte in die bergebenen Arrays geschrieben und das berfahrene Linkable Hardware Element zur ckgegeben Au erdem erfolgt an dieser Stelle noch eine Abfrage ob eine Bahn in gerade diesem Schritt vollst ndig in das Netz eingefahren ist in dem Fall muss n
26. void insertSignalProperties char name bool waits bool waitl bool waitr bool rrs bool rrl bool rrr long int switchtime werden die Eigenschaften fiir das entsprechende Signal in die Symboltabelle eingetragen Hierbei sind einige Eigenschaften optional Dies wird wie folgt erm glicht waitstraightopt WAIT_STRAIGHT empty gt Gibt es das entsprechende Schliisselwort fiir die Eigenschaft wird der Wert hierfiir auf TRUE gesetzt ansonsten auf FALSE Dies geschieht entsprechend bei allen optionalen Eigenschaften Der n chste eventuell zu reduzierende Block ist der f r die Point Properties Dessen h chste Regel schaut nach dem Schl sselwort und dessen anh ngende Liste von ptprop def ptpropblock POINT_PROPERTIES ptpropdeflist POINT_PROPERTIES error 2 ptpropdeflist ptpropdef ptpropdef ptpropdeflist Eine ptpropdef besteht aus dem Bezeichner f r die Weiche und denn Eigenschaften ptpropdef POINTID passiveopt fallbackopt breakableopt SWITCHTIME POSINT insertPointProperties Wobei wieder der Postfix opt fiir die optionalen Eigenschaften steht die wie bereits vorher beschrieben optional gehalten werden Durch den Aufruf von KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 156 void insertPointProperties char name bool psv int dir bool brk long int sw wird das entsprechende Element aus der Symboltabelle ausgesucht und die zugeh rigen Eigenschaft
27. A B Bool So befindet sich in dem Beispiel das Signal s3013 an der Seite A des Sensors g4125 signal_be f ore s3013 g4125 A TRUE KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 238 7 6 5 2 Controller Modell Um das Controller Modell zu erstellen werden Informationen ber die Routen aus den Projektierungsdaten ben tigt 7 6 5 2 1 Route Dispatcher Aus den Projektierungsdaten f r den Route Dispat cher werden die Informationen ben tigt die sich durch folgende Funktionen ausdr cken lassen e Die Funktion routes routesge Projektierungsdaten Reet liefert die Menge aller in den Projektierungsdaten enthaltenen Routen e Die Funktion con flict conflict routel Rset x route2 Rset Bool gibt f r zwei unterschiedliche Routen routel Rset und route2 Rse an ob ein Konflikt zwischen ihnen definiert ist e Die Funktion rrsensor_id rrsensor_id route Rse Integer liefert die ID des Route Request Sensors einer Route route Reet 7 6 5 2 2 Route Controller Aus den Projektierungsdaten f r den Route Control ler werden die Informationen ben tigt die sich durch folgende Funktionen ausdr cken lassen Welche Signal bzw Weichenstellungen jeweils ben tigt werden kann man daran erken nen welches Bit gesetzt ist e Die Funktion point_request point_request p Pse x route Re X direction Bool mit direction L R S gibt an ob eine Weiche p Pet f
28. Abbildung 7 60 Schema des Hardware Software Integrationstests aus Sicherheitsaspekten relevanten Testf lle aussucht Hierbei sollten insbesondere die sicherheitskritischen berg nge der Transition gepr ft werden Eine solche Heuristik wurde nicht entwickelt Desweiteren ist in Zukunft eine Erweiterung des oben beschriebenen Testvorgehens not wendig um auch harte Echtzeiteigenschaften eines Safety Controllers berpr fen zu k nnen Hierzu k nnten die in AD94 vorgeschlagenen Grid Automata benutzt werden Dies steht allerdings nicht im Widerspruch zum bisherigen Testkonzept da auch Grid Automata eine Erweiterung der in Cho78 eingef hrten W Methode sind Ein solches Konzept zum Testen von Echtzeiteigenschaften eines Safety Controllers wurde ebenfalls noch nicht entwickelt Helge L ding 7 7 8 Reflexion In diesem Kapitel sollen die Erkenntnisse und Erfahrungen iiber die Arbeit die fiir die Entwicklung der Testprozeduren geleistet wurde eingesch tzt und bewertet werden 7 7 8 1 Wintersemester 2003 2004 In dem ersten Projektsemester wurden theoretische Grundlagen des Testvorganges er fasst Es wurde ein Arbeitsplan erstellt der die Arbeitspakete enthielt die im n chsten Semester in die Tat umgesetzt werden sollten KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 310 SUT Testrechner Linux System Projektierungsdaten L Testsoftware X oe Gleisnetz
29. Auch diese Sendeeinheit des Simulators wird als eigener Thread realisiert damit der Simulator nicht durch einen ggf l nger dauernden Sendevorgang blockiert wird Folglich ist auch hier ein Datenaustausch zwischen Simulator und Sender n tig dieser erfolgt analog zu obigem Vorgehen ebenfalls ber eine Liste Der Simulator schreibt in diese Liste der Sender pr ft fortlaufend ob sich etwas darin befindet und sendet die in der Liste befindlichen Meldungen an die Hardware Treiber des Steuerinterpreters Zur Nebenl ufigkeit gilt das Gleiche wie oben 7 8 4 6 2 Kommunikationsablauf und Nachrichtenformat F r die Kommuni kation wurde ein Nachrichtenformat definiert das im Folgenden beschrieben werden soll Beginnen soll die Beschreibung jedoch mit dem Kommunikationsablauf e Jeder Treiber muss sich nach seinem Start beim Simulator anmelden Die Anmel denachricht enth lt die Hardware ID f r welche der Treiber zust ndig ist e Die so entstandene Verbindung wird offengehalten und fortan in beide Richtungen benutzt e Der Simulator antwortet darauf mit einer ersten Statusmeldung in der der Schalt zustand des Elements bermittelt wird KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 365 e Im fortlaufenden Betrieb erfolgen lediglich Meldungen wenn Anderungen am Zu stand eingetreten sind der neue Zustand berschreibt demnach den alten e Gleiches gilt fiir die Treiber Meldungen werden nur abgesetzt wenn ein neuer Zustand angefordert werd
30. Aus der TND k nnen die folgenden Informationen gewonnen werden ID Treibertyp und Mapping von ID auf Hardwareklasse Ein paar Informationen sind jedoch nicht direkt mit in die TND aufgenommen worden da sie vom konkreten Gleisnetz unabh ngig sind So sollten die Hardwareklassen inkl der Hardwaredaten selbst f r alle Gleisnetze g ltig sein und die Zuordnung von Hardwareklassen zu Treiberklassen ist mehr Software als Gleisnetzspezifisch z B wird ein Simulator wohl andere Treiber benutzen als ein operatives System Zur Realisierung wurde die TND um einen neuen Block erweitert in dem die Zuordnung von Hardwareelementen zu Hardwareklassen spezifiziert wird lt HWBLOCK gt hardwaremap lt HWDEF gt lt HWDEF gt lt HWCLASS gt lt ELEMENTID gt lt ELEMENTID lt HWCLASS gt c lt IDENTIFIER gt Es wird also f r jede Hardwareklassen eine Liste der zugeh rigen Elemente angegeben Elemente die f r den Steuerinterpreter nicht interessant sind z B Markierungspunk te haben keine Hardwareklasse und werden hier nicht aufgelistet Ein Nachteil dieser L sung ist dass die Typinformationen Treibertyp und Hardwareklasse f r jedes Ele ment in zwei verschiedenen Listen verwaltet werden Die genauen Daten einer Hardwareklasse werden in folgender Form festgehalten lt HWCLASSDEFS gt lt HWCLASS gt lt DESCRIPTION gt lt TIMEOUT gt n lt DESCRIPTION gt lt LETTER OR DIGIT gt lt DES
31. BESCHREIBUNG DER KOMPONENTEN 312 vorliegende Vernachlassigung des Testbereiches zu nennen sind Marcin Dysarz letztes Semester auch Arne Stahlbock KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 313 7 8 Simulator 7 8 1 berblick Im Rahmen des Projektes wurde ein Simulator f r Stra enbahnnetze entwickelt Die ser Simulator ist dabei so angelegt dass mit ihm mehrere im Projektkontext stehende Aufgaben gel st werden k nnen die sich wie folgt identifizieren lassen e Visualisierung des Gleisnetzes Der Simulator soll ein komplettes Gleisnetz im statischen Zustand visualisieren k nnen zur berpr fung ob das Gleisnetz in korrekter Form vorliegt Dies dient zur Pr fung der Korrektheit des ebenfalls im Projekt TRACS entwickelten CAD TND Konverters e Visualisierung der Funktionsweise des Steuerinterpreters Um die Anweisungen des im Projekt entwickelten Steuerinterpreters anschaulich nachvollziehen und berpr fen zu k nnen wird ein Gleisnetz samt darauf fahren den Stra enbahnen visualisiert und ein dynamischer Ablauf simuliert e Erstellung einer Testm glichkeit Mit Hilfe des Simulators soll es m glich sein bestimmte Situationen gezielt nach stellen zu k nnen um die Reaktion des Steuerinterpreters zur Laufzeit berpr fen zu k nnen Auch soll der Simulator f r SI Dauertests einsetzbar sein Allgemein gesagt simuliert der Simulator ein Gleisnetz mit darauf fahrenden Stra Benbahnen sendet die Informationen ber den j
32. CUP Parser Generator for Java aka Java Based Constructor of Use ful Parsers ist ein Tool fiir Java welches aus einer Spezifikationsdatei einen Parser generiert hnlich bison f r C Es ist ausgelegt auf eine Kombination mit dem Lexer Generator JFlex CVS s Concurrent Versions System Data Exchange File kurz auch DXF Dateiformat f r zweidimensionale CAD 481 ANHANG F GLOSSAR 482 Zeichnungen Datendarstellung etikettierte Beschreibung in der die einzelnen Elemente durch Auszeichnungen gekennzeichnet sind Domain Specific Language Eine Domain Specific Language DSL ist eine spezielle Sprache die fiir ein bestimmtes Anwendungsgebiet entwickelt wird Wir beschreiben mit unserer DSL den Aufbau eines Gleisnetzes vor allem Sensoren Signale und Weichen Doxygen Doxygen ist ein Dokumentationswerkzeug f r u a Java und C C welches auf Grundlage von Quelltext Dateien eine Dokumentation z B in HTML au tomatisch generiert Sofern Klassen Methoden und Variablen im Quellcode kommentiert sind werden diese auch in die Dokumentation kopiert DSL s Domain Specific Language DXF s Data Exchange File EBNF s Extended Backus Naur Form Extended Backus Naur Form Die Extended Backus Naur Form EBNF ist eine g ngige Notation mit der man die Syntax einer Sprache formulieren kann Wir beschrei ben damit die Syntax unserer DSL EVP Entwicklungs Verifikationsprozess Fehlerbaumanalyse Eine Fehle
33. D h eine von dieser Seite auf den Sensor zufahrende Bahn muss das Signal beachten b Das Signal steht zwischen zwei Sensoren In diesem Fall muss es an einer Markierung stehen damit der genaue Punkt auf dem Gleis an dem eine Bahn ggf halten muss bekannt ist Aufgef hrt werden hier in diesem Fall der Sensor Seite von dem die Bahn kommt die Markierung an der das Signal steht und der Sensor mit der Seite auf die die Bahn zuf hrt Beiden Darstellungen ist also gemeinsam dass immer der letzte Sensor derjenige ist auf den die Bahn aus der f r ihn angegebenen Seite zufahren muss um das Signal zu sehen Beispiel signal positions si gl01 A s2 g201 A s3 g300 B x1 g301 A s4 g401 A 7 1 3 2 9 RouteBlock lt ROUTEDEFINITIONS gt lt rtdef gt lt ROUTEID gt lt SENSID gt lt SENSID gt lt SENSID gt lt REQUESTAT gt lt SENSID gt lt SENSID gt lt routeblock gt lt rtdef gt KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 73 Vor dem RouteBlock steht das Wort routes welches den Block identifiziert Der ge samte Block von beliebig vielen Routendefinitionen wird mit geschweiften Klammern umrahmt Jede Routendefinition f ngt mit dem Namen der Route an auf den ein Dop pelpunkt folgt Anschlie end werden alle Sensoren dieser Route aufgez hlt und durch Kommata getrennt Es m ssen mindestens zwei Sensoren pro Route angegeben werden Es folgt ein Bindestrich das Schl sselw
34. Das einfache sequen zielle Testen besteht aus zwei Schritten Als erstes sendet man Input Befehle zum SUT dann berpr ft man die Ausgabe des SUT und vergleicht diese mit der erwarteten Ausgabe Solche Tests sind vor allem f r Unit Test aber nicht f r viele komplexe Applikationen geeignet bei denen einige logi sche Threads parallel zusammenarbeiten In Situationen bei denen das Verhalten des SUT abh ngig ist von einigen Zustandsvariablen die wom glich unabh ngig vonein ander ver ndert werden funktioniert dies aufgrund der asynchronen Simulationen der verschiedenen Schnittstellen nicht Ausgaben von einer AM werden oft nicht nur vom KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 262 SUT sondern auch von den anderen AMs verarbeitet deren kommendes Verhalten oder deren Testergebnisse abh ngig von den Ereignissen der Ausgaben sind Wenn eine SUT Schnittstelle ver ndert wird oder SWI Test Software Integrationstest Spezifikationen auf HSI Test Hardware Software Integrationstest Stufe mehrmals benutzt werden ist es praktisch nur das zusammenf hrend Interface Module IFM gewechselt wird ohne die Test Spezifikationen zu ndern Jun Liang und Jinghong Jin bearbeitet von Marcin Dysarz 7 7 4 Testvorbereitung Aus bereits genannten Gr nden haben wir nur Software Tests durchgef hrt d h Unit Tests die jeweilige Hauptfunktion der Software Komponenten F r die verschiedenen Ebenen der Integrationstests besteht ein Vorschlag
35. Der Typ der Weiche soll au erdem erkennbar sein Signale Signals F r die Visualisierung eines Signals ist es wichtig sowohl die Anzeige als auch die Richtung des Signals zu verdeutlichen Wenn z B auf einer Geraden Stra enbah nen sowohl in die eine als auch in die andere Richtung fahren dann ist es wichtig als Anwender des Simulators zu erkennen ob das Signal an dem die Bahn gerade vorbeif hrt f r die Weiterfahrt der Bahn zust ndig ist Stra enbahnen Trams Die Darstellung einer fahrenden Bahn sollte erkennen lassen wo sich der Kopf und wo sich das Ende befinden also in welche Richtung die Stra enbahn f hrt und auf welchem Bereich auf dem Gleisnetz die Bahn gerade steht Dies ist wichtig f r die manuelle Kontrolle ob die Sensoren richtig funktionieren ob die Bahn auf die Signale reagiert und ob ein Zusammensto auch richtig erkannt wird Da die Hauptaufgabe der Visualisierung die Darstellung des Systemzustands ist also die Komposition der Zust nde der einzelnen Sensoren Signale Weichen und Bahn en spielt die Formsch nheit lediglich eine untergeordnete Rolle Die Darstellung soll grafisch am Bildschirm erfolgen Ferner muss die Darstellung geeignet sein die Korrektheit der CAD TND Umwandlung N heres zum CAD TND Konverter in den Kapiteln 7 2 3 2 auf Seite 89 und 7 2 4 auf Seite 104 zu verifizieren Dazu m ssen also alle Details die in der DXF Darstellung vorkommen auch in der Visualisierung des Simu
36. ENDSEC ANHANG B DXF DATEI FORMAT 469 Als Anmerkung sei erw hnt das das Programm DXFSeperator java neben dem Ex trahieren der Sektionen auch die vorhandenen Daten etwas ausd nnt und dabei die unwesentlichen Zeilenpaare entfernt Henrik R hrup Anhang C DXF Objekt Bibliothek C 1 CAD Bibliothek Im Folgenden eine graphische Darstellung aller Elemente der DXF Objekt Bibliothek Zum paa Talla bo aM an ar an Tun praia Padibect da right etree as s ae Sum paths bp Swap acting und hraakahla Swap adira wed mir nabs olen Swap mtra Mlha 4a lett ATAS KATR ane on Swap paaria fallback to ripitin igit Fwar puache Goble ve ve X lpntcher jarientty HOT rappari Abbildung C 1 Weichen Objekte Die Abbildung C 1 zeigt s mtliche Weichen Objekte der Teil Bibliothek points Es gibt diverse 2 Wege Weichen 3 Wege Weichen und sog Kreuzungsweichen Kreuzungen mit 470 471 ANHANG C DXF OBJEKT BIBLIOTHEK Weichenelementen Die beiden zuerst genannten Kategorien sind sowohl als aktive mit Motor wie als passive Umstellung bei berfahren vorhanden P Abbildung C 2 Signal Objekte Die Abbildung C 2 zeigt s mtliche Signal Objekte Fahrtrichtungssignale der Teil Bibli othek signals Welches Signal welche Richtungen anzeigen kann ist dem Textfeld in nerhalb des Kreises zu entnehmen Abbildung C 3 Sensoren Objekte Die Abbildung C 3 zeigt s mtliche Sensor Objekte der Teil Bibliothek sen
37. Im Prinzip ist das Steuersystem ebenfalls ein Element der Bahntechnik da aber Teile des Steuersystems von uns entwickelt werden w hrend die brige Bahntechnik bereits wie beschrieben vorliegt wird es hier gesondert aufgef hrt Zudem kann ein Gleisnetz auch ohne Steuersystem betrieben werden aber umgekehrt hat ein Steuersystem ohne Gleisnetz keinen Nutzen 2 3 4 Gleisnetzdaten Nicht direkt als Bahntechnik zu bezeichnen dennoch in diesem Zusammenhang auf zuf hren sind verschiedene Dokumentationen ber das Gleisnetz die insbesondere f r den Betrieb des Steuersystems ben tigt werden Dazu z hlen KAPITEL 2 DIE DOMANE 25 e Verschlusstabellen Routendefinitionstabelle definiert die durch das Gleisnetz zu befahrenden Routen das m ssen nicht zwangsl ufig alle berhaupt m glichen Routen sein sondern nur die vom Gleisnetzbetreiber gew nschten Konflikttabelle zeigt auf welche Routen miteinander in Konflikt stehen und daher nicht zeitgleich befahren werden d rfen Weichenstellungstabelle und Signalstellungstabelle zeigen auf welche Wei chen bzw Signalstellungen jeweils f r das Befahren der definierten Routen ben tigt werden e Gleisnetzbeschreibung Dokumentiert wie das Gleisnetz als solches aus den in diesem Weltmodell beschriebenen Elementen zusammengesetzt ist Diese kann u a als sogenannter Netzgraph einer CAD Zeichnung vorliegen e Hardwarebeschreibung Dokumentiert die verschiedenen im
38. Zustand wechseln Wichtig Wenn ein Element erst einmal in diesem Zustand ist kommt es nicht wieder zur ck zum Normalverhalten wenn man also einmal w hrend des Simulationslaufs die Option eingeschaltet hatte k nnen sich Elemente infiziert haben aber erst nach Abschalten der Option der Ausfall tats chlich stattfinden da der tats chliche Ausbruch wiederum an einem zuf lligen Zeitpunkt erfolgt 7 8 4 5 Visualisierung Die Visualisierung der Simulation dient dem leichteren Verst ndnis wie die Simulation abl uft Damit die Zeichen Routinen den Simulator nicht abbremsen l uft die Visua lisierung in einem eigenen Thread Die graphische Darstellung soll korrekt sein aber die Formsch nheit spielt eine untergeordnete Rolle vgl Anforderung s 7 8 2 3 auf Sei te 318 Die zu visualisierenden Elemente sind Gleise Weichen Sensoren Signal und Stra enbahnen Bei den Hardware Elementen Weiche Sensor und Signal soll au erdem die Stellung und die Information des Typs erkennbar sein Markierungen werden nicht extra visualisiert da sie ein funktionsloser Teil des Gleisnetzes sind der bereits durch die Gleise visualisiert wird Bei der Visualisierung handelt es sich um eine Darstellung in 2D in der Draufsicht Es werden keine Grafiken benutzt sondern alle Elemente werden gezeichnet Die Vi sualisierung der einzelnen Elemente wird einfach und eindeutig gehalten Da bei der Darstellung von Stellungen und Zust nden symbolisch
39. auch als Versagen der Gruppe bewerten Silvia Graumann Niklas Polke Arne Stahlbock Kapitel 8 Sicherheitsnachweis 8 1 berblick Die wesentliche Aufgabe von Bahnsteuerungssystemen ist es Katastrophen wie Kolli sionen oder Entgleisungen zu vermeiden Das Steuerungssystem muss daher die Signale und Weichen so schalten dass solche Ereignisse nicht auftreten k nnen Um die Sicherheit des Systems nachzuweisen werden zun chst alle m glichen Bedrohun gen Hazards identifiziert die dazu f hren k nnen dass die Sicherheitsanforderungen nicht erf llt sind Die ermittelten Hazards beruhen auf dem Weltmodell Jeder Hazard kann dabei unterschiedliche Ursachen haben Aus diesen Ursachen werden diejenigen ermittelt die durch das System zu beeinflussen sind Um die Hazards bzw die Ursachen eines m glichen Hazards systematisch darzustellen wird eine Fehlerbaumanalyse Fault Tree Analysis durchgef hrt So wird nachgewiesen dass der jeweilige Hazard nicht auftreten kann wenn sichergestellt wird dass die Ursa chen nicht auftreten k nnen Diese Fehlerbaumanalyse wird im Abschnitt 8 2 angegeben Eine Auswertung des Fehlerbaums erfolgt im Abschnitt 8 3 auf Seite 435 Taffou Happi Ruben Rothaupt 8 2 Fehlerbaumanalyse Das Ergebnis der Fehlerbaumanalyse l sst sich in einer Baumstruktur darstellen Auf diese Weise l sst sich erkennen welche Ursachen der jeweilige Hazard haben kann e Der senkrechte Strich steht f r eine Oder
40. d h die Anforderung wird an das entsprechende Hardware Element weitergeleitet Ein beispielhafter Ablauf k nnte wie folgt aussehen Nehmen wir an der Steuer interpreter entscheidet sich zur Umschaltung einer Weiche und beschreibt den entsprechenden Speicherbereich im Shared Memory Diese nderung wird vom Treiber erkannt der daraufhin einen String mit der Anforderung zusammensetzt Dieser String wird dann an den DriverRequestServer gesendet welcher im Simu lator die Anforderungsannahme darstellt Der String wird also eingelesen auf Korrektheit gepr ft und im Falle der Korrektheit in einer Warteliste abgelegt Wie bereits beschrieben pr ft der Simulator in jedem Rundendurchlauf ob neue Anforderungen anliegen ist das der Fall so holt er sich diese aus der Warte liste extrahiert die ben tigten Informationen aus dem String und ruft auf dem Hardware Element f r das die Anforderung gilt in unserem Fall also eine Wei che eine Methode auf die diesem Element die Anforderung bergibt Zus tzlich wird der Zeitpunkt der Anforderung gespeichert damit das Element sp ter nach der richtigen Reaktionszeit umschalten kann siehe 7 65 Tumout setRequestedStateinew state new state valid get timestamp from simulator false handle failure set requested state Abbildung 7 65 Aktivit tsdiagramm Turnout setRequestedState 2 Hardware besch digen Ist es gew nscht dass Hardware Elemente ausfall
41. defekt die zweite potentiell defekt und die dritte defekt Eine Aktivierung dieser Option bewirkt dass Elemente von Ebene 1 auf Ebene 2 bergehen k nnen Sind sie erst einmal auf Ebene 2 k nnen sie nicht wieder zur ck auch falls die Option wieder abge schaltet wird Auf Ebene 2 befindliche Elemente k nnen in jedem Moment unabh ngig von dem Bet tigen dieser Option Defekte zeigen und damit auf Ebene 3 wechseln auf der sie dann bis ans Ende der Simulation verbleiben 7 8 7 3 10 Info About SimTracs Diese Option gibt einen kurzen Info Text aus Arne Stahlbock 7 8 8 Reflexion In diesem abschlie endem Kapitel soll r ckblickend ber die Erkenntnisse und Erfah rungen berichtet werden die bei der Implementierung des Simulators gewonnen wurden Unser R ckblick befasst sich mit zwei getrennten Aspekten unserer Arbeit zum einen mit den inhaltlich gewonnenen Erkenntnissen und zum anderen mit den Erfahrungen ber Gruppenarbeit und die speziellen Schwierigkeiten in unserer Arbeitsgruppe 7 8 8 1 Planungsfehler Im Rahmen der gesamten Planung des Simulators wurden von der Simulatorgruppe viele Fehler gemacht Diejenigen die wir bis dato erkannt haben beschreiben wir in diesem Unterkapitel Erkannt haben wir folgende unserer Fehler e keine n Zeitplan Arbeitspakete aufgestellt e Anforderungen erst w hrend der Implementierung aufgestellt e Konzept erst w hrend der Implementierung aufgestellt e Benutzung vo
42. drv gt old_out amp OUTPUT_MASK in else bytes_read strlen read_buffer read_buffer bytes_read 0 bytes_worked 0 if strncmp read_buffer STR_STATUS 7 0 bytes_worked 7 if atoi read_buffer bytes_worked drv gt id bytes_worked 4 if strncmp read_buffer bytes_worked STR_STRAIGHT 9 0 new_shm in amp INPUT_MASK KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 406 new_shm 1 lt lt POINT_GET_STRAIGHT out new_shm drv gt old_out new_shm else if strncmp read_buffer bytes_worked STR_LEFT 5 0 1 new_shm in amp INPUT_MASK new_shm 1 lt lt POINT_GET_LEFT xout new_shm drv gt old_out new_shm else if strncmp read_buffer bytes_worked STR_RIGHT 6 0 new_shm in amp INPUT_MASK new_shm 1 lt lt POINT_GET_RIGHT out new_shm drv gt old_out new_shm else if strncmp read_buffer bytes_worked STR_UNDEFINED 10 0 new_shm in amp INPUT_MASK out new_shm drv gt old_out new_shm else if strncmp read_buffer bytes_worked STR_FAILURE 8 0 new_shm in amp INPUT_MASK new_shm 1 lt lt POINT_GET_FAILURE out new_shm drv gt old_out new_shm else out drv gt old_out amp OUTPUT_MASK in else out drv gt old_out amp OUTPUT_MASK in else out drv gt old_out amp OUTPUT_MASK in return 0 Diese Funktion nimmt Nachrichten des Simulators an
43. e CAD System zur Aufnahme eines Gleisnetzes e Konverter Software zur Generierung der Netzgraph Informationen eines Gleisnet zes und Erstellung einer TND Datei 7 2 3 1 Einarbeitung in CAD System Das erste eigentliche Arbeitspaket war die Einarbeitung in das CAD System QCad um dieses sinnvoll zum Zeichnen der zu konvertierenden Gleisnetze einsetzen zu k nnen Das Hauptaugenmerk lag auf dem Erlernen von Techniken mit deren Hilfe man ohne gr eren Aufwand Netzpl ne von Bahnsystemen erstellen kann KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 85 7 2 3 1 1 QCad und die Objekt Bibliothek QCad bietet die M glichkeit sog Bl cke zu definieren welche dann innerhalb einer Zeichnung mehrfach Anwendung finden k nnen im Prinzip also Ausschnittszeichnungen h ufig verwendeter Zeichen Elemente Aus diesem Grund wurde eine Objekt Bibliothek erstellt welche Bl cke f r alle in einem Gleisnetz vorkommenden Elemente also alle Typen von Weichen Signa len Sensoren etc enth lt Durch Einsatz dieser Bibliothek ist es m glich innerhalb des Dateiformates DXF diese Elemente wiederzufinden wodurch das sp tere Einlesen dieser Datei erst auf sinnvolle Weise erm glicht wird Die Bibliothek ist in mehrere Kategorien unterteilt points s mtliche Weichen sen sors s mtliche Sensoren signals s mtliche Signale track normale Kreuzungen und others Eintritts und Ausgangspunkte Markierungen etc Diese Objektbibliothek muss vom Anwender in
44. im BTNB die erhaltenen Informationen in die Klassenstruktur des Simulators der Klas se Simulator eingef gt Mit der Methode getHardware kann der BTNB auf eine HashMap des Simulators zugreifen indem s mtliche Hardware gesammelt wird 01 protected static void addSensor String name String type 02 03 if type equalsIgnoreCase tg sensors 04 getHardware put name new ToggleSensor name 05 06 07 protected static void setCoords String name int coords 08 09 Hardware hw Hardware getHardware get name 10 hw setCoords coords 11 Die erste Methode addSensor macht nichts anderes als ein Objekt vom entsprechen den Typ mit der bergebenen ID zu erzeugen und dieses der HashMap des Simulators hinzuzuf gen Die zweite Methode setCoords ist f r das Setzen der Koordinaten von bereits existenten Objekten zust ndig Zuerst wird die Hardware ber die ID die als Key der HashMap dient geholt und f r diese dann die Koordinaten gesetzt Im BTNB gibt es sehr viele Stellen an denen gecastet wird oder an denen berpr ft werden muss ob die ben tigten Objekte berhaupt existieren Dies ist der Einfachheit halber f r dieses Beispiel an dieser Stelle weggelassen worden 7 8 5 1 5 Fazit Wichtig f r das Projekt TRACS ist an dieser Stelle dass sowohl der Compiler der die TND Datei f r den Steuerinterpreter weiterverarbeitet als auch der Compiler der Simulatorgruppe die gleiche Grammatik einlesen un
45. int stime int shmid Hiermit sind dann die Projektierungsdaten f r den Safety Monitor erzeugt Waldemar Wockenfu 7 4 5 Schnittstellen In diesem Abschnitt sollen die Schnittstellen des tram Compilers erl utert werden Da bei sollen die externen als auch die wichtigsten internen Schnittstellen betrachtet wer den Wobei die externen Schnittstellen in den vorherigen Abschnitten schon genauer betrachtet wurden und hier nur noch einmal kurz erl utert werden Als erste externe Schnittstelle ben tigt der Compiler Eingabedaten Die zweit externe Schnittstelle sind die Projektierungsdaten f r den Steuerinterpreter Als interne Schnittstellen sollen die zentralen Funktionen des Compilers betrachtet werden 7 4 5 1 Eingabedaten Die Eingabedaten die der tram Compiler erh lt bestehen aus einer Textdatei in Form der TND Beschreibung die im Anhang genauer erkl rt wird In Abschnitt 7 4 4 wird genauer auf das Zusammenspiel zwischen Compiler und TND eingegangen Im Prinzip wir die Originale EBNF Beschreibung genommen die in dem Compiler in eine BNF gewandelt wurde Diese wird dann gepr ft und deren Daten in einen Syntaxbaum und eine Symboltabelle geschrieben die das weitere Verarbeiten der Daten erm glichen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 168 7 4 5 2 Zentrale Funktionen Die internen Schnittstellen des Compilers sind seine eigenen Funktionen In den vorhe rigen Abschnitten wurde bereits gezeigt wie der Compiler aus den einge
46. mlich das an der Einfahrt befindliche Element ggf ein Sensor der reagieren muss ermittelt werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 382 7 8 5 2 2 Signalvorausschau der Tram Signale k nnen an allen Linkable Hard ware Elementen vorkommen Da es m glich ist dass mehrere solche Elemente in kurzem Abstand aufeinander folgen muss die Tram in der Lage sein bis hin zu einer bestimm ten Sichtweite die Weite aus der sie garantiert noch zum Halt kommen kann ohne ein Signal zu berfahren voraus zuschauen auch ber mehrere Linkable Hardware Elemente hinweg Dabei muss der Zustand aller innerhalb dieser Sichtweite befindlichen Signale gespeichert und bei Erreichen des jeweiligen Signals entsprechend angehalten falls Stop Signal fr h genug gesehen oder durchgefahren falls Stop zu sp t gesehen oder Signal auf Fahrt werden Dazu wird der folgende rekursive Algorithmus benutzt 01 private boolean checkStop TrackElement te int pos 02 boolean dir int steps int iter bergabeparameter sind aktuelle Kopf Position der Bahn TrackElement Position dar auf Fahrtrichtung au erdem die noch vorauszuschauende Sichtweite steps und die Iterationstiefe iter angegeben als Zweierpotenz z B Rekursionstiefe 0 iter 1 Rekur sionstiefe 2 iter 4 etc s u 03 boolean stop false 04 Hardware hw te getBorders dir 1 0 05 int length te getLength 06 if hw instanceof Linkable 07 Linkable 1 Linkable h
47. oder Ausgangs sensor einer aktiven Route sind m ssen auf Null stehen und bei aktiven Routen muss der Z hler des Eingangssensors gr er oder gleich dem des Ausgangssensors sein zu jedem Sensor also maximal eine Bedingung da ein Sensor auch niemals zu mehreren gleichzeitig aktiven Routen geh ren kann Nach Belegung dieser beiden Strukturen wird dann die Kopie in hw_to_test erstellt wozu folgende Hilfsfunktion eingesetzt wird void copy_mem for hardware_loop 0 hardware_loop lt united_cond_size hardware_loop hw_to_test hardware_loop id united_conditions hardware_loop id for bits_loop 0 bits_loop lt 16 bits_loopt KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 295 Die Funktion hat zwei Hauptschleifen In der ersten werden die in der Struktur united_conditions enthaltenen Werte in die Struktur hw_to_test kopiert Die zweite Schleife nimmt eine Teil Analyse der united conditions Struktur vor und schreibt in die Struktur hw_to_test die Anzahl der einem ID zugeh rigen gesetzten Bits Anschlie end werden mit Hilfe zweier weiterer Funktionen die Daten zur bergabe an das SUT vorbereitet void set_shm_shadow for count_shadow 0 count_shadow lt united_cond_size count_shadow int tmp_id hw_to_test count_shadow id test_shadow tmp_id io ioseparated input hw_to_test count_shadow input for loop_counter 0 loop_counter lt 1000 loop_counter test_shadow
48. struct symtab_entry_t next struct idlist_t u Abbildung 7 39 struct hwmap t typedeflist typedef fillDefinitions typedef typedeflist fillDefinitions Eine typedeflist besteht aus einer typedef oder auch aus mehreren Dies wird durch die Rekursion in der zweiten Regel erm glicht Durch den Aufruf von struct definitions_t fillDefinitions struct definitions_t defs struct idlist_t list werden die Daten in den Syntaxbaum eingetragen Hierfiir ist es fiir den Parser wichtig vorher bereits typedef erkannt zu haben typedef senstype sensdef 1 fillType pointtype pointdef fillTypeQ sigtype sigdef fillType ROUTES routedef MARKS markdef HWCLASSES hwdef CROSSINGS crossdef 3 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 153 Bei typedef handelt es sich um die Beschreibung aller Elemente des Gleisnetzes Wo bei nur eine n her beschrieben werden soll da die Regeln f r die anderen Elemente hnlich aufgebaut sind Ein typedef kann zum Beispiel ein senstype gefolgt von einem Doppelpunkt und einem sensdef mit einem abschlie enden Semikolon sein Unter sens type versteht man die verschieden Sensortypen die vorkommen k nnen Dies ist in der folgenden Reduktionsregel verankert senstype RRSENSORS TDSENSORS TGSENSORS SDSENSORS SGSENSORS 3 Das hei t da
49. 1 Steuerungssystemausfall XXX 1 1 6 1 1 Stromausfall XXX 1 1 6 1 2 Hardwaredefekt XXX Auswahl der Hardware 1 1 6 1 3 Softwareprobleme z B Absturz Deadlock XXX 1 1 6 2 Nicht alle betroffenen Signale HALT XXX 1 2 Bahnen in entgegengesetzter Fahrtrichtung auf demselben Gleisabschnitt 1 2 1 Bahnen auf entsprechend f hrende Gleise geleitet n gi g2 dst g1 g2 amp amp dst g2 g1 1 2 1 1 Signale so geschaltet dass Bahnen aufeinander zufahren 1 2 1 1 1 St rung eines Signals oder des zu ihm f hrenden Ubertragungsweges 1 2 1 1 1 1 Nichtbefolgen von Schaltanweisungen 1 1 Schaltanweisung wird ignoriert 1 2 Schaltanweisung gelangt nicht zu Signal 1 1 1 2 1 wegen Defekt am Steuersystem XXX 1 1 1 2 2 wegen Defekt auf Ubertragungsweg 144221 2 Eigenm chtige Schaltungen des Signals 1 2 1 1 2 Fehlverhalten des Steuersystems 1 2 1 1 2 1 Fehler in Projektierungsdaten 1 2 1 1 2 1 1 Benutzer gibt falsche Daten ein XXX 1 1 1 1 1 1 1 1 1 1 1 1 1 2 dtl el A 1 2 01 1 1 22 21 1 2 1 Leds KAPITEL 8 SICHERHEITSNACHWEIS 429 1 2 1 1 2 1 2 Netzgraph liefert TND die nicht der Zeichnung entspricht XXX 1 2 1 1 2 1 3 Compiler liefert Bin rdaten die nicht der Eingabe TND entsprechen XXX 1 2 1 1 2 2 Steuersystem gibt eine nicht den Projektierungsdaten entsprechende Anweisung oder unterl sst eine in den Projektierungsdaten geforderte Anweisung 2 1 Hardware Fehler
50. 2 2 2 4 Fehler in Betriebssystem o Systemumgebung XXX 1 3 1 2 2 3 wegen falscher Sensordaten 1 3 1 2 2 3 1 Sensor reagiert nicht auf Bahn 1 3 1 2 2 3 2 Sensor reagiert falsch auf Bahn 1 3 1 2 2 4 falsche Reaktion auf erkannten Sensor Signalausfall oder defekt 1 3 1 2 2 4 1 Sensor Signalausfall oder defekt 1 1 Sensor Signalausfall oder defekt 1 2 Steuersystem schaltet nicht alle betroffenen Signale auf Stop XXX 1 3 2 Bahn berf hrt Stop Signal 2 1 Fehlverhalten des Fahrers 2 2 Bremsendefekt an der Bahn kann nicht anhalten 5 de 3 a BA A 1 3 1 2 2 4 1 3 1 3 KAPITEL 8 SICHERHEITSNACHWEIS 432 1 3 3 unzureichende Signalaustattung des Gleisnetzes Abschnitte nicht zu schiitzen weil kein Signal vorhanden 1 3 4 Signale schlecht sichtbar 4 1 witterungsbedingt d h voriibergehend 4 2 Signale dauerhaft verdeckt 1 3 5 Bahn en bleibt stehen 1 3 5 1 Stromausfall 1 3 5 1 1 Stromausfall in Teilgleisnetz 1 3 5 1 2 Nicht alle betroffenen Signale HALT XXX 1 3 5 1 3 Fehlverhalten des Fahrers zu geringer Sicherheitsabstand 1 3 5 2 defekte Bahnen 1 3 6 Steuerungssystem 1 3 6 1 Steuerungssystemausfall 1 3 6 1 1 Stromausfall XXX 1 3 6 1 2 Hardwaredefekt XXX 1 3 6 1 3 Softwareprobleme z B Absturz Deadlock XXX 1 3 6 2 Nicht alle betroffenen Signale HALT XXX 1 3 1 3 2 Entgleisungen 2 1 zu hohe Geschwindigkeit 2 1 1 Fehlverhalten des Fahrers
51. 4 Fehler in Betriebssystem o Systemumgebung XXX 1 2 1 2 2 3 wegen falscher Sensordaten 1 2 1 2 2 3 1 Sensor reagiert nicht auf Bahn 1 2 1 2 2 3 2 Sensor reagiert falsch auf Bahn 1 2 1 2 2 4 falsche Reaktion auf erkannten BPRPReE eR NNNN Bee Bee NNN 1 2 1 1 2 1 2 1 1 2 tod 2021254 A Qe deb 24s 1 21 251 1 2 17 2 1 fe 2 ak 1 72 21 2 1 1 2 1 2 2 1 2 1 2 2 BPRPReE eR NONNN NY KAPITEL 8 SICHERHEITSNACHWEIS 430 Sensor Signalausfall oder defekt 1 2 1 2 2 4 1 Sensor Signalausfall oder defekt 1 1 Sensor Signalausfall oder defekt 1 2 Steuersystem schaltet nicht alle betroffenen Signale auf Stop XXX 1 2 2 Bahn berf hrt Stop Signal 1 2 2 1 Fehlverhalten des Fahrers 1 2 2 2 Bremsendefekt an der Bahn kann nicht anhalten 1 2 3 unzureichende Signalaustattung des Gleisnetzes Abschnitte nicht zu sch tzen weil kein Signal vorhanden 1 2 4 Signale schlecht sichtbar 4 1 witterungsbedingt d h voriibergehend 4 2 Signale dauerhaft verdeckt 1 2 5 Bahn en bleibt stehen 1 2 5 1 Stromausfall 1 2 5 1 1 Stromausfall in Teilgleisnetz 1 2 5 1 2 Nicht alle betroffenen Signale HALT XXX 1 2 5 1 3 Fehlverhalten des Fahrers zu geringer Sicherheitsabstand 1 2 5 2 defekte Bahnen 1 2 6 Steuerungssystem 1 2 6 1 Steuerungssystemausfall 1 2 6 1 1 Stromausfall XXX 1 2 6 1 2 Hardwaredefekt XXX 1 2 6 1 3 Softwareprobleme z B Absturz Deadlock XXX 1 2 6 2 Nicht
52. 5 3 1 5 Signale Diese Spezifikation gilt f r folgende Arten von Signalen wie im Weltmodell Abschnitt 2 3 beschrieben straight left SL e straight right SR e left right LR e straight left right SLR e straight S e left L e right R Eingabebereich Der Eingabebereich fiir einen Signal Treiber beschreibt den gerade vom Steuerinterpre ter angeforderten Zustand Hierbei wird jede m gliche Anforderung bin r codiert indem jedem einzelnen Bit eine Bedeutung zugewiesen wird Wenn im definierten Eingabe bereich mehr als ein Bit gesetzt ist liegt ein Fehler des Steuerinterpreters oder der Hard ware vor und der Treiber muss in einen Fehlerzustand wechseln s u eine Ausnahme sind REQUEST RECEIVED Anzeigen die zus tzlich zu GO STOP WAIT Anzeigen geschaltet werden k nnen Die folgenden Bits sind f r den Eingabebereich definiert Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 8 Bit 9 Bit 15 Anforderung fiir GO STRAIGHT Anzeige Anforderung fiir GO LEFT Anzeige Anforderung fiir GO RIGHT Anzeige Anforderung fiir STOP Anzeige Anforderung fiir REQUEST RECEIVED STRAIGHT Anzeige Anforderung fiir REQUEST RECEIVED LEFT Anzeige Anforderung fiir REQUEST RECEIVED RIGHT Anzeige Anforderung fiir WAIT STRAIGHT Anzeige Anforderung fiir WAIT LEFT Anzeige Anforderung fiir WAIT RIGHT Anzeige Anforderung in einen Fehlerzustand zu wechseln und die Ausf hrung zu beenden KAPITEL 7 BESCHREIBUNG
53. 6 3 auf der n chs ten Seite beschrieben Die Validierung der Hardwarebeschreibung wird im Abschnitt 6 4 auf Seite 54 beschrieben e Verifikation der Projektierungsdaten Auf die Sicherheits berpr fung der Projektierungsdaten mit Model Checking wird im Abschnitt 6 5 auf Seite 55 eingegangen e Test Im Abschnitt 6 6 auf Seite 56 werden die Tests der gleisnetzspezifischen Steue rungssoftware erl utert Dies beinhaltet Modultests und Softwareintegrati onstests Die Tests des fertigen Steuerungssystems werden im Abschnitt 6 8 auf Seite 58 erl utert Dazu werden Hardware in the Loop Tests ausgef hrt Wenn diese Schritte erfolgreich ausgef hrt werden ist nachgewiesen dass das Steue rungssystem seine beabsichtigte Aufgabe erf llt Deng Zhou Ruben Rothaupt 6 2 Validierung der TND Netzwerkbeschreibung Die TND Netzwerkbeschreibung wird durch einen Konverter aus dem Netzgraphen er zeugt Der Simulator verwendet einen Parser um die Netzwerkbeschreibung einzulesen und eine Visualisierung des Gleisnetzes zu erstellen Diese Visualisierung wird nun mit der KAPITEL 6 VALIDIERUNGS VERIFIKATIONS UND TESTPROZESS 53 urspriinglichen Gleisnetzdarstellung im Netzgraphen verglichen Wenn die beiden Dar stellungen quivalent sind wurde gezeigt dass der Konverter seine Funktion erf llt hat und die Netzwerkbeschreibung innerhalb der TND auch das tats chlich betrachte te Gleisnetz wiedergibt Wie der Simulator e
54. 7 BESCHREIBUNG DER KOMPONENTEN 398 actToken equals rrrightoff actToken equals rrleftoff actToken equals rrstraightoff return true else return false case 4 if actToken length 4 return false else actToken st nextToken if actToken equals quit return true else return false default return false Diese Methode pr ft den ihr bergebenen String auf Korrektheit bez glich des definier ten Formates Zum Zerteilen des Strings in einzelne Worte wird ein StringTokenizer eingesetzt der bei den blichen Whitespace Zeichen wie Leerzeichen Zeilenumbruch etc trennt F r eine korrekte Anfrage muss der String zun chst einmal aus drei Worten bestehen Das erste davon muss request lauten das zweite muss mit einer 1 2 3 oder 4 beginnen und genau vier Zeichen lang sein und damit eine korrekte ID f r Weiche Signal oder Sensor sein das dritte muss eines der Schl sselworte f r den angeforderten Zustand sein dieser Zustand muss zu dem Grundtyp d h Weiche Signal oder Sensor passen Es wird nicht gepr ft ob ein Element mit der genannten ID berhaupt im simulierten Gleisnetz existiert sondern nur ob die Anfrage in der Form korrekt ist Von der gleichen Bauart ist die Funktion initRequest welche daher hier nicht auf gef hrt wird private synchronized void addRequest String request requestList add request KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 3
55. Arbeitsgruppe Betriebssysteme und verteilte Systeme AGBS Um dem Leser den Einstieg in die Materie zu erm glichen soll in diesem Ka pitel zun chst nach einer kleinen allgemeinen Vorstellung des Projektes ein berblick ber Themenstellung und Hintergr nde des Projekts TRACS gegeben werden Danach folgen die zentralen Arbeitsbereiche des Projekts TRACS mit anschlie enden detaillier ten Einblicken in das Projekt 1 1 Einf hrung in TRACS TRACS war von Oktober 2003 bis September 2005 ein Hauptstudiumsprojekt im Stu diengang Informatik an der Universit t Bremen Ziel solcher Projekte ist es dass Stu denten ber einen Zeitraum von zwei Jahren selbstst ndig eine gegebene Problematik und Aufgabe bearbeiten und l sen Angeboten wurde dieses Projekt von der Arbeits gruppe Betriebssysteme und Verteilte Systeme AGBS betreut wurde es von Dr Jan Bredereke und Dr Ulrich Hannemann Kernthema von TRACS sind sicherheitskritische Systeme Safety Critical Systems ins besondere im Bahnbereich von deren korrektem Verhalten u U Menschenleben abh n gen Dieses Thema erfordert genaue Kenntnisse ber sicherheitstechnische Aspekte der Software Hardware und des Anwendungsgebiets 1 2 Die Dom ne Der Arbeitsbereich Weltmodell lieferte dem Projekt TRACS eine gemeinsame Grund lage in Bezug auf die Umwelt in der die von TRACS entwickelten Controller einmal funktionieren sollen sowie die verwendete Technik Hier wurden alle Annahmen Ab strak
56. CAD System 7 2 2 1 Was ist CAD CAD steht fiir Computer Aided Design Computerunterst tztes Zeichnen Es ist wich tig zwischen CAD Applikationen und einfachen Zeichenprogrammen zu unterscheiden Zeichnungen die in einem CAD System erstellt werden repr sentieren Objekte aus der realen Welt in exakten originalen Abmessungen Die wichtigsten Faktoren einer CAD Zeichnung sind die Genauigkeit und die Ersichtlichkeit aller Details die f r die Produktion des entsprechenden Objektes notwendig sind Mus04 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 83 7 2 2 2 CAD Programm QCad Wir benutzen die CAD Software QCad Version 2 x fiir die Darstellung des Netzgra phen im Projekt TRACS QCad ist ein 2D CAD System der Firma RibbonSoft www ribbonsoft com Das heisst dass alles auf Ebenen projiziert dargestellt wird Trotzdem k nnen nat rlich dreidimen sionale Objekte dargestellt werden Einige 2D Zeichnungen die ein Objekt von verschie denen Seiten darstellen reichen in der Regel aus um das Objekt vollst ndig in Form und Gr e zu definieren Mus04 Dies ist f r die Darstellung des Netzgraphen schon hinreichend QCad ist f r die Betriebssysteme Linux Unix Windows oder Mac OS X verf gbar Au erdem ist QCad Teil der Open Source Bewegung Das bedeutet dass Sie das Pro gramm erweitern k nnen wenn Sie die n tigen Programmierkenntnisse haben Mus04 QCad ist wegen seiner Einfachheit f r jedermann einsetzbar
57. Daher ist in dieser Richtung der Sensor g4126 kein direkter Folgesensor von g4125 Wenn man von Sensor g4126 in Richtung B geht gelangt man zu der Seite Y der Weiche w1018 Von dort kann man geradeaus oder nach rechts weitergehen Wenn man geradeaus weitergeht ist der Sensor g4126 nicht erreichbar Geht man nach rechts weiter wird zun chst die Seite L der Weiche w1019 erreicht Von Seite Y der Weiche w1019 erreicht man Seite A des Sensors g4126 Der Sensor ist also von Sensor g4125 zu erreichen und zwar auf Seite A Eine Bedingung daf r ist allerdings dass die Weiche w1018 nach rechts gestellt ist KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 236 is_reachable g4126 g4125 A g4125 A gt g4023 B return 1 is_reachable g4126 g4125 B g4125 B gt w1018 Y wi018 R gt w1019 L w1018 S gt k2016 A w1019 Y gt g4126 A k2016 B gt k2017 A return A w1018 state RIGHT k2017 B gt w1021 S w1021 Y gt g4128 A return 1 Der relations Block sieht f r das Beispiel folgenderma en aus relations g4023 A entrance g4025 A entrance g4027 A entrance g4023 B x1 g4125 A g4025 B x2 g4129 A g4027 B x3 g4127 A g4126 B exit g4128 B exit g4130 B exit g4125 B w1018 Y w1019 Y g4126 A g4127 B w1020 Y w1021 Y g4128 A g4129 B w1022 Y w1023 Y g4130 A w1018 R w1019 L w1020 R w1021 L w1022 S w1023 S w1018 S k2016 A k2016 D w1019 S k2017 B w1021 S w1020 S k2017 C w1022
58. Diese Textdatei muss hierbei der vom Projekt TRACS entwickelten dom nenspezifischen Beschreibungssprache TND oder Tram Network Description entsprechen Die TRACS TND enth lt hierbei drei verschiedene Typen von Informationen aus denen verschiedene Teile der resultierenden Projektierungsdaten generiert werden Zu unter scheiden sind Informationen ber Gleisnetzelemente Informationen ber einzelne Rou ten und die dabei involvierten Gleisnetzelemente und Konflikte zwischen einzelnen Rou ten 7 4 2 1 1 Elementinformationen Die Beschreibung einzelner Gleisnetzelemente beinhaltet unter Anderem Informationen ber den Typ eines Elementes dessen Ei genschaften sowie zu benutzende Treiber Diese Informationen werden ben tigt um dem TRACS Steuerinterpreter bin re Vorgaben ber Steuerimpulse sowie Sicherheits bedingungen f r das entsprechende Gleisnetzelement machen zu k nnen So gehen unter Anderem im folgenden Beispiel aus den Informationen f r ein Signal s3001 innerhalb der resultierenden Projektierungsdaten bin re Zeitbedingungen und Informationen ber Treiberzugeh rigkeit hervor definitions sr signals s3001 s3002 s3003 s3004 signal properties s3001 wait straight wait right rr straight rr right switchtime 1000 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 137 hardwaremap c1 s3001 s3002 s3003 s3004 7 4 2 1 2 Routeninformationen In der TRACS TND finden sich ben tigte In formationen ber Zugeh rigkeite
59. Dysarz 7 7 1 berblick Zu jeder Entwicklung geh rt auch ein entsprechender Testvorgang Ein Test dient der Qualit tssicherung einer neu erstellten Software Dabei geht es prinzipiell darum das tats chliche Verhalten mittels Testf llen zu untersuchen und die Ergebnisse mit den er warteten Ergebnissen Spezifikation zu vergleichen und zu dokumentieren In diesem Kapitel werden die Testkonzepte und Testvorg nge beschrieben die ein zu verl ssiges Funktionieren des TRACS Steuersystems gew hrleisten Das Konzept um fasst automatische Testgenerierung aus der Anfangsspezifikation sowie Testausf hrung und auswertung mit Hilfe des RT Testers ein Testwerkzeug das von der Firma Veri fied Ver entwickelt worden ist Es ist ein Modell eines Ebenen Tests gebaut worden anhand dessen sind die Tests durchgef hrt worden soweit dazu Zeit vorhanden war Weitere nicht mehr durchgef hrte Tests werden als Konzept beschrieben Marcin Dysarz 7 7 2 Testkonzepte Als Wissensbasis f r die Erstellung folgender Kapitel dienten uns die Papers HPO2 Pel03 HPO3b Pel02 PT02 PZ99 und Ver04 sowie das w hrend der Vorlesungen Testautomatisierung 1 und 2 sowie Safety Critical Systems 1 erworbene Wissen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 256 7 7 2 1 Automatische Testfallgenerierung Um Wiederverwendbarkeit der Testprozeduren f r verschiedene Gleisnetze zu erreichen m ssen die jeweiligen Testf lle f r ein konkretes Gleisnet
60. Ein gangs und Ausfahrtssensor gleich sind in der Nachbedinungsliste entsprechen sperrtimer_abgelaufen Uberpriifung ob der Sperrtimer zu einer Route abgelaufen ist anforderungssignal_zeigen Das zu einer Route zugeh rige Routenanforderungssi gnal zeigen sperrtimer_starten Starten des Sperrtimers setze_phase_naechster_RC bergang zum n chsten Route Controller hasNextRC berpr fung ob der gerade bearbeitete Route Controller der letzte ist Andreas Kemnade 7 5 4 6 Projektierungsdaten In den folgen Abschnitten wird der Aufbau der Projektierungsdaten erl utert und den einzelnen Teilen des Steuerinterpreters zugeordnet 7 5 4 6 1 Vorbemerkung Wenn im folgenden in C Codebeispielen die Arraynotation verwendet wird sind dies keine echten C Arrays sprich Pointer auf das erste Element sondern Inline Arrays die Daten liegen also genau an der Stelle im Speicher wo normal der Array Pointer stehen w rde Diese Inline Arrays werden durch spezielle Delimiter Eintr ge beendet in der Regel ist der entsprechende ID Eintrag negativ Ausnahmen werden entsprechend gekennzeichnet Wenn die Pointernotation verwendet wird so sind diese Zeiger immer als relativ zum Anfang der Projektierungsdaten zu verstehen S mtliche Integerwerte m ssen im Little Endian Format vorliegen Zwischen den einzelnen Abschnitten darf sich eine beliebige Menge an beliebigen Daten befinden so lange die Projektierungsdaten nicht zu gro werden Folgende
61. Ende angekommen ist TE2 gt O 1 2 3 4 1 4 0 TEI gt TE3 gt Abbildung 7 80 Implementierung Skizze eines TrackElements 11 if te getBorders dir 1 0 instanceof Linkable 12 failure Tram moves on unknown hardware element 13 no Linkable Abhangig von der Richtung auf der die Tram auf dem TrackElement unterwegs ist wird das entsprechende Ende des TrackElements geholt Am Ende eines TrackElements befindet sich ein Hardware Element dass das Interface Linkable implementiert an dernfalls bef nde sich dort ein Element welches an dieser Stelle nicht stehen darf und bei der Initialisierung wurde ein Fehler gemacht In diesem Fall muss die Simulation gestoppt werden Methode failure 14 else KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 380 15 1 Linkable te getBorders dir 1 0 16 try 17 te l getNextTE te head false 18 if 1 te getBorders 0 19 dir true 20 else 21 dir false 22 23 if dir true 24 pos 1 25 else 26 pos te getLength 2 27 28 catch NetworkEndException ne 29 if 1 instanceof Sensor amp amp 30 Sensor 1 getIsDeadEnd 31 Ql instanceof Mark amp amp 32 Mark 1 getIsDeadEnd 33 Simulator getInstance 34 handleFailureSI 35 Tram directed to dead end 36 else 37 if this headVanish 38 this vanish true 39 else 40 this headVanish true
62. Kapitel 7 5 4 5 auf Seite 191 implementiert Genau wie beim RD Testorakel wurde dabei der Originalcode nicht wei ter betrachtet um die Erstellung von identischem Code nicht zu provozieren Auf eine Code Wiedergabe kann unserer Meinung nach an dieser Stelle verzichtet werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 291 7 7 5 3 4 Testchecker Auch der Code des Testcheckers soll an dieser Stelle nicht wiedergegeben werden da er von der Vorgehensweise mit dem gezeigten RC Testchecker identisch ist und keine spektakul ren Innovationen aufweisen kann 7 7 5 3 5 Zusammenfassung Die so implementierten Teile der RC Testprozedur mussten dann noch zusammengefiigt werden Auch hier wurde der vom RD bew hrte Ansatz erneut verfolgt Es wurden auch erneut die f r den Bediener hilfreichen Flags und die M glichkeit einzelne Testf lle gezielt zu setzen eingebaut Eine n here Beschreibung f r den Bediener findet sich im Kapitel 7 7 6 auf Seite 298 Arne Stahlbock 7 7 5 4 Safety Monitor An dieser Stelle wird die Implementierung der Testprozeduren f r den Safety Monitor beschrieben Dieser Vorgang sollte in mehreren Etappen erfolgen von denen aber nur die erste vollst ndig die zweite teilweise erledigt wurde e Bestimmung einer sinnvollen Menge von Testf llen anhand der SM Spezifikation e Implementierung der Funktionalit t aus den Projektierungsdaten diese Testf lle f r das spezifische Gleisnetz zu erzeugen und sie in das SUT einzuspei
63. L k2018 A k2018 D w1023 R k2016 B k2017 A k2018 B k2016 C k2017 D k2018 C KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 237 7 6 5 1 3 point properties Block Im point properties Block sind zus tzliche Ei genschaften der Weichen definiert Der Block sieht f r das Beispiel so aus point properties w1018 switchtime 800 w1019 passive switchtime 800 w1020 switchtime 800 w1021 passive switchtime 800 w1022 switchtime 800 w1023 passive switchtime 800 Die Funktion active gibt an ob die jeweilige Weiche eine Aktiv oder eine Passivweiche ist und breakable bzw fallback geben an ob die Weiche die Eigenschaft BREAK A BLE bzw FALLBACK besitzt Hat die Weiche die Eigenschaft FALLBACK dann gibt fallback_direction die vordefinierte Richtung zur ck Diese Funktionen sind wie folgt definiert active p Psa Bool breakable p Pe Bool fallback p Pet Bool fallback_direction p Pset Integer 7 6 5 1 4 signal positions Block Im signal positions Block wird definiert wo sich die Signale befinden Dies sieht f r das Beispielgleisnetz folgenderma en aus signal positions s3013 g4023 B x1 g4125 A s3014 g4025 B x2 g4129 A s3015 g4027 B x3 g4127 A Die folgende Funktion gibt f r ein Signal s S und einen Sensor g Gset an ob sich das Signal an der Seite side vor dem Sensor befindet signal_be fore s Sset X g Get X side
64. Mustun A QCad Benutzerhandbuch RibbonSoft Winterthur Schweiz 2004 http www ribbonsoft com qcad manual_reference de PELESKA J Formal Methods for Test Automation Hard Real Time Tes ting of Controllers for the Airbus Aircraft Family In Proceedings of the Sixth Biennial World Cobference on Integrated Design and Process Technology IDPT02 Pasadena Kalifornien USA 2002 PELESKA J Automated Testsuites for Modern Aircraft Controllers In Methoden und Beschreibungssprachen zur Modellierung und Verifikation von Schaltungen und Systemen Seiten 1 10 Shaker Aachen 2003 PELESKA J D GROSSE A E HAXTHAUSEN und R DRECHSLER Au tomated Verification for Train Control Systems In SCHNIEDER E und G TARNAI Herausgeber Formal Methods for Automation and Safety in LITERATURVERZEICHNIS 488 PT02 PZ PZ99 Sun TRA Ver Ver04 Railway and Automotive Systems Braunschweig Germany 2004 Technical University of Braunschweig PELESKA J und A TSIOLAKIS Automated Integration Testing for Avio nics Systems In International Conference on Software Testing ICSTEST Diisseldorf 2002 PELESKA J und C ZAHLTEN Safety Cri tical Systems http www informatik uni bremen de agbs lehre ws0405 scs1 hintergrund safety ps PELESKA J und C ZAHLTEN Test Automation for Avionic Systems and Space Technology Extended Abstract Presented at the Workshop of the GI Working Group Test An
65. Orakel wird eine Test Entscheidung getroffen Software Integrationstests berpr fen die sich gegenseitig beeinflussenden Software Komponenten Dabei werden das Ein und Ausgabeverhalten des Systems sowie Soft ware Komponenten innerhalb des Systems getestet Die Hardware die zu steuernden Komponenten Weichen Signale Sensoren werden hierbei durch sogenannte Stubs si muliert Zum Testen wird die Softwareschnittstelle zur Steuerungssoftware genutzt Hardware Software Integrationstests testen ein Sub System das aus Originalhard ware und integrierter Software besteht Steuerhard und software mit I O Karten in KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 258 Blackbox Form Dies bedeutet von Interesse ist hier das Ein und Ausgabeverhalten der Steuerungssoftware nicht aber das interne Verhalten Die Testumgebung ist hierbei eine Simulation der zu steuernden Komponenten Gleisnetz und die eigene Hardware zur Verarbeitung der Steuerimpulse Als Schnittstelle dienen hier I O Karten durch die der Testling und der Testrechner verbunden sind System Integrationstests testen ein komplettes System innerhalb seiner operatio nalen Umgebung oder einer Simulation davon System Tests werden normalerweise als Blackbox Tests gegen die Systemanforderungen durchgef hrt Schnittstelle f r die Tests sind I O Karten an denen aber die richtige Hardwareelemente Weichen Signale Sen soren angeschlossen werden Marcin Dysarz 7 7 3 Testumgebung Um
66. Programmstruktur TE TE 2 4 HW 2 Kopf lt Param Direction Koordinaten MaxParam TE Ende lt Param Direction Liste FIFO Abbildung 7 67 Programmstruktur f r Bewegungsalgorithmen Die Programmstruktur ist dargestellt in Abbildung 7 67 Die Instanzen der Klasse HW Hardware bilden die St tzpunkte des Gleisnetzes zwischen ihnen existieren gerade Verbindungen TrackElement TE Damit lassen sich zwar keine richtigen Kurven modellieren doch diese Ungenauigkeit spielt f r den Steuerinterpreter und damit auch f r den Simulator keine Rolle Nur Signale sind nicht durch TEs mit den anderen HWs verbunden da keine Route direkt durch ein Signal hindurchgeht Zwar m ssen sie f r eine Interaktion mit der Bahn mit dem Gleisnetz verbunden sein die Bahn muss wissen wo sie halten muss aber das wird nicht f r die KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 344 Bewegung einer Bahn an sich ben tigt und wird deshalb in einem sp teren Kapitel behandelt Ein HW beinhaltet folgende Informationen TE 2 4 Dieses Array von TE beinhaltet die angrenzenden Geradenst cke deren An fang Ende an dieses HW gebunden sind Wenn die Gr e des Arrays gleich 2 ist dann ist dieses HW ein Verbindungsst ck auf einer einzelnen Strecke Wenn die Gr e gleich 3 ist dann handelt es sich bei diesem HW um eine Weiche und beim Index 0 befindet sich das TE auf der stem Seite und bei den anderen Indizes die TEs der branch Seite der Weiche
67. RR Sensor gelangt da f r die Bahn kein Einfluss auf Stellung der Weiche besteht Aus gleichem Grund darf kein Signal dazwischen vorhanden sein Hat die Bahn die Route erfolgreich absolviert und das Netz verlassen wird sie kurz darauf wieder an bereits genannter Einfahrt erscheinen und ihre Route erneut absolvieren Es handelt sich also hier um Bahnen die ihre Routen immer wiederholt befahren e L nge Die L nge gibt an wie lang die Stra enbahn sein soll Es kann eine L nge aus einer Liste ausgew hlt werden e maximale Geschwindigkeit Die maximale Geschwindigkeit gibt an wie schnell diese Stra enbahn maximal fahren kann Es kann eine Geschwindigkeit aus einer Liste ausgew hlt werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 420 e May fail Durch Aktivieren dieser Checkbox setzt der Nutzer die Option dass eine Bahn w hrend des Betriebes ausfallen kann Sie bleibt dann irgendwann stehen an wel chem Ort dies geschieht ist nicht vorhersehbar e Random behavior Eventuell k nnte der Fahrer dieser Bahn sich zum Missachten von Signalen ent schlie en Es folgen die Einstellungen f r Weichen e Stellung Die Stellung der Weiche in der sie zu Beginn der gezielten Simulation sein wird Aus einer Liste kann eine Stellung ausgew hlt werden Die Elemente dieser Liste sind abh ngig von dem Typ der Weiche So ist bei einer LR Weiche nicht die Stellung straight m glich e May fail Durch Aktivieren dieser Chec
68. Signal nicht im Zustand STOP ist In dem Beispiel wird der Sensor g4125 erreicht wenn Sensor g4023 erreicht wurde und das Signal s3013 nicht auf STOP steht H ufig ist ein Sensor von einem anderen Sensor nur erreichbar wenn bestimmte Wei chenstellungen vorliegen In dem Beispielgleisnetz ist der Sensor g4126 z B ereichbar wenn der Sensor g4125 erreicht wurde und die Weiche w1018 nach rechts gestellt ist oder wenn der Sensor g4129 erreicht wurde und die Weiche w1022 nach links gestellt ist g4125_cond case s3013 state STOP amp g4023 reached 1 1 0 esac g4126_cond case w1013 state RIGHT amp g4125 reached 1 w1022 state LEFT amp g4129 reached 1 1 22 05 esac g4127_cond case KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 249 s3015 state STOP amp g4027 reached 1 1 0 esac g4128_cond case w1018 state STRAIGHT amp g4125 reached 1 w1020 state RIGHT amp g4127 reached 1 T 0 esac g4129_cond case s3014 state STOP amp g4025 reached 1 1 0 esac g4130_cond case w1020 state STRAIGHT amp g4127 reached 1 w1022 state STRAIGHT amp g4129 reached 1 1 2305 esac 7 6 6 5 Verschlusstabellen 7 6 6 5 1 conflicts Block Zun chst soll der conflicts Block berpr ft werden In diesem sind bekanntlich die Routenkonflikte definiert die zu Kollisionen f hren k nnen Die Bedingung safe1 beinhaltet die drei folgenden allgemeinen Sicherheitsbedingungen die gel
69. T h ufig an Haltestellen anzutreffen wird von uns mit dem Wait Zustand gleichgesetzt d h anschlie end kommt Go e Weitere evtl existierende Signale werden nicht ber cksichtigt e Haltestellen ein zwischen zwei Sensoren durchgef hrter Halt w rde f r das Steu ersystem das lediglich die Sensorendaten bekommt genauso aussehen wie eine Langsamfahrt zwischen diesen Sensoren da Langsamfahrt grunds tzlich m glich ist ist das Halten an Haltestellen oder anderswo damit bereits abgedeckt e Vorsortierweichen Weichen an denen nach der Aufspaltung in zwei Gleise diese beiden Gleise noch ber eine l ngere Strecke verschlungen sind werden als normale Weichen mit l ngeren Zweigen angesehen e Routen die zwischen Eingangs und Ausgangssensor noch weitere Sensoren ha ben werden ohne diese zus tzlichen Sensoren betrachtet deren Informationen also nicht ausgewertet Arne Stahlbock 2 4 Die Experten 2 4 1 berblick Zur Aufstellung der vorher beschriebenen Weltmodelle musste sich das Projekt viel Wissen ber die Dom ne aneignen Hierzu wurde in der Literatur geforscht aber auch Kontakt zu Firmen die in der Dom ne t tig sind aufgenommen Relativ fr h in der KAPITEL 2 DIE DOMANE 28 Projektzeit wurde Kontakt zu der Bremer Stra enbahn AG aufgenommen und dann ein Treffen mit Vertretern vereinbart um genauere Informationen zu der Dom ne zu erhal ten Auf Basis dieser Informationen konnte man dann mit den Wel
70. TCP IP Protokollfamilie eingesetzt werden soll somit m ssen beide Rechner diese Protokolle kennen Besonders hohe Anforderungen an die Mindestbandbreite existieren nicht Geht man von einer durchschnittlichen Nachrichtenl nge von 30 Zeichen aus nimmt man ferner an dass 100 Hardware Elemente im Gleisnetz existieren und pro Sekunde f r jedes HW Element eine Nachricht gesendet wird so kommt man auf 3000 Zeichen pro Sekunde diese Anforderung wird selbst von heute g ngigen Analogmodems berboten von Ethernet ganz zu schweigen Im Nachfolgenden werden die verschiedenen Richtungen und das Format der Kommu nikation beschrieben 7 8 4 6 1 Eigenschaften der Kommunikation Die Kommunikation ist bidirek tional Vom Steuerinterpreter m ssen ber die Hardware Treiber Anweisungen an die simulierte Hardware abgesetzt werden in umgekehrter Richtung m ssen die HW Elemente Meldungen ber ihren aktuellen Zustand ausgeben e Treiber Simulator Der Steuerinterpreter sendet Anforderungen an Weichen und Signale bestimmte Stellungen einzunehmen Eine Nachricht enth lt demnach eine Kennzeichnung dass es sich um eine Anforderung handelt eine eindeutige Identifikation des angesprochenen Hardware Elements die Angabe der Stellung in die geschaltet werden soll Da der Steuerinterpreter zu jeder beliebigen Zeit Anforderungen senden kann muss auf Seiten des Simulators auch jederzeit eine Empfangseinheit bereitstehen Hier ist ein eigene
71. Taffou Happi Ruben Rothaupt Kapitel 9 Bewertung In diesem Kapitel soll das Projektergebnis und das Zustandekommen abschlie end be wertet werden Dabei sollen auch die aufgetretenen Probleme bei der Planung und der Zusammenarbeit beleuchtet und die wissenschaftliche Leistung herausgestellt werden 9 1 Wissenschaftliche Leistung Dieser Abschnitt soll eine Einsch tzung ber die im Projekt TRACS geleisteten Arbeiten in Bezug auf die Projektvorgaben geben Hierbei dienten die Quellen HP02 HPO3b HPO3a und PGHD04 als Arbeitsbasis Im Folgenden werden die zentralen Konzepte innerhalb dieser Quellen und deren Umsetzung im Projekt TRACS beleuchtet Hierbei werden sowohl nicht umgesetzte Teile der Vorgaben als auch im Rahmen der TRACS Arbeit zus tzlich oder anders umgesetzte Anforderungen an ein Gleisnetzsteuerungssys tem aufgezeigt 9 1 1 Dom nenspezifische Beschreibungssprache Die in HP02 vorgeschlagene dom nenspezifische Beschreibungssprache f r Gleisnetze wurde im Projekt TRACS entwickelt Hierbei stehen in HP02 vier sogenannte Inter locking Tables im Vordergrund die alle notwendigen Informationen enthalten die zum sicheren Steuern aller in einem Gleisnetz definierten Routen wichtig sind Diese Tabel len finden in der vom Projekt TRACS entwickelten Beschreibungssprache Tram Network Description siehe auch 7 1 ihre Entsprechung Zus tzlich werden in der Tram Network Description noch weitere Informationen angegeben w
72. Teil in dem aus der erkannten Grammatik Code generiert wird muss immer manuell geschrieben und angepasst werden Dieser Aspekt dient folglich nicht der Entscheidungsfindung Zusammengefasst l sst sich sagen dass eine Generierung eines Compilers zwar die Kom plexit t des Gesamtprogramms erh ht dies aber zugunsten der Struktur und der ver minderten Fehleranf lligkeit geschieht Seit der Entwicklung der ersten Compiler in den f nfziger Jahren wurden systematische Techniken entdeckt um mit vielen der wichti gen Aufgaben fertig zu werden die sich w hrend einer Compilierung ergeben ASU99 S 2 Viele Techniken wurden seitdem optimiert und es ist fraglich ob es Sinn macht wenn man diese Techniken neu erfindet und einen Compiler komplett selbst schreibt 7 8 4 3 3 Projektinterne Entscheidungsgriinde Au er dem allgemeinen Vergleich der Ans tze m ssen auch projektinterne Entscheidungsgr nde ber cksichtigt werden da es bereits eine Teilgruppe Compiler gibt und diese sich entschlossen hat Lexer und Parser Generatoren zu verwenden n mlich flex als Lexer und bison als Parser Generator Da diese Tools f r C und nicht f r Java Mentwickelt wurden kann die Arbeitsgruppe sie nicht direkt benutzen Aber wenn JFlex und CUP Java Based Constructor of Useful Parsers verwendet werden die sehr stark an ihre C Pendants angelehnt sind dann l sst sich sicherlich Know how der Compiler Gruppe und auch ein Gro teil der Spezifikatio
73. WAIT_STRAIGHT RR_LEFT RR_RIGHT RR_STRAIGHT SWITCHTIME DEFINITIONS SIGNAL_PROPERTIES POINT_PROPERTIES SLIP_SWITCHES RELATIONS CSRELATIONS PSRELATIONS SIGPOSITIONS ROUTEDEFINITIONS CONDITIONS CLEARANCES POINT_CONFLICTS CONFLICTS HARDWAREMAP COORDINATES ENTRANCE EXIT NONE yytext ANHANG A TND GRAMMATIK 455 s L alnum w alnum s alnum r alnum x alnum c alnum k alnum A l Bp nen l p uyn l np gm R digit digit lt gt t n SENSID POINTID SIGID ROUTEID MARKID HWID CROSSID SIDE CROSS_SIDE POINT_SIDE COORD POSINT Ignoriere sonstigen Whitespace ILLEGALTOKEN ANHANG A TND GRAMMATIK 456 A 2 Parsergrammatik der TND Version 3 0 29 4 2005 lt tnd gt lt defblock gt lt typdef gt lt sensdef gt lt senstype gt lt pointdef gt lt pointtype gt lt sigdef gt lt sigtype gt lt routedef gt lt markdef gt lt hwdef gt lt crossdef gt lt sigpropblock gt lt sigpropdef gt lt defblock gt lt coordblock gt lt sigpropblock gt lt ptpropblock gt lt slipswitchblock gt lt relblock gt lt sigposblock gt lt routeblock gt lt condblock gt lt clearblock gt lt ptconfblock gt lt confblock gt lt hwblock gt lt DEFINITIONS gt lt typdef gt lt sensdef gt lt pointdef gt lt sigdef gt lt routedef gt lt markdef
74. Weichen bestehen die in Form einer Kreuzung angeordnet sind Diese Kreuzungen werden in der TND als Slipswitches bezeichnet Eingabebereich Der Eingabebereich f r einen Slipswitch Treiber beschreibt den gerade vom Steuerin terpreter angeforderten Zustand Hierbei wird jede m gliche Anforderung bin r codiert indem jedem einzelnen Bit eine Bedeutung zugewiesen wird Wenn im definierten Ein gabebereich mehr als ein Bit gesetzt ist liegt ein Fehler des Steuerinterpreters oder der Hardware vor und der Treiber muss in einen Fehlerzustand wechseln s u Die folgenden Bits sind f r den Eingabebereich definiert Bit 0 Anforderung fiir GO STRAIGHT Position Bit 1 Anforderung fiir GO BENT Position Bit 15 Anforderung in einen Fehlerzustand zu wechseln und die Ausf hrung zu beenden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 177 Die Bits 2 14 sind nicht definiert und miissen vom Treiber ignoriert werden Ausgabebereich Analog zum Eingabebereich signalisiert der Wert im Ausgabebereich den aktuellen Sta tus der vom Treiber gesteuerten Kreuzung hnlich wie beim Eingabebereich darf auch im definierten Ausgabebereich prinzipiell nur ein Bit gesetzt sein allerdings ist es m glich sowohl einen Positionszustand als auch einen Fehlerzustand gleichzeitig abzu bilden in diesem Fall sind zwei gesetzte Bits erlaubt Die folgenden Bits sind f r den Ausgabebereich definiert Bit 0 aktuelle Position ist STRAIGHT POS Bit 1 aktuelle Position
75. Zusammenhang problematisch sein dass bei Einzelpersonen die Ideen zur L sung der Aufgaben relativ schnell ersch pft sein k nnen und dass vorhan dene Ideen von niemandem hinterfragt kritisch betrachtet werden womit die Gefahr einen falschen Weg einzuschlagen um einiges h her ist als bei mehreren Personen 9 2 6 1 6 Konsummentalit t In einigen F llen muss festgestellt werden dass Pro jektteilnehmer eine zu starke Konsum Haltung an den Tag legten ihnen also im Prinzip immer erst gesagt werden musste was zu tun sei Eigene Ideen wurden nicht oder nur in geringem Ma e entwickelt Au erdem kann eine solche Haltung dazu f hren dass derart eingestellte Teilnehmer die ihnen vorgelegten Konzepte und Ideen mehr oder weniger KAPITEL 9 BEWERTUNG 451 kritiklos hinnehmen da sie froh sind berhaupt Ansatzpunkte zur Arbeit zu haben 9 2 6 1 7 Art und Weise der Kritik Durch die Art und Weise in der zuweilen Kritik vorgebracht wurde erwies sich diese Kritik nicht immer als f rderlich Beispiel Wenn auf der einen Seite zu Recht siehe den vorigen Punkt kritisiert wird dass der eine oder andere Teilnehmer eine Konsummentalit t an den Tag legt aber auf der anderen Seite von den Teilnehmern eingebrachte L sungswege als schlecht hingestellt werden weil sie nicht dem Stand der Kunst entspr chen dann muss man sich fragen was eigentlich berhaupt gefordert wird So etwas ist jedenfalls die Motivationsbremse schlechthin und f hrt dazu
76. aber doch Diese Fehler wurden der SI Gruppe gemeldet und von ihr behoben so dass der RD nunmehr keine bekannten Fehler mehr aufweist Arne Stahlbock 7 7 6 3 Route Controller 7 7 6 3 1 Ausf hrung Um den RD Test durchf hren zu k nnen muss zun chst die Datei RTC test specs director rts angepasst werden Relativ am Anfang muss die Zeile const char filename home wolf359 tracs cvs compiler code final pd auf die zu verwendende Projektierungsdaten Datei angepasst werden Am Anfang der Hauptprozedur abstract machine director_main k nnen zudem weitere Einstellungen vorgenommen werden Gesetzt werden k nnen die Werte e debug auf 1 gesetzt erfolgen mehr Ausgaben bei der Generierung der Testf lle e comp_debug auf 1 gesetzt erfolgen mehr Ausgaben beim Vergleich der Outputs von SUT und Orakel e single_test auf 1 gesetzt erfolgt kein kompletter Durchlauf aller Testf lle sondern nur ein einzelner Test KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 302 In dem direkt folgenden Abschnitt k nnen dann die Werte f r diesen einzelnen Test gesetzt werden Beispielhaft k nnte das so aussehen single_gen_rst 1 single_gen_bc 0 single_gen_esc 0 single_gen_phase single_gen_route 8 single_gen_timer single_gen_shadow gt gen_point 7 single_gen_shadow gt gen_point 2 single_gen_shadow gt gen_signal 1 single_gen_shadow gt gen_sensor 102 single_gen_shadow gt gen_sensor 104 Il jo oO oO I O
77. alle betroffenen Signale HALT XXX 1 3 Bahnen sto en in die Flanken 1 3 1 Bahnen auf entsprechend f hrende Gleise geleitet n g g1 n g g2 dst gl g amp amp dst g2 g crossing gl g2 g3 g4 dst g1 g2 amp amp dst g3 g4 1 3 1 1 Signale so geschaltet dass Flankenkollision m glich 1 3 1 1 1 St rung eines Signals oder des zu ihm f hrenden bertragungsweges 1 3 1 1 1 1 Nichtbefolgen von Schaltanweisungen 1 1 Schaltanweisung wird ignoriert 1 2 Schaltanweisung gelangt nicht zu Signal 1 1 1 2 1 wegen Defekt am Steuersystem XXX 1 1 1 2 2 wegen Defekt auf Ubertragungsweg 1 3 1 2 Eigenmachtige Schaltungen des Signals 1 3 1 1 2 Fehlverhalten des Steuersystems 1 3 1 1 2 1 Fehler in Projektierungsdaten 1 3 1 1 2 1 1 Benutzer gibt falsche Daten ein XXX 1 3 1 1 2 1 2 Netzgraph liefert TND die nicht der Zeichnung entspricht XXX 1 3 1 1 2 1 3 Compiler liefert Bin rdaten die nicht der Eingabe TND entsprechen XXX 1 3 1 1 2 2 Steuersystem gibt eine nicht den Projektierungsdaten entsprechende Anweisung oder unterl sst eine in den Projektierungsdaten geforderte Anweisung Ad Ded 20204 te Wd Ti 25 208 5 1 2 1 2 1 3 1 1 1 1 3 1 1 1 1 3 1 1 3 E 1 1 KAPITEL 8 SICHERHEITSNACHWEIS 431 2 1 Hardware Fehler am Steuersystem XXX 2 2 Treiber Fehler XXX 2 3 SI Fehler XXX 2 4 Fehler in Betriebssystem o Systemumgebung XXX 1 3 1 1 2 3 wegen falscher Sensordaten 3
78. besondere Bedeutung sondern sind nur f r die interne Darstellung der DXF Datei von Relevanz Der Name muss aber eindeutig sein gel 2 as Ee 4 Abbildung 7 19 QCad Werkzeugleiste Blockerstellung Kurven Es ist m glich Kurven zu zeichnen indem mehrere kurze gerade Linien aneinander ge setzt und auf diesen Knotenpunkten einfache Markierungen platziert werden welche nat rlich auch benannt werden m ssen Diese Funktionalit t ist aber nur in der Test Version des Konverters fehlerfrei nutzbar Layer Darstellung Es ist m glich zur besseren bersicht einzelne Elementtypen auszublenden Dazu wur den die einzelnen Elementtypen auf verschiedenen Ebenen Layern erstellt Beim Einf gen eines neuen Elements sollte man sich immer auf der Hauptebene befinden wenn man denn einen sinnvollen Ensatz der Layer Technik sicherstellen will F r die Konver tierung ist dies aber nicht erforderlich sondern lediglich als Hilfestellung bei komplexeren Gleisnetzen gedacht um den berblick zu behalten Auf Details wird hier verzichtet da dies nicht von wesentlicher Bedeutung ist und wir da von ausgehen dass sich der Benutzer mit der CAD Software als solches vertraut macht Informationen zu QCad sind im Internet unter der Adresse www ribbonsoft com zu finden Dort ist zum einen das Programm selbst downloadbar als auch eine Dokumen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 113 tation zu finden 7 2 4 4 Bedienung der Konverter
79. da BISON nur diese versteht Da es bei dem Parser um einen BOTTOM UP Parser handelt wird der Syn taxbaum von den Bl ttern aus zur Wurzel aufgebaut Dies geschieht durch miteinander verkn pfte structs die den Knoten des Baums entsprechen Um hier einen besseren berblick zu gew hrleisten sei hier dennoch die Wurzel als erstes dargestellt tnd defblock coordblock sigpropblock ptpropblockopt slipswitchblockopt relblock sigposblock routeblock condblock clearblock ptconfblockopt confblockopt hwblock syntree makeSyntree KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 150 route struct symtab_entry_t cond_clear struct condclear_t _ struct symtab_entry_t ee next struct condclearlist_t 0 1 struct condclear_t sigpoint struct symtab_entry_t direction int next struct condclear_t Abbildung 7 37 struct condclearlist_t Dies ist der letzte Verarbeitungsschritt des Parsers der alle vorhanden Bl cke schon reduziert hat Diese Bl cke werden nun zu der Wurzel des Syntaxbaums reduziert Die einzelnen Bl cke entsprechen denen der TND deren Name hier nur der bersichtlichkeit gek rzt wurden Da einige Bl cke optional sind tragen sie als Konvention opt am Ende ihres Namens Mit dem Aufruf der folgenden Funktion werden die einzelnen Bl cke an die richtige Stelle des Syntaxbaums hinzugef gt struct section_t makeSyntree struct definitions_t definitions struct slipswitch_t slipswitches s
80. dann wenigsten berhaupt mal Hardware h tte um sie anzusteuern Diese M glichkeiten wurden im Projekt nicht ausprobiert Um reale Weichen anzusteuern br uchte man noch weitere Elektronik 7 5 3 2 1 Beispiel f r eine PCI IO Karte Als Beispiel f r eine PCI IO Karte wird die Karte mit der Artikelnummer ADAP37 von Decision Computer vorgestellt Dec Diese Karte hat 48 I O Leitungen und mehrere Timer Ansteuerung Die I O Leitungen k nnen angesteuert werden indem auf die entsprechenden I O Register der Karte zugegriffen wird Die zwei Chips mit der Bezeichnung 8255 haben vier Register wovon eins zur Konfiguration benutzt wird man also einstellt welche Leitun gen als Eingang und welche als Ausgang benutzt werden sollen Die anderen drei Register dienen dann dazu die Leitungen anzusteuern Ins92 S 268ff Auf diese Register kann mit den C Makros inb und outb zugegriffen wird wenn geeignete Zugriffsrechte vorhanden sind Das bedeutet dass man wenn es ausserhalb des Kernels funktionieren soll die entsprechenden IO Bereiche mit ioperm freischalten muss 7 5 3 2 2 Beispiel f r eine USB IO Karte Als Beispiel f r eine M glichkeit durch den USB Ausgang I O Leitungen zu bekom men besteht dazu die Bausteine mit der Bezeichnung IOWarrior der Firm Code Mer cenaries zu benutzen Cod Sie haben bis zu 32 I O Leitungen dabei gibt es spezielle Unterst tzung f r einige serielle Protokolle Ansteuerung Die Ansteuerung k
81. das Verhalten des Steuerinterpreters an das Gleisnetz anzupas sen Der wiederverwendbare Steuerinterpreter bildet daher mit den jeweiligen Projek tierungsdaten zusammen die Software Um das Endprodukt die Steuerungssoftware auf der Zielmaschine zu erreichen muss die Software noch in die verwendete Hardware integriert werden Taffou Happi Deng Zhou Ruben Rothaupt berarbeitet von Andreas Kemnade Kapitel 6 Validierungs Verifikations und Testprozess 6 1 berblick Im Laufe des Projektes wurde immer wieder die Frage gestellt wieso man davon ausge hen kann dass es sicher ist in eine Stra enbahn einzusteigen Hinter dieser Frage steht die Anforderung an die Sicherheit eines Steuerungssystems Wenn beispielsweise ein Signal oder eine Weiche falsch gestellt sind oder ein Signal eine Route freigibt bevor zu der Route geh rige Weichen richtig gestellt sind kann es zu Kollisionen oder Entgleisungen kommen Um zu garantieren dass das Steuerungssystem das gew nschte Verhalten zeigt muss es validiert verifiziert und getestet werden bevor es eingesetzt wird In diesem Abschnitt wird der Prozess beschrieben durch den gew hrleistet wird dass das entwickelte Steuerungssystem sicher ist und es wird dargestellt wie dieser Prozess automatisiert werden kann Das Prinzip der Validierungs Verifikations und Testmethode sieht folgenderma en aus e Validierung stellt sicher dass die Sicherheitszusagen und die Softwarespezifikatio
82. das entsprechende Verzeichnis kopiert werden bzw der Anwender muss in den Programm Einstellungen der CAD Software den Pfad zu dieser Bibliothek als Quelle f r DXF Bibliotheken hinzuf gen s a Ab schnitt 7 2 3 4 Ob diese Bibliothek auch mit anderen zum DXF Format kompatiblen CAD Programmen problemlos genutzt werden kann ist nicht klar da der Netzgraph gruppe nur das Programm QCad zur Verf gung stand Wie diese Einbindung in QCad erfolgen kann wird im Handbuch f r die Netzgraph Konverter Tools beschrieben Abbildung 7 2 zeigt ein kleines Beispiel f r ein mit der DXF Objekt Bibliothek ge Abbildung 7 2 Beispiel eines mittels der QCAD Objekt Bibliothek erstellten Teilgleis plans KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 86 zeichnetes Gleisnetz Anmerkung Die fiir dieses und die weiteren Beispiele verwendete Objekt Bibliothek ist mittlerweile veraltet Die Unterschiede sind allerdings nur margi nal so dass hier keine neuen Grafiken angefertigt wurden Um die Ubersichtlichkeit und Darstellbarkeit von gro en Gleisnetzen in der CAD Soft ware zu verbessern haben wir uns dazu entschieden die verschiedenen Arten von Ele menten auf verschiedenen Ebenen Layern darzustellen welche bei Bedarf ein und ausgeblendet werden k nnen Es ist also m glich nur die Gleisansicht zu betrachten und bei Bedarf Sensoren und Signale ein oder auszublenden Dies erleichtert unserer Ansicht nach die Erstellung von solchen Gleispl nen da so
83. dass das Treiberframework und der SI gestartet wurde 7 5 4 3 Safety Monitor In Abbildung 7 41 wird der Safety Monitor in einem Statechart dargestellt Der Safety Monitor iiberpriift ob der aktuelle Zustand und der vom RC gelieferte Sollzustand einem der in den Projektierungsdaten aufgelisteten sicheren Zust nden entsprechen Ist das der Fall werden die Anforderungen vom RC weitergeleitet andernfalls werden alle Signale auf Wait gesetzt Im folgenden werden jeweils die Eingangsdaten die Ausgangsdaten und die einzelnen Funktionen beschrieben 7 5 4 3 1 Eingangsdaten e Sollzustand geliefert vom RC als globales int Array Indizes sind die SHM IDs Istzustand vom SHM e Struktur sm_data_t aus den Projektierungsdaten KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 7 5 4 3 2 Ausgangsdaten 188 e Sollzustand Bereich im SHM wo er von den Treibern dann weiterverarbeitet wer den kann Safety Monitor E init Wartephase istSicher amp amp timeouts leiteWeiter setzePhase RD grundstellAnforderung reboot setzePhase RD Stable Safe istSicher tinyeouts sperreGleisnetz Abbildung 7 41 Safety Monitor Transitionssystem 7 5 4 3 3 Funktionen istSicher pr ft ob der aktuellen Zustand in der Liste sicherer Zust nde enthalten ist oder ob es Sollzustandsanforderungen f r Elemente gibt deren Sollzust nde nicht mit den Istzust nden bereinstimm
84. dass ein Projekt zum Stillstand kommt Nicht jede Standard Methode ist immer die beste Methode um ein Problem zu l sen 9 2 6 1 8 Zu sp t aufgestellter Zeitplan Eine Zeitplanung wurde erst im Laufe des zweiten Semesters begonnen Ein wesentlich besserer Zeitpunkt w re irgendwann im ersten Semester gewesen Eventuell w re dies deutlicher geworden h tte man zu Anfang die Grundlagen in Form eines EVP gelegt 9 2 6 1 9 Mangelndes Interesse am Zeitplan Ein wesentliches Problem bei der Zeitplanung war das mangelnde Interesse an einem solchen Plan seitens eines gewissen Teils der Teilnehmer Es wurden von den entsprechenden Arbeitsgruppen entweder gar keine oder unge naue Angaben zu den Arbeitspaketen gemacht so dass nahezu jeder Zeitplan bei der Ver ffentlichung eigentlich schon wieder hoffnungslos berarbeitungsbed rftig war Interessant auch die unverst ndliche Einstellung einiger Gruppen dass man die Grup penst rke nicht auf die veranschlagte Zeit umrechnen k nne Damit waren konsistente Zeitangaben schlicht unm glich 9 2 6 1 10 Probleme beim Definieren der Arbeitpakete Ein anderes Problem trat bei einigen Gruppen auf die ihre Arbeitspakete nicht definieren konnten So wurden f r Kleinigkeiten mehrere Wochen angesetzt w hrend gr ere Teile f r einen kurzen Zeitraum geplant waren Oder es wurden Dinge in mehrere Pakete aufgesplittet welche eigentlich zusammengeh rten Auch wurde einfach nur ein riesiges nicht n her definiert
85. dem ersten Semester wurde diese Gruppe aufgel st und die Teilnehmer in andere Gruppen eingeteilt Bei den auch in der Folge noch n tigen Anpassungen und Erweite rung dieser Sprache wurde auf ehemalige Gruppenmitglieder zur ckgegriffen 9 2 3 2 Steuerinterpreter Diese Gruppe war daf r zust ndig das eigentliche Steuersystem bzw den generischen Teil desselben herzustellen Dieses generische Steuersystem wird dann in Verbindung mit konkreten Projektierungsdaten zu einem konkreten Steuersystem Zun chst war auch vorgesehen dieser Gruppe die Aufgabe zu geben Hardware zur testweisen An steuerung durch das Steuersystem auszuw hlen bzw zusammenzubauen Arbeitstitel Elektronikbasteleien dieser Teil wurde dann aber mangels Zeit verworfen Ebenso aufgegeben wurde der Ansatz f r das Steuersystem ein spezielles Echtzeitbetriebssys tem zu ermitteln und einzusetzen 9 2 3 3 Test Diese Gruppe war daf r zust ndig das erzeugte Steuersystem mittels Tests auf Kor rektheit zu berpr fen Sp ter wurde diese Gruppe in HWSW Gruppe HWSW steht f r Hardware Software Integrationstest umbenannt 9 2 3 4 Modelchecker Die Modelchecker Gruppe besch ftigte sich mit der Verifikation des Systems Sie ber pr fte die Sicherheitseigenschaften f r die zu steuernden Gleisnetze 9 2 3 5 BSAG Die BSAG Gruppe war im ersten Semester einzig und allein damit besch ftigt mit der Bremer Stra enbahn AG BSAG Kontakt aufzunehmen um Information
86. den Projektierungsdaten nur Route nach Queue vorliegt und das Setzen der gen Werte auf den ersten Testfall geschieht hier Calculate how many test cases we are facing Set the gen_xyz values to first test case printf d Queues found pdata gt rd_data gt max_queues gen_queues int malloc sizeof int pdata gt rd_data gt max_queues max_queues int malloc sizeof int pdata gt rd_data gt max_queues queue_info struct queue_data malloc sizeof struct queue_data pdata gt rd_data gt max_queues for i 0 i lt pdata gt rd_data gt max_queues it gen_queues i 0 count 0 for j 0 j lt pdata gt rd_data gt max_routes j if pdata gt rd_data gt queue_tab j i count J printf Queue d is responsible for d routes n i count queue_info i num_routes count queue_info i route_id int malloc sizeof int count max_queues i count 1 printf It can therefore have d different test states n max_queues i total max_queues i gen_queues i 0 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 282 count 0 for j 0 j lt pdata gt rd_data gt max_routes j if pdata gt rd_data gt queue_tab j i queue_info i route_id count j count max_rst pow 2 pdata gt rd_data gt max_routes printf There are d routes nThe RST has d test states n pdata gt rd_data gt max_routes max_r
87. der Eintrag der Idlist hinzugef gt Das Nichtterminal een steht f r m gliche Gleisnetzbegrenzer anstelle einer zweiten Seitenangabe KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 159 een ENTRANCE EXIT NONE Als nachstes soll gezeigt werden wie der Signal Positions Block ausgewertet wird sigposblock SIGPOSITIONS sigposdeflist 3 Wie bei den anderen Bl cken wird auch hier das entsprechende Schl sselwort erkannt das von einer sigposdeflist in geschweiften Klammern gefolgt wird Diese sigposdeflist kann aus einer oder mehreren sigposdefs bestehen was wie folgt bewerkstelligt wurde sigposdeflist sigposdef makeSigposList sigposdef sigposdeflist makeSigposList Durch den Aufruf von makeSigposList werden die Signal Psitions zu einer Liste zu sammengeftigt Dabei bekommt diese Funktion jeweils die Adresse des neuen Eintrags und die Adresse der bereits vorhandenen Liste bergeben Zu der sigposdef kann dann folgenderma en reduziert werden sigposdef SIGID sensid_side MARKID sensid_side makeSigpos SIGID sensid_side makeSigpos 3 Als erstes kommt die zugeh rige Id des Signals mit seiner sensidside und gegebenen falls einer MARKID und einer folgenden sensidside Fie Funktion makeSigpos erstellt einen einzelnen Signal Position Eintrag Dabei werden hier der Bezeichner des Signals Die Adresse des ersten Sensors mitsamt Seitenangabe
88. der Skizze F r das Zeichnen eines Abschnittes wurde folgende Hilfsmethode implementiert public void drawTram Graphics g int type int xHead int yHead int xTail int yTail int width Die Methode erwartet als Parameter den Grafikkontext g die x und y Koordinaten des Anfangs dieses Abschnittes in Fensterkoordinaten xHead yHead die beiden Koordi naten des Endes dieses Abschnittes xTail yTail in Fensterkoordinaten und width die Breite der Tram im Fenster Interessant ist auch der Parameter type dieser gibt an ob es sich um denjenigen Abschnitt der Bahn handelt der den Kopf beinhaltet oder einen anderen Abschnitt Die Methode liefert nichts zur ck sondern zeichnet direkt im Fenster Graphics2D g2 Graphics2D g g2 setRenderingHint RenderingHints KEY_ANTIALIASING RenderingHints VALUE_ANTIALIAS_ON Als erstes wird der Grafikkontext in eine 2D Umgebung gecastet um mehr Kontrolle besonders ber Geometrie zu erlangen s Sun Klasse Graphics2D Des Weiteren wird Antialiasing eingeschaltet double xDiff xHead xTail double yDiff yHead yTail double radius width 2 double abstand int Math sqrt xDiff xDiff yDiff yDiff double xNeu xTail double yNeu yTail if abstand gt 0 xNeu xDiff abstand radius abstand yNeu yDiff abstand radius abstand Hier wird mathematisch der Punkt 2 aus Abbildung 7 82 auf Seite 390 bestimmt Sowohl x als auch y Koord
89. der Vorgabe eines Anfangsbuchstabens gebildet werden diese dienen sp ter als Bezeichner Au erdem z hlen Ganzzahlen sowie einige Sonderzeichen zum Sprachum fang Als Whitespace gelten Leerzeichen Tabulator und Zeilenumbruch Die komplette lexikalische Grammatik ist im Anhang A 1 auf Seite 453 aufgeschrieben 7 1 3 2 Syntaktische Grammatik und Semantik Die syntaktische Grammatik definiert welche Folgen von Symbolen die ihrerseits also in der lexikalischen Grammatik definiert werden in einer Sprache g ltig sind In der Folge wird die syntaktische Grammatik f r die Sprache TND in EBNF Form dargestellt und erl utert Eine zusammenh ngende und vollst ndige TND ist in den Anh ngen A 1 auf Seite 453 und A 2 auf Seite 456 enthalten Anmerkung Die folgende Beschreibung der EBNF der TND wird anhand von Beispielen verdeutlicht Eine Zeichung des Beispielgleisnetzes ist unter 7 1 zu sehen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 63 Abbildung 7 1 Beispielgleisnetz 7 1 3 2 1 Gesamtaufbau lt tnd gt lt defblock gt lt coordblock gt lt sigpropblock gt lt ptpropblock gt lt slipswitchblock gt lt relblock gt lt sigposblock gt lt routeblock gt lt condblock gt lt clearblock gt lt ptconfblock gt lt confblock gt lt hwblock gt Die TND enth lt verschiedene Bl cke in denen die Beschreibung des Gleisnetzes vor genommen wird Die Reihenfolge dieser Bl cke ist fest vorgegeben dabei sind einige Bl
90. der senstype immer aus einem Schl sselwort besteht der den Sensortypen repr sentiert Die Reduktion zu sensdef ist ein wenig komplizierter sensdef SENSID makeList SENSID sensdef makeList 2 Hierbei kann wieder auch eine Liste von mehrerer Bezeichner fiir den jeweiligen Sensor typen erstellt werden Die Funktion struct idlist_t makeList char struct idlist_t int Fiir Weichen und Signale funktioniert dies analog Bei den Routen Markierungen Hard wareklassen und Kreuzungen ist dies hnlich nur ist bei denen eine Reduktion weniger n tig da es hier nur ein Schl sselwort gibt und nicht noch nach dem genauen Typen geschaut werden mu Das w ren auch alle Regeln f r den Definitionsblock Der zweite Block ist der coordblock Eine Reduktion auf diesen wird durch folgende Regeln erreicht coordblock COORDINATES coorddeflist Der coordblock besteht aud dem hierfiir vorgesehenen Schliisselwort gefolgt von einer in geschweiften Klammern stehenden coorddeflist die es wieder nur erm glicht eine Lis tenstruktur aus mehreren coorddef zu machen Zu einem coorddef kann wiederum nach folgender Regel reduziert werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 154 coorddef elementid coord coord coord fillCoords Sie besteht aus einer elementid und den zugeh rigen Koordinaten Durch den Aufruf von void fillCoords char elem int x int
91. der veranschlagten Dauer bzw dem geplanten Fertigstellungstermin dargestellt Ein sinnvoller Zeitplan besteht also aus einer spinnennetzartigen Verkettung der Pakete und einer zeitlichen Darstellung auf einer Art Zeitschiene Die ersten Versuche einer Zeitplanung wurden im Laufe des zweiten Projektsemesters unternommen Hierf r wurde eine Zeitplangruppe einberufen die aus jeweils einem Ver treter der Arbeitsgruppen bestand Es wurde auch ein Zeitplan aufgestellt der jedoch aus verschiedenen Gr nden schnell wieder berholt war Im Laufe der Zeit wurden neue Zeitplan Revisionen erstellt wieder berholt neu erstellt usw Die Planungsarbeit ver lagerte sich dabei mehr und mehr von der urspr nglichen Gruppe auf einen einzelnen Projektteilnehmer der naturgem allerdings auf die von den Gruppen zu liefernden Angaben angewiesen war 9 2 6 Abschlie ende Bewertung Im Nachhinein muss man feststellen dass das Projekt zwar einige seiner Ziele erreicht hat jedoch nicht alle Es existiert eine dom nenspezifische Beschreibungssprache es existieren in Form des TND Builders der CAD Objektbibliothek und des auf dieser aufbauenden Netzgraph Konverters Eingabetools f r diese Sprache es existiert ein Projektierungsdaten Com KAPITEL 9 BEWERTUNG 449 piler ein Steuerinterpreter ein Simulator Die Projektierungsdaten k nnen mit Model checking Techniken auf ihre Sicherheit gepr ft werden auch Tests wurden in gewissem Umfang durchgef hr
92. die Weiche auffahrbar ist Handelt es sich um eine R ckfallweiche schaltet sie anschlie end wieder in den vorigen Zustand zur ck e Reaktion Bahn Bahn Eine Bahn erkennt den Fall wenn sie auf eine ihr voraus fahrende Bahn auf fahren w rde und kommt vor einer Ber hrung hinter der anderen Bahn zum stehen Sie f hrt anschlie end weiter sofern die voraus fahrende Bahn wei terf hrt Damit soll das Einhalten von Sicherheitsabst nden durch die Fahrer simuliert werden Das Nichteinhalten k nnte nicht durch den SI verhindert werden daher muss dieser Fall nicht ber cksichtigt werden F hrt eine Bahn mit dem Kopf voraus in den Kopf einer anderen Bahn so wird ein Crash erkannt F hrt eine Bahn einer anderen auf einer Weiche oder auf einer Kreuzung in die Seite hinein so wird ein Crash erkannt denn dieser Fall muss nicht vom Fahrer der Stra enbahn vorhergesehen sondern soll vom Steuerinterpreter verhindert werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 318 Eine Bahn fahrt mit gesetzter Route los sobald sie an einer Einfahrt auf das Gleisnetz gelangt Eine Bahn f hrt immer mit konstanter Geschwindigkeit Ausnahme Anhal ten an Signalen oder hinter einer Bahn Variable Geschwindigkeiten oder Halt an Haltestellen werden nicht vorgesehen da letztlich der Steuerinterpre ter nur eine Folge von Sensorenausl sungen als Input bekommt Wichtig ist die Reihenfolge der Ausl sungen nicht die dazwischen lieg
93. die Informationen und damit auch die Rou tennnamen aus der TND gewonnen werden w hrend die Routeninformationen bei der Uberpriifung des Systemmodells aus den Projektierungsdaten kommen VAR route_A route23 route24 route25 route26 route27 route28 no route_B route23 route24 route25 route26 route27 route28 no ASSIGN init route_A init route_B route23 route24 route25 route26 route27 route28 no route23 route24 route25 route26 route27 route28 no next route_A next route_B no no 7 6 6 2 Weichenverhalten Zunachst wird die Modellierung des Weichenverhaltens beschrieben 7 6 6 2 1 Allgemeines Weichenverhalten In dem Modul point wird das Verhal ten beschrieben das fiir alle Weichen gleich ist Als Parameter werden drei Bedingungen iibergeben die angeben ob eine Anforderung existiert die entsprechende Weiche gera deaus nach links oder nach rechts zu stellen Die Variable state repr sentiert den aktuellen Zustand der Weiche und kann die Werte STRAIGHT RIGHT LEFT und UNDEFINED annehmen UNDEFINED dr ckt aus dass die je weilige Weiche noch nicht gestellt wurde Dies ist der Initialzustand einer Weiche Ist nun eine Bedingung zum Umschalten der Weiche erfiillt nimmt diese den entsprechenden Zustand an Ansonsten beh lt die Weiche ihren vorherigen Zustand bei Die Variable point_conflict gibt an ob f r eine Weiche unterschiedliche Weichenstel lungen angefordert wurden Die
94. die SI Spezifikation ber cksichtigt werden sondern nur 2 Die Bahnz hler m ssen nicht variabel belegt werden Da das einzige was der RD mit ih nen machen soll darin besteht sie zu erh hen ihre Ausgangswerte aber nicht betrachtet KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 279 werden k nnen wir hier einen konstanten Wert als Testeingabe verwenden Schlie lich fehlt noch der die Fairness herstellende Z hler wie oft die erste Route ber sprungen wurde Hier muss zwischen zwei Werten variiert werden da von dem Wert bzw dessen Erreichen einer Schwelle eine Entscheidung abh ngt die beiden Testbele gungen sind folglich ein Wert unter und einer ber der Schwelle Mit diesen berlegungen haben wir die Zahl der Testf lle gegen ber dem wirklich kom pletten Durchkombinieren aller m glichen Eingaben bereits deutlich eind mmen k nnen ohne dabei unserer Meinung nach relevante Testf lle auszulassen Auch mit diesen Ein schr nkungen kann ein Testlauf bei einem gro en Gleisnetz noch Stunden dauern und wenn man betrachtet wie schnell man sich auch nur eine Verdopplung der Testf lle einhandeln kann von noch schlimmeren F llen nicht zu sprechen dann bleibt auch nicht wirklich eine Wahl 7 7 5 2 2 Testgenerator Wir generieren die verschiedenen Testf lle indem wir f r jeden zu variierenden Ein gangswert zwei Werte festhalten Einer davon kann als seed bezeichnet werden er cha rakterisiert den gerade f r diese Eingan
95. die in den Projektierungsdaten enthaltenen sicheren Zust nde iteriert F r jeden Zustand werden mehrere Testf lle generiert Einen in dem dieser Zustand gilt und der SM ihn folglich akzeptieren muss und f r jedes einzelne Hardware Element das in diesem Zustand enthalten ist Testf lle die diesen Zustand verletzen und damit unsicher machen falls nicht zuf llig der so ver nderte Zustand seinerseits in der Gesamtliste der sicheren Zust nde vorkommt Einmal w rde der Zustand durch eine Verletzung im real SHM einmal im shadow SHM korrumpiert werden Dadurch ergibt sich als Testabdeckung dass f r jeden in den Sicherheitsbedingungen enthaltenen sicheren Zustand einmal ein entsprechender Zustand hergestellt w rde und dass ebenso f r jede in diesem enthaltene Teil Bedingung Verletzungen generiert w rden So kommt man auf eine gewisse Zahl von sicheren wie unsicheren Zust nden wobei die unsicheren nicht v llig aus der Luft gegriffen sondern wie einzelne Bitkipper aussehen w rden Dar ber hinaus sollten in weiteren Testf llen noch abgelaufene Timer vorgege ben werden so dass auch dieser Bereich gepr ft w rde Marcin Dysarz Arne Stahlbock 7 7 5 4 2 Testgenerator Zu Beginn werden die Projektierungsdaten mit den aus 7 7 5 1 auf Seite 268 bekannten Funktionen eingelesen und einige Datenstrukturen initialisiert Hierzu z hlen diejeni gen die als Eingabe des SUT ben tigt werden sowie einige f r den Checker ben tigte Struktur
96. die jeweilige Weiche bzw das jeweilige Signal ist und ob der jeweilige Sensor ein Route Request Sensor ist Dazu werden die folgenden Funktionen umgesetzt e Typ des Signals Die Funktion signalj ist wie folgt definiert signaliyp SE Sse 5S L R SL SR LR SLR Sie gibt f r ein gegebenes Signal s aus der TND den Typ des Signals zur ck Mit S L R sind hier straight left bzw right gemeint und SR LR SLR repr sentieren die entsprechenden Kombinationen e Typ der Weiche Analog zu der Funktion signalip ist die Funktion pointip folgenderma en definiert Pointyp p Pse SL SR LR SLR e Typ des Sensors Da ein Sensor entweder ein Route Request Sensor oder ein anderer Sensor ist wird die Funktion is_rrsensor als Boolean definiert is_rrsensor g E Gsa Bool Diese Funktion liefert f r einen gegebenen Sensor g true zur ck falls g ein Route Request Sensor ist Ansonsten wird false zur ckgegeben e Kreuzung Es gibt nur einen Typ von Kreuzungen Daher wird keine Funktion ben tigt die den Typ der Kreuzung liefert F r das Beispiel sieht der definitions Block folgenderma en aus KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 235 definitions rr sensors g4023 g4025 g4027 tg sensors g4125 g4126 g4127 g4128 g4129 g4130 sl points w1019 w1021 w1022 sr points w1013 w1020 w1023 sl signals s3014 sr signals s3013 s3015 crossings k2016 k2017 k2018 7 6 5 1 2 rel
97. diese Bl cke die selben Informationen wie die in HPO2 S 4 vorgeschlagene Route Conflict Table 9 1 1 0 7 Point Position Table Um pro Route Informationen dar ber zu haben wie Weichen f r welche Route geschaltet sein m ssen wird in HPO2 S 4 die sogenann te Point Position Table vorgeschlagen In dieser Tabelle wird pro Route f r jede der zu berfahrenden Weichen dieser Route eine Richtung vorgegeben Auch diese Informa tionen finden in der Tram Network Description eine direkte Entsprechung Der Block Conditions enth lt pro Route eine Liste von Weichen mit zugeh riger Richtung f r die se Route Er bildet daher die selben Informationen wie die in HPO2 S 4 vorgeschlagene Point Position Table in textueller Form ab 9 1 1 0 8 Signal Setting Table Analog zu den pro Route ben tigten Weichenstel lungen sind Informationen dar ber notwendig welche Stellung Signale pro zu befahren der Route haben m ssen Diese Informationen werden in der Tram Network Description durch den Block Clearances angegeben Er entspricht in seinen Informationen dadurch der in HP02 S 4 vorgeschlagenen Signal Setting Table 9 1 1 0 9 Zus tzliche Angaben Zur Steuerung eines Gleisnetzes ben tigte das Projekt TRACS mehr Informationen als in HP02 gefordert Daher wurden der Tram Network Description weitere Blocke hinzugefiigt um solche Informationen spezifizieren zu k nnen KAPITEL 9 BEWERTUNG 439 Da zum Steuern einzelner Hardwareelemente eines G
98. ee SS ee MR ES S 135 Ady berbheie an An Eat i Auta bite eo ee ed Ay Bled 135 PAD lt Anlordenineen 4 aie dba hea ae amp See amp Be es 135 CAS Archtekt r 22 22 208 ok Rie esta heran 140 TAA Alkonthmen are eat ie OS A 147 7 4 5 Schnittstellen 3 3 2 Blam be Dar 2 EA es a at ae 167 7 4 6 Systemvoraussetzungen a2 2 24 a BR 169 TAA ACCOMM nase is at aa a Bang arten amp amp 169 TI chellexion deraa eia ne OS ew A eo 170 Steuerinberpreier xp geek eee eS aoe K GAU aoh SRS eh E a 171 al berblick orena a de a eRe A E Sete E Se as Pac 171 2 PARCIILOR LUT a 03 282 2 Mae ede Beh Boel ih fe de eh pide ed 171 7 5 3 Schnittstellen yok Sa 3 EEE ee 174 7 5 4 Spezifikation 2 24 Bhan S ek Pe eet een le 183 7 5 5 Resumee der Zeit Anforderungen 2 200 7 5 6 Reflexion N u 10 re a ee Gre a a a Ned nz 202 Model Checker Ge ee AS ed a 203 1 01 Uperblick ros ee eh Rn A Ee te ena ey a 203 7 6 2 Konzept zur Verifikation der Projektierungsdaten 204 7 6 3 NuSMV New Symbolic Model Verification 2 2 2 207 7 6 4 berpr fung des Systemmodells 22222222 213 7 6 5 Automatische Generierung der Eingabedatei 233 7 6 6 berpr fung der Verschlusstabellen 2 2 22 2222 22 239 TOL Reflexion 2 2 0 Gi ce ae Be are Boe ee Se hee es Sees 252 Hardware Sottware Test ass u an ae rer 255 RL berblick voran 255 tae Lestk nzepte a 25 zu Saas ae een 255 2 78 Lesipmipe bine
99. ein neues Gleisst ck betreten hat In dem Fall kann es zu einer seitlichen Kollision mit einer anderen Bahn gekommen sein s checkCollision Nach den Kollisionspr fungen be handelt doFinish die Reaktionen die evtl durch die Fahrt der Stra enbahn ausgel st wurden Die Anzahl der Schritte die die Stra enbahn noch in dieser Runde f hrt wird um Eins erniedrigt Tram checkStop Diese Methode realisiert die Vorausschau eines Stra en bahnfahrers nach Signalen vor denen er halten muss und die Entscheidung ob er direkt vor einem Haltesignal steht und halten muss Der Algorithmus ist so auf gebaut dass nur bis zum n chsten Hardware Element geschaut wird Da es aber auch sein kann dass der Fahrer auf mehr als ein Signal in seiner Sichtweite achten muss ruft der Algorithmus sich selbst iterativ auf bis er am Ende der Sichtweite angekommen ist Als Parameter werden dieser Methode die Position der Bahn und die L nge der Vorausschau bergeben Ein Durchlauf von checkStop gliedert sich in drei Bereiche die Registration von Stop Signalen der iterative Aufruf und die Entscheidung ob die Stra enbahn in diesem Augenblick anhalten muss Zun chst holt sich die Methoden das Hardware Element auf das die Tram als n chstes fahren wird Dann wird gepr ft ob dieser Hardware ein Signal zugeord net ist Falls Ja wird der Zustand des Signals abgefragt Wenn das Signal etwas anderes als Stop zeigt oder es gar kein Signal gi
100. erf llt TND s Tram Network Description Toggle Sensor Sensor der bei jeder Aktivierung ein Bit an der Schnittstelle zum Steuerinterpreter abwechselnd auf 0 oder 1 setzt TRACS s Train Control Systems Train Control Systems Train Control Systems TRACS ist der Name eines Pro jektes an der Universit t Bremen das im Zeitraum vom Wintersemester 2003 2004 bis zum Sommersemester 2005 von zehn urspr nglich ca 20 Studenten im Hauptstudium durchgef hrt wurde Dieses Projekt besch ftigt sich mit der Entwicklung und Veri fikation von Bahnsteuerungssystemen wie sie in Stellwerken und Z gen zum Einsatz kommen TRA Tram Network Description kurz TND vom TRACS Projekt entworfene DSL die zur Beschreibung von Gleisnetzen dient bersetzer s Compiler Unix ein Computer Betriebssystem Validierung Nachweis dass geforderte Eigenschaften eines Systems gegeben sind ANHANG F GLOSSAR 485 wird durch Untersuchungen erbracht Verified Der Hersteller des RT Testers Ver Verifikation Nachweis dass jedes einzelne Entwicklungsprodukt mit der Spezifikation konsistent ist Verschlusstabellen Diese Tabellen beschreiben die Bedingungen die notwendig sind um die sichere Durchfahrt aller Routen zu gew hrleisten Es gibt folgende Tabellen Point Position Table Route Conflict Table Route Definition Table Signal Setting Ta ble Windows kommerzielles Betriebssystem f r Personal Computer der Firma Micro s
101. ersten Schritt des Einlesevorgangs wird diese Text Datei vom Lexer eingelesen Dieser liest jedes Zeichen einzeln ein und gibt die erkannten Token anschlie end an den Parser weiter Spezifiziert ist das Verhalten des Lexers in der Datei lexer def diese wurde von der Compilergruppe erstellt und von der Simulatorgruppe KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 374 fiir JFlex angepasst aus dieser wird mit JFlex der Lexer Lexer java generiert dabei wird die bei der Parsergenerierung erstellte Datei Sym java ben tigt Nun folgen auszugsweise einige Zeilen aus der Spezifikation des Lexers die f r die lexikalische Analyse der Beispieldatei notwendig sind 01 tg sensors return symbol Sym TGSENSORS yytext 02 definitions return symbol Sym DEFINITIONS 03 coordinates return symbol Sym COORDINATES 04 05 return symbol Sym DOPPELPUNKT o6 return symbol Sym SEMIKOLON OT return symbol Sym KOMMA 08 return symbol Sym GKA 09 return symbol Sym GKZ 10 return symbol Sym KA 114 return symbol Sym KZ 12 13 g alnum return symbol Sym SENSID yytext 14 digit return symbol Sym COORD new Integer yytext 15 16 WhiteSpace Ignoriere sonstigen Whitespace In den Zeilen 1 3 werden Symbole stellvertretend f r die erkannten W rter durch ge reicht Zeile 1 gibt zus tzlich das Wort als String mit da es im Pars
102. f r den Soll und den Istzustand gesetzt und ber eine Bitmas ke maskiert diese Werte werden zusammen mit der zugeh rigen SHM ID gespeichert Als C Struktur struct shm_value int id uint_16_t input uint_16_t input_mask uint_16_t output uint_16_t output_mask Input bedeutet dabei Eingaben vom SI an den Treiber Output bedeutet Ausgabe vom Treiber an den SI Diese Werte sollen so gesetzt werden dass man sie folgenderma en verwenden kann input input amp shm_value input_mask shm_value input_mask amp shm_value input Das ist dann das was in der RC Spezifikation als Ausf hren einer Liste bezeichnet ist Das Testen im RC geschieht dann folgenderma en output amp shm_value output_mask shm_value output amp shm_value output_mask Anmerkung S mtliche Daten m ssen gepackt gespeichert werden Padding ist also nicht erlaubt Die Daten f r einen Route Controller haben folgende Struktur struct rc_data_t int route_id struct shm_value_t point_pos struct shm_value_t free_sig_pos struct shm_value_t lockfirst_sig_pos struct shm_value_t lock_sig_pos KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 196 struct shm_value_t req_sig_pos int entry_sens_id int exit_sens_id i Hierbei werden die Arrays jeweils durch spezielle Delimitereintr ge beendet 7 5 4 6 3 f r den Route Dispatcher Zuordnung Routen zu Queues queue_tab Diese Tabelle dient dazu alle Route Re quest Sensoren
103. geschrieben gefordert Anschlie end muss mindestens ein alpha numerisches Zeichen folgen Die Anzahl ist be liebig wobei aber eben nur Buchstaben a z und Ziffern 0 9 verwendet werden d rfen sonst nichts F r Weichen wird als Anfangsbuchstabe ein w verwendet F r Signale muss ein s f r Sensoren ein g f r Kreuzungen ein k f r Slipswitches q wobei Slipswitches nur in der Test Version unterst tzt werden und f r Markierungen ein x gew hlt wer den Aufgrund eines internen Designs bei Signal Darstellungen sollte man es vermeiden Mar kierungen mit der Anfangs Zeichenkette xs zu verwenden Dasselbe gilt f r Bezeichner mit kq oder wq am Anfang da Slipswitches in Kreu zungen und Weichen aufgel st werden sofern sie unterst tzt werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 112 Signale werden in der sp ter zu generierenden TND Datei auf Markierungen aufgesetzt so dass diese besonderen Markierungen letzlich die ID den Namen des Signals mit einem vorangestellten x als eigene Bezeichnung tragen Sowohl Text als auch zugeh riges Element m ssen markiert werden Danach wird auf das untere schwarze Pfeilsymbol in der Werkzeugleiste siehe auch Abbildung 7 19 geklickt und anschlie end ein beliebiger Bezugspunkt gew hlt Abschlie end wird ein beliebieger Name f r diesen neuen Block gew hlt Der Name und der Bezugspunkt ha ben f r die sp tere Konvertierung keine
104. gt lt elementid gt lt COORD gt lt COORD gt lt COORD gt Jr lt elementid gt lt SENSID gt lt POINTID gt lt SIGID gt lt MARKID gt lt CROSSID gt Im CoordBlock findet die Zuordnung der Hardwareelemente Weichen Signale Senso ren Kreuzungen und Markierungen zu ihren Ortskoordinaten statt Er beginnt mit dem Schliisselwort coordinates und umfasst beliebig viele Koordinaten Definitionen in einem von geschweiften Klammern umfassten Block Eine einzelne Definition enth lt den Bezeichner des Elements gefolgt von einem Doppelpunkt einer ge ffneten Klam mer dann drei jeweils durch Komma getrennte Ganzzahlen geschlossene Klammer und Semikolon Die drei Zahlen sind als x y und z Koordinaten zu interpretieren Der Null punkt des Koordinatensystems muss nicht zwingend gegeben sein da die Koordinaten lediglich dazu dienen die Relation zwischen den einzelnen Elementen darzustellen Als Ma einheit wird Zentimeter angenommen daher erscheinen Integerzahlen als ausrei chend pr zise Das folgende Beispiel w re dann ein mikroskopisches Gleisnetz es dient ja aber auch nur der Verdeutlichung der Notation Koordinaten sind f r alle tats chlich auf am Gleis befindlichen Elemente Sensoren Weichen Kreuzungen anzugeben bei Signalen und Markierungen ist der punktgenaue Standort nur wichtig falls dies f r eine Visualisierung als notwendig erachtet wird Die Koordinatenangaben sind wie folgt zu
105. gt w1018 state UNDEFINED sr3_3 g4127 ctr gt 0 g4127_cond_1 gt w1020 state UNDEFINED 7 6 4 7 4 Vierte Sicherheitsbedingung Wenn eine Weiche von einem Sensor er reichbar ist und sich eine Bahn an dem Sensor befindet dann darf es nicht sein dass eine Anforderung zum Umschalten der Weiche besteht Wenn sich in dem Beispiel eine Bahn an Sensor g4129 befindet darf keine Anforderung eingehen die Weiche w1022 umzuschalten sr4 sr4_1 amp sr4_2 amp sr4_3 sr4_1 g4129 ctr gt 0 g4129 ctr gt 0 g4129_cond_1 amp w1022 state STRAIGHT gt w1022_left amp g4129_cond_1 amp w1022 state LEFT gt w1022_straight sr4_2 g4125 ctr gt 0 g4125 ctr gt 0 g4125_cond_1 amp w1018 state STRAIGHT gt w1018_right amp g4125_cond_1 amp w1018 state RIGHT gt w1018_straight sr4_3 g4127 ctr gt 0 g4127 ctr gt 0 g4127_cond_1 amp w1020 state STRAIGHT gt w1020_right amp g4127_cond_1 amp w1020 state RIGHT gt w1020_straight 7 6 4 7 5 F nfte Sicherheitsbedingung Wenn ein Abschnitt des Gleisnetzes von zwei Eingangssensoren Sensoren die von einem Route Request Sensor erreichbar sind aus entgegengesetzten Richtungen erreichbar ist d rfen die Z hlerwerte dieser beiden Sensoren nicht beide gr er als 0 sein KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 231 Diese Sicherheitsbedingung muss nur beachtet werden wenn es in einem Gleisnetz
106. ist BENT Bit 13 Fehlerzustand OFF Bit 14 Fehlerzustand INVALID Bit 15 Fehlerzustand FAILURE Die Bits 2 12 sind nicht definiert und miissen vom Steuerinterpreter ignoriert werden Die verschiedenen Fehlerzust nde haben folgende Bedeutungen OFF Die Ausf hrung des Treibers wurde beendet es werden keine Anforderungen mehr ausgef hrt INVALID Die letzte Anforderung war ung ltig z B weil Bit 1 und Bit 2 gleichzeitig gesetzt waren FAILURE Ein Hardwarefehler wurde erkannt Der Steuerinterpreter muss auf alle Fehlerzust nde gleich reagieren und den betroffenen Abschnitt gem ss den Sicherheitsbedingungen absperren 7 5 3 1 4 Sensoren Diese Spezifikation gilt f r folgende Arten von Sensoren wie im Weltmodell Abschnitt 2 3 beschrieben Route Request RR Toggle mit Richtung TD Toggle ohne Richtung TG Zustand mit Richtung SD Zustand ohne Richtung SG KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 178 Hierbei existiert f r jede Route ein RR Sensor der immer ausl st sobald die ihm zuge ordnete Route angefordert wird Wenn ein physikalischer Route Request Sensor mehrere Routen ausl sen kann dann muss es daf r f r jede Route einen logischen RR Sensor geben Toggle Sensoren schalten bei jedem Kontakt ihr Toggle Bit um sie k nnen jedoch nicht die aktuelle Anwesenheit eines Zugs berpr fen Zustandssensoren k nnen dies Hat der Sensor eine Richtungserkennung so steht zus tzlich die Information bereit
107. j 0 printf d rcinfo i point j printf n rcinfoli num_signals pdata gt rc_data i num_free_sig single_total pow 56 rcinfo i num_signals rcinfoli signal malloc sizeof int rcinfo i num_signals rcinfoli gen_signal malloc sizeof int rcinfo i num_signals printf Signals for j 0 j lt rcinfo i num_signals j rcinfo i signal j pdata gt rc_data i free_sig_pos j id rcinfolil gen_signallj 0 printf Y d rcinfo i signal j KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 290 printf n printf test cases d n int single_total 1200 total single_total 1200 Die Iteration ber die verschiedenen Testf lle funktioniert wie beim RC Test also etwa increase seed go to next test case gen_rstt if gen_rst max_rst gen_rst 0 j 0 rcinfo rc gen_sensor j 1 while rcinfo rc gen_sensor j max_sensor amp amp j 1 lt rcinfo rc num_sensors rcinfo rc gen_sensor j 0 rcinfo rc gen_sensor j 1 1 jtt if j 1 rcinfo rc num_sensors amp amp rcinfo rc gen_sensor j max_sensor rcinfo rc gen_sensor j 0 j 0 rcinfo rc gen_signal j 1 while rcinfo rc gen_signal j max_signal amp amp j 1 lt rcinfo rc num_signals rcinfo rc gen_signal j 0 rcinfolrc gen_signal j 1 1 jtt 7 7 5 3 3 Testorakel Das Testorakel wurde anhand der RC Spezifikation in
108. ja nein e fiir Weichen und Kreuzungen Information ob und mit welchen anderen Elementen zusammen ein Element eine Kreuzungsweiche bildet e fiir Signale Richtungen die das Signal freigeben kann e fiir Signale Zeit die nach einer Schaltanforderung maximal vergehen darf bis die Schaltung erfolgt ist KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 62 e f r Signale zus tzliche Schaltzust nde die ein Signal einnehmen kann Wartean zeigen A Anzeigen e f r Sensoren Typ des Sensors Toggle Toggle mit Richtungserkennung State State mit Richtungserkennung Route Request e fiir Weichen Signale Sensoren und Kreuzungen letztere nur sofern in Kreuzungs weiche enthalten Information ber die Zugeh rigkeit zu Hardwareklassen um eine Zuordnung herstellen zu k nnen mit welchem Treiber ein jeweiliges Element anzusteuern ist Susanne Spiller Arne Stahlbock 7 1 3 Sprachdefinition der TND Eine typische Sprachbeschreibung besteht aus der lexikalischen Grammatik der syntak tischen Grammatik Typregeln und der Semantik Im Folgenden werden diese Elemente f r die Sprache TND dargestellt 7 1 3 1 Lexikalische Grammatik In der lexikalischen Grammatik wird definiert welche bestimmten Folgen von Einzelzei chen in einer Sprache Symbole bilden F r die Sprache TND ist das relativ unspektakul r es gibt eine gewisse Menge an genau festgelegten Schl sselworten dar ber hinaus k nnen aber auch einige Worte beliebig nur mit
109. kann aus den Projektierungsdaten ebenfalls ein Modell des konkreten Steuersystems ge wonnen werden Modellvorgaben f r m gliche Bahnbewegungen gehen aus dem TRACS Weltmodell hervor in dem entsprechende Voraussetzungen formalisiert wurden Diese drei Teilmodelle ergeben ein Gesamtmodell eines Steuerungssystems mit seiner zu steu ernden Umwelt Das Gesamtmodell ergibt nun einen Zustandsraum welcher in jedem Zustand den Sicherheitsbedingungen gem PGHD04 S 6 11 entsprechen muss Ist dies nicht der Fall k nnen die eingelesenen Projektierungsdaten nicht als sicher ange sehen werden Das Projekt TRACS entschied sich anstatt des in PGHD04 vorgeschlagenen Model Checkers SystemC den Model Checker NuSMV zu nutzen Dies hat aber keinen Einfluss auf das generelle Vorgehen Die Vorgaben aus PGHD04 wurden nur in einem anderen Werkzeug realisiert Informationen zum TRACS Modellvergleich finden sich in Abschnitt 7 6 9 1 4 Automatisierter Test von Steuerungssystemen Ein generiertes TRACS Steuerungssystem bestehend aus TRACS Steuerinterpreter und Projektierungsdaten f r ein Gleisnetz kann mithilfe einer automatisch generierten Test suite auf Sicherheit getestet werden Hierbei diente HP03a als Vorgabe KAPITEL 9 BEWERTUNG 441 Die wiederverwendbaren Komponenten des TRACS Steuerinterpreters Route Dispat cher Route Controller Safety Monitor und Hardware Abstraction Layer werden hierbei durch Modultests auf spezifikationsgem es Verh
110. kaum vermieden werden k nnen da wir keine Erfahrung mit der Implementierung solcher Compiler hatten und den Arbeitsaufwand nicht absch tzen konnten 7 8 8 2 Gruppeninterne Erkenntnisse Wie gut die Arbeit innerhalb der Gruppe funktionierte was gut und was weniger gut bei der Kommunikation lief wird nun folgend dargestellt 7 8 8 2 1 Gruppengr e Die Gruppengr e von vier Personen halten wir f r eine angemessene Anzahl Die Arbeit an den verschiedenen Stellen im Simulator erlaubte eine einfache Aufteilung und bei vier Personen k nnen auch relativ leicht Entscheidungen getroffen und Kompromisse gemacht werden Auch bei Ausfall eines Mitglieds z B aufgrund einer Krankheit l sst es sich mit drei Personen noch gut arbeiten Nach einem Semester jedoch musste die Simulatorgruppe einen R ckgang auf eine Per son hinnehmen Zwei vorige Mitglieder arbeiteten auf den Bachelor Abschluss hin und verlie en das Projekt plangem Diese Situation war aber lange vorher bekannt und daher in der weiteren Zeitabsch tzung auch so ber cksichtigt Kurz nach Beginn des dritten Semesters schied jedoch ein weiterer Teilnehmer aus so dass die Gruppe aus nunmehr einer Person bestand Im Nachhinein betrachtet war diese Situation jedoch nicht sch dlich f r das Vorankommen der Arbeit auch wenn eine gr ere Gruppe sicher lich w nschenswerter gewesen w re Unter Betrachtung der Bedeutung des Simulators f r das Gesamtprojekt konnte diese Gruppengr e
111. loop_counter 4000 sensor_counter united_cond_counter loop_counter counter Diese Funktion besteht aus zwei Schleifen In der ersten werden die Werte die in struct hw_to_test enthalten sind auf test_shadow abgebildet Die zweite Schleife kopiert die Sensorz hler auf das entsprechende test shadow Bereich void set_shm_real for count_real 0 count_real lt united_cond_size count_real int tmp_id hw_to_test count_real id test_real tmp_id gt io ioseparated input hw_to_test count_real input KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 296 for loop_counter 0 loop_counter lt 1000 loop_counter test_shadow loop_counter 4000 sensor_counter united_cond_counter loop_counter counter Diese Funktion hat identischen Aufbau und Funktion wie die obere mit einem Unter schied n mlich dass sie die in struct hw_to_test gespeicherten Werte auf test_real abbildet Die Datenstrukturen die an den Testling zu bergeben sind sind nun belegt so dass der Testling aufgerufen werden kann An dieser Stelle m sste dann auch der Einsatz von Orakel und Checker erfolgen Nach diesem ersten Testfall der mit den Belegungen durchgef hrt wurde die dem si cheren Zustand entsprechen m ssen nun solche generiert werden die diesen Zustand verletzen Dabei wird zun chst das bereits beschriebene copy_mem ausgef hrt um die Kopie in hw_to_test wieder dem Original anzugleichen nach diesem ersten Test
112. lt direction gt lt LEFT gt lt STRAIGHT gt lt RIGHT gt lt CLEARANCES gt lt cleardef gt lt ROUTEID gt lt clearance gt lt clearance gt lt SIGID gt lt direction gt ANHANG A TND GRAMMATIK 458 lt ptconfblock gt lt confdef gt lt confblock gt lt hwblock gt lt hwdefs gt lt hwelid gt lt coordblock gt lt coorddef gt lt elementid gt lt POINT_CONFLICTS gt lt confdef gt lt ROUTEID gt lt ROUTEID gt lt ROUTEID gt lt CONFLICTS gt lt confdef gt lt HARDWAREMAP gt lt hwdefs gt lt HWID gt lt hwelid gt lt hwelid lt SENSID gt lt POINTID gt lt SIGID gt lt CROSSID gt lt COORDINATES gt lt coorddef gt lt elementid gt lt COORD gt lt COORD gt lt COORD gt lt SENSID gt lt POINTID gt lt SIGID gt lt MARKID gt lt CROSSID gt Anhang B DXF Datei Format B 1 Aufbau einer DXF Datei In einer DXF Datei gibt es zwei Typen von Zeilen e eine Zeile welche einen Code liefert welcher als eine Art TAG anzusehen ist der Code ist 1 3stellig und ggf um 1 2 Blanks einger ckt rechtsbiindig e eine Zeile die direkt im Anschluss an die erste folgt und den Wert des TAGS beinhaltet Diese Zeilenpaare m ssen immer als eine Einheit gesehen werden B 1 1 F r TRACS relevante Codes bersicht ber die f r den Netzgrap
113. m glichst korrektes Funktionieren Wert gelegt werden Dies soll gew hrleistet werden indem sowohl bei der Entwicklung des Programms auf einige Aspekte zur korrekten Quellcodeerstellung geachtet werden soll als auch nach der Fertigstellung des Quellcodes ausf hrliche Tests durchgef hrt werden sollen Im Zusammenspiel sollen diese Tests inklusive der darauf folgenden Kor rekturen eine m glichst hohe Fehlerfreiheit des Simulators sicherstellen 7 8 4 7 1 Fehlervermeidung w hrend der Entwicklung Um von vornherein die Anzahl der Fehler im Quellcode m glichst gering zu halten so wie es in den Anforde rungen im Kapitel 7 8 2 5 auf Seite 320 gefordert wurde wird auf eine bersichtliche Datenstruktur im Programm geachtet s S 328 und eine Programmiersprache gew hlt die solche eine Struktur berhaupt erm glicht s S 325 Des Weiteren werden bei der Entwicklung des Simulators folgende Aspekte welche die Korrektheit des Programms f rdern sollen ber cksichtigt e Ausf hrliche Dokumentationen Die Dokumentationen im Quellcode erm glichen einerseits mit Hilfe von Doxygen Dokumente zu erzeugen die die Funktionsweise der einzelnen Klassen Methoden und Variablen erkl ren Andererseits enth lt der Quellcode auch viele Kommenta re die nicht in den von Doxygen generierten Dokumenten auftauchen da sie dem Programmierer helfen sollen den Quellcode zu erweitern bzw zu korrigieren Dies ist wichtig wenn Projektteilnehmer von TRACS am Quel
114. m ssen den Speicherbereich kennen der zur Kommunikation benutzt wird Kon kret hei t das dass jeder Speicherbereich eine eindeutige ID bekommt die der SI und der zugeordnete Treiber kennen 7 5 3 1 1 Schema zu SHM ID Vergabe KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 175 allgemeiner Bereich 1000 9999 Weichen 1000 1999 Kreuzungen 2000 2999 Signale 3000 3999 RR Sensoren 40xx wobei xx die Routen ID ist Sensoren allgemein 4000 4999 Timer 5000 7999 Routen Freigabe Timer 80xx xx ist die Routen ID Routen Sperr Timer 8lxx xx ist die Routen ID 7 5 3 1 2 Weichen Diese Spezifikation gilt f r folgende Arten von Weichen wie im Weltmodell Abschnitt 2 3 beschrieben die sich durch die m glichen Schaltstellungen unterscheiden welche in der folgenden Auflistung angegeben sind e straight left SL e straight right SR e left right LR e straight left right SLR Eingabebereich Der Eingabebereich f r einen Weichen Treiber beschreibt den gerade vom Steuerinter preter angeforderten Zustand Hierbei wird jede m gliche Anforderung bin r codiert indem jedem einzelnen Bit eine Bedeutung zugewiesen wird Wenn im definierten Ein gabebereich mehr als ein Bit gesetzt ist liegt ein Fehler des Steuerinterpreters oder der Hardware vor und der Treiber muss in einen Fehlerzustand wechseln s u Die folgenden Bits sind f r den Eingabebereich definiert Bit 0 Anforderung fiir GO STRAIGHT Position Bit 1 Anforderung fiir
115. mit ihren jeweiligen Seiten genannt werden hei t dies dass die beiden Elemente mit ihren genannten Seiten einander zugewandt sind mithin durch ein Gleisst ck verbunden sind Eine Bahn die das eine Element zu der dort ge nannten Seite hin verl sst wird also als n chstes das zweite Element an dessen genannter Seite erreichen Zwischen den Elementen kann eine Folge von Markierungen vorliegen die auch in der Reihenfolge vom erstgenannten Element zum zweiten angeordnet sind Bei Sensoren gibt es nur zwei Seiten daher ist hier die Bedeutung relativ simpel Eine Bahn die von einer Seite auf einen Sensor f hrt wird ihn an der anderen wieder ver lassen Bei Kreuzungen ist es etwas komplexer diese haben vier Seiten die Bedeutung dieser Seiten ist wie folgt Eine Bahn die eine Kreuzung von Seite A her bef hrt wird an Seite B ausfahren analog sind C und D verbunden F r die Weiche wurden der Anschaulichkeit halber andere Buchstaben gew hlt und zwar sind die bis zu drei Seiten auf der stumpfen Seite mit L S und R bezeichnet f r left straight right die spitze Seite tr gt die Bezeichnung Y Im zweiten Fall dass also ein Sensor mit Seite gefolgt von einer Mark Liste und ei nem der erw hnten Schl sselworte auftritt liegt dort ein Gleisnetzende vor bei leerer Mark Liste direkt an der genannten Seite des ersten Sensors bei nicht leerer Mark Liste an der letzen Mark Die Art des Gleisendes wird durch das Schl sselwort bestimmt ENT
116. ng TNDCreator lt TND File gt 7 2 4 4 4 TracsDXF2TND Die zuvor beschriebenen Schritte sind lediglich f r ein manuelles Debugging sinnvoll Im Normalfall sollte der Konvertiervorgang mit einem einzigen Programmaufruf durchgef hrt werden Dazu gibt es das Programm Tracs DXF2TND java welches alle zuvor beschriebenen Schritte vereint Es werden dem Programm sowohl die DXF Quell Datei als auch die TND Ziel Datei als Parameter bergeben Optional kann noch ein dritter Parameter list angegeben werden welcher das Anzeigen der Elementliste erm glicht Der genaue Aufruf lautet java ng TracsDXFTND list lt DXF File gt lt TND File gt Soll nur die Liste ausgegeben werden aber keine Erzeugung der TND durchgef hrt wer den kann einfach der Parameter f r die TND Datei weggelassen werden Externe Programme welche zur Bearbeitung der TND eingesetzt werden um zum Bei spiel die Routeninformationen hinzuzuf gen sollten eben diesen Befehl einbinden um die DXF Datei mehr oder weniger direkt einzulesen Durch Abfrage des Exit Codes kann eine erfolgreiche Programm Ausf hrung festgestellt werden Ein Exit Code ungleich 0 bedeutet einen Fehler w hrend 0 selbst eine er folgreiche Ausf hrung bedeutet Ein Beispiel Code f r den Aufruf aus einem anderen Java Programm ist hier zu sehen try Runtime rt Runtime getRuntime Process proc rt exec java ng TNDTracsDXF2TND test dxf test tnd InputStream stder
117. oO O we Die hier gesetzten Werte werden dann als seed fiir die jeweiligen Variablen benutzt siehe auch die Beschreibung in 7 7 5 3 auf Seite 287 Was die einzelnen Werte letztlich f r Eingaben bewirken kann man bei Setzen von debug auf 1 erfahren da dann bei der Generierung mehr Ausgaben erfolgen Anmerkung Schlagt ein Testfall fehl werden die f r diesen Testfall verantwortlichen seed Werte ausgegeben damit sie ggf noch einmal gezielt gesetzt werden k nnen Die Indizes bei gen_point sind die Weichen ID minus 1000 bei Signalen entsprechend minus 3000 Sensoren minus 4000 Kreuzungsweichen werden bei den Weichen eingegeben und haben dann Indizes von 1000 aufw rts Es muss jedoch darauf hingewiesen werden dass die Ausf hrung einzelner Testf lle und vor allem die Interpretation ihrer Ausgaben nicht trivial ist und daher nur mit gen gend Hintergrundwissen um die SI Spezifikation und die Testprozeduren sinnvoll ist F r den Laien muss die Ausf hrung der kompletten Testreihe single_test 0 gen gen ist sie erfolgreich so ist der getestete RD in Ordnung schl gt sie fehl so muss er sich mit eben diesem Ergebnis zufriedengeben und zur Ermittlung der Fehlerursache Experten z B TRACS hinzuziehen 7 7 6 3 2 Auswertung Der uns anfangs vorliegende RC wurde mit den Test Gleisnetzen 1 und 2 getestet dabei wurden folgende Fehler zu Tage gef rdert e Es war zwar spezifiziert dass der Eingangssensorz hler zu den Ein und Aus ga
118. regelm igen Abst nden seine Eingabebits Dazu wird der entsprechende Bereich des SHM kopiert um eventuelle Konflikte die durch gleichzeitigen Zugriff von Treiber und Steuersoftwa re eintstehen zu vermeiden Liegt eine ung ltige Eingabedatenkombination vor z B Schaltbefehle die f r den entsprechenden Typ des Hardwareelementes nicht durchf hr bar sind n heres siehe Abschnitt 7 5 3 1 wechselt der Treiber in den Fehlerzustand In jeder Iteration werden au erdem die entsprechenden Bits f r den aktuellen Zustand im SHM gesetzt Der Treiber ergreift Ma nahmen um den Istzustand dem Sollzustand anzupassen Dabei sind erneute nderungen des Sollzustandes verboten solange der Treiber den Istzustand noch nicht angeglichen hat Sind die entsprechenden Bits im Shared Memory gesetzt dann bedeutet das auch dass die Hardware die der Treiber steuert bereit ist eine neue Anforderung entgegenzunehmen 7 5 4 1 1 Aufbau des Treibers Ein Treiber besteht aus einer Initialisierungsroutine und zwei Callback Funktion die vom Treiberframework aufgerufen werden Die Namen der Funktionen m ssen immer mit dem Namen der jeweiligen Treiberklasse beginnen Beschreibung der einzelnen Funk tionen e Treibername_init Initialisierungsfunktion die einmal beim Starten aufgerufen wird KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 184 e Treibername_state_change Diese Funktion wird aufgerufen wenn sich die Va riablen f r den jeweiligen Treiber ge ndert
119. s3015 STOP STOP STOP state amp g4125 ctr amp g4129 amp 84127 state ctr state ctr Es wird eine Invariante safety_monitor definiert die erfiillt ist wenn einer der 14 sicheren Zustande gilt st3 st4 st5 st6 st7 sti1 st12 st13 st2 st10 sti st9 sto sts safety_monitor INVARSPEC safety_monitor 7 6 4 9 Ergebnisse Die hier beschriebene Verifikation wurde f r unsere Teststrecke durchgef hrt Die Test strecke ist im Abschnitt 7 7 4 auf Seite 262 zu finden Dass alle Sicherheitsbedingungen erf llt sind l sst sich f r die Strecken 2 3 und 4 jeweils innerhalb weniger Sekunden nachweisen F r die komplexere Strecke 1 braucht der Model Checker dazu rund f nf Minuten Dabei wurde ein Pentium 4 Prozessor mit 2 6 GHz verwendet Wenn man das Programm so ver ndert dass eine Sicherheitsbedingung nicht erf llt ist wird dies f r jede der vier Strecken vom Model Checker innerhalb einiger Sekunden erkannt und ein entsprechendes Gegenbeispiel erzeugt Ruben Rothaupt Taffou Happi KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 233 7 6 5 Automatische Generierung der Eingabedatei Damit das System mit Model Checking automatisch verifiziert werden kann wird die Eingabedatei des Model Checkers fiir das jeweilige zu steuernde Gleisnetz automatisch generiert Dazu werden bestimmte Informationen verwendet die ben tigt werden um das System zu modellieren Zum Erstellen des phys
120. schaltet nicht alle betroffenen Signale auf Stop XXX 2 4 1 2 Weichen so geschaltet dass Bahnen Bahnen auf nicht auffahrbare Weichen zufahren 2 4 1 2 1 St rung einer Weiche oder des zu ihr f hrenden bertragungsweges 2 4 1 2 1 1 Nichtbefolgen von Schaltanweisungen 2 4 1 2 1 1 1 Schaltanweisung wird ignoriert 2 4 1 2 1 1 2 Schaltanweisung gelangt nicht zu Weiche 2 4 1 2 1 1 2 1 wegen Defekt am Steuersystem XXX 2 4 1 2 1 1 2 2 wegen Defekt auf bertragungsweg 2 4 1 2 1 2 Eigenm chtige Schaltungen der Weiche 2 4 1 2 2 Fehlverhalten des Steuersystems 2 4 1 2 2 1 Fehler in Projektierungsdaten N NNN Bop BOB 2 4 1 1 2 4 2 4 1 1 2 4 1 1 KAPITEL 8 SICHERHEITSNACHWEIS 434 1 Benutzer gibt falsche Daten ein XXX 2 Netzgraph liefert TND die nicht der Zeichnung entspricht XXX 2 4 1 2 2 1 3 Compiler liefert Bin rdaten die nicht der Eingabe TND entsprechen XXX 2 4 1 2 2 2 Steuersystem gibt eine nicht den Projektierungsdaten entsprechende Anweisung oder unterl sst eine in den Projektierungsdaten geforderte Anweisung 2 4 1 2 2 1 2451225221 2 4 1 2 2 2 1 Hardware Fehler am Steuersystem XXX 2 4 1 2 2 2 2 Treiber Fehler XXX 2 4 1 2 2 2 3 SI Fehler XXX 2 4 1 2 2 2 4 Fehler in Betriebssystem o Systemumgebung XXX 2 4 1 2 2 3 wegen falscher Sensordaten 2 4 1 2 2 3 1 Sensor reagiert nicht auf Bahn 2 4 1 2 2 3 2 Sensor reagiert falsch auf Bahn 2 4 1 2 2 4 falsche Rea
121. seed Werte ausgegeben damit sie ggf noch einmal gezielt gesetzt werden k nnen Der Pointer single_gen_queues muss so viele Elemente erhalten wie es Queues in dem Test Gleisnetz gibt Es muss jedoch darauf hingewiesen werden dass die Ausf hrung einzelner Testf lle und vor allem die Interpretation ihrer Ausgaben nicht trivial ist und daher nur mit gen gend Hintergrundwissen um die SI Spezifikation und die Testprozeduren sinnvoll ist F r den KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 301 Laien muss die Ausf hrung der kompletten Testreihe single_test 0 gen gen ist sie erfolgreich so ist der getestete RD in Ordnung schl gt sie fehl so muss er sich mit eben diesem Ergebnis zufriedengeben und zur Ermittlung der Fehlerursache Experten z B TRACS hinzuziehen 7 7 6 2 2 Auswertung Der uns anfangs vorliegende RD wurde mit den Test Gleisnetzen 1 und 2 getestet dabei wurden zwei Fehler zu Tage gef rdert e In zwei aus dem Zustand Route bearbeiten ausgehenden Transitionen verlangte die Spezifikation einen Vergleich von uebersprungene_queues mit anz_queues Hier war in der RD Implementation der Vergleichsoperator falsch die Spezifikation verlangt gt und lt es waren gt und lt implementiert e In der dritten aus Route bearbeiten ausgehenden Transition wenn eine Route freigeschaltet wird wird laut Spezifikation kein Vergleich von uebersprungene_queues mit anz_queues vorgenommen In der Implementation geschah das
122. soll hier jedoch kein ausschlie lich negatives Fazit gezogen werden Gewisse oben bereits genannte Ziele wurden erreicht auch die Dar stellung am Projekttag scheint auf Zustimmung des Publikums gesto en zu sein Einige Wochen vorher war wesentlich Schlimmeres zu bef rchten Henrik R hrup Arne Stahlbock Anhang A TND Grammatik A 1 Lexergrammatik der TND Version 3 0 29 4 2005 rr sensors RRSENSORS td sensors TDSENSORS tg sensors TGSENSORS sd sensors SDSENSORS spe sensors SGSENSORS sl points SLPOINTS sr points SRPOINTS Ir points LRPOINTS slr points SLRPOINTS l signals LSIGNALS s signals SSIGNALS r signals RSIGNALS sl signals SLSIGNALS sr signals SRSIGNALS lr signals LRSIGNALS slr signals SLRSIGNALS routes ROUTES marks MARKS crossings CROSSINGS hwclasses HWCLASSES 453 ANHANG A TND GRAMMATIK 454 straight left right request at passive fallback breakable wait left wait right wait straight rr left rr right rr straight switchtime definitions signal properties point properties slip switches relations cs relations ps relations signal positions routedefinitions conditions clearances point conflicts conflicts hardwaremap coordinates entrance exit none wen l Wah Lee y l ven wy STRAIGHT LEFT RIGHT REQUESTAT PASSIVE FALLBACK BREAKABLE WAIT_LEFT WAIT_RIGHT
123. sp ter von au en aufgerufen wer den sollte Ihr bergeben wird der Dateiname der Projektierungsdaten Datei sowie zwei Pointer auf die Datenstrukturen in denen die Daten abgelegt werden sollten wie be schrieben einmal im Originalformat einmal in unserem erweiterten Format Diese Funktion ruft dann nacheinander Unterfunktionen auf die die einzelnen Abschnit te bearbeiten sollen Sobald irgendwo ein Fehler auftritt wird 1 zur ckgegeben so dass die aufrufende Funktion feststellen kann ob das Einlesen erfolgreich ist Als Beispiel f r eine Unterfunktion w hlen wir die folgende int read_rc_data FILE file struct test_projdata pdata config_data_t sidata int i int j long pos int shm_count int intbuf int malloc sizeof int uint16_t uinti6buf uint16_t malloc sizeof uint16_t KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 273 jump to rc_data_offset if fseek file pdata gt offsets gt rc_data_offset SEEK_SET 0 return 1 J if pdata gt rd_data gt max_routes gt 0 create structs according to number of routes pdata gt num_rc_data pdata gt rd_data gt max_routes pdata gt rc_data struct test_rc_data_t malloc pdata gt rd_data gt max_routes sizeof struct test_rc_data_t sidata gt rc_data malloc pdata gt rd_data gt max_routes sizeof void for i 0 i lt pdata gt rd_data gt max_routes i sidata gt rc_data i struct rc_data_t malloc size
124. state STRAIGHT amp g4127 reached sr2 sr2_1 amp sr2_2 amp sr2_3 sr2_1 g4129 reached amp w1022 state LEFT amp w1018 state RIGHT amp g4125 reached sr2_2 g4125 reached amp w1018 state STRAIGHT amp w1020 state RIGHT amp g4127 reached sr2_3 g4127 reached amp w1020 state STRAIGHT amp w1022 state STRAIGHT amp g4129 reached sr3 1 Jetzt wird angegeben bei welchen Routenkombinationen im conflicts Block ein Konflikt definiert ist F r das Beispiel sieht dies folgenderma en aus conf case route_A route23 amp route_B route26 1 route_A route23 amp route_B route27 1 route_A route23 amp route_B route28 1 route_A route24 amp route_B route26 1 route_A route25 amp route_B route27 1 route_A route26 amp route_B route23 1 route_A route26 amp route_B route24 1 route_A route26 amp route_B route27 1 route_A route27 amp route_B route23 1 route_A route27 amp route_B route25 1 route_A route27 amp route_B route26 1 route_A route28 amp route_B route23 1 1 0 esac Die folgenden beiden Bedingungen dr cken aus dass wenn f r zwei Routen ein Konflikt markiert wurde irgendwo eine Kollison m glich sein muss bzw wenn kein Konflikt markiert wurde keine Kollision m glich sein darf SPEC conf SPEC conf 1 gt AG safei O gt AG safei KAPITEL 7 BESCHREIBUNG DER KOMPONENT
125. unterschiedliche Weise an den Testling weitergereicht ohne dass dies Einfluss auf die Testfallgenerierung hat Ebenso wird fiir Software Integrationstest und Hardware Software Integrationstest nur ein Testchecker ben tigt da auch dieser seine Informationen in abstrakter Form erh lt Zun chst soll nun auf die benutzte Testtheorie sowie die dazu notwendigen Testkompo nenten eingegangen werden bevor deren Anwendung innerhalb der einzelnen Testarten beschrieben wird Helge L ding 7 7 7 1 Spezifikation Die in 7 5 vorgestellte Spezifikation des TRACS Steuerinterpreters bildet in sich noch keine Spezifikation f r einen konkreten Safety Controller da hier insbesondere nicht klar ist welche Anzahl von Routen zu steuern sind Da pro Route ein Route Controller notwendig ist kann dort nur das Verhalten eines einzelnen Route Controllers abstrakt beschrieben werden Zusammen mit der Projektierung eines solchen Steuerinterpreters ergibt sich erst ein konkreter Safety Controller Daraus folgt dass diese Spezifikation zu Testzwecken noch um Projektierungsinformationen erg nzt werden muss Um einen Safety Controller gegen seine Spezifikation testen zu k nnen muss das Test system diese Spezifikation also aus der Spezifikation des Steuerinterpreters und den zugeh rigen Projektierungsdaten f r einen Safety Controller herleiten Hierbei muss aus den Projektierungsdaten ermittelt werden wieviele Routen zu steuern sind und die ab strakte Spezifikati
126. verlassen hat eine andere dann auf dieses Element gelangt was noch als Kollision gewertet werden muss e Riickfallweichen _ Schalten sie nach Uberfahren in die Standardlage zurtick e Weichen und Signale Schalten Werden Schaltanforderungen umgesetzt Werden unm gliche Anweisungen be merkt Wird die Switchtime beachtet nicht quantitativ getestet sondern durch Absch tzen von Gr enordnungen e Treiber Reaktion auf Eingaben Den Treibern wurden Eingaben vom Simulator geschickt es wurde eine Ver nde rung des SHM Zustandes erwartet Umgekehrt wurden SHM Zust nde ge ndert die das Aussenden einer Meldung an den Simulator provozieren sollten Eben so musste die Initialisierung und das Verhalten auf inkorrekte Eingaben getestet werden Hinweis diese Tests sind mit gewisser Vorsicht zu genie en da sie zwar prinzipiell an den in den Treibern verwendeten Algorithmen durchgef hrt wurden die Treiber aber um ohne SI lauff hig zu sein in gewissem Rahmen ver ndert wur den In Realit t sollen die Treiber nicht direkt auf dem SHM arbeiten sondern lediglich auf Kopien die vom Treiberframework des SI geliefert werden im Test wurde auf ein SHM direkt zugegriffen e Kommunikation mit den Treibern DriverRequestServer und StatusSender im Test 7 8 6 3 Gesamttests Gesamttests konnten lange Zeit nur in der Form durchgef hrt werden dass ein Gleisnetz mit mehreren Bahnen betrieben wurde und die Anforderungen entweder per telnet Kons
127. von Name und Element zu gew hrleisten was auch sehr feh leranf llig sein kann wenn man nicht st ndig genau aufpasst Gedrehte Elemente sind ebenfalls einfacher darstellbar vor allem die Koordinaten Neuberechungen und Erkennung von Nachbarschaftsbeziehungen sind in der CAD L sung in diesem Szenario alles andere als simpel Es w rde also der Gro teil an Fehlerquellen wegfallen Au erdem w re ein solches Pro gramm sicherlich einfacher zu implementieren gewesen wobei hier sicherlich die grafische Oberfl che und die Objektbibliothek einen gro en Teil der Zeit beansprucht h tten Ebenso w rde das zuletzt TND Builder siehe auch Abschnitt 7 3 auf Seite 123 genann te Arbeitspaket komplett wegfallen da es in der beschriebenen L sung recht einfach gewesen w re auch die Routen und Hardware Klassen Informationen einzubauen So k nnte es zum Beispiel eine Funktion geben in welcher man alle Elemente einer Route hintereinander anklickt und schon w re die Route als solches komplett Eine in telligente Methode w re ebenfalls denkbar in der einfach nur Start und Endpunkt und ggf wichtige Knotenpunkte f r den Fall dass es mehrere Wege von A nach B gibt markiert werden und so die Route automatisch anhand der internen Daten berechnet wird F r die Hardware Klassen w re eine hnliche Funktionalit t denkbar in der ein fach alle zu einer Klasse geh renden Elemente markiert werden Die Folge w re ein Programm gewesen welches all
128. vorhanden ist KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 70 7 1 3 2 7 RelBlock lt relblock gt lt RELATIONS gt lt reldef gt lt reldef gt lt relation gt lt relnone gt lt relation gt lt elementid side gt lt MARKID gt lt elementid side gt lt relnone gt lt sensid side gt lt MARKID gt lt een gt lt een gt lt ENTRANCE gt lt EXIT gt lt NONE gt lt elementid side gt lt sensid side gt lt crossid side gt lt pointid side gt lt sensid side gt lt SENSID gt lt SIDE gt lt crossid side gt lt CROSSID gt lt cross side gt lt cross side gt lt SIDE gt lt CROSS_SIDE gt lt pointid side gt lt POINTID gt lt POINT_SIDE gt Der RelBlock gibt Nachbarschaftsbeziehungen zwischen Elementen an und beschreibt diesbeziiglich Gleisstiicke Schliisselwort dieses Blocks ist relations Nach bekanntem Muster gibt es dann eine beliebige Anzahl von Relationsbeschreibungen von denen eine einzelne in verschiedenen Formen auftreten kann Ein Element und eine Seitenangabe gefolgt von einem Doppelpunkt bilden den Anfang danach kommt eine evtl leere Lis te von Marks dann ein weiteres Element mit Seitenangabe Eine weitere Form enth lt einen Sensor mit einer Seitenangabe wieder gefolgt von einer ggf leeren Mark Liste dann eines der Schl sselworte entrance exit oder none Bedeutung F r den Fall dass zwei Elemente
129. war ein PC mit einer AMD Athlon CPU und 500 MHz Taktrate sowie einem Hauptspeicher von 256 MB Erfolgreich getestet wurde das System aber auch auf einem Intel Pentium Prozessor mit 166 MHz und 64 MB Hauptspeicher Als Entwiklungsumgebung wurde das Java2 Software Developmentkit J2SDK in der Version 1 4 2 verwendet Eine J2SDK oder J2RE Java2 Runtime Environment der Version 1 4 x der Firma Sun Microsystems Inc sollte auf jeden Fall verwen det werden JavaTM Umgebungen anderer Hersteller wurden nicht getestet und daher in dieser Version nicht unterst tzt Ob die Software auch unter einer anderen Version prinzipiell lauff hig ist wird nicht garantiert QCad wurde in Version 2 0 4 0 www ribbonsoft com verwendet welche zusammen mit dem verwendeten Linux System mitgeliefert wurde Eine Version kleiner 2 x wird nicht unterst tzt da wesentliche Funktionalit ten fehlen Ob auch andere DXF kompatible KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 106 CAD Software wie zum Beispiel AutoCAD nutzbar ist kann nicht klar gesagt wer den da TRACS keine Alternative zur Verfiigung stand Wenn der Funktionsumfang aber mindestens dem von QCad 2 x entspricht und mit einer DXF Element Bibliothek in dem Stil wie sie von QCad verwendet wird gearbeitet werden kann so sollte dies m glich sein 7 2 4 2 2 Installation Es wird davon ausgegangen dass auf dem System sowohl QCad als auch die Java Laufzeitumgebung J2RE bzw die Entwicklungsumgebung J2S
130. werden Das Senden und Empfangen von Stell Auftr gen muss also in einem eigenen Thread ablaufen um ein Blockieren des ganzen Simulators zu vermeiden 7 8 4 9 Hardware Der Simulator wird f r einen handels blichen Einprozessor PC entwickelt Dieser muss ber eine Netzwerkanbindung verf gen damit mit den Treibern und so letztendlich KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 372 dem Steuerinterpreter kommuniziert werden kann Die Alternative ihn auf dem selben Rechner wie den SI auszufiihren stellt sich nicht Mindestanforderungen an Speicher und Prozessor konnten bisher nicht exakt ermittelt werden es bleibt jedoch die Feststel lung dass auch die etwas alteren Rechner im Projektraum bisher keine Schwierigkeiten hatten die ben tigten Geschwindigkeiten zu liefern Silvia Graumann Niklas Polke Arne Stahlbock 7 8 5 Implementierung des Simulators Dieses Kapitel besch ftigt sich mit der Implementierung in der Form dass die wichtigs ten und entscheidenden Stellen im Quellcode sowie diejenigen die beispielhaft f r eine Vielzahl von Stellen stehen beschrieben und erl utert werden Dieses Kapitel enth lt bzw beschreibt also nicht ann hernd die H lfte des gesamten Quellcodes lediglich ausgew hlte Beispiele beschreiben die Umsetzungen von Ausz gen des Konzeptes Fol gendes wird beschrieben e der Einlesevorgang der TND anhand eines kleinen Beispiels e Bewegung Signalvorausschau Auffahren und Kollisions berpr fung
131. werden konnten 7 2 5 7 Gruppen bergreifende Zusammenarbeit Zur Zusammenarbeit mit anderen Teilgruppen ist zu sagen dass es eine direkte Zu sammenarbeit so nicht gab da dies nicht notwendig war da der Netzgraph Konverter ein eigenst ndiges Programm darstellt welches keine direkten Schnittstellen zu anderen Teilen des Projektes hat Es wird lediglich das Produkt einer Konvertierung von anderen Teilgruppen insbesondere von der Komponente TND Builder weiterverarbeitet Das Format des Produktes n mlich die TND ist aber von der DSL Gruppe bereits defi niert worden Hierbei gab es allerdings mit der Zeit st ndige nderungen sodass hier mehr oder weniger eine indirekte Zusammenarbeit mit den entsprechenden Gruppen vorhanden war 7 2 5 8 Alternativer L sungsansatz Abschlie end soll eine alternative L sungsidee f r die Aufgabe der Erfassung eines Gleis netzes und Umsetzung in die TND nicht unerw hnt bleiben Diese Idee kam im Arbeitsbereich Netzgraph auf als immer klarer wurde welche Feh lerquellen von Eingabe der Zeichnung bis zur Konvertierung entstehen k nnen Zu die sem Zeitpunkt war es aber nicht mehr m glich auf diesen L sungsweg umzuschwenken weil zum einen die Zeit nicht mehr ausreichen w rde und zum anderen die Arbeit von fast zweieinhalb Semestern umsonst gewesen w re und quasi nur noch als Program mier bung da stehen w rde Der Frust w re dann sicherlich noch viel gr er gewesen als er es aufgrun
132. werden soll und nach links wenn die Route route26 befahren werden soll w1022_straight case route_A route25 route_B route25 1 1 0 esac w1022_left case route_A route26 route_B route26 1 1 0 esac w1018_straight case route_A route23 route_B route23 1 1 0 esac w1018_right case route_A route24 route_B route24 1 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 245 1 205 esac w1020_straight case route_A route27 route_B route27 1 1 0 esac w1020_right case route_A route28 route_B route28 1 1 2 05 esac 7 6 6 3 Signalverhalten Nun wird die Modellierung des Signalverhaltens dargestellt 7 6 6 3 1 Allgemeines Signalverhalten In dem Modul signal wird das Verhal ten beschrieben das f r alle Signale gleich ist Als Parameter werden drei Bedingungen bergeben die angeben ob eine Anforderung existiert das entsprechende Signal gera deaus nach links oder nach rechts zu stellen Die Variable state repr sentiert den aktuellen Zustand des Signals und kann die Werte STOP STRAIGHT RIGHT und LEFT annehmen Der Initialzustand eines Signals ist STOP Ist nun eine Bedingung zum Umschalten des Signals erf llt nimmt dieses den entspre chenden Zustand an Ansonsten beh lt das Signal seinen vorherigen Zustand bei Bei der Verschlusstabellen berpr fung ist es nicht notwendig ein Signal wieder zur ck auf STOP zu stellen Wann ein Signal auf STOP geste
133. wertet sie aus und falls sie korrekt KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 407 gem dem definierten Format zusammengesetzt sind wird der SHM Zustand bzw dessen Kopie in out entsprechend gesetzt Sind die Nachrichten nicht korrekt werden sie verworfen und nicht weiter beachtet Diese Funktion wird vom Treiberframework des SI periodisch aufgerufen static int driver_point_init struct driver_info drv struct internal_data data struct internal_data malloc sizeof struct internal_data char port 6 char send_buffer 64 struct sockaddr_in sender_addr struct sockaddr_in malloc sizeof struct sockaddr_in sender_addr gt sin_family PF_INET sender_addr gt sin_addr s_addr inet_addr SIM_HOST sender_addr gt sin_port htons SIM_PORT data gt sender_addr sender_addr init_con data strcpy send_buffer STR_INIT sprintf port d drv gt id strcat send_buffer port strcat send_buffer n drv gt private_data data send_msg drv gt private_data send_buffer return 0 In der Init Funktion wird die Verbindung zum Simulator hergestellt und die Init Mel dung an diesen geschickt Daher muss der Simulator zum Zeitpunkt des Treiber Starts bereits laufen der Simulator als Prozess nicht die eigentliche Simulation Die Treiber nutzen insgesamt drei Hilfsfunktionen die mit send_msg recv_msg und init_con bezeichnet werden Diese tun im Wesentlichen das was ihr Name and
134. wird Die Pixelkoordinaten entsprechen denen vom Fenster indem das Gleisnetz ange zeigt werden soll Aus diesen Werten kann man nun die Verh ltnisse berechnen zwischen Welt und Pixel koordinaten zMultiplier und yMultiplier xMultiplier Pxmax Pxmin xmax xmin 7 1 yMultiplier Pymax Pymin ymaz ymin 7 2 Wenn man zum einen alles im Bild haben m chte und zum anderen keine Verzerrung erlaubt dann nimmt man f r beide Koordinaten den kleinsten der beiden Multiplier Multiplier min x Multiplier yMultiplier 7 3 Mit Hilfe von diesem Multiplier der bei einer nderung der Fenstergr e angepasst werden muss kann man nun die Koordinaten umrechnen und zwar folgenderma en pixelCoord weltCoord xmin x Multiplier 7 4 Damit wir keine Elemente direkt am Rand eines Fensters zeichnen miissen wurde be schlossen ein wenig Platz zwischen dem Rand und der Zeichenfl che zu lassen Die Dicke des Randes in Pixel legen wir unter der Konstanten BORDERSIZE fest Fiir die Einbeziehung dieses Randes in die Formeln muss folgendes gemacht werden 1 Prmin und Prmax m ssen angepasst werden 2 x und y Multiplier m ssen neu berechnet und Multiplier neu ausgew hlt werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 360 3 Formel 7 4 muss ge ndert werden Die n tigen nderungen sind in den Formeln 7 5 bis 7 7 zusammengefasst Pxmin Pxmin BORDERSIZE 7 5 Pxmaxr Pxmax BORDERSIZE 7 6 pixelCoord
135. x die Weiche auf das stumpfe Ende von dem die Einfahrt erfolgt um schalten lassen so dass die Bahn die Weiche berfahren kann und an das spitze Ende gelangt wie vor und zus tzlich schaltet die Weiche nach berfahren wieder in die urspr ngliche Stellung zur ck wenn sie vom Typ R ckfallweiche ist Schaltet eine Weiche gerade um w hrend sie befahren wird abgesehen von dem Umschalten durch Auffahren an Weichen die auffahrbar sind kann es zu Entglei sungen kommen Als Schaltzust nde einer Weiche k nnen demnach die m glichen schaltbaren Strecken benannt werden sowie der Zustand gerade keine Strecke ge schaltet Es gibt jedoch eine Vorschrift die besagt dass Weichen w hrend der KAPITEL 2 DIE DOMANE 21 Anwesenheit einer Bahn nicht umschalten d rfen und dagegen eigenst ndig ab gesichert sein m ssen man darf an dieser Stelle aber nicht zwangsl ufig davon ausgehen dass diese weltweit gilt Dar ber hinaus k nnen Weichen defekt sein in diesem Fall kann es zu Entgleisun gen kommen wenn eine Bahn eine defekte Weiche bef hrt Eine Weiche kann eine automatische Schaltvorrichtung haben die auf Anforde rung eine Schaltung vornimmt Als Kenngr e ist hierbei die maximale Schaltzeit zu nennen ist nach dieser Zeit keine Schaltung erfolgt muss die Weiche als defekt angesehen werden Eine Weiche kann aber auch immer unter Einsatz einer Me tallstange manuell umgeschaltet werden Eine Weiche ohne Schaltvo
136. y int z wird das entsprechende Element aus der Symboltabelle herausgesucht und die Koordi naten hierf r in diese eingetragen Da es verschiedene Elementtypen geben kann mu folgenderma en zu elementid reduziert werden elementid SENSID POINTID SIGID MARKID CROSSID 3 Hierbei besteht eine elementid aus dem zugeh rigen Bezeichner f r ein bestimmtes Ele ment Verbleibt nur noch die Reduktion der eigentlichen Koordinaten auf coord Dieses geschieht auf diese Weise coord POSINT NEGINT 3 Wobei POSINT und NEGINT die entsprechenden Werte f r die Koordinaten beinhalten Der Signal Properties Block wird folgenderma en reduziert sigpropblock SIGNAL_PROPERTIES sigpropdeflist 2 Er besteht also aus dem Schliisselwort fiir die Signal Properties gefolgt von einer in geschweiften Klammern stehenden sigpropdeflist Diese ist wiederum folgenderma en aufgebaut sigpropdeflist sigpropdef sigpropdef sigpropdeflist Hierbei wird wieder eine Listenstruktur erm glicht da es eine oder mehrere sigpropdef geben kann Eine sigpropdef kann reduziert werden wenn folgende Regel anzuwenden ist KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 155 Sigpropdef SIGID waitstraightopt waitleftopt waitrightopt rrstraightopt rrleftopt rrrightopt SWITCHTIME POSINT insertSignalProperties 2 Sie besteht also aus einem Bezeichner SIGID und den zugeh rigen Eigenschaften Durch den Aufruf von
137. z B ein schnellerer berblick ber das Schienennetz erlangt werden kann F r die direkte Weiterverarbeitung im anschlie Bend beschriebenen CAD TND Konverter sind die Layer aber nicht notwendig Abbildung 7 3 Gleisnetzzeichnung mit allen Layern Die Abbildung 7 3 zeigt eine Gleisnetzzeichnung mit allen Layern w hrend bei Abbil dung 7 4 auf der n chsten Seite die Sensoren und einige andere Elemente ausgeblendet sind Abbildung 7 5 auf Seite 88 zeigt hingegen nur die Gleise selbst KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 87 Abbildung 7 4 Gleisnetzzeichnung ohne Sensoren und Ein Ausg nge 7 2 3 1 2 DXF Dateiformat Im Laufe des dritten Projekt Semesters wurden noch einige Erweiterungen bzw Modifikationen an der Bibliothek vorgenommen So wur den zum Beispiel im Rahmen der berarbeitung des Weltmodells Kreuzungsweichen hinzugef gt Auch fehlten bisher Einfahrts bzw Ausfahrtspunkte Zur Erleichterung des Erkennens von Nachbarschaftsbeziehungen wurden die bergangspunkte Ein und Ausg nge von z B Weichen entsprechend markiert da es sonst sehr aufw ndig gewesen w re diese innerhalb eines Element Blocks zu bestimmen Dadurch wurde auch die wei tere Arbeit im Vergleich zur ersten Idee stark vereinfacht da nur noch vergleichsweise wenig Informationen aus der DXF Datei ausgelesen werden m ssen Bei der Untersuchung des uns anfangs zur Verf gung stehenden Programms in der Ver sion 1 5 x stellten wir fest da
138. zu einer Queue zusammenzusetzen die von ann hernd demselben Ort ausgel st werden und m glicherweise von einem einzigen physikalischen RR Sensor aus gel st werden Die Indizes in diesem Array entsprechen den Routen IDs Die Eintr ge sind dann die IDs der Queues Route Conflict Table Diese wird als zweidimensionales char Array implementiert Aus serdem wird die aktuelle Anzahl der verwalteten Routen ben tigt Jedes Element inner halb des Arrays entspricht einer Zelle in der Route Conflict Table es werden also nur boolsche Werte gespeichert Beispiel f r eine RCT 1 2 3 struct rd_data_t int max_routes int max_queues char rct char queue_tab Da die Anzahl der Routen durch max_routes bekannt ist werden fiir conflicts hier keine Delimitereintr ge ben tigt Um zu erkennen ob zu einer Route x ein konfliktierende Route existiert kann man die RCT dann in der folgenden Art auswerten KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 197 Auswertung fiir eintreffenden Route Request fiir Route x for int i 0 i lt rd_data max_routes i if route_aktiv i amp amp rd_data rct x i 1 return CONFLICT return NO_CONFLICT 7 5 4 6 4 f r den Safety Monitor Liste aller Sicherheitsbedingungen Diese wird durch die Menge aller sicheren Zust nde abgebildet Diese Menge wird durch eine Liste von ODER verkn pften Zust nden darge stellt wobei jeder Zustand wiederum eine Liste von UND verkn pften SHM Zust n
139. zum einen darin dass es mehrere Ans tze der Spezifikation gegeben hat ber die nur schwer Einigung erzielt werden konnte Dadurch entstand trotz der Ma nah men um die Dokumentation zu strukturieren eine un bersichtliche Dokumentstruktur was das Erlangen von Feedback im Plenum erschwerte Ein weiteres Problem war dass Diagramme und Text lange nicht bereinstimmten Das wurde unter anderem dadurch verursacht dass es schwer fiel zur Textbeschreibung sich Zust nde und Transitionen vorzustellen wenn es sich um eine einfache Schleife handelte Als das gelungen ist war es dann nicht mehr schwer zu den Funktionsnamen Text zu schreiben Die Implemen tierung gestaltete sich dann nicht mehr als besonders schwierig Andreas Kemnade KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 203 7 6 Model Checker 7 6 1 berblick Model Checking ist eine relativ neue Verifikationsmethode in der Informatik bei der in den letzten Jahren gro e Fortschritte erzielt werden konnten und die dadurch auch f r die Praxis interessant geworden ist Im Unterschied zu anderen Verifikationstechniken handelt es sich beim Model Checking um einen automatischen Ansatz Seine Einsatzm glichkeiten sind daher auf Systeme mit einer endlichen Anzahl von Zust nden beschr nkt 7 6 1 1 Prinzip des Model Checkings Mit Model Checking l sst sich berpr fen ob eine bestimmte Eigenschaft in einem bestimmten Transitionssystem erf llt ist Die Verifikation mit Model Checking umfass
140. 0 0 w1016 points point_sl_act none 800 ms 30 0 39 0 0 0 w1013 points point_sl_passive passive 800 ms 30 0 5 0 0 0 w1014 points point_slr_act none 800 ms 21 5 1 9000001 0 0 ANHANG E name category type properties switchtime coords name category type coords name category type coords name category type coords name category type coords name category type coords name category type coords name category type coords NETZGRAPH KONVERTER ELEMENT LISTEN AUSGABE 479 w1015 points point_sl_passive passive 800 ms 5 0 29 0 0 0 k2008 crossings crossing _rl 30 0 15 0 0 0 k2011 crossings crossing_90deg_rotby45deg_small 25 5 32 0 0 0 k2009 crossings crossing 90deg_small 21 5 30 0 0 0 k2010 crossings crossing_90deg_small 21 5 34 0 0 0 x1004 marks entrance 30 0 46 5 0 0 x1008 marks exit 21 5 46 0 0 0 x1003 marks entrance 3 0 34 0 0 0 ANHANG E name category type coords name category type coords name category type coords name category type coords name category type coords NETZGRAPH KONVERTER ELEMENT LISTEN AUSGABE 480 x1007 marks exit 3 0 29 0 0 0 x1002 marks entrance 21 5 10 2 0 0 x1006 marks exit 30 0 10 0 0 0 x1001 marks entrance 44 8 15 0 0 0 x1005 marks exit 45 0 20 0 0 0 Henrik R hrup Anhang F Glossar branch Die Seite einer Weiche an
141. 1 Sensor reagiert nicht auf Bahn 3 2 Sensor reagiert falsch auf Bahn 1 3 1 1 2 4 falsche Reaktion auf erkannten Sensor Signalausfall oder defekt 1 3 1 1 2 4 1 Sensor Signalausfall oder defekt 1 1 Sensor Signalausfall oder defekt 1 2 Steuersystem schaltet nicht alle betroffenen Signale auf Stop XXX 1 3 1 2 Weichen so geschaltet dass Flankenkollision m glich 1 3 1 2 1 St rung einer Weiche oder des zu ihr f hrenden bertragungsweges 1 3 1 2 1 1 Nichtbefolgen von Schaltanweisungen 1 3 1 2 1 1 1 Schaltanweisung wird ignoriert 1 3 1 2 1 1 2 Schaltanweisung gelangt nicht zu Weiche 2 1 1 2 1 wegen Defekt am Steuersystem XXX 2 1 1 2 2 wegen Defekt auf bertragungsweg 1 3 1 2 Eigenm chtige Schaltungen der Weiche 1 3 1 2 2 Fehlverhalten des Steuersystems 1 3 1 2 2 1 Fehler in Projektierungsdaten 1 1 Benutzer gibt falsche Daten ein XXX 1 2 Netzgraph liefert TND die nicht der Zeichnung entspricht XXX 1 3 1 2 2 1 3 Compiler liefert Bin rdaten die nicht der Eingabe TND entsprechen XXX 1 3 1 2 2 2 Steuersystem gibt eine nicht den Projektierungsdaten entsprechende Anweisung oder unterl sst eine in den Projektierungsdaten geforderte Anweisung PRPRe eB BREE Bee B NNNN 12360 6122 1 3 1 1 2 Hd Bd L245 1 3 1 1 2 4 2 3 12 1 3 1 2 1 3 1 2 2 1 3 1 2 2 1 3 1 2 2 2 1 Hardware Fehler am Steuersystem XXX 1 3 1 2 2 2 2 Treiber Fehler XXX 1 3 1 2 2 2 3 SI Fehler XXX 1 3 1
142. 2 486 LITERATURVERZEICHNIS 487 HPO3a HP03b Ins92 Krii00 Krii03 Lex97 MDB03 Mus04 PelO2 Pelo3 PGHD04 HAXTHAUSEN A E und J PELESKA Automatic Verification Validation and Test for Railway Control Systems based on Domain Specific Descriptions IFAC03 In TSUGAWA S und M AOKI Herausgeber Proceedings of the 10th IFAC Symposium on Control in Transportation Systems Tokio Japan 2003 Elsevier Science Ltd Oxford HAXTHAUSEN A E und J PELESKA Generation of Executable Railway Control Components from Domain Specific Descriptions In TARNAI G und E SCHNIEDER Herausgeber Formal Methods for Railway Operation and Control Systems Proceedings of Symposium FORMS03 Seiten 83 90 Budapest Ungarn Mai 2003 INSTITUT ZUR ENTWICKLUNG MODERNER UNTERRICHTSMEDIEN E V Bremen Mikroprozessor und Mikrocomputertechnik Erste Auflage 1992 KR GER G GoTo Java 2 Handbuch der Java Programmierung Addison Wesley M nchen Zweite Auflage 2000 ISBN 3 8273 1710 X KR GER G Handbuch der Java Programmierung Addison Wesley M nchen Dritte Auflage 2003 ISBN 3 8273 2120 4 LEXIKONREDAKTION MEYERS Herausgeber Sch ler Duden Informatik Meyers Lexikonredaktion Mannheim Dritte Auflage 1997 ISBN 3 411 04483 7 M HLBACHER D P DOBROVKA und J BRAUER Computerspiele De sign und Programmierung mitp Bonn Zweite Auflage 2003 ISBN 3 8266 0920 4
143. 2 1 2 fehlende oder unpassende Geschwindigkeitsbeschr nkungen 2 1 3 Nicht genuegend Abstand zwischen Signale Verkehrzeichen und Weiche Kurve Kreuzung bzgl Bremsweg 2 1 4 Bremsendefekte 2 2 Besch digungen 2 2 1 an Gleisen inkl Weichen 1 1 Beschaedigtes Gleis beschaedigte Weiche 1 2 Nicht alle betroffene Signal HALT XXX 2 2 2 an der Bahn 2 3 Umschalten von Weichen w hrend sie befahren werden Weiche im Umschaltzustand amp amp Signal HALT Weiche im Umschaltzustand amp amp ctr g ctr gl ctr g2 2 3 1 Anwesenheit von Bahnen wird dem Steuersystem nicht mitgeteilt 2 3 1 1 unzureichende Sensorausstattung 2 3 1 2 Sensordefekt 2 3 1 3 Hardwaredefekt auf bertragungsstrecke 2 3 2 Anwesenheit von Bahnen wird dem Steuersystem mitgeteilt aber von diesem nicht beachtet 2 3 2 1 Hardwaredefekt am Steuersystem XXX 2 3 2 2 Software setzt Sensormeldung nicht oder falsch um 2 3 2 2 1 Treiber Fehler XXX 2 3 2 2 2 SI Fehler XXX 2 3 2 2 3 Fehler in Projektierungsdaten 2 2 22 2 2 s 3 1 Benutzer gibt falsche Daten ein XXX 3 2 Netzgraph liefert TND die nicht der Zeichnung entspricht XXX 2 3 2 2 3 3 Compiler liefert Bin rdaten die nicht der Eingabe TND entsprechen XXX 2 3 2 2 2 3 2 2 KAPITEL 8 SICHERHEITSNACHWEIS 433 2 3 2 3 Fehler an Betriebssystem Systemungebung XXX 2 4 Auffahren auf nicht auffahrbare Weichen 2 4 1 Bahnen auf entsprechend fiihrende Gleise gel
144. 2 2 Initialisierung der Variablen F r alle in einem Gleisnetz enthaltenen aktiven Weichen werden Variablen erstellt Dazu wird jeweils das Modul point aufge rufen und als Parameter werden die Bedingungen bergeben die angeben wann die Weiche den jeweiligen Zustand annehmen soll Damit nur Anforderungen m glich sind die zu dem Weichentyp passen ist none als Bedingung definiert die niemals erf llt sein kann w1022 point w1022_straight w1022_left none w1018 point w1018_straight none w1018_right w1020 point w1020_straight none w1020_right KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 217 7 6 4 2 3 Bedingungen zum Stellen der Weichen F r jede Weiche existieren Bedingungen wann diese in eine bestimmte Richtung gestellt werden soll Wenn sich eine Route im Zustand ACTIVE befindet die die entsprechende Weichenstel lung ben tigt ist die Bedingung zum Schalten der Weiche erf llt In dem Beispiel soll die Weiche w1022 geradeaus gestellt werden wenn die Route r2 im Zustand ACTIVE ist und nach links wenn die Route r3 im Zustand ACTIVE ist w1022_straight case r2 state ACTIVE 1 1 0 esac w1022_left case r3 state ACTIVE 1 1 0 esac w1018_straight case rO state ACTIVE 1 1 0 esac w1018_right case ri state ACTIVE 1 1 0 esac w1020_straight case r4 state ACTIVE 1 1 0 esac w1020_right case r5 state ACTIVE 1 1 03 esac 7 6 4 3 Signalverhalten
145. 22 state 1 0 esac s3013_stop case rO_lock_cond ri_lock_cond 1 lt 0 esac s3013_straight 1 0 esac s3013_right case ri state ACTIVE amp w1018 state 1 0 esac s3015_stop case r4_lock_cond r5_lock_cond 1 0 esac s3015_straight 1 0 esac s3015_right case r5 state ACTIVE amp w1020 state t 15 case r2 state ACTIVE amp w1022 state case rO state ACTIVE amp w1013 state case r4 state ACTIVE amp w1020 state STRAIGHT 1 LEFT 1 STRAIGHT 1 RIGHT 1 STRAIGHT 1 RIGHT 1 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 220 1 2705 esac 7 6 4 4 Sensorverhalten Nun folgt die Beschreibung des Sensorverhaltens 7 6 4 4 1 Allgemeines Sensorverhalten In dem Modul sensor wird das Verhal ten beschrieben das f r alle Sensoren gleich ist Als Parameter werden zwei Bedingungen bergeben die angeben wann der Sensor er reicht werden kann bzw wann der Sensorz hler wieder zur ckgesetzt werden soll Die Variable ctr repr sentiert den Sensorz hler Anhand der Z hler kann man erkennen wo sich momentan wie viele Bahnen befinden Zudem dienen die Z hler dazu zu bestim men wann eine Bahn einen bestimmten Sensor erreichen kann sowie zum Ausdr cken der Sicherheitsbedingungen Der Z hler wird inkrementiert wenn die Bedingung cond_1 gibt an ob der Sensor erreicht werden kann erf llt ist und wieder zur ckgesetzt wenn die Bedi
146. 3014 left route27 s3015 straight route28 s3015 right Route Conflict Table Route routes route23 X X X X route24 X X route25 X X route26 X X X X route27 X X X X route28 X X 7 6 6 1 Routenanforderungen Zur berpr fung der Verschlusstabellen m ssen nur maximal zwei Routen befahren werden Dadurch kann man feststellen ob zwischen diesen beiden Routen ein Konflikt besteht Dass sich mehrere Bahnen auf einer Route befinden k nnen oder dass sich Rou ten in bestimmten Zust nden befinden ist f r die berpr fung der Verschlusstabellen nicht notwendig Zum berpr fen des Route Conflicts Table m ssen alle Routenkombinationen durchpro biert werden Ist beispielsweise route_A route23 und route_B route26 dann werden die beiden Routen route23 und route26 befahren Nun kann man erkennen ob diese Routen im Konflikt stehen Zum berpr fen von Route Definition Table Point Position Table und Signal Setting Table muss jeweils nur eine einzelne Route befahren werden statt eines Routenpaares Wenn man nun route_A route23 und route_B no setzt dann wird nur die Route route23 befahren Jetzt kann man erkennen ob die Route so durchfahren wird wie es definiert wurde Es f llt auf dass die Routen hier andere Namen haben als bei der berpr fung des KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 243 Systemmodells obwohl es sich um das selbe Beispielgleisnetz handelt Dies liegt daran dass bei der Verschlusstabelleniiberpriifung
147. 4 fiir den Model Checker automatisch erzeugt werden kann Wie die in den Verschlusstabel len gemachten Angaben berpr ft werden k nnen wird im Abschnitt 7 6 6 auf Seite 239 beschrieben Schlie lich folgt im Abschnitt 7 6 7 auf Seite 252 noch eine abschlie ende Reflexion Ruben Rothaupt Taffou Happi 7 6 2 Konzept zur Verifikation der Projektierungsdaten In diesem Abschnitt wird beschrieben wie sich nachweisen l sst dass die Projektie rungsdaten die notwendigen Sicherheitsanforderungen erf llen Um zu berpr fen ob alle Sicherheitsbedingungen erf llt sind wird Model Checking verwendet Dazu muss ein formales Modell des Systems erstellt werden und die Sicher heitsbedingungen m ssen spezifiziert werden 7 6 2 1 Sicherheitsbedingungen Die folgenden Sicherheitsbedingungen m ssen in jedem Gleisnetz erf llt sein Dabei kann man zwischen Kollisionen und Entgleisungen unterscheiden e Kollisionen Keine Bahnen d rfen aus unterschiedlichen Richtungen auf dieselbe Kreuzung zufahren so dass es zu einem Flankenzusammensto kommen kann Keine Bahnen d rfen aus unterschiedlichen Richtungen auf dieselbe Weiche zufahren so dass es zu einem Flankenzusammensto kommen kann Keine Bahnen d rfen in entgegengesetzter Fahrtrichtung aufeinander zufah ren so dass es zu einem Frontalzusammensto kommen kann e Entgleisungen Keine Weichen d rfen umgeschaltet werden w hrend sie befahren werden Wenn d
148. 5 4 5 1 Eingangsdaten KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 192 e Route State Table Bahnz hler e Eingangssensorz hler Routenbeschreibung f r die jeweilige Route aus Projektierungsdaten bestehend aus Anforderungsliste Signalpositionen um Anforderungen anzuzeigen Stellliste Weichenpositionen um die Route freigeben zu k nnen und alle Si gnalpostionen die nicht zur Freigabe f hren Freigabeliste Signalpositionen um die Route freigeben zu k nnen und die RR Anzeigen wieder freizugeben Einfahrts und Ausfahrtssensor Sperrliste Signalpositionen um die Route wieder zu sperren Deaktivierungsliste Signalpositionen um alle Signale der Route auf rot zu schalten aktueller SHM Zustand Kopie der SHM Schnittstelle 7 5 4 5 2 Ausgangsdaten e Route State Table e neuer SHM Zustand ge nderte Kopie e Bahnz hler e Eingangssensorz hler 7 5 4 5 3 Funktionen aktionsliste_ausfuehren SHM Zust nde anhand der als Parameter angegebenen Liste setzen aktionsliste_erfuellt berpr fung ob SHM Zust nde den in der als Parameter bergebenen Liste geforderten entsprechen eingangssensor_ausgeloest berpr fung ob der Eingangssensor einer Route aus gel st wurde sensor_reset R cksetzen der Sensoren RESET bit setzen am Eingang und Aus gang einer Route KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 193 nachbedingungsliste_erfuellt berpr fung ob die Sensorz hlerst nde vom
149. 6 MB Flash 256 MB RAM Sicherheitsreserven e evtl 8255 IO Karte Dec e evtl IOWarrior IO Karte Cod e Unterbrechnungsfreie Stromversorgung 7 5 4 2 2 Konzept Softwareplattform Linux Kernel monolithisch kompiliert in minimaler Konfiguration e uclibc minimale Variante der Glibe einer Bibliothek mit Standard C Funktionen e alles statisch gelinkt e evtl zus tzliche Bibliotheken f r Treiber e busybox stellt eine Vielzahl von Systemprogrammen in einfacher Form in einem einzelnen Programm zur Verf gung e evtl Fernwartungstools ssh telnet e primitiver Bootloader 7 5 4 2 3 Konfiguration Es muss einen eigenen Init Prozess geben der einen Pr fsummencheck f r alle Datei en des Steuerinterpreters durchf hrt Dabei sollen m glichst wenig Prozesse gestartet werden und das System aus einer RAM Disk initrd initial ram disk geladen werden damit zur Laufzeit Zugriffe auf den wahrscheinlich langsameren persistenten Speicher zugegriffen wird KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 186 7 5 4 2 4 Konzept Startvorgang des Systems Bevor dieser Startvorgang durchgef hrt wird muss sichergestellt werden dass sich keine Bahn auf den Routen befindet dies muss n tigenfalls durch manuelles Herausleiten geschehen Zun chst l dt der Bootloader den Kernel mit initrd Dateisystem der dann das root Dateisystem auf der Ramdisk anlegt und den SI init Prozess Dieser macht folgendes e optional SI init startet nicht SI
150. 99 public synchronized boolean checkRequestPending if requestList size 0 return false else return true public synchronized String getRequest String retvalue new String retvalue String requestList removeFirst return retvalue Diese drei Methoden realisieren den Zugriff auf die Liste der Anfragen Diese Zugriffe m ssen getrennt voneinander erfolgen um typische Nebenl ufigkeitsprobleme zu umge hen daher sind die Methoden synchronized addRequest das Hinzuf gen einer neuen Anfrage muss nur von diesem Server selbst aufgerufen werden daher kann sie private deklariert werden checkRequestPending pr ft ob aktuell Anfragen in der Liste vorhanden sind getRequest liefert die erste und damit lteste Anfrage zur ck Die beiden zuletzt genannten Methoden werden vom Simulator aufgerufen und sind daher als public deklariert private synchronized void addDriver String request SocketChannel driver ArrayList temp new ArrayList StringTokenizer st new StringTokenizer request n String actToken st nextToken actToken st nextToken temp add new Integer actToken temp add driver driverList add temp public synchronized boolean checkDriverPending if driverList size 0 return false else return true public synchronized ArrayList getDriver ArrayList retval new Arraylist retval ArrayList driverList removeFirst KAPITEL 7 BESCHREIBUNG
151. APITEL 7 BESCHREIBUNG DER KOMPONENTEN 109 Bblothek Browser x 3 Verzeichnisse t LAE 8 points i sensors 8 signals A track 4 tracs LGA cvs 2 A others A points A sensors signals track fee oe r n DA pa PE ya emp 4 A ba m ID Io T LI sensor_rr sensor_sd sensor_sg sensor_td Io sensor_tg Einf gen Block Liste x Abbildung 7 18 QCad Bibliotheks Browser Die einzelnen Elemente sind in der Objekt Bibliothek in verschiedene Kategorien unter teilt wobei deren Namen in den meisten F llen selbsterkl rend sein sollten Die Kate gorie track umfasst alle Schienen Elemente die keiner anderen Kategorie zuzuordnen sind also z B Kreuzungen w hrend points alle Weichen Elemente enth lt Die Ka tegorien signals und sensors enthalten ausschlie lich die im Namen genannten Ele mente In der Kategorie others sind Markierungselemente zu finden sowie Symbole f r Eintritts und Ausgangspunkte eines Gleisnetzes Einfache Gleise werden durch simple Linien dargestellt Hierf r gibt es keine eigenen Teilzeichnungen innerhalb der Bibliothek 7 2 4 3 3 Hinweise zum Zeichnen mit QCad Rasterfang Es sollte auf jeden Fall darauf geachtet werden dass die Funktion Raster fangen ak tiviert ist Dies ist z B ber das Men Fang einstellbar Diese Funktionalit t ist erforderlich weil es exakte Ber hrungspunk
152. Abschnitt dieser Datei wie folgt aussehen lt ui config gt lt commands gt lt command path usr bin rtt compile test name RTT GUI Command Compile gt lt command path usr bin rtt new test name RTT GUI Command New Test Case gt lt command path usr bin rtt copy test name RTT GUI Command Copy gt lt command path usr bin rtt run test name RTT GUI Command Run gt lt command path usr bin rtt stop test name RTT GUI Command Stop gt lt command path usr bin rtt doc test name RTT GUI Command Doc gt lt command path name RTT GUI Command Index gt lt command path name RTT GUI Command Coverage gt lt commands gt lt environment gt lt env var value usr name RTTHOME gt lt env var value home wolf359 tracs cvs hwsw testsuite name RTT_TESTCONTEXT gt lt environment gt lt ui config gt Hier sind die gegebenen Werte f r command path den Pfaden auf dem jeweiligen Sys tem anzupassen damit die RT Tester GUI die Binaries finden kann Au erdem sind die beiden Umgebungsvariablen RTTHOME und RTT_TESTCONTEXT anzupassen Wurde die An passung vorgenommen kann die RT Tester GUI gestartet werden Zur Bedienung des RT Testers und der GUI wird an dieser Stelle auf das entsprechende Manual Ver04 verwiesen Arne Stahlbock KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 300 7 7 6 2 Route Dispatcher 7 7 6 2 1 Ausf hrung Um den RD Test durchf hren zu k nnen muss zun
153. BORDERSIZE weltCoord xmin x multiplier 7 7 Mit diesen Formeln k nnen wir zu jeder Zeit die zugeh rigen Pixelkoordinaten zu den Weltkoordinaten ausrechnen Dabei m ssen xmin xmaz ymin und ymax nur einmal am Anfang ausgerechnet werden da keine weiteren Elemente hinzukommen und Prmin P max Pymin und Pymax m ssen immer nur dann neu ausgerechnet werden wenn die Fenstergr e ge ndert wird 7 8 4 5 2 Zeichenreihenfolge Damit die Visualisierung der Simulation f r das menschliche Auge nachvollziehbar dargestellt wird ist es wichtig auf die richtige Zei chenreihenfolge zu achten Wenn z B die Gleise erst nach der Stra enbahn gezeichnet werden so verwirrt das und erweckt den Anschein als ob die Stra enbahn unterhalb der Gleise fahren w rde Die Reihenfolge der einzelnen Visualisierungen wurde wie folgt festgelegt e Weichen verdicken die Gleise Sensoren liegen auf Gleisen e Kreuzungen verdicken die Gleise Stra enbahnen fahren auf Gleisen Weichen Kreuzungen Sensoren Gleise bilden die Grundlage Signale stehen neben Hardware Elementen 7 8 4 5 3 Zeichenmethoden Anhand der Zeichenreihenfolge werden nun die ver schiedenen Darstellungen aller Elemente vorgestellt e Weichen Weichen und ihre Stellung werden dadurch visualisiert dass die Gleise die in der aktuellen Stellung berfahren werden k nnen dicker gezeichnet werden Wenn sich eine Weiche in einem Umschaltvorgang befindet dann wird nur da
154. Bei der maximalen Gr e von 4 handelt es sich bei diesem HW um eine Kreuzung oder eine Doppelweiche Bei einer Kreuzung muss darauf geachtet werden dass an den Indizes 0 und 1 zwei TEs stehen die direkt ineinander bergehen f r die Indizes 2 und 3 gilt das gleiche Im Gegensatz dazu muss bei einer Weiche darauf geachtet werden dass sich beim Index 0 das TE der stem Seite befindet und bei den anderen Indizes die TEs der branch Seite befinden Koordinaten Die Koordinaten der einzelnen HWs werden ben tigt als Positionsangabe ohne diese w re eine Visualisierung gar nicht m glich Gleichfalls werden sie dazu gebraucht um z B die L nge eines TEs aus zurechnen Die Instanzen der Klasse TE TrackElement enthalten die Informationen f r die Geradenst cke zwischen zwei HWs TEs verbinden jeweils zwei HWs miteinander Ein TE selbst ist kein aktives Element des Gleisnetzes es wird passiv f r die Verbindung der HWs und f r die Positionsbestimmung der Bahnen ben tigt und benutzt Ein TE enth lt folgende Informationen HW 2 Ein TrackElement ist ein Geradenst ck zwischen genau zwei HWs die an dieser Stelle festgehalten werden Die genaue Positionsbestimmung auf ei nem TE funktioniert mit Hilfe von Parametern die im Folgenden genauer beschrieben werden Wichtig an dieser Stelle anzumerken ist dass beim HW am Index 0 der Parameter gleich 0 ist und beim HW am Index 1 der Para meter gleich MaxParam ist Anhand dieser Festle
155. Builder OfTheUNIverse erstellt Diese Komponente liest eine TND Datei ein und pr ft ob die Datei lexikalisch und syntaktisch korrekt ist Am Ende erzeugt sie eine Objektdarstellung f r das betreffende Gleisnetz Eine ausf hrliche Erkl rung dazu ist in der Beschreibung der Simulator Programmstruktur in Abschnitt 7 8 4 2 auf Seite 328 zu finden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 131 7 3 4 2 3 Objekt Darstellung Die Komponente Objekt Darstellung modelliert alle Objekte die fiir die Routendefinitionen wichtig sind Zudem fiihrt sie die Umwan dung von Routenobjekten zu Routenbl cken aus Die Abbildung 7 28 zeigt das Klassendiagramm fiir TND Objekte current 1 0 next current 1 P He previous trDevice A in ouf_ in 2 oud 2 trSensor trSignal trMark trCrossing rr in_1 trDevice null out_1 trDevice null right left sera ight trPoint incoming trDevice null straight trDevice null left trDevice null in_2 trDevice null right trDevice null 0 j out_2 trDevice null 0 trPointInRoute ir ein exi S point trPoint signalsinroute entry_sigal has position String trRoute pointsinroute trPointInRoute rr_sensor trSensor entry_signal trSignal entry_signal_value String entry_sensor trSensor exit_sensor trSensor signal
156. C CHARACTER gt lt DESC CHARACTER gt lt LETTER OR DIGIT gt p 2 N lt TIMEOUT gt 1 lt INTEGER gt lt INTEGER gt lt DIGIT gt lt DIGIT gt KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 200 Der hier spezifizierte Timeout Wert gibt jeweils an in welchem Zeitraum gemessen in Millisekunden die Hardware auf einen Befehl des Steuerinterpreters reagieren muss bevor ein Fehler ausgel st wird Im realen Einsatz w rde sich eine Art Hardware Bibliothek mit diesen Informationen ansammeln die man f r mehrere Gleisnetze wiederverwenden k nnte Damit man diese Informationen nicht jedes Mal wieder in die TND Daten einf gen m sste ist es wahr scheinlich g nstiger die Daten in einer eigenen Datei zu halten Diese Datei wird im Folgenden als HW Info Datei bezeichnet Man k nnte die Datei mit Hilfe eines Pr pro zessors z B den Standard C Pr prozessor in die TND einbinden wodurch der Auf wand diese Information zu verarbeiten minimiert werden w rde Alternativ k nnte man die Datei v llig getrennt einlesen was aber z B f r den Simulator einen Mehraufwand bedeutet Als dritte Informationsquelle dient eine weitere Textdatei die die Zuordnungen von Trei berklassen zu Hardwareklassen enth lt Diese Zuordnung ist unabh ngig vom Gleisnetz und damit auch der TND aber daf r wahrscheinlich abh ngig vom Anwendungs szenario z B Simulation Testbetrieb operatives System Eine Treiberklasse ist eine Grup
157. D x KOMMA COORD y KOMMA COORD z KZ 48 RESULT new int 3 49 RESULT O x intValue 50 RESULT 1 y intValue 51 RESULT 2 z intValue 52 ag 53 Viele dieser Produktionen ist kein Quellcode angeh ngt Diese Zeilen sind dennoch f r die Erkennung der Grammatik der Datei unverzichtbar nur findet an diesen Stellen eben keine Weiterverarbeitung von Informationen statt Die Zeilen 11 29 zeigen eine Struktur welche an vielen Stellen im gesamten Parser zu finden ist Zum einen wird ein Typ erkannt und als String zur ckgegeben Zeile 26 28 und zum anderen wird eine Liste erstellt und gef llt mit einer Reihe von Objekten in diesem Fall sind es IDs von Sensoren Zeile 17 25 Sobald die Liste komplett ist trifft sie an anderer Stelle mit dem Typ zusammen an dieser Stelle wird sie dann auch verarbeitet Zeile 11 16 Hier wird die Liste wieder zerteilt und f r jeden Sensor eine Methode im BTNB aufgerufen Die Zeilen 30 32 zeigen wie man eine Optionalisierung eines Blockes einf gt In den Zeilen 39 42 treffen wieder die Informationen zusammen und werden an den BTNB weiter geschickt Anhand der Beispieldatei auf Seite 373 l sst sich erkennen dass die hier erkannte ID die gleiche sein wird wie im DEFBLOCK insofern muss bei der Weiterverarbeitung im BTNB erkannt werden dass es dasselbe Objekt ist KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 377 7 8 5 1 4 BestTramNetworkBuilderOffheUNIverse Im letzten Schritt werden
158. DER KOMPONENTEN 180 Die Bits 10 14 sind nicht definiert und m ssen vom Treiber ignoriert werden Ausgabebereich Analog zum Eingabebereich signalisiert der Wert im Ausgabebereich den aktuellen Sta tus des vom Treiber gesteuerten Signals hnlich wie beim Eingabebereich darf auch im definierten Ausgabebereich prinzipiell nur ein Bit gesetzt sein Ausnahme f r RE QUEST RECEIVED gilt auch hier allerdings ist es m glich sowohl einen Anzeigezu stand als auch einen Fehlerzustand gleichzeitig abzubilden in diesem Fall sind zwei bzw drei gesetzte Bits erlaubt Die folgenden Bits sind f r den Ausgabebereich definiert Bit 0 aktuelle Anzeige ist STRAIGHT POS Bit 1 aktuelle Anzeige ist LEFT POS Bit 2 aktuelle Anzeige ist RIGHT POS Bit 3 aktuelle Anzeige ist STOP Bit 4 aktuelle Anzeige ist REQUEST RECEIVED STRAIGHT Bit 5 aktuelle Anzeige ist REQUEST RECEIVED LEFT Bit 6 aktuelle Anzeige ist REQUEST RECEIVED RIGHT Bit 7 aktuelle Anzeige ist WAIT STRAIGHT Bit 8 aktuelle Anzeige ist WAIT LEFT Bit 9 aktuelle Anzeige ist WAIT RIGHT Bit 13 Fehlerzustand OFF Bit 14 Fehlerzustand INVALID Bit 15 Fehlerzustand FAILURE Die Bits 10 12 sind nicht definiert und miissen vom Steuerinterpreter ignoriert werden OFF Die Ausf hrung des Treibers wurde beendet es werden keine Anforderungen mehr ausgef hrt INVALID Die letzte Anforderung war ung ltig z B weil Bit 1 und Bit 2 gleichzeitig gesetzt waren FAILURE Ein Hardwarefe
159. DER KOMPONENTEN 400 return retval Diese Methoden realisieren den Zugriff auf die Liste der Treiberinformationen die je des Mal gef llt wird wenn ein Treiber sich erstmals anmeldet Es werden dann zwei Werte als da w ren die ID des von diesem Treiber gesteuerten HW Elements und der SocketChannel auf dem der Treiber angebunden ist in dieser Liste abgelegt Der Simu lator pr ft bevor die eigentliche Simulation angelaufen ist st ndig ob sich neue Treiber angemeldet haben und teilt dies dem StatusSender mit da dieser diese Daten ben tigt 7 8 5 5 Richtung Simulator Treiber Die Gegenrichtung wird relativ hnlich realisiert Wir haben dieses Mal einen Thread der st ndig den Status einer Liste berwacht und sobald ein String in dieser Liste vor handen ist diesen an den Hardware Treiber sendet Auch hier gelten die oben gemachten Anmerkungen zum Quellcode keine Kommentare nicht vollst ndig aufgef hrt public class StatusSender extends Thread private ArrayList statusList private HashMap drivers private Logger logger Als Variable verf gt diese Klasse wiederum ber eine Liste in der in diesem Fall die Statusmeldungen f r den SI gesammelt werden In einer HashMap werden die Daten ber die Treiberinstanzen festgehalten als Index dienen die IDs der jeweiligen Gleisnet zelemente Zudem steht auch der Logger zur Verf gung public void run String report while true if checkPending report get
160. DK installiert sind Die TRACS Objekt Bibliothek fiir die CAD Software sollte idealerweise in jenem Ver zeichnis abgelegt werden welches fiir die sogenannten Teile Bibliotheken vorgesehen ist Auf dem verwendeten System war dies der Pfad usr share qcad libraries Theoretisch sollte es aber auch m glich sein ein beliebiges Verzeichnis zu w hlen und in den Einstellungen der CAD Software den Pfad entsprechend zu ver ndern Was die Konverter Tools betrifft so reicht es diese in einem beliebigen Verzeichnis ab zulegen auf das w hrend der gesamten Laufzeit Schreibzugriff f r den ausf hrenden Benutzer besteht Sollten die einzelnen Java Klassen erst noch bersetzt werden m ssen so reicht es in den Pfad zu wechseln welches das Verzeichnis mit dem Namen ng enth lt in welchem s mtliche Java Klassen des Konverters zu finden sind und mittels javac ng java die se zu bersetzen Als Ergebnis erh lt man die mittels des Befehls java ausf hrbaren Programme 7 2 4 3 Benutzung der CAD Software QCad und der Objekt Bibliothek F r die erfolgreiche Erstellung von Gleisnetzdarstellungen in einer CAD Software und anschlie ender Konvertierung wird das Programm QCad in einer Version 2 x ben tigt Dieses Programm ist f r verschiedene Betriebssysteme vorhanden Da der TracsDXF2 TND Konverter in erster Linie f r ein Linux System entwickelt wurde wird dazu gera ten auch die entsprechende Linux Version von QCad zu verwenden QCad sollte in j
161. DXF Formats Desweiteren bezieht sie sich lediglich auf die f r TRACS relevanten Teile daher auch Vereinfachte DXF Grammatik lt dxf gt DXF Datei Header weitere Sektionen lt blocksec gt lt entitysec gt 0 EOF lt blocksec gt lt a OM SECTION 2 BLOCKS o lt blocks gt ENDSEC lt entitysec gt IESE yo Or SECTION 2 ENTITIES o lt entities gt ENDSEC lt blocks gt BLOCK 2 alnum _ 70 ou lt startcoord gt 3 ANHANG B DXF DATEI FORMAT lt startcoord gt lt endcoord gt lt entities gt lt entheader gt lt insert gt lt point gt alnum _ 1 1 o lt entities gt ENDBLK o 10 digit 20 digit 30 digit 11 digit 21 digit 31 digit lt line gt lt circle gt lt point gt lt text gt lt insert gt U 8 alnum 62 256 6 ByLayer lt startcoord gt lt entheader gt o lt entheader gt digit digit digit digit digit digit J dd J J 462 ANHANG B DXF DATEI FORMAT 463 o lt circle gt lt entheader gt 40 digit digit o lt text gt lt entheader gt 40 alnum _ eig alle
162. Daten werden vom SI f r die Projektierungsdaten ben tigt 7 5 4 6 2 f r die einzelnen RC Instanzen Diese Liste wird nicht terminiert da die L nge bekannt ist e Routen ID f ngt bei 0 an zu z hlen e Stellliste ben tigte Weichenpositionen um die Route freigeben zu k nnen und alle Signalpositioonen die nicht zur Freigabe f hren e Freigabeliste Signalpositionen um die Route freizugeben e Sperrliste Signalpositionen um die Route wieder zu sperren KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN hasNextRC setze_phase_master SM RC Schleife hasNextRC naechster_RC true RC i gt Testphase Rst_eintrag ROUTE_INAKTIV setze_phase_naechster_RC naechter_RC true N aktionsliste_ausfueren stellliste sensor_reset naechster_RC true Rst_eintrag ROUTE_ANGEFORDERT anforderungssignal_zeigen naechster_RC true aktionsliste_erfuellt deaktivierungsliste amp amp Rst_eintrag ROUTER_SPERREN Rst_eintrag ROUTE_INAKTIV naechster_RC true Rst_eintrag ROUTE_AKTIV aktionsliste_ausfuehren freigabeliste naechster_RC true Deaktivierungsphase N Bl aktionsliste_erfuellt deaktivierungsliste amp amp Rst_eintrag ROUTE_AKTIV naechster_RC true aktionsliste_erfuellt sperrliste amp amp nachbedingungsliste_erfuellt amp amp sperrtimer_abgelaufen amp amp Rst_eintrag ROUTE_AKTIV aktionsliste_ausfuehren de
163. DefBlock definiert worden ist genau einmal vorkommen Diese Regeln sorgen im Wesentlichen daf r dass TND Dokumente mit einem Inhalt der sinnlose oder sogar unm gliche Gleisnetze darstellen w rde so gut wie m glich verhindert werden wenngleich an dieser Stelle nicht behauptet werden soll dass nicht trotzdem noch die Notation eines sinnlosen Gleisnetzes m glich ist Silvia Graumann Niklas Polke Henrik R hrup Susanne Spiller Arne Stahlbock 7 1 4 Schnittstellen Es gibt mehrere Schnittstellen zu anderen Bestandteilen des Projekts Daten werden so wohl in die TND Form konvertiert als auch aus ihr ausgelesen Da die TND sowohl Rou teninformationen als auch Koordinaten und Beziehungen umfasst wird eine vollst ndige Datei die das gesamte Gleisnetz enth lt und f r die Verarbeitung im Projekt ben tigt wird aus verschiedenen Quellen zusammengesetzt e Die Informationen ber das physikalisch vorhandene Gleisnetz wie Elementbezie hungen und Koordinaten werden vom CAD TND Konverter der aus einer DXF Datei die Informationen ausliest und in TND Form in einer neuen Datei abspei chert geliefert e Alle weiteren Informationen z B die Daten der Verschlusstabellen werden mittels des TND Builders in die TND Datei eingef gt e Prinzipiell kann auch jede Information von Hand eingef gt werden Eine TND Datei wird von mehreren Arbeitsgruppen des Projekts weiterverarbeitet Si mulator HW SW Testgruppe Modelchecker und Compil
164. Die Aufgabenstellung des Projektes TRACS verlangt nach einem Beschreibungsformalis mus f r Stra enbahn Gleisnetze und der auf einem Gleisnetz aufbauenden Steueraufga be Dieser Formalismus wurde in Gestalt der Sprache TND entwickelt In dieser Sprache k nnen Gleisnetze f r Stra enbahnsysteme beschrieben werden au erdem Informatio nen ber in dem Gleisnetz bestehende Routen Steuerinformationen f r die einzelnen Routen ggf Konflikte zwischen Routen Hardwaredaten Damit k nnen in einem spe zifischen TND Dokument alle zur Erf llung der Steueraufgabe n tigen Daten angelegt werden Aus einer in TND vorliegenden Beschreibung einer Steueraufgabe wird dann das ausf hr bare Steuersystem generiert Dazu wird die Beschreibung in ein Bin rformat umgewan delt welches dann von einem Steuerinterpreter verarbeitet wird Das TND Format ist unabh ngig von etwaigen Eingabetools gehalten TND Dateien k nnen prinzipiell per Hand in einem Texteditor erstellt werden Im Rahmen von TRACS wurden aber auch mehrere Eingabehilfen hergestellt Zum einen handelt es sich hier um einen CAD TND Konverter der aus CAD Zeichnungen von Gleisnetzen TND Dateien erzeugen kann Die so erzeugten Dateien erhalten dann zwar alle Daten ber das physisch vorhandene Gleisnetz an sich jedoch noch nicht die zur Steuerung erfor derlichen Informationen ber Routen Konflikte etc An dieser Stelle setzt der ebenfalls von TRACS entwickelte TND Builder an der eine Eingab
165. Die Deklaration der Routen ist so zu verstehen dass f r die sp ter genau spezifizierten Routen Bezeichner reserviert werden Diese Bezeichner beginnen mit r hnlich verh lt es sich mit den Markierungen marks hierbei handelt es sich um Hilfs punkte auf dem Gleis die bei der Transformation in eine graphische Darstellung ben tigt werden In diesem Block werden zun chst nur Bezeichner eingef hrt Ebenso werden Kreuzungen an dieser Stelle deklariert Weiterhin werden Bezeichner f r Hardwareklassen eingef hrt die f r den Steuerinter preter von Interesse bez glich der Treiberansteuerung sind Beispiel definitions sd sensors g101 g102 g103 g104 g105 g201 g202 g203 g301 g302 g303 g304 g401 g402 g403 g404 g405 g406 rr sensors g100 g200 g300 g400 s signals s2 s3 sr signals s1 s4 sl points w2 w3 sr points w1 w4 routes routel route2 route3 route4 route5 route6 marks x1 hwclasses ci c2 Das Beispielnetz enth lt eine gewisse Anzahl an Sensoren als Typ wurde ohne Be schr nkung der Allgemeinheit sd gew hlt es h tte auch durchaus ein anderer sein k nnen vier Signale unterschiedlichen Typs vier Zweiwegeweichen und es sind sechs Routen definiert wie das Netz zu durchfahren ist Au erdem gibt es genau eine Mar kierung KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 66 7 1 3 2 3 CoordBlock lt coordblock gt lt COORDINATES gt lt coorddef gt lt coorddef
166. EN 251 7 6 6 5 2 point conflicts Block Nun soll der point conflicts Block berpr ft wer den in dem die Weichenkonflikte definiert sind Dazu wird eine Bedingung safe2 defi niert die wahr ist wenn keine Weichenkonflikte auftreten safe2 w1022 point_conflict amp w1018 point_conflict amp w1020 point_conflict Es wird angegeben bei welchen Routenkombinationen im point conflicts Block ein Wei chenkonflikt definiert ist point_conf case route_A route23 amp route_B route24 1 route_A route24 amp route_B route23 1 route_A route25 amp route_B route26 1 route_A route26 amp route_B route25 1 route_A route27 amp route_B route23 1 route_A route28 amp route_B route27 1 1 0 esac Wenn ein Weichenkonflikt definiert wurde muss auch einer auftreten bzw wenn kein Weichenkonflikt definiert wurde darf auch keiner existieren SPEC point_conf 1 gt AG safe2 SPEC point_conf 0 gt AG safe2 7 6 6 5 3 routedefinitions Block conditions Block und clearances Block Es soll berpr ft werden ob die Routen so durchfahren werden wie sie definiert wurden Dazu braucht immer nur eine Route befahren zu werden da Routenkonflikte hier keine Rolle spielen Wenn eine Route in der beabsichtigten Weise befahren wird dann muss es immer zu einem Zustand kommen in dem Ein und Ausgangssensor der Route erreicht wurden und es muss immer zu einem Zustand kommen in dem der Eingangs
167. FO Time 1111182650647 INFO Trying to move 138 8 steps KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 413 INFO Tram TramO must stop in front of signal while 138 8 steps are pending INFO Tram TramO must stop in front of signal while 0 0 steps are pending INFO Tram TramO is now located Head on TE 1 between HW g1 and HW g2 at distance 19898 Tail on TE 1 between HW gi and HW g2 at distance 16699 INFO Time 1111182650757 INFO Trying to move 138 8 steps INFO Tram TramO must stop in front of signal while 138 8 steps are pending INFO Tram TramO must stop in front of signal while 0 0 steps re pending INFO Tram TramO is now located Head on TE 1 between HW g1 and HW g2 at distance 19898 Tail on TE 1 between HW gi and HW g2 at distance 16699 Wie man sehen kann f hrt die Bahn zun chst noch weiter bis das Signal erreicht ist und h lt dort an Sie versucht dann jeden Zyklus wieder weiterzufahren was aber da das Signal nicht umschaltet nicht gelingt Wird die Situation neu gestartet diesmal mit dem Signal in der gew nschten Stellung so ist der Output INFO Tram TramO is now located Head on TE 1 between HW gi and HW g2 at distance 19848 Tail on TE 1 between HW gi and HW g2 at distance 16649 INFO Time 1111183956307 INFO Trying to move 139 20044 steps INFO Tram TramO Correct signal percepted ini iteration INFO Tram TramO is now located Head on TE 2 between HW g2 and HW g3 at distance 87 Tail on TE 1 between HW
168. Farben Symbole und Abk rzun gen verwendet werden wird es eine Hilfe geben die jederzeit aufgerufen werden kann und in der der Zustand der Gleiselemente in Textform ausgegeben wird Die zugrunde liegenden Koordinaten werden entsprechend der Fenstergr e skaliert Bei Ver nderung der Fenstergr e wird die Visualisierung durch Skalierung angepasst Eine bestimmte Mindestgr e f r das Fenster sowie ein geringer Abstand zwischen den u eren Gleisen und dem Rand werden vorausgesetzt Nun folgt die Darstellung der Reihenfolge in welcher die verschiedenen Elemente visua KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 309 lisiert werden und wie welches Element genau dargestellt werden soll um den Anforde rungen zu gen gen 7 8 4 5 1 Welt Pixelkoordinaten Die Welt Koordinaten welche in der TND Datei niedergeschrieben sind und welche anschlie end in die Klassenstruktur ber nommen werden m ssen bevor etwas visualisiert werden kann in Pixelkoordinaten umgerechnet werden F r die Umrechnung ben tigt man zuerst einmal folgende Daten e die kleinste gr te x Weltkoordinate xmin zmax e die kleinste gr te y Weltkoordinate ymin ymar e die kleinste gr te x Pixelkoordinate Prmin Pxmaz e die kleinste gr te y Pixelkoordinate Pymin Pymax Diese Werte werden berechnet indem einmal nach dem Einlesen einer TND Datei und vor der ersten Visualisierung ber alle Hardwareelemente nach diesen Werten gesucht
169. GO LEFT Position Bit 2 Anforderung fiir GO RIGHT Position Bit 15 Anforderung in einen Fehlerzustand zu wechseln und die Ausfiihrung zu beenden Die Bits 3 14 sind nicht definiert und miissen vom Treiber ignoriert werden Ausgabebereich KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 176 Analog zum Eingabebereich signalisiert der Wert im Ausgabebereich den aktuellen Sta tus der vom Treiber gesteuerten Weiche Ahnlich wie beim Eingabebereich darf auch im definierten Ausgabebereich prinzipiell nur ein Bit gesetzt sein allerdings ist es m glich sowohl einen Positionszustand als auch einen Fehlerzustand gleichzeitig abzubilden in diesem Fall sind zwei gesetzte Bits erlaubt Die folgenden Bits sind fiir den Ausgabebereich definiert Bit 0 aktuelle Position ist STRAIGHT POS Bit 1 aktuelle Position ist LEFT POS Bit 2 aktuelle Position ist RIGHT POS Bit 13 Fehlerzustand OFF Bit 14 Fehlerzustand INVALID Bit 15 Fehlerzustand FAILURE Die Bits 3 12 sind nicht definiert und miissen vom Steuerinterpreter ignoriert werden Die verschiedenen Fehlerzust nde haben folgende Bedeutungen OFF Die Ausf hrung des Treibers wurde beendet es werden keine Anforderungen mehr ausgef hrt INVALID Die letzte Anforderung war ung ltig z B weil Bit 1 und Bit 2 gleichzeitig gesetzt waren FAILURE Ein Hardwarefehler wurde erkannt 7 5 3 1 3 Kreuzungsweichen Slipswitches Diese Spezifikation gilt f r aktive Weichen die aus zwei bzw vier 2 Wege
170. Gleisnetz verwendeten Hardwareelemente und die f r die Steuerung relevanten Eigenschaften Jedem mit dem Steuersystem in Verbindung stehenden Element Sensoren Weichen Signale muss der genaue Hardwaretyp sowie dessen Schaltzeit Signale Weichen bzw Reaktionszeit Sensoren zugeordnet sein Zum oben verwendeten Routenbegriff folgende Definition Als Route wird eine zusam menh ngende Folge von Gleisst cken betrachtet die von zwei Sensoren begrenzt wird Eingangs und Ausgangssensor und vor der sich ein Finfahrtssignal befindet Eine Bahn kann demnach eine Route in einem Zug durchfahren Ein Gleisst ck kann zu mehreren Routen geh ren Wenn dieser Fall auftritt stehen die ber dieses Gleisst ck f hrenden Routen miteinander in Konflikt 2 35 Annahmen An ein von unserem System zu steuerndes Gleisnetz werden bestimmte Bedingungen gestellt Diese werden nun aufgef hrt In Bezug auf Sensoren und Signale werden an das Gleisnetz folgende Bedingungen ge stellt e Alle Routen die dasselbe Einfahrtssignal haben m ssen von demselben Route Request Sensor RR Sensor verwaltet werden oder von einem jeweils eigenen die dann aber so nah zusammenliegen m ssen dass sie als Gesamtheit die u a Be dingung an die Elementabfolge und distanz f r den Beginn einer Route erf llen e Jede Route darf nur von einem RR Sensor verwaltet werden KAPITEL 2 DIE DOMANE 26 Der Ausfahrtssensor einer Route muss so weit von der letzten Kreuzung ode
171. Gr e unseres Gleisnetzes gesamtes Stra enbahnnetz einer Stadt erkl rt werden Auch muss te unser Aufgabenbereich insofern eingegrenzt werden als dass wir uns nur um die sichere Steuerung der Stra enbahnen selber k mmern alle anderen Verkehrsteilnehmer aber au er Acht und somit der Verantwortung des Fahrers berlassen Dar berhinaus sagten wir zu auf vorgefertigte Schnittstellen zur HW zur ckgreifen zu wollen was zu dem Zeitpunkt in Frage stand Vortrag von Herrn Hatesaul zur Schienen Fahrzeugtechnik und Beantwor tung des Fragenkatalogs Generell hat jede Stra enbahn einen Joystick mit dem der Fahrer ber eine Sende spule im Bordcomputer Ibis Wagenbus und eine Empfangsspule Weichen nach rechts links oder geradeaus gesteuert werden k nnen Die Lichtsignalanlagen werden durch Ber hrung von Kontakten an den Oberleitungen geschaltet Hier greift kein zentrales System ein jede Weiche l sst sich nur dann bedienen wenn keine andere Stra enbahn auf ihr steht oder sie schon gestellt hat Die Eingabe der Routen geschieht derzeit noch per Datenfunk nach der Umstellung auf das neue Zugsteuerungssystem werden aber alle Daten morgens per CD in den Bordcomputer gespielt so dass die Weichen automatisch gestellt werden w hrend der Fahrer weiterhin jederzeit manuell steuern kann und so auch weiterhin die Verantwortung tr gt So wird auch keine automatische Zwangsbrem sung ausgel st Der Befehl eine Weiche zu stellen wird in dem sog
172. Hilfe des bereits im Konzept genannten Tools CUP werden der eigentlich Parser Parser java sowie zus tzlich die Datei Sym java generiert letztere ist f r die Kommunikation zwischen Lexer und Parser notwendig Nun folgt der fiir unser Beispiel ben tigte Auszug aus der Spezifikation des Parsers 01 tnd defblock coordblockopt 02 03 defblock DEFINITIONS GKA GKZ 04 DEFINITIONS GKA deflist GKZ 05 06 deflist typedef 07 typedef deflist 08 09 typedef sensdef 10 11 sensdef senstype type DOPPELPUNKT senslist list SEMIKOLON 12 for int i 0 i lt list size i 13 BestTramNetworkBuilderOfTheUNIverse addSensor String list get i type 14 15 16 17 senslist SENSID id 18 RESULT new ArrayList 19 RESULT add id 20 21 SENSID id KOMMA senslist list 22 list add id 23 RESULT list 24 25 26 senstype TGSENSORS type 27 RESULT type 28 29 30 coordblockopt coordblock 31 empty 32 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 376 33 coordblock COORDINATES GKA GKZ 34 COORDINATES GKA coordlist GKZ 35 36 coordlist coorddef 37 coorddef coordlist 38 39 coorddef coordtype id DOPPELPUNKT coord coords SEMIKOLON 40 BestTramNetworkBuilderOfTheUNIverse setCoords id coords 41 3 42 5 43 coordtype SENSID id 44 RESULT id 45 iF 46 47 coord KA COOR
173. I Es werden w hrend der Pause nat rlich keine Stellanweisungen umgesetzt was Auswirkungen auf den Ablauf im SI haben kann Jedoch l uft die Zeit auch in Pausen weiter so dass nach der Pause umgehend alle Stellanweisungen umge setzt werden die in der Zeit der Pause h tten umgesetzt werden m ssen Stellbefehle die in der Pause eingehen werden als direkt nach der Pause eingegangen betrachtet was entsprechende Auswirkungen auf den Zeitpunkt ihrer Umsetzung hat Verl sst eine Bahn das Netz und wird dadurch die konfigurierte Zahl an Bahnen un terschritten wird eine neue Bahn in das Netz einfahren Diese wird bei einer detailliert konfigurierten Simulation die gleiche Route befahren wie die verschwundene Bahn Neben dem Normalfall gibt es nat rlich auch noch den Fehlerfall der zum Abbruch der Simulation f hrt Eine so gestoppte Simulation kann auch nicht fortgesetzt werden es muss in dem Fall eine neue Simulation begonnen werden Erkannte Fehlerf lle sind e Es tritt eine Kollision auf KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 418 e Es wird eine Stellanweisung gegeben die vom angesprochenen Element hardwa reseitig nicht umsetzbar ist e Eine Bahn wird von der spitzen Seite auf eine Weiche geleitet die sich im Schalt zustand undefined befindet Dieser Zustand kann allenfalls am Anfang auftreten wenn f r das Element noch keine Schaltanweisung gegeben worden ist e Eine Weiche wird umgestellt w hrend eine Bahn anwese
174. IV has_conflict 1 if has_conflict 0 rst curr_route RST_AKTIV tram_count curr_route 1 if longer_queue qpl i queues qp1 i longer_elen longer_queue 1 longer_elem 1 else queues qp1 i 1 if i 0 left_queues 1 else left_queues 0 j i while j lt pdata gt rd_data gt max_queues 1 tmp qpl j apl j qpl j 1 qapl j 1 tmp 475 i else if left_queues gt pdata gt rd_data gt max_queues rst curr_route RST_ANGEFORDERT stop 1 else rst curr_route RST_ANGEFORDERT 7 7 5 2 4 Testchecker Zum Schluss wird dann noch eine Funktion ben tigt die die von SUT und Orakel gelieferten Outputs vergleicht Diese seiht in diesem Fall wie folgt aus KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 285 this is the checker comparing the SI outputs with the expected ones int compare_results int retval 1 int i for i 0 i lt pdata gt rd_data gt max_routes i if rst i RST_INAKTIV amp amp si_rst i RST_INAKTIV if comp_debug printf ERROR SI has route d at state d while checker has it at state d n i si_rst i rst i retval 0 else if rst i RST_ANGEFORDERT amp amp si_rst i RST_ANGEFORDERT if comp_debug printf ERROR SI has route d at state d while checker has it at state d n i si_rst i rst i retval 0 else i
175. Klasse w hrend des KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 101 Erzeugens der TND Beschreibung erledigt wird da bisher nur eine Grobsortierung z B alle Signale in globale Kategorien vorgenommen wurde In den Objekten sind bereits alle notwendigen Daten enthalten aber es wurde eben bisher nur eine Vorsortierung vorgenommen Auch werden Signale im Gegensatz zu anderen Elementen in besonderer Weise in der TND Darstellung repr sentiert so dass auch hier noch etwas an Aufbereitungsbedarf besteht bevor im n chsten Schritt die Bl cke zu einer TND Datei zusammengesetzt werden k nnen Auch dies wird hier gemacht Intern wird die TND als eine Aneinanderreihung von diversen Zeichenketten repr sen tiert welche im finalen Schritt in die zu erzeugende Datei geschrieben werden Da aus dem Netzgraphen nicht alle f r ein steuerbares Gleisnetz ben tigten Informa tionen gewonnen werden k nnen genau betrifft dies die Routeninformationen und die Hardwareklassendefinitionen werden jene Bl cke leer gelassen so dass die TND auch ohne diese Informationen einer formalen G ltigkeit entspricht Sinnvoll steuerbar ist das so dargestellt Gleisnetz allerdings noch nicht so dass die dazu fehlenden Informa tionen von einer weiteren Teil Komponente geliefert werden m ssen siehe dazu TND Builder 7 3 auf Seite 123 Die Detailansicht des Klassendiagramms f r diese Klasse Abb 7 12 auf der vorherigen Seite zeigt die zur Verwendung kommenden Methoden u
176. MPONENTEN 1 2705 esac g4128_cond_1 case wi018 state STRAIGHT amp g4128 ctr lt g4125 ctr w1020 state RIGHT amp g4128 ctr lt g4127 ctr 1 2 05 esac g4129_cond_1 case s3014 state STOP amp rr_i1_next_tram no 1 1 0 esac g4130_cond_1 case w1020 state STRAIGHT amp g4130 ctr lt g4127 ctr w1022 state STRAIGHT amp g4130 ctr lt g4129 ctr 1 0 esac 7 6 4 4 4 Bedingungen zum Zur cksetzen der Z hler 1 t 1 222 Der Z hler eines Sensors soll wieder zur ckgesetzt werden wenn eine Route zu der der Sensor geh rt wieder in den Zustand INACTIVE bergeht Dies ist der Fall wenn die Bedingung erf llt ist dass die Route in den Zustand INACTIVE wechseln soll und gleichzeitig nicht die Bedingung erf llt ist dass die Route in den Zu stand ACTIVE wechseln soll W ren beide Bedingungen erf llt dann w rde die Route den Zustand ACTIVE annehmen Dies kann passieren wenn eine weitere Bahn die betreffende Route befahren m chte Der Z hler des Sensors g4125 soll in dem Beispiel zur ckgesetzt werden wenn die Route ro oder die Route r1 in den Zustand INACTIVE bergeht g4125_cond_2 case rO_inactive_cond amp rO_active_cond 1 ri_inactive_cond amp ri_active_cond 1 1 0 esac g4126_cond_2 case ri_inactive_cond amp ri_active_cond 1 r3_inactive_cond amp r3_active_cond 1 1 0 esac g4127_cond_2 case r4_inactive_c
177. Main Menu Load TND gelangt man zu einem Dateiauswahldialog in dem man eine TND Datei ausw hlt die geladen werden soll Nach der Auswahl baut sich umgehend das Gleisnetz auf der Darstellungsfl che auf KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 416 War die geladene Datei nicht im korrekten Format erscheint eine Fehlermeldung Der Bediener muss dann eine neue Datei laden Wir gehen an dieser Stelle aber vom erfolgreichen Laden aus ein Gleisnetz ist auf der Darstellungsflache zu sehen Nun hat der Bediener die M glichkeit zwischen zwei Op tionen zu w hlen e nur Anzahl der Bahnen vorgeben e detaillierte Konfiguration aller Gleisnetzelemente und Bahnen M glichkeit 1 ist erreichbar ber Options Configure Random Simulation w hrend sich die Detailkonfiguration unter Options Configure Preset Simulation verbirgt Wir nehmen an dieser Stelle die detaillierte Konfiguration Es erscheint ein Fenster zur Bestimmung der Bahnanzahl Gefolgt wird es von einem Dialog in dem Eigenschaften der Bahnen eingegeben werden k nnen danach erscheint der Dialog f r die Weichen einstellungen annschlie end die Sensoreinstellungen zum Schluss die Signaleinstellun gen N here Beschreibungen der verf gbaren Einstellungen finden sich im folgenden Abschnitt Entscheidet sich der Nutzer daf r nur die Anzahl der Bahnen vorzugeben muss er nur den ersten der f nf Dialoge absolvieren Ist die Konfiguration abgeschlossen ist der Zeitpunkt gekommen
178. N 253 Der Begriff Model Checking war zun chst f r alle Mitglieder der Gruppe neu Um in das Thema einzusteigen wurde das Seminar Methoden der Verifikation der Arbeitsgrup pe Rechnerarchitektur empfohlen In diesem Seminar hielten wir einen Vortrag zum Thema CTL Model Checking Bis dahin war der Begriff Model Checking immer sehr abstrakt geblieben Nach mehreren Treffen mit Prof Rolf Drechsler von der Arbeitsgruppe Rechnerarchi tektur erfuhren wir u a dass es f r uns geeignete Model Checker Tools gibt mit denen das System spezifiziert werden kann um zu berpr fen ob in dem System bestimmte Eigenschaften gelten Es wurde in der Gruppe beschlossen den Model Checker NuSMV zu verwenden da dieser unsere Anforderungen erf llt Dieser Model Checker wurde u a auch von Prof Rolf Drechsler empfohlen Das erste Arbeitspaket war die Ableitung der Sicherheitsbedingungen die im System erf llt sein m ssen In HP03a wurde schon eine Liste von Sicherheitsbedingungen ange geben Allerdings musste noch berpr ft werden ob diese korrekt und vollst ndig sind Dazu wurde eine Fehlerbaumanalyse durchgef hrt Es musste ein Modell des Systems in Form eines Transitionssystems in der Eingabe sprache des Model Checkers erstellt werden Das Modell besteht bekanntlich aus einem physikalischen Modell des betrachteten Gleisnetzes und einem Modell des Controllers Eine Beschreibung wie ein physikalisches Modell aussehen kann wu
179. ND Konverter entschieden Der Hauptgrund f r diese Entscheidung war die Tatsache dass zu jenem Zeitpunkt eben diese Sprache von allen Mitgliedern der Netzgraph Gruppe am besten beherrscht und somit erwartet wurde dass die Implementierung in dieser Sprache am effektivsten vor anschreiten w rde Da w hrend der Implementierung diesbez glich auch keine gr eren Probleme aufgetreten sind erachten wir diese Wahl im Nachhinein als richtige Entschei dung C oder C Kenntnisse waren zwar vorhanden aber die Erfahrungen beschr nkten sich zu jenem Zeitpunkt auf ein Minimum so dass eine Verwendung dieser Sprachen einen sehr hohen Einarbeitungsaufwand erfordert h tte Ein Vorteil von C C ge gen ber Java war zu jenem Zeitpunkt nicht erkennbar und ist es auch am Ende der Arbeit am Konverter nicht Java ist eine objektorientierte Programmiersprache OOP Diese Eigenschaft machen wir uns beim Auslesen der DXF Datei und auch beim Erzeugen der TND Datei zu Nut ze Da das Konvertieren einer Datei in ein anderes Format keine zeitkritische Angelegenheit ist ist es auch kein Problem Java was im Vergleich zu C bei der Ausf hrung der Programme recht langsam ist zu verwenden 7 2 3 2 2 Entscheidung gegen bersetzerbauwerkzeuge Im Verlaufe der ers ten Semesterh lfte des dritten Projekt Semesters wurde au erdem endg ltig die Ent scheidung getroffen beim Einlesen der DXF Daten auf die Verwendung von berset zerbauwerkzeugen zu verzi
180. NSERTs innerhalb der BLOCKS SECTION Bei LINE kommt auch noch der 2 Koor dinatensatz 11 21 31 als Endpunkt hinzu Ebenfalls ist immer das Layer 8 definiert Der Code 40 ist sowohl bei TEXT als auch bei CIRCLE zu finden Bei TEXT gibt es noch die Textbreite 41 und nat rlich den Wert 1 Der Drehwinkel ist bei TEXT und INSERT Entities i d R auch vorhanden 50 Weitere Codes oder Tags sind teilweise auch noch vorhanden oder sie sind optional N heres ist der DXF Reference Aut03 zu entnehmen In s mtlichen bekannten untersuchten Versionen des DXF Formats hat sich an der ei gentlichen Syntax nichts ge ndert Die Versionen sind abw rtskompatibel Wir verwenden keine der neueren Codes und brechen die DXF Datei sozusagen auf ein rudiment res Format herunter in dem keinerlei der neueren Verwaltungsinformationen vorkommen Mit QCAD ist eine solche vereinfachte DXF Datei darstellbar Sollten an dere CAD Programme dies nicht k nnen so muss eben QCAD verwendet werden Henrik R hrup ANHANG B DXF DATEI FORMAT 461 B 2 Vereinfachte DXF Grammatik Die Darstellung ist nicht vollkommen korrekt im Sinne einer EBNF Form Da sie ein Nebenprodukt der berlegungen bzgl des Einsatzes von CUP Parser Generator for Java ist welches aber beim Netzgraphen doch nicht benutzt wird ist auch diese Form der Grammatik nicht mehr in Benutzung so dass sie nicht weiter ausformuliert wurde Sie dient daher auch nur zur allgemeinen Veranschaulichung des
181. ONENTEN 138 route02 route04 route05 route06 route07 route08 route03 route08 routel2 Zus tzlich werden vom TRACS Steuerinterpreter Informationen ben tigt welche Route an welchem Sensor angefordert werden kann Da dies mehrere Routen pro Anforde rungssensor sind werden gegebenenfalls auch Anforderungs Warteschlangen ben tigt Auch diese Informationen werden dem TRACS Steuerinterpreter in bin rer Form zur Verf gung gestellt Ein Beispiel verdeutlicht dies routedefinitions route01 g4101 g4105 request at g4001 route02 g4101 g4107 request at g4001 route03 g4101 g4102 request at g4001 F r detailliertere Informationen zur TND Tram Network Description welche die Ein gabe f r den tram Compiler bildet wird auf Abschnitt 7 1 verwiesen 7 4 2 2 Ausgabedaten Die Ausgabedaten des tram Compilers bilden die bin ren Projektierungsdaten die ein TRACS Steuerinterpreter zum sicheren Steuern eines Gleisnetzes ben tigt Diese sind in drei zentrale Bl cke aufgeteilt die vom tram Compiler separat generiert werden Diese drei Komponenten der Projektierungsdaten entsprechen der Projeketierung der drei zen tralen Komponenten des TRACS Steuerinterpreters F r genauere Informationen zum TRACS Steuerinterpreter und dessen Architektur wird auf Abschnitt 7 5 verwiesen 7 4 2 2 1 Projektierung des Route Dispatcher Der Route Dispatcher des TRACS Steuerinterpreters entscheidet zur Laufzeit anhand der vorliegenden B
182. P NuSMV gt simulate r 2 Simulation Starting From State 1 1 k e NuSMV gt show_traces v HEFHHHHHHAHHHHHHHHHE Trace number 1 HHHHHHHHHHHEHHH gt State 1 1 lt safe 1 g2_reachable 0 gi_reachable 1 si GO s2 STOP gt State 1 2 lt safe 1 g2_reachable 1 gi_reachable 0 si STOP s2 GO gt State 1 3 lt safe 1 g2_reachable 0 gi_reachable 1 si GO s2 STOP NuSMV gt goto_state 1 3 The starting state for new trace is gt State 2 3 lt safe 1 g2_reachable 0 gi_reachable 1 si GO s2 STOP Eine ausf hrliche Beschreibung ist ebenfalls in CCO zu finden Ruben Rothaupt Taffou Happi 7 6 4 berpr fung des Systemmodells In diesem Abschnitt soll das Modell des Systems dargestellt werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 214 Dazu wird das Verhalten der Sensoren der Weichen und der Signale modelliert Zudem wird modelliert wann eine Route welchen Zustand annimmt und wann eine Route ange fordert werden kann Schlie lich folgt noch die Spezifikation der Sicherheitsbedingungen die in dem jeweiligen Gleisnetz gelten m ssen 7 6 4 1 Beispiel Das Modell wird anhand eines Beispiels erl utert Als Beispielgleisnetz wird die Teil strecke 4 der Teststrecke verwendet die in Abbildung 7 47 zu sehen ist Aus der Gleisnetzbeschreibung kann das physikalische Modell erstellt werden Unten werden die Verschlusstabellen f r das Beispiel a
183. RANCE hier kann eine Bahn in das Gleisnetz gelangen oder es verlassen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN EXIT hier kann eine Bahn das Gleisnetz verlassen aber nicht hineingelangen NONE hier keine Ein oder Ausfahrt also z B Prellbock totes Ende etc Beispiel relations g100 A entrance g200 A entrance g300 A entrance g400 A entrance g100 B g101 A g200 B g201 A g300 B x1 g301 A g400 B g401 A g104 B exit g203 B exit g304 B exit g405 B exit k1 A g102 B k1 B g103 A k1 C g403 B k1 D g404 A k2 A g103 B k2 B g104 A k2 C g201 B k2 D g202 A k3 A g301 B k3 B g302 A k3 C g202 B k3 D g203 A k4 A g402 B k4 B g403 A k4 C g302 B k4 D g303 A w1 Y g101 B w1 S g102 A w1 R g105 A w2 Y g304 A w2 S g303 B w2 L g406 B Y A w3 Y g405 we KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 72 w3 S g404 B w3 L g105 B w4 Y g401 B w4 S g402 A w4 R g406 A 7 1 3 2 8 SigPosBlock lt sigposblock gt lt sigposdef gt lt SIGPOSITIONS gt lt sigposdef gt lt SIGID gt lt sensid side gt lt MARKID gt lt sensid side gt Hier werden die Positionen der Signale im Gleisnetz beschrieben Blockschl sselwort ist signal positions Genannt ist die Signal ID danach gibt es zwei M glichkeiten a Das Signal steht direkt an einem Sensor In diesem Fall ist nur die Sensor ID mit der Seite genannt in die auch das Signal weist
184. REIBUNG DER KOMPONENTEN 123 7 3 TND Builder 7 3 1 berblick Im Rahmen des Projektes wurde ein GUI Werkzeug erstellt damit der Benutzer die Routen auf einfache Weise definieren kann Die definierten Routen werden dann in der TND gespeichert So wird eine endg ltige TND Datei erstellt die der Compiler weiterverarbeiten kann Dieses Softwarewerkzeug bezeichnen wir als TND Builder Der TND Builder hat folgende Eigenschaften e Fr ist f r unterschiedliche Gleisnetze wiederverwendbar e Durch Intergration des CAD TND Konverters kann die CAD Zeichendatei direkt in die TND konvertiert und weiter bearbeitet werden e Bei ungiiltigen Routendefinitionen erfolgt eine Fehlermeldung e Der TND Builder ist fiir unterschiedliche Platformen verwendbar Die Software ist in Java implementiert Deng Zhou 7 3 2 Funktionsbeschreibung 7 3 2 1 Ein und Ausgabe Der TND Builder hat zwei Eingabem glichkeiten Die erste M glichkeit besteht darin eine CAD Datei einzulesen und in das TND Format umzuwandeln Die CAD Datei soll dabei in QCad erstellt werden und verwendet unsere Zeichen Bibliothek Die zweite M glichkeit besteht darin eine bereits existierende TND Datei direkt einzulesen Die Ausgabe des TND Builders ist eine vollst ndige TND mit Routendefinition Diese TND Datei ist f r den Compiler direkt verwendbar 7 3 2 2 Bestandteile einer TND Datei Eine TND Datei besteht aus zwei Teilen e Der erste Teil beinhaltet alle Hardwareelemente di
185. REIBUNG DER KOMPONENTEN 396 Thread sleep 100 catch Exception e Anschlie end l uft in einer Endlosschleife der folgende Vorgang Es wird gepr ft ob eine Anfrage durch einen externen Prozess am Server Port vorliegt Sobald diese erfolgt wird die Verbindung angenommen und der entstandene Client Socket in Form eines SocketChannel der Liste der ClientSockets hinzugef gt Eben falls wird ein Lesepuffer f r ihn angelegt Anschlie end wird ber alle vorliegenden Cli entSockets iteriert Befindet sich im zugeh rigen Lesepuffer ein Zeilenende Zeichen so wird davon ausgegangen dass es sich um eine komplette Meldung des angeschlossenen Treibers handelt Diese wird aus dem Puffer entfernt und nachfolgend auf ihren Typ berpr ft Ist es ein Init Request werden die Daten ber den neuen Treiber f r welches HW Element ist er zust ndig unter welchem Port wartet er auf Meldungen in der daf r vorgesehenen Liste abgelegt Ist es dagegen eine Anforderung auf Zustands nderung des Elements wird der String mittels addRequest der Liste der Anfragen hinzugef gt Ent spricht der String keinem der beiden vorgesehenen Formate wird er verworfen Als letz ter Schritt in der Iteration ber die Sockets wird nun versucht etwas aus dem Socket zu lesen und dem zugeh rigen Puffer hinzuzuf gen Sollte der Socket inzwischen geschlossen sein werden die Eintr ge in der Liste der Sockets und der Puffer entfernt Anschlie end wird der n chste
186. Report StringTokenizer st new StringTokenizer report try String hw st nextToken hw st nextToken SocketChannel s SocketChannel drivers get new Integer hw if s isConnected drivers remove new Integer hw s null KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 401 if s null try report report n CharBuffer tmpbuf CharBuffer allocate report length put report tmpbuf rewind Charset enc Charset forName US ASCII ByteBuffer bb enc encode tmpbuf int len s write bb if len lt 0 System out println write returned len addAgain report else logger info Writing report catch Exception e logger info Failed writing report addAgain report else logger info Cannot send report report gt Driver unknown catch Exception e logger info Failed writing do not try again report e printStackTrace else try Thread sleep 100 catch Exception e J Der Ablauf erfolgt auch hier in einer Endlosschleife Es wird gepr ft ob eine Meldung in der Liste vorliegt ist das der Fall wird ver KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 402 sucht den zust ndigen Treiber zu ermitteln und an diesen die Meldung abzuschicken Wird kein Treiber f r das angesprochene HW Element gefunden wird die Nachricht verworfen scheitert etwas beim Sendevorgang selbst wird die Meldung
187. Route State Table KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 278 e die Bahnz hler f r jede Route e der Z hler wie oft die erste Queue bersprungen wurde Vom SHM Zustand werden lediglich die Route Request Sensoren betrachtet und da auch nur ob sie ausgel st haben es muss also nicht jeder beliebige SHM Zustand hergestellt werden Im Gegenteil k nnen wir hier die Zahl der Testf lle massiv verringern indem wir pro Testfall entweder keinen oder nur einen RR Sensor als ausgel st setzen Da das einzige was mit ausgel sten RR Sensoren geschehen soll im Zur cksetzen des Sensors und Aufnahme der angeforderten Route in die zugeh rige Queue ist wobei Sensor f r Sensor nacheinander abgearbeitet wird kann man sich diesen Abschnitt des RD als Un terprozess vorstellen der als Eingabe den Zustand der RR Sensoren und der Queues hat Beziehungsweise da nacheinander gearbeitet wird ist f r jede einzelne Entschei dung nur der Zustand eines RR Sensors und der ihm zugeh rigen Queue relevant Tests mit einer beliebigen Zahl gesetzter RR Sensoren lassen sich prinzipiell daher alle auf solche mit nur einem oder keinem gesetzten RR Sensor zur ckf hren bzw w rden diese nur wiederholen Die Projektierungsdaten und die Zuordnung von Routen zu Queues sind f r ein Gleisnetz konstant m ssen also vom Testgenerator nicht variiert werden Die Queue Zust nde werden ebenfalls nicht v llig durchkombiniert es wird nur das erste Element jeder Queue var
188. SMV Interpreter Jedes ausf hrbare NuSMV Programm muss genau ein main Modul enthalten Folgende Bestandteile eines Moduls werden sp ter ben tigt um das System zu model lieren MODULE atom atom atom atom var_declaration assign_declaration define_declaration spec_declaration checkinvar_declaration In der var_declaration Umgebung werden Variablen erzeugt die Transitionsbedingun gen der Variablen werden in der assign_declaration Umgebung definiert und in der defi ne_declaration Umgebung werden zus tzliche Definitionen ausgedr ckt Schlie lich wer den in der spec_declaration Umgebung und der checkinvar_declaration Umgebung die zu pr fenden Eigenschaften als CTL Formeln bzw Invarianten spezifiziert 7 6 3 1 1 var_declaration Die f r die Modellierung des Systems ben tigten Varia blen werden in der var_declaration Umgebung erstellt die mit dem Schl sselwort VAR eingef hrt wird Variablen werden auf folgende Arten definiert e var boolean Die Variable var ist vom Typ boolean und kann die Werte 0 und 1 annehmen die false bzw true repr sentieren KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 208 e var 0 9 Die Variable var kann Werte innerhalb eines definierten Zahlenbereiches annehmen hier von 0 bis 9 e var value_l value_n Es wird eine beliebige Anzahl von Begriffen definiert Die Variable var nimmt jeweils einen dieser Begriffe an e var module p
189. Sektionen Abschnitte aufgeteilt Jede Sektion erf llt ih ren eigenen Zweck So gibt es zum Beispiel die Sektion ENTITIES in der die einzelnen Elemente oder ein Verweis auf eine Gruppe von Elementen Block einer Zeichnung definiert sind Die Sektion BLOCKS beinhaltet eben solche Gruppen von Elementen sogenannte Bl cke Die Sektionen selbst sind ebenfalls untergliedert wobei die Anzahl dieser Unterteilungen von der Anzahl der Elemente f r die Sektion ENTITIES oder Bl cke BLOCKS abh ngt In jeder dieser Unterteilungen sind alle zusammengeh ri gen Code Wert Zeilenpaare enthalten Die genaue Reihenfolge ist nicht weiter definiert Ebenso m ssen nicht alle Codes welche z B zu einem Zeichenelement geh ren enthal ten sein da sie m glicherweise optional oder mit Standard Werten vorbelegt sind Dar berhinaus gibt es noch die Sektionen HEADER und TABLES Genauere Informationen sind der DXF Referenz Aut03 zu entnehmen Die DXF Dateien k nnen ohne CAD Programm mit normalem Texteditor ge ffnet wer den und der Inhalt der Dateien ist lesbar Das bedeutet man kann relativ einfach die Informationen aus den DXF Dateien bekommen egal ob ein CAD Progamm verf gbar ist oder nicht Es ist allerdings die angesprochene DXF Referenz notwendig um das Format als solches verstehen zu k nnen stark berarbeitete Fassung Henrik R hrup 7 2 3 Arbeitspakete Die Arbeitspakete der Netzgraph Gruppe sind in zwei wesentliche Bereiche einzuteilen
190. Sensor 0 die Route rO angefordert hat und diese Anforderung in der Warteschlange die zu Route Request Sensor 0 geh rt an der ersten Position ist dann soll ro den Zustand ACTIVE annehmen sofern die Konfliktrouten r1 r3 r4 und r5 im Zustand INACTIVE sind Die Variable rr_O_next_tram steht dabei fiir die Anforderung die sich an der ersten Position der zu Route Request Sensor 0 geh rigen Warteschlange befindet rO_active_cond case rr_O_next_tram r0 ri state INACTIVE r3 state INACTIVE r4 state INACTIVE r5 state INACTIVE 1 1 0 esac P PYP ri_active_cond case rr_O_next_tram r amp rO state INACTIVE amp rO_active_cond amp r3 state INACTIVE 1 1 0 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN P PP P PP esac r2_active_cond case rr_1_next_tram r2 r3 state INACTIVE r4 state INACTIVE te Q esac r3_active_cond case rr_i_next_tram r3 r0 state INACTIVE ri state INACTIVE r2 state INACTIVE r4 state INACTIVE 1 0 esac r4_active_cond case rr_2_next_tram r4 rO state INACTIVE r2 state INACTIVE r3 state INACTIVE r5 state INACTIVE 1 0 esac r5_active_cond case rr_2_next_tram r5 rO state INACTIVE r4 state INACTIVE 1 2 0 esac 7 6 4 5 4 Routenzustand LOCKED Eine Route soll in den Zustand LOCKED amp IrO_active_cond amp Iri_active_cond amp Ir2_active_cond amp 15 IrO_active_cond amp Ir2_active_cond amp Ir3
191. Signal h ngen geblieben ist muss der SI dann auf verschiedenste Weise das Gleisnetz wieder sicher machen eigenm chtige Schaltungen In diesem Fehlerfall wird das Signal sich spontan umschalten Wann und wie oft es schaltet wird im Programmlauf zuf llig bestimmt Auch hier muss dann der SI reagieren KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 358 Zu beachten ist dass die Elemente durch Anwahl der oben erkl rten Optionen zun chst in einen internen Zustand bergehen der besagt dass der angew hlte Fehler auftreten kann Solche als ausfallgef hrdet bestimmte Elemente werden w hrend des Programm laufs dann an zuf lligen Zeitpunkten in das tats chliche Ausfallverhalten bergehen Dagegen werden Elemente bei denen keine Fehleroption angew hlt wurde ihr korrektes Verhalten im gesamten Simulationslauf beibehalten Weiterhin soll die M glichkeit geboten werden auch die Elemente die ausfallen sol len zuf llig ausw hlen zu lassen Dies ist dann auch die einzige M glichkeit Ausf lle in Simulationen vorkommen zu lassen die ber oben beschriebene Zufallskonfiguration gestartet wurden da bei dieser ja keine Startkonfiguration der einzelnen Elemente er folgt Hierf r wird im Hauptmen des Simulators eine ein und ausschaltbare Option Random Defects geboten die bei laufendem Betrieb beliebig bet tigt werden kann Ist sie eingeschaltet k nnen beliebige Hardwareelemente spontan in den ausfallgef hrde ten
192. Socket berpr ft und wenn alle Sockets durchlaufen wurden beginnt die Endlosschleife von neuem public boolean checkRequest String request String actToken StringTokenizer st new StringTokenizer request if st countTokens 3 return false else actToken st nextToken if actToken equals request return false else actToken st nextToken switch actToken charAt 0 case 1 if actToken length 4 return false KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 397 else actToken st nextToken if actToken equals quit actToken equals left actToken equals straight actToken equals bent actToken equals right return true else return false case 2 if actToken length 4 return false else actToken st nextToken if actToken equals quit actToken equals straight actToken equals bent return true else return false case 3 if actToken length 4 return false else actToken st nextToken if actToken equals quit actToken equals left actToken equals right actToken equals straight actToken equals stop actToken equals waitright actToken equals waitstraight actToken equals waitleft actToken equals rrrighton actToken equals rrlefton actToken equals rrstraighton KAPITEL
193. TRACS Abschlussbericht Andreas Kemnade Arne Stahlbock Deng Zhou Helge L ding Henrik R hrup Marcin Dysarz Marius Mauch Taffou Happi Ruben Rothaupt Waldemar Wockenfu ehemalige Teilnehmer Feng Zheng Jonas Jokovic Li Qiu Jinghong Jin Jun Liang Niklas Polke Silvia Graumann Susanne Spiller Thomas Harlos Wei Han Xiaobo Chen 30 09 2005 Train Control Systems Universitat Bremen Betreut von Dr Jan Bredereke Dr Ulrich Hannemann Arbeitsgruppe Betriebssysteme Verteilte Systeme Inhaltsverzeichnis 1 Einleitung 14 Einf brune in TRAGSA s e OOo ee ORY er Oa Car Oe Se a 12 Die Dom ne 22 oo nn onen 1 3 Problembeschreibung we 2 GA ty 2 a Gay er ee 1 4 Der L sungsansatz ee in eb ee a hd ec dl 1 5 Entwicklungsprozess 24 ae tale ae Bi N pie end 1 6 Verilikationsprozess 2 52 wur hoben an es 1 7 Sicherheitsnachweis 2 CC m m nn ne 18 VBREWESTLUNE an Ne aan nr ek ea RL we Gem Aa 2 Die Dom ne Qik Einleitung ir gai ae as Soot are Ge a ee Bed aks ge AE a a ck aS 2 2 Die Umwelt aaia 2 0 0 32 2 2008 8 2 are ee te lar 22 STATS ETO ca dh a ee an De Ae aR 2 2 2 Textuelle Beschreibung 1 2222 22H a As ar 2 3 Die Technik rne ei a cache Se en erlernte es 2 3 1 berblick ar ah en ae ie een ehe 2 3 2 Gleisnetzelemente 0 0 0000000000008 8 23 9 Ste rsystemi 2 5 aig big ae ae o pete bp get eke 2 2 3 4 Gleisnetzdaten 2 nn 23 8 Annahmen Sa a Bak oe Bs a Ee all he 2 307 A
194. Test Language Scanner s Lexer SHM s Shared Memory Shared Memory kurz SHM Eine vom Betriebssystem unterst tzte Methode zur Kommunikation von mehreren Prozessen untereinander Hierbei k nnen s mtliche be teiligten Prozesse auf einen gemeinsamen Adressbereich zugreifen Signal Setting Table Beschreibt die Stellung von Signalen die f r die Einfahrt einer Route notwendig sind Software Integrationstest kurz SWI Testet Softwarekomponenten die sich gegen seitig beeinflussen Dabei wird das Ein und Ausgabeverhalten der Software getestet Spline Eine Kurve die durch eine bestimmte Anzahl von Punkten verl uft und diese m glichst glatt miteinander verbindet Interpolation Socket Als Socket bezeichnet man eine streambasierte Programmierschnittstelle zur Kommunikation zweier Rechner in einem TCP IP Netz Sockets wurden mit Ber keley UNIX 4 1 4 2 allgemein eingef hrt Das bertragen von Daten ber eine Socket Verbindung hnelt dem Zugriff auf eine Datei Kr 00 S 1057 stem s branch Steuerinterpreter Ein Programm das die Projektierungsdaten interpretiert und die Steuerungsaufgaben f r verschiedene Hardware Elementen erf llt SWI s Software Integrationstest Systemintegrationstest Systemintegrationstests testen ein komplettes System in nerhalb seiner operationalen Umgebung oder einer Simulation davon Test berpr fung ob das implementierte Steuerungssystem die erwartete Aufgabe
195. Tools Der DXF CAD nach TND Konverter kann auf verschiedene Weise aufgerufen werden So ist es zum Beispiel m glich f r Debuggung Zwecke die jeweiligen Schritte einzeln manuell zu starten Oder aber es wird eine DXF Datei in einem Durchgang in eine Basis TND Datei berf hrt was die empfohlene Methode ist Es ist au erdem m glich sich eine komplette Liste aller Elemente in Textform ausgeben zu lassen Im Folgenden sollen nun die einzelnen Aufrufe beschrieben werden Es wird dabei ange nommen dass man sich in der Verzeichnisebene befindet in der das Verzeichnis ng zu finden ist welches s mtliche Programmdateien des Konverters enth lt Die einzelnen Teilprogramme sind DXFSeparator java NDDatacollector java und TNDCreator java TracsDXF2TND java ist jenes Program welches alle Schritte in einem vereint 7 2 4 4 1 DXFSeparator Der erste Schritt in der Konvertierung ist das Separieren der f r den Konvertiervorgang relevanten von den irrelvanten Informationen einer DXF Datei Diese Trennung wird durch das Programm DXFSeparator java durchgef hrt Der Aufruf ist ganz einfach Es wird dem Programm einfach die zu konvertierende DXF Datei bergeben und man erh lt im aktuellen Verzeichnis zwei Zwischendateien mit den Namen blocks tmp tng und entities tmp tng Diese beiden Dateien enthalten die beiden Sektionen einer DXF Datei welche f r uns von Relevanz sind Au erdem sind in dem Trennvorgang schon einige zus tzliche nicht ben tigte I
196. Tram Instanz gespeichert um sp ter f r den Simulator abrufbar zu sein Tram drived simulation stopped move true lt gt check stop amp signals else move true calculate next position Ce drive into other tram move true move tram check head collision on new track true check other collision else do finishing things reduce missing steps Abbildung 7 69 Aktivit tsdiagramm Tram drive Tram drive drive enth lt den Ablauf was passiert wenn eine Stra en bahn um genau einen Schritt weiter fortbewegt werden soll Falls die Bahn nicht im Modus Signale nicht beachten ist wird nach m glichen Haltesignalen geschaut und gepr ft ob die Tram aufgrund eines Signals halten muss s checkStop KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 348 Wenn die Stra enbahn halten muss ist die Methode beendet Wenn nicht wird mit calculatePosition die neue Position der Bahn errechnet Dann wird gepr ft ob die Stra enbahn an der neu errechneten Position auf eine andere Tram auffah ren w rde drivelnto Ist dies der Fall so bricht die Methode ab Ansonsten wird die Tram auf die neue Position bewegt Dann erfolgt die berpr fung ob es aufgrund eines Fehlers vom Steuerinterpreter zu einem Zusammensto gekommen ist Zuerst wird gepr ft ob zwei Stra enbahnen frontal zusammen gesto en sind s checkHeadCollision Danach wird gepr ft ob die Tram
197. VAR state INACTIVE ACTIVE LOCKED ASSIGN init state INACTIVE next state case lock_cond LOCKED KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 224 active_cond ACTIVE inactive_cond INACTIVE 1 state esac 7 6 4 5 2 Initialisierung der Variablen F r alle definierten Routen werden Va riablen erstellt Dazu wird jeweils das Modul route aufgerufen und als Parameter wer den die drei erw hnten Bedingungen bergeben die ausdr cken wann eine Route den jeweiligen Zustand annehmen soll rO route r0_active_cond rO_lock_cond rO_inactive_cond ri route ri_active_cond ri_lock_cond ri_inactive_cond r2 route r2_active_cond r2_lock_cond r2_inactive_cond r3 route r3_active_cond r3_lock_cond r3_inactive_cond r4 route r4_active_cond r4_lock_cond r4_inactive_cond r5 route r5_active_cond r5_lock_cond r5_inactive_cond 7 6 4 5 3 Routenzustand ACTIVE Eine Route soll den Zustand ACTIVE anneh men wenn eine Bahn die Route angefordert hat und alle Konfliktrouten im Zustand INACTIVE sind Dabei muss die betreffende Anforderung allerdings in der zu dem jewei ligen Route Request Sensor geh rigen Warteschlange an der ersten Position sein Wenn zwei Konfliktrouten zum gleichen Zeitpunkt den Zustand ACTIVE annehmen k nnten wird die Route mit der h heren Priorit t vorgezogen So befindet sich die Route r in dem Beispiel im Konflikt mit den Routen r1 r3 r4 und r5 Wenn eine Bahn bei Route Request
198. Verkn pfung der Knoten auf der gleichen Ebene e Das Plus steht f r eine Und Verkn pfung der Knoten auf der gleiche Ebene 427 KAPITEL 8 SICHERHEITSNACHWEIS 428 Eine Und Verkn pfung bedeutet dass die bergeordnete Ursache auftritt wenn alle der untergeordneten Ursachen auftreten Eine Oder Verkn pfung bedeutet dass die bergeordnete Ursache auftritt wenn min destens eine der untergeordneten Ursachen auftritt Nun soll der entwickelte Fehlerbaum vollst ndig angegeben werden Diejenigen Punkte bei denen eine Beeinflussung durch TRACS m glich ist werden mit XXX markiert Da durch dass man garantieren kann dass keiner dieser Punkte auftritt wird nachgewiesen dass die Sicherheitsanforderungen des Gesamtsystems erf llt sind Die Sicherheitsbedingungen des Gesamtsystems Strassenbahnsteuerungssystem werden nicht erfuellt 1 Kollisionen zwischen Bahnen 1 1 Auffahrunf lle 1 1 1 Fehlverhalten des Fahrers zu geringer Sicherheitsabstand 1 1 2 Sensor Signalausfall oder defekt 2 1 Sensor Signalausfall oder defekt 2 2 Nicht alle betroffenen Signale HALT XXX 1 1 3 Zu viele Bahnen auf einem Abschnitt 1 1 3 1 Zeitgleich mehr Bahnen auf einem Gleisabschnitt als maximal m glich 4 Verkehrszeichenprobleme 5 Bahn bleibt pl tzlich stehen 1 1 5 1 Stromausfall 5 1 1 Stromausfall in Teilgleisnetz 5 1 2 Nicht alle betroffenen Signale HALT XXX 1 1 5 2 defekte Bahn 1 1 6 Steuerungssystem 1 1 6
199. W hrend der Testvorbereitungsphase konzentrierten sich die Aufgaben auf folgende Aspekte e Identifikation der Testziele e Auswahl der Teststrecke e Vorbereitung der Testf lle Als die Grundlage f r diese Aufgaben diente uns die im Kapitel 7 5 auf Seite 171 ent haltene Spezifikation des gesamten Systems 7 7 4 1 Identifikation der Testziele F r Software Tests haben wir den Safety Controller SC genommen der den Route Dispatcher RD die Route Controller RC und den Safety Monitor SM beinhaltet F r jede dieser Komponenten musste ein Test Generator ein Test Orakel und ein Test Checker vorbereitet werden Um die Testf lle aus der spezifischen Gleisnetzkonfiguration generieren zu k nnen muss te au erdem eine Komponente zum Einlesen der Konfigurationsdatei in diesem Fall Projektierungsdaten erstellt werden Diese musste jedoch nur einmal hergestellt wer den um dann von allen Test Generatoren verwendet werden zu k nnen F r den Implementierungvorgang haben sich somit folgende Aufgaben herausgestellt e Implementierung des Einlesens der Projektierungsdaten e Implementierung der Testprozeduren f r die zu testenden Komponenten KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 263 7 7 4 2 Auswahl der Teststrecke Die Tests sollen m glichst originalgetreu die Realit t eines Gleisnetzes abbilden Daf r haben wir mit Hilfe der BSAG ein Beispielgleisnetz mit vier Teststrecken zusammen gestellt
200. W in TND Beschreibung vom Kunden Y Software Lo y compilieren Integration Software z EE SW HW Integration Abbildung 5 3 Erstellungsprozess bertragung der vom Kunden gelieferten Hardwarespezifikation in die TND bertragung der vom Kunden gelieferten Verschlusstabellen in die TND Erzeugen von Projektierungsdaten f r das jeweillige Gleisnetz aus der TND Erzeugen der Steuerungssoftware aus Steuerinterpreter und konkreten Projektie rungsdaten Erzeugen des Zielproduktes durch Integration der Steuerungssoftware in der Hard ware Die f r jedes Gleisnetz ben tigten Eingaben sind die Gleisnetzdarstellung im Netzgraph die Verschlusstabelleneingaben sowie die Hardwarespezifikation vom Kunden Diese Ein gaben sollen in der TND repr sentiert werden Die TND besteht also aus einer Netzwerk beschreibung einer Verschlusstabellendarstellung und einer Hardwarebeschreibung Ein Konverter erzeugt aus dem Netzgraphen die TND Netzwerkbeschreibung und die TND Hardwarebeschreibung Die in den Verschlusstabellen gemachten Angaben werden in die TND Verschlusstabellendarstellung bertragen Es wird ein Compiler entwickelt KAPITEL 5 ENTWICKLUNGSPROZESS 49 welcher aus der TND Verschlusstabellendarstellung und der TND Hardwarebeschrei bung die Projektierungsdaten fiir das jeweilige Gleisnetz erzeugt Die Projektierungs daten dienen dazu um
201. Zeichen erl 50 digit digit 41 digit digit 7 alnum _ eig alle Zeichen erl 71 ou 72 1 lt endcoord gt 73 non o Beim DXF Format ist zu beachten dass es zeilenweise aufgebaut ist Eine zeile enth lt einen eindeutigen Code und jede zweite Zeile den dazugeh rigen Wert Es ergeben sich daraus also Zeilenpaare Mehrere Codes und Werte hintereinander in der selben Zeile sind nicht erlaubt Die Anzahl der Zeilen einer DXF Datei muss immer gerade sein da die Informationen wie beschrieben immer als Zeilenpaar vorkommen Henrik R hrup B 3 DXF Beispiel Dies ist der Rahmen einer DXF Datei mit den vier vorkommenden Sektionen HEA DER TABLES BLOCKS und ENTITIES von denen nur beiden letzten f r uns interessant sind ANHANG B DXF DATEI FORMAT 464 999 dxflib 2 0 2 1 0 SECTION 2 HEADER verschiedene globale Definitionen etc wird von uns nicht weiter beachtet 0 ENDSEC 0 SECTION 2 TABLES Definition von Tabellen u a fiir Layer wird von uns nicht weiter beachtet 0 ENDSEC 0 SECTION 2 BLOCKS verschiedene Block Definitionen 0 ENDSEC 0 SECTION 2 ENTITIES verschiedene Entities 0 ENDSEC 0 ANHANG B DXF DATEI FORMAT 465 EOF B 3 1 Beispieldatei Abbildung B 1 zeigt eine graphische Beispielzeichnung eines Gleisnetzes Die DXF Repr sentation der f r TRACS interess
202. _REQUEST strcat send_buffer idbuf strcat send_buffer STR_QUIT strcat send_buffer n send_msg drv gt private_data send_buffer else if in 0 out drv gt old_out amp OUTPUT_MASK in else printf invalid request n out in 1 lt lt POINT_GET_INVALID KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 405 strcpy send_buffer STR_REQUEST strcat send_buffer idbuf strcat send_buffer STR_QUIT strcat send_buffer n send_msg drv gt private_data send_buffer return 0 Diese Funktion wird dann vom SI Treiberframework aufgerufen wenn eine Anweisung an das Element bermittelt werden soll In der Variablen in ist der Eingabebereich des Sha red Memory enthalten der also die Anweisung umfasst Es wird dann gepr ft ob es sich um eine korrekte Anforderung gem SI Treiberspezifikation handelt Ist dem so wird eine Meldung zusammengesetzt und mittels der Hilfsfunktion send_msg abgeschickt In out wird anschlie end die SHM Belegung zur ckgeliefert die Schaltanweisung ist an dieser Stelle nat rlich noch nicht ausgef hrt Bei einer inkorrekten Anforderung setzt der Treiber ein invalid Bit und meldet sich beim Simulator ab static int driver_point_callback struct driver_info drv u_int32_t in u_int32_t out int bytes_read int bytes_worked int new_shm struct internal_data data drv gt private_data char read_buffer data gt cmd if recv_msg data out
203. _active_cond amp 15 IrO_active_cond amp Ir4_active_cond 1 225 wechseln wenn sie sich im Zustand ACTIVE befindet der Eingangssensor der Route ausgel st wurde und keine Bahn direkt folgt die ebenfalls die betreffende Route befahren m chte In dem Beispiel soll die Route rO den Zustand LOCKED annehmen wenn sie sich im Zustand ACTIVE befindet der Eingangssensor g4125 erreicht wurde und keine Bahn direkt folgt die bei Route Request Sensor 0 ebenfalls die Route rO angefordert hat rO_lock_cond case r0 state ACTIVE amp g4125 state HIGH amp rr_O_next_tram 1 0 esac KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 226 ri_lock_cond case ri state ACTIVE amp g4125 state HIGH amp rr_O_next_tram ri 1 1 0 esac r2_lock_cond case r2 state ACTIVE amp g4129 state HIGH amp rr_i_next_tram r2 1 1 0 esac r3_lock_cond case r3 state ACTIVE amp g4129 state HIGH amp rr_1_next_tram r3 1 1 0 esac r4_lock_cond case r4 state ACTIVE amp g4127 state HIGH amp rr_2_next_tram r4 1 1 0 esac r5_lock_cond case r5 state ACTIVE amp g4127 state HIGH amp rr_2_next_tram r5 1 1 2 0 esac 7 6 4 5 5 Routenzustand INACTIVE Eine Route soll in den Zustand INACTIVE wechseln wenn sie im Zustand LOCKED ist alle Signale die sich auf der Route befinden auf STOP sind und der Z hler des Eingangssensors den selben Wert hat wie der Z hler des Au
204. _n esac 7 6 3 1 4 spec_declaration In dieser Umgebung werden Eigenschaften in der tem poralen Logik CTL Computation Tree Logic spezifiziert CTL ist eine Logik mit ver zweigter Zeit d h es k nnen f r einen Zustand mehrere Folgezust nde existieren Das Schl sselwort SPEC dr ckt aus dass eine Eigenschaft folgt die in CTL formuliert ist Eine CTL Formel ist e eine atomare Formel p true oder false e wenn p und q CTL Formeln sind dann auch Ip p amp q p p p gt q AX AF AG Alp Uq EX EF EG Elp U q Die temporalen Verkn pfungen sind jeweils aus einem Pfadquantor gibt an f r welche Pfade eines Transitionssystems eine Eigenschaft gilt und einem temporalen Operator zusammengesetzt Es existieren folgende Pfadquantoren bzw temporale Operatoren e Pfadquantoren A Always entlang aller Pfade E Exists entlang eines Pfades e temporale Operatoren X F G U rn neXt n chster Zustand rn Future in einem zuk nftigen Zustand Globally in allen zuk nftigen Zust nden Until bis nn Folgende CTL Formeln haben z B folgende Bedeutungen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 210 e AGp Entlang aller Pfade im Transitionssystem ist p in allen zuk nftigen Zust nden erf llt e EGp Es existiert ein Pfad im Transitionssystem in dem p in allen zuk nftigen Zust n den erf llt ist e AFp Entlang alle Pfade im Transitionssystem wird irgen
205. a kein funktionsf higer Steuerinterpreter vorliegt KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 368 7 8 4 8 Echtzeitfahigkeit Der Simulator soll ein Gleisnetz samt re agierender Sensoren Weichen und Signalen sowie der darauf fahrenden Stra enbahnen simulieren Der finanzielle Rahmen des Pro jektes TRACS erlaubt keine Hardwareausstattung um f r jedes oben genannte Element eine eigene CPU abzustellen Der gesamte Simulator l uft auf einer einzigen CPU s S 371 Wir benutzen ein Konzept der sequentiellen Abarbeitung s mtlicher Hardwa reelemente Wie dieses Konzept aussieht und warum wir keine Threads zur parallelen Abarbeitung benutzen wird im ersten Unterkapitel erl utert Damit die Simulation ein Echtzeitsystem korrekt simuliert muss die im Simulator als vergangen berechnete Zeit mit der tats chlich vergangenen Zeit bereinstimmen Auf diesen Aspekt wird im darauf folgenden Kapitel eingegangen Das letzte Unterkapitel schlie lich beleuchtet die Konzepte die befolgt werden damit die Rechenzeit pro Runde m glichst gering gehalten wird 7 8 4 8 1 Threads vs sequentielle Abarbeitung Wir haben uns f r eine sequen tielle Abarbeitung und gegen die Benutzung von einem Thread pro Hardwarelement entschieden da die Verwendung der Rechenzeit der CPU auf diese Weise effektiver erscheint Einzige Threads sind die beiden Kommunikationsschnittstellen Sender und Empf nger der Simulator und die GUI Bei der Verwendung von einem Thread p
206. abellen oder Routenpl nen wird weitgehend manuell das Steuerungssys tem hergestellt und implementiert Das kann den Vorteil haben dass jeder so entwickelte Controller bestm glich zu der vorliegenden Situation passt verlangt aber f r jeden Con troller erneut einen eigenen Entwicklungsprozess Das Projekt TRACS verfolgt einen neuen Ansatz in welchem das ausf hrbare Soft waresystem automatisch aus den Anforderungsspezifikationen erzeugt wird Diese An forderungsspezifikationen sind die Basis f r eine daraus erzeugbare Verifikations und Testsuite mit deren Hilfe die Korrektheit von Konfigurationsdaten ausf hrbarer Soft ware und der Integration der Software in der Hardware automatisch berpr ft werden kann KAPITEL 1 EINLEITUNG 8 1 5 Entwicklungsprozess Das Projekt TRACS hat einen Entwicklungsprozess ausgearbeitet in dem das Zusam menspiel aller vom Gesamtsystem ben tigten Komponenten festgelegt wird In diesem Prozess wurden eine Reihe von Komponenten entwickelt welche zur Erzeugung eines konkreten Bahnsteuerungssystems erforderlich sind Dies beginnt bereits bei der Ein gabe des zu steuernden Gleisnetzes und geht bis zum eigentlichen Controller der die Steuerung des Systems bernimmt Das komplette System soll dabei auf einer herk mm lichen PC Plattform lauff hig sein Der Entwicklungsprozess ist au erdem die Grundlage f r den Verifikationsprozess 1 6 Verifikationsprozess Die Grundlage f r den TRACS Verifikation
207. aber akzeptiert werden 7 8 8 2 2 Kommunikation Die Kommunikation in der Gruppe war zum gro en Teil sehr gut Bei den w chentlichen Treffen gab es gute Diskussionen und der Email verkehr in der restlichen Zeit der Woche war sehr rege trug zu Entscheidungsfindungen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 425 bei und half bei Zwischenfragen Die Beantwortungszeit auf eine Frage in einer Email war meist sehr gering so dass dies kaum Verz gerungen bei der Programmierung nach sich zog Anmerkung Dies gilt nat rlich nur f r die Zeit als die Gruppe noch aus vier Personen bestand 7 8 8 2 3 Leistung Die Mitglieder arbeiteten mit einer Ausnahme alle gleichwertig bei der weiteren Planung Diskussion und L sungsfindung mit Zu Beginn des zweiten Semesters wurde noch nicht sehr viel pro Woche geschafft hier h tte man noch mehr Leistung bringen k nnen Jedoch waren die Simulator Gruppenmitglieder nicht sehr motiviert durch die insgesamt sehr geringe Motivation im Projekt Aber nach ein paar Wochen kann man passender weise als Startschwierigkeiten bezeichnen wurde die Arbeitsleistung erh ht und das Arbeitstempo angezogen Die Leistungssteigerung wurde zus tzlich durch die Tatsache verst rkt dass zwei Mitglieder der Simulator Gruppe am Ende des angesprochenen Semesters das Projekt mit dem Bachelor Abschluss verlassen und eine m glichst gute Anschlussnote bekommen m chten Die weitere Arbeit des im Anschluss an das zweite Semester
208. aktivierungsliste naechster_RC true Rst_eintrag ROUTE_AKTIV aktionsliste_ausfuehren freigabeliste naechster_RC true Rst_eintrag Sperrphase aktionsliste_erfuellt sperrliste nachbedingungsliste_erfuellt sperrtimer_abgelaufen amp amp naechster_RC true eingangssensor_ausgeloest amp amp bahn_zaehler 1 Rst_eintrag ROUTE_SPERREN bahn_zahler naechster_RC true aktionsliste_ausfuehren sperrliste sperrtimer_starten SER ROUTE_AKTIV gt Stellphase Rst_eintrag ROUTE_AKTIV V Freigabephase naechster_RC false i aktionsliste_erfuellt stellliste naechster_RC true aktionsliste_erfuellt stellliste aktionsliste_ausfuehren freigabeliste nachster_RC true aktionsliste_erfuellt freigabeliste naechster_RC true aktionsliste_erfuellt freigabeliste naechster_RC true eingangssensor_ausgeloest naechster_RC true y Einfahrtsphase E A eingangssensor_ausgeloest amp amp bahn_zaehler gt 1 bahn_zaehler naechster_RC true Abbildung 7 43 Route Controller Transistionssystem 194 e Deaktivierungsliste Signalpositionen um alle Signale auf der Route auf Rot zu stellen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 195 e IDs von Anfang und Endsensor Signal und Weichenpositionen werden dabei als SHM Belegungsmaske gespeichert Es werden die relevanten Bits
209. al wird sie vorbeifahren oder halten An einer undefinierten Weiche wird sie entgleisen 7 8 4 4 4 Simulation von fehlerhaft agierendem Gleisnetz Eine Teilaufgabe des Simulators im Projekt TRACS ist das Simulieren von Situationen in denen ein oder mehrere Sensoren Weichen Signale oder Stra enbahnen falsch oder gar nicht reagieren vgl Kapitel 7 8 2 2 2 auf Seite 318 Diese Testm glichkeit wird im Simulator dadurch realisiert dass man wie bereits oben beschrieben bei der Konfiguration der Simulation bestimmte Elemente als ausfallgef hrdet bestimmen kann An dieser Stelle sollen noch einmal die m glichen Fehlersituationen zusammengefasst werden e Tram die ausgew hlten Stra enbahnen k nnen folgende fehlerhafte Verhaltens weisen simulieren bleibt irgendwo liegen Die Stra enbahn wird in K rze anhalten und sich dann nicht mehr von der Stelle bewegen Dies simuliert den Fall dass eine Stra enbahn aufgrund ei nes technischen Defekts oder anderer u erer Umst nde im Gleisnetz stehen bleibt beachtet kein Signal mehr Dies ist ein Fehlerfall bei dem der Steuerinterpreter einen dadurch verur sachten Unfall nicht verhindern kann und auch nicht muss denn im Schie nenverkehr wird davon ausgegangen dass der Stra enbahnfahrer sich an die Signale h lt Dennoch kann man dadurch testen ob der Steuerinterpreter sein KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 307 M sglichstes tut um Unf lle die aufgrund eines igno
210. alten berpr ft Diese Tests sind Gleis netzunabh ngig geh ren aber trotzdem zur Testsuite eines Gleisnetzes Diese Komponenten werden dann in Subsystemtests im Zusammenspiel mit ihren Pro jektierungsdaten auf korrektes Verhalten getestet Hierzu liest ein Testfallgenerator die Projektierungsdaten des zu testenden Subsystems ein und generiert Testf lle f r vollst ndige Zustands und bergangs berdeckung Ein Testorakel bedient sich eben falls der Projektierungsdaten um gem HP03a und der in HPO3b gegebenen Steue rungssemantik zu entscheiden ob sich das Subsystem sicher verh lt Im Software Integrationstest wird ein vollst ndiges Steuerungssystem auf Korrektheit gepr ft Hierbei dienen wieder die Projektierungsdaten als Basis f r Testf lle und Te storakel Der in HP03a vorgeschlagene Hardware Software Integrationstest konnte nicht durch gef hrt werden da im Kontext des Projektes TRACS keine konkrete Hardware benutzt wurde und daher die f r diese Form von Test ben tigten Eingabe und Ausgabehard ware des Testlings und Testsystems nicht zur Verf gung stand Details zum automatischen Test von Gleisnetzsteuerungssystemen finden sich in Ab schnitt 7 7 9 1 5 Eigene Erweiterungen Zus tzlich zu den Projektvorgaben aus HP02 HPO3b HPO3a und PGHD04 wur den weitere Komponenten entwickelt welche die Generierung von Gleisnetzsteuerungs systemen erleichtern sollen Um ein Gleisnetz nicht textuell beschreib
211. altestellen ist anzuhalten wenn Fahrg ste ein oder aussteigen wollen Beim Auftreten von Hindernissen auf dem Gleis ist zu halten Es darf in den Bereichen die vom Steuersystem kontrolliert werden nicht r ck w rts gefahren werden solange das Steuersystem aktiv ist 2 3 6 Abstraktionen Da es in der Welt viele Gleisnetze geben mag die nicht von obiger Beschreibung abge deckt werden die aber dennoch von unserem System beherrschbar sein sollen nehmen wir an einigen Stellen Abstraktionen vor um das Verhalten bzw die Eigenschaften kom plizierterer Elemente und Elementgruppierungen auf einfachere F lle zur ckzuf hren Diese listen wir an dieser Stelle auf KAPITEL 2 DIE DOMANE 27 e Gleisverschlingungen Stellen an denen ein Strang eines Gleises sich zwischen den beiden Str ngen eines anderen Gleises befindet werden als Kreuzungen interpre tiert e Bereiche in denen zwei Gleise zwar nicht ineinander verschlungen sind aber sich Bahnen dennoch nicht kollisionsfrei begegnen k nnen werden ebenfalls als Kreu zungen betrachtet e Vorsignale werden vom geplanten Steuerungssystem nicht ber cksichtigt e Signale zur Vorgabe von H chstgeschwindigkeiten werden lediglich als Signale zur Freigabe der Fahrt interpretiert e Signale zur Anzeige des Weichenzustandes werden vom Steuerungssystem nicht direkt angesteuert k nnen aber an Weichen gekoppelt sein und die Daten zur Anzeige direkt von diesen beziehen e Signalzustand
212. alysis and Verification of Software 1999 Sun MICROSYSTEMS INC Java 2 Platform Standard Edition v 1 4 2 API Specification http java sun com j2se 1 4 2 docs api Heruntergela den am 3 Oktober 2004 TRACS Train Control Systems http www informatik uni bremen de agbs lehre tracs Verified Systems International GmbH http www verified de VERIFIED SYSTEMS INTERNATIONAL GMBH Bremen RT Tester 6 0 User Manual Issue 1 0 2004 http www verified de
213. am Steuersystem XXX 2 2 Treiber Fehler XXX 2 3 SI Fehler XXX 2 4 Fehler in Betriebssystem o Systemumgebung XXX 1 2 1 1 2 3 wegen falscher Sensordaten 3 1 Sensor reagiert nicht auf Bahn 3 2 Sensor reagiert falsch auf Bahn 1 2 1 1 2 4 falsche Reaktion auf erkannten Sensor Signalausfall oder defekt 1 2 1 1 2 4 1 Sensor Signalausfall oder defekt 1 1 Sensor Signalausfall oder defekt 1 2 Steuersystem schaltet nicht alle betroffenen Signale auf Stop XXX 1 2 1 2 Weichen so geschaltet dass Bahnen aufeinander zufahren 1 2 1 2 1 St rung einer Weiche oder des zu ihr f hrenden bertragungsweges 1 2 1 2 1 1 Nichtbefolgen von Schaltanweisungen 1 1 Schaltanweisung wird ignoriert 1 2 Schaltanweisung gelangt nicht zu Weiche 2 1 1 2 1 wegen Defekt am Steuersystem XXX 2 1 1 2 2 wegen Defekt auf Ubertragungsweg 1 2 1 2 Eigenm chtige Schaltungen der Weiche 1 2 1 2 2 Fehlverhalten des Steuersystems 1 2 1 2 2 1 Fehler in Projektierungsdaten 1 1 Benutzer gibt falsche Daten ein XXX 1 2 Netzgraph liefert TND die nicht der Zeichnung entspricht XXX 1 2 1 2 2 1 3 Compiler liefert Bin rdaten die nicht der Eingabe TND entsprechen XXX 1 2 1 2 2 2 Steuersystem gibt eine nicht den Projektierungsdaten entsprechende Anweisung oder unterl sst eine in den Projektierungsdaten geforderte Anweisung 1 2 2 2 1 Hardware Fehler am Steuersystem XXX 1 2 2 2 2 Treiber Fehler XXX 1 2 2 2 3 SI Fehler XXX 1 2 2 2
214. andelt es sich um das Endprodukt von TRACS Aus der TND und der Systemspezifikation werden Tesprozeduren entwickelt und ein Testsystem erstellt Die korrekte Funktionalit t des Steuerungssystems muss auf Grund lage einer formalen Spezifikation nachgewiesen werden Es muss berpr ft werden ob das ausf hrbare Steuerungssystem alle seine beabsichtigten Aufgaben erf llt Hierauf wird ebenfalls im Abschnitt 7 7 auf Seite 255 n her eingegangen Verifikationsschritt TND Spezifikation HW SW System Beschreibung SI Treiber Testprozedurentwicklung Entwicklungsschritt Testsystembau Systemtest gegen Systemspezifikation gleicher Input f hrt zu gleichem Output Rot Komponente oder Pfad wird als korrekt angenommen Dicke Elipse Wiederverwendbares Produkt Normal Elipse Nicht wiederverwendbare Daten Abbildung 6 7 Systemtest gegen Systemspezifikation Deng Zhou Ruben Rothaupt Kapitel 7 Beschreibung der Komponenten 7 1 Tram Network Description TND 7 1 1 berblick Die Tram Network Description kurz TND ist eine sogenannte Domain Specific Language DSL Bei DSLs handelt es sich wie ihr Name schon andeutet um Sprachen die speziell f r ein bestimmtes Anwendungsgebiet entworfen werden Diese Tatsache erlaubt es eine Sprache genau an die Bed rfnisse des jeweiligen Gebietes anzupassen so dass sie insbesondere f r Experten aus dem Gebiet einfach verwendbar ist
215. ang Konfigurationsdateien f r den Testvorgang 7 7 4 3 Vorbereitung der Testf lle F r die RD RC SM ist ein Unit Test durchgef hrt worden SM nicht komplett f r den gesamten SC war ein Software Integrationstest vorgesehen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 266 Unit Tests Komponententest tiberpriifen die einzelnen Funktionen innerhalb der Steuerungssoftware Die Tests spielen deshalb eine gro e Rolle in dem gesamten Testvor gang weil man auf Grund der Feststellung dass s mtliche Bauteile des Systems korrekt funktionieren die Chancen erh ht dass das Gesamtsystem auch korrekt funktioniert Schnittstellen sind hier die globalen Variablen oder bergabe Parameter Linux RT Tester AMs Generator AMs Checker Globale Variablen oder bergabe Par Projektierungsdaten oF Abbildung 7 57 Schema der Unit Tests Folgende Komponenten sind zum Test notwendig e Steuerungssoftware mit Projektierungsdaten e PC Rechner Betriebssystem Testsoftware Vorbereitung der Testf lle f r die einzelnen Software Komponenten ist ausf hrlich in dem Kapitel 7 7 5 auf der n chsten Seite beschrieben Software Integrationstests tiberpriifen sich gegenseitig beeinflussende Software Kom ponenten in Form eines Blackbox Tests Die Tests berpr fen das gesamte Software Sys tem Schnittstelle ist hier Shared Memory SHM KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 267
216. ann durch die libusb ist als Paket bei den meisten Linux Distribu tionen enthalten erfolgen oder durch ein Kernelmodul daf r Andreas Kemnade Marius Mauch Deng Zhou KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 183 7 5 4 Spezifikation In den folgenden Abschnitten werden die Eingaben die Ausgaben und das Verhalten der einzelnen Teile des Systems bestehend aus Treiberblock und Safety Controller defi niert Dabei ist zu beachten dass stets definiert wird was in einer Iteration geschieht Sicherheitskritische Echtzeitanforderungen tauchen dort nicht auf Es gibt aber sehr wohl Zeiten die das Komfortverhalten beeintr chtigen etwa in der Form dass Bah nen zu lange auf die Freigabe von Routen warten m ssen oder bremsen m ssen Wenn Timer verwendet werden also zur Defekterkennung bei berschreitung der maximalen Schaltzeit oder um der Bahn eine Einfahrtszeit in Routen zu erlauben ist es f r die Sicherheit nur wichtig dass die Zeit nicht unterschritten wird eine berschreitung ist f r die Sicherheit unproblematisch 7 5 4 1 Treiber In diesem Abschnitt wird zun chst Allgemeines ber das Verhalten des Treibers spe zifiziert Danach wird der Aufbau eines Treibers beschrieben Abschlie end folgt die Spezifikation von ein paar Besonderheiten von verschiedenen Treiberklassen Um die zwei Aufgaben die ein Treiber hat n mlich Verarbeiten von Anforderungen und Bekanntgabe des aktuellen Zustands zu erf llen pr ft jeder Treiber in
217. anten Sektionen von dieser Zeichnung sieht aus schnittsweise wie folgt aus Abbildung B 1 Eine Besipiel Zeichnung eines Gleisnetzes B 3 2 Auszug aus BLOCKS Section Hier folgt der Auszug aus der zur Beispiel Zeichnung B 3 1 geh renden BLOCKS Sek tion welche nach Anwendung von DXF Seperator java in die Datei blocks tmp tng ex trahiert wurde ANHANG B DXF DATEI FORMAT 466 0 SECTION 0 BLOCKS 0 BLOCK 10 0 0 20 0 0 30 0 0 3 crossing_lr 0 1 LINE track 10 2 v0 20 0 0 30 0 0 11 2 5 21 10 0 31 0 0 LINE track 10 0 0 20 0 0 30 ANHANG B DXF DATEI FORMAT 467 0 0 11 0 0 21 10 0 31 0 0 0 ENDBLK aufgrund der Dateil nge wurde nur ein Ausschnitt gew hlt weitere Bl cke w rden hier folgen 0 ENDSEC B 3 3 Auszug aus ENTITIES Section Hier folgt der Auszug aus der zur Beispiel Zeichnung B 3 1 geh renden Sektion ENTI TIES welche nach Anwendung von DXFSeperator java in die Datei entities tmp tng extrahiert wurde 0 SECTION 0 ENTITIES 0 INSERT 8 2 crossing_lr 0 10 80 0 20 50 0 30 0 0 0 INSERT ANHANG B DXF DATEI FORMAT 468 2 point_arc_right 0 10 85 0 20 60 0 30 0 0 0 INSERT 8 2 crossing_x 0 10 85 0 20 70 0 30 0 0 0 Aufgrund der Dateil nge wurde hier nur ein Ausschnitt gew hlt Die eigentliche Datei enth lt deutlich mehr Entities INSERT LINE 0 8 INSERT 8 2 signal_example 3 10 80 0 20 53 0 30 0 0 0
218. ar kierungen zwischen zwei Sensoren interpretiert Die TND erlaubt aber dar berhinaus noch die Darstellung als Sensor selbst Auch dies wird nicht als Einschr nkung in diesem Sinne angesehen eher als restriktivere Regel 7 2 4 5 4 Test Version Neben der beschriebenen stabilen Version existiert auch ei ne Test Version in welcher einige Einschr nkungen nicht mehr vorhanden sein sollten So sind zum einen Mehrfach Markierungen mehrere Markierungen in Folge hier m g lich Zum anderen gibt es eine Basis Unterst tzung von Slipswitches Hierbei ist al lerdings anzumerken dass zur Normalausrichtung verdrehte Slipswitches nicht korrekt konvertiert werden da die Koordinaten der internen Weichen nicht einwandfrei berech net werden k nnen Da diese Version nicht ausreichend getestet werden konnte ist sie als Zweit Version hier vorhanden Benutzung auf eigene Gefahr 7 2 4 6 Abschlie ende Anmerkungen Es folgen noch ein paar Anmerkungen welche beim abschlie enden Testen aufgefallen sind 7 2 4 6 1 Zeichenfehler Da sich bei den Tests herausgestellt hat dass DXF Zeich nungen manchmal etwas eigenwillig abgespeichert werden kann es trotz anscheinender Korrektheit der Zeichnung jedenfalls was die Darstellung in QCad betrifft zu internen Fehlern kommen welche trotz intensiver Bem hungen nicht endg ltig gekl rt werden konnten da sie zumeist nicht reproduzierbar waren Dies tritt vor allem bei gr eren Gleisnetzen auf und
219. aram_l param_n Eine Variable kann auch eine Instanz eines Moduls sein Dazu wird die jeweilige Anzahl von Parametern tibergeben Hier ist die Variable var eine Instanz des Moduls module Sie kann nun auf alle Variablen des betreffenden Moduls zugreifen Wenn das Modul module z B eine Variable vari enth lt erfolgt der Zugriff mit var var1 wodurch eine hierarchische Struktur zwischen den einzelnen Modulen entsteht 7 6 3 1 2 assign_declaration Nachdem die Variablen erstellt sind m ssen die Transitionsbedingungen f r die Variablen definiert werden Dies geschieht in der assign_declaration Umgebung die mit dem Schl sselwort ASSIGN eingef hrt wird e Startzustand Mit dem Schl sselwort init wird einer Variable bei der Systeminitialisierung ein Anfangswert zugeordnet Dieser Wert muss dabei vom zuvor definierten Typ sein init var value e Transitionsbedingungen Mit dem Schl sselwort next wird einer Variable der jeweilige Folgezustand zuge ordnet Abh ngig davon welche Bedingung erf llt ist wird der betreffende Folge zustand angenommen next var case condition_1 value_l condition_n value_n esac KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 209 7 6 3 1 3 define_declaration In der define_declaration Umgebung lassen sich De finitionen erstellen Diese Umgebung wird mit dem Schliisselwort DEFINE eingefiihrt e definition value e definition case condition_1 value_1 condition_n value
220. ared Memory Schnittstelle definiert Im zweiten Semester wurde dann am Treiberframework gearbei tet und ein Projektierungsdatenformat entworfen was dazu dienen konnte ein Tran sitionssystem einzulesen Es wurde spezifiziert wie der SI diese Projektierungsdaten interpretieren soll und es wurde eine begonnen einen Interpreter f r dieses Format zu schreiben Das Problem dabei war aber dass dann der Compiler extrem aufwen dig sein w rde und der Steuerinterpreter dann nur als ganzes getestet werden k nnte Daher wurde dann das Projektierungsdatenformat und die Spezifikation im dritten Se mester neu entworfen Erst im vierten Semester konnte die Spezifikation abgeschlossen werden und p nktlich zum Projekttag die Implementierung vorf hrreif erstellt werden Fairness Probleme mussten noch danach behoben werden 7 5 6 2 Aufgetretene Probleme Ein tiefer Einschnitt ergab sich nach dem zweiten Semester da der vorherige Ansatz sich als falsch erwies Es wurde kein Steuersystem spezifiziert sondern nur ein Steuerin terpreter und auch das nicht ganz vollst ndig aber es wurde kaum berpr ft ob der Compiler sinnvoll entsprechende Projektierungsdaten erzeugt werden konnte so dass sich ein Steuersystem ergibt und auch nicht ob das Ganze dann verifiziert werden kann Dadurch musste das meiste ausserhalb des Treiberframeworks neu spezifiziert und imple mentiert werden Gerade die Spezifikation erwies sich als gro er Brocken Das Problem bestand
221. as Auffahren nicht m glich ist d rfen keine Bahnen auf die Weiche auffahren Aus der Gleisnetzbeschreibung lassen sich die Hazards bestimmen die in dem jeweiligen Gleisnetz auftreten k nnen Der Controller muss die Signale und Weichen so schalten dass keine Sicherheitsbedingung verletzt wird 7 6 2 2 Systemmodell Es wird ein formales Modell des Systems in Form eines Transitionssystems erstellt Dieses Modell besteht aus einem physikalischen Modell des betrachteten Gleisnetzes und einem Modell des Controllers KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 205 7 6 2 2 1 Physikalisches Modell Domain of Control Das physikalische Mo dell stellt eine Abstraktion des betrachteten Gleisnetzes dar Es werden nur die physi kalischen Komponenten des Gleisnetzes Sensoren Weichen Signale ohne Steuerungs aufgabe modelliert Anhand der Sensor Signal und Weichenzust nde kann man bestimmen wann ein Sensor von einer Bahn erreichbar ist Ein spezieller Teil des physikalischen Modells sind die Sicherheitsbedingungen die eben falls vom Aufbau des jeweiligen Gleisnetzes abh ngen 7 6 2 2 2 Controller Modell Controller Im Controller Modell wird das Verhal ten des Steuerinterpreters und somit die eigentliche Steuerungsaufgabe modelliert Die Abbildung 7 44 zeigt physikalisches Modell Controller Modell und die Beziehung zwischen beiden Modellen Das physikalische Modell liefert die Informationen in welchen Zust nden sich die Sensoren Signal
222. as auf Stop steht so wird das entsprechende Bit gesetzt mustStop iter daher auch die besondere Darstellung der Iterationstiefe so kann man ihren Wert direkt benutzen um mustStop zu manipulieren Das Setzen geschieht nat rlich nur falls das Bit noch nicht gesetzt war 23 else 24 logger info Tram id 25 Correct signal percepted in 26 iter iteration 27 if mustStop iter 2 1 28 mustStop iter 29 30 Ist zwar ein Signal vorhanden steht es aber nicht auf Stop und nicht in einer fiir die gew nschte Route falschen Position so wird ein eventuell gesetztes Bit in mustStop zur ckgenommen Das geschieht unabh ngig von der Entfernung zum Signal da ja auch die Situation denkbar ist dass das Signal kurz bevor die Bahn es erreicht die Fahrt freigibt Regel Stop kann nur dann beachtet werden wenn man es rechtzeitig vorher sieht Fahrtfreigabe kann immer beachtet werden 31 else 32 if mustStop iter 2 1 33 mustStop iter 34 35 Ist kein Signal vorhanden wird selbstverst ndlich das Bit nicht gesetzt die eventuelle Riicknahme eines gesetzten Bits ist nur pro forma 36 int dist dir 7 length 1 pos pos 37 if steps gt dist 38 try 39 te l getNextTE te false true KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 384 40 if 1 te getBorders 0 41 dir true 42 else 43 dir false 44 45 if dir true
223. ashing ver waltet und bietet dementsprechend schnellen Zugriff auf einzelne Eintr ge der Symbol tabelle wobei der Bezeichnername eines Gleisnetzelements hierbei als Schl ssel f r den Zugriff dient KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 143 Der tram Syntaxbaum selbst enth lt dementsprechend selbst keine Bezeichnernamen da an jedem Blatt des Baumes anstatt eines Bezeichnernamens ein Verweis auf den entsprechenden Eintrag in der Symboltabelle benutzt wird Auf diese Weise kann bei der Auswertung des Syntaxbaumes in jedem Kontext nicht nur auf Bezeichnernamen sondern auch direkt auf zugeordnete Hardware Eigenschaften zugegriffen werden In Abbildung 7 30 wird die Speicherstruktur eines einzelnen Symboltabelleneintrags ge zeigt Neben den prim ren Attributen eines Gleisnetzelements wie Name Parser ID und hnlichem wird hier deutlich wie r umliche Koordinaten und weichen bzw si gnalspezifische Eigenschaften gespeichert werden struct symtab_entry_t ID int SHMID int type int name char coords struct coords_t attr union attrt gt ___ unionattrt xal int sigattr struct sigattr_t TE zval int _structsigattrt sigattr_t wait_straight bool falback bool j walt tt i bool direction int wait_nght bool breakable bool n_straight bool switchtime long int m_left bool m_nght bool switchtime long int Abbildung 7 30 Ubersicht tram C
224. at bergeben wird die Hardware die gerade berfahren wurde Wenn es sich dabei um eine Weiche oder ein Kreuzung handelt beginnt der Pr fvorgang Wenn das Hardware Element als besetzt gekennzeichnet ist so bedeutet dass das sich eine anderen Stra enbahn darauf befindet oder darauf befand aber sich im selben Simulatorzyklus bereits davon wegbewegt hat Dann ist es zu einem Crash gekommen und dies wird dem Simulator gemeldet KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 302 Tram checkCollision passed hardware passed hardware turnout crossing true hardware was occupied true false handle crash Abbildung 7 74 Aktivit tsdiagramm Tram checkCollision Tram doFinish doFinish f hrt Arbeiten aus die durch die Fortbewegung der Stra enbahn hervorgerufen werden Als Parameter bekommt diese Methoden die von Kopf und Ende berfahrenen Hardware Elemente und das alte Gleisst ck auf dem der Kopf war doFinish gliedert sich in zwei Elemente die hnlich ablaufen einmal der Bereich f r den Kopf Aktionen die durch den Kopf her vorgerufen wurden und dann der Abschnitt f r das Ende der Tram Aktion die auftreten wenn die Bahn etwas verl sst Hat der Kopf ein Hardwareelement berfahren so wird diese Hardware als besetzt markiert wichtig f r die Kollisions berpr fung s checkCollision Handelt es sich dabei um eine Weiche oder Sensor so merkt sich die Tram da
225. ations Block Im relations Block werden die Nachbarschaftsbeziehun gen der einzelnen Elemente definiert Daraus kann man ableiten welches Element von welchem anderen Element aus erreichbar ist Die Funktion is_reachable pr ft ob ein bestimmtes Element von einem bestimmten Sensor erreichbar ist wenn man von dem Sensor in eine bestimmte Richtung f hrt Diese Funktion ist wie folgt definiert is_reachable x Pset UGset U Kset X 9 Get x y A B 1 r x p mit r A B Y L R S C D und p Peeling Petting ist die Menge aller m glichen Einstellungen der jeweiligen Weichen p bedeutet dass die Komponente p f r das Paar r x p optional ist Wie f r die TND definiert sind A und B die Seiten eines Sensors Y L R und S die Seiten einer Weiche und A B C und D die Seiten einer Kreuzung Ist das betreffende Element von dem betreffenden Sensor in der betreffenden Richtung erreichbar wird die Seite zur ckgegeben an der das Element erreicht werden kann Zudem kann es sein dass das Element nur erreichbar ist wenn bestimmte Weichenstel lungen vorliegen Diese Weichenstellungen werden ebenfalls ermittelt Wenn das Element von dem Sensor nicht erreichbar ist dann wird 1 zur ckgegeben Es soll nun beispielhaft angegeben werden wie gepr ft wird ob der Sensor g4126 vom Sensor g4125 aus erreichbar ist Wenn man von Sensor g4126 in Richtung A geht gelangt man zu der Seite B des Sensors g4023
226. auf jeden Fall doch relativ gro gewesen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 119 w re h tte man das Ziel einer Gruppenverschmelzung ernsthaft weiter verfolgt wur de diese Idee recht schnell von der Netzgraphseite verworfen Auch h tte es f r die Netzgraphseite eine gravierende Umstellung hinsichtlich auf die beim Compiler verwen dete Programmiersprache gegeben was ebenfalls zu einer erh hten Einarbeitungszeit gef hrt h tte siehe dazu auch die Entscheidung f r die Programmiersprache Java Mim Abschnitt 7 2 3 2 1 auf Seite 89 Im Hinblick auf diesen Tatbestand h tte eine Verschmelzung dieser Art nach Auffas sung des einzig verbliebenen Netzgraph Mitglieds wenig Sinn gemacht zumal anschlie Bend sehr wahrscheinlich dasselbe Problem bei der Wiederaufnahme an der Netzgraph Implementation aufgetreten w re und unterm Strich tendenziell eher ein Zeitverlust als eine Beschleunigung aufgetreten w re Von anderer Seite her kam im brigen auch nie der ernsthafte Versuch einer Zusammenlegung zustande Aus der Kommunikation zwi schen den einzelnen Gruppen konnte man auch zu absolut keiner Zeit entnehmen dass durch diesen Entschluss der Netzgraphseite beim Compiler irgendwelche neuen Proble me aufgetreten w ren Auf der anderen Seite h tte die Compiler Gruppe nicht in die Zeitnot geraten m ssen in der sie sich am Ende befand wenn sich deren Mitglieder nicht neben dem Projekt TRACS noch mit einer anderen offenbar sehr zeitaufw ndi
227. ax der TND zu benennen muss irgend wo in relativer N he ein Textfeld plaziert weren welches den Namen enth lt M ssen auch noch zus tzliche Properties eingegeben werden so geschieht dies im selben Text feld Die Properties werden von sogenannten Unterstrichen vom Namen des Elements abgetrennt wobei die Switchtime immer die erste Eigenschaft ist Die Syntax lautet wie folgt Signale Elementname_Switchtime_Signal Properties Weichen Elementname_Switchtime sonst Elemente Elementname Beispiel eines L Signales mit der Schaltzeit von 500 ms und Anzeigen f r Wait Left Route Request Left s359_500_RRL_WL Beispiel einer LR Weiche mit der Schaltzeit von 700 ns w467_700 Die Switchtime bei Signalen und Weichen ist ein Wert in Millisekunden Die Signal Properties selbstredend nur bei Signalen sind aus einer f r den entsprechenden Signal Typ m glichen Menge zu w hlen RRL RRR RRS WL WR WS RRx sind Route Request Properties Routen Anforderungs Anzeigen w hrend Wx f r Wait Properties Anzeigen f r Warte Aufforderungen steht Damit dieses Textfeld aber exakt einem Element zugeordnet werden kann muss es mit dem entsprechenden Element Block zu einem neuen Block kombiniert werden Dies kann mittels des Men punktes Block erstellen aus dem Men Block gemacht werden F r den Namen d rfen nicht beliebige Zeichen verwendet werden Je nach Element typ wird ein bestimmter Anfangsbuchstabe und zwar klein
228. bedaten des RC geh rt es war aber nicht spezifiziert wo und unter welchen Umst nden er ge ndert wird In der Implementation wurde er in eingangssensor_ausgeloest ge ndert e In eingangssensor_ausgeloest Der dort durchgef hrte Vergleich sollte besser mit lt statt mit durchgef hrt werden ansonsten k nnte entry_sensor_count ins Unermessliche wachsen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 303 e In eingangssensor_ausgeloest Das Erh hen des Wertes funktioniert nur mit entry_sensor_count nicht mit entry_sensor_count e In der Deaktivierungsphase wich die Implementation von der Spezifikation ab Die Transition zur Testphase hat u a als Bedingung dass der RST Eintrag ROUTE_SPERREN sein muss diese Bedingung kam im Code nicht vor Diese Fehler wurden der SI Gruppe gemeldet und von ihr behoben so dass der RC nunmehr keine bekannten Fehler mehr aufweist Arne Stahlbock 7 7 6 4 Safety Monitor Wir k nnen nicht sagen dass wir eine komplette automatische Testausf hrung und Aus wertung gemacht haben Dazu fehlte uns der Test Checker Aber w hrend der Program mierungs Phase haben wir die Testroutine mehrmals durchgef hrt und manuell auf Grund der Ausgabe ausgewertet Da haben wir bemerkt dass bei dem ersten Test durchlauf wenn noch die Input Output Werte nicht korrumpiert sind die zu testende Funktion antworte trotzdem negativ hat also die Input Output Belegung als ungul tig An dieser Stelle so
229. beim Gleisbau vermieden werden Gibt es dennoch gef hrlich Bereiche sollten diese durch Geschwindigkeitsbegrenzungen gekenn KAPITEL 2 DIE DOMANE 15 zeichnet sein Die elektromagnetischen Wirkungen k nnen auch Einfluss auf die sichere Fahrt der Bahn haben Dort gibt es Felder um Stromleitungen Handys und andere elektronische Ger te und Elektrosmog bzw Funkverkehr All diese Sachen k nnen sich auf die Elektronik in der Bahn auswirken und somit im schlimmsten Fall die Steuerelektronik verwirren Diese Gefahr sollte aber durch besonde re Vorgehensweise bei der Herstellung dieser Elemente ausgeschlossen werden Genauso wie andersartiger Funkverkehr den Funkverkehr der Bahn st ren k nnte diese Frequen zen jedoch reserviert sind In diesem Bereich l sst sich unser System auch nicht verbessern Physikalische Auswirkungen wie Korrosion und Verschlei ben sich nat rlich auch ne gativ auf das Fahrverhalten einer Bahn aus Dies sind Sch den die mit dem Alter der Bauteile zusammenh ngen Es ist selbst verst ndlich dass bei allen Komponenten im Lauf der Jahre ein Verschlei entsteht Besonders schwerwiegend k nnen sich solche M ngel am Motor der Karroserie den Steuerkomponenten und der Elektrik auswirken da hier zum einen die sichere Fahrt direkt gef hrdet ist z B durch Ausf lle einzelner oder gar aller dieser Komponenten aber auch die Passagiere im Innenraum gef hrdet werden k nnen Auf all diese Punkte hat unser Syst
230. bestimmen ob dieser Fall eintreten w rde und die Bahn nur einen Schritt weitersetzen wenn dieser Fall nicht vorliegt Zur Erinnerung die Position einer Bahn bestimmt sich durch vier Angaben e TrackElement auf dem sich der Kopf befindet e genaue Position des Kopfes auf diesem TrackElement e TrackElement auf dem sich das Ende befindet e genaue Position des Endes auf diesem TrackElement Die Algorithmen zur berpr fung ob eine Tram auf das Ende einer anderen Tram auff hrt und die Kollisions berpr fung ob es zu einem Frontalzusammensto gekom men ist sind sehr hnlich Der eine pr ft ob die Kopfposition einer Bahn mit der Endposition einer anderen Bahn identisch ist der andere pr ft ob zwei K pfe die glei che Position haben Aus diesem Grund wird an dieser Stelle nur der Quellcode von KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 386 driveInto Auffahren erkl rt und die Stellen an denen der Algorithmus zu der Frontal Kollisionspriifung abweicht entsprechend angesprochen Die Kollisions berpr fung ob eine Tram einer anderen in die Seite hinein gefahren ist wird nicht anhand von Quellcode erl utert da es sich um eine sehr simple Methode handelt s Konzept 7 8 4 4 2 auf Seite 351 Es wird lediglich abgefragt ob ein Hardware Element auf das eine Bahn in der aktuellen Runde gefahren ist schon von einer anderen Bahn besetzt ist oder in eben dieser Runde schon von einer anderen Tram besetzt war Die andere Bahn k nn
231. bildung 7 21 auf der n chsten Seite zeigt in einem Screenshot das Laden einer vorhandenen TND Datei KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 125 Abbildung 7 21 Vorhandene TND Datei laden 7 3 2 5 Eigenschaften der Hardwareelemente Die Abbildung 7 22 zeigt die Darstellung der Eigenschaften der Hardwareelemente Die Eigenschaften der Hardwareelemente kommen aus der CAD Datei Im TND Builder darf der Benutzer die Eigenschaften nicht ndern _PointName PointTwe Switch Time Passive Fallback a a TC E 2 wor ferpoimts eoo mMm S Oo wate lets sn IE 4 woa jskpainis on Sm S SCC SC S wos frpoms boo O O 1 Abbildung 7 22 Hardwareliste und Eigenschaften 7 3 2 6 Routendefinitionen Die Abbildung 7 23 auf der n chsten Seite zeigt wie die in der TND Datei definierten Routen aussehen Die Darstellung erfolgt gem HP02 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 126 g4oi4witl4ien 9401 4 w1 01 4 right g4017 g4013 9401 8 w1 01 6 straight g4018 w1 01 G lett 401 4 w1 01 4 straight Abbildung 7 23 Definierte Routen 7 3 2 7 Routeninformationen Wenn man auf eine Route doppelklickt wird ein Dialog angezeigt der detaillierte In formationen tiber die jeweilige Route enthalt Diese Informationen beinhalten beispiels weise eine Liste der Weichen in der Reihenfolge in der diese befahren werden sowie die jeweiligen Weichenstellungen Dies ist in Abbildung 7 24 zu sehen
232. bin ren Projektierungsdaten Jeder Zwischenschritt der Verarbeitung wird hierbei so weit vorgestellt dass ein Verst ndnis des Gesamtablaufs m glich ist Abschnitt 7 4 5 gibt Einblick in sowohl die externen Schnittstellen des tram Compi lers als auch die wichtigsten internen Schnittstellen die zur Generierung von bin ren Projektierungsdaten benutzt werden Abschnitt 7 4 6 beschreibt schliesslich welche Systemvoraussetzungen gelten um den TRACS tram Compiler benutzen zu k nnen Helge L ding 7 4 2 Anforderungen In diesem Abschnitt werden die Anforderungen an den TRACS tram Compiler beschrie ben Zun chst werden die notwendigen Eingabedaten f r den Compiler beleuchtet Hier KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 136 wird darauf eingegangen welche Informationen welche Relevanz fiir die zu erstellenden bin ren Projektierungsdaten haben Darauf folgt eine Beschreibung der Ausgaben des tram Compilers in der beleuchtet wird welche Bedingungen die zu generierenden Projektierungsdaten in Bezug auf die Eingabedaten erf llen m ssen Abschliessend folgt eine Einordunung des Compilers in den Verifikationsprozess des Ge samtsystems Hierbei wird betrachtet welche Anforderungen der tram Compiler in Be zug auf die Sicherheit des resultierenden Steuerungssystems erf llen mu 7 4 2 1 Eingabedaten Die Eingabedaten des Compilers bildet eine Textdatei welche alle zur Steuerung eines Gleisnetzes notwendigen Informationen enth lt
233. bstraktion i 24 Magne Sly At sind 2 0 a Gea Dee dee ee Dew gs Ge 2 4 Die Experten zung de oie hh ot ee es eh ee ho edi Bs DAW berblick sose eera es GOO de Bh GY dh eee heat Wed he as et 2 4 2 Bremer Stra enbahn AG 0 0 0000004 22 9 Hanning amp Kahl ois tate ae CH Sead COA Ss GO eS 3 Problembeschreibung 3 1 Gleisnetzsteuerung 24 24 2a kA we ew ber 3 2 Gleisnetzsteuerungssysteme ooo e 3 3 Deren Generierung 35 2 8 a each INHALTSVERZEICHNIS 2 3 4 Deren automatische Generierung 2020004 36 4 Der L sungsansatz 38 4 1 Architektur ai ae are rate Ene ena ee ee OD he AS eS 38 4 2 Automatische Generierung 0000 pe eee eee 40 4 2 1 Wiederverwendbare Komponenten 41 4 2 2 Generierte Anteile 2 4 as 382 8m 3a 8 ara era 42 4 3 Verifikation und automatisierter Test 2 2 2222 nn 43 4 3 1 Model Checking zr 2 8 aaa ee aaa 43 4 3 2 Automatisierter Test nn 23 3 Dei a era 43 5 Entwicklungsprozess 45 Bulk berblicke Ss sen en BEE as Feed args gh toed 45 5 2 Umfang des von TRACS gelieferten Systems 45 5 3 Entwicklungsschritte u 2 Gat A ok ene na Bolte ye ee Gwe ee ar e 46 5 4 Eistellinesprozess 2a 2 ana oO a OS ee Ee Or 47 6 Validierungs Verifikations und Testprozess 50 Bl berblick seer ice Sci win wae a eae a ia ae wee OHREN 50 6 2 Validierung der TND Netzwerkbeschreibung 52 6 3 Validierung der TND Routenbeschreibung
234. bt so wird als n chstes gepr ft ob an dieser Stelle zuvor ein Signal gesehen wurde Falls Ja dann wird jetzt vermerkt dass dort kein Stop Signal mehr ist Gibt es ein Signal und zeigt es Stop an so wird gepr ft ob die Stra enbahn noch weit genug entfernt ist um auf das Signal zu reagieren oder ob sie steht Wenn einer der beiden F lle zutrifft so pr ft sie ob das Signal bereits in einem vorherigen Schritt gesehen und registriert wurde Falls Nein so wird registriert dass die Tram ein Stop Signal erkannt hat Nach dieser Registration eines Signals wird gepr ft ob auch auf ein weiteres wei ter entferntes Signal geachtet werden muss Falls Ja so wird die Position zu Beginn des neues Gleisst cks errechnet und checkStop mit dieser neuen Position und dem verbleibenden Rest der Vorausschau gestartet KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 349 Tram checkStop position on track preview get next hardware is there a signal true get state of signal mene far enough away to react OR tram stopped true signal already registered false register signal was there a stop signal E cancel registration have to look at next track true calculate start position at next track i false checkStop new position on new track rest of preview stop at next hardware AND at stop position false true Abbildung 7 70 Aktivit tsdiagramm Tram checkStop Nachdem alle m glich
235. c char _L final static char _R final static char _Y final static char final static char EXIT final static char X ENTRANCE final static char DEADEND final static char elementType String elementClass String dxfCoords String elementAngle String elementName String elementNeighbours String elementNBSides String contactPointCoords String insertedInBlock String blockName String signalProperties String insertedBlocks String ctPtSides char switchTime int fallbackDirection int insertCount int breakable boolean false fallback boolean false passive boolean false z lt zarwvonu gt setElementName name String void setElementCoords coords String void setElementNeighbours nb String void getElementName String getElementCoords String getElementNeighbours String setCtPtSides sides char void setSwitchTime time int void setPointType type int fbDir int void setElementType type String void setElementAngle angle String void setElementContactPointCoords coords String voip setInsertCoords coords String void steElementNBSides nb String void setBlockName name String void setSignalProperties props String void setInsertedInBlock name String void setInsertedBlocks list String void setInsertCount counter int void getCtPtSides char getSwitchTime int getPointType int getFallbackDirection int getEleme
236. ch auch simuliert werden Zwei grundlegende F lle sollen simuliert werden k nnen e korrekt funktionierendes Gleisnetz In diesem Fall wird davon ausgegangen dass das gesamte Gleisnetz korrekt funk tioniert Das bedeutet dass alle Hardwareelemente gem ihrer Parameter wie gew nscht funktionieren und die Stra enbahnen so fahren wie man es von einem normalen Stra enbahnfahrer erwartet e zum Teil fehlerhaft agierende Elemente In diesem Fall soll getestet werden wie der Steuerinterpreter auf unvorhergesehene Ereignisse reagiert dazu geh ren Hardwareelemente die nicht reagieren oder die fehlerhafte Informationen liefern Auch k nnen Bahnen unvermittelt stehen bleiben oder Signale missachten 7 8 2 2 1 Korrekt funktionierendes Gleisnetz Das gesamte zu simulierende Sys tem besteht also aus einem zun chst statischen Gleisnetz zusammengesetzt aus Gleisen Sensoren Signalen und Weichen welches durch Hinzuf gen von Stra enbahnen die an einer Einfahrt in das Gleisnetz eintreten zu einem dynamischen System wird in dem folgende Interaktionen simuliert werden m ssen e Reaktion Signal Bahn Eine Bahn h lt an wenn sie rechtzeitig ein f r ihr Gleis zust ndiges Signal sieht das ihr die Weiterfahrt in die gew nschte Richtung verwehrt Eine Bahn h lt nicht an wenn sie ein f r ihr Gleis zust ndiges Signal auf Stop springen sieht aber schon so nah ist dass ein Anhalten davor nicht mehr m gl
237. ch der Testling zum Betrieb mit Projektierungsdaten versorgt wer den musste und dieser nat rlich sein Format erwartete mussten auch die von der SI Gruppe vorgegebenen Strukturen benutzt werden Der Einlesevorgang wurde daher so gestaltet dass die aus der Datei extrahierten Daten gleichzeitig in zwei verschie dene Datenstrukturen im Speicher eingetragen wurden einmal in die originalen SI Projektierungsdatenstrukturen und einmal in die von uns erstellten erweiterten Struk turen die dann von den Testprozeduren benutzt werden sollten Die erweiterten Strukturen werden nun dargestellt KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN Offsets struct test_offsets_t int version_offset int rd_data_offset int rc_data_offset int sm_data_offset Versionsdaten struct test_version_t int major time_t build Struktur f r RD struct test_rd_data_t int max_routes int max_queues char rct char queue_tab BEGIN Strukturen f r RC struct test_shm_value_t int id uint16_t input uint16_t input_mask uint16_t output uint16_t output_mask struct test_sensor_value_t int idi int id2 int relation int value struct test_rc_data_t int route_id int num_point 269 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN struct test_shm_value_t point_pos int num_free_sig struct test_shm_value_t free_sig_pos int num_lockfirst_sig struct test_shm_value_t lockfirst_sig_po
238. ch f r eine Route die geforderten Richtungen f r das Signal und die Weiche unterscheiden So soll es z B nicht m glich sein dass f r eine Route die Weiche nach links und das Signal nach rechts gestellt werden soll Wenn keine Widerspr che zwischen Signal und Weichenanforderungen bestehen und alle Routendefinitionen als richtig erkannt wurden dann wurde auch gezeigt dass im clearances Block keine Fehler enthalten sind Im conflicts Block wird f r zwei Routen ein Konflikt definiert wenn ein gemeinsames Befahren dieser beiden Routen zu einer Kollision f hren k nnte Der conflicts Block kann berpr ft werden indem alle m glichen Zweierpaare von Routen befahren werden Wenn f r die jeweilige Routenkombination kein Konflikt definiert ist dann darf auch keine Kollision m glich sein wenn die beiden betreffenden Routen gleichzeitig befahren werden Ansonsten w re vergessen worden f r diese Routenkombination einen Konflikt zu definieren Wenn ein Konflikt definiert wurde dann muss f r die betreffende Routenkombination eine Kollision m glich sein W re keine Kollision m glich dann w re die Definition eines Konfliktes hier falsch da die betreffenden Routen nicht im Konflikt stehen w rden Sind diese beiden Bedingungen erf llt dann sind die im conflicts Block enthaltenen Angaben korrekt KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 241 Entsprechend zum conflicts Block kann auch der point conflicts Block gepr ft werden Im point co
239. che C noch die Compilerbau Standardwerkzeuge flex und bison zum Einsatz Im folgenden wird zun chst der grobe Aufbau des tram Compilers mit seinen einzelnen Komponenten beschrieben bevor auf einzelne Komponenten genauer eingegangen wird 7 4 3 1 Gesamtaufbau Generell besteht der tram Compiler zun chst aus einem Parser welcher eine eingege bene TND auf syntaktische Korrektheit pr ft Ist eine Eingabedatei korrekt so wird eine Symboltabelle angelegt welche alle beschriebenen Gleisnetzelemente sowie deren physikalische Eigenschaften beschreibt und speichert Zus tzlich wird ein Syntaxbaum angelegt der die eingelesenen Informationen die ber Hardwareeigenschaften hinausge hen im Speicher repr sentiert Nachdem eine Eingabedatei von der Parser Komponente des tram Compilers erfolgreich verarbeitet wurde bilden der entstandene Syntaxbaum und die Symboltabelle die Basis f r die darauf folgende Generierung von bin ren Projektierungsdaten Eine in C geschriebene Bibliothek von Funktionen ist dann daf r verantwortlich aus dem im Speicher entstandenen Syntaxbaum mit Symboltabelle Projektierungsdaten f r den TRACS Steuerinterpreter zu erstellen und diese im Dateisystem abzulegen Abbildung 7 29 zeigt den Aufbau des TRACS tram Compilers Im folgenden wird der Aufbau der einzelnen Komponenten des tram Compilers n her betrachtet An dieser Stelle soll hierbei nur die Struktur des tram Compilers erl utert werden Genaurer Informationen zur Funk
240. cherheitsanforderungen sind nicht erf llt wenn eines der folgenden f nf Ereignisse auftritt e Kollisionen zwischen Bahnen e Entgleisungen e Kollisionen mit Hindernissen nicht Bahnen e Fahrg ste kommen zu Schaden ohne dass Bahnen kollidieren e Bahntechnik Bahnen halten der Belastung nicht stand Von diesen Ereignissen kann das entwickelte Steuerungssystem Kollisionen zwischen Bahnen sowie Entgleisungen vermeiden Es sollen nun die Ursachen betrachtet werden welche entweder zu Kollisionen zwischen Bahnen oder zu Entgleisungen f hren k nnen und bei denen eine Beeinflussung durch TRACS m glich ist Ein Fehlverhalten des Systems w re in folgenden F llen durch TRACS verschuldet e Fehler in Projektierungsdaten e Steuerungssystem gibt eine nicht den Projektierungsdaten entsprechende Anwei sung oder unterl sst eine in den Projektierungsdaten geforderte Anweisung e falsche Reaktion auf erkannten Ausfall oder Defekt eines Hardwareelements e Steuerungssystemausfall oder defekt Um einen Fehler in den Projektierungsdaten zu vermeiden m ssen die Ursachen ausge schlossen werden die zu fehlerhaften Projektierungsdaten f hren k nnen e Ob der Benutzer in den Verschlusstabellen falsche Daten eingegeben hat wird durch Model Checking berpr ft Details dazu sind im Abschnitt 7 6 auf Seite 203 zu finden KAPITEL 8 SICHERHEITSNACHWEIS 436 e Ob aus dem Netzgraph eine TND Netzwerkbeschreibung erzeugt wird die nicht der Zeic
241. chkeit f r den SI dar ist daher nicht sicherheitskritisch und muss daher nicht formal verifiziert werden 7 8 2 6 Zeitverhalten Das ganze System welches letztendlich zum Laufen gebracht werden soll besteht aus einem Steuerinterpreter einem Simulator und den f r die Kommunikation ben tigten Treibern Simuliert werden soll also ein System bestehend aus einem Gleisnetz samt fahrender Stra enbahnen das in einer solchen Zeit l uft die m glichst realit tsnah bez glich Fahrgeschwindigkeiten Schaltzeiten von Weichen und Signalen sowie Ausl se zeiten von Sensoren ist Von einem Computer mit nur einem Prozessor der keine zwei KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 322 Anweisungen tats chlich parallel ausf hren kann ist Echtzeit nicht realisierbar Den noch soll der Simulator mit einem Computer mit nur einem Prozessor auskommen weswegen das Zeitverhalten in der Realit t vom Simulator nicht exakt eingehalten wer den kann aber m glichst naturgetreu wiedergegeben werden k nnen soll Folgende Anforderungen definieren die Bedingungen die erreicht werden m ssen e Sensoren Weichen und Signale sollen so schnell reagieren und ihre Meldungen bertragen wie es in der Realit t der Fall ist Da im Simulator keine analogen Meldungen verschickt und entschl sselt werden m ssen l sst sich hier bereits ein wenig Zeit gewinnen e Die bertragungszeit einer Anweisung vom Steuerinterpreter zu einem Signal oder einer Weiche soll
242. chlagenen Testl ufen richtig betrachtet nur der Aufruf musste naturgem schon vorher bekannt sein Wir zeigen an dieser Stelle den Code erl utern ihn aber nicht weiter Was er tut steht im Wesentlichen in der SI Spezifikation in Kapitel 7 5 4 4 auf Seite 189 auch wenn von den in der Spezifikation geforderten Unterfunktionen hier abgewichen und alles in die eine Hauptfunktion gepackt wurde This is the test oracle computing the expected outputs It is implemented following the SI spec void rd_test_oracle int i int j int tmp int curr_route int confl_route int has_conflict 0 int stop 0 if rr lt pdata gt rd_data gt max_routes if queues int pdata gt rd_data gt queue_tab rr 1 queues int pdata gt rd_data gt queue_tab rr rr longer_queue 1 longer_elem 1 else longer_queue pdata gt rd_data gt queue_tabl rr longer_elem rr F else longer_queue 1 longer_elem 1 for i 0 i lt pdata gt rd_data gt max_queues amp amp stop 0 i curr_route queues qpl i if curr route 1 has_conflict 0 for confl_route pdata gt rd_data gt max_routes curr_route confl_route lt pdata gt rd_data gt max_routes curr_route 1 confl_routet if pdata gt rd_data gt rct confl_route 1 amp amp rst confl_route pdata gt rd_data gt max_routes KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 284 RST_AKT
243. chleife ber alle Queues f r jede Route ihre Queue eingetragen Damit w ren die Projektie rungsdaten f r den Route Dispatcher generiert 7 4 4 3 2 Route Controller Der TRACS Steuerinterpreter hat f r jede zu steu ernde Route einen Route Controller und ben tigt somit auch die Projektierungsdaten f r die einzelnen Routen vom Compiler In diesen Datan enthalten f r jede Route bin re Listen von Steuerimpulsen f r jegliche Elemente des Gleisnetzes um ein Schalten Freige ben oder Sperren der Route zu erm glichen Die Route Controller Projektierungsdaten f r einen Route Controller sehen folgenderma en aus struct rc_data_t int route_id struct shm_value_t free_sig_pos struct shm_value_t lockfirst_sig_pos struct shm_value_t point_pos struct shm_value_t lock_sig_pos KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 165 struct shm_value_t req_sig_pos int entry_sens_id int exit_sens_id a Wobei routeid die ID der entsprechen Route ist freesigpos die Aktionsliste zum Frei geben der Route ist lockfirstsigpos die Aktionslist zum Rotstellen des ersten Signals pointpos die Liste zum Stellen der Weichen regsigpos die Liste zum Anschalten der Route Request Signale entrysensid der Eingangssensor und ezitsensid der Ausgangs sensor der Route Die Funktion zur Generierung dieser Daten f r jeden einzelnen Route Controller ist folgende void getRCData struct section_t syntree struct rc_data_t newRcd int rid Als Eingabedat
244. chriebenen Gleisnetzes reali siert wurde auch in Anbetracht des im Laufe der Zeit immer begrenzter zur Verf gung KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 104 stehenden Personals und des daraus resultierenden Zeitmangels beschlossen dieses Ar beitspaket ersatzlos zu streichen Es w re allerdings auch extrem aufw ndig gewesen dieses Paket zu realisieren da wie bereits mehrfach erw hnt das DXF Format in welchem die CAD Software eine Zeich nung abspeichert in extrem vielen Versionen verf gbar ist und jede Version diverse Zusatzinformationen enth lt welche nicht wirklich von einem R ckkonverter generiert werden k nnten Ob eine DXF Zeichnung mit den Minimal Informationen wirklich ein wandfrei im CAD Programm darstellbar gewesen w re ist unklar Auf jeden Fall w ren deutlich mehr Personen in der Netzgraphgruppe daf r notwendig gewesen als letztlich zur Verf gung standen 7 2 3 4 Handbuch zu den Konverter Tools Das abschlie ende Arbeitspaket im Teilprojekt Netzgraph war das Anfertigen eines Handbuchs f r den Netzgraph Konverter inklusive einer Anleitung f r die Erzeugung einer Basis TND Datei Dieses Handbuch umfasst sowohl die eigentlichen Aufrufpara meter des Konverters als auch Informationen zur Installation als solches Der wesentliche Bestandteil aber ist die genaue Erl uterung wie ein Zeichner eines Gleisnetzes dieses mit Hilfe der CAD Software und der von TRACS gelieferten Objekt Bibliothek anfertigt was zu bea
245. chritt wird ber eine Schleife die zweidimensionale Routenkonflikttabelle allokiert Danach werden die harten und weichen Konflikte in diese Tabelle durch den Aufruf der Funktion KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 164 void setConflicts struct conflict_t confs struct rd_data_t rdd eingetragen Diese Funktion erhalt eine Liste von Routenkonflikten und tragt fiir jeden Konflikt den entsprechenden Wert in die Konflikttabelle der Route Dispatcher Projek tierungsdaten ein Diese ist als Zieladresse zu spezifizieren Um dann die Menge der ben tigten Queues zu bestimmen wird in einer Schleife ber alle Routen folgende Funk tion aufgerufen struct queue_tmp_t makeQueueTmp struct route_t routedef struct queue_tmp_t list Wobei hier der Struct folgenderma en aussieht struct queue_tmp_t int queue int rr int rt struct queue_tmp_t next queue ist hier die ID des Queues rr die ID des Routerequest Sensors rt die ID der Route und next der Verweis auf das n chste Element der Liste Die eben genannte Funktion erstellt eine Liste der erforderlichen Queues um mehrere Routen auf einen RouteRequest Sensor abzubilden Hierbei wird bei jedem Aufruf eine neue Routendefinition und die bis jetzt erstellte Queue Liste bergeben die dann gegebenenfalls erg nzt wird Die Anzahl der Queues wird dann in die Route Dispatcher Projektierungsdaten einge tragen Als n chstes wird die Tabelle f r die Queues allokiert und ber eine S
246. chst die Datei RTD test specs director rts angepasst werden Relativ am Anfang muss die Zeile const char filename home wolf359 tracs cvs compiler code final pd auf die zu verwendende Projektierungsdaten Datei angepasst werden Am Anfang der Hauptprozedur abstract machine director_main k nnen zudem weitere Einstellungen vorgenommen werden Gesetzt werden k nnen die Werte e debug auf 1 gesetzt erfolgen mehr Ausgaben bei der Generierung der Testf lle e comp_debug auf 1 gesetzt erfolgen mehr Ausgaben beim Vergleich der Outputs von SUT und Orakel e single_test auf 1 gesetzt erfolgt kein kompletter Durchlauf aller Testf lle sondern nur ein einzelner Test In dem direkt folgenden Abschnitt k nnen dann die Werte f r diesen einzelnen Test gesetzt werden Beispielhaft k nnte das so aussehen single_gen_queues int malloc sizeof int 4 single_gen_queues 0 0 single_gen_queues 1 single_gen_queues 2 single_gen_queues 3 0 0 2 2 single_gen_qpl 8 single_gen_rst 179 single_gen_left_queues 1 single_gen_rr 0 Die hier gesetzten Werte werden dann als seed f r die jeweiligen Variablen benutzt siehe auch die Beschreibung in 7 7 5 2 auf Seite 277 Was die einzelnen Werte letztlich f r Eingaben bewirken kann man bei Setzen von debug auf 1 erfahren da dann bei der Generierung mehr Ausgaben erfolgen Anmerkung Schl gt ein Testfall fehl werden die f r diesen Testfall verantwortlichen
247. cht m glich eine vollst ndige Testprozedur zu planen weil die Systemspezifikation nicht als endg ltig erkl rt worden ist KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 311 7 7 8 4 Sommersemester 2005 Relativ zu Beginn des Semesters wurde die Gruppe wieder um eine Person erweitert da durch Fertigstellung eines anderen Teilprojekts Arbeitskraft frei geworden war Es herrschte jedoch nach wie vor der Zustand dass die ben tigte Spezifikation nicht vorlag Es musste daher auf Arbeiten ausgewichen werden die zu diesem Zeitpunkt schon erle digt werden konnten wie z B die Implementierung des Projektierungsdaten Einlesens gl cklicherweise war dieses Format schon stabil Auch wurde die Fertigstellung der SI Spezifikation durch Reviews derselben unterst tzt Dar ber hinaus fiel in diese Phase auch die Vorbereitung des Projekttages in die eini ges wenn auch nicht alles an Kapazit t floss was im Nachhinein auch als berechtigt angesehen werden muss Erst kurz vor dem Projekttag konnte als die SI Spezifikation fertiggestellt war mit der Implementierung der Testprozeduren begonnen werden Bei der Aufwandssch tzung f r diese hatte man dann noch gewaltig danebengelegen man muss diese Prognosen im R ckblick als unerf llbares Wunschdenken betrachten Nach dem Projekttag kam zudem auch noch die Zeit in der der Abschlussbericht vorbe reitet werden musste so dass hier wiederum Zeit anderweitig eingesetzt werden musste die dann nat rlich d
248. chten auch wenn die Aufgabe mit solchen in der Praxis erprobten Werkzeugen theoretisch realisierbar w re KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 90 Bei der Entscheidung wurde haupts chlich das Werkzeug CUP Parser Generator for Java betrachtet welches vom Simulator Abschnitt 7 8 auf Seite 313 verwendet wird Es wurde der Versuch unternommen sich in dieses Werkzeug so einzuarbeiten so dass es auch in der Gruppe Netzgraph Anwendung finden kann Die Einarbeitungszeit stell te sich dabei aber schnell als recht gro heraus da zu jenem Zeitpunkt nur noch eine Person am gesamten Netzgraph Teil Projekt arbeitete Auch ergab sich augenscheinlich kein berzeugender Vorteil weder im Hinblick auf eine Beschleunigung der Implemen tierung noch eine Vereinfachung der Datengewinnung so dass die Idee der weiteren Verwendung verworfen wurde Wie bereits beschrieben ist eine DXF Datei in mehrere Teile untergliedert und darin ggf in mehrere als Einheit anzusehende Untergruppierungen Innerhalb dieser Untergrup pierungen sollten f r den jeweiligen Zweck z B ein Textfeld bestimmte DXF Codes und zugeh rige Werte vorhanden sein Nach weitergehenden Tests w hrend der Einar beitungsphase und des dritten Semesters berarbeitung der DXF Objekt Bibliothek stellte sich heraus dass nicht zwangsl ufig alle Codes vorkommen m ssen um in der CAD Software eine korrekte Darstellung zu gew hrleisten jedenfalls gilt dies f r das verwendete CAD S
249. chten ist und auch welche Einschr nkungen es in der vorliegenden Version hinsichtlich des Weltmodells und der M glichkeiten der TND gibt Das Handbuch ist im Abschnitt 7 2 4 zu finden Da dieses Handbuch eigentlich als eigenst ndiges Dokument gedacht war welches der Software beiliegt k nnen sich Wiederholungen in der Beschreibung im Hinblick auf ein zelne Teile dieses Berichtes ergeben Henrik R hrup 7 2 4 Benutzerhandbuch DXF CAD nach TND Konverter Dieses Dokument soll eine Einf hrung in den DXF CAD nach TND Konverter liefern Es werden Informationen zu der zum Betrieb erforderlichen Systemumgebung geliefert wie auch weitere Hinweise zum Erstellen einer TND Datei wie sie von anderen zum TRACS Projekt geh renden Komponenten benutzt wird 7 2 4 1 berblick Der DXF CAD nach TND Konverter ist eine eigenst ndige Software welche aus einer mit Hilfe der mitgelieferten Objekt Bibliothek erstellten CAD Datei in DXF Form ein Gleisnetz in TND Form generiert Diese TND enth lt alle notwendigen Informationen um das Gleisnetz zum Beispiel mit KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 105 dem TRACS Simulator der TND Dateien einlesen kann darstellen zu k nnen Damit ein solches Gleisnetz auch von einer Steuerungssoftware gesteuert werden kann m ssen jedoch noch weitere Informationen hinzugef gt werden Diese Informationen k nnen aber nicht aus dem Netzgraphen eines Stra enbahnnetzes abgeleitet werden und m ssen durch zus tzlich
250. cke optional 7 1 3 2 2 DefBlock lt defblock gt lt DEFINITIONS gt lt typdef gt lt typdef gt lt sensdef gt lt pointdef gt lt sigdef gt lt routedef gt lt markdef gt lt hwdef gt lt crossdef gt KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 64 lt sensdef gt lt senstype gt lt SENSID gt lt SENSID gt lt senstype gt lt RRSENSORS gt lt TDSENSORS gt lt TGSENSORS gt lt SDSENSORS gt lt SGSENSORS gt lt pointdef gt lt pointtype gt lt POINTID gt lt POINTID gt lt pointtype gt lt SLPOINTS gt lt SRPOINTS gt lt LRPOINTS gt lt SLRPOINTS gt lt sigdef gt lt sigtype gt lt SIGID gt lt SIGID gt lt sigtype gt lt LSIGNALS gt lt SSIGNALS gt lt RSIGNALS gt lt SLSIGNALS gt lt SRSIGNALS gt lt LRSIGNALS gt lt SLRSIGNALS gt lt routedef gt lt ROUTES gt lt ROUTEID gt lt ROUTEID gt lt markdef gt lt MARKS gt lt MARKID gt lt MARKID gt lt hwdef gt lt HWCLASSES gt lt HWID gt lt HWID gt lt crossdef gt lt CROSSINGS gt lt CROSSID gt lt CROSSID gt Im Definitionsblock werden alle in der Gleisnetzbeschreibung vorkommenden Elemente deklariert Das gilt fiir Hardware Elemente wie Weichen Sensoren Signale und Kreu zungen genau wie f r logische Elemente Routen Markierungen und Ha
251. ckers simuliert Der Checker verarbeitet die Eingaben des Testgenerators ebenso wie der Testling selbst und ver ndert innerhalb der Simulation seinen Zustand gem ss der Spezifikation Sind laut Spezifikation Aktionen des Testlings zu erwarten so pr ft der Testchecker den Soll Zustand des Shared Memory vom Testling und pr ft damit ob sich der Testling spezifikationsgem ss verh lt Hierzu sind also f r alle Shared Memory Aktionen der Spezifikation zus tzliche Funktionen notwendig die jede Shared Memory Aktion des Testlings in Abh ngigkeit seiner Projektierung berpr fen Diese Funktionen ersetzen in der Simulation der Spezifikation die eigentlichen Aktionen da der Testchecker nur passiv wirken soll Der Testchecker muss allerdings nicht nur die Eingaben des Testgenerators verarbeiten sondern auch die internen Zustandsfelder wie Befahrungskonstellationen einzelner Rou ten verwalten Da diese aus Sicht von Integrationstests nicht sichtbar sind k nnen sie innerhalb des Testcheckers nicht im Testling eingesehen werden und m ssen dement sprechend als eigene Kopie zu Vergleichszwecken selbst verwaltet werden Helge L ding 7 7 7 6 Integrationstests Im Software Integrationstest werden nun alle Softwarekomponenten auf korrektes Zu sammenspiel gepr ft Hierbei laufen Testumgebung und Testling auf dem selben Rech ner da hierbei nur Softwareaspekte der Integration interessant sind Mit dem oben beschriebenen Testgenerator und Testcheck
252. ct idlist_t 1 crossing struct symtab_entry_t points struct idlist_t switchtime long int next struct slipswitch_t D eS Abbildung 7 33 struct slipswitch_t sen um einzelne Routen sicher befahren zu k nnen Diese Informationen bilden den Grundstock der vom tram Compiler zu generierenden Projektierungsdaten da sie pro Route direkt in Treiberbefehle der entsprechenden Gleisnetzelemente umgesetzt werden In Abbildung 7 37 wird dargestellt wie Informationen ber Signal und Weichenstellun gen pro Route im tram Syntaxbaum abgelegt werden 7 4 3 4 8 struct conflictt Die Bl cke Conflicts und Pointconflicts der TRACS TND beschreiben welche Routen nie gleichzeitig befahren werden d rfen da auf diesen Routen Kollisionen nicht auszuschliessen w ren Aus diesen Informationen entsteht innerhalb der Projektierungsdatengenerierung der sogenannte Route Conflict Table der vom TRACS Steuerinterpreter genutzt wird um Routen sicher freigeben zu k nnen N here Informationen hierzu finden sich in Abschnitt 7 5 Abbildung 7 38 zeigt wie Konflikte zwischen Routen innerhalb des tram Syntaxbaumes repr sentiert werden bevor sie in Projektierungsdaten umgesetzt werden k nnen 7 4 3 4 9 struct hwmap_t Der Block Hardwaremap der TRACS TND beschreibt welche Hardwareelemente von welchen Treibern bedient werden Hierzu werden soge nannte Hardwareklassen beschrieben die alle Elemente die einen Treibertyp nu
253. d Management a Ho ra Eher GEN Wberblie 412 4 45 0 erinnerte 9 2 2 Verwaltungsgruppen ox Brecht Sp eee a 9 2 3 Arbeitsgruppen lt 4 220 18 ad Hw ORS He we 9 2 4 Projektplenum und weitere Treffen aller Teilnehmer 9 25 SZeitplan me s alg PP Shy eB Ba a en 9 2 6 Abschlie ende Bewertung 2 2 2 22 nn nennen A TND Grammatik A 1 Lexergrammatik der TND Version 3 0 29 4 2005 A 2 Parsergrammatik der TND Version 3 0 29 4 2005 B DXF Datei Format B 1 B 2 B 3 Aufbau einer DXF Datei 4 2 er a a a B 1 1 F r TRACS relevante Codes 2 22 aa Bel Erl uterungen sr ine ede 4 eee Ede Vereinfachte DXF Grammatik 2 2 2 2 EL EL nn DEP Beispiel Aa dor Sian Beta On see ira Dias Bay B 3 1 Beispieldatel 2 02 23 W232 Pa Diaz an ara ann B 3 2 Auszug aus BLOCKS Section 2 versteh INHALTSVERZEICHNIS 5 B 3 3 Auszug aus ENTITIES Section 22222222 467 C DXF Objekt Bibliothek 470 Gol SGAD Bibl chek oe a er ee ee a ee zei ke 470 D Netzgraph Konfigurationsdatei 473 D 1 Beispiel einer Netzgraph Konfigurationsdatei 473 E Netzgraph Konverter Element Listen Ausgabe 475 E 1 Beispielgleisnetz 2 er ae En Endes nee bier 475 E 2 Element Listen Ausgabe 2 2 m En nn nn 476 F Glossar 481 G Literaturverzeichnis 486 Kapitel 1 Einleitung Dieser Bericht dokumentiert das studentische Projekt TRACS TRAin Control Sys tem der Universit t Bremen
254. d auf den Webauftritt der Freunde der Bremer Stra enbahn e V Fre04 verwiesen 2 4 2 2 Arbeitsschritte Vortrag Nach Festlegung der Gruppenmitglieder wurde ein Vortrag ausgearbeitet und gegen Ende des ersten Semesters eine erste Version an alle Projektmitglieder gesendet Auf dem Projektwochenende wurde ein kurzer berblick des Vortrags zur Diskussion gebracht und festgestellt dass dieser auch f r Besuche bei weiteren Firmen genutzt werden soll Nach Einarbeitung einiger Anregungen wurde eine neue Version zur Durchsicht ver schickt Wiederum wurden Anregungen nun mehr das Layout als Inhaltliches eingear beitet zus tzlich eine Grafik als Projekt bersicht sowie die beschlossenen Kurzvortr ge der einzelnen Gruppen Nach mehreren Revisionen wurde dann eine entg ltige Fassung erst kurz vor Beginn des zweiten Semesters fertig F r den Fragenkatalog wurden der BSAG Gruppe aus den anderen Gruppen Fragen ge stellt die sich teilweise aufgrund der Informationen von Prof Dr Jan Peleska erledigten wohingegen nat rlich auch neue Fragen auftauchten Besuchsorganisation Die erste Kontaktaufnahme erfolgte im November 2003 per Telefon Es gab ein Gespr ch mit Herrn Kai Teepe Bauleitung bei dem kurz das Projekt TRACS und die uns inter essierenden Themen vorgestellt wurden Da Herr Teepe verantwortlich f r die Bauarbei ten am Schienennetz war wurde als Besuchstermin statt vor Weihnachten 2003 Ende Januar 2004 vereinbart Bei der e
255. d der schwierigen Bedingungen so schon war Wenn man w hrend des KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 121 Projektwochenendes detaillierter ber andere L sungswege nachgedacht h tte und sich nicht so schnell auf die nun vorliegende CAD Variante fixiert h tte so w re man viel leicht schon zu jenem Zeitpunkt auf etwas hnliches gekommen Aber nun zur eigentlichen Idee 7 2 5 8 1 Grafisches Baukastensystem Anstatt die Eingabe des Gleisnetzes mit tels einer CAD Software vorzunehmen um deren Ausgabedatei dann zu konvertieren h tte man gleich eine Eingabem glichkeit w hlen sollen welche eine Konvertierung ber fl ssig macht Ein Baukastensystem mit grafischer Benutzeroberfl che in welchem man eine wie im CAD Programm vordefinierte Element Bibliothek zur Verf gung h tte mit dessen Hil fe man das Gleisnetz direkt zusammensetzen k nnte w re durchaus die bessere L sung gewesen Die Objekte welche die Gleisnetzelemente darstellen w ren intern bereits so struktu riert so dass man durch Zusammensetzen mehrerer Objekte bereits die Nachbarschafts beziehungen auslesen k nnte Der ganze umst ndliche Umrechungs und Extrahiervor gang w rde wegfallen Auch die Benennung der Elemente w re einfacher wenn man einfach nur das Element markieren und ihm einen Namen geben k nnte welcher dann einfach im Objekt ab gespeichert werden w rde anstatt durch zus tzlicher Erzeugung eines eigenen Blockes die Zusammengeh rigkeit
256. d diese auch auf diesel be Weise interpretieren Damit dies m glich ist muss die Beschreibung der einzulesenden Sprache der TND so exakt wie m glich gehalten sein und keinen Interpretationss pielraum bieten 7 8 5 2 Simulation Zu der Simulation werden die Implementierungen der wichtigsten und interessantesten Algorithmen vorgestellt An einigen Stellen wurde eine ganz bestimmte Art der Im plementierung gew hlt die erl utert und begr ndet wird Die interessanten Stellen der Simulation sind unseres Ermessens nach die Positionsbestimmung der Stra enbahn d h Berechnung einer neuen Position die Vorausschau auf die n chsten Signale die sich in Sichtweite befinden die Vermeidung von Auffahrunf llen und die Kollisions berpr fun gen die auf dem physikalischen Weltmodell basieren KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 378 7 8 5 2 1 Positionsbestimmung der Tram Auf Grundlage der Programmstruk tur des Bewegungsalgorithmus 7 8 4 4 2 auf Seite 343 wird nun der Quellcode erklart wie die Stra enbahn einen Schritt vorw rts gesetzt wird bzw wie die neue Position errechnet wird 01 private Linkable calculatePosition int posArr TrackElement teArr boolean dirArr boolean head 02 if emerge gt 0 amp amp head 03 return null 04 else 05 int pos posArr 0 06 boolean dir dirArr 0 07 TrackElement te teArr 0 08 Linkable 1 null Die Methode calculatePosition wird aufgerufen
257. d ein Gegenbeispiel erzeugt In dem Gegenbeispiel wird ein Zustand erzeugt in dem eine Sicherheitsbedingung nicht erf llt ist safe sri amp sr2 amp sr3 amp sr4 amp sr5 Die Invariante safe beinhaltet also fiinf Bedingungen die folgende Bedeutungen haben e sri enth lt alle Sicherheitsbedingungen die eingehalten werden m ssen damit keine Bahnen aus unterschiedlichen Richtungen auf dieselbe Kreuzung zufahren so dass es zu einem Flankenzusammensto kommen kann e sr2 enth lt alle Sicherheitsbedingungen die eingehalten werden m ssen damit keine Bahnen aus unterschiedlichen Richtungen auf dieselbe Weiche zufahren so dass es zu einem Flankenzusammensto kommen kann e sr3 enth lt alle Sicherheitsbedingungen die eingehalten werden m ssen damit keine Bahnen auf Weichen auffahren wenn das Auffahren nicht m glich ist e sr4 enth lt alle Sicherheitsbedingungen die eingehalten werden m ssen damit keine Weichen umgeschaltet werden w hrend sie befahren werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 229 e sr5 beinhaltet alle Sicherheitsbedingungen die eingehalten werden m ssen damit keine Bahnen in entgegengesetzter Fahrtrichtung aufeinander zufahren so dass es zu einem Frontalzusammensto kommen kann Jede dieser fiinf Bedingungen beinhaltet die Sicherheitsbedingungen der jeweiligen Ka tegorie die in dem konkreten Gleisnetz gelten miissen 7 6 4 7 1 Erste Sicherheitsbedingung Ist eine Kreuzung von zwei u
258. dacht realisiert werden konnten An der einen oder anderen Stelle gab es Kommunikationsprobleme zwischen den einzelnen Teilgruppen oder aber auch im gesamten Projekt und der Schwund an Projektmitgliedern bis zur Halbzeit des Projekts machte das Erreichen des Ziels nicht gerade einfacher Letzten Endes steht das System wobei die angedachte Verifizierung nur teilweise durchgef hrt werden konnte Henrik R hrup Kapitel 2 Die Dom ne 2 1 Einleitung Im folgenden Kapitel wird die Dom ne in der das von TRACS entwickelte System angesiedelt ist n her beleuchtet Diese Betrachtung dient als eine wichtige Grundlage der anschlie enden Entwicklungsarbeit Es wird so eine gemeinsame Basis geschaffen auf der alle Komponenten des Systems aufbauen und an die sie sich halten m ssen Damit wird auch eine m gliche Quelle f r Inkonsistenzen zwischen einzelnen Komponenten weitgehend ausgeschaltet Das Kapitel ist in insgesamt drei Abschnitte unterteilt e Die Umwelt Hier beschreiben wir die Umwelt in der ein Stra enbahnsystem angesiedelt ist und deren Einfluss es ausgesetzt ist e Die Technik Hier beschreiben wir die typischerweise in einem Stra enbahnsys tem vorkommende Technik und ihre Funktion e Die Experten Hier wird ber Kontakte zu Dom nenexperten berichtet die sich w hrend des Projektes ergaben und die zur Informationsgewinnung genutzt wurden Arne Stahlbock 2 2 Die Umwelt Die sichere Fahrt einer Bahn kann durch viel
259. de Module bieten sich die Kommunikationsschnittstelle beide Rich tungen einzeln die Sensoren die Weichen die Signale und die Stra enbahnen an Hierbei soll nun nicht mehr jede Methode einzeln getestet werden sondern die Ergebnisse die solch ein Modul produziert Beispiele f r solche Tests w ren der Gesamtvorgang des Umsetzens von Schaltanforderungen die korrekte Fahrt ber Weichen und Kreuzungen etc e Zusammenspiel von Daten und Visualisierung An dieser Stelle soll eher stichprobenartig getestet werden ob die angezeigten Informationen mit den abgespeicherten in der Datenstruktur bereinstimmen Dies betrifft vor allem die Informationen die nicht 1 zu 1 bertragen und visualisiert werden k nnen wie die Ortskoordinaten und die Zust nde von Sensoren Weichen und Signalen Auch die Vorausschau der Bahnen zum n chsten Signal empfiehlt sich hier zu testen da sie ein interner Teil ist der visualisiert leicht zu berpr fen ist e Funktion des Simulators mit angeschlossenem SI Die allgemeinste Ebene der Tests ist das so genannte Black Box Testen des ge samten Simulators Hierzu wird ein Steuerinterpreter angeschlossen und Situa tionen initialisiert die dann durchlaufen werden k nnen Dazu m ssen vorher die erwarteten Ergebnisse aufgeschrieben werden die nach dem Testlauf dann mit den tats chlich durch den Simulator protokollierten Ergebnissen verglichen wer den Auf diese Tests muss bisher leider verzichtet werden d
260. definiert Am zweiten davon befindet sich ein Signal Der Simulator wird nun mit dieser TND beschickt und eine vorkonfigurierte Simulation gew hlt bei der das Signal im undefinierten Zustand belassen wird Die Zahl der Bah nen wird auf eine beschr nkt diese soll die einzige m gliche Route befahren Erwartet wird dass die Bahn am Signal anh lt Das Logfile enth lt folgenden Output nur Auszug der relevanten Stellen INFO Tram Tram Wrong signal percepted ini iteration eer INFO Trying to move 138 80043 steps INFO Tram TramO is now located Head on TE 1 between HW g1 and HW g2 at distance 19570 Tail on TE 1 between HW gi and HW g2 at distance 16371 INFO Time 1111182650317 INFO Trying to move 139 60043 steps INFO Tram TramO is now located Head on TE 1 between HW gi and HW g2 at distance 19709 Tail on TE 1 between HW gi and HW g2 at distance 16510 INFO Time 1111182650427 INFO Trying to move 139 40044 steps INFO Tram TramO is now located Head on TE 1 between HW gi and HW g2 at distance 19848 Tail on TE 1 between HW gi and HW g2 at distance 16649 INFO Time 1111182650537 INFO Trying to move 139 20044 steps INFO Tram TramO must stop in front of signal while 89 20044 steps are pending INFO Tram TramO must stop in front of signal while 0 0 steps are pending INFO Tram TramO is now located Head on TE 1 between HW gi and HW g2 at distance 19898 Tail on TE 1 between HW gi and HW g2 at distance 16699 IN
261. den s RC Daten ist im Wesentlichen also eine Disjunktive Normalform Ausserdem wird eine Liste von Hardware Timeouts bergeben und zwar als SHM ID Timeout Tupel struct sensor_value_t int id1 int id2 int relation int value struct sm_condition_t int type union struct shm_value_t shm_value struct sensor_value_t sensor_value condition struct hw_timeout_t int id time_t timeout struct sm_data_t struct sm_condition_t sm_conditions struct hw_timeout_t hw_timeouts KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 198 Bei struct sensor_value_t muss genau eins der beiden Elemente id2 oder value ge setzt sein einen positiven Wert haben das jeweils andere muss einen negativen Wert haben relation gibt an was wie verglichen werden soll Bei relation 0 wird auf Gleich heit verglichen Bei relation 1 wird verglichen ob id1 kleiner ist als id2 oder value Bei relation 2 wird verglichen ob id1 gr sser ist als id2 oder value Bei relation 3 wird ver glichen ob id1 kleiner oder gleich ist als id2 oder value Bei relation 4 wird verglichen ob idl gr sser oder gleich ist als id2 oder value 7 5 4 6 5 Gesamtformat Die Projektierungsdaten bestehen im Gesamtformat aus den Daten fiir die einzelnen Tei le und davon einem Block mit Offset Daten und einem Block mit Versionsinformationen aneinandergereiht Durch den Offset Block kann beim Auslesen der Projektierungsda ten berechnet werden
262. den die Eingabedatei also korrekt aufgebaut ist Der Lexergenerator flex erh lt als Eingabe die Datei tram 1 welche in Form von re gul ren Ausdr cken definiert welche Token der zu generierende Lexer unterscheiden soll Wird ein Token erkannt so liefert der generierte Lexer neben der eigendlichen Token Information den Inhalt des Tokens als String an den Parser da aus diesen Informationen anschliessend ein Syntaxbaum mit Symboltabelle aufgebaut werden soll Die Tokende finitionen f r den Lexergenerator flex entsprechen den regul ren Ausdr cken die in Abschnitt 7 1 die lexikalischen Regeln der TRACS TND definieren Der folgende Aus schnitt aus der tram 1 zeigt wie f r einen Weichenbezeichner ein regul rer Ausdruck definiert wird und wie der tats chliche Bezeichnername zus tzlich zum Tokennamen an den Parser weitergeleitet werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 142 w L alnum yylval cp malloc strlen yytext 1 memcpy yylval cp yytext strlen yytext 1 return POINTID Ausdruck Weichen Die vom Lexer gelieferten Token werden von einem Parser auf syntaktische Korrektheit berpr ft der mit bison generiert wird Dieser Parsergenerator erh lt als Eingabe die Datei tram y in der die zu erkennende Grammatik spezifiziert ist Zus tzlich zu den einzelnen Regeln der zugrundeliegenden Grammatik finden sich in dieser Datei Auswer tungsregeln die pro Grammatikregel aus den vom Lexer gelieferten Token S
263. den ggf angeschlos senen Steuerinterpreter und die Treiber zu starten Ein Anbinden des SI w hrend einer laufenden Simulation erscheint nicht ratsam da der SI dann potentiell bereits eine kri tische und nicht mehr behebbare Situation vorfinden k nnte Anschlie end erfolgt der Start der Simulation ber Options Start Simulation Nun beginnen die ersten Bahnen in das Gleisnetz einzutreten und ihre Routen zu absol vieren Sensoren geben R ckmeldungen Signale und Weichen nehmen Stellanweisungen an Ist f r ein Hardware Element kein Treiber angemeldet so gibt dieses keine R ck meldungen ab es wird dann nur im Simulationslog festgehalten dass eine R ckmeldung mit einem bestimmten Text erfolgt w re aber nicht gesendet werden konnte da kein Treiber bekannt war an den man h tte senden sollen Anweisungen an die Elemente kann man hingegen auch geben wenn f r das Element kein Treiber aktiv ist Man be nutze hierf r eine Telnet Konsole die Verbindungsanfrage ist an Port 12345 auf dem Simulatorrechner zu richten Nach Verbindungsaufbau kann dann ein Request String eingegeben werden nach Absenden des Befehls beendet sich die Verbindung wieder Zu beachten ist dass diese Hintert r zur Befehlseingabe auch f r die Elemente funktio niert f r die ein Treiber angemeldet ist Der Treiber bzw der SI bek me in dem Fall KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 417 nicht direkt mit dass eine Anweisung gegeben wird sondern w rde erst ei
264. der Stra en bahn e Visualisierung einer Stra enbahn e Schnittstelle zu den Treibern bertragung von Anforderungen und Statusmel dungen e Treiber Beispiel Weichentreiber 7 8 5 1 Auszug aus einem TND Einlesevogang Das Einlesen einer TND Datei ist keine triviale Angelegenheit wie bereits im Kapi tel 7 8 4 3 auf Seite 334 beschrieben wurde Vor allem die Abbildung 7 63 auf Seite 335 gibt einen Eindruck dar ber wie viele Stationen durchlaufen werden m ssen bis die Informationen aus einer einzigen Zeile Text in der TND Datei eingelesen und verarbei tet sind An dieser Stelle wollen wir anhand eines Beispiels den Durchlauf und die darin enthaltenen Stationen erl utern Alle nun folgenden Codeausz ge sind nur Bruchteile der eigentlichen Dateien lexer def parser def Best TramNetworkBuilderOfTheUNlIverse java und teilweise auch vereinfacht dargestellt Die Zahlen am Anfang jeder Zeile sind nur f r die Erkl rung hinzugef gt worden sie sind nicht Teil der originalen Dateien Die vollst ndigen Dateien sind auf der dem Bericht beigef gten CD enthalten KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 373 Anmerkung Dieses Beispiel stammt von September Oktober 2004 inzwischen hat sich der Code der genannten Dateien wegen diverser TND Anderungen ebenfalls ver ndert dieses Beispiel wird aber hier beibehalten da die Anderungen die Grammatik betreffen nicht aber die Vorgehensweise mit der der Simulator das Einlesen betr
265. der mehrere Gleise entspringen nennt sich Ver zweigungsseite branch die andere Seite mit einem Gleis hei t Stammseite stem CAD s Computer Aided Design Callback Funktion Funktion dazu bestimmt sind als Funktionszeiger an einen an deren Programmteil bergeben zu werden und von diesem in klar definierten Situationen aufgerufen zu werden Casting Unter bestimmten Bedingungen kann in einem Programm eine Variable eines gegebenen Typs in einen anderen Typen berf hrt werden dies bezeichnet man als Typumwandlung oder Casting Central Processing Unit Central Processing Unit CPU hei t bersetzt so viel wie Zentraleinheit Im allgemeineren Sinne fasst man unter Zentraleinheit den Rechnerkern und den Hauptspeicher zusammen Lex97 S 546 Compiler Ein Programm das Text aus einer Programmier Sprache in einen ma schinenlesbaren Code bersetzt Computer Aided Design kurz auch CAD genannt Eine moderne M glichkeit grafische Modelle zu entwerfen Mit Hilfe von Bildbearbeitungsprogrammen die den Schwerpunkt technisches Zeichnen haben entstehen Objekte am Computer Concurrent Versions System Concurrent Versions System CVS hei t bersetzt so viel wie Versionsverwaltungssystem Dieses System verwaltet Versionen von Dateien auf einem zentralen Server und erleichtert die Arbeit wenn mehrere Personen an einer Datei arbeiten und ihre nderungen zusammenf gen m ssen CPU s Central Processing Unit CUP
266. der realen Ubertragungszeit m glichst hnlich sein e Die simulierten Stra enbahnen sollen ihre Entscheidungen m glichst in Echtzeit treffen Die Reaktionszeit einer Stra enbahn die kurzfristig noch ein rotes Signal bekommt soll m glichst realistisch simuliert werden Dieser Aspekt sollte bei allen Aufgaben zur Realisierung dieses Simulators gut im Auge behalten werden damit gleich im Voraus bei der Struktur des Simulators keine unn tigen Erschwernisse eingebaut werden Ein Verzicht auf Speicheroptimierung zugunsten der Geschwindigkeit bietet sich hier an Auf unterschiedliche Simulationsgeschwindigkeiten wird verzichtet da der SI auch im realen Leben nicht mit Elementen die in v llig anderen zeitlichen Gr enordnungen arbeiten konfrontiert w rde 7 8 2 7 Systemumgebung Die Systemumgebung in der der Simulator laufen soll muss bestimmten Anforderungen gerecht werden So soll der Simulator genau wie den SI auf Standard PC Hardware laufen k nnen Auch an das Betriebssystem sollen keine besonderen Forderungen gestellt werden Vorgesehen ist ein gew hnliches d h nicht speziell konfiguriertes oder gar umprogrammiertes Li nux einzusetzen Sollte der Simulator zus tzlich auf weiteren Systemen laufen so w re das ein Nebeneffekt auf den nicht gezielt hingearbeitet wird der aber auch durchaus zu begr en w re Das System auf dem der Simulator l uft muss mit demjenigen auf dem der SI l uft kommunizieren k nnen Da n
267. des jewei ligen Gleisnetzes erm glichen Anhand der in der TND Netzwerkbeschreibung enthaltenen Informationen kann be stimmt werden an welcher Stelle des Gleisnetzes sich zu welchem Zeitpunkt Bahnen befinden k nnen und welche Sicherheitsbedingungen das System erf llen muss Anhand der in den Projektierungsdaten enthaltenen Informationen kann bestimmt werden wie das Steuerungssystem die Weichen und Signale schalten soll KAPITEL 6 VALIDIERUNGS VERIFIKATIONS UND TESTPROZESS 56 Es kann nun durch Model Checking iiberpriift werden ob ein Zustand erzeugt werden kann in dem eine der spezifizierten Sicherheitsbedingungen verletzt wird Dies wird im Abschnitt 7 6 auf Seite 203 detaillierter beschrieben Entwicklungsschritt Verifikationsschritt TND Netzwerk Beschreibung eae Abstraktion der SI Spezifikatio TND NW erstellen Abstraktion der TND NW Verifikation der Projektierungsdaten Projektierungsdaten mit SI Spezifikation gegen die Sicherheitsbedingungen Model Checker Sicherheitsbedingungen erf llt Rot Komponente oder Pfad wird als korrekt angenommen Dicke Elipse Wiederverwendbares Produkt Normal Elipse Nicht wiederverwendbare Daten Abbildung 6 5 Verifikation der Projektierungsdaten Deng Zhou Ruben Rothaupt 6 6 Test der Steuerungssoftware Die Steuerungsoftware besteht aus dem wiederverwendbaren Steuerinterpreter und den gleisnetzspezifischen Projektier
268. des uns vorliegenden DXF Formates hat sich herauskristallisiert dass eigentlich nur zwei Sektionen von wirklichem Interesse sind Dies ist zum einen die Sektion ENTITIES wo letztlich alle Zeichenelemente z B Linien Punkte etc mit ihrer genauen Lage Ausrichtung und sonstiger Formatierung vermerkt sind Zum an deren ist dies die Sektion BLOCKS in der die zuvor genannten Bl cke definiert sind welche dann in der Sektion ENTITIES nur noch als INSERT Einf gung wie ein normales Zeichenelement vermerkt werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 89 Ein Auszug aus einer Beispiel DXF Datei sowie die fiir uns relevanten DXF Elemente sind im Anhang B 3 auf Seite 463 zu finden 7 2 3 2 CAD TND Konverter Um ein per CAD System graphisch erstelltes Gleisnetz weiterverarbeiten zu k nnen wird ein Konverter ben tigt der das Dateiformat der CAD Software in unser TND Format transformiert Dies ist das zweite wichtigste und zugleich aufw ndigste Arbeit spaket im Teilprojekt Netzgraph Die Vorarbeit n mlich das Kennenlernen des Ausga beformates der CAD Software wurde im vorangegangenen Arbeitspaket durchgef hrt Weiterhin ist zu beachten dass der Konverter von der Definition des TND Formats abh ngt Um so einen Konverter zu implementieren gibt es mehrere Wege und mehrere verwend bare Programmiersprachen 7 2 3 2 1 Entscheidung f r Java als Programmiersprache Wir haben uns f r Java als Programmiersprache f r den CAD R
269. die Adresse des zweiten Sensors mitsamt Seitenangabe und der Bezeichner fiir die jeweilige Markierung bergeben Sind letzere Beiden nicht vorhanden wird NULL iibergeben Die letzte Reduktion zum routeblock erfolgt gem den bereits gezeigten Bl cken routeblock ROUTEDEFINITIONS rtdeflist Es wird auch wie bereits vorher eine Listenstruktur erm glicht rtdeflist rtdef makeRouteList rtdef rtdeflist makeRouteList KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 160 Die einzige nderung zu den meisten vorhergehenden Bl cken ist die Reduktion auf rtdef die folgenderma en aussieht rtdef ROUTEID SENSID SENSID kommasenslistopt REQUESTAT SENSID kommasenslistopt makeRoute Als erstes steht der Bezeichner der Route gefolgt von den Bezeichnern zweier Senso ren und einer kommasenslist die eine Liste von weiteren Sensoren erm glicht einem Schl sselwort f r einen Requestsensoren und mindestens einem Bezeichner f r den ent sprechenden Sensoren Die Funktion makeRoute erstellt dann einen einen Eintrag in der Routedefinitions Liste wobei sie den Bezeichner f r die Route die Adresse der Idlist f r die Sensoren und die Adresse der Idlist der Requestsensoren bergeben bekommt Wie der Postfix bereits andeutet ist die kommasenslistopt optional da durch die bereits bekannte Regel realisiert ist kommasenslistopt kommasenslist empty Die kommasensli
270. die TRACS Steuerungssoftware zu testen war eine Testumgebung notwendig Diese bestand aus einem Computer der ber die notwendige Testsoftware verf gte F r Tests die die Hardware mit einbeziehen h tte man den Computer noch mit bestimmter Hard ware z B IO Karten ausstatten m ssen Zur Kommunikation zwischen Testumgebung und dem Testling Softwaresystem k nnen dann je nach Testebene verschiedenene Kommunikationskan le eingesetzt werden Diese sind e Umgebungsvariablen globale Variablen e bergabeparameter und R ckgabewerte e Shared Memory e 1 O Karten bzw Leitungen Bei den von uns durchgef hrten Unit Tests wurde sich auf Ubergabeparameter und R ckgabewerte beschr nkt da die hier zu testenden Funktionen in dieser Form alle von ihnen ben tigten Daten bekommen k nnen Durch die Kan le fand der Datenaustausch zwischen beiden Systemen statt Testein gaben wurden in den Testling eingespeist und anhand dessen Ausgaben wurde das Testergebnis bestimmt Die Voraussetzung f r dies war ein Rechner mit Betriebssystem welcher die von der Testsoftware und dem Testling solange es um Software Tests geht ben tigten Funk tionalit ten anbot F r die TRACS Testumgebung war ein PC Computer ben tigt auf dem ein Linux Betriebssystem installiert war Ein Linuxsystem ist notwendige Voraussetzung f r den KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 259 RT Tester 6 0 der als Testsoftware fiir die TRACS Steuerungssoftware eingese
271. dkoordinaten werden nun die Koordinaten des vordersten Punktes des gezeichneten Abschnittes gesetzt if tailDir 4 try tailTE Linkable borders 1 getNextTE tailTE false true KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 392 if borders 1 tailTE getBorders 0 tailDir true else tailDir false catch NetworkEndException ne break else try tailTE Linkable borders 0 getNextTE tailTE false true if borders 0 tailTE getBorders 0 tailDir true else tailDir false catch NetworkEndException ne break borders tailTE getBorders length tailTE getLength coords 0 calcCoords borders 0 getCoords coords 1 calcCoords borders 1 getCoords Es wird nun mittels der Funktionen f r die Fortbewegung der Bahn das vom Ende der Bahn aus n chstvordere TrackElement ermittelt und zum Beginn der while Schleife zur ckgekehrt Befindet sich der Kopf auch nicht auf diesem TE hei t das dass der n chste Abschnitt der Bahn sich ber das ganze TE erstreckt dieses wird gezeichnet das n chste TE weiter vorn geholt die Position des Kopfes gepr ft usw headCoords 0 coords 0 0 int double headPos double length x coords 1 0 coords 0 0 headCoords 1 coords 0 1 int double headPos double length x coords 1 1 coords 0 1 drawTram g HEAD_TAIL headCoords 0 headCoords 1 tailC
272. ds 37 8 15 0 0 0 name s3006 category signals type signal_slr properties WS RRS RRL WL WR RRR switchtime 300 ms coords 21 5 4 0 0 0 name g4114 category sensors type sensor_tg coords 19 4 34 0 0 0 name g4116 ANHANG E category type coords name category type coords name category type coords name category type coords name category type coords name category type coords name category type coords name category type coords name category NETZGRAPH KONVERTER ELEMENT LISTEN AUSGABE 477 sensors sensor_tg 21 5 44 0 0 0 g4115 sensors sensor_tg 30 0 44 1 0 0 g4111 sensors sensor_tg 32 5 20 0 0 0 g4017 sensors sensor_rr 9 4 34 0 0 0 g4018 sensors sensor_rr 30 0 45 1 0 0 g4014 sensors sensor_rr 21 5 7 9 0 0 g4110 sensors sensor_tg 30 0 0 9 0 0 g4109 sensors sensor_tg 32 5 10 1 0 0 g4013 sensors ANHANG E type coords name category type coords name category type coords name category type properties switchtime coords name category type properties switchtime coords name category type properties switchtime coords name category type properties switchtime coords NETZGRAPH KONVERTER ELEMENT LISTEN AUSGABE 478 sensor_rr 44 0 15 0 0 0 g4113 sensors sensor_tg 1 3 29 0 0 0 g4112 sensors sensor_tg 21 5 3 8 0 0 w1017 points point_sr_passive passive 800 ms 30 0 25 0
273. dung von CUP Parser Generator for Java hat ebenfalls einige Zeit ge kostet so dass beides im Hinblick auf eine Motivationssteigerung eher hinderlich war KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 120 und unterm Strich leider rund 6 Wochen Zeit verloren gegangen sind Die Diskussion tiber das Fiir und Wider ist in Abschnitt 7 2 3 2 2 auf Seite 89 zu finden Dar berhinaus gab es noch einige andere Probleme welche darauf zur ckzuf hren sind dass eine Person alleine bei einer Planung mehr Fehler macht oder Probleme iibersieht als wenn mehrere Personen sich der Sache annehmen So wurde zum Beispiel das Erkennen der Nachbarschaftsbeziehungen vollkommen falsch eingesch tzt woraufhin letztlich vier Wochen an Fehlersuche eingeschoben werden muss ten so dass gegen Ende ein gewisser Zeitdruck entstand welcher aber noch im Rahmen blieb da von vorn herein mit einem gewissen Zeitpuffer geplant wurde Wiederholte nderungen an der TND Beschreibung waren auch nicht unbedingt hilf reich aber die daraus resultierenden nderungen am Konverter hielten sich gl cklicher weise in Grenzen Letztlich ist ein gut funktionierender DXF nach TND Konverter entstanden welcher si cherlich besser h tte sein k nnen vor allem was die Fehlerbehandlung betrifft aber die eigentlich gew nschte Funktionalit t ist vorhanden Kurz vor Abgabeschluss wurden sogar noch ein paar Funktions Einschr nkungen beho ben welche allerdings nicht mehr ausf hrlich getestet
274. dwann ein Zustand erreicht in dem p erf llt ist e Alp U q Entlang aller Pfade im Transitionssystems ist p solange erf llt bis q erf llt ist 7 6 3 1 5 checkinvar declaration In der checkinvar_declaration Umgebung wer den Invarianten spezifiziert Dies sind Bedingungen die in allen Zust nden des Systems erf llt sein m ssen Das Schl sselwort INVARSPEC dr ckt aus dass eine Invariante folgt 7 6 3 2 Beispiel Es soll nun ein einfaches Beispiel angegeben werden Das Beispiel dient dazu das Grund prinzip von NuSMV zu verdeutlichen bevor im n chsten Abschnitt die Modellierung das eigentlichen Systems beschrieben wird Die Abbildung 7 46 zeigt eine einfache Kreuzung Vor der Kreuzung befindet sich jeweils ein Signal und hinter der Kreuzung ein Sensor Tsi gl Abbildung 7 46 Einfaches Gleisnetz KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 211 Es wird nun ein NuSMV Programm erstellt das die Sicherheit der Kreuzung nachweist So darf die Kreuzung niemals von verschiedenen Richtungen gleichzeitig erreichbar sein und die Kreuzung muss aus beiden Richtungen irgendwann zu erreichen sein F r das Beispielgleisnetz werden Variablen f r die Signale s1 und s2 erstellt Die beiden Signale sollen die Werte STOP und GO annehmen k nnen Ein Signal soll in den Zustand GO wechseln wenn es zuvor im Zustand STOP war und in den Zustand STOP wenn es zuvor im Zustand GO war Au erdem wird definiert dass ein Sensor erreichbar ist wenn sic
275. dware vom und an das Testsys tem umgeleitet werden dies geschieht allerdings innerhalb des Hardware Abstraction Layer der Schicht des Testsystems die Ein und Ausgaben des Testlings mit Test komponenten verbindet Abbildung 7 60 auf der n chsten Seite zeigt den Aufbau eines Hardware Software Integrationstests Zuletzt wird ein System Integrationstest durchgef hrt Hierbei bleibt der Testgenerator aussenvor da hier keine Testdaten mehr generiert werden sondern ein echtes Gleisnet ze an den Testling angeschlossen wird Der Testchecker bleibt unver ndert simuliert weiterhin die Spezifikation der Safety Controllers und berpr ft dadurch dessen spezi fikationsgem sses Verhalten Abbildung 7 61 auf Seite 310 zeigt den Testaufbau Helge L ding 7 7 7 7 Erw gungen zu Laufzeit und Timing Da insbesondere bei vielen Routen die flache Spezifikation eines Safety Controllers re lativ viele Zust nde enth lt ist davon auszugehen dass nicht alle Tests in angemesse ner Zeit ausgef hrt werden k nnen Um dieses Problem zu l sen muss eine geeignete Auswahl von Testf llen getroffen werden Hierzu ist eine Heuristik notwendig die die KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 309 SUT Testumgebung Linux Linux RT Tester Projektierungsdaten AM Generator AM Checker al Treiber i Treiber i ry System OI Karte E I Ol Karte H Ai
276. e Nichtterminal confdeflist bereits seine Auswertungsregeln im dariiber stehenden Block hat Der letzte auszuwertende Block ist der Hardwaremap Block Er sieht den anderen Bl cken wieder sehr hnlich hwblock HARDWAREMAP hwdeflist 2 hwdeflist hwclassdef makeHwmapList hwclassdef hwdeflist makeHwmapList hwclassdef HWID hwelid kommahwlistopt makeHwmap kommahwlistopt kommahwlist empty kommahwlist hwelid makeList hwelid kommahwlist makeList hwelid SENSID POINTID SIGID CROSSID Diese Auswertungsregeln sind in sehr hnlicher Form allesamt weiter oben in diesem Abschnitt bereits behandelt worden Sind alle Bl cke reduziert worden wird dann anhand der ersten Regel auf tnd reduziert KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 163 tnd defblock coordblock sigpropblock ptpropblockopt slipswitchblockopt relblock sigposblock routeblock condblock clearblock ptconfblockopt confblockopt hwblock Hiermit ware der Aufbau der Symboltabelle und des Syntaxbaums abgeschlossen Die weiteren Schritte zur Generierung der Projektierungsdaten folgen in den n chsten Ab schnitten 7 4 4 3 Projektierungsdaten In diesem Abschnitt soll erl utert werden wie die einzelnen Projektierungsdaten f r den Route Dispatcher den Route Controller und den Safety Monitor erzeugt werden die der Steuerinterpreter zur effizienten Steuerung eines Glei
277. e Schritte von der Eingabe bis hin zur TND Erzeugung durchf hrt statt wie in der gew hlten L sung drei Programme zu KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 122 haben von denen eines QCad au erdem noch nicht einmal von TRACS stammt Eventuell w re sogar eine Einbindung des Simulators an dieser Stelle m glich gewesen Jedenfalls h tte man somit auch die Visualisierung von einem als TND Datei vorliegen den Gleisnetz erhalten k nnen Vielleicht ist diese Idee in einem anderen Zusammenhang ja noch verwertbar aber f r TRACS kommt sie leider zu sp t 7 2 5 9 Fazit Die Arbeit in der Netzgraphgruppe war eher von Frust und Demotivierung gepr gt als durch das was eigentlich ein Hauptziel in einem Hauptstudiumsprojekt ist Teamarbeit denn diese gab es eigentlich nie Das Positive ist aber dass am Ende ein Produkt steht welches zwar mit kleinen nicht unbedingt gravierenden Einschr nkungen behaftet aber in dem geplanten Rahmen den noch funktionsf hig ist Ein Teil der urspr nglich geplanten Software ist aber letzten Endes entfallen wobei im Hinblick auf die Probleme auch niemals alles h tte entwickelt werden k nnen Da zu Beginn der Netzgraph Arbeit alles zu schnell auf eine Idee hin ausgelegt war ist ein besseres Produkt leider verhindert worden Dennoch Die gewonnen Erfahrungen werden f r die Zukunft sicherlich hilfreich sein derartigen Problemen rechtzeitig aus dem Wege zu gehen Henrik R hrup KAPITEL 7 BESCH
278. e Tools erg nzt werden welche diese Basis TND dazu einlesen k nnen In den folgenden Abschnitten werden zum einen die Systemvorausetzungen und zum anderen die Vorgehensweisen zur Benutzung dieses Konverters beschrieben Au erdem wird erkl rt wie ein Gleisnetz mittels einer CAD Software QCad und der mitgeliefer ten TRACS Objekt Bibliothek erstellt werden kann In diesem Software Paket befinden sich zwei Versionen des Konverters da ein paar Funk tionen nicht ausreichend getestet werden konnten Diese sind also nur in der Test Version verf gbar Genaueres ist im Abschnitt zu den Einschr nkungen bei der TND Erzeugung zu finden 7 2 4 2 Installation und Systemvoraussetzungen Generell ist anzumerken dass die Software auf einem Linux System mit aktuellem Ker nel der 2 6er Reihe entworfen wurde und auf jedem vergleichbaren System lauff hig sein sollte 7 2 4 2 1 Systemvoraussetzungen Sowohl die ben tigte JavaTM Entwicklungs umgebung bzw Laufzeitumgebung als auch die CAD Software QCad sind sowohl f r Linux als auch f r Microsoft Windows verf gbar Getestet wurde die Funktion aber nur auf einem Linuxsystem und einer i386 kompatiblen PC Plattform und daher wird in der vorliegenden Version die Ausf hrung auf anderen Plattformen auch unter bunden Bei der Entwicklung wurde ein Linux System mit Kernel der Version 2 6 genau ein Debian GNU Linux 3 1r0 mit Kernel 2 6 8 auch als Debian Sarge bekannt genutzt Der Rechner selbst
279. e der Spezifikation in KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 305 ein einzelnes Statechart bernommen Jetzt m ssen von jedem Zustand des Route Dis patchers Ubergiinge zum ersten Route Controller eingefiigt werden die der Transition auf der urspr nglich obersten Ebene entsprechen Analog m ssen berg nge von je dem Route Controller n zum Route Controller n 1 eingef gt werden Ebenso m ssen berg nge vom letzten Route Controller zum Safety Monitor eingef gt werden Da innerhalb der Hierarchie der urspr nglichen Spezifikation auch History Einnahme ei nes zuletzt aktuellen Zustandes innerhalb einer Hierarchiestufe benutzt wird muss auch hier eine Transformation vorgenommen werden Es muss hierzu bei jedem Zustands wechsel zwischen urspr nglich hierarchischen Komponenten in der flachen Entsprechung berg nge zu jedem Zustand der Zielkompontente geben wobei diese berg nge durch ein Zustandsfeld pro Komponente unterschieden werden m ssen Dieses Zustandsfeld muss bei jedem bergang innerhalb einer Komponente aktualisiert werden Zusammengefasst ergibt dies folgendes Vorgehen e Zust nde aller Safety Controller Komponenten in ein einzelnes Statechart ber nehmen e Bei jedem bergang innerhalb einer Komponente ein entsprechendes Zustandsfeld verwalten e Von jedem Zustand einer Komponente berg nge zu jedem Zustand der Folge komponente anlegen e Solche berg nge mit Bedingungen und Aktionen aus urspr nglich ob
280. e ggf Sch den verursachen e stellbare Hardware Elemente aktualisieren e Stra enbahnen aktualisieren e Ver nderungen der Hardware Elemente senden e Output besch digter Sensoren generieren e Neue Bahnen starten e Zeitstempel holen und warten KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 339 Simulator run exists a new request yes get it and notify hardware no random damages allowed yes randomly damage HW elements no exists HW not updated in this round report changes yes lt gt update it has it changed no exists tram not updated tn this round possibly has it moved damage it over sensor and or switched move it turnout create output of damaged sensors and report too few trams gt create one no update time Abbildung 7 64 Aktivit tsdiagramm Simulator run KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 340 Der Simulator bildet das Bindeglied zwischen der Schnittstelle zu den Hardware Treibern und den einzelnen Hardware Elementen in der Simulation Es soll keine direkte Kom munikation zwischen der Treiber Schnittstelle und z B einer Weiche erfolgen damit der Ablauf bersichtlich nachvollziehbar und leichter berpr fbar ist 1 Anforderungen holen Zu Beginn einer Runde pr ft der Simulator ob neue Anforderungen des Steuerin terpreters an die Hardware gesendet wurden Falls Ja so werden die Anforderungen einzeln vom Empfangsserver abgeholt und ausgef hrt
281. e in einem DXF Gleisnetz vorkommen den Elemente erkannt und in entsprechenden Java Objekten abgespeichert Dabei werden die Koordinaten und die Art sowie der Name des Elements z B ei ne Links Rechts Weiche mit dem Namen w359 und evtl vorhandene Eigenschaften ausgelesen Dazu kommen die ben tigten Informationen zu Nachbarschaftsbeziehungen welche aus Ber hrungspunkten bzw Verbindungslinien Gleisgeraden abgeleitet wer den Dieser zuletzt genannte Teil hatte zwischenzeitlich einige Fehler verursacht welche nur mit m hsamer Arbeit langsam ausgefiltert werden konnten Ein weiteres Problem ergab die Tatsache dass Objekte in einer Zeichnung auch zu ihrer relativen Ausrichtung rotiert dargestellt werden k nnen Durch diese Rotation ver nderten sich logischerweise auch die absoluten Koordinaten der Ber hrungspunkte mit anderen Elementen Dieser Umstand wurde aufgrund der anf nglichen Planung oh ne derartige Ber hrungspunkte es sollten urspr nglich die einzelnen Gleisnetzelemente KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 95 NGDataCollector ENTITIES_FILE_NAME final static String entities tmp tng BLOCKS_FILE_NAME final static String blocks tmp tng lines static NGLines block static NGElement entity static NGElement element static NGElement blockList static NGElementList entityList static NGElementList elementList static NGElementList signalClass static NGElementList sensorClass static NGElemen
282. e sich gleichzeitig ohne zu kollidieren auf diesem St ck befinden k nnen 2 3 2 1 1 Verkn pfungen von Gleisst cken Eine Gerade oder eine Kurve hat zwei Enden Eine Weiche hat auf der einen Seite ein Ende auf der anderen Seite zwei oder drei Enden Eine Kreuzung hat vier Enden wobei jeweils zwei Enden einander zugeh rig sind An einem Ende eines Gleisst cks kann ein weiteres Gleisst ck angeschlossen sein so dass eine Bahn hier vom einen auf das andere Gleisst ck fahren kann Ist an einem Ende kein Gleisst ck angeschlossen endet hier das Gleisnetz An solchen Stellen k nnen Bahnen in das Netz gelangen oder aus ihm entfernt werden Eine weitere M glichkeit ist dass an solchen Stellen das Gleisnetz mit einem Prellbock abgeschlossen wird so dass kein Einfahren oder Verlassen m glich ist F r alle Gleiselemente gilt dass es zu Kollisionen zwischen Bahnen kommen kann wenn sich a mehrere Bahnen gleichzeitig auf dem Element befinden und es von unterschied lichen Enden her befahren oder b wenn von zwei hintereinander fahrenden Bahnen die zweite schneller f hrt Eine Bahn kann sich gleichzeitig auf mehreren Gleiselementen befinden Sie erstreckt sich dann gerade ber einen oder mehrere Verkn pfungspunkte zwischen Gleiselementen 2 3 2 1 2 Eigenschaften der verschiedenen Gleisformen e Gerade Eine Gerade ist ein kreuzungsfreies Gleisst ck mit zwei Enden Eine auf einer Geraden fahrenden Bahn kann nicht mit einer Bahn die sich auf eine
283. e sich im Gleisnetz befinden die Eigenschaften der Hardwareelemente sowie geographische Beziehungen zwischen den Hardwareelementen e Der zweite Teil beinhaltet die Routendefinition f r das Gleisnetz sowie die Infor mationen ber Konflikte zwischen Routen hnlich arbeitet auch der TND Builder in zwei Phasen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 124 e In der ersten Phase wird der CAD TND Konverter aufgerufen um den ersten Teil der TND zu generieren Dabei werden definitions Block coordinates Block signal properties Block point properties Block relations Block signal positions Block und hardwaremap Block generiert Sonstige Bl cke in der TND sind leer nur Blockname ohne Inhalt e In der zweiten Phase k nnen Routendefinitionen erstellt oder bearbeitet werden und Routenkonflikte identifiziert werden In dieser Phase werden routedefinitions Block conditions Block clearances Block conflicts Block und point conflicts Block generiert 7 3 2 3 Erzeugen einer neuen TND aus einer CAD Datei Die Abbildung 7 20 zeigt in einem Screenshot das Erzeugen einer TND Datei aus ei ner CAD Datei Bevor die Konvertierung stattfindet muss man eine vorhandene DXF Datei selektieren und ein TND Datei als Ziel angeben sowie eine Konfigdatei f r den DXF2TND Konverter DXF config file optional Speeity TND target file mom Ja Abbildung 7 20 Erzeugen einer neuen TND 7 3 2 4 Laden einer vorhandenen TND Die Ab
284. e und Weichen befinden Das Modell des Controllers liefert die eigentlichen Steuerungsinformationen Abh ngig von den Informationen aus dem physikalischen Modell werden bestimmte Signal und Weichenzust nde angefordert Durch diese Anforderungen muss vermieden werden dass ein Zustand erreicht werden kann in dem eine Sicherheitsbedingung nicht erf llt ist incoming trams sensor states Domain of Control Physical Model Controller Control Model signal states point states route requests YYYY Railway network Trams Safety Conditions signal ctrl cmds point ctrl cmds lt outgoing trams Abbildung 7 44 Systemmodell PGHD04 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 206 F r den Safety Monitor wird eine Menge von Zust nden generiert in denen sich das System befinden muss damit keine Hazards auftreten Ob diese Zust nde gelten wird ebenfalls berpr ft Im Gegensatz zu den oberen Sicherheitsbedingungen werden diese Zust nde anhand der in den Verschlusstabellen gemachten Angaben erzeugt und sind daher von der Richtigkeit dieser Angaben abh ngig 7 6 2 3 Entwurfsprozess Das Modell muss in der Eingabesprache des verwendeten Model Checkers NuSMV er stellt werden Die Abbildung 7 45 zeigt wie die Eingabedatei f r den Model Checker automatisch erzeugt werden kann Die Informationen welche zum Erstellen des physikalischen Modells ben tigt werden erh lt man a
285. e unterschiedliche Aspekte beeinflusst wer den die nicht direkt mit der Bahntechnik zusammenh ngen sondern aus der Umwelt kommen Als erstes kommt eine Auflistung dieser Aspekte die dabei bereits in Ka tegorien zusammengefasst sind um einen schnelleren berblick zu liefern und um die Zusammengeh rigkeiten der einzelnen Punkte zu verdeutlichen 10 KAPITEL 2 DIE DOMANE 11 2 2 1 Auflistung Physikalische Wirkungen e die Bahn direkt betreffend Tragheitskrafte x Fliehkrafte Beschleunigung Verz gerung x Gravitation Elektromagnetische Wirkungen x Felder um Stromleitungen Handys Elektronische Ger te Elektrosmog Funkverkehr Korrosion Verschlei Motor x Karosserie Steuerkomponenten Elektrik Batterien e das Gleisnetz betreffend Korrosion Verschlei x Gleise verrostet verschmutzt spr de Sensoren Kabelbr che etc x Weichen eingerostet Kabelbr che etc Signale Gl hbirnen Kabelbr che etc Stromleitungen Elektromagnetische Wirkungen x Falsch beeinflusste Sensoren Hitzewirkungen Umfeld e Stromausf lle e Andere Verkehrsteilnehmer e Tiere Hindernisse auf Gleisen KAPITEL 2 DIE DOMANE e Geographie Hiigel Tunnel Bodenbeschaffenheit e Gesperrte Teilgleisnetze Verhalten e Fahrer Fahrweise Sicht Reaktionszeiten Miidigkeit Entnervtheit e Notbremsungen Passagiere und Fahrer e Sehr sp ter Haltewunsch e Vanda
286. e_A route26 route_B route26 1 120 esac s3013_straight case route_A route23 route_B route23 1 1 0 esac s3013_right case route_A route24 route_B route24 1 1203 esac s3015_straight case route_A route27 route_B route27 1 1 303 esac s3015_right case route_A route28 route_B route28 1 1 0 esac KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 247 7 6 6 4 Sensorverhalten Schlie lich folgt noch die Modellierung das Sensorverhaltens 7 6 6 4 1 Allgemeines Sensorverhalten In dem Modul sensor wird das Verhal ten beschrieben das f r alle Sensoren gleich ist Als Parameter wird eine Bedingungen bergeben die angibt wann der Sensor erreicht werden kann Die Variable reached gibt an ob ein Sensor bereits erreicht wurde Wurde der Sensor noch nicht erreicht und ist die als Parameter bergebene Bedingung cond erf llt wird er im n chsten Schritt erreicht Im Gegensatz zur Pr fung des Systemmodells sind hier keine Sensorz hler notwendig da es zur Pr fung der Verschlusstabellen ausreicht wenn sich eine Bahn auf einer Route befindet MODULE sensor cond VAR reached boolean ASSIGN init reached 0 next reached case cond 1 1 reached esac 7 6 6 4 2 Initialisierung der Variablen F r alle in einem Gleisnetz enthaltenen Sensoren werden Variablen erstellt Dazu wird jeweils das Modul sensor aufgerufen und als Parameter die Bedingung iibergebe
287. eder aktuellen Linux Distribution enthalten sein Empfohlen wird von uns Debian GNU Linux 3 1 7 2 4 3 1 Einbinden der Objekt Bibliothek Um entsprechende Gleisnetze zeich nen zu k nnen muss zu allererst die von TRACS gelieferte Objekt Bibliothek in QCad eingebunden werden Dazu muss der Pfad zu dieser Bibliothek in QCad gespeichert wer den Dies ist ber das Programm Men Bearbeiten und dem Men punkt Applikations Einstellungen und dann auf der Seite Pfade zu erldigen Hier befindet sich der Eintrag Teile Bibliotheken wo der entsprechende absolute Pfad zu setzen ist siehe auch Ab KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 107 bildung 7 15 w iS Applikations Einstellungen 2 laj x Erscheinung e Standards bersetzungen fusrshare geadiqm schrafur Muster usr share gcad patterns schriften usr share qeadtonts Scripts usr shareigead scripts Teile Bibliotheken usr sharergead libraries eu Abbrechen Ob Abbildung 7 15 Eingabe des Bibliothekspfades Sollte es vorkommen dass diese Einstellung nicht gespeichert wird so ist zu empfehlen den dort vorgegebenen Pfad zu verwenden und die Objekt Bibliothek unterhalb dieses Pfades abzuspeichern Auf diese Weise sollte auf jeden Fall die Verf gbarkeit sicherge stellt sein Desweiteren sollte ber den Men punkt Ansichten des Men s Ansicht der Biblio theks Browser Abbildung 7 18 auf Seite 109 aktivier
288. ediglich besagte Ausf lle und Fehl verhalten simuliert ohne auf n here Ursachen einzugehen e Analog gilt dies auch f r Ausf lle von Bahnen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 324 Entgleisungen von Bahnen kann der SI nicht verhindern daher werden sie und die sie ausl senden Gegebenheiten auch nicht simuliert Ausnahmen hiervon sind das Umschalten einer Weiche w hrend eine Bahn anwesend ist oder das Auffahren auf eine nicht auffahrbare Weiche diese werden in der Simulation ber cksichtigt Arne Stahlbock 7 8 4 Konzept des Simulators Das Konzept beschreibt eine abstrakte Struktur des Simulators die die Anforderungen auf Basis des Weltmodells umsetzt und realisiert Es dient anschlieBend als Grundlage fiir die Implementierung Das Konzept ist zusammengesetzt aus folgenden Teilen Programmiersprache Wir benutzen im Wesentlichen die Programmiersprache Java in diesem Unterkapitel wird aufgezeigt warum wir uns fiir diese Sprache entschieden haben TM Programmstruktur Die Programmstruktur erl utert die Klassenstruktur des Programms und gibt einen berblick ber die Bedeutung der einzelnen Klassen Flexibilit t In diesem Unterkapitel wird beschrieben wie der Simulator Gleisnetze in TND Form einliest und damit flexibel jedes beliebige Gleisnetz verarbeiten kann Simulation Dieses Unterkapitel umfasst den Kern des Simulators die Abl ufe und die Me thoden zur Berechnung des Simulationszustands werde
289. efah rungs und Anforderungskonstellation des zu steuernden Gleisnetzes und einer entspre chenden Konflikttabelle welche Routen freigeschalter werden d rfen und welche Routen momentan nicht befahren werden d rfen Die dazu notwendige Konflikttabelle welche beschreibt welche Routen nicht gleichzeitig befahren werden d rfen erh lt der TRACS Steuerinterpreter aus den Projektierungsdaten Zus tzlich ben tigt man noch noch den Block Route Definitions aus der TND Beschreibung um die jeweiligen Route Request Sensoren zu bestimmen Eventuell notwendige Warteschlangen f r mehrere Routenan forderungen an einem Sensor werden ebenso aus den Projektierungsdaten ausgelesen Diese Daten werden aus den oben beschriebenen Konfliktinformationen der vom tram Compiler eingelesenen TND generiert KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 139 7 4 2 2 2 Projektierung der Route Controller Pro Route existiert in einem lau fenden TRACS Steuerinterpreter je ein Route Controller Diese ben tigen zum Steuern ihrer zugeordneten Route alle erforderlichen Steuerimpulse zum Freigeben Einstellen und Sperren dieser Route Hierzu werden bin re Listen von Steuerimpulsen f r ent sprechende Gleisnetzelemente generiert die jeweils eine Route Freigeben ihre Weichen setzen oder die Route wieder sperren Diese Steuerimpulse werden pro Route vom tram Compiler generiert und in einem effizient auszuwertendem Format dem Steuerinterpreter zur Verf gung gestellt Als Basis dies
290. efehl zu starten e java jar tndbuilder jar KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 130 Fiir diejenigen die das Programm selber kompilieren wollen haben wir ein Makefile fiir diesen Zweck erstellt Man braucht dazu das Makefile einmal mit fogendem Befehl aufzurufen wodurch eine endgiiltige JAR Datei erstellt wird e make release Deng Zhou 7 3 4 Implementierung 7 3 4 1 Programmierssprache Als Programmierssprache fiir den TND Builder verwenden wir Java Weil der TND Builder ein User Interface Programm ist um Routen in einem Gleisnetz zu definieren sollte er nicht mit einem speziellen System oder Betriebssystem verbunden sein sondern in m glichst verschiedenen Systemen einsetzbar sein An dieser Stelle ist Java die beste Wahl fiir uns 7 3 4 2 Programmstruktur Die Programmstruktur gibt einen berblick ber die Komponenten aus denen der TND Builder besteht Dies sind insgesamt 4 Komponenten e DXF2TND Konverter externer CAD TND Konverter e IND Parser e Objekt Darstellung e GUI 7 3 4 2 1 DXF2TND Konverter Die Komponente DXF2TND Konverter wird von der Netzgraph Gruppe bernommen Das Programm wird hier einfach aufgerufen um aus der eingegebenen DXF Datei eine TND Datei zu erzeugen Eine ausf hrliche Erkl rung dazu ist im Abschnitt 7 2 auf Seite 82 zu finden 7 3 4 2 2 TND Parser Die Komponente TND Parser wird von der Simulator Gruppe bernommen Diese hat bereits eine Komponente Best TramNetwork
291. eibt 7 8 5 1 1 Beispiel Unserer Beispieldatei im TND Format liegt folgende Grammatik zugrunde die in EBNF Form aufgeschrieben ist 01 lt TND gt lt DEFBLOCK gt lt COORDSBLOCK gt 02 03 lt DEFBLOCK gt definitions lt TYPEDEF gt 04 lt TYPEDEF gt lt SENSDEF gt 05 lt SENSDEF gt lt SENSTYPE gt lt SENSID gt lt SENSID gt 06 lt SENSTYPE gt tg sensors 07 08 lt COORDBLOCK gt coordinates lt COORDDEF gt 09 lt COORDDEF gt lt ELEMENTID gt lt COORD gt lt COORD gt g lt COORD gt g 10 lt ELEMENTID gt lt SENSID gt 11 lt COORD gt lt DIGIT gt lt DIGIT gt Anmerkung Die Zeilen 1 4 6 und 10 sind teilweise sehr stark vereinfacht worden wodurch die meisten Zeilen der gesamten Grammatik entfallen Eine gesamte TND Datei kann aus sehr vielen Bl cken bestehen doch unser Beispiel besch ftigt sich nur mit dem DEFBLOCK und dem COORDBLOCK Diese Kombination wurde ausgew hlt da der letztere Block Bezug zu den Informationen aus dem ersten Block nimmt Nun folgt unsere Beispieldatei die lediglich aus den gerade beschriebenen zwei Bl cken besteht Im ersten wird ein Toggle Sensor mit der ID g003 definiert und im zweiten werden diesem Sensor Ortskoordinaten zugewiesen n mlich 1 1 0 01 definitions 02 tg sensors g003 03 04 05 coordinates 06 g003 1 1 0 07 7 8 5 1 2 Lexer Im
292. einen eventuellen Ausgang in dem Gleisnetz und erstellt hieraus einen neuen einzelnen Relations Eintrag Bei dieser Reduktion sind die ersten Nichtterminale wie sensidside crossidside und pointidside die jeweiligen Bezeichner der Elemente und seien hier am Beispiel f r die crossidside gezeigt KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 158 crossid_side CROSSID cross_side makeElementidSide 2 cross_side SIDEA SIDEB CROSS_SIDE_C CROSS_SIDE_D Durch den Aufruf der Funktion struct elementid_side_t makeElementidSide char elem int side wird ein neuer Elementid Side Eintrag erstellt F r die anderen Side Eintr ge funktio niert dies hnlich Das Nichtterminal elementidside besteht nur aus den anderen Nicht terminalen elementid_side sensid_side crossid_side pointid_side Das Nichtterminal marklistoptkomma dient nur dazu das Terminal marklistkomma op tional zu machen Die marklistkomma kann aus einem oder mehreren Bezeichnern fiir die Markierungs Ids bestehen marklistkomma MARKID makeList MARKID marklistkomma makeList Die Funktion struct idlist_t makeList char name struct idlist_t oldlist int type erh lt als Eingabe den Namen des Elements die vorhandene Idlist und den Typs des Eintrags Wenn m glich sucht sie den entsprechenden Eintrag aus der Symboltabelle heraus Ist dieser nicht vorhanden wird er in die Symboltabelle eingetragen Anschlie Bend wird
293. eingebaut wurden die zur Beobachtung von Variablen oder des Kontroll flusses dienten Im Wesentliche wurde dies an den mit der Fortbewegung der Bahnen zusammenh ngenden Methoden betrieben Positionsberechnung Signalvorausschau Eine andere Vorgehensweise konnte einfach bei den Zeichenmethoden der GUI beschrit ten werden hier wurden einfach die Zeichenmethoden alle bis auf eine f r eine bestimm te HW Klasse auskommentiert so dass nur Elemente einer Klasse gezeichnet wurden und so die jeweilige Zeichenmethode gepr ft werden konnte 7 8 6 2 Modultests Diese Ebene von Tests ist innerhalb der Testreihen als die gr te zu bezeichnen Hier wurden verschiedene Module bestehend aus mehreren Funktionen im Zusammenspiel auf ihre gew nschte Funktionalit t getestet Dies sind e GUI Visualisierung der Elemente Werden alle HW Elemente richtig in Bezug auf Ort und Zustand dargestellt KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 409 e GUI Visualisierung der Bahn Als komplexester Unterpunkt der Visualisierung wurde die Bahn gesondert unter sucht e GUI Meniifunktionen Bewirken die Meniibefehle das was sie sollen e Parser Einlesen Mit verschiedenen TNDs wurde getestet ob der Einlesevorgang inkl des Aufbau ens der Objektstruktur richtig funktioniert Die Priifung dafiir wurde mit Hilfe der GUI vorgenommen richtige Darstellung l sst auf richtiges Einlesen schlie en e Parser Inkorrekte TND TND Dateien die nicht der Sprachde
294. eisnetzelementen und deren Benennung ein einfaches Textfeld zust ndig sind m ssen erstere noch her ausgefiltert werden damit die eigentliche Weiterverarbeitung der Informationen aus ei ner DXF Datei fortgesetzt werden kann Hierf r ist die Methode generateElementList zust ndig Weitere Methoden sind f r die Neuberechnung von absoluten Koordinaten zust ndig Dies ist zum Beispiel bei Elementen notwendig die zu ihrer Normalausrichtung gedreht sind da intern jedes Element als solches nur relative Koordinaten liefert Manche Element Typen besitzen au erdem bestimmte Eigenschaften Properties wel che erkannt werden m ssen Hierbei handelt es sich um Weichen und Signal Elemente Auch hierf r gibt es eine eigene Methode searchFor AdditionalProperties Zur Erkennung von Nachbarschaftsbeziehungen zwischen einzelnen Elementen ist es not wendig die Seiten oder Ein und Austrittspunkte der Elemente zu erkennen da diese in der TND Datei von enormer Bedeutung sind Dies wird mit der Methode sideRecogni tion erledigt Die Nachbarschaftsbeziehungen selbst werden letzlich in zwei Schritten gesucht e direkte Nachbarschaften zwei Elemente treffen sich in ihren definierten Ein Austrittspunkten e indirekte Nachbarschaften zwei Elemente sind ber Linien einfache Schienen st cke miteinander verbunden Die Methode findNeighbours vereint diese beiden Schritte in einem Aufruf Zu dieser Klasse ist noch zu sagen dass Slipswi
295. eisnetzes vereinfacht aber die Weiterverarbeitung einer solchen Gleisnetzbeschreibung da ein daf r zu nutzender Compiler einfacher wird 9 1 2 Wiederverwendbare Architektur des Steuerungssystems Der TRACS Steuerinterpreter bildet die wiederverwendbare Steuerungkomponente eines TRACS Gleisnetzsteuerungssystems Sein Aufbau entspricht der in HP02 S 4 vorge schlagenen Architektur Die in HP02 S 4 vorgegebene Aufteilung in Route Dispatcher Route Controller Safety Monitor und Hardware Abstraction Layer wurde umgesetzt Dadurch kann pro Route ein einzelner Route Controller seine eigene Route freischalten berwachen und wieder sperren Anforderungen f r Routen werden vom Route Dispatcher entgegengenommen und je nach Befahrungskonstellation des Gleisnetzes an den entsprechenden Route Con troller weitergegeben Alle Steuerimpulse werden dann innerhalb des Safety Monitor auf Sicherheit berpr ft bevor sie an den Hardware Abstraction Layer weitergegeben werden welcher aus Steuerimpulsen konkrete Treiberaufrufe herleitet Die in HPO3b vorgeschlagene Semantik eines solchen Gleisnetzsteuerungssystems wur de innerhalb des TRACS Steuerinterpreters umgesetzt Aufgrund der Struktur von Pro jektierungsdaten f r den TRACS Steuerinterpreter enth lt der Safety Monitor allerdings innerhalb seiner Statechart Spezifikation nur eine Transition in den Sicheren Zustand da entgegen der Vorgaben aus HP03b Sicherheitsbedingungen nicht getrennt vorlieg
296. eiter von H amp K pr sen tierte uns das Unternehmen H amp K H amp K wurde im Jahr 1898 in Oerlinghausen gegr ndet und seit dieser Zeit besch ftigt sich das Unternehmen mit Stellvorrichtungen und Steuerungen im Nahverkehrsbereich Das Unternehmen ist in drei Gesch ftsbereiche gegliedert Bremsen Dienstleistungen und Nahverkehr Der Prim reinsatz liegt im Ausland Im Jahr 2004 hatte das Unternehmen 300 Mitarbeiter und erreichte einen Umsatz von 40 Mio Euro Folien dazu befinden sich im Schrank des Projektraums unseres Projektes 2 4 3 2 3 Vortrag von TRACS Verschiedene Projektteilnehmer haben einen Vor trag ber unser Projekt gehalten wobei die Projektaufgaben und der aktuelle Stand dargelegt wurden KAPITEL 2 DIE DOMANE 34 Folien dazu befinden sich auf der TRACS Webseite Ein Protokoll welches das gesamte Treffen detailliert beschreibt befindet sich im Ver zeichnis docs protocol sowie auf der TRACS Webseite 2 4 3 3 Reflexion Wir k nnen das Treffen auf jeden Fall als f r uns gelungen beurteilen Schade war nur dass die Kontaktaufnahme zu so einem sp ten Zeitpunkt kurz vor dem Projektende stattfand Aus Zeitgr nden konnten die verbleibenden Fragen nicht mehr diskutiert wer den Diese wurden per Mail an H amp K stellvertretend Herr Mesterheide zugeschickt H amp K hat sich dazu bereit erkl rt unser Weltmodell durchzulesen und uns entsprechen de Kommentare zuzuschicken W hrend des inoffizielle Teils des T
297. eitet 2 4 1 1 Signale so geschaltet dass Bahnen auf nicht auffahrbare Weichen zufahren 2 4 1 1 1 St rung eines Signals oder des zu ihm f hrenden Ubertragungsweges 2 4 1 1 1 1 Nichtbefolgen von Schaltanweisungen 2 4 1 1 1 1 1 Schaltanweisung wird ignoriert 2 4 1 1 1 1 2 Schaltanweisung gelangt nicht zu Signal 2 4 1 1 1 1 2 1 wegen Defekt am Steuersystem XXX 2 4 1 1 1 1 2 2 wegen Defekt auf Ubertragungsweg 2 4 1 1 1 2 Eigenm chtige Schaltungen des Signals 2 4 1 1 2 Fehlverhalten des Steuersystems 2 4 1 1 2 1 Fehler in Projektierungsdaten 2 4 1 1 2 1 1 Benutzer gibt falsche Daten ein XXX 2 4 1 1 2 1 2 Netzgraph liefert TND die nicht der Zeichnung entspricht XXX 2 4 1 1 2 1 3 Compiler liefert Bin rdaten die nicht der Eingabe TND entsprechen XXX 2 4 1 1 2 2 Steuersystem gibt eine nicht den Projektierungsdaten entsprechende Anweisung oder unterl sst eine in den Projektierungsdaten geforderte Anweisung 4 1 1 2 2 1 Hardware Fehler am Steuersystem XXX 4 1 1 2 2 2 Treiber Fehler XXX s4 1 1 22 4 1 1 2 1 1 2 3 SI Fehler XXX 2 4 Fehler in Betriebssystem o Systemumgebung XXX 2 4 1 1 2 3 wegen falscher Sensordaten 2 4 1 1 2 3 1 Sensor reagiert nicht auf Bahn 2 4 1 1 2 3 2 Sensor reagiert falsch auf Bahn 2 4 1 1 2 4 falsche Reaktion auf erkannten Sensor Signalausfall oder defekt 2 4 1 1 2 4 1 Sensor Signalausfall oder defekt 1 1 Sensor Signalausfall oder defekt 1 2 Steuersystem
298. el route4 route2 route2 routel route3 route3 route2 route4 route route4 route3 routel routed routed route4 route6 route3 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN TT Dieses sind die weichen Konflikte der einzelnen Routen des oben genannten Beispieles in Abbildung 7 1 auf Seite 63 Beispielsweise hat die Route route2 drei weiche Konflikte Sie kreuzt sich wie auf der Abbildung zu erkennen ist mit der Route route3 und mit der Route route6 und anschlie end trifft sie auf einer Weiche mit der Route route4 zusammen Nur anhand dieses Blockes kann man also nicht erkennen ob es sich um eine Kreuzung oder ein Zusammentreffen handelt 7 1 3 2 14 HWBlock lt HWBLOCK gt lt HARDWAREMAP gt lt HWDEFS gt lt HWDEFS gt lt HWID gt lt HWELID gt lt HWELID lt HWELID gt lt SENSID gt lt POINTID gt lt SIGID gt lt CROSSID gt Der HWBlock ordnet jeder im DefBlock deklarierten Hardwareklasse die ihr zugeh ri gen Elemente zu Das den Block einleitende Schliisselwort lautet hardwaremap danach folgt in geschweiften Klammern eine beliebige Zahl von Zuordnungen Jede einzelne Zu ordnung beginnt mit dem Namen der Hardwareklasse gefolgt von einem Doppelpunkt danach durch Kommata getrennt die einzelnen zugeh rigen Elemente mind 1 Jede Zuordnung wird mit Semikolon abgeschlossen Zu beachten ist weiterhin dass nur Sensoren Weichen Signale und einer Kreuzungs weiche ange
299. elche prim r f r den von TRACS entwickelten Gleisnetzsimulator relevant sind 437 KAPITEL 9 BEWERTUNG 438 9 1 1 0 5 Route Definition Table In HP02 S 3 wird eine Route Definition Ta ble vorgeschlagen eine Tabelle die pro Route vorgibt welche Sensoren jede definierte Route tiberfahren muss Durch diese Informationen ist der Verlauf jeder Route durch ein Gleisnetz fiir ein Steuerungssystem eindeutig definiert Diese Tabelle findet in der Tram Network Description eine Entsprechung Der Route Definitions Block der Tram Network Description bildet die selben Informationen in textueller Form ab Dort werden pro Route Listen von Sensoren angegeben Jede Zeile dieses Blockes bildet somit eine Zeile der in HPO2 S 3 vorgegebenen Route Definition Table 9 1 1 0 6 Route Conflict Table Die in HP02 S 4 vorgegebene Route Conflict Table beschreibt tabellarisch welche Routen innerhalb eines Gleisnetzes niemals gleich zeitig befahren werden d rfen Werden solche konfliktierenden Routen gleichzeitig befah ren so kann es zu Kollisionen durch gemeinsam genutzte Gleisabschnitte sowie zu Ent gleisungen durch verschieden zu schaltende Weichen kommen Informationen dar ber welche Routen miteinander in Konflikt stehen werden in der Tram Network Descripti on durch die Bl cke Conflicts und Point Conflicts spezifiziert Auch hier wird pro Route eine Liste angegeben welche die mit dieser Route in Konflikt stehenden Routen angibt Zusammen enthalten
300. elemente gt signale united_conditions ist eine Struktur die f r jedes HW Element die zugeh rige SHM Belegung aufnehmen soll united_cond_counter nimmt Z hlerst nde f r Sensoren auf und hw_to_test soll eine Kopie von united_conditions werden die noch um die zus tz liche Information erg nzt ist wieviele Bits jeweils im Input und Output Bereich gesetzt sind xxx_size KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 294 struct hw_to_test int id int input_size int output_size int input int output int input_mask int output_mask Es werden dann united_conditions und united_cond_counter mit Werten die dem ersten sicheren Zustand aus den Projektierungsdaten entnommen werden belegt Da es prinzipiell vorkommen kann dass innerhalb eines solchen Zustandes mehrere Bedinun gen an ein und dasselbe Element gestellt werden z B kann Bedingung a ein bestimmtes gesetztes Bit bei Element X fordern Bedingung b ein anderes ebenfalls bei X werden diese Bedingungen vereinigt was mit simpler Oder Verkniipfung der Bitfelder erledigt werden kann Somit hat man am Ende nur eine Bedingung tiber jedes Element beziiglich der SHM Belegung Bei den Sensorz hlern ergibt sich eine solche Vereinigung nicht da zu jedem Sensor innerhalb eines sicheren Zustandes nur eine Z hlerstandsbedingung vorkommt die Struktur der Projektierungsdaten erlaubt zwar mehr in der Praxis gibt es aber nur wenige vorkommende F lle Sensoren die nicht Eingangs
301. elgleisnetz gibt es drei Route Request Sensoren An dem Route Request Sensor 0 k nnen z B die Routen rO und r1 angefordert werden VAR rr_O_next_tram no r0 ri rr_i1_next_tram no r2 r3 rr_2_next_tram no r4 r5 ASSIGN init rr_O_next_tram no init rr_1_next_tram no init rr_2_next_tram no next rr_O_next_tram case g4125 ctr gt 3 no rr_O_next_tram no no r0 ri g4125 state LOW amp g4125_cond_1 no r0 ri 1 rr_O_next_tram esac next rr_1_next_tram case g4129 ctr gt 3 no rr_i_next_tram no no r2 r3 g4129 state LOW amp g4129_cond_1 no r2 r3 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 228 1 rr_i_next_tram esac next rr_2_next_tram case g4127 ctr gt 3 no rr_2_next_tram no no r4 r5 g4127 state LOW amp g4127_cond_1 no r4 r5 1 rr_2_next_tram esac 7 6 4 7 Sicherheitsbedingungen Die Sicherheitsbedingungen werden als Invariante spezifiziert Das bedeutet es wird gepr ft ob e 1 im Startzustand alle Sicherheitsbedingungen erf llt sind e 2 im Zustand p 1 alle Sicherheitsbedingungen unter der Annahme erf llt sind dass sie im Zustand p gelten INVARSPEC safe Die Invariante safe beinhaltet alle f r das jeweilige Gleisnetz geltenden Sicherheitsan forderungen Ist die Invariante wahr dann bedeutet es demzufolge dass alle Sicherheits anforderungen erf llt sind Ist die Invariante falsch wir
302. elten Simulation sein KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 355 wird Aus einer Liste kann eine Stellung ausgew hlt werden Die Elemente dieser Liste sind abh ngig von dem Typ der Weiche So ist bei einer LR Weiche nicht die Stellung Straight m glich May fail Durch Aktivieren dieser Checkbox setzt der Nutzer die Option dass eine Wei che w hrend des Betriebes ausfallen kann Sie wird dann keine Schaltbefehle mehr ausf hren Wann der Ausfall eintritt ist unvorhersehbar Random behavior Die Weiche wird sich potentiell eigenm chtig umstellen wenn diese Option aktiviert ist Mittels des Knopfs OK wird der Initialisierungsschritt der Weichen abgeschlos sen und zum n chsten Schritt bergegangen e Sensoren stellen Set Sensors Die M glichkeit Sensoren zu stellen wird im dritten Initialisierungsschritt gege ben F r Sensoren gibt es lediglich die verschiedenen Defekte zur Auswahl May fail So eingestellte Sensoren werden irgendwann keine Meldungen mehr geben Random behavior Diese Option bewirkt dass ein Sensor ggf R ckmeldungen gibt wenn keine Bahn anwesend ist Mittels des Knopfs OK wird der Initialisierungsschritt der Sensoren abgeschlos sen und zum n chsten Schritt bergegangen e Signale stellen Set Signals Im letzten Schritt der Spezifikation des gezielten Testens werden die Signale ge stellt Alle Signale die im zugrunde liegenden Gleisn
303. em keinen Einflu Hier sollte gute Wartung und Instandhaltung f r gen gend Sicherheit sorgen 2 2 2 1 2 das Gleisnetz betreffend Ebenso wie die Bahn ist auch das Gleisnetz physikalischen Wirkungen ausgesetzt Dabei kann es sich direkt um die Gleise wie auch um einzelne der sonstigen Elemente am Gleisnetz handeln Hierbei kann es ebenso wie bei der Bahn zu Korrosion bzw Verschlei kommen Dadurch k nnen die Gleise rosten verschmutzen oder spr de werden was zu einer erh hten Gefahr der Entgleisung f hrt aber auch den oben besprochenen Bremsweg beeinflusst Desweiteren k nnen die Sensoren an der Strecke z B Kabelbr che bekommen die na t rlich die Funktion dieser Sensoren unm glich machen hnlich verh lt es sich bei den anderen Elementen wie Weichen und Signalen Das Auf tauchen eines solchen Schadens kann unser System durch fehlende R ckmeldung dieser Komponente bemerken Desweiteren k nnen noch durch Verschlei Sch den an den Lei tungen entstehen Diese M ngel k nnen durch unser System genauso wie Probleme an den Gleisen nicht abgefangen werden KAPITEL 2 DIE DOMANE 16 Auch Elemente des Gleisnetzes k nnen durch elektromagnetische Wirkungen beeinflusst werden Insbesondere k nnten hierdurch Sensorwerte verf lscht werden Desweiteren gibt es noch Temperatureinwirkungen Hierbei sind Auswirkungen gemeint die durch Hitze und K lte entstehen Also das Ausdehnen und Zusammenziehen von Elementen bei den jeweilig
304. emente die KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 98 linesList ArrayList linesListIndex int 0 addLineToList coords String void getLine index int String getLineCounter int Abbildung 7 10 Detailansicht Klassendiagramm NGLines einfachen Gleisstiicke Entgegen anf nglicher Planungen diese als eigene Elemente in der CAD Objektbiblio thek zu realisieren werden in der Endfassung nun simple Linien variabler L nge als Gleisst ck benutzt Da diese Linien f r die Zusammensetzung eines Gleisnetzes eine relevante Rolle spielen indem sie die Nachbarschaftsbeziehungen einzelner Elemente spezifizieren werden alle Verbindungslinien ebenfalls in einem ArrayList Objekt gespei chert In diesem Zusammenhang ist die Nebenklasse NGLines java entstanden welche neben der ArrayList auch Methoden zur einfacheren Verarbeitung liefert Das detaillierte Klassendiagramm Abb 7 10 zeigt die in dieser Klasse verwendeten Methoden und Attribute Auch hier ist aus einem hnlichen Grund wie bei NGElementList java der Umfang der Attribute und Methoden schnell berschaubar 7 2 3 2 10 TNDCreator java Die dritte Hauptklasse TNDCreator java in dieser Idee ist f r die eigentliche Generierung der TND Beschreibung des Gleisnetzes zust ndig Diese Klasse ruft letztlich die bereits beschriebene Klasse NGDataCollector java auf und liest aus den damit erzeugten Sortier Containern den NGElementList Objekten die einzlenen Objekte vom Ty
305. ementen sich Gleisst cke befinden das steht in diesem Block Auch werden hier Endpunkte des Gleisnetzes definiert SigPositions Block Die Zuordnung eines Signals zu einem Sensor bzw einem Standort zwischen zwei Sensoren erfolgt in diesem Block RouteDefinitions Block In diesem Block steht welche Route ber welche Sensoren f hrt Diese Informa tion wird ben tigt um w hrend der Simulation entscheiden zu k nnen ob eine simulierte Stra enbahn die eine bestimmte Route fahren will vom SI tats chlich ber die verlangte Route geleitet wird Clearances Block Hier sind die f r eine Route n tigen Signalstellungen aufgef hrt Eine simulierte Bahn soll nur fahren wenn ihre gew nschte Richtung freigegeben ist KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 316 Diese Informationen muss der Simulator speichern um w hrend einer Simulation darauf zur ckgreifen zu k nnen Um eine fl ssige und m glichst genaue Simulation gew hrleis ten zu k nnen sollte die Datenstruktur so aufgebaut sein dass ein Auslesen eventuell verbunden mit einem Suchen sehr effizient vorgenommen werden kann 7 8 2 2 Berechnung der Simulation Die Simulation ist die Kernaufgabe des Simulators M glichst realistisch sollen in diesem Simulator die Reaktionsweisen von Sensoren Signalen und Weichen simuliert werden Damit diese Hardwareelemente berhaupt ausl sen brauchen sie Stra enbahnen auf die sie reagieren k nnen diese Stra enbahnen m ssen folgli
306. en Darunter sind zwei die Anzahl und IDs der in den Sicherheitsbedingungen vorkommen den Elemente aufnehmen sollen struct hardware_elemente int weichen int sensoren KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 293 int signale In dieser Struktur wird die Anzahl der einzelnen HW Elemente gespeichert struct hw_elemente_daf int weichen int sensoren int signale Hier werden die HW IDs gruppiert nach Typen Weichen Sensoren Signale gespeichert Zwar wird der Inhalt der zweiten Struktur als solcher nicht mehr ben tigt zum Zeit punkt der Erstellung war man aber noch davon ausgegangen und da es nicht sch dlich erscheint hat man sie beibehalten falls sie doch noch einmal verwendet werden k nnen Diese Strukturen werden dann unter Einsatz einer Hilfsfunktion gef llt die alle siche ren Zust nde durchl uft und die hier vorkommenden HW IDs aufnimmt sofern sie zum ersten Mal auftreten Anschlie end beginnt der eigentliche Generationsprozess Daf r werden zun chst folgen de Datenstrukturen angelegt united_conditions struct test_shm_value_t malloc sizeof struct test_shm_value_t hw_elemente gt weichen hw_elemente gt sensoren hw_elemente gt signale united_cond_counter struct shm_state_counter malloc sizeof struct shm_state_counter 1000 hw_to_test struct hw_to_test malloc sizeof struct hw_to_test hw_elemente gt weichen hw_elemente gt sensoren hw_
307. en KAPITEL 9 BEWERTUNG 440 sondern als eine einzelne Invariante aus den Projektierungsdaten ausgelesen werden Wird diese Invariante verletzt veranlasst der Safety Monitor einen Ubergang des Gleis netzes in einen sicheren Zustand Diese Abweichung der Vorgaben aus HPO3b stellt allerdings nur einen formalen nicht aber einen semantischen Unterschied dar Die Steuersemantik des TRACS Steuerinterpreters weicht insofern von den Vorgaben aus HPO3b ab als dass zus tzliche Gleisnetzeigenschaften wie Doppelweichen und R ck fallweichen integriert werden mussten Das in HP03b vorgeschlagene Zustandsbasierte Verhalten wurde beibehalten und an den entsprechenden Stellen erg nzt Die genaue Steuerungssemantik des TRACS Steuerinterpreters ist aus dessen formaler Spezifikati on in 7 5 ersichtlich 9 1 3 Verifikation eines Steuerungssystems Um die Sicherheit von Projektierungsdaten f r einen TRACS Steuerinterpreter gew hr leisten zu k nnen werden diese durch Modellvergleiche gepr ft Hierbei werden gem PGHD04 Modelle f r Gleisnetze Bahnbewegungen und Steuersysteme erzeugt Der Zustandsraum des Gesamtmodells kann dann durch Model Checking auf unsichere Zu st nde berpr ft werden Innerhalb von zu berpr fenden Projektierungsdaten finden sich notwendige Informa tionen um ein Modell des von diesen Projektierungsdaten zu steuernden Gleisnetzes zu erstellen Zusammen mit der Spezifikation des TRACS Steuerinterpreters siehe 7 5
308. en timeouts true wenn sich f r mindestens ein Hardwareelement Sollzust nde und Ist zust nde unterscheiden und der zugeh rige Timer nicht l uft sonst false grundstellAnforderung pr ft ob eine Anforderung gekommen ist um das System in den Ausgangszustand zu setzen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 189 leiteWeiter leitet die Sollzustandsanforderungen vom RC RD weiter Unterschei det sich der angeforderte Sollzustand vom RC RD mit dem schon bekannten Sollzu stand wird der Timer f r das jeweilige Element mit neugestartet l uft nach der maxi malen Schaltzeit ab sperreGleisnetz setzt alle Signale auf Wait Die in den Projektierungsdaten aufgelisteten sicheren Zust nde sollen folgende Bedin gungen gew hrleisten 1 Keine zwei Bahnen fahren in entgegengesetzte Richtungen auf demselben Gleis st ck 2 Keine zwei Bahnen fahren gleichzeitig auf denselben Sensor von verschiedenen Richtungen zu 3 Auf jedem Gleisst ck sind nicht mehr als eine vorgegebene Anzahl von Z gen gleichzeitig 4 Bei jeder Weiche darf die Anzahl der Z ge die gleichzeitig auf den Abzweigungen fahren ein Maximum nicht berschreiten 5 Keine zwei Z ge befinden sich gleichzeitig auf zwei unterschiedlichen Gleisst cken die sich kreuzen 6 Weichen haben ihren Schaltvorgang nach der maximalen Schaltzeit beendet Zu einem sicheren Zustand geh rt auch dass keine Signal Anforderungen vom Route Controller vorliegen d
309. en gr er sein wird Der Nachteil der durch den Zusatzaufwand eines Compilers der in Java geschrieben werden muss entsteht kann durch die schnellere und sichere Pro grammierung in Java Mausgeglichen werden Demnach wird zwar mehr Quellcode pro duziert jedoch wird nicht mehr Zeit ben tigt 7 8 4 2 Programmstruktur Die Programmstruktur gibt einen berblick ber die Klassen die programmiert werden wie diese Klassen voneinander abh ngen und welche Gemeinsamkeiten sie verbinden Der gesamte Simulator gliedert sich in die beiden Pakete e sim KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 329 e gui Das Paket sim enth lt alle Berechnungen und Kommunikations Abl ufe die der Simulator durchf hrt Im Paket gui sind die kompletten Grafikroutinen ausgelagert die zur Visualisierung der Simulation dienen gt Hardware x V V interface V V gt Linkable interface Sourceable Tram NetworkEndException H TrackElement BestTramNetworkBuilderOfTheUNiverse StatusSender DriverRequestServer Sym ee ee Abbildung 7 62 Klassendiagramm Package sim 7 8 4 2 1 Paket sim In Abbildung 7 62 sind alle Klassen enthalten die zur Si mulation eines Gleisnetzes das vom Steuerinterpreter angesteuert wird samt Stra en bahnen n tig sind Wie schon an der graphischen Anordnung zu erkennen ist gliedert sich die Struktur des Pakets sim in drei Bereiche e Gleisnetz Ele
310. en Stop Signale registriert sind wird gepr ft ob an dem n chsten Hardware Element ein Stop Signal steht und ob sich die Tram unmittel bar vor diesem Signal befindet Falls Ja stoppt die Tram Tram calculatePosition calculatePosition errechnet auf Grundlage der alten Position die als Parameter bergeben wird und in die die neue Position ein KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 350 Tram calculatePosition old position one more step reached end of track amp reached end oftrack true get new track direction position else return the passed hardware Abbildung 7 71 Aktivit tsdiagramm Tram calculatePosition getragen wird die n chste Position Diese Position untergliedert sich in Gleisst ck Richtung und Position auf dem Gleis Der Algorithmus l uft wie folgt ab zuerst wird abh ngig von der Richtung auf dem aktuellen Gleisst ck ein Schritt weiter nach vorne ger ckt Falls durch diesen Schritt das Ende des Gleisst cks erreicht wurde muss auf das n chste gewechselt werden in dem das neue Gleisstiick die Richtung auf dem neuen Gleis und die Position auf dem Gleis berechnet wird Zur ckgegeben wird die berfahrene Hardware oder der Wert null Tram drivelnto drivelnto bekommt als Parameter die Position an der gepr ft werden soll ob die Tram auf eine andere Tram auffahren w rde Alle Stra Benbahnen im Gleisnetz werden geholt und einzeln berpr ft Da
311. en Temperaturen Auf diese zuletzt genannten Auswirkungen kann unser System ebenfalls nicht reagieren Diese sollten bereits bei der Erstellung des Gleisnetzes bedacht sein 2 2 2 2 Umfeld Au er den physikalischen Auswirkungen gibt es noch Einfl sse durch das Umfeld der Bahn und ihres Gleisnetzes Hierzu z hlen wir alle Einfl sse die von Au en aus dem Bereich in dem sich die Bahn befindet kommen Als erstes seien hier Stromausf lle aufgef hrt die sowohl einen kleinen Bereich als auch das komplette Netz betreffen k nnten Hierbei sollte unser System immer in der Lage sein dies zu erkennen und das gesamte Gleisnetz in einen sicheren Zustand berf hren Eine weitere Gefahr aus dem Umfeld der Bahn auf die unser System aber nicht rea gieren kann sind andere Verkehrsteilnehmer wie z B Autos Fahrr der und Fu g nger Diese k nnen immer pl tzlich auf die Gleise kommen Auf diese Gefahr muss der Fahrer reagieren Ein hnliches Problemfeld sind Tiere oder andere Hindernisse auf den Gleisen 2 3 Auf eine solche Gefahrensituation muss auch der Fahrer reagieren da unser System ein solches Problem nicht erkennen kann Desweiteren ist zum Umfeld die Geographie des Gleisnetzes zu z hlen Dazu z hlen wir H gel Tunnel und die Bodenbeschaffenheit Diese k nnen zum Einen auf die Sicht des Fahrers Einflu haben sowie auf physikalische Wirkungen wie dem Bremsweg oder die Beschleunigung Auf diese Wirkungen kann unser System keinen Einfl
312. en dort eingetragen Als n chstes soll die Auswertung des Slipswitch Blockes erl utert werden Zum slipswitchblock kann auf folgende Art und Weise reduziert werden slipswitchblock SLIP_SWITCHES slipswitchdeflist Er besteht aus dem zugeh rigen Schl sselwort und einer slipswitchdeflist die dem Schl sselwort in geschweiften Klammern stehend folgt Diese slipswitchdeflist kann aus einer oder mehreren slipswitchdefs bestehen slipswitchdeflist slipswitchdef makeSlipswitchList slipswitchdef slipswitchdeflist makeSlipswitchList Mit dieser Regel wird so eine Listenstruktur erm glicht Durch den Aufruf von struct slipswitch_t makeSlipswitchList struct slipswitch_t newss struct slipswitch_t oldlist wird das neue Element zu der bereits vorhandenen Liste von Slipswitches vorne an geh ngt Dazu mu aber vorher zu slipswitchdef nach folgender Regel reduziert worden sein slipswitchdef CROSSID POINTID POINTID pair2opt SWITCHTIME POSINT makeSlipswitch 2 Hierbei ist CROSSID der Bezwichner der Kreuzung POINTID sind die Bezeichner f r die Weichen pair2opt kann ein optionales zweites Weichenpaar sein SWITCHTIME ist ein Schl sselwort und POSINT ist der positive Wert den diese annehmen kann Ein zweites Weichenpaar wird durch folgende Regel auf pair2opt reduziert pair2opt POINTID POINTID makeList Die Funktion struct slipswitch_t
313. en erh lt diese Funktion den Syntaxbaum des entsprechenden Gleisnet zes die zu benutzende Zieladresse f r die Route Dispatcher Projektierungsdaten und die ID der entsprechenden Route Als erstes wird die Routen ID eingetragen Danach werden mit Hilfe der clearances aus dem Syntaxbaum die Signalstellung f r die Route gesucht und der Wert f r die firstsigpos eingetragen Dies geschieht mit der Funktion void setStopSignal struct condclear_t clear struct shm_value_t sig int io Diese Funktion ermittelt anhand einer Signalbedingung einen entsprechenden SHM Wert der je nach Steuerparameter in den entsprechenden Bereich der Zieladresse schreibt Hierbei wird bei False der Eingabe und Ausgabebereich gesetzt bei True nur der Ausgabebereich Dann wird mit einer Schleife ber alle Signale mit der selben Funk tion der Wert f r die locksigpos eingetragen Innerhalb dieser Schleife wird auch der Wert f r die freesigpos ermittelt und eingetragen Dies geschieht durch den Aufruf folgender Hilfsfunktion void setSignal struct condclear_t clear struct shm_value_t sig Als n chstes wird ber eine Schleife aller Weichenstellungen f r diese Route aus dem Syntaxbaum der Wert f r die pointpos eingetragen Hierzu wird folgende Hilfsfunktion genutzt void setPoint struct condclear_t cond struct shm_value_t pnt KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 166 Danach wird aus dem Syntaxbaum die Sensorenliste fiir die Route erstellt Mit de
314. en k nnen so werden nach einem Zufallsverfahren Elemente besch digt Solcherma en gekennzeichnete Elemente k nnen bei der Aktualisierung im n chsten Schritt anderes als das Normalverhal ten zeigen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 341 3 stellbare Hardware Elemente aktualisieren Anschlie end werden alle stellbaren Hardware Elemente aktualisiert Bei einer Ak tualisierung kann eine stellbare Hardware ihren Zustand ndern wenn gen gend Zeit seit der Annahme einer Anforderung f r dieses Element vergangen ist in der Regel werden die Elemente nach der H lfte ihrer in der TND festgehaltenen maxi malen Schaltzeit umgestellt Besch digte Elemente ndern ihren Zustand nicht auch wenn das erwartet werden sollte oder sie ndern ihn spontan und uner wartet Der Simulator merkt sich alle ver nderten Hardware Elemente da er die Ver nderungen dem Steuerinterpreter in einem sp teren Schritt mitteilen wird Turnout update is another state requested rue has my switchtime passed false 5 true false switch state return if something changed Abbildung 7 66 Aktivit tsdiagramm Turnout update In jedem Durchlauf des Simulators wird auf jedem Hardware Element ein Update ausgef hrt d h es wird gepr ft ob in der Vergangenheit eine Anforderung einge gangen ist die noch nicht umgesetzt wurde und ob der Zeitpunkt zur Umsetzung gekommen ist in der Regel wird nach der H lfte der i
315. en read int und read uint16 tun nichts weiter als ein Element des entsprechenden Typs aus der Datei zu lesen und in den bergebenen Puffer zu schreiben Letztlich f llen wir also zwei Datenstrukturen mit Inhalt die dann in den Testprozeduren weiter verwertet werden Arne Stahlbock 7 7 5 2 Route Dispatcher An dieser Stelle wird die Implementierung der Testprozeduren f r den Route Dispatcher beschrieben Dieser Vorgang erfolgte in mehreren Etappen e Bestimmung einer sinnvollen Menge von Testf llen anhand der RD Spezifikation e Implementierung der Funktionalit t aus den Projektierungsdaten diese Testf lle f r das spezifische Gleisnetz zu erzeugen und sie in das SUT einzuspeisen Test generator e Implementierung der Funktionalit t aus einem Testdatensatz den vom SUT er warteten Output zu bestimmen Testorakel e Implementierung der Funktionalit t den vom SUT gelieferten Output mit dem des Testorakels zu vergleichen Testchecker 7 7 5 2 1 Bestimmung einer Menge von Testf llen Hierzu betrachten wir zun chst die Parameter der zu testenden Funktion void calculate_routes shm_state_t shm_shadow struct rd_data_t r char queue_tab struct queue_t queues int qpl int rst int bahn_counter int uebersprungene_queues Es werden also tibergeben e der SHM Zustand die Projektierungsdaten fiir den RD die Zuordnungstabelle von Routen zu Queues der aktuelle Zustand der Queues die Queue Priority List die
316. en soll e Es findet kein Austausch von Empfangsbest tigungsmeldungen statt e Der SI erkennt die erfolgreiche bertragung seiner Anforderungen daran dass diese umgesetzt werden und entsprechende Statusmeldungen erfolgen e Fehlerhafte Meldungen die nicht dem Nachrichtenformat entsprechen sind beim Empf nger zu ignorieren es findet keine R ckmeldung statt e Werden f r ein Element gleichzeitig mehrere Zust nde gemeldet so ist die Rei henfolge in der die Zust nde aufgef hrt werden nicht vorgeschrieben Das Nachrichtenformat e Bei Anforderungen request lt Element ID gt lt Zustand gt wobei request das Schl sselwort f r ei ne Anforderung darstellt lt Element ID gt der eindeutige Bezeichner des HW Elements und lt Zustand gt der angeforderte Zustand ist Die m gliche Zust nde sind left straight right bent dieser Zustand kann nur bei SL oder SR Weichen bzw Kreuzungsweichen angefordert werden bei anderen f hrt Anfor derung dieses Zustandes zum undefinierten Zustand quit bei Weichen bei Signalen sind es quit left right straight stop waitright waitstraight waitleft rrrighton rrlefton rrstraighton rrrightoff rrleftoff rrstraightoff Auch an Sensoren kann eine Anforderung gesendet werden die einizig m gliche ist hierbei quit Das Senden einer quit Anweisung f hrt da zu dass der Simulator f r dieses Element keine weiteren R ckmeldungen mehr erstattet da er damit rechnen muss das
317. en zu m ssen wurde eine Komponente entwi ckelt die es erm glicht ein Gleisnetz mithilfe des CAD Programms QCAD graphisch zu spezifizieren Diese Grafik kann dann automatisch in eine Tram Network Descripti on gewandelt werden Allerdings k nnen auf diese Art nur topologische Informationen erzeugt werden Eine graphische Eingabemaske erm glicht es eine Gleisnetzbeschrei bung in Form einer Tram Network Description komfortabel zu bearbeiten und zu ver vollst ndigen Mehr Informationen zu diesem sogenannten TND Builder finden sich in Abschnitt 7 3 Da im Projekt TRACS keine realen Gleisnetze gesteuert werden konnten wurde ein Gleisnetzsimulator entwickelt der ein Gleisnetz visualisiert und vom TRACS Steuerin terpreter gesteuert werden kann Details hierzu finden sich in Abschnitt 7 8 Helge L ding KAPITEL 9 BEWERTUNG 442 9 2 Projektarbeit und Management 9 2 1 berblick Dieser Bereich des Berichtes befasst sich mit der Projektarbeit als solcher Es soll ge zeigt werden wie die Projektaufgabe angegangen wie die Arbeit organisiert wurde und welche Erfahrungen dabei gemacht wurden Nicht fehlen sollen auch Einsch tzungen ob und wie man bestimmte Dinge h tte besser l sen k nnen Wir teilen den folgenden Abschnitt thematisch wie folgt auf e Verwaltungsgruppen Fiir organisatorische Dinge sowie fiir nicht auf das Projektthema bezogene aber auch ber die Dauer des Projektes anstehende Arbeiten wurden Verwaltungsgrup pen ein
318. en zu vorhan denen Stra enbahnsteuerungssytemen zu erlangen Anschlie end wurde sie aufgel st 9 2 3 6 Compiler Mit Beginn des zweiten Semesters wurde die Compilergruppe ins Leben gerufen welche die Aufgabe hatte einen Compiler f r die ben tigten Projektierungsdaten zu entwerfen der als Eingabe ein Dokument in TND Form bekommt KAPITEL 9 BEWERTUNG 446 9 2 3 7 Netzgraph Ein Nebenprodukt des Projektwochenendes in Nienburg gegen Ende des ersten Semes ters war der Netzgraph Bis dato war niemals die Rede davon dass eine graphische Darstellung eines Gleisnetzes mit Konvertierungstools zur Erzeugung einer Gleisnetzbe schreibung in TND Form ben tigt wird Diese Gruppe wurde also gegen Ende des ersten Semesters erschaffen und zu Beginn des zweiten Semesters mit neuer Besetzung fortgef hrt Sie hatte die Aufgabe der Konver tierung von mittels einer CAD Software erstellten Gleisnetzen in die TND Darstellung 9 2 3 8 Simulator Die Simulatorgruppe war ebenfalls ein Ergebnis des Projektwochenendes in Nienburg Sie wurde ebenfalls zum zweiten Semester ins Leben gerufen und konnte ihre Aufgabe die Erstellung einer Software zur Simulation von Gleisnetzen die dann letztlich durch den SI gesteuert werden sollten innerhalb von zwei Semestern bis auf kleine Nachar beiten bei Vorliegen des SI erledigen so dass danach wieder Arbeitskraft f r andere Bereiche frei wurde 9 2 3 9 EVP Die Gruppe zu Entwicklungs und Verifikationsp
319. enannten Weichente legramm erteilt dass etliche Informationen wie Routenziel Linie Routennummer Kurs Wagennummer den Richtungswunsch und eine Pr fnummer enth lt CRC und mu dreimal in Folge erteilt werden Die Signalsteuerung ist unabh nging von der der Weichen Die lteren noch mit Gl hbir nen ausgestatteten Anlagen werden durch solche mit LEDs ersetzt da es inzwischen auch Baugruppen zur Ausfallerkennung dieser gibt In so einem Fall sperrt die Weiche so dass der n chste Fahrer die Zentrale informieren und dann durch manuelles Verstellen der KAPITEL 2 DIE DOMANE 31 Weiche weiterfahren kann Zu den Sensoren z hlen sowohl Koppelspulen und Ortsbakensender als auch die Ab tastung der Weichenlage durch induktive N herungsschalter in der Bahn Zuk nftig soll auch durch magnetische Fahrsperren eine Richtungserkennung m glich sein Eine Ausfallerkennung findet nur durch den Fahrer statt und nur dann wenn etwas nicht funktioniert was wiederum an die Zentrale weitergeleitet wird Auch mit den Beschreibungsformalismen wird hnlich manuell verfahren Das Gleisnetz ist durch Hand und CAD Zeichnungen mit Eintragung der Koppelspulen und Weichen beschrieben inzwischen wird mit einem Gleismesswagen eine GPS gest tzte Abbildung im Stadtplan erstellt um Gleiszust nde anzeigen zu k nnen Vernetzt werden sollen die einzelnen Gleispl ne erst mit Umsetzung des neuen Systems Die Sicherheitsbedingun gen sind in der Dienstanweisung f
320. enden Zeitabst nde zumal diese durch unterschiedliche Verkehrsverh ltnisse Witterungsbedin gungen etc beeinflusst werden k nnen so dass der SI hier mit allen m glichen Abst nden umgehen muss e Reaktion Sensor Bahn und Bahn gt Signal F r beide F lle sind keine Reaktionen vorgesehen da auch in der Realit t keine hier stattfindende Reaktion erkennbar ist Die Einstellungen welche Route eine Stra enbahn bef hrt und wie schnell sie sich fortbe wegen kann sollen vom Anwender vor dem Start gesetzt werden k nnen Ebenso soll es m glich sein initial Weichen und Signale zu stellen damit gezielt getestet werden kann wie der Steuerinterpreter auf die gestellte Situation reagiert Beeinflussungen durch den Nutzer im laufenden Betrieb sind nicht explizit vorgesehen 7 8 2 2 2 Fehlerhaft agierendes Gleisnetz Mit Hilfe eines simulierten fehlerhaft agierenden Gleisnetz soll getestet werden wie der Steuerinterpreter z B mit Ausf llen von Hardwareelementen fertig wird bzw wie er auf diese reagiert Folgende fehlerhafte Situationen sollen daf r simuliert werden k nnen e Ausfall eines Hardwareelements Sensor Signal Weiche d h keine Reaktion des Elementes mehr e Eigenm chtige Schaltvorg nge von Weichen und Signalen bzw Sensorausl sun gen wenn keine Bahn am Sensor vorbeigekommen ist allgemein nicht erwartete Vorg nge e Nichtbeachten von Signalen durch Bahnen zwar kann der SI in diesem Fall einen Unfal
321. eoberfl che f r eben diese 59 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 60 noch fehlenden Daten bereitstellt so dass die in der TND abzulegenden Informationen vervollst ndigt werden k nnen Arne Stahlbock 7 1 2 Beschreibungssprache TND Die TND Beschreibungen enthalten folgende Informationen e Netzwerk e Verschlusstabellen e Hardware Beschreibung 7 1 2 1 Netzwerk Das Netzwerk besteht aus e Weichen points e Signalen signals e Sensoren sensors e Streckensegmente relations e Kreuzungen crossings Dar ber hinaus gibt es Kreuzungsweichen slipswitches Diese bestehen jedoch direkt aus Kreuzungen und Weichen so dass sie zun chst nicht als eigenes Hardware Element gef hrt werden sondern diejenigen Weichen und Kreuzungen die jeweils zu einer Kreu zungsweiche zusammengeschlossen sind an einer bestimmten Stelle in der Beschreibung als solche deklariert werden Die Netzwerkbeschreibung stellt die Zusammenh nge zwischen den vorgenannten Ele menten her Eine Erweiterung des Netzwerkes stellt der Netzgraph dar Dieser liegt h ufig in visueller Form CAD Darstellung vor und enth lt zus tzlich topologische Informationen wie zum Beispiel Koordinaten coordinates g200 0 0 0 und Markierungspunkte marks x100 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 61 7 1 2 2 Verschlusstabellen Verschlusstabellen beschreiben die Konditionen die notwendig sind um die sichere Durchfahrt von Bahnen durch das Gleisnetz
322. epot statt die vom Verein Freunde der Bremer Stra enbahn eingerichtet wurde Hier informierten sich die Projektteilnehmer vor allem ber Stra enbahntechnik der Vergangenheit KAPITEL 9 BEWERTUNG 448 9 2 4 5 Besuch der Bremer Strassenbahn AG BSAG Gegen Ende des ersten Semesters fand ein von der BSAG Arbeitsgruppe organisierter Besuch bei der BSAG statt Das Projekt stellte sich dort der BSAG vor und erfuhr im Gegenzug einiges tiber die bei der BSAG eingesetzten Systeme 9 2 4 6 Besuch von Hanning amp Kahl Im dritten Semester wurde Kontakt zu der Firma Hanning amp Kahl hergestellt die sich auch als relativ interessiert an unserer Thematik erwies Dies fiihrte letztlich zu einem Besuch eines Vertreters dieser Firma an der Universitat Bremen Ahnlich wie bei dem BSAG Besuch stellten beide Seiten ihre Arbeit genauer vor 9 2 5 Zeitplanung Die Zeitplanung ist ein wesentlicher Bestandteil eines Projektes Sie soll den Teilnehmern eines Projektes helfen das Ziel nicht aus den Augen zu verlieren n mlich die gestellte Aufgabe innerhalb des vorgegebenen Zeitraums m glichst vollst ndig zu erf llen Sie soll auch gew hrleisten dass die Teilnehmer bei den einzelnen Teilaufgaben nicht den berblick f r den Gesamtkontext verlieren Letztlich stellt sie also eine Planungshilfe f r alle Beteiligten dar In einem solchen Zeitplan werden die einzelnen Arbeitspakete der Teilgruppen mit ihren Abh ngigkeiten zu andern Paketen und
323. er Die Gruppen brauchen da bei nicht unbedingt alle Daten aus der TND e Der Simulator braucht aus der TND Datei nur die Informationen die n tig sind um das Gleisnetz zu visualisieren Ferner braucht er auch noch die Routenin formationen um auf dem dynamischen Gleisnetz Stra enbahnen entlang vorher definierter Routen fahren zu lassen s Simulator Kapitel 7 8 auf Seite 313 e Der Steuerinterpreter der vom Compiler die bin ren Projektierungsdaten be kommt die letztlich aus der TND hervorgehen ben tigt keine Koordinaten wohl aber alle Informationen aus den Verschlusstabellen und die Hardwaredaten e Modelchecker und HW SW Test als Verifikationsinstrumente f r den Steuerin terpreter ben tigen logischerweise dieselben Daten wie dieser da ansonsten eine Verifikation fehleranf llig ist Silvia Graumann Henrik R hrup Arne Stahlbock KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 80 7 1 5 Fortentwicklung der TND Die soeben beschriebende Sprachdefinition ist bereits die dritte Version die im Rahmen von TRACS entstanden ist Die erste Version stand zum Ende des ersten Projektse mesters musste aber im Laufe des dritten Semesters relativ umfassend berarbeitet werden da sich aus einzelnen Gruppen neue Anforderungen bez glich des durch die TND zu realisierenden Informationsumfanges ergaben Eine weitere jedoch nicht mehr so weitreichende Erneuerung wurde zu Beginn des vierten Semesters vorgenommen dies ist die vorliegende Fassun
324. er Daten dienen die oben beschriebenen Routen informationen einer vom tram Compiler einzulesenden TND 7 4 2 2 3 Projektierung des Safety Monitor Der Safety Monitor eines TRACS Steuerinterpreter pr ft zu jedem Zeitpunkt der Ausf hrung ob sich ein gesteuertes Gleisnetz in einem sicheren Zustand befindet Hierzu werden pro m glicher sicherer Befahrungskonstellation des zu pr fenden Gleisnetzes Sensorrelationen Weichen und Signalstellungen und Fehlermeldungen der Elemente ausgewertet Dies geschieht indem der Steuerinterpreter eine Liste von sicherern Gleisnetzzust nden auswertet Befindet sich das Gleisnetz in keinem der gegebenen sicheren Zust nde reagiert der Steuerinter preter mit seiner Ausnahmebehandlung Diese Liste von sicheren Zust nden erh lt der TRACS Steuerinterpreter aus seiner Projektierung die der tram Compiler zu diesem Zwecke generiert Hierzu errechnet der tram Compiler zun chst s mtliche sicheren Befahrungskonstella tionen Dies geschieht auf Basis der oben beschriebenen Konfliktinformationen einer eingelesenen TND Pro sicherer Befahrungskonstellation wird ermittelt wie sich Sensorenst nde des Gleis netzes zueinander verhalten m ssen und welche Stellung Signale und Weichen haben m ssen Diese Daten entstehen aus den oben beschriebenen Routeninformationen einer TND Zus tzlich zu Signal Sensor und Weichenst nden beinhaltet jeder sichere Zustand eine Pr fung aller eingesetzten Gleisnetzelemente auf Fehlerme
325. er Implementierung verlorenging Es musste so letztlich oft an meh reren Baustellen gleichzeitig gearbeitet werden wenn es besser gewesen w re sich auf eine Sache konzentrieren zu k nnen Es konnten somit nur noch die Testprozeduren f r den Route Dispatcher und den Route Controller fertiggestellt und die jeweiligen Tests durchgef hrt werden wobei auch in der Tat einige Fehler der getesteten Systeme zum Vorschein kamen Es stand letztlich nur knapp ber ein halbes Semester f r die angesetzten Arbeiten zur Verf gung wobei davon auch noch ein gewisser Teil in andere Bereiche von TRACS investiert werden musste Mit einer gr eren Besetzung h tte man zumindest noch die Parallelverarbeitung jede Person arbeitet an Testprozeduren f r ein anderes Teilsystem erh hen k nnen die ohnehin schon mit regelm igen Arbeitsbesprechungen betrieben wurde Da aber in anderen Teilbereichen von TRACS auch niemand h tte abgezogen werden k nnen musste man diese Situation hinnehmen Erst gegen Ende gab es noch einmal Unterst tzung bei der Erstellung der Konzepte f r die Integrationstests Die Ursachen f r diese Situation sind sicher vielschichtig und k nnen hier nicht vollst n dig gekl rt werden doch meinen wir dass im Wesentlichen die zu sp te Bereitstellung des Systems und der Spezifikation wof r es wiederum zig verschiedene Ursachen gibt eigentlich k nnte man da fast einen Fehlerbaum aufstellen sowie die ber lange Zeit KAPITEL 7
326. er Parser vorgestellt der eine TND Textdatei einliest Gofelgt wird dieser Arbeitsschritt vom Aufbau des Syntaxbaums Anschlie end soll noch genauer auf die Generierung der Projektierungsdaten eingegangen werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 148 0 1 struct sigpos_t signal struct symtab_entry_t sensi struct elementid_side_t sens2 struct elementid_side_t mark struct symtab_entry_t next struct sigpos_t T struct elementid_side_t elem struct symtab_entry_t side_elem int Abbildung 7 35 struct sigpos_t 7 4 4 1 Parser Hier soll nun der Parser mit seiner Funktionsweise erl utert werden Der Parser erh lt vom Scanner eine Folge von Symbolen die dieser aus der TND Beschreibung eines Gleisnetzes erzeugt Diese Symbolfolge wird von ihm gepr ft ob sie auch der Grammatik der f r die TND erzeugten EBNF entspricht Bei vorkommenden Fehlern wird der Parser eine Fehlermeldung generieren und diese mit der Zeilenangabe des Fehlers ausgeben Dabei geht er nach der panic recovery Methode vor d h bei einem gefunden Fehler versucht der Parser an einer geeigneten Stelle das Parsen wieder aufzunehmen damit er m glichst viele Fehler in einem Durchgang finden kann Der Parser des tram Compilers ist ein BOTTOM UP Parser d h bei der Ereugung des Syntaxbaums wird an den Bl ttern angefangen und der Parser arbeitet von dort bis oben zur Wurzel durch Der Parser versucht dabei immer die rechte Sei
327. er Simulation der Funktionsweise der Hardwareelemente und der Stra enbahnen Was muss wie simuliert werden damit die Simulation die Realit t ausreichend genau beschreibt Visualisierung der Zust nde aller Hardwareelemente und der Stra enbahnen Was muss wie visualisiert werden damit der Anwender des Simulators alle ben tig ten Informationen ber den simulierten Zustand des Gleisnetzes bekommt Schnittstelle zum SI der Simulator simuliert das Verhalten eines Gleisnetzes s o das von einem SI gesteuert wird Damit es gesteuert werden kann m ssen Treiber hergestellt werden Diese m ssen ber die von der SI Gruppe definierte Treiberschnittstelle ansprechbar sein Korrektheit Die Korrektheit des Simulators wird im Rahmen des Projektes TRACS nicht von anderen Modulen verifiziert Aus diesem Grund muss hier besonderen Wert auf eigene berpr fungen der Korrektheit geachtet werden Zeitverhalten Die Aktionen und Reaktionen in einem realen Gleisnetz laufen in bestimmten zeitlichen Gr enordnungen ab Damit die Simulation m glichst pr zise die realen Bedingungen wiedergeben kann muss darauf geachtet werden dass die Simulation die realen Zeiten in etwa einhalten kann Systemumgebung Es erscheint w nschenswert den Simulator m glichst auf handels blichen PC Systemen einsetzen zu k nnen zumal auch der SI als Kernprodukt des Projektes auf Standard PCs funktionieren soll 7 8 2 1 Flexibilit t Simulation verschieden
328. er Zeitplan um einiges in die L nge Diese Neu Einsch tzung stimmte dann am Ende aber ganz gut mit der wirklichen Dauer be rein Eine zwischenzeitlich gew nschte Verst rkung der Gruppe war leider mangels Personals nicht m glich Es wurde dagegen zu Beginn des dritten Projekt Semesters der Vorschlag gemacht die Netzgraphgruppe mit der Compilergruppe zusammenzulegen dies wur de aber niemals endg ltig beschlossen obwohl anderslautende Meinungen diesbez glich nie wirklich verstummten Anmerkung Es findet sich dazu auch in keinem Plenums Protokoll ein Hinweis auf einen derartigen Beschluss lediglich auf diesen Vorschlag wie auch die Netzgraphseite hat niemals die Zustimmung dazu gegeben und ber den Kopf eines betroffenen Projekt Mitglieds hinweg kann auch ein Plenum eine solche Entscheidung nicht treffen da dies dann andere f r das gesamte Projekt unangenehme Konsequenzen zur Folge gehabt h tte 7 2 5 5 Personalkarussell Die Idee hinter diesem Vorschlag war es jedenfalls durch eine Verst rkung der Com pilergruppe die Fertigstellung des Compilers zu beschleunigen und au erdem die dort gewonnenen Erfahrungen sp ter im Netzgraphen einflie en zu lassen was vom Prinzip her sicherlich ganz sinnvoll gewesen w re Da aber bei beiden Gruppen eine Einarbeitung der jeweils anderen Gruppenmitglieder h tte erfolgen m ssen welche aus Sicht der Netzgraphgruppe beim Blick auf Verst nd nisfragen bei der Aufgabe des Compilers dort
329. er f r die Wei terverarbeitung sogar noch an den Best TramNetworkBuilderOfTheUNIverse BTNB weitergegeben wird In den Zeilen 5 11 werden die erkannten Zeichen als Symbole wei tergegeben In Zeile 13 wird eine ID erkannt diese besteht aus einem g mit anschlie Penden Ziffern und Buchstaben In der darauf folgenden Zeile wird eine Koordinate erkannt welcher optional ein Minuszeichen voraus gestellt ist und daraufhin mindestens eine Ziffer folgt Der eingelesene und erkannte String wird an dieser Stelle gleich in ein Integer gecastet und weitergegeben Letztendlich wird s mtlicher WhiteSpace dazu geh ren Leerzeichen TabStops und Zeilenumbr che ignoriert 7 8 5 1 3 Parser Nach dem Einlesen der Datei durch den Lexer erfolgt die Wei terverarbeitung der erkannten Token durch den Parser Dieser muss nun schauen dass er Produktionen findet so dass die erkannten Token zu der vom Parser akzeptierten Grammatik passen Ist dies nicht der Fall so w rde der Parser eine Fehlermeldung aus geben Der Parser selbst ist in der Datei parser def spezifiziert welche ebenfalls von der Compilergruppe erstellt wurde und von der Simulatorgruppe im Vergleich zu der Spezifikation des Lexers gr ndlich ver ndert bzw angepasst werden musste teils weil KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 375 Differenzen zwischen CUP und yacc existeiern teils weil die Art der Weiterverarbeitung sich zwischen Compiler und Simulator zu stark unterschieden Mit
330. er kann nun ein Software In tegrationstest durchgef hrt werden Hierbei werden Projektierungsdaten f r einen kon kreten Safety Controller eingelesen und dessen flache Spezifikation hergeleitet Der Test generator kann daraus nun Testtraces generieren und ausf hren Dadurch wird der Test ling durch Schreiben von Shared Memory Werten im Ist Zustand stimuliert und muss reagieren Der Testchecker simuliert die Spezifikation und berpr ft die resultierenden Shared Memory Werte im Soll Zustand Treten Inkonsistenzen zur Spezifikation zwi schen Testling und Simulation auf so gilt der Test als gescheitert Abbildung 7 59 auf der n chsten Seite zeigt das Zusammenspiel von Spezifikation Testgenerator Testche cker und Testling im Testaufbau KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 308 RT Tester Testgenerator W Methode Testfallgenerierung Testdaten Spezifikation L x Projektierungsdaten SHM EJ Verarbeitung Safety Controller Soll Zustand eer Ist verarbeiten Testchecker sae as Abbildung 7 59 Testkonzept der Software Integrationstests Nun kann ein Hardware Software Integrationstest durchgef hrt werden Hierbei wird die zu testende Software auf ihrer Zielhardware getestet Das Testvorgehen entspricht hierbei dem Vorgehen im Software Integrationstest Aufgrund der Architektur der Te stumgebung bleiben hierbei Testgenerator und Testchecker unver ndert Zwar m ssen hierbei Ein und Ausgaben des Testlings ber I O Har
331. er seine Munition zum Steuern von Gleisnetzen liefert entstand der Name tram aus TRACS Ammunition 7 4 1 berblick Gleisnetzinformationen werden in Form einer textuellen Beschreibungssprache vorge geben welche alle zur Steuerung relevanten Daten ber ein Gleisnetz enth lt Diese Informationen werden vom tram Compiler eingelesen und verarbeitet Als Resultat entstehen Bin rdaten welche einem vom TRACS Steuerinterpreter vorge gebenen Format entsprechen Diese bin ren Eingabedaten f r den Steuerinterpreter sind so strukturiert dass sie effizient zum Steuern des urspr nglich beschriebenen Gleisnetzes genutzt werden k nnen Der folgende Abschnitt erl utert detailliert welche Anforderungen an den tram Compiler gestellt werden wie er aufgebaut ist und auf welche Weise er seine Aufgaben erf llt Zus tzlich werden externe sowie die wichtigsten internen Schnittstellen beschrieben Abschnitt 7 4 2 beschreibt die Aufgaben des tram Compilers mit Bezug auf diejeni gen TRACS Komponenten die vom tram Compiler abh ngen Dieser Abschnitt dient haupts chlich der Einordunug des Compilers in den Gesamtrahmen des TRACS Pro jektes Abschnitt 7 4 3 beschreibt den Aufbau des tram Compilers Hierbei werden die einzelnen Stufen der Generierung von bin ren Projektierungsdaten f r den TRACS Steuerinter preter entsprechenden Teilen des tram Compilers zugeordnet Abschnitt 7 4 4 erl utert das Vorgehen des tram Compilers bei der Erstellung von
332. er und manueller Generierung verglichen 3 3 Deren Generierung In der manuellen Entwicklung gibt es neben dem wiederkehrenden Entwicklungsaufwand das Problem dass mehrere Schritte der Entwicklung relativ aufwendig von Hand auf ihre Sicherheit gepr ft werden m ssen was eine Menge Zeit kostet und damit auch Geld weil diese Schritte f r jedes Gleisnetz erneut durchgef hrt werden m ssen Es muss f r jedes Gleisnetz von Hand die gesamte Entwicklungsarbeit f r das Steue rungssystem erneut ausgef hrt werden Daneben gibt es das Problem dass auch die Validierung f r jedes Gleisnetz neu von Hand durch gef hrt werden Die h ndische Pro grammierung ist au erdem noch fehlertr chtig und f hrt zu Inkonsistenzen 3 4 Deren automatische Generierung Wenn die Gleisnetzsteuerungssysteme hingegen automatisch generiert werden k nn ten w rden die obengenannten Probleme reduziert werden Daf r ergibt sich dann das zus tzliche Problem dass die automatische Generierung auch f r jedes Gleisnetz funktionieren muss welches dem im Abschnitt 2 auf Seite 10 beschriebenen Weltmo dell entspricht Aber mit genau dieser Universalit t kann dann vermieden werden dass f r jedes Gleisnetz Code von Hand geschrieben werden muss so dass der Code daf r wiederverwendbar ist Durch die Wiederverwendbarkeit muss nicht mehr alles neu ent wickelt werden wodurch der Entwicklungsaufwand verkleinert wird Auch der Verifi kationsaufwand kann durch die Automa
333. erden Die Nachbarschaftssituationen f r trPoint und trCrossing sind anderes als f r trDevice Bei trPoint ist das Hardwareelement das sich auf der Seite incoming befindet benachbart mit den Hardwareelementen auf den Seiten straight left oder right Die Hardwareelemente auf der Seite straight left bzw right ist nur benachbart mit dem Hardwareele ment auf der Seite incoming Bei trCrossing ist das Hardwareelement auf der Seite inl nur benachbart mit dem Hardwareelement auf der Seite outl und das Hardwareelement auf der Seite in2 ist nur benachbart mit dem Hardwareelement auf der Seite out2 e trRoute trRoute repr sentiert die f r das jeweilige Gleisnetz definierten Rou ten Sie ist eine wichtige Klasse im Klassendiagramm Die Klasse hat folgende Attribute einen Route Request Sensor einen Eingangssensor einen Ausgangssensor ein Eingangssignal eine Liste von Signale die sich auf der Route befinden und ihre GO Rich tungen eine Liste von Weichen die sich auf der Route befinden und ihre Einstellun gen eine Liste von Konfliktrouten eine Liste von Routen zu denen Weichenkonflikte bestehen e trTNDObjectStore trINDObjectStore umfasst alle f r ein Gleisnetz ben tigten Objekte So sind alle Hardwareelemente und alle logischen Routen in tr TINDOb jectStore gespeichert 7 3 4 2 4 GUI Die Komponente GUI ist f r die graphische Darstellung von Kom
334. erneut der Liste hinzugef gt damit sie nicht verloren geht und erneut ein Sendeversuch unternommen werden kann Anschlie end kehrt die Endlosschleife an den Beginn zur ck public synchronized boolean checkPending if statusList size 0 return false else return true private synchronized void addAgain String report statusList addFirst report private synchronized String getReport String retvalue new String retvalue String statusList removeFirst return retvalue public synchronized void addReport String report statusList add report Dieses sind die Zugriffsmethoden auf die Warteliste in diesem Fall darf nur der Sendethread selbst Strings entnehmen und im Falle des gescheiterten Sendens erneut einf gen daher haben getReport und addAgain nur private Zugriff Das Hinzuf gen addReport und Pr fen auf nicht leere Liste checkPending ist public deklariert Zu beachten ist noch dass keine Pr fung auf Korrektheit des Strings erfolgt der Sender geht also davon aus dass das Format bereits anderweitig also im Simulator der ja die Strings generiert sichergestellt wurde public synchronized void addDriver ArrayList drv Integer hw Integer drv get 0 SocketChannel sock SocketChannel drv get 1 drivers put hw sock System out println Adding driver for hw KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 403 public synchronized void removeDriver Object hw if hw instance
335. errkreis Slipswitch Slipswitch simuliert eine Kreuzungsweiche Diese Klasse koppelt zwei bzw vier Instanzen von Turnout und eine von Crossing zusammen und sorgt daf r dass diese als ein gemeinsames Element bez glich des Umschaltens und der Kollisionsabfrage behandelt werden Signal Signal simuliert ein Lichtsignal das von einem Stra enbahnfahrer gesehen wird Die Klasse erbt von SwitchableHW und Linkable und hat hn lich wie Turnout einen Typ annehmbare Zust nde einen angeforderten Zustand und eine Schaltzeit Mark Mark bildet einen St tzpunkt im Gleisnetz an dem die Gleisst cke ver kn pft sein k nnen Die Klasse erbt direkt von Hardware und Linkable und hat keine weiteren Eigenschaften Crossing Crossing stellt eine Kreuzung im Gleisnetz dar bei der die sich schneiden den Gleise auf gleicher H he sind Diese Klasse erbt direkt von Hardware und Linkable und hat keine weiteren Eigenschaften Sensor Sensor erbt direkt von Hardware und bildet eine abstrakte Vaterklasse f r alle Sensortypen Sensoren k nnen aktiviert und deaktiviert werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 331 RouteRequestSensor RouteRequestSensor erbt direkt von Sensor Dieser Typ Sensor l st aus wenn eine Stra enbahn bei der berfahrt ein Routentelegramm schickt StateSensor StateSensor erbt direkt von
336. ers von C in JavaTM bersetzt Dies w rde viel Pro grammieraufwand bedeuten jedoch w re der gr te Aufwand nicht die Implemen tierung sondern die Verifikation dieses Compilers Aus diesem Grund kommt ein Compiler C Java Mnicht in Frage Der andere Weg ist einen eigenen Compiler in Java zu programmieren der das TND Format einliest und eine Klassenstruktur f r den Simulator erstellt Dies ist nicht sonderlich schwierig bedeutet jedoch etwas mehr Aufwand Siehe hierzu den kommenden Abschnitt 7 8 4 3 M e Schnittstelle Steuerinterpreter Der Simulator kommuniziert w hrend der Laufzeit mit dem Steuerinterpreter Die Kommunikation erfolgt hierbei mittels Shared Memory das auf dem Rechner auf dem der SI l uft angelegt wird Um diesen Rechner wiederum an denjeni gen auf dem der Simulator l uft anzukoppeln wird eine Netzwerkverbindung auf TCP IP Basis benutzt ber die Meldungen in Form von Strings also Zeichen ketten versendet werden sollen F r die Umsetzung der Informationen die der SI KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 328 in das Shared Memory schreibt in die an den Simulator zu versendenden Strings und entsprechend f r die Gegenrichtung werden Treiber ben tigt die den Anforderungen des SI an Hardware Treiber gen gen Diese Treiber werden in C geschrieben um an den ebenfalls in dieser Sprache geschriebenen SI angebunden werden zu k nnen Texte k nnen sowohl von C als auch von Java gleich inter preti
337. erster Ebene versehen e Solche berg nge zus tzlich mit Bedingungen ber das Zustandsfeld der Zielkom ponente versehen Helge L ding 7 7 7 2 W Methode Die oben beschriebene flache Spezifikation eines konkreten Safety Controllers kann nun als Basis f r Testfallgenerierung genutzt werden Hierbei kommt es darauf an zu zeigen dass die Implementation des Safety Controllers die selben Zust nde und berg nge wie die Spezifikation hat Hierzu wird die sogenannte W Methode aus Cho78 verwen det mit der diese Forderungen nachgewiesen werden k nnen indem nacheinander alle Zust nde der Spezifikation angenommen werden und dann Eingaben geliefert werden die durch Reaktionen des Testlings darauf den aktuellen Zustand von allen anderen Zust nden unterscheiden Hierzu sind allerdings Erweiterungen notwendig da bei der original W Methode nur Testtraces aus Events generiert werden Da wir in unserer Spe zifikation allerdings nur mit Bedingungen und nicht mit Events arbeiten Dies l sst sich allerdings aufeinander abbilden wie sp ter beschrieben wird KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 306 Zus tzlich k nnen nicht alle berg nge der Spezifikation erzwungen werden da nicht intrusiv getestet werden soll und nicht alle berg nge von externen Bedingungen ab h ngen Hierzu m ssen Testtraces zus tzlich mit dem internen Alphabet den m glichen intern auftretenden Freignissen kombiniert werden um jeden Zustand der Spezifikatio
338. ert werden d h die Programmiersprache des eigentlichen Simulators kann unabh ngig von der der Treiber C gew hlt werden Die Kommunikation mit dem Steuerinterpreter und die simulatorinterne Kommu nikation Treiber eigentlicher Simulator wird sp ter im Abschnitt 7 8 4 6 genauer beschrieben e Fazit Daraus ergibt sich dass f r das Einlesen des Gleisnetzes im TND Format die Pro grammiersprache C von Vorteil w re Die Benutzung der Sprache Java w rde mehr Aufwand bedeuten ist aber auch m glich F r die Kommunikation mit den Treibern ist es egal ob Java oder C benutzt wird 7 8 4 1 3 Pers nliche Erfahrungen Die derzeitigen Mitglieder der Arbeitsgrup pe Simulator haben sowohl Erfahrungen mit der Programmiersprache Java als auch mit C wobei die Java Kenntnisse deutlich berwiegen Des Weiteren wurde die Programmierung einer graphischen Benutzeroberfl che bisher nur mittels Java in Er fahrung gebracht Somit sind alle Mitglieder fitter in Java Mals in C was bedeutet dass wir in Java weniger Einarbeitungsaufwand ben tigen und effektiver programmie ren k nnen 7 8 4 1 4 Fazit Es hat sich herausgestellt dass Java fiir unsere Zwecke die geeig netere Sprache ist Auch die pers nlichen Erfahrungen sprechen f r Java Nur beim Einlesen des Gleisnetzes w re die Wahl von C von Vorteil Wir gewichten die Vortei le von Java gegeniiber C schwerer da die Effizienz beim Java M Programmier
339. es d h die Topologie s mtliche Routendaten und Angaben zu Gleisnetzelementen kurz gesagt alles was f r ein Steuerungssystem ben tigt wird Die TND ist damit die mass gebende Datenquelle f r unseren Generierungs und Verifikationsprozess Eine genaue Beschreibung findet sich in Abschnitt 7 1 auf Seite 59 4 2 2 2 bin re Projektierungsdaten W hrend die TND eine menschenlesbare Datei mit mehreren Verwendungszwecken ist ben tigt das Steuerungssystem eine m glichst einfach zu verarbeitende und hocheffizien KAPITEL 4 DER LOSUNGSANSATZ 43 te Form von Steueranweisungen Diese werden in Form der bin ren Projektierungsdaten generiert die genau angeben welche Hardwareelemente vorhanden sind sowie wann und wie sie zu schalten sind Marius Mauch 4 3 Verifikation und automatisierter Test 4 3 1 Model Checking Model Checking ist ein Verfahren um zu berpr fen ob in einem System bestimmte Ei genschaften gelten Dazu muss ein Modell des Systems erstellt werden und es m ssen die zu berpr fenden Eigenschaften spezifiziert werden Hier soll Model Checking eingesetzt werden um die Sicherheitseigenschaften zu berpr fen Eine wesentliche Aufgabe des Steuerungssystems ist es das Auftreten von Entgleisungen und Kollisionen zu verhindern Anhand der Beschreibung des jeweiligen Gleisnetzes l sst sich ein Modell des Gleisnetzes erstellen und es lassen sich die Sicherheitsbedingungen bestimmen die in dem Gleisnetz gelten m ssen Da
340. es Paket genannt obwohl es in mehrere Teile aufsplittbar gewesen w re All dies machte eine Zeitplanung zeitweilig extrem schwierig da hierdurch auch viele Inkonsistenzen entstanden 9 2 6 1 11 Fehleinsch tzungen des Zeitaufwandes Ebenso passierte es hin und wieder dass die eine oder andere Gruppe mit ihren Zeitsch tzungen deutlich daneben lag so dass die Fertigstellung eines Teils der Arbeit schon einmmal fast sechs Monate l nger dauerte wovon andere Gruppen mehr oder minder abh ngig waren Zu allem KAPITEL 9 BEWERTUNG 452 Ubel kam dann noch der vorzeitige Abgang diverser Projektteilnehmer dazu so dass durch diesen Personalschwund s mtliche Zeitsch tzungen revidiert werden mussten 9 2 6 1 12 Unklare Betreuungssituation Es war wenig hilfreich dass der eigent lich als Hauptbetreuer vorgesehene Professor gleich zu Beginn ein Forschungssemester einlegte und erst danach zum Projekt dazusto en wollte was letztlich niemals geschah W hrend des ersten Semesters bestand so immer eine gewisse Unsicherheit m gli cherweise auch bei den Betreuern die erst mit der endg ltigen Absage aufgehoben wurde 9 2 6 1 13 Begleitende Lehrveranstaltungen Auch war es alles andere als ideal dass wesentliche begleitende Lehrveranstaltungen erst im zweiten oder gar dritten Pro jektsemester angeboten wurden obwohl sie im Nachhinein betrachtet im ersten Semester h tten stattfinden m ssen 9 2 6 2 Fazit Trotz der beschriebenen Probleme
341. es auch jemanden geben der die Ger te betreut und einrichtet Dazu wurde die Admingruppe ins Leben gerufen KAPITEL 9 BEWERTUNG 444 9 2 2 6 Service und Technik Die Service und Technikgruppe ist eine Zusammenlegung der drei zuletzt genannten Gruppen im letzten Semester des Projektes da zu diesem Zeitpunkt bereits mehr als die Halfte der urspriinglichen Teilnehmer das Projekt verlassen hatten und ein gewis ser Personalmangel bestand Diese Gruppe kiimmerte sich also fortan um die Bereiche Webseite CVS Dokumentation und Projektraumrechner 9 2 3 Arbeitsgruppen Da das Projekt letztlich aus mehreren Teilaufgaben bestand wurden verschiedene Ar beitsgruppen eingerichtet die jeweils ein bestimmtes Aufgabenfeld bearbeiten sollten Einige Gruppen existierten dabei ber die gesamte Projektdauer andere nur f r k rzere Zeitr ume Die Gruppen waren im Einzelnen e DSL e Steuerinterpreter e HW SW Test e Modelchecking e BSAG e Compiler e Netzgraph e Simulator e EVP e TND Builder e Weltmodell FTA Diese Gruppen werden nun n her beschrieben KAPITEL 9 BEWERTUNG 445 9 2 3 1 DSL Die DSL Gruppe hatte die Aufgabe eine dom nenspezifische Beschreibungssprache fiir die Darstellung von Gleisnetzen zu entwickeln Diese Gruppe war nach einer Reihe von Vortr gen auch in der Lage dies zu bewerkstelligen und konnte bis zum Ende des ersten Projektsemesters eine erste Version der als TND bezeichneten Sprache vorstellen Nach
342. es keinen Sinn macht dass eine Tram auf sich selbst auff hrt wird dieser Fall nicht berpr ft Falls eine andere Stra enbahn gefunden wurde so wird gepr ft ob das Ende der dieser Stra enbahn auf der zu pr fenden Position ist Falls Ja stoppt die Stra en bahn Falls Nein wird die Pr fung mit den restlichen Stra enbahnen fortgesetzt Tram checkHeadCollision checkHeadCollision pr ft ob eine Stra en bahn mit einer anderen frontal zusammengesto en ist Dazu werden alle anderen Stra enbahnen wie bei driveInto berpr ft Jedoch wird hier gepr ft ob sich der Kopf einer anderen Stra enbahn an der gleichen Position befindet wie der Kopf der eigenen Tram Falls Ja ist ein Zusammensto passiert und dem Simulator wird Bescheid gegeben Danach ist die Methode beendet KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 351 Tram drivelntafnew position on new track get all trams tram me tail of other tram ahead no trams lefi return iftram stops Abbildung 7 72 Aktivit tsdiagramm Tram drivelnto Tram checkHeadCollisiong get all trams trar me head of other tram ahead true handle crash no trams left Abbildung 7 73 Aktivit tsdiagramm Tram checkHeadCollision Tram checkCollision Diese Funktion pr ft ob es eine andere Kollision au er dem Frontal Zusammensto gibt Dies ist nur m glich wenn die Tram auf ein neues Gleisst ck gewechselt h
343. eschreibung des Gleisnetzes gewonnenen Informationen abh ngig wo sich der jeweilige Sensor befindet Ein Sensor kann erreicht werden wenn sein Vorg ngersen sor passiert wurde und die Signal und Weichenstellungen dies zulassen Befindet sich vor einem Sensor ein Signal dann ist der Sensor nur erreichbar wenn das Signal nicht auf STOP steht So ist in dem Beispiel der Sensor g4125 nur erreichbar wenn das Signal s3013 nicht auf STOP steht Damit der Sensor g4125 erreichbar ist muss zudem eine Bahn von Route Request Sensor 0 auf ihn zufahren Zudem ist es oft nur m glich einen Sensor von einem anderen Sensor aus zu erreichen wenn bestimmte Weichen bestimmte Stellungen haben So kann der Sensor g4126 in dem Beispielgleisnetz erreicht werden wenn die Weiche w1018 nach rechts gestellt ist und eine Bahn von Sensor g4125 auf ihn zuf hrt Das eine Bahn von g4125 auf g4126 zuf hrt kann man daran erkennen dass der Z hlerwert von g4126 kleiner ist als der von g4125 Der Sensor g4126 kann ebenfalls erreicht werden wenn die Weiche w1022 nach links gestellt ist und eine Bahn von Sensor g4129 auf ihn zuf hrt g4125_cond_1 case s3013 state STOP amp rr_O_next_tram no 1 1 0 esac g4126_cond_1 case wi018 state RIGHT amp g4126 ctr lt g4125 ctr 1 w1022 state LEFT amp g4126 ctr lt g4129 ctr 1 1 0 esac g4127_cond_1 case s3015 state STOP amp rr_2_next_tram no 1 KAPITEL 7 BESCHREIBUNG DER KO
344. estgehalten worin die Mitarbeiter viermal im Jahr geschult werden Es gibt also keine booleschen Regeln ob ein Fahrzeug in eine Route einfahren darf oder nicht da ja der Fahrer alles manuell steuern kann ber den Betrieb der BSAG wacht die Technische Aufsichtsbeh rde die alle Neueinf hrungen begutach ten mu Vortrag von Herrn Hatesaul ber das Steuerungssystem IMU100 Anhand von Folien des Herstellers Siemens wurden die technischen Details des IMU100 erl utert von denen aber einige wie die Funkfrequenzen und Abmessungen der Bauteile nicht von Interesse sind Es ist ein Bordinformationssystem in dem alle m glichen Rou ten auch Umleitungsstrecken gespeichert sind Die externe Kommunikation wird ber Antenne die interne ber den seit 1980 als unverbindlichen VDV Standard definierten Ibis Wagenbus geregelt Die Fahrzeugortung l uft ber Erkennung der gefahrenen Me ter und wird auch dazu verwandt Haltestellen anzusagen was bisher der Fahrer per Knopfdruck erledigen mu te Die Zeit wird per Funkuhr ermittelt Die Weichen geben dem System keine R ckmeldung das Fahrzeug wird nur ber den Achskurzschlu und sein Gewicht registriert so dass nachfolgende Z ge die Weiche nicht stellen k nnen Mit dem IMU100 Empf nger k nnen 16 frei definierbare Relais gesteuert werden Das integrierte aus finanziellen Erw gungen gleich mitgekaufte System ORBAS wird noch nicht eingesetzt Diese ORtsBAkenSender verf gen ber jeweils acht Relais
345. esuch der Ausstellung Das Depot Die Stra enbahn Ausstellung Das Depot ist eine Ausstellung die von ehrenamtlichen Mitarbeitern geleitet wird die Freunde der Bremer Stra enbahn e V Wir entschlos sen uns zu einem Besuch der Ausstellung da sich das Treffen mir der BSAG immer weiter nach hinten verschob und wir einige Fragen bez glich des Stra enbahnsystems beantwortet haben wollten um etwas weiterarbeiten zu k nnen Diese Fragen bezogen sich auf die grundlegenden Konzepte des Stra enbahnbetriebs Anfang M rz 2004 trafen wir uns mit den ehrenamtlichen Mitarbeitern vom Depot und erhielten eine pers nliche F hrung bei der uns alle Fragen die wir stellten gern und nach besten Wissen beantwortet wurden Dass dieser Besuch nicht das Treffen mit der KAPITEL 2 DIE DOMANE 29 BSAG ersetzen w rde war von vornherein klar Wir erhielten viele interessante Informa tionen vor allem ber Weichen Signale Schilder und Ampelsteuerung Die Mitarbeiter vom Depot stellten uns den Stra enbahnbetrieb aus Sicht des Stra enbahn Fahrers vor Bei unseren tiefergehenden Fragen zu den technischen Gegebenheiten konnten sie uns leider nicht viel weiterhelfen F r genauere Informationen unseres Besuchs liegt eine Mitschrift der Ausstellung vor welche in elektronischer Form auf der Webseite unseres Projekts zu finden ist F r weiterf hrende Informationen zur Ausstellung sei auf die Internetseite der Ausstel lung Bre04 un
346. ete Au erdem war es daf r verant wortlich den allgemeinen Ablauf im Projekt zu koordinieren bei Problemen zwischen Gruppen und Teilnehmern zu vermitteln etc Es war quasi das Bindeglied zwischen Projektteilnehmern und Projektbetreuern 9 2 2 2 Projekttag Organisation Eine nur in der ersten H lfte des letzten Projektsemesters aktive Gruppe war jene Grup pe zur Organisation des Projekttages welcher gegen Ende eines jeden Hauptstudium projektjahrgangs stattfindet Sie musste den Projektstand und die Pr sentation des Projektes auf dem Projekttag als solches planen und organisieren 9 2 2 3 Web Die Webgruppe war f r die Einrichtung und Gestaltung einer das Projekt beschreiben den Webseite zust ndig W hrend des gesamten Projektes musste diese Seite immer wieder aktualisiert werden da ber einen mit einem Passwort gesch tzten Bereich auch die Protokolle der einzelnen Projektplena und auch die Pr sentationsfolien von gehalte nen Vortr gen als Download verf gbar gemacht wurden 9 2 2 4 Doku Die sogenannte Dokugruppe war nicht nur f r die Erstellung eines Rahmens f r die Dokumentation dieser und andere Berichte sondern war auch f r die Einrichtung eines CVS Repositories zust ndig mit welchem fortan gearbeitet wurde 9 2 2 5 Sysadmins F r die Rechner in unserem Projektraum der uns von der Universit t und dem Ver anstalter Arbeitsgruppe Betriebssysteme und verteilte Systeme zur Verf gung gestellt wurde musste
347. ete Zeit im Simulator bereinstimmen Die im Computer vergangene Zeit setzt sich zusammen aus e Zeit f r die Berechnung einer Runde der Simulation e Zeit f r die Verarbeitung von Nachrichten der Treiberschnittstelle e Zeit f r die Berechnung der Visualisierung e Zeit f r die arbeitenden Hintergrunddienste im System Da es keine Anforderung des Simulators an ein Echtzeitbetriebssystem gibt stellt ge rade der letzte Punkt eine m glicherweise gro e und unberechenbare Gr e dar Durch einen Verzicht auf permanent der Echtzeit entsprechende Zust nde im Simulator l sst sich jedoch eine andere Art der Echtzeit realisieren es wird daf r gesorgt soweit eben m glich dass jeder Simulatorschritt gleich lang dauert indem man nach Abschluss ei ner Runde eine bestimmte Zeit abwartet bevor man die n chste Runde einleitet Die Soll Dauer einer Runde wird so gro gew hlt dass alle n tigen Berechnungen auf jeden Fall in dieser Zeit erfolgen k nnen Es wird die Dauer der Berechnungen gemessen und die Runde vervollst ndigt indem die noch zur Soll Dauer fehlende Zeit gewartet wird Dieses Ziel wird durch das in Pseudo Code dargestellte Konzept in Abb 7 79 realisiert Dabei wird nicht davon ausgegangen dass die Systemuhr die absolut korrekte Uhrzeit 1 curTime aktuelle Systemzeit 2 if prevTime Simulator STEP_DURATION gt curTime 3 sleep prevTime Simulator STEP_DURATION curTime 4 5 prevTime aktuelle Systemzei
348. etz enthalten sind werden aufgelistet Optionen sind Stellung Die Stellung gibt an was das Signal zu Beginn der Simulation anzeigen soll Aus einer Liste kann die gew nschte Stellung ausgew hlt werden Die Ele mente der Liste sind abh ngig vom Typ des Signals d h es kann nur eine Stellung ausgew hlt werden die das Signal auch annehmen kann RR Mit bis zu drei Checkboxen je nach Vorhandensein der RR Anzeigen am Signal k nnen diese RR Anzeigen initial ein oder ausgeschaltet werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 356 May fail Durch Aktivieren dieser Checkbox setzt der Nutzer die Option dass ein Signal w hrend des Betriebes ausfallen kann Es wird dann keine Schaltbefehle mehr ausf hren Wann der Ausfall eintritt ist unvorhersehbar Random behavior Das Signal wird sich potentiell eigenm chtig umstellen wenn diese Option aktiviert ist Mittels des Knopfs OK wird der Initialisierungsschritt der Signale und der ge samte Initialisierungsprozess abgeschlossen e Random Simulation Der Nutzer hat auch die M glichkeit auf Einstellungen fast vollst ndig zu ver zichten Er muss dann lediglich eine Abfrage die f r die Anzahl der Bahnen absolvieren Die Bahnen werden dann zuf llige Routen w hlen Signale und Wei chen bleiben dann im anf nglichen undefined Zustand bis sie vom SI erstmals geschaltet werden Gelangt eine Bahn an ein im undefinierten Zustand stehendes Sign
349. eutet KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 408 send_msg sendet einen String ber den offenen Socket ab recv_msg bertr gt auf dem Socket eingegangene Daten in einen Lesepuffer und extrahiert daraus komplette Strings die dann vom Treiber ausgewertet werden k nnen init_con baut die Verbindung auf Die weiteren Treiber unterscheiden sich nicht wesentlich von diesem die Differenzen liegen lediglich darin dass andere Elementtypen angesteuert werden daher die SHM Belegungen andere Bedeutungen haben und folglich andere Textmeldungen ausgetauscht werden Die Treiber wurden urspr nglich ohne einen vorliegenden SI entwickelt Dies hatte zur Folge dass erst bei Existenz eines lauff higen SI kurz vor dem Projekttag wirkliche Tests betrieben werden konnten Dabei zeigte sich dass es besser war f r jeden Treiber eine Verbindung zum Simulator aufzubauen und diese dann f r den Betrieb aufrechtzu erhalten als bei jeder Meldung eine neue Verbindung zu initiieren Die hierf r n tigen Umstellungen wurden von der SI Gruppe vorgenommen Silvia Graumann Niklas Polke Arne Stahlbock 7 8 6 Tests In diesem Kapitel soll beschrieben werden welche Tests an Teilkomponenten und der gesamten Simulatorsoftware durchgef hrt wurden 7 8 6 1 Tests von Methoden Tests von Methoden sind die unterste Ebene der am Simulator durchgef hrten Tests sie wurden meist derart durchgef hrt dass in die Methoden zwischenzeitlich print1n Anweisungen
350. evor die Probleme begannen Die Netzgraphgruppe wurde zum Ende des ersten Projektsemesters ins Leben gerufen nachdem der Netzgraph berhaupt erst an dem Projektwochenende in jenem Semester auf die Tagesordung gehoben wurde In der verbleibenden Zeit jenes Semesters wurden vorrangig allgemeine Informationen zur Thematik recherchiert und unter anderem die zu verwendende CAD Software festgelegt Zu diesem Zeitpunkt war die Gruppe aber nur eine Art Nebengruppe da deren Mitglie der in anderen Gruppen aktiv waren Erst mit Beginn des zweiten Semesters wurde die Gruppe zu einer vollwertigen Gruppe mit haupts chlich neuer Besetzung 7 2 5 3 Gruppeninterne Probleme Im zweiten Projekt Semester gestaltete sich dann die Arbeit in der Netzgraphgruppe als schwierig da zwei Drittel der Gruppenmitglieder vorzeitig ihre Arbeit eingestellt und bis zum Ende des Semesters das Projekt TRACS verlassen haben so dass letztlich die Arbeit nur von einer Person durchgef hrt werden konnte Da bis zu jenem Zeitpunkt die Kommunikation innerhalb der Gruppe trotz mehrfacher Versuche und Einberufung von Treffen seitens des am Ende verbliebenen Mitglieds niemals richtig funktionierte ist es folglich auch zu mehreren Situationen gekommen wo angefangene Arbeit verwor fen werden musste da die entsprechenden Gruppenmitglieder nicht mehr zur Verf gung standen und grundlegende Informationen zum L sungsansatz anderweitig nicht existier ten Von der urspr nglichen Bese
351. eweils aktuellen Zustand zum SI und empf ngt und verarbeitet die Anweisungen die der SI als Reaktion auf den aktuellen Zustand zur cksendet Dieser Abschnitt des Berichtes befasst sich mit der Konzeptionierung und Entwicklung dieses Simulators Niklas Polke Arne Stahlbock 7 8 2 Anforderungen an den Simulator Im Projekt TRACS ist das Ziel des Simulators eine zus tzliche da nicht vollst ndige und anschauliche berpr fung der Funktionsweise und der Korrektheit des Steuerinter preters SI Des Weiteren ergibt sich erst durch das Vorhandensein des Simulators die M glichkeit f r den SI ein Gleisnetz wenn auch nur simuliert zu steuern Mehr zur Funktion des SI in Kapitel 7 5 auf Seite 171 Diese Ziele werden vom Simulator erf llt indem er ein beliebiges Gleisnetz aufge schrieben in einer Datei in TND Form auf ihm fahrende Stra enbahnen sowie die KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 314 Zust nde aller vorhandenen Hardwareteile visuell darstellt und deren Funktionsweise simuliert die Anweisungen des SI befolgt und ihm R ckmeldung ber den aktuellen Zustand des Systems gibt Die Anforderungen an den Simulator sind die folgenden die auch im weiteren Verlauf in Unterkapiteln n her erl utert werden Flexibilit t Simulation verschiedenster Gleisnetze Der Simulator muss flexibel jedes beliebige Gleisnetz das ihm in TND Form ber geben wird simulieren k nnen Dazu geh rt das Einlesen der TND Berechnung d
352. f rst i RST_AKTIV amp amp si_rst i RST_AKTIV if comp_debug printf ERROR SI has route d at state d while checker has it at state d n i si_rst i rst i retval 0 if tram_count i si_tram_count i if comp_debug printf ERROR SI has tram count for route d at d while checker has it at d n i si_tram_count i tram_count i retval 0 Y if left_queues si_left_queues if comp_debug KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 286 printf ERROR SI has left_queues at d while checker has it at d n si_left_queues left_queues retval 0 if rr lt pdata gt rd_data gt max_routes if si_shadow 4000 rr io ioseparated input 1 if comp_debug printf ERROR SI did not set reset bit for sensor d n 4000 rr retval 0 for i 0 i lt pdata gt rd_data gt max_queues i if qpl i si_qpl i if comp_debug printf ERROR SI has gpl d at d while checker has it at Yd n i si_qpl i qpl li retval 0 if queues i 1 amp amp si_queues i current_len 0 if comp_debug printf ERROR SI has queue d not empty while checker has it empty n i retval 0 else if queues i gt 1 amp amp si_queues i routes 0 queues i if comp_debug printf ERROR SI has queue d at d while checker has it at d n i si_queues i routes 0 queues i
353. fahren werden k nnen wie sie definiert wurden und alle Routenkonflikte fehlerfrei definiert wurden Die wiederverwendbare Steuerungssoftware ist nicht vom jeweiligen zu steuernden Gleis netz abh ngig und wird durch ausf hrliche Tests und Review des Programmcodes op tional berpr ft Weiter wird berpr ft ob die vom Compiler erstellten gleisnetzspezifischen Projektie rungsdaten eine sichere Steuerung des Gleisnetzes erm glichen Dazu wird das System als Transitionssystem modelliert In den Projektierungsdaten ist dabei definiert wann die Weichen und Signale wie geschaltet werden sollen Es wird vollst ndig berpr ft ob keine Transition dazu f hren kann dass eine Sicherheitsbedingung verletzt wird KAPITEL 6 VALIDIERUNGS VERIFIKATIONS UND TESTPROZESS 52 Nun erfolgt der letzte Schritt Dabei wird das fertige Steuerungssystem das aus wieder verwendbarer Steuerungssoftware gleisnetzspezifischen Projektierungsdaten Treibern und Hardware besteht ausf hrlich getestet Diese Tests sind erforderlich um zu ber pr fen ob das System auch nach der Integration mit den verwendeten Treibern und der verwendeten Hardware noch das korrekte Verhalten zeigt Demzufolge m ssen nun folgende Validierungs Verifikations und Testschritte aus gef hrt werden e Validierung einer TND Datei Die Validierung der Netzwerkbeschreibung wird im Abschnitt 6 2 beschrie ben Die Validierung der Routenbeschreibung wird im Abschnitt
354. finition entsprechen m ssen abgelehnt wer den e Bahnen Fahrt F hrt die Bahn auf normaler Strecke keine Weichen Kreuzungen Signale wie sie soll e Bahnen Fahrt ber Weichen F hrt die Bahn richtig ber Weichen D h f hrt sie am richtigen Ende von der Weiche herunter Schaltet sie passive Weichen beim Auffahren Entgleist sie beim spitzen Befahren wenn die Weiche im undefinierten Zustand ist Wird Auffahren auf nicht auffahrbare Weichen festgestellt e Bahnen Fahrt ber Kreuzungen F hrt die Bahn richtig ber eine Kreuzung e Bahnen Fahrt ber Sensoren Bahnen fahren ber Sensoren und es wird anhand des Strings der an die Treiber gesendet werden soll f r jede Sensorart gepr ft ob der richtige Output erfolgt e Bahnen Beachten von Signalen Halten Bahnen vor Stop Signalen Halten sie auch falls eine andere als die f r ihre Route ben tigte Richtung freigegeben ist Wird die Sichtweite eingehalten d h wenn ein Signal erst ganz sp t auf Stop schaltet f hrt die Bahn dann noch durch Funktioniert die Vorausschau ber mehrere Elemente e Bahnen Nicht auffahren Wenn eine Bahn hinter einer anderen herf hrt darf sie nicht auffahren KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 410 e Bahnen Kollisionen Beide Kollisionstypen werden inszeniert der Simulator muss das Auftreten fest stellen Insbesondere sind hier auch die Kreuzungsweichen zu beachten und der Fall dass eine Bahn im einem Zyklus schon ein Element
355. ftware oder Hardwareschnittstellen unabh ngig ist um ein konkretes SUT zu ver binden Interface Module Layer Das Interface Module Layer IFML besteht aus den Interface Modules IFMs IFMs im plementieren die Schnittstellenverfeinerung von der Schnittstelle der AMs zu der Schnitt stelle des konkreten SUT Die Abstraktion der Schnittstelle ist gerade umgekehrt d h sie wird von den Ausgaben des konkreten SUT zu den abstrakten AM Channels abgebildet Communication Control Layer Das Communication Control Layer CCL bertr gt die Ereignisse zwischen den AMs und den IFMs Beispielsweise k nnen verschiedene AMs Ausgaben generieren die in das gleiche Channel c bertragen werden Diese Ausgaben werden durch die Communication Control Layer zu den dazugeh rigen IFMS abgebildet und Channel c wird dann als ein KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 261 mapping via rttemlib or customised event mapping System Under Test SUT Abbildung 7 51 Aufbau des RT Testers Input Channel der AMs deklariert Testen mit dem RT Tester Das organisatorische Modell das oben beschrieben wird wird im Folgenden ber cksich tigt Das Testen von eingebetteten Systemen erfordert parallele Prozesse f r die Simulation von externen Systemen in der SUT Betriebsumgebung und die Stimulation von spezi fischen Ereignissen um die Test Durchf hrung zu kontrollieren und die SUT Reaktion auf Inputs die von der Testumgebung gegeben werden zu pr fen
356. g def static String usedRelations static ArrayList usedRelParts static ArrayList usedMarks static ArrayList markRelations static ArrayList usedSigPos static ArrayList signalClass static NGElementList sensorClass static NGElementList pointClass static NGElementList slipswitchClass static NGElementList crossingClass static NGElementList markClass static NGElementList badVersion static boolean true main args String void dataCollector static boolean defWriter static void extractSignalData static void extractSensorData static void extractPointData static void extractSlipSwitchData static void extractCrossingData static void extractMarkData static void tndComment static boolean blockEnd static boolean defBlock static boolean coordBlock static boolean sigPropBlock static boolean ptPropBlock static boolean slipSwitchBlock static boolean relBlock static boolean sigPosBlock static boolean routeBlock static boolean condBlock static boolean clearBlock static boolean ptConfBlock static boolean confBlock static boolean hwBlock static boolean buildTND static boolean createTNDFile static boolean Abbildung 7 12 Detailansicht Klassendiagramm TNDCreator In der TND ist es auch wichtig die verschiedenen Typen von Signalen Sensoren etc voneinander zu unterscheiden so dass diese Arbeit auch in dieser
357. g 7 11 NGElementList Abbildung 7 9 NGLines Abbildung 7 10 und NG System Ab bildung 7 14 sind Hilfsklassen Die brigen Klassen sind die Hauptklassen des Konver ters Die Klasse TracsDXF2TND Abbildung 7 13 stellt letzten Endes das eigentliche Programm dar welches die Konvertierung als Ganzes durchf hrt Die Klassen DXF Se KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 92 Klassendiagramm TRACS Netzgraph DXF Separator ConfigReader a NGDataCollector TNDCreator hei nn u TracsDXF2TND a es NGElementList NGSystem NGElement Abbildung 7 6 vereinfachte Darstellung des Klassendiagramms fiir den CAD TND Konverter parator Abbildung 7 7 NGDataCollector Abbildung 7 8 und TNDCreator Abbil dung 7 12 werden von der zuvor genannten Klasse nacheinander aufgerufen Sie sind aber auch als eigenst ndige Programme nutzbar so dass mit deren Hilfe einzelne In formationen anzeigbar sind bzw Teilschritte einzeln durchgef hrt werden k nnen was insbesondere f r das Debugging Sinn ergibt Daher haben auch alle drei Klassen eine eigene Main Methode Die Klasse ConfigReader wird von der Klassen DXF Separator aufgerufen um ggf Initia lisierungsdaten einzulesen Urspr nglich sollte sie auch von den brigen Hauptklassen aufgerufen werden jedoch ergab sich hier letzlich kein wirklicher Anwendungszweck so dass diese Idee wieder verworfen wurde Die Klassen NGElement NGLines und NGEle mentLis
358. g Was das Projekt TRACS betrifft handelt es sich damit auch um die abschlie ende Version Arne Stahlbock 7 1 6 Reflexion Anmerkung Da dieser Textabschnitt nicht direkt nach Abschluss der Arbeit in die ser Gruppe angefertigt wurde sondern gut 1 5 Jahre danach kann es sein dass einige Umst nde hier nicht mehr so umfassend behandelt werden wie es bei einem fr her ent standenen Text der Fall gewesen w re Die DSL Gruppe arbeitete als solche nicht einmal ein ganzes Semester zusammen sie wurde im Laufe des ersten Semesters eingerichtet und am Ende dessen auch wieder aufgel st Bez glich ihrer Aufgabenerf llung ist festzuhalten dass am Ende des ersten Semesters auch eine zu diesem Zeitpunkt hinreichende Version der TND erstellt worden war so dass ein weiterer Bedarf an einer kompletten Arbeitsgruppe f r das Projekt nicht mehr bestand und die Aufl sung somit zu Recht erfolgte um die so freiwerdende Ar beitskraft an anderer Stelle einsetzen zu k nnen Die in der Folge dennoch gelegentlich n tigen Arbeiten siehe auch den vorigen Abschnitt konnten im Wesentlichen auch von einer Person erledigt werden die zu diesem Zweck ihre eigentliche T tigkeit unterbrach Probleme innerhalb der Gruppe als es noch eine Gruppe war existierten nicht Be z glich der Zusammenarbeit mit anderen Gruppen ist zu sagen dass die DSL Gruppe gerade im ersten Semester weitgehend unabh ngig von anderen Gruppen arbeitete was zusammen mit der Tatsac
359. gen Sache besch ftigt h tten aber dies ist eine andere Sache Wie dem auch sei die gewonnene Erkenntnis auf der Netzgraphseite bei dieser An gelegenheit war jedenfalls die dass das Einarbeiten neuer Leute in ein bestehendes Teil Projekt viel Zeit in Anspruch nehmen kann welche vielleicht besser in L sung der eigentlichen Aufgabe gesteckt werden sollte Eine Aufstockung der Gruppenst rke sollte immer rechtzeitig erfolgen und nicht erst wenn die Arbeit im vollem Gange ist da diese vermeintliche Verst rkung letzlich wenig bringt und unter Zeitdruck eher dazu f hrt dass sich die Fertigstellung des gesamten Projektes eher noch mehr verz gert Da zwischenzeitlich auch in anderen Gruppen Personalprobleme aufgetreten waren und der Gesamt Zeitplan daher als immer kritischer anzusehen war je weiter die Zeit vor anschritt w re es auch fraglich gewesen ob nach Ende der Compilerarbeit wirklich eine vereinte Netzgraph Compiler Gruppe in dieser Form die Arbeit am Netzgraphen wieder aufgenommen h tte Wahrscheinlicher w re es gewesen dass allenfalls zwei Personen am Netzgraphen weitergearbeitet h tten und der Netzgraph Konverter nicht in dieser Form zustandegekommen w re was unter Umst nden auch den TND Builder in Frage gestellt h tte da dieser vom Netzgraph CAD TND Konverter mehr oder weniger abh ngig ist 7 2 5 6 Andere Probleme Aber auch an anderer Stelle wurde zu viel Zeit verloren Die Frage bez glich der m gli chen Verwen
360. genaue Beschreibung findet sich in Abschnitt 7 4 auf Seite 135 4 2 1 3 Steuerinterpreter W hrend die bisherigen Schritte nur Informationen ausgewertet und bersetzt haben ist der Steuerinterpreter zust ndig f r die Ausf hrung der generierten Anweisungen Es handelt sich hierbei um eine generische Steuerungssoftware die nur im Zusammenspiel mit den vom Compiler erzeugten bin ren Projektierungsdaten sinnvoll benutzbar ist da diese die konkreten Steuerungsinformationen enthalten Eine genaue Beschreibung findet sich in Abschnitt 7 5 auf Seite 171 4 2 1 4 Treiber Die letzte Komponente sind schliesslich die einzelnen Hardwaretreiber die am Ende des Generierungsprozesses ins Steuerungssystem eingebunden werden Sie sind das entschei dende Glied in der Kommunikation zwischen Steuerinterpreter und den verschiedenen Hardwarelementen im Gleisnetz und daf r verantwortlich dass die vom Steuerinterpre ter gegebenen Anweisungen korrekt umgesetzt werden 4 2 2 Generierte Anteile Zwar sind die wiederverwendbaren Komponenten der Schl ssel von TRACS allerdings werden im Verlauf des Generierungsprozesses auch diverse gleisnetzspezifische Kompo nenten automatisch generiert die die konkreten Daten des jeweiligen Gleisnetzes wie derspiegeln Nur mit diesen k nnen die generischen Komponenten schliesslich sinnvoll eingesetzt werden 4 2 2 1 TND Zwischendarstellung Unsere Tram Network Description enth lt den kompletten Aufbau eines Gleisnetz
361. generierten Projektierungsdaten f r den Route Dispatcher und die Route Controller und generiert aus diesen die Pro jektierungsdaten f r den Safety Monitor Wie dies im einzelnen funktioniert wird jetzt beschrieben Als erstes wird in dieser Funktion die Anzahl der Timer berechnet Dann werden die sicheren Befahrungskonstellationen ermittelt Dies geschieht mit folgender Hilfsfunktion struct occ_conf_t getSafe0ccConfs struct rd_data_t rdd KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 167 Als Eingabe erh lt sie die Route Dispatcher Projektierungsdaten Hier werden zun chst alle Befahrungskonstellationen ermittelt die theoretsich m glich sind Mit der Hilfsfunk tion int isValidCombo u_int32_t combo struct rd_data_t rdd werden dann alle Konstellationen einzeln berpr ft ob sie auch sicher sind Diese siche ren Befahrungskonstellationen werden dann wieder zur ckgegeben und mit der Funktion struct sm_condition_t getSmConditionByOcc struct occ_conf_t occ struct rc_data_t rcdata struct section_t syntree werden die Projektierungsdaten f r den Safety Monitor anhand der sicheren Befahrungs konstellationen erzeugt indem f r jeden Zustand alle Zust nde der einzelnen Hardwa reelemente eingetragen werden Dann werden ber mehrere Schleifen ber alle Hardwaretypen die zugeh rigen Timeouts erstellt und eingetragen Dies geschieht mit folgender Hilfsfunktion struct hw_timeout_t getHwTimeout struct hw_timeout_t newhw
362. gerichtet e Arbeitsgruppen In diesen Gruppen wurde die eigentliche Entwicklungsarbeit geleistet e Projektplenum W chentlich in der vorlesungsfreien Zeit seltener fand ein Projektplenum statt e Zeitplanung F r eine erfolgreiche Arbeit ist eine Zeitplanung unerl sslich e Einsch tzung Zum Schluss darf eine Bewertung nicht fehlen 9 2 2 Verwaltungsgruppen Zum Beginn des Projektes wurden sogenannte Verwaltungsgruppen gegr ndet so wie es bei den meisten Hauptstudiumsprojekten im Studiengang Informatik an der Universit t Bremen blich ist da auch die Organisation selbst ein Teil des Projektes ist und somit in studentischer Hand liegen soll Es wurde gleich zu Beginn klargestellt dass von Seiten der Projektbetreuung gew nscht wird dass die Gruppen rotieren sollen und jeder Teilnehmer m glichst einmal berall und vor allem beim Projekt Management mitgewirkt haben soll Dass dies eigentlich kaum m glich war wurde alleine schon an der Anzahl der Projektteilnehmer deutlich Die im Projekt TRACS vertretenen Verwaltungsgruppen sind die folgenden e Projektmanagement e Projekttag Organisation KAPITEL 9 BEWERTUNG 443 e Web e Doku e Sysadmins e Service und Technik 9 2 2 1 Projektmanagement Die vermeintlich wichtigste Verwaltungsgruppe war jene fiir das Projektmanagement kurz PM Das PM war daf r verantwortlich f r jedes Plenum eine Tagesordnung zu er stellen welche die zu behandelnden Themen beinhalt
363. gesamten Arbeit als Grundlage dient zu k mmern dies wurde erst zum Ende des zweiten Semesters begonnen Der Simulatorgruppe ist aufgefallen dass sie sich w hrend des Semesters ihr eigenes Weltmodell zugrunde gelegt hat welches aber mit keiner ande ren Gruppe abgesprochen war und welches auch nirgendwo genau dokumentiert wurde Auch dies kostete die Simulatorgruppe Zeit es nachzuholen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 424 7 8 8 1 3 Konzept erst w hrend der Implementierung aufgestellt Die Simu latorgruppe hat f r einzelne Bereiche immer erst ein Konzept aufgestellt bevor mit der Implementierung angefangen wurde Doch es fehlte ein Gesamtkonzept f r die Zu sammenh nge der Bereiche Die einzelnen Teilkonzepte wurden so flexibel gehalten dass unser Vorgehen erfreulicherweise keine gro en Probleme f r uns aufgeworfen hat Dennoch h tten wir mit einem Gesamtkonzept in der Tasche noch strukturierter und effektiver arbeiten k nnen 7 8 8 1 4 Benutzung von Compiler Konstruktions Werkzeugen nicht recht zeitig berdacht F r den Einlesevorgang der TND ben tigen wir einen Compiler Diesen haben wir zuerst selbst programmiert ohne Generierungs Tools Erst als be reits wenige Personenwochen an Zeit vergangen waren fiel uns der Zeitaufwand solch eines Compilers auf und wir wechselten um und entschieden uns f r die Benutzung so genannter Compiler Konstruktions Werkzeuge Lexer und Parser Generatoren Dies h tte von unserer Seite
364. gi and HW g2 at distance 16788 INFO Report to SI status g2 toggleon INFO Cannot send report status g2 toggleon Driver unknown INFO Time 1111183956417 INFO Trying to move 139 00044 steps INFO Tram TramO is now located Head on TE 2 between HW g2 and HW g3 at distance 226 Tail on TE 1 between HW g1 and HW g2 at distance 16927 Der Kopf der Bahn berf hrt also das Element l st den Sensor aus da kein im Test kein Treiber angeschlossen war kann auch keine Meldung erfolgen und bewegt sich weiter KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 414 7 8 6 5 Testergebnisse Bei den verschiedenen Tests wurde eine Reihe von Fehlern im Programm gefunden die dann auch behoben werden konnten Momentan sind keine weiteren Fehler bekannt was nat rlich nicht automatisch hei t dass es keine mehr gibt Vor allem nach Anschluss des SI traten noch einmal einige Fehler zu Tage die erst im l ngeren Betrieb erkennbar waren und l ngerer Betrieb war ohne SI quasi nicht m glich es h tte dann ein Mensch st ndig als Ersatz SI agieren und via telnet Kommandos an den Simulator schicken m ssen Auch diese Fehler konnten zeitnah behoben werden Da das System im Vorfeld des Projekttages und auch an diesem selbst jeweils ber ei ne Dauer von mehreren Stunden problemlos lief und erst durch Befehl des Bedieners gestoppt wurde darf mit relativ hoher Sicherheit angenommen werden dass keine gra vierenden Fehler mehr vorhanden sind Arne Stahlboc
365. gsvariable generierten Wert der andere stellt das konstante Maximum f r seed dar Es kann dann ein Code wie der folgende benutzt werden increase seed go to next test case gen_left_queues t if gen_left_queues max_left_queues gen_left_queues 0 gen_qpl if gen_qpl max_qpl gen_qpl 0 gen_rr t if gen_rr max_rr gen_rr 0 gen_rstt if gen_rst max_rst gen_rst 0 i 0 gen_queues i 1 while gen_queues i max_queues i amp amp i lt pdata gt rd_data gt max_queues if i pdata gt rd_data gt max_queues 1 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 280 stop_tests 1 i else gen_queues i 0 gen_queues i 1 1 i gt Es d rfte relativ leicht erkennbar sein was hier geschieht Es wird ein gen xyz erh ht entspricht dem angesprochenen seed und falls dieser Wert sein Maximum erreicht hat wird er auf Null zur ckgesetzt und stattdessen ein anderer Wert erh ht So erreicht man letztlich dass jede Wertekombination im Laufe des Gesamtablaufs einmal vor liegt und ganz am Ende wird eine Stop Variable auf 1 gesetzt um eine bergeordnete whileSchleife zu verlassen Die Eingaben an Orakel und SUT werden dann einfach gesetzt mit set inputs reset_shm set_tram_count set_left_queues gen_left_queues set_qpl gen_apl set_rst gen_rst set_rr gen_rr for i 0 i lt pdata gt rd_data gt max_queues i
366. gt lt hwdef gt lt crossdef gt lt senstype gt lt SENSID gt lt SENSID gt lt RRSENSORS gt lt TDSENSORS gt lt TGSENSORS gt lt SDSENSORS gt lt SGSENSORS gt lt pointtype gt lt POINTID gt lt POINTID gt lt SLPOINTS gt lt SRPOINTS gt lt LRPOINTS gt lt SLRPOINTS gt lt sigtype gt lt SIGID gt ae lt SIGID gt ou lt LSIGNALS gt lt SSIGNALS gt lt RSIGNALS gt lt SLSIGNALS gt lt SRSIGNALS gt lt LRSIGNALS gt lt SLRSIGNALS gt lt ROUTES gt lt ROUTEID gt lt ROUTEID gt lt MARKS gt lt MARKID gt lt MARKID gt lt HWCLASSES gt lt HWID gt lt HWID gt lt CROSSINGS gt lt CROSSID gt lt CROSSID gt lt SIGNAL_PROPERTIES gt lt sigpropdef gt lt SIGID gt lt WAIT_STRAIGHT gt lt WAIT_LEFT gt lt WAIT_RIGHT gt lt RR_STRAIGHT gt lt RR_LEFT gt lt RR_RIGHT gt lt SWITCHTIME gt lt POSINT gt ANHANG A TND GRAMMATIK 457 lt ptpropblock gt lt ptpropdef gt lt slipswitchblock gt lt slipswitchdef gt lt relblock gt lt reldef gt lt relation gt lt relnone gt lt een gt lt elementid side gt lt sensid side gt lt crossid side gt lt cross side gt lt pointid side gt lt sigposblock gt lt sigposdef gt lt routeblock gt IH lt rtdef gt i lt condblock gt lt conddef gt Aut
367. gung wird die Orientierung eines TEs bestimmt MaxParam Parameter werden zur genauen Positionsbestimmung auf einem TE ben tigt Es handelt sich um Ganzzahlwerte zwischen 0 und MaxParam Zwischen den Parametern und 7 1 ist immer der gleiche Abstand dieser ist f r alle TEs der gleiche und wird zentral festgehalten Eine Fortbewegung der Bahn KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 345 ausgedr ckt in der Differenz der Parameter ist mindestens 1 pro Runde eine kleinere Einheit gibt es nicht Aus diesem Grund muss die Einheit so klein gew hlt werden dass die Simulation eine fl ssige Bewegung darstellt Die Gr e dieser Einheit wirkt sich weder auf die ben tigte Speichergr e des Simulators noch auf die Rechenzeit aus und kann insofern fast beliebig gew hlt werden Die dritte f r die Bewegung der Bahnen notwendige Klasse hei t Tram Stra Benbahn Sie stellt ein aktives Element im Simulator dar Sie entscheidet nach eingestelltem Setup selbstst ndig ob sie f hrt oder nicht F r die Fortbewegung an sich ben tigt eine Bahn folgende Informationen Kopf Der Kopf beschreibt die Spitze der Tram Zwischen ihm und dem Ende be findet sich die gesamte Tram Eine Tram bewegt sich immer in Richtung des Kopfes x TE Das TrackElement auf dem sich der Kopf der Tram befindet x Param Der Parameter der angibt wo auf dem TE sich der Kopf der Tram befindet Direction Die Richtung in die sich der Kopf der T
368. h rende Kreuzungen einer Hardwareklasse zugeordnet werden k nnen da dies diejenigen Elemente sind ber die der Steuerinterpreter die tats chliche Steuerung vornehmen bzw zur Laufzeit Informationen ber den Zustand einholen kann Beispiel c1 g101 g102 g103 g104 g105 g201 g202 g203 g301 g302 g303 g304 g401 g402 g403 g404 g405 g406 g100 g200 g300 g400 c2 s2 s3 si s4 w2 w3 wi w4 Ein sinnvolles Beispiel ist hier weniger gut m glich 7 1 3 3 Typregeln ber die beiden Grammatiken hinaus gibt es ferner noch diverse Typregeln die innerhalb eines kompletten Dokumentes erf llt sein m ssen damit es der Sprachdefinition von TND gen gt Diese werden nun genannt e Im DefBlock darf jede PointID SigID SensID MarkID RouteID CrossID oder HWID nur einmal vorkommen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 78 e Generell f r alle Bl cke au er dem DefBlock Jede PointID SigID SensID Mar kID RouteID CrossID oder HWID die in einem der Bl cke vorkommt muss auch im DefBlock vorkommen e Im CoordBlock muss jede PointID SigID SensID MarkID oder CrossID die im DefBlock definiert worden ist genau einmal vorkommen e Im SigPropBlock muss jede SigID die im DefBlock definiert worden ist genau einmal vorkommen e Im SigPropBlock d rfen den SigIDs nur Wait bzw RR Anzeigen zugeordnet wer den mittels Vorkommen der entsprechenden Token deren Richtung das zugeh ri ge Signal auch hat Bs
369. h das zugeh rige Signal im Zustand GO befindet und nicht erreichbar ist wenn sich das zugeh rige Signal im Zustand STOP befindet MODULE main VAR si GO STOP s2 GO STOP ASSIGN init s1 GO init s2 STOP next s1 case si STOP GQ si GO STOP esac next s2 case s2 STOP GQ s2 GO STOP esac DEFINE gi_reachable case si GO Sally si STOP 0 esac g2_reachable case s2 GO a es s2 STOP 0 esac safe si GO amp s2 GO INVARSPEC safe INVARSPEC gi_reachable amp g2_reachable SPEC AG safe SPEC AG gi_reachable amp g2_reachable SPEC AF gi_reachable KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 212 SPEC AF g2_reachable Die Bedingung safe ist wahr wenn die Signale s1 und s2 nicht gleichzeitig auf GO gesetzt sind Mit der folgenden Invariante wird berpr ft ob dies in allen Zust nden des Systems gilt INVARSPEC safe Die Eigenschaft kann alternativ auch folgenderma en spezifiziert werden SPEC AG safe Die weiteren Eigenschaften berpr fen ob die beiden Sensoren niemals gleichzeitig er reichbar sind und ob beide Sensoren in jedem Fall irgendwann erreicht werden k nnen 7 6 3 2 1 Ausf hren von NuSMV Die definierten Eigenschaften k nnen nun au tomatisch berpr ft werden Dies geschieht durch Eingabe des folgenden Befehls wobei mc_bsp smv der Name des Beispielprogramms ist NuSMV mc_bsp smv In der Ausgabe kann man erkennen da
370. h nicht um die Freigabe von nicht mehr genutztem Speicher k mmern da es in Java Meinen sog Garbage Collector gibt der diese Auf gabe automatisch erledigt Also gibt es in Java Meine M glichkeit weniger Programmierfehler zu machen vgl Kr 03 S 39 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 326 Portabilitat Java stellt im Vergleich zu C standardm ig eine weitaus gr ere Klas senbibliothek zur Verf gung die die gleichen Funktionen auf allen Platt formen verwirklicht Z B sind Netzwerkprogrammierung Serialisierung und Grafikprogrammierung in der Basis Version von Java verfiigbar Diese drei Elemente waren auch fiir den Einsatz in unserem Simulator geplant auf Serialisierung wurde dann sp ter verzichtet Ein weiterer Unterschied ist die Portabilit t des kompilierten Quellcodes in Java Der Quellcode wird in Bytecode bersetzt welcher von einer Java Virtual Machine auf einer beliebigen Plattform interpretiert werden kann Im Gegensatz dazu ist es bei C Programmen notwendig den Code f r eine neue Plattform neu zu kompilieren da der kompilierte C Code direkt auf die benutzte Plattform zugeschnitten wird vgl beide Unterschiede mit Krii03 S 45 Grafikprogrammierung Da die Grafikprogrammierung einen recht gro en Teil in unserem Simula tor darstellt sollte man sich mit diesem Thema noch genauer auseinander setzen Wie oben angesprochen steht mit Java und ihren Klassenbiblio the
371. h wieder gefangen und es lief dann auch wieder besser aber durch st ndige nderungen war nur selten ein Ziel zu schen Am Ende ist aber dennoch das Ziel erreicht worden mit der Zufriedenheit der Gruppe Die Zusammenarbeit innerhalb der Gruppe verlief vorbildlich auch wenn nicht schwer mit zwei Mann Die Zusammenarbeit mit den anderen Gruppen war durchaus erfolgreich Insbesondere mit den Leuten vom Steuerinterpreter wurde untereinander viel ausge tauscht Immer wenn man einen Ansprechpartner einer anderen Gruppe gebraucht hat hat sich auch jemand gemeldet Als Fazit bleibt zu sagen da man viel gelernt hat insbesondere was die Zusammenarbeit mit Anderen angeht meistens funktioniert dies aber leider manchmal auch nicht Mit unserem Ergebnis sind wir jedenfalls zufrieden Waldemar Wockenfu KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 171 7 5 Steuerinterpreter 7 5 1 berblick Der Steuerinterpreter ist eine zentrale Komponente des Projektes die den generischen Teil der Steuerungssoftware bildet und als solches das Gleisnetz steuern muss An ihn werden folgende Anforderungen bez glich der Funktionalit t gestellt e Leiten von Z gen durch einen Gleisnetzabschnitt e Kommunikation mit den Gleisnetzelementen Weichen Sensor Signal e Reaktion auf Sicherheitsverletzungen defekte Hardware unsichere Freigaben von Routen e Vermeidung der im FTA siehe Abschnitt 8 2 gefundenen potenziellen Bedrohun gen e Universelle Verwendbarke
372. haben Sie sollte den Zustand der Hard ware berpr fen daraufhin dementsprechend mit der Hardware kommunizieren und dabei die entsprechenden Werte im Shared Memory zur ckliefern e Treibername_callback Optional kann ein Treiber auch innerhalb dieser Funk tion unabh ngig von Ver nderungen im Shared Memory t tig werden An das Ende eines Treibers geh rt ein Aufruf des Makros DRV_CLASS_INIT welches als Parameter eine Klassen ID und den Treibernamen erh lt Durch das Makro wird eine Struktur mit Pointern auf die einzelnen Funktionen erzeugt die vom Treiberframework ben tigt wird um die einzelnen Treiber ansteuern zu k nnen Beim Schreiben von Treibern ist darauf zu achten dass kein blockierendes I O verwen det wird Die oben genannten Funktionen sind innerhalb k rzester Zeit abzuarbeiten und es darf nicht auf irgendwas gewartet werden Bei Betriebssystemaufrufen ist zu berpr fen ob sie die Echtzeiteigenschaften zu sehr negativ beeinflussen Optimaler weise greift der Treiber direkt auf die I O Ports also direkt auf die Anschl sse wo die Hardware angeschlossen ist ohne Kernelbeteiligung zu 7 5 4 1 2 Besonderheiten des Signaltreibers Wenn mehr als ein Bit gesetzt ist dann wechselt der Treiber in den Fehlerzustand mit der Ausnahme dass eine REQUEST RECEIVED Anzeige zus tzlich zu einer anderen Anzeige gefordert werden kann Au erdem wechselt der Treiber in den Fehlerzustand wenn eine durch die jeweilige Signalart nicht da
373. he dass zu diesem Zeitpunkt noch ein Weltmodell fehlte dazu f hrte dass die erste Version der TND nicht alle sp ter noch aufkommenden Anforde rungen erf llte Hier w ren also andere Arbeiten Erstellung des Weltmodells Sammlung von Anforderungen an die zu entwickelnde Sprache vor der Erstellung der TND n tig gewesen die von der DSL Gruppe im Bezug auf das Weltmodell auch dem brigen Projekt zu diesem Zeitpunkt nicht erkannt worden waren Nach dem Aufkommen weiterer Anforderungen in den sp teren Semestern konnte die TND jeweils relativ schnell auf einen neuen Stand gebracht werden Hier wurden dann KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 81 auch die jeweiligen Forderungen der anderen Gruppen relativ klar kommuniziert was ebenfalls im ersten Semester weitgehend ausblieb Insgesamt wird dennoch ein positives Fazit gezogen die Aufgaben sind erfiillt worden auch wenn eine andere Vorgehensweise m glicherweise schneller gewesen w re Arne Stahlbock KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 82 7 2 Netzgraph und TND Erzeugung 7 2 1 berblick Der Netzgraph ist die elektronische Beschreibung eines Gleisnetzes d h er enth lt eine vollst ndige Aufz hlung aller vorhandenen Elemente Sensoren Signale Weichen die Nachbarschaftsbeziehungen zwischen Elementen Gleisabschnitte und letztendlich auch topologische Informationen Koordinaten Ausrichtungen Der Netzgraph enth lt nicht die Verschlusstabellen also die rou
374. hen relevanten DXF Codes der Rest kann getrost ignoriert werden 999 Dateianfang 0 bezeichnet irgendwelche Steuerabschnitte Objekttypen etc SECTION ENDSEC ENTITIES BLOCKS TABLES LINE CIRCLE POINT TEXT EOF 8 Name des Layers bei uns signals sensors track oder gt others 10 20 30 bezeichnen im Allgemeinen Startpunkt Koordinaten X Y Z oder Mittelpunkt oder INSERT Point abh vom Typ des Objektes 11 21 31 wie oben nur diesmal Endpunkt 40 Radius CIRCLE oder Text H he TEXT 41 Text Breite width TEXT 459 ANHANG B DXF DATEI FORMAT 460 50 Start Winkel ARC oder Text Rotation oder INSERT Rotation 51 End Winkel ARC 1 Text Value 7 Text Style Name def STANDARD 71 Text Geneartion Flags opt 72 Horizontal Text Justification Type def 0 73 Fixed Length 39 Thickness Text 2 INSERT Blockname Blockname vor Flags Koords in BLOCK SECTION 3 Blockname nach Flags Koords in BLOCK SECTION 41 42 43 X Y Z Scale Factors def 1 B 1 2 Erl uterungen In unserem Fall wird es au er dem Entity INSERT vermutlich nur noch ein LINE in der ENTITIES SECTION geben Ggf k nnen noch Text Bl cke eingef gt werden welche aber nicht weiter ausgelesen werden Der Rest wird in der BLOCK SECTION definiert Hier gibt es nur LINE CIRCLE TEXT und INSERT als Entities Zu jedem Entity geh rt auf jeden Fall eine X Y Z Koordinate Dies gilt auch f r alle I
375. hend in den Ist Zustand Bereich des Shared Memory geschrieben Art und Reihenfolge der Sti mulationen bestimmen hierbei den Zustand in den der Testling bergeht Da die Spezifikation nicht auf Events basiert sondern durch Bedingungen ber Shared Memory Werte gesteuert wird sind zus tzliche Funktionen notwendig die in Abh ngig keit der Projektierung eines Safety Controllers Alle Shared Memory Bedingungen der Spezifikation wahr oder falsch werden lassen bzw das Shared Memory entsprechend mo difizieren Diese Funktionen entsprechen dann den in Cho78 verwendeten Events einer Spezifikation Fin Testtrace ist dann eine Folge von Aufrufen dieser Funktionen Um auch interne berg nge des Testlings berdecken zu k nnen muss das interne Al phabet des Testlings bekannt sein Dies sind f r einen TRACS Safety Controller insbe sondere die internen Zustandsfelder f r Befahrungskonstellationen der einzelnen Routen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 307 Diese k nnen nur intrusiv stimuliert werden und sollten daher aus der Spezifikation in jedem Tesfall impliziert werden Helge L ding 7 7 7 5 Testchecker Um die Reaktionen eines Testlings auf die Stimulationen des Testgenerators pr fen zu k nnen ist ein Testchecker notwendig der die Ausgaben des Testlings berwacht und sie auf Inkonsistenzen zur zugrundeliegenden Spezifikation berpr ft Hierzu wird die wie oben beschrieben hergeleitete Spezifikation innerhalb des Testche
376. hkeit zu bieten dass einige Klassen die gleichen Methoden erben implementieren wurden in Java die Interfaces eingef hrt vgl Kr 03 38 Da in unse rem Simulator verschiedene Hardware Elemente simuliert werden sollen die recht viele Gemeinsamkeiten untereinander haben ist eine Mehrfachverer bung wiinschenswert Jedoch kann auch mit Einfachvererbung und Interfaces das gleiche Ergebnis erzielt werden e Fazit Es wird festgestellt dass die genannten Vorteile von Java bei der Programmie rung des Simulators zum Tragen kommen und die Nachteile von Java vernach l ssigbar sind Somit ist Java die geeignetere Wahl f r unseren Simulator 7 8 4 1 2 Schnittstellen des Simulators Der Simulator hat lediglich zwei Schnitt stellen zu Arbeitspaketen anderer Gruppen Die erste Schnittstelle ist die im Projekt TRACS entwickelte Beschreibungssprache TND die andere ist die Kommunikation mit dem Steuerinterpreter e Schnittstelle TND Das Gleisnetz welches simuliert werden soll liegt im TND Format vor Unser TRACS Compiler der dieses Format einliest und f r die anderen Arbeitsgruppen weiter verarbeitet ist in C geschrieben er k nnte also nur direkt Anwendung im Simulator finden wenn dieser C verwenden w rde W rde der Simulator aber in Java geschrieben werden so gibt es zwei M glichkeiten um das TND Format einzulesen Die erste M glichkeit w re einen zus tzlichen Compiler zu schreiben der den Output des TRACS Compil
377. hler wurde erkannt Anmerkungen Da Signale der Typen SL SR und LR nur je zwei Zust nde kennen ist der jeweils dritte Zustand der nicht der Hardware entspricht als nicht definiert anzusehen und bei einer entsprechenden Anforderung muss der Treiber in einen Fehlerzustand wechseln KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 181 7 5 3 1 6 Timer Diese Spezifikation gilt fiir Timer mit festgelegter Laufzeit Eingabebereich Der Eingabebereich fiir einen Timer dient dazu ihn zu starten und dabei zurtickzusetzen Bit 0 Anforderung fiir Timer starten Bit 15 Anforderung in einen Fehlerzustand zu wechseln und die Ausf hrung zu beenden Die Bits 1 14 sind nicht definiert und miissen vom Treiber ignoriert werden Ausgabebereich Der Ausgabebereich gibt den aktuellen Zustand des Treibers an Bit 0 Timer l uft Bit 1 Timer ist abgelaufen Bit 15 Fehlerzustand OFF Die Bits 2 14 sind nicht definiert und miissen vom Steuerinterpreter ignoriert werden Der Timer hat initial kein Bit gesetzt Sobald das Startbit gesetzt ist wird der Timer gestartet und Bit 0 gesetzt und das Bit 0 im Eingabebereich gel scht Ist der Timer abgelaufen wird Bit 0 gel scht und Bit 1 gesetzt Diese Timer werden intern f r den SI im Treiberframework verwaltet Durch die zur Compilierzeit vorliegenden Informationen wird die Laufzeit festgelegt 7 5 3 2 Verbindung zur Hardware In diesem Abschnitt geht es darum ein paar M glichkeiten darzustellen wie die A
378. hnung entspricht wird berpr ft indem der Simulator aus der TND Netzwerkbeschreibung eine Visualisierung des Gleisnetzes erstellt Nun kann ber pr ft werden ob diese Visualisierung und der Netzgraph auch ein identisches Gleisnetz wiedergeben Details dazu wie diese Visualisierung erstellt wird sind im Abschnitt 7 8 auf Seite 313 zu finden e Ob der Compiler f lschlicherweise Bin rdaten liefert die zu Kollisionen oder Ent gleisungen f hren k nnen und nicht der Eingabe TND entsprechen wird durch Model Checking berpr ft Details dazu sind im Abschnitt 7 6 auf Seite 203 zu finden Um zu vermeiden dass das Steuerungssystem eine nicht den Projektierungsdaten ent sprechende Anweisung gibt oder eine in den Projektierungsdaten geforderte Anweisung unterl sst m ssen die Ursachen die dazu f hren k nnen ausgeschlossen werden Ob die im Folgenden angegebenen Ursachen auftreten wird durch ausf hrliche Tests berpr ft Details zu den Tests sind im Abschnitt 7 7 auf Seite 255 zu finden e Hardware Fehler am Steuerungssystem e Treiber Fehler e SI Fehler e Fehler in Betriebssystem oder Systemumgebung Ob das Steuerungssystem bei einem erkannten Ausfall oder Defekt eines Hardwareele ments alle betroffenen Signale auf STOP schaltet wird ebenfalls durch Tests berpr ft Durch Tests wird auch berpr ft ob Defekte am Steuerungssystem beispielsweise durch Softwareprobleme wie Deadlocks oder durch Hardwaredefekte existieren
379. hrscheinlichkeit beim Simulator so gering wie m glich zu halten sollten folgende Aspekte beachtet und befolgt werden e bersichtliche Struktur Eine bersichtliche gut durchdachte m glichst einfache und selbsterkl rende Struktur kann einerseits im Voraus die Fehlerquellen deutlich vermindern und an dererseits die Implementierung erleichtern was wiederum indirekt weniger Fehler verursacht Auch im Falle eines Tausches von Projektteilnehmern erleichtert eine gute Struktur diesen den Einstieg und mindert auch hier die Fehlerursachen e Gr ndliche Tests Die einzelnen Module und Funktionen Methoden des Simulators sollen so gr nd lich durch Tests auf ihre Funktionsweise hin berpr ft werden dass Fehler m g lichst ausgeschlossen werden k nnen Ziel dieser Tests ist jedoch nicht eine Veri fikation des Simulators welche eine korrekte Funktionsweise beweisen w rde Im Wesentlichen soll sichergestellt werden dass die oben im Abschnitt Berechnung der Simulation 7 8 2 2 beschriebenen Reaktionen korrekt ablaufen dass die gra fische Darstellung funktioniert und dass die Treiber zur Anbindung an den SI wie vorgeschrieben reagieren Wie genau diese Anforderungen auch umgesetzt werden es kann bei der Auswertung von auftretenden Fehlern bei der Anwendung des Simulators in Kombination mit dem Steuerinterpreter nie ausgeschlossen werden dass der Fehler beim Simulator liegt Der Simulator stellt jedoch nur eine untergeordnete Testm gli
380. ht F r alle Typen gilt dass sie defekt sein k nnen wobei ein Defekt nicht zwangsl ufig vom Steuersystem zu erkennen ist Ebenso k nnen sie abgeschaltet werden Jeder Sensor hat eine Verz gerung die zwischen tats chlicher Ausl sung durch eine Bahn und dem Zeitpunkt der R ckmeldung an das Steuersystem gilt 2 3 2 3 Signale Ein Signal ist ein Element das sich r umlich nicht auf dem Gleis sondern nur in dessen N he befindet Es ist jedoch genau wie ein Sensor einem bestimmten Punkt auf dem Gleis zugeordnet Ein Signal ist ein Anzeigeelement das dem Fahrer Anweisungen gibt M gliche Anweisungen sind e Fahrt nicht freigegeben Stop e Fahrt geradeaus freigegeben Go straight e Fahrt nach rechts freigegeben Go right e Fahrt nach links freigegeben Go left e Warten geradeaus Wait straight e Warten rechts Wait right e Warten links Wait left Ein Signal verf gt immer ber die M glichkeit Stop zu zeigen sowie ber eine der drei Go Varianten Es kann zus tzlich weitere Go Varianten und oder Warten Varianten haben wobei Warten Varianten nur f r diejenigen Richtungen vorhanden sein k nnen f r die KAPITEL 2 DIE DOMANE 23 auch ein Go existiert Ein Signal mit zwei Schaltm glichkeiten wechselt immer zwischen diesen zwei Zust nden Signale mit Wait Anzeige k nnen diesen Zustand zwischen dem Stop Zustand und dem der Wait Richtung entsprechenden Go Zustand annehmen Die Abfolge ist also Stop Wait f r eine Rich
381. ht r5 s3015 right Im Route Conflict Table werden die Konflikte zwischen den Routen definiert Route Conflict Table Route r0 rl r2 r3 r4 r5 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 216 7 6 4 2 Weichenverhalten Zunachst wird die Modellierung des Weichenverhaltens dargestellt 7 6 4 2 1 Allgemeines Weichenverhalten In dem Modul point wird das Verhal ten beschrieben das fiir alle Weichen gleich ist Demzufolge ist dieser Teil gleisnetzu nabh ngig Als Parameter werden drei Bedingungen bergeben die angeben ob eine Anforderung existiert die entsprechende Weiche geradeaus nach links oder nach rechts zu stellen Dabei sind nur Anforderungen m glich die mit dem jeweiligen Weichentyp vereinbar sind Eine SL Weiche kann also beispielsweise nicht nach rechts gestellt werden Die Variable state repr sentiert den aktuellen Zustand der Weiche und kann die Werte STRAIGHT RIGHT LEFT und UNDEFINED annehmen UNDEFINED dr ckt aus dass die je weilige Weiche noch nicht gestellt wurde Dies ist der Initialzustand einer Weiche Ist nun eine Bedingung zum Umschalten der Weiche erf llt nimmt diese den entsprechenden Zustand an Ansonsten beh lt die Weiche ihren vorherigen Zustand bei MODULE point straight_req left_req right_req VAR state STRAIGHT RIGHT LEFT UNDEFINED ASSIGN init state UNDEFINED next state case straight_req STRAIGHT left_req LEFT right_req RIGHT 1 state esac 7 6 4
382. i soll auf positives wie auch auf negatives bei der Fertigstellung eingegangen werden Mit unserem Endprodukt sind wir sehr zufrieden es erledigt ge nau die Arbeiten die auch vorgesehen waren Allerdings gab es auch Probleme Friih in der Projektphase haben wir einen Netzplan fiir unseren Bereich geschaffen um ein Vor bild fiir die anderen Gruppen zu sein Dies klappte allerdings aus zwei Griinden nicht Zuerst haben die anderen Gruppen nicht sofort nachgezogen und zum zweiten lagen wir in unserer Planung komplett falsch Anfangs sind wir davon ausgegangen dass wir den Compiler in einem Semester fertigstellen was uns aber absolut nicht m glich war Wir haben jegliche Zeiteinsch tzungen wegen der Einarbeitungszeiten in jeden einzel nen Bereich untersch tzt Dazu kamen immer wieder nderungen die im Nachhinein eingearbeitet werden mu ten Desweiteren wurde von Anfang an dir Gr e der Gruppe falsch eingesch tzt Anfangs gab es noch drei Mitglieder wobei eines noch fr h im ers ten Semester verloren ging Sp ter sollte diese Gruppe wieder auf drei Mann aufgestockt werden was allerdings aufgrund der Motivation des Neuen auch nicht klappte So blieb diese Gruppe im Endeffekt immer zwei Mann stark Durch gravierende pers nliche Pro bleme um das zweite Semester herum konnte auch einer dieser zwei nicht besonders viel zur Arbeit beitragen so dass die Arbeitskraft auf tats chlich einen und einen halben Mann bergrenzt war Diese Situation hat sic
383. ich ein nenneswerter Zeitgewinn ergeben h tte Aufgrund der bereits mehrfach angesprochenden Versions Vielfalt des DXF Formats ga rantiert die Netzgraphgruppe eine problemlose Verarbeitung auch nur f r die zum Zeit punkt der Implementierung des Konverters von QCad angebotenenen Versionen R12 und AutoCad2004 An diesen Versionen sind keine nderungen zu erwarten so dass das Argument f r bersetzerbau Werkzeuge hinsichtlich Grammatik nderungen und einem Mehraufwand beim Verzicht auf diese Werkzeuge aus Sicht des Netzgraphen zu vernachl ssigen ist Das Argument der geringeren Fehleranf lligkeit bei jenen Werkzeugen kann man unter Umst nden weiterhin anf hren sofern man die Versionsvielfalt mit diesen Werkzeugen in den Griff bek me jedoch sah die Netzgraphgruppe aufgrund der Art und Menge der einzulesenden Daten kein wirklich gro es Fehlerpotenzial welches nicht mit geringem Aufwand in den Griff zu bekommen gewesen w re Au erdem bedeutet ein Verzicht auf derartige Werkzeuge noch lange nicht dass das Ergebnis am Ende ein schlechteres sein wird 7 2 3 2 3 Klassendiagramm Die Implementierung dieses Konverters basiert auf einer berlegung in welcher es im Groben drei Haupt Klassen und einige Neben Klassen gibt die im folgenden Abschnitt beschrieben werden sollen Das Klassendiagramm Abbildung 7 6 zeigt die erstellten Klassen des Netzgraph Kon verter Paketes Die Klassen ConfigReader Abbildung 7 7 NGElement Abbildun
384. ich ist Eine Bahn f hrt durch wenn sie ein f r ihr Gleis zust ndiges Signal sieht das ihr die Weiterfahrt in die gew nschte Richtung erlaubt e Reaktion Weiche Bahn KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 317 Wenn eine Bahn von der spitzen Seite auf eine Weiche gelangt die sich nicht im undefinierten Schaltzustand befindet fahrt die Bahn auf der gerade ge schalteten stumpfen Seite wieder aus Fahrt eine Bahn von einem stumpfen Ende auf eine Weiche die auffahrbar ist oder die gerade auf dieses stumpfe Ende geschaltet ist gelangt die Bahn an das spitze Ende Fahrt eine Bahn von der spitzen Seite auf eine sich in einem undefinierten Schaltzustand befindliche Weiche schaltet eine Weiche gerade um w hrend eine Bahn sich auf ihr befindet oder f hrt eine Bahn von einer nicht geschal teten stumpfen Seite auf eine nicht auffahrbare Weiche so kommt es zum Schadensfall e Reaktion Bahn gt Sensor Sensoren bemerken wenn eine Bahn in ihren Einflussbereich ein bzw austritt und ndern je nach Funktionsweise ihren eigenen Zustand RouteRequestSensoren erhalten den Routenwunsch von Bahnen wenn diese sich neben auf ihnen befinden e Reaktion Bahn gt Weiche Wenn eine Bahn ber eine Weiche von der Seite kommt auf der mehrere Gleise abzweigen so schaltet die Weiche um so dass sie anschlie end auf die Verzweigung eingestellt ist ber die gerade die Bahn gefahren ist wenn
385. icht davon auszugehen ist dass beide zeitgleich auf dem selben Rechner laufen da der Betrieb des Simulators sonst unerw nschte Auswirkungen auf den Betrieb des SI haben k nnte lediglich die Treiber zur Anbindung des Simu lators m ssen auf dem SI Rechner laufen muss eine Netzwerkverbindung zwischen Treiber und Rest des Simulators vorgesehen werden Niklas Polke Arne Stahlbock KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 323 7 8 3 Weltmodell und Abstraktionen Fiir den Simulator ist selbstredend das projektweite Weltmodell beschrieben in Ka pitel 2 auf Seite 10 insbesondere der Abschnitt zur Bahntechnik in 2 3 auf Seite 18 bindend An dessen Entwicklung hat sich die Simulatorgruppe mafgeblich beteiligt An einigen Stellen werden jedoch fiir den Simulator Vereinfachungen und Abstraktionen vorgenommen die in besagtem Kapitel nicht erscheinen und die daher hier beschrieben werden sollen e Jede Bahn f hrt mit einer konstanten Geschwindigkeit diese Geschwindigkeit kann allerdings von Bahn zu Bahn unterschiedlich sein Ausnahmen sind das Halten vor einem Signal oder das Fahren hinter einer langsameren Bahn Zu begr nden ist diese Vereinfachung damit dass die dem SI gelieferten Daten ber den Fahrtverlauf von Bahnen sich auf Abfolgen von Sensorausl sungen beschr nken und Bahnen die ihre Fahrgeschwindigkeiten ndern nur die Abst nde zwischen den Ausl sun gen ver ndern nicht aber die Folge an sich In diesem Zusammenha
386. ie solche Sicherheitsverletzungen provozieren Diese Forderung ist notwendig um sicherheitskritsche Echtzeitanforderungen zu vermeiden Andreas Kemnade 7 5 4 4 Route Dispatcher In Abbildung 7 42 wird der Route Dispatcher in einem Statechart dargestellt Der Rou te Dispatcher ist daf r zust ndig zu berpr fen welche Routen freigeschaltet werden k nnen ohne dass es zu Konflikten kommt Im folgenden werden jeweils die Eingangs daten und die Ausgangsdaten und die einzelnen Funktionen beschrieben 7 5 4 4 1 Eingangsdaten e Route State Table RST e Route Conflict Table RCT aus Projektierungsdaten KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 190 e Liste von Routen Request Sensoren als SHM IDs aus Projektierungsdaten aktueller SHM Zustand als Kopie Queue Priority List QPL umsortierbare Liste von Queues ist initial nach der ID aufw rts geordnet Zuordnung Route Request zur RR Queue aus Projektierungsdaten Bahncounter f r jede Route als int Array initial 0 7 5 4 4 2 Ausgangsdaten e Route State Table int Array initial alle Routen inaktiv e Jueue Priority List e Bahncounter f r jede Route als int Array initial 0 Die Queue Priority List liegt ebenfalls als globales int Array vor Die RR Queues f r die einzelnen Routen haben eine maximale L nge von 3 und sind initial leer Der Route Dispatcher besteht aus einer Schleife ber alle Route Request Sensoren die berpr ft ob eine Routenanforderung vo
387. ierende Liste in der Informationen ber Treiberinstanzen abgelegt werden die sich erstmals mit dem Simulator verbunden und ein Init Request gesendet haben Au erdem liegt als Konstante die Portnummer vor auf der dieser Server betrieben wird und an die die Treiber ihre Anforderungen richten m ssen public void run this requestList new LinkedList this driverList new LinkedList ArrayList clientSockList new ArrayList ArrayList readerList new ArrayList ServerSocket serverSocket null boolean success true try KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 394 serverSocket ServerSocketChannel open serverSocket socket bind new InetSocketAddress PORT serverSocket configureBlocking false catch IOException e System out println Port PORT not usable success false Die Klasse muss die Methode run implementieren um als Thread laufen zu k nnen Zun chst werden in dieser Methode die Listen f r die Anfragen und Treiberinfos an gelegt au erdem zwei weitere Listen die einerseits die verschiedenen offenen Sockets andererseits die daf r existierenden Lesepuffer enthalten Es wird dann versucht einen Socket auf dem bereits bezeichneten Port zu ffnen Ist das nicht m glich erfolgt eine Meldung dar ber so dass der Nutzer des Simulators an dieser Stelle informiert wird und die n tigen Schritte einleiten kann um den Start wie gew nscht zu erm glichen while success Soc
388. iert ist Falls das der Fall ist sorgen sie daf r dass alle notwendigen Hardwareelemente entsprechend geschaltet werden damit die Route befahren werden kann Dies beinhaltet auch das finale Freigabesignal Sie sind auch daf r zust ndig die Signale entsprechend zu setzen so dass die Route wieder gesperrt ist Route wieder frei ist Der Safety Monitor schliesslich vergleicht die von RD und RC angeforderten Zust nde und den aktuellen Ist Zustand mit einer Liste von Sicher heitsbedingungen und schl gt Alarm falls diese verletzt werden RD RC und SM sind dabei jeweils Funktionen die innerhalb einer Endlosschleife wie folgt aufgerufen werden e zuerst wertet der RD alle anliegenden Route Requests aus e anschliessend werden die gerade aktiven RC aufgerufen nderungen werden je doch nicht direkt an das Treiberframework gesendet sondern in einer Kopie des SHM gespeichert KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 174 e Der SM berpr ft schliesslich diese SHM Kopie UND den aktuellen Ist Zustand ge gen die Sicherheitsbedingungen falls keine Sicherheitsverletzungen vorliegen wird die Kopie and das Treiberframework gesendet Andernfalls wird in einen Fehler zustand gewechselt der das System sichert und kontrolliert herunterf hrt Marius Mauch Andreas Kemnade Deng Zhou 7 5 3 Schnittstellen 7 5 3 1 Shared Memory Zust nde Im folgenden wird zun chst allgemein der Aufbau der Shared Memory Schnittstelle erl utert dann die Vertei
389. ies si rr straight rr right switchtime 100 s2 wait straight switchtime 200 s3 switchtime 200 s4 switchtime 100 7 1 3 2 5 PointPropBlock lt ptpropblock gt lt POINT_PROPERTIES gt lt ptpropdef gt sPepEcReers lt POINTID gt lt PASSIVE gt lt FALLBACK gt lt direction gt lt BREAKABLE gt lt SWITCHTIME gt lt POSINT gt lt direction gt lt LEFT gt lt STRAIGHT gt lt RIGHT gt Der Aufbau dieses Blockes ist analog zum vorigen er unterscheidet sich durch das ein leitende Schl sselwort point properties au erdem handelt es sich bei den hier auf gef hrten Eigenschaftsbeschreibungen um solche f r Weichen die daher auch mit Wei chenbezeichnern beginnen und andere optionale Schl sselworte haben Die Switchtime jedoch ist wieder genau wie oben Bedeutung KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 69 PASSIVE Die Weiche hat keine automatische Stellvorrichtung Fehlt das Token bei ei ner Weiche ist eine solche vorhanden FALLBACK Die Weiche ist eine R ckfallweiche d h f llt nach dem Auffahren aus der nicht geschalteten Richtung in ihre vorherige Lage zur ck Diese Standardlage muss angegeben werden bei Aktivweichen kann sie durch den Motor umgestellt werden BREAKABLE Die Weiche wird durch Auffahren aus der falschen Richtung potentiell besch digt darf nicht aufgefahren werden Verpflichtend ist die Switchtime in Millisekunden anzugeben Beispiel point properties
390. ies aber nicht mehr erfolgen 7 2 4 5 2 Markierungen Bei den Markierungen gibt es ebenfalls ein paar Ein schr nkungen bzw restriktivere Regeln W hrend die TND keine expliziten Eingangs und Ausgangsmarkierungen erfordert Sensoren k nnen diese Aufgabe bernehmen werden sie bei der Umsetzung eines DXF Gleisnetzes zwingend ben tigt Da hier nur eine unwesentliche Option der TND eingeschr nkt wird sollte auch dies keine Probleme bei der Erzeugung von Gleisnetzen hervorrufen Problematischer k nnte hingegen die in dieser Version unzureichende Unterst tzung von mehreren Markierungen in Folge sein In der aktuellen Version ist es nicht erlaubt meh rere Markierungen hintereinanderzusetzen ohne dass ein anderes Element dazwischen liegt F r die Darstellung von Kurven und hnlichem ist dies nun eine relativ starke Einschr nkung Da aber TRACS kleine Ausschnitte eines gro en Netzplanes als Gleisnetz ansieht kann man mit dieser Einschr nkung hoffentlich leben In einer zuk nftigen Version sollte diese Unzul nglichkeit in jedem Fall beseitigt werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 116 Es ist auch zu beachten dass sich die Markierungen fiir Eingang Ausgang und auch fiir ein totes Gleisende Sackgasse untereinander und von den einfachen Markierungen un terscheiden Es diirfen aber auch keine einfachen und Sondermarkierungen aufeinander folgen 7 2 4 5 3 Signale Signale werden in dieser Implementation ausschlie lich als M
391. igeben kann ein A vorhanden sein umgekehrt aber darf kein A f r eine nicht vorhandene Richtung existieren Ein typischer Ablauf w re folgender Eine Bahn berf hrt einen Route Request Sensor und fordert eine Route an Anschlie end n hert sie sich dem Signal das ihre Route freigeben wird Dieses steht auf Stop und nach Eingang der Anforderung zus tzlich auf A Sobald die Route geschaltet ist wird Go gegeben die Bahn f hrt in die Route ein Sobald sie den n chsten Sensor innerhalb der Route erreicht erkennt das Steuersystem dass die Bahn ihre Route begonnen hat setzt das Signal wieder auf Stop und schaltet gleichzeitig das A ab Ein Signal schaltet sich auf Anforderung des Steuersystems um wobei eine maximale Schaltzeit wie bei der Weiche existiert Das Verhalten eines Signals f r den Fall dass w hrend der Umsetzung eines Schaltbefehls ein weiterer Befehl eingeht ist nicht defi niert Ein Signal kann defekt sein dieser Zustand muss nicht zwangsl ufig vom Steuersys tem erkennbar sein Weiterhin sind Signale abschaltbar Signale melden ihren aktuellen Zustand an das Steuersystem 2 3 2 4 Bahnen Stra enbahnen befahren das Gleisnetz Kenngr en einer Bahn sind ihre r umlichen Di mensionen ihre H chstgeschwindigkeit und ihr maximaler Bremsweg f r verschiedene KAPITEL 2 DIE DOMANE 24 im Betrieb m gliche Geschwindigkeiten maximal bedeutet in diesem Zusammenhang unter ung
392. igits is less than 3 the space is filled with the appropriate number of blanks BEFORE any digits No other characters are allowed Only 473 ANHANG D NETZGRAPH KONFIGURATIONSDATEI 474 digits and blanks Exactly three characters are allowed no more no less ENTITIES SECTION control O e Layername 8 e X coordi 10 X coord2 11 Y coordi 20 Y coord2 21 Z coordi1 30 Z coord2 31 ooo o o oO BLOCKS_SECTION control 0O b dummy 3 b Textvalue 1 b Radius TextHeight 40 b Die genaue Beschreibung kann dem Datei Kopf entnommen werden Henrik R hrup Anhang E Netzgraph Konverter Element Listen Ausgabe E 1 Beispielgleisnetz In Abbildung E 1 ist ein komplettes Gleisnetz zu sehen welches mit Hilfe der CAD Software QCad eingegeben worden ist Abbildung E 1 Beispiel Gleisnetz Gleisnetz2 475 ANHANG E NETZGRAPH KONVERTER ELEMENT LISTEN AUSGABE 476 E 2 Element Listen Ausgabe Im Folgenden ist die komplette Ausgabe der Element Liste eines Gleisnetzes Abbil dung E 1 auf der vorherigen Seite zu sehen welche mit dem Parameter list erzeug bar ist name s3007 category signals type signal_l properties WL RRL switchtime 300 ms coords 19 0 34 0 0 0 name s3008 category signals type signal_sl properties WS RRS RRL WL switchtime 300 ms coords 30 0 44 5 0 0 name s3005 category signals type signal_r properties WR RRR switchtime 300 ms coor
393. iiert Die Begr ndung liegt darin dass nur dieses erste Element relevant ist wenn es darum geht welche Route freigegeben wird Nachfolgende Elemente in einer Queue haben nur dann eine Wirkung wenn sie ein Request f r die gleiche Route darstellen die auch vom ersten Element verlangt wird In dem Fall k nnen ggf gleich mehrere Requests erf llt und der Bahnz hler dieser Route entsprechend erh ht werden Jedoch erh lt man solche Testf lle bereits dann wenn das erste Element gesetzt ist und dann noch ein zweites ber einen gesetzten RR Sensor dazukommt In Kombination mit der Variation der gesetzten RR Sensoren reicht es also aus nur das erste Queue Element zu variieren um letztlich alle m glichen Kombinationen der ersten zwei Elemente pro Queue zu erhalten Auf das noch m gliche dritte wird dann allerdings verzichtet um die Zahl der Testf lle nicht zu stark steigen zu lassen Die Queue Priority List besteht aus so vielen Elementen wie Queues vorhanden sind in der Regel nur wenige die H chstzahl bei den getesteten Gleisnetzen betr gt 4 und wird voll durchkombiniert Die m glichen Kombinationen in der Route State Table k nnen ebenfalls verringert werden wenn man sich vor Augen f hrt dass f r die Entscheidung ob eine Route freigegeben werden kann nur wichtig ist ob eine in Konflikt dazu stehende Route aktiv ist oder nicht Hier m ssen f r die Belegung der RST also nicht 4 m gliche Zust nde pro Route diese Anzahl definiert
394. ikalischen Modells werden Informa tionen aus der TND Gleisnetzbeschreibung verwendet und zum Erstellen des Controller Modells Informationen aus den Projektierungsdaten Die Sicherheitsbedingungen las sen sich ebenfalls anhand der Beschreibung des betrachteten Gleisnetzes automatisch erzeugen 7 6 5 1 Physikalisches Modell Um das physikalische Modell zu erstellen werden Informationen ber die Beschaffenheit des Gleisnetzes aus der TND ben tigt Diese Informationen sind in folgenden Bl cken enthalten e definitions Block e point properties Block e relations Block e signal positions Block 7 6 5 1 1 definitions Block Der definitions Block beinhaltet alle im Gleisnetz ent haltenen Sensoren Weichen Signale und Kreuzungen Zun chst ben tigt man f r ein Gleisnetz folgende Informationen e Informationen ber die Menge der Signale Ser Diese Menge ist definiert durch die Funktion signalss signalsger tnd Set Diese Funktion liefert die Menge aller in der tnd enthaltenen Signale Analog zur Funktion signals werden die Funktionen points sensor Sse und crossingSsez definiert e Informationen ber die Menge der Weichen Pet points se tnd Pret KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 234 e Informationen ber die Menge der Sensoren G set Sensor Sset tnd gt Ger e Informationen ber die Menge der Kreuzungen K ge CrOSSINGS ser tnd K set Zudem muss man wissen von welchem Typ
395. ildung 7 32 struct definitions_t 7 4 3 4 4 struct relation_t Der Relations Block der TRACS TND ordnet Gleis netzelemente relativ zueinander an Auf diese Weise k nnen ansonsten uneindeutige Gleisnetzbeschreibungen klarer formuliert werden Diese Informationen werden prim r f r Modellpr fungen auf Sicherheit von Projektierungsdaten ben tigt Siehe hierzu auch Abschnitt 7 6 Abbildung 7 34 zeigt den Aufbau dieses Teilbaums des tram Syntaxbau mes 7 4 3 4 5 struct sigpos_t Der Signalpositions Block der TRACS TND nimmt Zuordnungen zwischen Sensoren und Signalen vor Dadurch werden insbesondere Ein gangssensoren f r einzelne Routen deutlich Diese Informationen werden wie in Abbil dung 7 35 gezeigt im tram Syntaxbaum abgelegt 7 4 3 4 6 struct route_t Der Routedefinitions Block der TRACS TND definiert den Verlauf einzelner Routen durch das zu steuernde Gleisnetz Hierbei werden die zu berfahrenden Sensoren pro Route aufgef hrt Diese Informationen sind f r den TRACS Steuerinterpreter siehe Abschnitt 7 5 zentral und finden sich dementsprechend in den vom tram Compiler generierten Projektierungsdaten wieder Abbildung 7 36 zeigt wie diese Informationen im Speicher dargestellt werden 7 4 3 4 7 struct condclearlist_t Die TND Bl cke Conditions und Clearances beinhalten Informationen dariiber welche Stellungen Weichen und Signale haben miis KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 146 entry struct symtab_entry_t next stru
396. ile sind so zu konstruieren dass sie eine garantierte Maximalanzahl an Durchl ufen haben es sind also Z hler zu verwenden Eine Ausnahme darf nur die Hauptschleife sein die nie beendet werden soll Diese Vorgaben sind bei der Entwicklung ber cksichtigt worden Schleifen sind stets mit Z hlern versehen die innerhalb der Schleife nicht ver ndert werden In einem Fall wird allerdings der Z hler unter bestimmten Bedingungen zur ckgez hlt aber da ist auf andere Art und Weise sichergestellt dass die Schleife abbricht 7 5 2 2 Treiberblock Das Treiberframework ist zust ndig f r die Verwaltung s mtlicher Treiber die f r das zu steuernde Gleisnetz notwendig sind Alle Treiber definieren dazu einen Satz von Callback Funktionen also treiberspezifische Funktionen die zu einem festgelegten Zeit punkt aufgerufen werden die vom Framework zur Laufzeit aufgerufen werden Es sind Callbacks vorgesehen f r die Initialisierung einen Sollzustandswechsel sowie optional f r eine allgemeine Ausf hrung S mtliche Treiberinformationen m ssen zur Compile zeit vorliegen da sie entscheiden welche Objektdateien ins Framework gelinkt und wel che Datenstrukturen generiert werden m ssen Zur Laufzeit initialisiert das Framework zun chst alle Treiber sowie seine eigenen globalen Datenstrukturen und die Shared KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 173 Memory Schnittstelle Das Shared Memory dient dazu um ber Prozessgrenzen hinweg einen gemei
397. in rdaten bersetzt Der Simulator hingegen wird diese Datei direkt einlesen und somit auf den gleichen Daten arbeiten Das erste nun folgende Unterkapitel beschreibt den Ablauf des Einlesens einer Datei Das anschlie ende Kapitel beschreibt die Gr nde warum wir uns f r die Benutzung von JFlex und CUP entschieden und keinen eigenen Compiler programmiert haben 7 8 4 3 1 Einlesevorgang einer TND Datei Das Einlesen einer TND Datei mit Hilfe von Lexer und Parser ist ein Ablauf der in mehrere Schritte unterteilt ist Die Ein gabe besteht aus einer TND Datei und das Ergebnis soll eine instanziierte Klassenstruk tur in Java sein Auf dem Weg zu diesem Ziel werden folgende Schritte durchlaufen welche zur Veranschaulichung in Abb 7 63 auf der n chsten Seite dargestellt sind 1 Lexikalische Analyse Der Scanner oder Lexer liest die Gleisnetzbeschreibung die in Form einer TND in einer Datei vorliegt ein und gibt beim Abruf des Parsers ein Symbol nach dem anderen an diesen weiter vgl ASU99 Abb 3 1 auf S 102 2 Syntaktische Analyse Der Parser verarbeitet die Symbole des Scanners Er erkennt fehlerhafte Eingaben und beschreibt diese Fehler m glichst pr zise Bei dieser Analyse entscheidet unser Parser ber die Relevanz der einzelnen Informationen Nur die f r den Simulator und die f r die Pr fung des CAD TND Konverters entscheidenden Informationen aus der TND werden anschlie end an den Best TramNetworkBuilderOfTheUNI verse wei
398. in welcher Richtung der Sensor berquert wurde Eingabebereich Der Eingabebereich f r einen Sensor Treiber beschreibt den gerade vom Steuerinterpre ter angeforderten Zustand Hierbei wird jede m gliche Anforderung bin r codiert indem jedem einzelnen Bit eine Bedeutung zugewiesen wird Die folgenden Bits sind f r den Eingabebereich definiert Bit 0 Alle Sensorwerte zur cksetzen haupts chlich f r RR Bit 15 Anforderung in einen Fehlerzustand zu wechseln und die Ausf hrung zu beenden Die Bits 1 14 sind nicht definiert und m ssen vom Treiber ignoriert werden Ausgabebereich Analog zum Eingabebereich signalisiert der Wert im Ausgabebereich den aktuellen Sta tus des vom Treiber gesteuerten Sensors Hierbei d rfen Bit 0 und 1 nicht gleichzeitig gesetzt sein ebenso darf ein Treiber nur Bit 2 oder Bit 3 benutzen RR Sensoren d rfen nur Bit 10 benutzen Die folgenden Bits sind f r den Ausgabebereich definiert Bit 0 Richtung A Bit 1 Richtung B Bit 2 Zug ist anwesend Bit 3 Toggle Bit 10 Route Request ausgel st Bit 13 Fehlerzustand OFF Bit 15 Fehlerzustand FAILURE Die Bits 4 9 11 12 und 14 sind nicht definiert und m ssen vom Steuerinterpreter igno riert werden Die verschiedenen Fehlerzust nde haben folgende Bedeutungen OFF Die Ausf hrung des Treibers wurde beendet es werden keine Anforderungen mehr ausgef hrt FAILURE Ein Hardwarefehler wurde erkannt KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 179 7
399. in und fasst einzelne Zeichen zu vordefi nierten Token zusammen Der Klasse Lexer wird automatisch generiert Als Spezifikationsdatei f r diese Klasse wird die Datei lexer def zu Grunde gelegt Parser Parser bekommt vom Lexer das Gleisnetz in Token Form und arbeitet die ses anhand einer Grammatik durch Relevante Informationen gibt er an den Best TramNetworkBuilderOfTheUNiverse weiter Auch die Klasse Parser wird automatisch erstellt und hat als Spezifikation die Datei parser def Sym Sym enth lt alle Terminale die Lexer und Parser verwenden Auch diese Klasse wird automatisch generiert auf Grundlage der parser def Best TramNetworkBuilderOfTheUNiverse Best TramNetworkBuilderOfTheUNiverse erstellt die Datenstruktur im Si KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 333 mulator d h er baut die Klassenstruktur aufbauend auf dem geparsten Gleis netz auf so dass das statische System des Simulators erzeugt wird 7 8 4 2 2 Paket gui Im Paket gui sind s mtliche Elemente vorzufinden die mit der graphischen Darstellung des Simulators zu tun haben Diese sind MainFrame MainFrame realisiert das Hauptfenster der Darstellung in dem auch das Bedie nungsmen vorliegt ImageComponent ImageComponent ist f r die Visualisierung der Simulation zust ndig hier be finden sich die Methodem zum Zeichnen der Elemente NewSimDialog NewSimDialog ist ei
400. inate miissen berechnet werden Anschaulich sieht die Formel zur KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 389 Berechnung des Punktes wie folgt aus wobei Radius den Radius des Kreises bezeichnet Abstand 22 21 y2 y1 7 8 xNeu xl 2x22 x1 Abstand Radius yNeu yl y2 yl Abstand xNeu und yNeu sind die Koordinaten des Punktes der in der Skizze auf H he von 2 liegt g2 setStroke new BasicStroke width BasicStroke CAP_BUTT BasicStroke JOIN_MITER g2 setColor Color red g2 drawLine xTail yTail int xNeu int yNeu Mittels setStroke wird die Dicke der Linie gesetzt sozusagen die Pinselbreite mit der gemalt werden soll Diese Methode ist eine exklusive Graphics2D Methode Der Para meter width in Zeile 10 gibt die Dicke an BasicStroke CAP_BUTT bedeutet dass der Pinselstrich keine abgerundeten Kanten haben soll und auch nicht ber die Enden hin weg ragen soll dies ist mittels eines anderen Parameters m glich Der letzte Parameter hat fiir das Zeichnen von Linien keine Bedeutung Anschlie end wird die Pinselfarbe auf Rot gesetzt und vom Ende der Tram bis zu dem neu errechneten Punkt eine dicke Linie gezogen Damit ist der Rumpf der Stra enbahn gezeichnet if type HEAD_TAIL g2 setStroke new BasicStroke width BasicStroke CAP_ROUND BasicStroke JOIN_MITER g2 setColor Color cyan g2 drawLine int xNeu int yNeu int xNeu int yNeu Falls es sich bei dem Abschnitt um denjenigen
401. indigkeit und dem Gewicht der Bahn so wie nach vorhandenem Antrieb kommt es zu unterschiedlichen Beschleunigungen bzw Verz gerungen also Bremswegen der Bahn Hierbei spielen auch noch viele weitere Punkte eine Rolle wie z B die Beschaffenheit der Gleise die Geographie f hrt die Bahn gerade von einem H gel runter Niederschlag der sich wiederum auf die Be schaffenheit der Gleise auswirkt usw In dem meisten F llen sollte sich eine geringere Beschleunigung nicht negativ auswirken es sei denn die Bahn muss schnell einen Gefahrenbereich verlassen Problematischer wirkt sich eine geringe Verz gerung aus was gleichbedeutend mit l nge ren Bremswegen ist Kommt es durch die eben genannten Umst nde zu einem zu langen Bremsweg kann die Bahn zum Beispiel nicht mehr rechtzeitig an Signalen halten oder sie kommt zu schnell in eine Kurve Das kann beim ersten im schwersten Fall zu schweren Unf llen f hren egal ob mit einer anderen Bahn oder sonstigem Verkehr Im zweiten Fall kann es dann durch die bereits oben erw hnten Fliehkr fte in besonders schlimmen F llen zu Entgleisungen kommen Die Gravitation hat insbesondere Auswirkungen auf die anderen physikalischen Wirkun gen wie die Beschleunigung Die Risiken durch diese Einwirkungen lassen sich durch unser System nicht vermindern Hierbei kommt es vor allem auf den Fahrer an der seine Fahrweise immer den u eren Umst nden anpassen sollte Viel zu steile Kurven sollten zudem bereits
402. ine Visualisierung des Gleisnetzes erstellt wird im Abschnitt 7 8 auf Seite 313 beschrieben Entwicklungsschritt Verifikationsschritt CAD Konverter _Reverah DxFDatt gt konvertieren N besc Be Y TND einlesen und visualisieren y Visualisiertes Netz im Simulator i 1 Gleisnetzdarstellung vergleichen C beide ienis Rot Komponente oder Pfad wird als korrekt angenommen Dicke Elipse Wiederverwendbares Produkt Normal Elipse Nicht wiederverwendbare Daten Abbildung 6 2 Validierung der TND Netzwerkbeschreibung Deng Zhou Ruben Rothaupt 6 3 Validierung der TND Routenbeschreibung Die TND Routenbeschreibung enth lt die in den Verschlusstabellen gemachten Anga ben Zur berp fung der Routenbeschreibung wird Model Checking verwendet KAPITEL 6 VALIDIERUNGS VERIFIKATIONS UND TESTPROZESS 54 Dazu wird aus der TND Netzwerkbeschreibung ein Modell des Gleisnetzes abgeleitet Nun kann berpr ft werden ob die Routen auch so befahrbar sind wie sie definiert wurden und ob alle Routenkonflikte richtig definiert wurden Auf diesen Vorgang wird im Abschnitt 7 6 auf Seite 203 naher eingegangen Entwicklungsschritt Verifikationsschritt TND Builder Routenbeschribung TND Nerzerkbeschreibung rot Transformation Abstraktion der Routenbeschreibung in TND TND NW erstellen TND Abstraktion outenbeschreibun der TND NW Modell Checker Konsi
403. is nach Anwendung der DXFSeparator Klasse siehe B 3 2 auf Seite 465 und B 3 3 auf Seite 467 7 2 3 2 5 ConfigReader java Die Klasse ConfigReader java ist eine Hilfsklasse Sie wurde zum Einlesen von Konfigurationsdaten entwickelt und war haupts chlich f r die Klasse DXF Separator java gedacht ist aber darauf ausgelegt auch f r weitere Klassen Konfigurationsdateien einzulesen was aber im Laufe des Projekts nicht weiter verfolgt wurde da f r die brigen Klassen nicht der zwingende Bedarf bestand Ein Beispiel einer Konfigurationsdatei mit Formaterkl rung befindet sich im Anhang siehe D 1 auf Seite 473 Das detaillierte Klassendiagramm 7 7 auf der vorherigen Seite zeigt u a die in dieser Klasse verwendeten Methoden und Attribute 7 2 3 2 6 NGDataCollector java Die n chste wichtige Haupt Klasse NGData Collector java in diesem L sungsansatz ist f r das eigentliche Einlesen der DXF Infor mationen zust ndig und bildet einen zentralen Bestandteil des Konverters Diese Klasse wird durch das Hauptprogramm TracsDXF2TND java Seite 102 und auch von der dritten Hauptklasse des Konverters TNDCreator java Seite 98 aufgerufen kann aber auch direkt aufgerufen werden f r Debugging Die Implementierung dieser Klasse zog sich bis ins letzte Projektsemester hin da zwischenzeitlich einige unerwartete Proble me auftraten und auch einige Details hinsichtlich der Nachbarschaftsbeziehungen nicht wirklich bedacht wurden Es werden nun aber all
404. issingSteps 0 09 return true 10 11 F 12 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 387 Wenn in der Liste eine andere Tram gefunden wurde so wird berpr ft ob ihr Ende das gleiche TrackElement und die gleiche Position hat auf die die Tram hinbewegt werden soll Falls Ja so wird im Logger vermerkt dass ein Auffahren erkannt wurde und die Tram wird gestoppt Die verbleibenden Schritte die gefahren werden sollen werden auf 0 gesetzt und die Methode wird mit dem Wert true verlassen Bei der Kollisions berpr fung werden zwei andere Positionen verglichen Befindet sich der Kopf einer anderen Tram auf der gleichen Position auf dem gleichen TrackElement wie die Tram selbst so ist es zu einem Zusammensto gekommen Wenn dies der Fall ist so wird das im Logger entsprechend vermerkt im Simulator wird eine handleCrash Methode aufgerufen und die Tram merkt sich selbst dass sie mit einer anderen Tram zusammengesto en ist 13 return false 14 Wurde kein Zusammensto festgestellt so wird die Methode mit dem Wert false ver lassen 7 8 5 3 Graphical User Interface Bei dem Graphical User Interface GUI sind alle Methoden recht simpel gehalten Der Algorithmus wie die Gleisnetz Koordinaten in die Fenster Koordinaten umgerechnet werden wurde bereits ausf hrlich in 7 8 4 5 1 auf Seite 359 erkl rt und die Implemen tierung in Java ist nicht von Belang Auch die Methoden zum Zeichnen des Gleisnet zelemente sind nicht kom
405. it f r verschiedenste Gleisnetze Au erdem werden folgende strukturelle Anforderungen gestellt e Einfacher Aufbau um zur Vermeidung von Compilervalidierung eine Implemen tierung in Assembler zu erm glichen was aber im Projekt nicht mehr realisiert wurde e Verwendung von Standard PC Hardware aus Kostengr nden e Finfache Verifizier und Testbarkeit Mit der nachfolgend beschriebenen Architektur sollen diese Anforderungen erf llen wer den Die darauffolgende Spezifizikation der Schnittstelle zu den Treibern der Syste mumgebung und der einzelnen Teilkomponenten muss pr zise genug sein damit eine Verifizier und Testbarkeit erreicht wird Deng Zhou Andreas Kemnade 7 5 2 Architektur In den folgenden Unterabschnitten wird die Architektur der einzelnen Teile des Steu ersystems dargestellt Wir haben diese Architektur so gew hlt dass die einzelnen Teile unseres Systems eine klare Aufgabenteilung haben Dabei haben wir uns an dem Sa fety Architecture Framework aus der SCS1 Vorlesung orientiert PZ Dabei entspricht unser Treiberframework dem System interface layer und der Safety Monitor entspricht dem Safety Layer Route Controller und Route Dispatcher entsprechen dabei etwas dem User Interface Layer da hier Routenanforderungen von der Bahn dem Fahrer also dem Benutzer verarbeitet werden Das Treiberframework dient dazu die Treiber zu verwalten KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 172 7 5 2 1 Gesamtsystem Die eige
406. k 7 8 7 Anleitung Dieses Kapitel enth lt die Bedienungsanleitung f r den Simulator 7 8 7 1 Voraussetzungen und Installation 7 8 7 1 1 Systemvoraussetzungen Die Software ist f r den Einsatz auf einem handels blichen PC konzipiert Besondere Mindestanforderungen an die CPU Geschwin digkeit oder die Gr e des Hauptspeichers haben sich bisher nicht bestimmen lassen da die Testeins tze auch auf den langsamsten gepr ften Rechnern Dual Pentium II 350 MHz 128 MB RAM bzw Pentium III 866 MHz 128 MB RAM noch zufriedenstellend verliefen Verpflichtend ist jedoch eine Netzwerkanbindung Als Betriebssystem wird ein g ngiges Linux empfohlen getestet Debian 3 0 und 3 1 SuSE 9 0 wenngleich sicher auch andere m glich sind Die oben verlangte Netzwerkan bindung muss ber das TCP IP Protokoll verf gbar sein Ebenso ist da der Simulator eine Grafikanwendung ist eine grafische Benutzeroberfl che wie bspw KDE oder Gnome Voraussetzung Auf dem System muss folgende Software verf gbar sein e Javat Compiler e Java Interpreter e JFlex e CUP Parser Generator for Java C Compiler fiir die Treiber KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 415 Java Compiler und Interpreter gibt es zahlreich w hrend der Entwicklung des Si mulators wurde Java 2 Platform Standard Edition v 1 4 2 von Sun eingesetzt weswegen wir an dieser Stelle auch genau dieses empfehlen erhaltlich unter http java sun com j2se 1 4 2 download htm
407. k steht das Wort clearances welches den Block identifiziert Der gesamte Block von beliebig vielen Freigabesignalen wird mit geschweiften Klammern umrahmt Jede Freigabedefinition beginnt mit einem Routenbezeichner gefolgt von ei nem Doppelpunkt Anschlie end werden alle Freigabebedingungen getrennt durch Kom mata angegeben Jede Beschreibung der Freigabesignale einer Route endet mit einem Semikolon Eine Freigabebedingung besteht aus dem Signalbezeichner und der geforder ten Signalstellung Allgemein m gliche Signalstellungen sind left right und straight Der ClearBlock enth lt die Informationen der Signal Setting Table Zu jeder Route werden hier die Signale und ihre Signalstellungen angegeben die n tig sind um die Strecke freizuschalten und befahren zu k nnen Bei den Signalen handelt es sich um das Eingangssignal der Route und die weiteren Signale die z B vor Weichen stehen Eine Route besteht aus mindestens einem Freigabesignal KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 75 Beispiel clearances route si straight route2 s2 straight route3 s3 straight route4 s4 straight routed si right route6 s4 right Dieses sind die Signalstellungen f r die einzelnen Routen des oben genannten Beispieles in Abbildung 7 1 auf Seite 63 Sie entsprechen genau den Richtungen der Weichenstel lungen im CondBlock s oben 7 1 3 2 12 PtConfBlock lt POINT_CONFLICTS gt lt confdef gt lt ROUTEID gt
408. kbox setzt der Nutzer die Option dass eine Weiche wahrend des Betriebes ausfallen kann Sie wird dann keine Schaltbefehle mehr ausfiihren Wann der Ausfall eintritt ist unvorhersehbar e Random behavior Die Weiche wird sich potentiell eigenm chtig umstellen wenn diese Option akti viert ist F r Sensoren kann eingestellt werden e May fail So eingestellte Sensoren werden irgendwann keine Meldungen mehr geben e Random behavior Diese Option bewirkt dass ein Sensor ggf R ckmeldungen gibt wenn keine Bahn anwesend ist Abschlie end f r Signale e Stellung Die Stellung gibt an was das Signal zu Beginn der Simulation anzeigen soll Aus einer Liste kann die gew nschte Stellung ausgew hlt werden Die Elemente der Liste sind abh ngig vom Typ des Signals d h es kann nur eine Stellung ausgew hlt werden die das Signal auch annehmen kann KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 421 e RR Mit bis zu drei Checkboxen je nach Vorhandensein der RR Anzeigen am Signal k nnen diese RR Anzeigen initial ein oder ausgeschaltet werden e May fail Durch Aktivieren dieser Checkbox setzt der Nutzer die Option dass ein Signal wahrend des Betriebes ausfallen kann Es wird dann keine Schaltbefehle mehr ausfiihren Wann der Ausfall eintritt ist unvorhersehbar e Random behavior Das Signal wird sich potentiell eigenm chtig umstellen wenn diese Option aktiviert ist Wurde eine Konfiguration dieser Art v
409. ken erstmals eine Sprache zur Verf gung die das Erstellen von GUI Programmen bereits als Kernfunktionalit t bietet Krii03 S 41 Ne ben elementaren Grafikfunktionen stellt Java das Swing Toolset bereit das viele Funktionen enth lt um grafische Elemente zur Interaktion mit dem Be nutzer zu erstellen und anzupassen e Nachteile von Java gegentiber C F r unsere Aufgabe einen Simulator zu programmieren sind die Nachteile von Java in den Bereichen Rechenzeit und Vererbung von Interesse und sollten somit genauer untersucht werden Rechenzeit Da Java kompilierter Code in einem Byte Format vorliegt muss dieser zur Laufzeit erst noch von einer Java Virtual Machine vorinterpretiert werden bevor der Prozessor die Befehle ausf hren kann Dadurch erh ht sich die Re chenzeit In C ist der kompilierte Code direkt vom Prozessor les und ausf hrbar Dieser Zeit Unterschied macht sich jedoch nur bei rechenintensi ven Programmen bemerkbar vgl Kr 03 S 45 Die einzigen recheninten siven Leistungen in unserem Simulator werden Such Operationen sein die jedoch bei der Initialisierung durchgef hrt und zur Laufzeit vermieden wer den Aus diesem Grund ist Java fiir unsere Bed rfnisse ausreichend schnell Vererbung In Java Mist keine Mehrfachvererbung wie in C m glich nur eine linea KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 327 re Einfachvererbung kann erreicht werden Um trotzdem die M glic
410. ketChannel clientSocket null String request try clientSocket serverSocket accept if clientSocket null clientSocket configureBlocking false clientSockList add clientSocket readerList add new StringBuffer catch Exception e e printStackTrace for int i 0 clientSockList size gt i i try SocketChannel s SocketChannel clientSockList get i StringBuffer buf StringBuffer readerList get i int nlpos while nlpos buf indexOf n gt 0 if nlpos 0 buf deleteCharAt 0 continue KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 395 try request buf substring 0 nlpos buf delete 0 nlpos 1 System out println Request received request if initRequest request addDriver request s J if checkRequest request addRequest request ls x int len ByteBuffer tmpbytebuf ByteBuffer allocate 100 while len s read tmpbytebuf 0 if s isConnected len lt 0 s socket close clientSockList remove i readerList remove i 1 27 System out println Socket closed break byte tmpbuf new bytellen tmpbytebuf rewind tmpbytebuf get tmpbuf String tmpstr new String tmpbuf US ASCII buf append tmpstr tmpbytebuf ByteBuffer allocate 100 catch Exception e catch e printStackTrace Exception e e printStackTrace try KAPITEL 7 BESCH
411. ktion auf erkannten Sensor Signalausfall oder defekt 2 4 1 2 2 4 1 Sensor Signalausfall oder defekt 1 1 Sensor Signalausfall oder defekt 1 2 Steuersystem schaltet nicht alle betroffenen Signale auf Stop XXX 2 4 2 Bahn berf hrt Stop Signal 2 4 2 1 Fehlverhalten des Fahrers 2 4 2 2 Bremsendefekt an der Bahn kann nicht anhalten 2 4 3 unzureichende Signalaustattung des Gleisnetzes Abschnitte nicht zu sch tzen weil kein Signal vorhanden 2 4 4 Signale schlecht sichtbar 2 4 4 1 witterungsbedingt d h vor bergehend 2 4 4 2 Signale dauerhaft verdeckt Hindernisse auf nahe von Gleisen Planungs und Baufehler 2 4 1 2 2 2 2 4 1 2 2 4 2 5 2 6 3 Kollisionen mit Hindernissen nicht Bahnen 3 1 Hindernisse auf nahe von Gleisen 4 Fahrg ste kommen zu Schaden ohne dass Bahnen kollidieren 4 1 St rze 4 1 1 Gebrechliche Fahrg ste 4 1 2 Fahrg ste halten sich nicht fest 4 1 3 stark ruckelige Fahrt 4 1 3 1 zu ruckelige starke Bremsvorg nge 1 Bremsendefekte 2 Signale schalten auf Stop wenn Bahn schon knapp davor XXX 4 1 3 1 3 Fehlverhalten des Fahrers 4 1 3 2 zu ruckeliges starkes Beschleunigen 1 Defekt an der Bahn 2 Fehlverhalten des Fahrers 4 1 3 1 4 1 3 1 4 1 3 2 4 1 3 2 KAPITEL 8 SICHERHEITSNACHWEIS 435 5 Bahntechnik Bahnen halten der Belastung nicht stand Arne Stahlbock Andreas Kemnade Taffou Happi Ruben Rothaupt 8 3 Auswertung Die Si
412. l Andere m gen auch funktionieren das kann an dieser Stelle aber nicht garantiert werden JFlex eingesetzte Versionen 1 3 5 und 1 4 1 kann unter www jflex de bezogen werden CUP eingesetzte Version 0 10k kann unter http www cs princeton edu appel modern java CUP bezogen werden Als C Compiler wurde gcc in den Versionen 2 95 4 und 3 3 5 eingesetzt http gcec gnu org 7 8 7 1 2 Installation Das Sourceverzeichnis des Simulators von nun an als src bezeichnet ist in ein beliebiges Verzeichnis auf dem Zielrechner zu platzieren Dabei darf die Verzeichnis und Dateistruktur innerhalb von src nicht ge ndert werden Das bei der CUP Installation enthaltene Archiv cup jar ist ebenso wie das Verzeichnis src in die Umgebungsvariable CLASSPATH aufzunehmen Java Compiler und Interpreter sowie JFlex nach den zugeh rigen Anleitungen in stallieren falls nicht ohnehin eine Installation ber ein in der verwendeten Distribution enthaltenes Paket gew hlt wird Der Simulator kann nun kompiliert werden indem nach src gewechselt wird und make bzw make sim ausgef hrt wird Sollen die Treiber kompiliert werden ist make drivers aufzurufen alles zusammen ist mit make all zu erreichen Nach erfolgreichem Kompilieren wird der Simulator mit dem Shellscript SimTracs sh gestartet 7 8 7 2 Ablauf einer Simulation Nach erfolgtem Start findet der Benutzer ein Fenster mit zun chst leerer d h grauer Darstellungsfl che vor ber
413. l sse wie z B Gewitter die Einflu auf die sichere Fahrt haben k nnen Durch ein Gewitter kann es zum Beispiel zu Stromausf llen kommen oder elektronische Elemente k nnen gest rt werden Desweiteren kann das Wetter auch Einflu auf die Sicht des Fahrers und Anderer ha ben Da kann es Nebel geben oder stark regnen oder hageln Diese Wetterverh ltnisse beeintr chtigen stark die Sicht Ein weiterer Punkt der nicht ganz genau den anderen Punkten hier entspricht ist Ein fluss durch Feuer Ein Brand in einer Bahn hat nat rlich einen erheblichen Einflu auf die sichere Fahrt dieser Bahn In solchen F llen kann unser System keinen Einflu nehmen Dies trifft auf fast alle bis her genannten Einwirkungen zu Bei einigen wenigen davon kann unser System bei der Erkennung helfen und damit eine schnellere Behebung erm glichen Hardwarest run gen Bei den meisten der oben genannten F lle sollte unser System nach Erkennung auch von Au en schnell das Gleisnetz in einen sicheren Zustand berf hren Waldemar Wockenfu KAPITEL 2 DIE DOMANE 18 2 3 Die Technik 2 3 1 berblick Nachdem nun die Umwelt beschrieben wurde kommen wir in diesem Abschnitt zum zweiten f r unser Weltmodell bedeutenden Teil n mlich der Bahntechnik Im Folgen den beschreiben wir die Bahntechnik mit der zusammen unser Steuersystem eingesetzt werden soll und ihre Funktionsweise Dar ber hinaus zeigen wir wo wir Vereinfachun gen vornehmen beispielsweise
414. l nicht verhindern jedoch m sste er Vorkehrungen treffen den Schaden ge ring zu halten z B durch Absperren des betroffenen Abschnittes 7 8 2 3 Visualisierung Der Simulator ist das einzige Modul des Projektes TRACS welches die Funktionsweise des Steuerinterpreters anschaulich darstellt Aus diesem Grund ist die Visualisierung KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 319 eine wichtige Anforderung Damit die Funktionsweise leicht nachvollzogen werden kann m ssen folgende Aspekte visualisiert werden Gleise Der Aufbau des gesamten Gleisnetzes soll m glichst genau dargestellt werden Wichtig hierbei ist dass die Streckenl ngen m glichst pr zise sind und der Ge samteindruck des Gleisnetzes stimmt Es muss au erdem ganz deutlich sein an welchen Stellen sich die Strecken kreuzen Die genaue Form von Kurven ist f r die Simulation unwichtig Sensoren Sensors In der Visualisierung des gesamten Gleisnetzes sollen die Positionen der Sensoren der Typ und der Zustand der z T unterschiedlich agierenden Sensoren erkennbar sein Diese Informationen sollen m glichst deutlich dargestellt werden damit der Anwender leicht nachvollziehen kann was der Sensor zum Zeitpunkt gerade tut Weichen Points Die Darstellung der Weichen soll erkennen lassen in welchem Zustand sich gerade die Weiche befindet also ob sie zum Beispiel gerade nach links oder nach rechts geschaltet ist oder ob sie sich gerade in einem Umschaltvorgang befindet
415. lators ihren Platz finden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 320 7 8 2 4 Schnittstelle zum SI Der Simulator simuliert lediglich die Reaktionen des Gleisnetzes auf die Anweisungen eines Steuerinterpreters SI sowie die Stra enbahnen Ohne SI w rden folglich die Mel dungen der Sensoren unbeachtet bleiben und die Signale w rden berhaupt nicht und die Weichen nur passiv geschaltet werden Da der SI nicht f r die Steuerung eines Si mulators entwickelt wird ben tigt der Simulator eine Schnittstelle um mit dem SI zu kommunizieren Der SI verf gt ber eine Treiberschnittstelle an der Hardware Treiber f r Weichen Sensoren und Signale angebunden werden k nnen F r den Simulator sind daher Treiber zu entwickeln die diese Schnittstelle nutzen und die f r den SI wie nor male Hardwaretreiber erscheinen Damit die Komposition aus Simulator und SI funktionieren kann muss eine bidirek tionale Kommunikation stattfinden Der SI muss vom Simulator ber dessen aktuellen Zustand benachrichtigt werden wenn dieser seinen Zustand ndert und der Simulator muss seinerseits vom SI benachrichtigt werden wenn dieser die Umstellung eines Signals oder einer Weiche befiehlt Die zu realisierenden Aspekte der Kommunikation sind im Folgenden aufgelistet und beschrieben e Reaktion Sensoren gt SI Der SI muss permanent ber die aktuellen Zust nde der Sensoren informiert sein e Interaktion Signale gt SI Der SI muss per
416. lcode arbeiten sollen die ihn nicht selbst erstellt haben e Cross Reviews Bei wichtigen fiir die Korrektheit des Programms entscheidenden und komplizier ten Methoden oder auch Klassen werden diese von einem Mitglied der Simula torgruppe durchgesehen dass nicht an der Entwicklung des Quellcodes beteiligt war Durch Nachfragen und Hineindenken dieses hinzugekommenen Mitglieds sol len vor allem konzeptuelle Fehler gefunden werden da diese auch bei mehrfachem KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 367 Durchsehen des Entwicklers im Allgemeinen nicht auffallen Im dritten Projektse mester war diese Technik bei der zuletzt vorliegenden Gruppengr e leider nicht mehr einsetzbar 7 8 4 7 2 Fehlersuche im Anschluss an die Fertigstellung Au er den Ma nahmen zur Fehlervermeidung w hrend der Entwicklung werden f r den Simulator auch anschlie ende Tests durchgef hrt die die korrekte Funktionsweise zumindest ann hernd sicherstellen sollen Daf r werden im Voraus Methoden geschrieben die den aktuellen Zustand in bersichtlicher und gut lesbarer Form in eine Textdatei oder auf den Bild schirm schreiben Getestet werden soll im Anschluss e Funktion einzelner Methoden Dies ist die unterste Ebene der Tests Hier werden vor allem die komplizierteren Methoden ausf hrlich und sehr im Detail auf ihre Richtigkeit hin berpr ft Als Beispiel w ren hier die Methoden zur Fortbewegung der Bahn zu nennen e Funktion der Module Als zu testen
417. ldungen Dies wird durch die oben beschriebenen Elementinformationen einer TND m glich F r genaue Informationen ber das Projektierungsdatenformat des TRACS Steuerin terpreters m ge der Abschnitt 7 5 zu Rate gezogen werden 7 4 2 3 Sicherheitsanforderungen Der tram Compiler ist zwar verantwortlich f r die konkrete Steuerungslogik eines Gleis netzes muss allerdings trotzdem nicht formal validiert werden Innerhalb des TRACS Verifikationsprozesses existiert ein Modellvergleich der die vom tram Compiler gene rierte Projektierungssdaten auf Sicherheit pr ft Dieser Modellvergleich trifft vor dem Einsatz von generierten Projektierungsdaten mit dem generischen TRACS Steuerin terpreter die endg ltige Entscheidung ob die f r ein konkretes Gleisnetz generierten KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 140 Projektierungsdaten im Zusammenspiel mit dem TRACS Steuerinterpreter ein sicheres Steuerungssystem ergeben Dennoch stellt der tram Compiler den informellen Anspruch an sich fiir jedes Gleis netz sichere Projektierungsdaten zu generieren oder sollte dies nicht m glich sein eine entsprechende Fehlermeldung zu generieren N here Information zur Sicherheitspr fung von bin ren Projektierungsdaten finden sich in Abschnitt 7 6 Helge L ding 7 4 3 Architektur Der TRACS tram Compiler besteht aus modular entwickelten Komponenten deren Zu stammenspiel die Gesamtfunktionalit t ausmacht Hierbei kommen neben der Program mierspra
418. leises und es darf folglich immer nur ein Element welcher Art auch immer mit diesen Symbolen verbunden werden Desweiteren d rfen sich auch nicht mehrere Linien oder Elemente in einem und dem selben Ber hrungspunkt eines anderen Elements treffen Pro Ber hrungspunkt darf es nur zwei Elemente geben Ausnahme bilden hier Markierungen da diese auf dem Ber hrungspunkt zweier Linien liegen und somit quasi drei Teile sich in diesem Punkt treffen Markierungen sind au erdem nur zwischen zwei Linien erlaubt nicht aber direkt an einem anderen Element Sensoren und Signale sind gerichtete Elemente so dass ggf auf die Fahrtrichtung geach tet werden muss Bei diesen Elementen ist au erdem darauf zu achten dass es sich wegen der Fahrtrichtungserkennung um Zwei Punkt Elemente handelt deren zwei Koordina ten sehr eng beieinander liegen sodass es zu Zeichenfehlern kommen k nnte wenn man nicht genau aufpasst Eine Vergr erung des betreffenden Ausschnitts Heranzoomen ist daher ratsam Benennung von Elementen Die einzelnen Elemente eines Gleisnetzes m ssen zum Zwecke der Konvertierung und korrekten Erstellung einer TND Datei eindeutige Namen haben Au erdem m ssen ggf bei Weichen und Signalen einzelne Properties Eigenschaften wie z B besonde re Signal Anzeigen gesetzt werden Dies wird beides im jeweils selben Arbeitsschritt KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 111 durchgef hrt Um ein Element eineutig entsprechend der Synt
419. leisnetzes noch zus tzlich zu den oben angegebenen Informationen echte Hardwareeigenschaften wie Schaltzeiten oder R ckfallrichtungen notwendig sind k nnen in der Tram Network Description inner halb der Bl cke Signal Properties und Point Properties Hardwareeigenschaften pro Signal bzw Weiche angegeben werden Genauere Informationen hierzu sind 7 1 zu entnehmen Da innerhalb des Projekts TRACS keine realen Gleisnetze gesteuert werden konnten wurde ein Gleisnetzsimulator entwickelt siehe 7 8 der ebenfalls auf der Tram Network Description aufbaut Daher enth lt sie zus tzliche Informationen ber Koordinaten ein zelner Hardwareelemente sowie deren Anordnungen zueinander Diese Daten sind not wendig um nur anhand einer Tram Network Description ein Gleisnetz visualisieren zu k nnen das ansonsten in seiner Topographie nicht eindeutig beschrieben w re Hierzu wurden die Bl cke Coordinates Relations und Signal Positions integriert Zus tz lich werden Doppelweichen in der Tram Network Description erlaubt die im Block Slipswitches zu spezifizieren sind Um eine Zuordnung von Gleisnetzelementen zu Treibertypen vornehmen zu k nnen wurde ein weiterer Block Hardwaremap in die Tram Network Description aufgenommen Hier werden einzelnen Hardwareklassen die den gleichen Treiber nutzen entsprechende Gleisnetzelemente zugeordnet Der Block Definitions der Tram Network Description enth lt keine zus tzlichen Infor mationen zum Steuern eines Gl
420. leistung die Bildschir mausgabe in Anspruch nimmt liegt bei bis zu 30 MDB03 S 336 Daher sollte die grafische Ausgabe so gering wie m glich gehalten und berfl ssige Daten vermieden wer den Eine Optimierung der grafischen Ausgabe bietet der folgende Weg der allerdings nicht beschritten worden ist Bei der visuellen Darstellung der Simulation sollten nur die Ver nderungen neu gezeichnet werden statt das komplette Gleisnetz Bewegt sich eine Stra enbahn auf dem Gleisnetz einen Schritt vorw rts so wird nur der betreffende Bereich bermalt Das Suchen in einer Menge ist immer eine sehr zeitaufw ndige Angelegenheit Je nach Datenstruktur und Suchanfrage m ssen viele Objekte gesucht und Membervariablen durchsucht werden Hier bietet es sich an die Geschwindigkeit beim Suchen durch eine erh hte Verwendung von Speicher zu maximieren bzw die Datenstruktur so aufzubauen dass Suchen m glichst vermieden werden k nnen auf Kosten des Speicherverbrauchs Blockierende Aufrufe sind Methoden die auf ein externes Ereignis warten wie z B die R ckmeldung der Festplatte und bis zum diesem Zeitpunkt nicht fortfahren k nnen In unserem Fall ist das Empfangen der SI Anfragen blockierend denn eine neue Anfrage soll jederzeit an den Simulator gesendet werden k nnen Dazu funktioniert die Simulator Seite der Kommunikationsschnittstelle wie ein Postfach alle ankommenden Auftr ge werden gesammelt und k nnen jederzeit vom Simulator abgerufen
421. lemente die an den Enden liegen Tram Tram simuliert eine Stra enbahn die aus Kopf und Ende besteht Sie f hrt eine Route entlang reagiert auf Signale und kann mit einer anderen Stra enbahn zusammen sto en KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 332 Route Route enth lt die Informationen ber welche Sensoren eine Route f hrt und wie welche Weichen geschaltet sein m ssen damit die Route richtig ab gefahren wird NetworkEndException NetworkEndException ist von Exception abgeleitet und ist lediglich vor handen um einen speziellen Exception Typ zu haben e Schnittstelle zu den Treibern Die Schnittstelle zu den Treibern besteht aus zwei Klassen die f r das Empfangen und Senden von Daten zust ndig sind DriverRequestServer DriverRequestServer ist verantwortlich f r das Empfangen von Anforde rungen die der Steuerinterpreter an die Treiber geschickt hat und die von diesen in Strings bersetzt worden sind StatusSender StatusSender sendet den aktuellen Status eines Elements als Nachricht an die Treiber die diese Information wiedrum in das Shared Memory eintragen e Einlesen des Gleisnetzes Da es m glich sein soll den Simulator auf verschiedenen Gleisnetzen laufen zu lassen s S 334 ist es notwendig ein Gleisnetz automatisch einlesen und die Datenstruktur des Simulators daraus erstellen zu k nnen Lexer Lexer liest die Gleisnetz Datei e
422. lesenen Daten den Syntaxbaum erstellt Die Funktionen um die Projektierungsdaten zu erstellen wur den im Abschnitt davor behandelt sollen aber hier noch einmal kurz erl utert werden Als erstes gibt es void getRCData struct section_t syntree struct rc_data_t newRcd int rid Diese Funktion analysiert den gegebenen Syntaxbaum und erstellt f r eine per ID ge gebene Route die ben tigten Aktionslisten f r den Steuerinterpreter Hierbei werden mithilfe anderer Funktionen einzelne Informationen aus dem Syntaxbaum in einzelne SHM Steuerbefehle umgesetzt Die Ausgabe erfolgt in einen spezifizierten Zielbereich der bereits allokiert sein mu Als Eingaben erh lt die Funktion den zu benutzenden Syntaxbaum die zu benutzende Zieladresse und die jeweils zu bearbeitende Route Diese Funktion erstellt die Projektierungsdaten f r alle Route Controller Als n chstes gibst es da struct rd_data_t getRDData struct section_t syntree Hier erh lt die Funktion nur den Syntaxbaum mitsamt seiner Daten und erstellt daraus eine Konflikttabelle und die notwendigen Route Request Queues Dann gibt es noch struct sm_data_t getSMData struct section_t syntree struct rc_data_t rcdata struct rd_data_t rddata Hier werden die Daten f r den Safety Monitor erzeugt Diese Funktion erh lt die bereits generierten Daten f r den Route Dispatcher und f r die Route Controller und den Syntaxbaum und liefert die Projektierungsdaten f r den Safety Moni
423. letzten verbliebenen Grup penmitglieds m gen andere beurteilen eine Eigenbewertung scheint hier nicht ange bracht 7 8 8 2 4 Schwierigkeiten Die Arbeitsgruppe Simulator muss eingestehen dass sie es das ganze zweite Semester ber nicht geschafft hat eines der vier Mitglieder zu in tegrieren Das langsame Arbeiten eines Mitgliedes wurde zuerst noch mit sprachlichen Schwierigkeiten begr ndet doch es stellte sich schnell heraus dass das nicht das einzige Problem war Es wurde versucht beim Programmieren mit Java Hilfestellung zu geben dabei wurde offensichtlich dass es auch an Grundlagen bei der Programmierung mit Java Mfehlte Bei den Gruppentreffen wurde sehr fr h erkennbar dass dieses Mitglied den Anschluss zu verlieren drohte und es wurde von den anderen versucht darauf hinzu weisen dass es mehr tun m sse Es wurde sich darum bem ht auf das vierte Mitglied R cksicht zu nehmen doch irgendwann war es klar es hatte den Anschluss an das Projekt verloren Die restlichen drei Mitglieder f hlten sich an einer Gabelung angekommen Die eine M glichkeit bestand in dem Versuch das letzte Mitglied auf Biegen und Brechen zu integrieren und es zur Mitarbeit zu zwingen und dabei auch viele Hilfestellungen zu geben was die Weiterentwicklung des Simulators mehr oder minder zum Stillstand ge bracht und auch nur dann geholfen h tte wenn das vierte Mitglied sich sehr engagiert h tte Die Alternative war das Ignorieren des vie
424. lismus Terror anderes Fehlverhalten Wettereinfliisse e Wind e Uberschwemmung e Gewitter Extreme Temperaturen Eis Schnee Eingschr nkte Sicht Nebel Starker Regen Hagel e Feuer Gesetzliche Einschr nkungen e Mindest Maximalgeschwindigkeiten 12 KAPITEL 2 DIE DOMANE e Maximale Anzahl Passagiere e Vorgaben fiir den Fahrer e Sicherheitsstandards e Verkehrsordnung 13 KAPITEL 2 DIE DOMANE 14 2 2 2 Textuelle Beschreibung Als n chstes folgt nun eine kurze Beschreibung der einzelnen Aspekte und auf welche Art und Weise sie die sichere Fahrt der Bahn beeinflussen k nnen Dabei wird nicht genau auf alle oben genannten Punkte im einzelnen eingegangen da sich viele von ihrer Beschaffenheit und Auswirkung gleichen oder zumindest sehr hneln Andere Punkte stehen wiederum in einem Zusammenhang zueinander obwohl sie in v llig unterschied lichen Teilbereichen aufgez hlt werden 2 2 2 1 Physikalische Wirkungen 2 2 2 1 1 die Bahn betreffend Als erstes sollen hier die physikalischen Wirkungen auf die Bahn angesprochen werden Hierbei gibt es als erstes die Tr gheitskr fte Von denen gibt es verschiedene Arten Die Fliehkr fte wirken sich insbesondere in Kurven aus F hrt eine Bahn in eine Kurve wird sie durch die Fliehkr fte je nach Geschwindigkeit und Gewicht der Bahn verschie den stark nach au en getragen und k nnte in extremen F llen dadurch entgleisen Ebenfalls nach bereits vorhandener Geschw
425. llt werden soll hat unmittelbar nichts mit den in den Verschlusstabellen gemachten Angaben zu tun sondern mit der Spezifikation des Systems MODULE signal straight_cond left_cond right_cond VAR state STOP STRAIGHT RIGHT LEFT ASSIGN init state STOP next state case straight_cond STRAIGHT left_cond LEFT right_cond RIGHT 1 state esac KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 246 7 6 6 3 2 Initialisierung der Variablen Auch f r alle in einem Gleisnetz enthal tenen Signale werden Variablen erstellt Dazu wird jeweils das Modul signal aufgerufen und als Parameter werden die Bedingungen bergeben die angeben wann das Signal den jeweiligen Zustand annehmen soll Dabei sind nur Anforderungen m glich die mit dem jeweiligen Signaltyp vereinbar sind s3014 signal s3014_straight s3014_left none s3013 signal s3013_straight none s3013_right s3015 signal s3015_straight none s3015_right 7 6 6 3 3 Bedingungen zum Stellen der Signale Ein Signal soll in eine bestimm te Richtung gestellt werden wenn eine Route befahren werden soll f r die im Signal Setting Table die entsprechende Signalstellung definiert wurde Das Signal s3014 soll in dem Beispiel auf geradeaus gestellt werden wenn die Route route25 befahren werden soll und nach links wenn die Route route26 befahren werden soll s3014_straight case route_A route25 route_B route25 1 1 0 esac s3014_left case rout
426. llte man genau untersuchen woran es liegt und den Test Checker pro grammieren Wenn er genauso wie zu testende Funktion arbeiten soll w rde es einfacher eine Entscheidung zu treffen woran die Fehler liegen Marcin Dysarz 7 7 7 Vorschl ge zu Software Hardware Software und Sys tem Integrationstest In diesem Abschnitt werden die Konzepte f r Software Integrationstest Hardware Soft ware Integrationstest und System Integrationstest entwickelt Innerhalb des Projekts wurden ausschliesslich Unit Tests durchgef hrt Um aber korrektes Funktionieren in Bezug auf die Spezifikation vollst ndig zu testen sind die genannten weiterf hrenden Tests notwendig um das Zusammenspiel von einzelnen Komponenten und Zielhardware miteinander zu berpr fen Alle drei Testarten beruhen auf der in 7 5 vorgestellten Spezifikation des Safety Control lers F r die dabei benutzten UML Statecharts existieren Testtheorien die das Testen gegen eine solche Spezifikation erm glichen Hierzu sind einige Vorgaben an den Test ling notwendig die sp ter beschrieben werden sollen Zus tzlich muss diese Spezifikation noch transformiert werden um Tests zu erm glichen Wird auf solche Weise getestet so erm glicht das benutzte Testwerkzeug dass ein Testgenerator f r sowohl Software KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 304 Integrationstest als auch Hardware Software Integrationstest notwendige Testdaten ge neriert Hierbei werden die selben Testdaten auf
427. lneh mern und des voraussichtlichen Aufwandes der damit verbunden w re haben wir das nicht getan Wir haben die Projektierungsdaten benutzt die auch vom System benutzt werden und sind davon ausgegangen dass diese korrekt waren da die Korrektheit der Projektierungsdaten mit Hilfe von Model Checking Methoden gezeigt wird Siehe hier zu 7 6 auf Seite 203 Marcin Dysarz 7 7 2 2 Ebenen Test Ein vollst ndiger Test besteht aus mehreren Teil Tests die auf mehreren Ebenen voll gezogen werden Heutzutage werden Tests blicherweise auf folgenden Ebenen durch gef hrt e Unit Test e Software Integrationstest e Hardware Software Integrationstest e System Integrationstest Wenn die Tests auf allen Ebenen mit einem positiven Ergebnis abgeschlossen werden dann kann man behaupten dass die Vollst ndigkeit der Tests garantiert ist und das System korrekt funktioniert Unit Tests Komponententests berpr fen einzelne Komponenten z B eine einzelne Funktion innerhalb der Software Dabei wird die Umgebung simuliert d h die Umge bungsvariablen sowie die globalen Variablen werden voreingestellt Zum berpr fen der Funktionen verwendet man Test Generator Test Orakel und Test Checker Als Schnitt stelle dienen hier die bergabeparameter und R ckgabewerte Anhand dieser werden die Funktionen auf ihr korrektes Funktionieren gepr ft Durch parallele Ausf hrung und Vergleich der Ergebnisse zwischen der zu testenden Funktion und einem Test
428. ls um auf Grundlage dieser Theorie basierend unseren Compiler zu erstellen 7 8 4 4 Simulation Den Kern des Simulators bildet die Simulation s Anforderungen 7 8 2 2 auf Seite 316 Der rundenbasierte Ablauf wird im Absatz Ablauf einer Runde erkl rt Der Simula tor soll nicht nur Weichen und Signale so stellen k nnen wie der Steuerinterpreter sie anfordert Annahme von ANforderungen zur Stellungs nderung sondern Weichen Sensoren und Signal liefern auch nderungen ihres Zustands an die Treiber bzw den Steuerinterpreter zur ck Zustands nderungen zur ckmelden Damit Sensoren ausl sen k nnen m ssen Stra enbahnen auf dem Gleisnetz bewegt werden Wie sich eine Stra en bahn fortbewegt und wie die darunter liegende Datenstruktur aussieht wird im Absatz Bewegungsalgorithmus n her erl utert Au erdem muss die Simulation initialisiert werden insbesondere m ssen die Stra en bahnen gesetzt und ihnen eine Fahrtroute zugewiesen werden damit die Simulation korrekt ablaufen kann Laut Anforderungen soll es zus tzlich m glich sein ein fehler haft agierendes Gleisnetz simulieren zu k nnen s Anforderungen 7 8 2 2 auf Seite 316 Das Konzept der Initialisierung und der fehlerhaften Aktion ist in den Abs tzen In itialisierung einer Simulation und Simulation von fehlerhaft agierendem Gleisnetz zu finden 7 8 4 4 1 Ablauf einer Runde Der Ablauf einer Runde im Simulator gliedert sich in mehrere Bereiche e Anforderungen holen
429. lso hier um Bahnen die ihre Routen immer wiederholt befahren L nge Die L nge gibt an wie lang die Stra enbahn sein soll Es kann eine L nge aus einer Liste ausgew hlt werden maximale Geschwindigkeit Die maximale Geschwindigkeit gibt an wie schnell diese Stra enbahn maxi mal fahren kann Es kann eine Geschwindigkeit aus einer Liste ausgew hlt werden May fail Durch Aktivieren dieser Checkbox setzt der Nutzer die Option dass eine Bahn w hrend des Betriebes ausfallen kann Sie bleibt dann irgendwann ste hen an welchem Ort dies geschieht ist nicht vorhersehbar Random behavior Eventuell k nnte der Fahrer dieser Bahn sich zum Missachten von Signalen entschlie en Die Zuweisung von Namen zu einer Stra enbahn ist nicht m glich Die Bahnen werden automatisch vom System durchnummeriert Es ist m glich dass mehrere Stra enbahnen die gleiche Spezifikation insbesondere die gleiche Route haben In diesem Falle werden die beiden Bahnen nacheinander in die Route einfahren Mittels des Knopfs OK wird der Initialisierungsschritt der Stra enbahnen abge schlossen und zum n chsten Schritt bergegangen e Weichen stellen Set Turnouts Im n chsten Spezifikationsschritt werden die Weichen gestellt Es erscheint eine Liste aller Weichen die im Gleisnetz vorhanden sind Bei Weichen sind folgende Einstellungen m glich Stellung Die Stellung der Weiche in der sie zu Beginn der gezi
430. lt bei den automatisierten Tests eine wichtige Rolle Sie dienen als Kommunikationskan le zwischen der Testumgebung und dem Testling zur KAPITEL 4 DER LOSUNGSANSATZ 44 Simulation und Erfassung der Reaktionen des zu testenden Systems In dem Testvorgang werden keine konkreten Testdaten fest gespeichert Die werden erst nach dem Einlesen der dem Test zugeh rigen Projektierungsdaten w hrend der Ausf hrung generiert Durch dieses Schema ist Wiederverwendbarkeit einer Testproze dur f r mehrere Testkonfigurationen garantiert Als Testwerkzeug benutzen wir die Software RT Tester der alle oben genannten Funk tionalit ten uns anbietet Die genaue Beschreibung ist im Kapitel 7 7 3 1 auf Seite 259 dargestellt Die vollst ndige Beschreibung der Testprozeduren findet man in den Abschnitten 7 7 2 auf Seite 255 7 7 4 auf Seite 262 7 7 5 auf Seite 267 Marcin Dysarz Kapitel 5 Entwicklungsprozess In diesem Kapitel wird der Prozess beschrieben wie in TRACS ein Steuersystem gene riert wird 5 1 berblick Um einen Verifikationsprozess zu erm glichen muss auch der Entwicklungsprozess sys tematisch beschrieben werden damit klar zu sehen ist welcher Entwicklungsschritt in welcher Form verifiziert werden kann Im Abschnitt 5 2 werden die Grenzen des TRACS Systems dargestellt Im Rahmen des Entwicklungsprozesses wird auf von uns entwickelte Komponenten zur ckgegriffen die ben tigt werden um eine ausf hrbare Steuerungs
431. lt condition gt lt direction gt lt clearblock gt lt cleardef gt lt clearance gt lt POINT_PROPERTIES gt lt ptpropdef gt lt POINTID gt lt PASSIVE gt lt FALLBACK gt lt direction gt lt BREAKABLE gt lt SWITCHTIME gt lt POSINT gt lt SLIP_SWITCHES gt lt slipswitchdef gt lt CROSSID gt lt POINTID gt lt POINTID gt lt POINTID gt lt POINTID gt 2 lt SWITCHTIME gt lt POSINT gt lt RELATIONS gt lt reldef gt lt relation gt lt relnone gt lt elementid side gt lt MARKID gt lt elementid side gt lt sensid side gt lt MARKID gt lt een gt lt ENTRANCE gt lt EXIT gt lt NONE gt lt sensid side gt lt crossid side gt lt pointid side gt lt SENSID gt lt SIDE gt lt CROSSID gt lt cross side gt lt SIDE gt lt CROSS_SIDE gt lt POINTID gt lt POINT_SIDE gt lt SIGPOSITIONS gt lt sigposdef gt lt SIGID gt lt sensid side gt lt MARKID gt lt sensid side gt lt ROUTEDEFINITIONS gt lt rtdef gt lt ROUTEID gt lt SENSID gt lt SENSID gt lt SENSID gt lt REQUESTAT gt lt SENSID gt lt SENSID gt lt CONDITIONS gt lt conddef gt lt ROUTEID gt lt condition gt lt condition gt lt POINTID gt
432. lung der Shared Memory IDs nach Hardwareklassen Danach erfolgt eine Auflistung der einzelnen Bits f r die jeweiligen Hardwareklassen getrennt nach Bits im Eingabe und Ausgabebereich Jeder Treiber kommuniziert mit dem Steuerinterpreter SI ber einen eigenen 32 Bit gro en Speicherbereich Dieser ist unterteilt in zwei je 16 Bit gro e Teile wobei der eine Bereich vom Treiber gelesen und vom Steuerinterpreter geschrieben wird Eingabebe reich und der andere vom Treiber geschrieben und SI gelesen wird Ausgabebereich Das bedeutet dass auf diesen Speicherbereich unter Umst nden von mehreren Prozessen zugegriffen werden muss es sich dabei also um Shared Memory handelt Durch diese einheitliche Schnittstelle wird die Treiber und die SI Entwicklung vereinfacht Die Se mantik f r Ein und Ausgabebereich ist von den einzelnen Treibern abh ngig und wird in den folgenden Treiberspezifikationen definiert Prinzipiell w rden f r Ein und Ausgabe auch je 8 Bit ausreichen dies w rde jedoch die M glichkeiten f r zuk nftige Erweiterungen unn tig einschr nken Aufgrund der Vor gabe eines 32 Bit Systems w rden des Weiteren keine Vorteile aus einer Beschr nkung auf 8 Bit entstehen Alle Lese und Schreibzugriffe auf einen einzelnen Speicherbereich m ssen atomar sein S mtliche nicht definierten Bits m ssen beim Auslesen ignoriert werden es darf nicht davon ausgegangen werden dass diese einen konstanten Wert haben Jeder Treiber und der SI
433. m glich ist dass ein Abschnitt in beide Richtungen befahren wird In dem Beispiel gleisnetz ist dies nicht der Fall und daher kann diese Sicherheitsbedingung hier nicht verletzt sein sr5 1 7 6 4 8 Safety Monitor F r den Safety Monitor wird eine Menge von Zust nden definiert die als sicher be trachtet werden Die Sicherheitsbedingungen wurden bekanntlich aus der Beschreibung des Gleisnetzes abgeleitet Im Gegensatz dazu werden diese Zust nde aus den in den Verschlusstabellen gemachten Angaben abgeleitet Wenn die dort gemachten Angaben nicht sicher sind sind demzufolge diese Zust nde auch nicht sicher In dem Beispiel werden 14 Zust nde als sicher angesehen stO s3013 state STOP amp g4125 ctr 0 amp g4129 ctr gt g4126 ctr amp w1022 state LEFT amp g4127 ctr gt g4128 ctr amp w1020 state RIGHT sti g4125 ctr gt g4126 ctr amp w1013 state RIGHT amp g4129 ctr gt g4130 ctr amp w1022 state STRAIGHT amp g4127 ctr gt g4128 ctr amp w1020 state RIGHT st2 s3013 state STOP amp g4125 ctr 0 amp g4129 ctr gt g4130 ctr amp w1022 state STRAIGHT amp g4127 ctr gt g4128 ctr amp w1020 state RIGHT st3 g4125 ctr gt g4126 ctr amp w1013 state RIGHT amp s3014 state STOP amp g4129 ctr 0 amp g4127 ctr gt g4128 ctr amp w1020 state RIGHT st4 s3013 state STOP amp g4125 ctr 0 amp s3014 state STOP amp g4129 ctr 0 amp g4127 c
434. m Typ boolean womit dort auftretende KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 102 Fehler leicht gemeldet und gef die weitere Ausfiihrung abgebrochen werden kann 7 2 3 2 11 TracsDXF2TND java Um nicht mehrere verschiedene Aufrufe t tigen zu m ssen um eine CAD Zeichnung im DXF Format in die TND Gleisnetzbeschreibung zu berf hren wurde eine bergeordnete Klasse TracsDXF2TND java geschaffen wel che letzlich nichts anderes macht als die drei genannten Hauptklassen der Reihe nach aufzurufen Dieser Klasse wird genau wie der Klasse DXF Separator java eine DXF Datei bergeben Zus tzlich wird aber auch das Ziel eine TND Datei angegeben Eine weitere Funktion ist das Aufrufen einer Auflistung s mtlicher Gleisnetzelemente Anhang E auf Seite 475 durch Angabe eines optionalen Parameters Die genauen Aufruf Parameter werden wie auch die einzelnen Arbeitsschritte bei der Gleisnetzerfassung und TND Erzeugung aus diesen Daten im Handbuch des Konver ters erl utert siehe Abschnitt 7 2 3 4 auf Seite 104 Die Detailansicht des Klassendiagramms f r diese Klasse Abb 7 13 zeigt die hierbei verwendeten Methoden und Attribute TracsDXF2TND TND_FILE_EXT final static String DXF_FILE_EXT final static String dxf BLOCKS final static Stringq blocks tmp tng ENTITIES final static String entities tmp tng ERROR final static boolean false TNDtarget static File DXFsource static File overwrite static boolean false err
435. m an deren Gleisst ck befindet das nicht an einem Ende dieser Geraden angeschlossen ist kollidieren Sind zwei nicht miteinander verbundene Gleisst cke r umlich den noch so nah zusammenliegend dass es zu Kollisionen zwischen Bahnen auf dem einen und dem anderen St ck kommen kann so werden diese eigentlich getrennten Elemente als ein Element n mlich eine Kreuzung betrachtet Auf einer Geraden gilt jeweils eine H chstgeschwindigkeit e Kurve Eine Kurve hnelt der Geraden nur dass ihr Verlauf nicht gerade ist Sie hat neben ihrer L nge demnach eine weitere Kenngr e den Kurvenradius Es kann in Kurven in Abh ngigkeit von Kurvenradius und Geschwindigkeit einer Bahn zu Entgleisungen kommen Folglich gilt eine physikalisch m gliche H chst geschwindigkeit in jeder Kurve Es kann jedoch nicht davon ausgegangen wer den dass eine dem Fahrer vorgeschriebene maximale Fahrgeschwindigkeit in jeder Situation sicher ist diese kann auch ber der physikalisch m glichen H chstge schwindigkeit liegen Der Fahrer muss hier also auch eigenst ndig sicherstellen in Kurven nicht wegen zu schneller Fahrt zu entgleisen KAPITEL 2 DIE DOMANE 20 e Kreuzung Eine Kreuzung hat vier Enden wobei jeweils zwei Enden einander zugeordnet sind Es lassen sich somit zwei Strecken bestimmen die sich genau wie die oben beschriebenen Geraden oder Kurven verhalten Eine an einem Ende einfahrende Bahn wird bei stetiger Vorw rtsfahrt die Kreuzung an dem zugeo
436. m befindet Auf die Weise wird keine Art Pathfinder zwischen Kopf und Ende ben tigt der eventuell eine gr ere Menge von Rechenzeit in Anspruch nehmen w rde Die L nge der Liste ist damit auf gt 1 festgelegt e Algorithmen Im Folgenden werden die Algorithmen vorgestellt die zur Bewegung der Trams notwendig sind Zuerst wird die Methode update vorgestellt Ausgehend von dieser Funktion werden dann die dort verwendeten Algorithmen drive checkStop calculatePosition drivelnto checkHeadCollision checkCollision und doFinish n her erl utert Tram updated missingSteps 1 else return the passed amp modified hardware Abbildung 7 68 Aktivit tsdiagramm Tram update Tram update Der Simulator ruft bei jeder Stra enbahn die Methode upda te auf um sie fortzubewegen Anhand der vor Start festgelegten Geschwindig keit der Bahn wird berechnet wie viele Schritte sie in diesem Simulatioszyklus fahren muss Dies wird in der Variablen missingSteps abgespeichert Dann pr ft die Tram ob sie sich fortbewegen darf Falls Ja ruft sie die Methode drive auf drive wird so oft aufgerufen bis die Stra enbahn keinen Schritt mehr KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 347 fortbewegt werden kann W hrend der Fahrt werden die berfahrenen Hardware Elemente bei denen sich dadurch etwas ge ndert hat Weichen und Sensoren in der
437. m getHeadPos int tailCoords new int 2 TrackElement tailTE tram getTailElement int tailPos tram getTailPos boolean tailDir tram getTailDir int hwCoords new int 2 TrackElement interTE null Hardware borders int length KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 391 int coords new int 2 1 borders tailTE getBorders length tailTE getLength coords 0 calcCoords borders 0 getCoords coords 1 calcCoords borders 1 getCoords tailCoords 0 coords 0 0 int double tailPos double length coords 1 0 coords 0 0 tailCoords 1 coords 0 1 int double tailPos double length coords 1 1 coords 0 1 Die Position der Bahn im Gleisnetz wird geholt die Position des Endes dabei bereits in Pixelkoordinaten umgerechnet Nun beginnt die Unterscheidung while headTE tailTE if tailDir headCoords coords 1 else headCoords coords 0 Falls Bahn Kopf und Bahn Ende nicht auf dem gleichen TE zu finden sind bedeutet dies dass der letzte Abschnitt vom Ende der Bahn bis zu einem Ende des TEs reicht abh ngig von der Fahrtrichtung ist welches Ende des TE ber cksichtigt werden muss drawTram g TAIL_TAIL headCoords 0 headCoords 1 tailCoords 0 tailCoords 1 TRAM_WIDTH tailCoords 0 headCoords 0 tailCoords 1 headCoords 1 Der Abschnitt wird gezeichnet Als n chste En
438. makeSlipswitch char cross struct idlist_t pointlist long int switchtime KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 157 erstellt aus den tibergebenden Werten einen einzelnen Slipswitch Eintrag Als n chstes folgt die Auswertung des Relation Blocks Die Reduzierung auf den rel block erfolgt wie auch bei den anderen Bl cken durch das Erkennen des zugeh rigen Schl sselworts und der nachfolgenden Liste relblock RELATIONS reldeflist Durch folgende Regel ist es m glich mehrere reldefs zu haben reldeflist reldef makeRelationList reldef reldeflist makeRelationList Der Aufruf der Funktion struct relation_t makeRelationList struct relation_t newrel struct relation_t oldlist f gt die einzelnen Relation Eintr ge zu einer Liste zusammen Zu einer einzelnen reldef kann nun folgenderma en reduziert werden reldef sensid_side marklistoptkomma elementid_side makeRelation crossid_side marklistoptkomma elementid_side makeRelation pointid_side marklistoptkomma elementid_side makeRelation sensid_side marklistoptkomma een makeRelation Die Funktion struct relation_t makeRelation struct elementid_side_t elemi struct elementid_side_t elem2 struct idlist_t marks int een erh lt als Eingaben die beiden Elemente mitsamt ihren Seitenangaben die Idlist mit den Marks und einen Wert f r
439. manent ber die aktuellen Zust nde der Signale informiert sein Die Signale im Simulator befolgen die Anweisungen vom SI e Interaktion Weichen gt SI Der SI muss permanent ber die aktuellen Zust nde der Weichen informiert sein Die Weichen im Simulator befolgen die Anweisungen vom SI Da die Kommunikation bidirektional ist und eine Menge Daten praktisch gleichzeitig hin und hergeschickt werden m ssen ist eine effiziente und pr zise formulierte Schnittstelle von N ten Die Datenpakete sollten daf r m glichst klein sein 7 8 2 5 Korrektheit Der im Projekt TRACS zu entwickelnde Simulator ist kein zentrales Modul des Pro jektes und wird nicht in die Kette von Verifikationen im Projekt eingebunden Bei der KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 321 Entwicklung muss folglich darauf geachtet werden dass dieser korrekt funktioniert Ziel des Simulators ist die M glichkeit den Steuerinterpreter anschaulich testen zu k nnen Wenn bei diesem Testen Fehler auftreten gibt es beim Zusammenspiel von Steuerinterpreter Treibern und Simulator folglich drei Fehlerquellen Die Treiber sollen m glichst simpel gehalten werden und es besteht nach Meinung der Autoren eine sehr hohe Wahrscheinlichkeit dass diese entweder permanent deutliche Fehler produzieren oder korrekt funktionieren Bevor man im Weiteren auf einen Fehler im SI sucht sollte auch die Fehlerquelle Simulator zuvor berpr ft werden Um im Voraus die Fehlerwa
440. mente Simulator e Schnittstelle zu den Treibern e Einlesen des Gleisnetzes Nun folgt eine kurze Beschreibung der Klassen und Erkl rung der Vererbungsstruktur e Gleisnetz Elemente Simulator Die Gleisnetz Elemente beinhalten alle Gleiselemente aus realen Stra enbahnnet zen die sich auf oder neben der Strecke befinden und elektronisch ansteuerbar oder abfragbar sind und f r die sichere Fahrt eine Rolle spielen Des Weiteren werden im Folgenden die Route und der Simulator definiert KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 330 Hardware Hardware bildet die Vaterklasse f r alle Elemente eines Gleisnetz ausge nommen den Gleisen selbst s TrackElement Abgeleitete Instanzen der abstrakten Klasse Hardware besitzen eine eindeutige Identifikation und Ortskoordinaten SwitchableHW SwitchableHW ist eine abstrakte Klasse f r schaltbare steuerbare Hard ware Elemente Diese Klasse enthalt als Membervariablen Typ Zustand ei nen angeforderten Zustand und die Schaltzeit und erbt von der Klasse Hard ware Turnout Turnout simuliert eine Weiche Diese Klasse ist abgeleitet von Switchab leHW und implementiert das Interface Linkable Eine Weiche hat einen bestimmten Typ und kann bestimmte Zust nde annehmen Der angeforderte Zustand wird eingenommen nachdem die Schaltzeit verstrichen ist Es gibt eine Lock Variable welche die Weiche f r automatisches Umstellen sperrt Weichensp
441. mer waren ebenfalls bald als Abg nge zu verzeichnen 9 2 6 1 2 Ung nstige Gruppeneinrichtung Die urspr nglichen Arbeitsgruppen wurden auf Wunsch der Projektbetreuer und des in jenem Semester amtierenden Pro jektmanagements relativ zu Beginn des Projektes eingeteilt Diese Einteilung gleich am Anfang des Projektes vorzunehmen hat sich im Nachhinein als fatale Fehlentscheidung herausgestellt Die Gruppen konzentrierten sich fortan vor allem auf ihren Bereich wobei der Blick f r das Gesamtprojekt weitgehend unterging Im Nachhinein betrachtet h tten eher andere Teilgruppen wie z B f r Weltmodell und EVP zu diesem Zeitpunkt ein gerichtet werden m ssen da diese Gruppen die Grundlagen f r alle weiteren folgenden Gruppen h tten legen k nnen Bei dem beschrittenen Vorgehen wurden diese wichtigen Themen daher erst sp ter zu sp t behandelt KAPITEL 9 BEWERTUNG 450 9 2 6 1 3 Unsystematische Arbeitsweise In mehreren Gruppen wurde zum Teil relativ unkoordiniert und unsystematisch gearbeitet Dies u erte sich z B bei der Auf stellung des Zeitplanes siehe weiter unten oder darin dass Spezifikationen nicht als n tig erachtet und vernachl ssigt wurden Zu Zeitpunkten da andere Gruppen von den Ergebnissen einer so arbeitenden Gruppe abh ngig waren blieben die negativen Wir kungen nicht aus 9 2 6 1 4 Inter Gruppen Kommunikation Die Kommunikation zwischen den unterschiedlichen Arbeitsgruppen verlief nicht in allen F llen zuf
442. mit dem Kopf handelt wird nun der Kopf gezeichnet Es wird weiterhin die Methode setStroke verwendet Wieder wird die Breite der Tram als Parameter bergeben und der zweite Parameter lautet diesmal BasicStroke CAP_ROUND was bedeutet dass Ecken abgerundet sein sollen Die Ecken werden so stark abgerundet dass sich ein Halbkreis am Ende der Linie bildet Es wird KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 390 jedoch nichts von der Linie abgeschnitten sondern die Linie wird um width 2 verl ngert s Abbildung 7 81 Dann wird die Farbe auf Cyan gesetzt und eine Linie gezeichnet die nur aus einem Punkt besteht Durch BasicStroke CAP_ROUND wird die Linie aber verl ngert und abgerundet so dass sich ein Kreis ergibt CAP_BUTT width AP_ROUND ow nn width 2 Abbildung 7 81 Tram zeichnen Unterschiede bei Pinselstrichen N gt I 1 23 Abbildung 7 82 Tram zeichnen Koordinaten 7 8 5 3 2 Zeichnen der gesamten Bahn Die gesamte Bahn besteht je anch ihrer Position aus einem bis hin zu vielen Abschnitten Darunter ist jedoch nur ein Abschnitt der den Kopf enth lt alle anderen sehen abgesehen von ihrer L nge gleich aus Dies wird ausgenutzt indem die Abschnitte der Bahn von hinten nach vorne durchgegangen werden der letzte zu zeichnende Abschnitt ist dann immer derjenige mit dem Kopf private void drawTram Graphics g Tram tram int headCoords new int 2 TrackElement headTE tram getHeadElement int headPos tra
443. mit vier Parametern posArr enth lt die Position der Tram auf dem aktuellen Gleisst ck teArr ist das aktuelle TrackElement und dirArr bezeichnet die Richtung in der die Tram auf dem Gleisst ck unterwegs ist Statt Integern und TrackElement werden Arrays diesen Typs bergeben die nur den einen Integer bzw das eine TrackElement enthalten Der Grund daf r ist dass die bergebenen Parameter von der Methode ver ndert werden sollen Da es in Java Mnicht m glich ist eine Referenz auf einen primitiven Datentypen wie Integer als Parameter zu bergeben muss man eine andere L sung finden Die M glichkeit die hier verwendet wurde ist den Integer in einem Array zu verpacken denn Arrays sind Objekte und Objekte werden immer per Referenz bergeben und k nnen somit von einer Funktion ge ndert werden vgl Kr 00 S 197 Letzter Parameter ist ein boolscher Wert der angibt ob die Berechung gerade f r den Kopf oder das Ende der Bahn stattfindet Dies ist n tig um in Situationen wie dem Einfahren oder Verlassen des Gleisnetzes richtige Berechnungen vorzunehmen beim Einfahren darf sich solange die Bahn nicht in voller L nge im Netz ist nur der Kopf voran bewegen beim Verlassen nur das Ende Den ersten Einsatz dieses Parameters kann man gleich sehen In der Variablen emerge ist abgelegt wie viele Schritte die Bahn noch braucht bis sie in voller L nge im Gleisnetz ist so lange darf nur der Kopf bewegt werden und entsprechend liefe
444. n forderungen von der Hardware zur Shared Memory Schnittstelle gelangen k nnen Das Problem ist dass kaum Informationen zu den Schnittstellen zu konkreter Gleishardware gibt Entsprechende Fragen sind Bestandteil der Frageliste an Hanning und Kahl ge wesen Diese Frageliste wurde aber nicht beantwortet Dadurch stehen die notwendigen Informationen nicht zur Verf gung um den obengenannten Weg vollst ndig zu beschrei ben Innerhalb des Projektes erfolgten daher keine weiteren Arbeiten an diesem Weg ausser dieser Beschreibung Es wurde jedoch schon deutlich dass bei Hanning und Kahl ausserhalb des Schaltschranks keine Digitaltechnik eingesetzt wird wobei Hanning und Kahl ihr System Schaltschrank und Bahntechnik nur komplett verkaufen Eine weitere KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 182 Frage ist wieweit Intelligenz auf den Schnittstellenkarten die bei Hanning und Kahl verwendet werden z B in Form von kleinen billigen Mikrocontrollern vorhanden ist so dass dort sich auch Software befindet die dem Treiber Arbeit abnehmen kann Fehlt diese Intelligenz und m ssen dadurch serielle Protokolle bitweise generiert werden dann k nnen schwierige Timingprobleme im Mikrosekundenbereich entstehen Im folgendes werden exemplarisch ein paar M glichkeiten gezeigt wie man digitale Ein Ausg nge erhalten kann an die man z B Leuchtdioden und Taster anschlie en kann Das w re immerhin eine Ann herung an den realen Einsatz da man
445. n Da der RC f r seine Entscheidung nur die Ist Zust nde von Weichen Sensoren und Signalen sowie Timern beobachtet und dabei auch nur auf das Gegebensein bestimmter Zust nde pr ft reicht es aus f r jedes Element lediglich verschiedene g ltige Ist Zust nde als Te steingabe zu verwenden Gegen die Sicherheitsbedingungen versto ende Zust nde wer den vom RC nicht beachtet und m ssen daher nicht generiert werden Am einfachsten f r die Implementierung ist es bspw bei Weichen ungeachtet ihres Typs einfach zwi schen den Zust nden links geradeaus und rechts zu variieren bei Signalen analog dazu noch die RR Anzeigen mit einzubeziehen bei Sensoren die Z hler zu variieren da hier prinzipiell der Wertebereich nach oben offen steht wurde eine Begrenzung von 0 bis 4 f r die Tests beschlossen und bei Timern zwischen laufend und nicht laufend zu unter scheiden Eine weitere Einschr nkung ergibt sich dadurch dass jeweils nur die f r die aktuelle Route relevanten Elemente betrachtet werden m ssen Die Route State Table muss beim RC Test anders als beim RD nicht komplett durch kombiniert werden es ist lediglich der f r die aktuelle Route geltende Wert zu ver ndern Bei den beiden Z hlern st nde der Bereich der m glichen Testwerte nach oben offen daher muss hier eine k nstliche Begrenzung vorgenommen werden Es wurde festgelegt als Bereich f r beide Z hler jeweils die Werte von 0 bis 4 einschlie lich zu verwenden 7 7 5 3 2 Tes
446. n die angibt wann der jeweilige Sensor erreichbar ist g4023 sensor g4023_cond g4025 sensor g4025_cond g4027 sensor g4027_cond g4125 sensor g4125_cond g4126 sensor g4126_cond g4127 sensor g4127_cond g4128 sensor g4128_cond g4129 sensor g4129_cond g4130 sensor g4130_cond 7 6 6 4 3 Erreichbarkeitsbedingungen Ein Sensor kann erreicht werden wenn ein anderer Sensor von dem der jeweilige Sensor erreichbar ist bereits erreicht wurde und die Signale und Weichen entsprechend gestellt sind Eine Ausnahme stellen Route KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 248 Request Sensoren dar Diese werden erreicht wenn eine Route befahren werden soll die den jeweiligen Sensor als Route Request Sensor hat So ist in dem Beispiel g4023 der Route Request Sensor der Routen route23 und route24 Wenn eine dieser Routen befahren werden soll wird g4023 demzufolge er reicht g4023_cond case route_A route23 route_B route23 1 route_A route24 route_B route24 1 12 05 esac g4025_cond case route_A route25 route_B route25 1 route_A route26 route_B route26 1 1 0 esac g4027_cond case route_A route27 route_B route27 1 route_A route28 route_B route28 1 1 0 esac Wenn eine Bahn von einem Sensor auf einen Nachbarsensor zuf hrt und sich zwischen den beiden Sensoren ein Signal befindet so wird der Nachbarsensor nur erreicht wenn das
447. n erreichen zu k nnen Ein genaues Vorgehen muss hier noch entwickelt werden Helge L ding 7 7 7 3 System under Test Um die W Methode aus Ch078 anwenden zu k nnen ist es n tig dass der Testling in seinen Startzustand versetzt werden kann da jeder Testfall vom Startzustand ausgeht Hierzu sind entsprechende Mechanismen noch zu entwickeln Zun chst wird vorgeschlagen dass der Testling vom Testsystem im laufenden Betrieb abgebrochen und f r jeden Testfall neu gestartet wird Dies kann aber negative Folgen f r die Durchf hrbarkeit aller Tests haben da sich deren Laufzeit hierdurch deutlich verl ngern kann Alternativ w re ein Reset Mechanismus innerhalb der Testlings vorstellbar Dies w re allerdings eine Massnahme die einen Eingriff in den Testling erfordern und somit intru sives Testen bedeuten w rde Helge L ding 7 7 7 4 Testgenerator Um Integrationstests durchf hren zu k nnen wird ein Testgenerator entwickelt der als Eingabe die wie oben beschrieben hergeleitete flache Spezifikation eines Safety Con trollers erh lt Aus dieser Spezifikation gehen dann mithilfe der W Methode Cho78 Eingaben an den Testling hervor die vollst ndige Zustands und bergangs berdeckung der Spezifikation des Testlings garantiert Da der Testling aus Sicht von Integrations tests als Eingaben nur den Ist Zustand eines Gleisnetzes in Form von Shared Memory Daten erh lt werden Stimulationen des Testlings vom Testgenerator entsprec
448. n geeignet und vollst ndig sind e Verifikation stellt sicher dass jedes einzelne Entwicklungsprodukt mit der Spezi fikation konsistent ist vollst ndig e Test stellt sicher dass das implementierte Steuerungssystem die erwartete Auf gabe erf llt unvollst ndig Eine kurze Zusammenfassung des Entwicklungsprozesses ist in Abbildung 6 1 auf der n chsten Seite zu sehen Die Abbildung zeigt dass es drei wichtige Schritte in der Entwicklungsphase gibt 50 KAPITEL 6 VALIDIERUNGS VERIFIKATIONS UND TESTPROZESS 51 grafische Gleisnetzbeschreibung Verschlusstabellen TND Gleisnetzbeschreibung bin re Konfigurationsdaten gleisnetzspezifische Steuerungssoftware fertiges Steuerungssystem Abbildung 6 1 Entwicklungsprozess N TND Tram Network Description internes Zwischenformat e Erstellung einer dom nenspezifischen Beschreibung TND e Erstellung einer gleisnetzspezifischen Steuerungssoftware e Erstellung des fertigen Steuerungssystems Die TND besteht aus einer Beschreibung des jeweiligen Gleisnetzes einer Hardwarebe schreibung und einer Routenbeschreibung die die in den Verschlusstabellen gemachten Angaben wiedergibt Bevor die TND vom Compiler verarbeitet wird soll berpr ft wer den ob sie auch alle f r das Gleisnetz spezifizierten Hardwareelemente und die Nachbar schaftsbeziehungen zwischen diesen Elementen korrekt wiedergibt Zudem soll berpr ft werden ob alle Routen g ltig sind also so be
449. n Compiler Konstruktions Werkzeugen nicht rechtzeitig berdacht Im Folgenden gehen wir n her auf die einzelnen Aspekte ein und beschreiben wie es dazu gekommen ist und was wir daraus gelernt haben KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 423 7 8 8 1 1 Zeitplan Arbeitspakete Die Simulatorgruppe hat es vers umt sich zu Beginn ihrer Arbeit einen Zeitplan aufzustellen und Arbeitspakete einzuteilen Das Fehlen eines Zeitplans hat es f r das Projektmanagement schwierig gemacht die Fortschritte des Simulators zu verfolgen und die Einhaltung des Gesamtzeitplans von TRACS zu bestimmen Zwar waren die Arbeitsergebnisse nach einem Semester durchaus zufriedenstellend doch das war nicht unbedingt abzusehen und h tte auch schief gehen k nnen Die Arbeitspakete wurden nicht von vornherein festgelegt dennoch haben sie sich sehr schnell ergeben da ein Gro teil der Arbeit von Einzelpersonen zu Hause erledigt wurde und daf r die Arbeit irgendwie aufgeteilt werden musste Die Gefahr hierbei war jedoch dass Arbeitspakete vergessen werden In der Tat es wurden Arbeitspakete vergessen die gl cklicherweise jedoch weder unseren Zeitplan gef hrdeten noch andere Arbeiten schwieriger gestalteten Dies ist der Vorteil einer Arbeitsgruppe die nur an wenigen Stellen mit dem Rest des Projektes verkn pft ist Ab dem zweiten Semester der Arbeit am Simulator d h dem dritten Projektsemes ter insgesamt wurde nach einem Zeitplan gearbeitet Dieser konnte a
450. n beschrieben Visualisierung An dieser Stelle werden die Konzepte zur Visualisierung des Gleisnetzes samt Stra enbahnen aufgezeigt Treiber zur Anbindung an den SI In diesem Unterkapitel wird die Schnittstelle zwischen Simulator und den Trei bern die der SI zur Steuerung der Simulation benutzt Ablauf und Format der Nachrichten beschrieben Korrektheit Konzepte zur Sicherstellung der Korrektheit des Simulators werden an dieser Stelle aufgezeigt und erl utert Echtzeitf higkeit Die Struktur welche dazu f hrt dass der Simulator ein Echtzeitsystem sehr pr zise simuliert wird hier n her beleuchtet KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 325 e Hardware Zuletzt wird die Zielhardware beschrieben fiir die der Simulator entwickelt wird 7 8 4 1 Programmiersprache Zur Programmierung eines Simulators mit vielen gleichen Elementen bietet sich das Konzept der objektorientierten Programmierung OOP an OOP geht von der Grund lage aus dass Objekte programmiert werden die sowohl Daten als auch Algorithmen enthalten Das Gegenteil findet man in der prozeduralen Programmierung in der diese beiden Elemente getrennt von einander programmiert werden Einige verbreitete OOP Sprachen sind Java C Simula und Smalltalk von denen die letzten beiden aber wegen mangelnder Kenntnisse der Simulatorgruppe ber diese Sprachen von vornherein ausgeschlossen waren Um die Entscheidung zu treffen ob nun Javat oder C verwen det
451. n der TND eingetragenen maximalen Schaltzeit umgeschaltet Falls dem so ist wird die Umschaltung vor genommen und gleichzeitig vermerkt dass eine solche stattfand Weiterhin wird beim Hardware Update im Fall von Weichen und Kreuzungen ein evtl Besetzt Zustand zur ckgesetzt falls im vorigen Zyklus die sich auf dem Element befindliche Bahn von diesem entfernt hat Dieses R cksetzen kann nicht sofort im Zeitpunkt des Verlassens ausgef hrt werden da ggf im selben Zyklus andere Bahnen auf das Element auffahren w rden Die Reihenfolge in der in dem Zyklus die Bahnen bewegt w rden h tte dann Auswirkungen darauf ob eine Kolli sion erkannt wird oder nicht Mit diesem nachgelagerten R cksetzen wird erreicht dass in der gegebenen Situation in jedem Fall eine Kollision erkannt wird In der Grafik 7 66 ist der Normalfall f r ein unbesch digtes Element zu sehen Ein KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 342 defektes Element wird dagegen nicht umschalten oder dann umschalten wenn es nicht verlangt ist 4 StraBenbahnen aktualisieren Nach der stellbaren Hardware werden als n chstes die Stra enbahnen fortbewegt Durch die Stra enbahnen k nnen sich auch die Zust nde von Hardware Elementen ver ndern De aktivieren eines Sensors passives berfahren einer Weiche Der Simulator sammelt die durch die Stra enbahnen ver nderten Hardware Elementen und f gt sie der Liste die er im vorherigen Schritt erstellt hat hinzu Auch St
452. n hat Die Vor und Nachteile der Benutzung dieser Werkzeuge sind in Tabel le 7 1 auf der n chsten Seite grob zusammengefasst und werden gegen bergestellt Das Mehr an Programmieraufwand ohne CKWs ist offensichtlich da CK Ws ja Quellcode generieren und somit einen Teil des Programmieraufwands ersetzen Gleichfalls ersicht lich ist der erh hte Einarbeitungsaufwand bei der Verwendung von CKWs da man sich hier erst einmal mit der Beschaffung der Installation der Verwendung und mit der Spezifikation besch ftigen muss die ein CKW braucht um daraus etwas zu generieren Bei einem Verzicht auf CKWs ist die Vermischung von Scanner und Parser m glich Zwar ergeben sich dadurch teilweise Optimierungsm glichkeiten durch sehr individuel le Anpassung der Implementierung gleichzeitig erh ht sich aber auch die Gefahr dass die Vermischung zweier in der Theorie eigenst ndige Teile die Fehlerwahrscheinlichkeit in der Implementierung erh ht CKWs trennen hier im Allgemeinen ganz klar auch um ihre eigene Komplexit t in Grenzen zu halten und diese strukturierte Generierung verhindert logische Fehler im Aufbau des Compilers vorausgesetzt die dem Generator zugrunde liegende Grammatik ist korrekt Eine eigene Implementierung des Compilers erm glicht kein direktes Herauslesen der Grammatik aus dem Quellcode w hrend bei der Benutzung von CKWs solch eine Gram KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 336 Compiler Konstruktions Werkzeuge ohne mit Un
453. n von Gleisnetzelementen zu definierten Routen Hier finden sich etwa Vorgaben ber Weichenstellungen f r bestimmte Routen oder Angaben ber Signalstellungen f r das Freigeben oder Sperren von einzelnen Routen Diese In formationen werden innerhalb des tram Compilers umgesetzt in konkrete Steuerimpulse f r Gleisnetzelemente nach Routen Unser Beispielsignal s3001 etwa muss die Routen route01 route02 und route03 freischalten und wieder sperren wenn sie befahren wer den sollen Konktete Signal Steuerimpulse f r die einzelnen Routen dementsprechend dem TRACS Steuerinterpreter zur Verf gung gestellt clearances route01 s3001 straight route02 s3001 straight route03 s3001 right Analog werden auch Weichenstellungen pro Route ausgewertet 7 4 2 1 3 Konfliktinformationen Innerhalb der TRACS TND sind Informationen dar ber enthalten welche Routen gleichzeitig befahren werden d rfen und welche Rou ten bei gleichzeitiger Befahrung kollisionsgef hrdet sind Aus diesen Informationen ent steht eine bin re Tabelle die es dem TRACS Steuerinterpreter erm glicht effizient zu entscheiden welche angeforderten Routen freigegeben werden d rfen Es folgt ein Bei spiel f r solche Konflikinformationen point conflicts route01 route02 route03 route06 route02 route01 route03 route05 route03 route01 route02 conflicts route01 route04 route05 route06 route08 route10 routei2 KAPITEL 7 BESCHREIBUNG DER KOMP
454. n vor einem roten Einfahrtssignal steht e Schalten von Signalen auf Rot durch den Safety Monitor Da auf Sicherheitsverlet zungen anhand des Sollzustands gepr ft wird werden gef hrliche Anforderungen des Route Controllers gar nicht erst weitergeleitet liegt in dem Fall dennoch kein sicherheitskritisches Zeitproblem vor Da aber der Safety Monitor aber auch gegen selbstt tiges Schalten der Weichen aktiv sein muss gibt es in dem Fall dennoch ein sicherheitskritsches Zeitproblem e Reaktion auf Bahnen die ein rotes Signal berf hrt Hier sollte so schnell wie m glich der sichere Zustand eingenommen werden Bei Fehlverhalten des Fahrers k nnen aber keine Sicherheitsgarantien gegeben werden e Erkennen von an Sensoren vorbeifahrenden Z gen Diese Information darf auf kei nen Fall verloren gehen da Routen nicht freigegeben oder zum richtigen Zeitpunkt wieder gesperrt werden k nnten e Reaktion auf Ablauf von Timern Timer geben stets eine Mindestzeit Mindestzeit die auf das Schalten von Weichen gewartet werden soll Mindestzeit die eine Bahn hat um in einer bereits gesperrten Route den ersten Sensor zu erreichen an wenn eine berschreitung ist daher auch nicht sicherheitskritisch Zur Verdeutlichung Wenn eine Weiche die maximale Schaltzeit berschreitet schadet es nicht wenn ihr da vielleicht mal noch eine Sekunde zus tzliche Zeit gelassen wird e Hardwareansteuerung durch Treiber Auf Grund fehlender Informationen k nnen
455. n werden k nnen wird eine Fehlermeldung angezeigt Hier wird ein Beispiel f r korrekte Nachbarschaftbeziehungen angegeben Das betreffen de Gleisnetz ist in Abbildung 7 27 auf der n chsten Seite zu sehen Zum Beispiel hat eine Route als Eingangssensor den Sensor 4101 und als Ausgangssensor 4105 Falls das Eingangssignal dieser Route nicht 3001 ist wird eine Fehlermeldung angezeigt dass Eingangssignal und Eingangssensor nichts bereinstimmen Falls der Route Request Sensor nicht 4001 ist wird eine Fehlermeldung angezeigt dass Route Request Sensor und Eingangssensor nichts bereinstimmen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 129 4012 4011 4010 4001 4002 4003 RR Sensor gt TG Sensor Signal Abbildung 7 27 Beispielgleisnetz Falls die Weiche 1001 fiir die betreffende Route nicht geradeaus gestellt ist wird eine Fehlermeldung angezeigt dass die Einstellung der Weiche nicht zu dem Ausgangssensor der Route f hrt Deng Zhou 7 3 3 Installation 7 3 3 1 Hardwareanforderungen Das Programm ben tigt einen IBM kompatiblen PC mit mindestens 32M RAM 7 3 3 2 Softwareanforderungen Das Programm braucht JDK JRE 1 4 oder h here Version 7 3 3 3 Package Wir liefern den TND Builder sowohl als vorkompiliertes Bin rprogramm JAR Datei wie auch als Quellcode Wer das Programm direkt ausf hren m chte braucht nur diese JAR Datei zum JA VACLASSPATH hinzuzuf gen und das Programm mit folgendem B
456. n wir den RT Tester das Werkzeug das wir zum Testen unseres Systems benutzt haben Es gibt verschiedene Typen von Test Spezifikationen Urspr nglich war es so dass f r jeden Typ das entsprechende Test Tool benutzt werden musste z B f r Unit Tests ein Werkzeug das auf low level Software Anforderungen basiert und f r die anderen Tests wieder deren entsprechende Tools so dass man mit vielen unterschiedlichen speziellen Tools arbeiten musste Der RT Tester macht dies nun als ein einziges Tool f r alle Typen von Tests Die Abbil dung 7 50 auf der n chsten Seite zeigt den urspr nglichen Testansatz Abbildung 7 51 auf Seite 261 zeigt den Aufbau des RT Testers Beide stammen aus PZ99 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 260 SUT Test Tool Test Specifications Tool 4 Module low level SW requirements We See Tool level SV regu ireme rts Abbildung 7 50 Urspriinglicher HW SW Testansatz Abstract Machine Layer Der Abstract Machine Layer AML besteht aus den Abstract Machines AMs die vor kompilierte ausfiihrbare Test Spezifikationen in Echtzeit interpretieren Dabei k nnen AMs parallel zueinander Tests durchf hren AMs implementieren einen Algorithmus um die Test Daten automatisch zu erzeugen Generator und pr fen automatisch die Reaktion vom SUT Checker Die Schnittstellen werden als Channels bezeichnet Diese Channels werden auf einer abstrakten Stufe kodiert und genutzt die von den konkreten So
457. nbahnen werden mit Form eines Rechtecks gezeichnet Der Kopf wird durch eine andere Farbe und durch eine runde Form gekennzeichnet berf hrt die Stra enbahn gerade ein Hardware Element so knickt sie in der Mitte s Abbil dung 7 76 auf der vorherigen Seite vierte Zeile Der Zwischenraum der auf der Au enseite entsteht wird nicht umst ndlich ausgef llt sondern bleibt erhalten aufgrund der untergeordneten Rolle der Formsch nheit e Gleise Gleise werden durch d nne Linien visualisiert Da ein Gleisst ck keine Kr mmung aufweisen kann handelt es sich um eine einfach Gerade mit Start und Endpunkt die gezeichnet wird Die Linie ist im Normalfall ohne Farbe bzw Farbe schwarz gehalten Zu beachten ist dass Gleise nicht eigenst ndig gezeichnet werden son dern zusammen mit den angrenzenden Hardware Elementen Immer wenn eines der o a HW Elemente gezeichnet wird werden die angrenzenden Gleise jeweils in halber L nge mitgezeichnet die fehlende zweite H lfte wird ja dann mit dem dort angrenzenden HW Element zusammen gezeichnet e Signale Signale stehen neben den Gleisen an ihren definierten Ortskoordinaten und wer den durch quadratische K stchen visualisiert Dei der Symbolisierung der Zust nde wird sich weitgehend an der Darstellung der echten Symbole orientiert Demnach ist der waagerechte Balken das Haltsignal der senkrechte ein Go straight der von links unten schr g nach rechts oben f hrende Balken ein Go righ
458. nd Attribute Die Anzahl der Attribute ist im Vergleich zu der der Methoden recht gro da wie be schrieben die TND intern als eine Aneinanderreihung von Zeichenketten repr sentiert wird Die diversen String Attribute stellen eben jene Zeichenketten her welche nach und nach beim Auslesen der Objekte aus den Element Containern ArrayLists gef llt werden Dies ist erforderlich da ein Objekt Gleisnetzelement Informationen f r mehrere Teile der TND enth lt zum Beispiel Koordinaten und bestimmte Properties Eigenschaften etc Die Methoden sind zum Teil f r das Auslesen der Sortier Container da z B extractSi gnalData f r die evtl vorkommenden Signale In diesen Methoden wird dann auch die oben beschriebene letzte Aufbereitung der Daten vollzogen Die Methode erxtractSlipSwitchData ist nur in der Test Version verf gbar da sie nicht ausreichend getestet werden konnte siehe dazu Abschnitt 7 2 3 2 13 auf Seite 103 Ein andere Teil der Methoden ist f r das Zusammensetzen der TND Datei als solches zust ndig F r jeden einzelnen Block existiert eine Methode z B coordBlock f r den Koordinaten Block In buildTND wird die TND dann endg ltig zusammengesetzt Um aber berhaupt die Daten des Gleisnetzes zu erhalten muss zuerst das Sammeln der Daten initiert werden indem die Klasse NGDataCollector java instanziiert wird Dies geschieht mit Hilfe der Methode dataCollector Die Methoden sind zu einem gro en Teil vo
459. nd ist Es gilt der Stell zeitpunkt nicht der Zeitpunkt an dem die Anweisung eingeht e Eine Bahn wird an ein totes Ende des Gleisnetzes geleitet e Eine Bahn erreicht eine Ausfahrt aus dem Gleisnetz hat aber ihre verlangte Route nicht absolviert wurde also fehlgeleitet 7 8 7 3 Optionen In diesem Abschnitt werden nun alle Men punkte detailliert beschrieben 7 8 7 3 1 Main Menu New Simulation Setzt eine Simulation in den Zustand vor der Konfiguration zur ck Alle Bahnen werden entfernt alle Schaltelemente gehen in den Zustand undefined ber Um die Simulation zu starten muss nun zun chst eine Konfiguration vorgenommen werden Diese Option ist nur verf gbar wenn bereits ein Gleisnetz geladen wurde Die Tastenkombination f r diese Option ist Ctrl N 7 8 7 3 2 Main Menu Load TND ffnet einen Dateiauswahldialog und l dt die ausgew hlte Datei Handelt es sich um eine korrekte TND kann nun die Konfiguration der Simulation vorgenommen werden Diese Option bewirkt quasi das Gleiche wie New Simulation nur dass noch ein Laden einer neuen TND vorgeschaltet ist Die Tastenkombination f r diese Option ist Ctrl L 7 8 7 3 3 Main Menu Quit Program Beendet den Simulator Die Tastenkombination f r diese Option ist Ctrl Q KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 419 7 8 7 3 4 Options Configure Random Simulation Leitet die Konfiguration einer Simulation ein bei der nur die Anzahl der Bahnen gew hlt werden s
460. nden bestimmter Belegungen geforderten Reaktionen sei an dieser Stelle auf den entsprechen den Teil der SI Spezifikation verwiesen Es folgen nun die relevanten Ausz ge aus dem Code des Weichentreibers static int driver_point_state_change struct driver_info drv u_int32_t in u_int32_t out KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 404 char send_buffer 64 char idbuf 6 sprintf idbuf 4d drv gt id if Cin 1 lt lt POINT_SET_STRAIGHT amp amp drv gt type TYPE_POINT_LR out drv gt old_out amp OUTPUT_MASK in strcpy send_buffer STR_REQUEST strcat send_buffer idbuf strcat send_buffer STR_STRAIGHT strcat send_buffer n send_msg drv gt private_data send_buffer else if in 1 lt lt POINT_SET_LEFT amp amp drv gt type TYPE_POINT_SR out drv gt old_out amp OUTPUT_MASK in strcpy send_buffer STR_REQUEST strcat send_buffer idbuf strcat send_buffer STR_LEFT strcat send_buffer n send_msg drv gt private_data send_buffer else if in 1 lt lt POINT_SET_RIGHT amp amp drv gt type TYPE_POINT_SL out drv gt old_out amp OUTPUT_MASK in strcpy send_buffer STR_REQUEST strcat send_buffer idbuf strcat send_buffer STR_RIGHT strcat send_buffer n send_msg drv gt private_data send_buffer else if in 1 lt lt POINT_SET_QUIT xout in 1 lt lt POINT_GET_OFF strcpy send_buffer STR
461. ne f r ihn unerwartete R ckmeldung dass eine Schaltung erfolgt sei erhalten Es wird daher nicht empfohlen diese Art der Eingabe f r solche Elemente zu nutzen f r die der SI gerade zust ndig ist M gliche Eingaben sind e f r Weichen request lt ID gt lt state gt wobei lt ID gt der vom Compiler vergebene Bezeichner nicht der aus der TND f r die Weiche ist lt state gt eine von drei m glichen Stellungen straight right left e f r Signale request lt ID gt lt state gt wobei lt ID gt der vom Compiler vergebene Bezeichner f r das Signal ist lt state gt eine der m glichen Stellungen straight right left stop waitstraight waitright waitleft rrstraighton rrstraightoff rrrighton rrrightoff rrlefton rrleftoff Die RR Anweisungen beziehen sich auf das An bzw Ausschalten der RR Anzeigen f r die jeweiligen Richtungen alle anderen Befehle d rften selbsterkl rend sein Wird eine Anweisung an eine Weiche oder ein Signal gegeben die dieses Element nicht erf llen kann z B weil es die entsprechende Anzeige nicht hat oder nicht f r die verlangte Rich tung zust ndig ist so f hrt das zu einem Fehler den der Simulator erkennt und genauso behandelt wie er unm gliche Schaltbefehle seitens des SI behandelt Im Normalfall l uft die Simulation nun so lange bis der Benutzer sie beendet Sie kann unterbrochen und unmittelbar an gleicher Stelle fortgesetzt werden Vorsicht bei Stopps mit angeschlossenem S
462. nen in denen z B die einzulesende Grammatik steht verwen den Des Weiteren muss im Projekt ber cksichtigt werden dass es jederzeit dazu kommen kann dass Projektteilnehmer das Projekt verlassen In diesem Fall muss gew hrleistet sein dass keine nicht schlie bare L cke entsteht bzw dass kein Quellcode von nieman dem mehr verstanden wird Ein vollst ndig selbst geschriebener Compiler der eventuell von einer einzigen Person geschrieben wurde l sst sich nur bei sehr strukturiertem und gut dokumentiertem Quellcode gut anpassen Da die Generierung sehr strukturiert vorgeht und die Compiler Konstruktions Werkzeuge bereits ausf hrlich getestet und do kumentiert sind sollte die Einarbeitung bei einem zumindest zum Teil generierten Compiler einfacher sein 7 8 4 3 4 Fazit Wir haben uns f r die Benutzung von Compiler Konstruktions Werkzeugen entschieden um Fehler bei einer eigenen Implementierung zu vermeiden und um schneller und einfacher auf Anderungen der einzulesenden Grammatik reagie KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 338 ren zu k nnen Der Simulator soll ein Test f r den Steuerinterpreter sein und wenn der Simulator auf fehleranf lligen Konzepten basieren w rde dann m sste bei vielen Fehlern eventuell erst einmal nachgeschaut werden ob der Fehler nicht beim Simulator liegt aus diesem Grund vertrauen wir lieber auf die langj hrige Weiterentwicklung der Theorie ber Compilerbau und verwenden die genannten Too
463. ner von mehreren Konfigurationsdialogen zum Starten einer Simulation SensorSettingDialog SensorSettingDialog ist einer von mehreren Konfigurationsdialogen zum Starten einer Simulation SignalSettingDialog SignalSettingDialog ist einer von mehreren Konfigurationsdialogen zum Starten einer Simulation TramCountDialog IramCountDialog ist einer von mehreren Konfigurationsdialogen zum Starten einer Simulation TramSettingDialog TramSettingDialog ist einer von mehreren Konfigurationsdialogen zum Starten einer Simulation TurnoutSettingDialog TurnoutSettingDialog ist einer von mehreren Konfigurationsdialogen zum Star ten einer Simulation AboutDialog AboutDialog ist ein allgemeiner Anzeigedialog zur Ausgabe von Informationen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 334 7 8 4 3 Flexibilit t Verarbeitung verschiedenster Gleisnetze Damit der Simulator seiner Aufgabe gerecht werden kann muss er verschiedenste Gleis netze simulieren k nnen Um sicherzustellen dass er das gleiche Gleisnetz als Grundlage hat wie der mit ihm verbundene Steuerinterpreter muss er inhaltlich gleiche Gleisnetz Konfigurationsdaten bekommen Diese liegen in einer Datei im Format TND vor Der Inhalt dieser TND Dateien befolgt eine festgelegte Grammatik die wiederum in EBNF Form im Projekt TRACS aufgeschrieben wurde siehe A 1 auf Seite 453 und A 2 auf Seite 456 F r den SI wird diese Datei mittels eines Compilers in B
464. nflicts Block werden m gliche Weichenkonflikte definiert Ein Weichenkon flikt besteht wenn f r eine Weiche f r unterschiedliche Routen unterschiedliche Wei chenstellungen angefordert werden Ein Weichenkonflikt f hrt also ebenfalls dazu dass die betreffenden Routen nicht gleichzeitig befahren werden d rfen Wenn f r eine Routenkombination ein Weichenkonflikt definiert wurde muss dieser auch tats chlich existieren Wurde kein Weichenkonflikt definiert dann darf auch keiner m glich sein Gelten diese beiden Bedingungen dann sind die im point conflicts Block enthaltenen Angaben korrekt Im Folgenden soll nun das Modell zum Pr fen der Verschlusstabellen erl utert werden Dazu soll wiederum die Teilstrecke 4 der Teststrecke als Beispiel dienen die in Abbil dung 7 48 angegeben ist 1023 1022 3014 a Ea 4025 RR Sensor Signal TG Sensor Abbildung 7 48 Strecke 4 Route Definition Table Route Route Request Sensor route23 84125 g4128 84023 route24 g4125 24126 4023 route25 84129 g4130 84025 route26 g4129 24126 4025 route27 g4127 g4130 84027 route28 g4127 g4128 84027 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 242 Point Position Table Route w1018 w1020 w1022 route23 straight route24 right route25 straight route26 left route27 straight route28 right Setting route23 s3013 straight route24 s3013 right route25 s3014 straight route26 s
465. nformationen aus den beiden Sektionen entfernt worden Der genaue Aufruf lautet java ng DXFSeparator lt DXF File gt 7 2 4 4 2 NGDataCollector Der zweite Schritt ist das Extrahieren der Gleisnetz daten aus diesen Zwischendateien Dies geschieht durch das Programm NGDataCol lector java welches die DXF Informationen soweit zerlegt so dass daraus die einzelnen Elemente eines Gleisnetzes bestimmt werden k nnen Diese Elemente werden intern in sogenannten Objekten gespeichert und in Listen nach Kategorien sortiert Diesem Programm werden die im vorangegangenen Schritt erzeugten Zwischendateien bergeben und man erh lt eine Liste aller im Gleisnetz enthaltenen Elemente Der genaue Aufruf lautet java ng NGDataCollector lt blocks tmp tng gt lt entities tmp tng gt KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 114 7 2 4 4 3 TNDCreator Der dritte und letzte Schritt ist das Erzeugen der TND Datei Dies geschieht mit Hilfe des Programms TNDCreator java Diesem Programm wird als Parameter einfach der Name der Zieldatei n mlich der zu erzeugenden TND Datei bergeben Es wird dabei angenommen dass sich jene Zwischendateien mit exakt den Namen wie sie erzeugt wurden im aktuellen Verzeichnis befinden Dieses Programm ruft die zuvor erw hnte Klasse auf um an die eigentlichen Element Daten zu gelangen Dabei werden die Elemente ausgelesen umgewandelt und der Output in die angegebene TND Datei geschrieben Der genaue Aufruf lautet java
466. ng werden im Simulator daher auch keine die Geschwindigkeit beeinflussende Umst nde ber ck sichtigt Haltestellen andere Verkehrsteilnehmer Fahrg ste geographische Gege benheiten Witterung e In der Simulation wird davon ausgegangen dass der Abstand in dem ein Signal gesehen werden kann immer gleich ist Damit wird eine Abstraktion f r das Fah rerverhalten bei unterschiedlichen Sichtweiten vorgenommen Kann der Fahrer in Realit t ein Signal erst sp t einsehen verringert sich sein Reaktionszeitfenster was er durch langsamere Fahrt wieder vergr ern m sste Im Endeffekt ist da mit das Reaktionszeitfenster in beiden F llen etwa gleich gro was mittels obiger Annahme simuliert werden kann e Das Fahrerverhalten in der Simulation wird durch zwei Regeln beschrieben Signa le die auf Stop schalten werden beachtet wenn die Bahn noch einen bestimm ten Mindestabstand zum Signal aufweist die vorgenannte Sichtweite andrenfalls f hrt die Bahn durch Auf vorherfahrende Bahnen wird nicht aufgefahren Das Be achten von Signalen durch den Fahrer kann allerdings auch abgeschaltet werden wenn solche Situationen simuliert werden sollen e Weichen Sensoren und Signale k nnen ausfallen oder Fehlverhalten aufweisen es ist jedoch irrelevant durch welche speziellen Umst nde dieses Fehlverhalten be wirkt wird Stromausf lle Hardwaredefekte Verschlei Daher werden auch solche Umst nde nicht ber cksichtigt sondern l
467. ngegeben Aus den dort enthaltenen Informationen werden die Projektierungsdaten erzeugt die zum Erstellen des Controller Modells ben tigt werden 1023 1022 3014 4130 a 4025 RR Sensor Signal TG Sensor Abbildung 7 47 Strecke 4 Im Route Definitions Table werden sechs Routen definiert F r jede Route werden die Sensoren angegeben die auf der Route liegen Zudem wird jeder Route ein Route Re quest Sensor zugeordnet In dem Beispielgleisnetz gibt es insgesamt drei Route Request Sensoren Die Namen der Routen und der Route Request Sensoren werden hier aus den Projektierungsdaten und nicht aus den eigentlichen Verschlusstabellen bernommen damit sie in der Modellierung wiedererkannt werden k nnen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 215 Route Definition Table Route Route Request Sensor 0 21125 24128 0 rl 24125 24126 r2 24129 24130 13 24129 24126 r4 g4127 g4130 r5 g4127 g4128 DVDHHOo Im Point Position Table wird definiert welche Weichenstellungen f r die jeweilige Route ben tigt werden Point Position Table Route w1018 w1020 w1022 r0 straight rl right r2 straight r3 left r4 straight r5 right Im Signal Setting Table wird definiert welche Signalstellungen f r die jeweilige Route ben tigt werden Signal Setting Table Route Setting r0 s3013 straight rl s3013 right r2 s3014 straight r3 s3014 left r4 s3015 straig
468. ngung cond_2 gibt an ob der Z hler zur ckgesetzt werden soll erf llt ist Die Variable state repr sentiert den aktuellen Zustand des Sensors Ein Sensor kann entweder im Zustand HIGH oder im Zustand LOW sein HIGH dr ckt aus dass der Sensor gerade erreicht wurde und LOW dass der Sensor wieder frei ist und von einer folgenden Bahn befahren werden kann MODULE sensor cond_1 cond_2 VAR state LOW HIGH ctr 0 35 ASSIGN init state LOW init ctr 0 next state case state LOW amp cond_1 HIGH state HIGH LOW 1 state esac next ctr case state LOW amp cond_1 ctr 1 cond_2 0 i setri esac KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 221 7 6 4 4 2 Initialisierung der Variablen F r die in einem Gleisnetz enthaltenen Sensoren werden Variablen erstellt Ausgenommen sind dabei die Route Request Senso ren die sp ter gesondert behandelt werden Es wird jeweils das Modul sensor aufgerufen und als Parameter werden die Bedingungen bergeben die angeben wann der Sensor erreichbar ist bzw wann der Z hler zur ckgesetzt werden soll g4125 sensor g4125_cond_1 g4125_cond_2 g4126 sensor g4126_cond_1 g4126_cond_2 g4127 sensor g4127_cond_1 g4127_cond_2 g4128 sensor g4128_cond_1 g4128_cond_2 g4129 sensor g4129_cond_1 g4129_cond_2 g4130 sensor g4130_cond_1 g4130_cond_2 7 6 4 4 3 Erreichbarkeitsbedingungen Wann ein Sensor erreichbar ist ist von den aus der B
469. nkt existieren Dort k nnten ggf mehrere Bahnen gleichzeitig abbiegen Zur Ansteuerung der Leilweichen der Kreuzungsweiche werden zwei Varianten ber cksichtigt individuelle Stellung der Teilweichen Kopplung der Teilweichen zu einem Gesamtsystem das nur zwei Stellungen hat alle Teilweichen auf geradeaus oder alle auf abbiegen 2 3 2 2 Sensoren Ein Sensor ist ein passives Element das sich auf an einem Gleis befindet Er kann also einem bestimmten Punkt auf dem Gleis zugeordnet werden Sensoren haben die KAPITEL 2 DIE DOMANE 22 Funktion dass sie wenn eine Bahn ber sie hinwegf hrt dem Steuersystem ber diesen Vorgang Auskunft geben Ubermittelt werden k nnen e die Tatsache dass sie berfahren wurden Toggle oder e die Tatsache dass zum aktuellen Zeitpunkt eine Bahn auf dem Sensor anwesend ist State Zus tzlich zu einer dieser beiden Optionen k nnen Sensoren ber Richtungserkennung verf gen also melden in welche Richtung sie berfahren wurden Als weiteren Typ gibt es auch noch Route Request Sensoren Diese dienen den Bahnen zum Anfordern einer Route durch das Gleisnetz Sie werden nicht von jeder sie ber fahrenden Bahn ausgel st sondern nur von denjenigen die die Route befahren wollen welche der Sensor verwaltet Diese Information welche Route sie befahren will muss von der Bahn bermittelt werden bspw Funk ber weitere Funktionalit t verf gt ein Route Request Sensor nic
470. nsam verwendbaren Speicherbereich zu haben Jeder Treiber hat einen ei genen Shared Memory Bereich von dem ein Teil der Sollbereich ist und ein Teil der Ist Bereich Genauere Informationen zu dieser Schnittstelle befinden sich im Abschnitt 7 5 3 1 Sobald alle Initialisierungen abgeschlossen sind werden in einer Endlosschleife fiir jeden aktiven Treiber die in der Spezifikation beschriebenen Callback Funktionen aufgerufen Es wird also f r jeden Treiber folgendes nacheinander durchgef hrt e die SHM Sollwerte ausgelesen und mit den vorhergehenden Werten verglichen e bei Abweichungen wird die Callback Funktion fiir Sollzustandswechsel aufgerufen e wenn vorhanden wird die allgemeine Ausf hrungsfunktion aufgerufen e bei Anderungen werden die SHM Istwerte geschrieben e Timer werden tiberpriift ob sie gestartet wurden oder abgelaufen sind e Sensorz hler werden verwaltet 7 5 2 3 Safety Controller In diesem Abschnitt wird der Aufbau der verschiedenen Komponenten des Safety Con troller beschrieben Der Safety Controller enth lt im Wesentlichen drei Komponenten Den Route Dispatcher RD eine Liste von Route Controllern RC und den Safety Monitor SM Der RD nimmt Route Requests von den Route Request Sensoren entgegen pr ft ob sie nach den entsprechenden Abschnitten der Projektierungsdaten aktiviert werden k nnen und markieren diese als aktiv Die einzelnen Route Controller berpr fen jeweils ob die entsprechende Route als aktiv mark
471. nserem Ergebnis zufrieden Ruben Rothaupt Taffou Happi KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 255 7 7 Hardware Software Test Heutzutage wird immer mehr von verschiedenen Computersystemen abhangig die die Kontrolle und Steuerung von vielen T tigkeiten im Leben bernehmen Das Spektrum reicht dabei von elektrischen Koch und Backger ten bis zu Steuerungssystemen deren St rung finanzielle Sch den ausl sen oder sogar Mensch und Umwelt gef hrden k nnen Aus diesen Gr nden ist das zuverl ssige Funktionieren von Computersystemen beson ders wichtig Bevor diese zum Einsatz kommen sollten sie auf korrekte Funktionsweise gepr ft werden Dies spart zum einen Kosten falls ein Ausfall w hrend des Betriebs auftreten sollte verhindert aber auch katastrophale Folgen einer Havarie z B Unfall eines Schnellzuges oder Atomkraftwerkes Das betrifft genauso die Software wie die Hardware des gesamten Systems Es wird also erst einmal gepr ft ob auf der Softwa reseite keine Fehler vorkommen d h ob die Programme korrekt funktionieren und die gew nschten Aufgaben erf llen dann werden die Funktionen der Software im Zusam menspiel mit der Hardware gepr ft Am Ende wird ein Integrationstest durchgef hrt wobei gepr ft wird ob die Software und Ziel Hardware zusammenspielen Wenn ja so hei t dies dass das Gesamt System korrekt zusammen funktioniert Andernfalls darf das System in seiner vorliegenden Form nicht zum Einsatz kommen Marcin
472. nsichtlich waren wurde aus zeitlichen Gr nden eine Einschr nkung auf das funktionierende System vor genommen NGSystem DE sysCheck int Abbildung 7 14 Detailansicht Klassendiagramm NGSystem 7 2 3 2 13 Zus tzliche Test Version Da kurz vor Projektende doch noch ein paar zus tzliche bisher aus Zeitgr nden nicht implementierte Funktionalit ten hinzugef gt wurden diese aber bei weitem nicht ausreichend getestet werden konnten existieren zwei Versionen des Konverters Die Test Version verf gt im Gegensatz zur stabilen Version ber eine eingeschr nkte Er kennung und Konvertierung von Slipswitches Die Einschr nkung hierbei ist allerdings dass diese Elemente in der CAD Zeichnung nicht gedreht werden sollten da sonst die Koordinaten der internen Einfachweichen nicht korrekt sind Hierzu war am Ende leider definitiv keine Zeit mehr brig Eine zweite Verbesserung gegen ber der stabilen Version sind Mehrfach Markierungen mehrere Markierungen in Folge Mit dieser Verbesserung k nnen nun auch Kurven modelliert werden Ansonsten sind beide Versionen in ihrer Funktionalit t identisch 7 2 3 3 TND CAD R ck Konverter Ein drittes urspr nglich geplantes Arbeitspaket des Netzgraphen war ein TND CAD R ck Konverter Dieser sollte aus der EBNF Beschreibung der TND wieder eine Visua lierung im CAD System herstellen Da sich aber mit der Zeit herausgestellt hat dass der Simulator ebenfalls eine Visualisierung des in der TND bes
473. nstigsten noch f r Fahrtbetrieb zugelassenen Umweltbedingungen aber bei voll funktionsf higer Bahn Gesteuert werden die Bahnen von einem menschlichen Fah rer Dieser reagiert auf den Schienenverkehr die Verkehrszeichen und auf die Signale Der Aufenthaltsort von Bahnen im Gleisnetz wird vom Steuersystem mittels der Senso renmeldungen erfasst Dar ber hinaus sind dem Steuersystem ggf angeforderte Routen der Bahn bekannt 2 3 2 5 Verkehrszeichen Verkehrszeichen sind ebenso wie Signale nahe der Strecke befindliche Anzeigen die An weisungen an den Fahrer darstellen Im Unterschied zum Signal sind ihre Anzeigen aber nicht ver nderbar sondern statisch Das Steuersystem kann ber Verkahrszeichen dem nach keinen Einfluss aus ben 2 3 3 Steuersystem Beim Steuersystem handelt es sich um einen Rechner auf dem die von uns entwickelte Steuersoftware l uft Dieses Programm nimmt Meldungen der Sensoren Weichen und Signale entgegen und entscheidet auf Basis dieser Meldungen und der Gleisnetzda ten welche Weichen und welche Signale wann wie zu schalten sind Das System soll sicherstellen dass e keine Kollisionen zwischen Bahnen auftreten e jede Bahn die von ihr gew nschte Route zeitnah befahren kann e keine Fahrten freigegeben werden die zur Besch digung von Bahntechnik f hren k nnen Zum Steuersystem z hlen weiterhin die Hardwarecontroller die den Weichen Signalen und Sensoren zugeh rig sind sowie menschliche Bediener
474. ntType String getElementAngle String getElementContactPoints String getInsertCoords String getElementNBSides String getBlockName String getSignalProperties String getInsertedInBlock String getInsertedBlocks String getInsertCount int 99 individuell im Quelltext anpassbar und sollte die eigentliche Funktion in keiner Weise beeintr chtigen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 100 TNDCreator TND_FILE_EXT final static String tnd BLOCKS final static String blocks tmp tng ENTITIES final static boolean entities tmp tng ERROR final static boolean true TNDtarget static File DXFsource static File overwrite static boolean false error static boolean false relError static boolean false w static BufferedWriter collector static NGDataCollector sigS static String sigL static String sigR static String sigLR static String sigSL static String sigSR static String sigSLR static String sensRR static String sensTG static String sensTD static String sensSG static String sensSD static String ptLR static String ptSL static String ptSR static String ptSR static String ptSLR static String sw static String marks static String cross static String sigMarkStr static String comment static String coords static String sigProp static String ptProp static String rel static String sigPos static Strin
475. nterschied lichen Sensoren erreichbar dann d rfen die Z hlerwerte dieser beiden Sensoren nicht beide gr er als 0 sein Damit eine Kreuzung von einem Sensor erreichbar ist sind h ufig bestimmte Weichenstellungen notwendig In dem Beispielgleisnetz ist die Kreuzung c2016 von Sensor g4125 erreichbar wenn die Weiche w1018 geradeaus gestellt ist und von Sensor g4129 wenn die Weiche w1022 nach links gestellt ist Demzufolge darf kein Zustand auftreten in dem die Z hler der Sensoren g4125 und g4129 beide gr er als 0 sind die Weiche w1018 geradeaus gestellt ist und die Weiche w1022 nach links gestellt ist Dies wird durch die Sicherheitsbedingung sr1_1 ausgedr ckt W re ein solcher Zustand erreichbar dann w re das System nicht sicher sri sri_1 amp sri_2 amp sr1i_3 sri_1 g4125 ctr gt O amp w1018 state STRAIGHT amp w1022 state LEFT amp g4129 ctr gt 0 sr1_2 g4125 ctr gt 0 amp w1018 state STRAIGHT amp w1020 state STRAIGHT amp g4127 ctr gt 0 sr1_3 g4129 ctr gt 0 amp w1022 state LEFT amp w1020 state STRAIGHT amp g4127 ctr gt 0 7 6 4 7 2 Zweite Sicherheitsbedingung Ist eine Weiche von zwei unterschiedli chen Sensoren erreichbar dann d rfen die Z hlerwerte dieser beiden Sensoren ebenfalls nicht beide gr er als 0 sein So ist in dem Beispielgleisnetz die Weiche w1019 von Sensor g4129 ereichbar wenn die Weiche w1022 nach links gestellt ist und von Sensor g4125
476. ntliche Steuerungssoftware besteht aus zwei grossen Bl cken die jeweils in ei genen Prozessen ablaufen Zum einen gibt es den Treiberblock der f r die Hardware steuerung zust ndig ist Zum anderen haben wir den Safety Controller der den Route Dispatcher die Route Controller und den Safety Monitor beinhaltet Die Anpassung der Steuerungssoftware an das konkrete Gleisnetz erfolgt durch Konfigu rationsdaten Diese Konfigurationsdaten beinhalten sowohl eine Beschreibung s mtlicher Hardwareelemente als auch alle notwendigen Informationen wie die vorhandenen Rou ten zu steuern sind Die Daten bez glich der Zuordnung von Hardware Elementen zu den Treibern werden in Headerdateien geschrieben die damit direkt beim Kompilieren des Treiberframeworks verarbeitet werden Der Rest wird jedoch vom TRACS Compiler siehe Abschnitt 7 4 in das spezifizier te Projektierungsdatenformat bersetzt und zur Laufzeit von der Steuerungssoftware geladen Die Projektierungsdatendatei wird dem Steuerinterpreter als Kommandozei lenparameter beim Start bergeben 7 5 2 1 1 Programmierstrategien Um gegen Programmfehler vorzusorgen soll folgendes nicht geschehen Es soll w hrend des Programmablaufs kein Speicher dynamisch alloziert werden sondern nur w hrend der Initialisierung Strings sollten m glichst nicht verwendet werden damit es keine Probleme mit zu langen Strings gibt Werden Arrays verwendet so sind die Grenzen zu berpr fen Schleifen for und wh
477. nur einen Teil der eigentlich zur Verf gung stehenden Funktionalit t nutzen und wo wir Bedingungen und Anforderungen an die Technik stellen Damit wird eine Basis geschaffen auf der die Entwicklung aller Systemkom ponenten aufgebaut wird und somit die Gefahr von Inkonsistenzen zwischen einzelnen Komponenten verringert Die hier vorliegenden Beschreibungen sind bindend f r alle im Projekt entwickelten Systemkomponenten 2 3 2 Gleisnetzelemente Gleisnetze bestehen f r unser System aus folgenden Elementen e Gleise Geraden Kurven Weichen Kreuzungen e Sensoren e Signale e Bahnen e Verkehrszeichen 2 3 2 1 Gleise Gleise werden von Bahnen befahren Ein komplettes Gleisnetz setzt sich dabei aus einer Vielzahl von Gleisst cken zusammen Diese Gleisst cke sind derart miteinander verbun den dass eine Bahn von einem Gleisst ck auf ein benachbartes Gleisst ck fahren kann Normalfall Gleisst cke k nnen aber auch besch digt sein was zum Entgleisen einer Bahn f hren kann Eine solche Besch digung muss nicht zwangsl ufig f r das Steuer system oder f r einen Betrachter sichtbar sein sondern kann unvorhergesehen auftreten KAPITEL 2 DIE DOMANE 19 und zum Entgleisen fiihren Ein Gleis ist passiv es kann vom Steuersystem kein direkter Einfluss auf das Gleis ausge bt werden Ein Gleisst ck hat eine L nge was im Zusam menspiel mit der L nge der darauf fahrenden Bahnen eine Maximalzahl von Bahnen ergibt di
478. nvironment M welche ANHANG F GLOSSAR 483 JF lex JFlex ist ein Tool f r Java welches aus einer Spezifikationsdatei einen Lexer generiert hnlich flex f r C Kernel Systemkern eines Betriebssystems Konflikt hart Ein harter Konflikt bezeichnet die Aufgabelung von zwei Routen an einer Weiche Konflikt weich Ein weicher Konflikt bezeichnet das Zusammentreffen von zwei Rou ten Zusammenf hrung an einer Weiche Konverter Ein Konverter ist ein Programm welches ein Datenformat in ein anderes umwandelt Lexer Ein Lexer auch Scanner genannt liest eine Datei Zeichen f r Zeichen ein und gibt die erkannten Token an einen Parser weiter Linux verbreitetes freies Unix hnliches Betriebssystem f r Personal Computer und Server Little Endian Ein Format f r die Byte Reihenfolge f r Integer Werte bei der das niederwertigste Byte an der niedrigsten Adresse gespeichert wird Mac OS ein Computer Betriebssystem Model Checker Die Aufgabe eines Model Checkers ist zu berpr fen ob gegebene Eigenschaften in einem gegebenen Zustands bergangssystem erf llt sind Netzgraph komplette Beschreibung eines Gleisnetzes egal ob physisch vorhanden oder imagin r enth lt Nachbarschaftsbeziehungen topologische Informationen Kann u a als CAD Zeichnung realisiert sein NuSMV NuSMV ist ein Tool zur Verifikation von Systemen mit Hilfe von Model Checking Techniken Dokumentation CCO F Padding Verl ngern von Daten
479. of Hardware drivers remove new Integer Hardware hw getSIid else if hw instanceof Route drivers remove new Integer Route hw getSIid else System out printin Unknown remove command protected void clearDrivers this drivers clear Mittels dieser Methoden greift der Simulator auf die Treiber HashMap zu um entweder neue Treiber einzutragen einzelne Treiberdaten zu l schen wenn der Treiber ein Exit Request gesendet hat oder alle Treiberdaten zu l schen wenn eine neue Simulation begonnen wird 7 8 5 6 Treiber Es wurden mehrere Treiber implementiert um den Simulator an den SI anbinden zu k nnen f r jede Hardwareklasse Sensor Signal Weiche Kreuzungsweiche einer Das Funktionsprinzip dieser Treiber ist quasi identisch weswegen hier stellvertretend auch f r die anderen Treiber der Weichentreiber gezeigt werden soll Die Treiber wurden in C implementiert Es m ssen fortlaufend zwei Schnittstellen beobachtet werden Zum einen ist das das Shared Memory zum anderen ein Socket Tritt eine nderung im SHM auf muss eine Textmeldung an den Simulator generiert und versendet werden die dann von der oben 7 8 5 4 auf Seite 393 beschriebenen Schnittstelle aufgenommen und im Simulator umgesetzt wird Umgekehrt kann eine Statusmeldung beim Treiber eingehen nach der er dann den Zustand des SHM ver ndern muss Zur Bedeutung der einzelnen SHM Belegungen und zu den vom Treiber bei Vorfi
480. of struct rc_data_t iteration number of routes for i 0 i lt pdata gt rd_data gt max_routes i read route ID if read_int file intbuf 0 printf R ID d n intbuf pdata gt rc_datalil route_id intbuf sidata gt rc_data i gt route_id intbuf else return 1 remember position count how many struct shm_value_t follow then jump back pos ftell file shm_count count_shm_val file fseek file pos SEEK_SET create structs according to number pdata gt rc_data i num_point shm_count pdata gt rc_data i point_pos struct test_shm_value_t KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 274 malloc shm_count sizeof struct test_shm_value_t sidata gt rc_datali gt point_pos struct shm_value_t malloc shm_count 1 sizeof struct shm_value_t first list are the point positions for j 0 j lt shm_count j if read_int file intbuf 0 fprintf Pt ID Ya n intbuf pdata gt rc_datalil point_pos j id intbuf sidata gt rc_data i gt point_pos j id intbuf else return 1 if read_uint16 file uint16buf 0 printf Pt Input d n uint16buf pdata gt rc_data i point_pos j input uint16buf sidata gt rc_data li gt point_pos j input uint16buf else return 1 if read_uint16 file uint16buf 0 printf Pt InputMask d n uint16buf pdata gt rc_data i p
481. oft Literaturverzeichnis AD94 ASU99 Aut03 Bre04 CCO Cho78 Cod Dec Fre04 HP02 ALUR RAJEEV und DaviD L DILL A Theory of Timed Automata In Theoretical Computer Science Volume 126 No 2 1994 AHO A V R SETHI und J D ULLMANN Compilerbau Teil 1 Olden bourg M nchen Zweite Auflage 1999 ISBN 3 486 25294 1 AUTODESK INC San Rafael Kalifornien USA DXF Reference 2004 2003 http adeskftp autodesk com prodsupp downloads dxf pdf Eine elektrisierende Ausstellung 2004 http www bsag de 6128 php Ab ruf am 07 05 2004 CAVADA R A CIMATTI E OLIVETTI G KEIGHREN M PISTORE und M ROVERI NuSMV 2 2 User Manual http nusmv irst itc it CHow TSUN S Testing Software Design Modeled by Finite State Machi nes In IEEE Transactions on Software Engineering SE 4 3 pp 178 186 Marz 1978 IO Warrior Universeller IO Controller am USB http www codemercs com IOWarriorD html Heruntergeladen am 7 Januar 2005 PCI 8255 8254 48 x I O Timer Karte http www decision computer de dio dio8255pci htm Heruntergeladen am 7 Januar 2005 Freunde der Bremer Stra enbahn e V 2004 http www fdbs net Abruf am 07 05 2004 HAXTHAUSEN A E und J PELESKA A domain specific language for rail way control systems In Proceedings of the Sixth Biennial World Conference on Integrated Design and Process Technology IDPT02 Pasadena Kalifor nien USA Juni 200
482. oint_pos j input_mask uint16buf sidata gt rc_data i gt point_pos j input_mask uint16buf else return 1 if read_uint16 file uint16buf 0 printf Pt Output d n uint16buf pdata gt rc_data i point_pos j output uint16buf sidata gt rc_data i gt point_pos j output uint16buf else return 1 if read_uint16 file uint16buf 0 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 275 printf Pt OutputMask d n uint16buf pdata gt rc_data i point_pos j output_mask xuint16buf sidata gt rc_data i gt point_pos j output_mask xuint16buf else return 1 terminate list in original structures sidata gt rc_data i gt point_pos shm_count id 1 jump back and count again make sure that we are at the end of the list fseek file pos SEEK_SET shm_count count_shm_val file remember position count how many struct shm_value_t follow then jump back pos ftell file shm_count count_shm_val file fseek file pos SEEK_SET create structs according to number pdata gt rc_data i num_free_sig shm_count pdata gt rc_datalil free_sig_pos struct test_shm_value_t malloc shm_count sizeof struct test_shm_value_t sidata gt rc_data i gt free_sig_pos struct shm_value_t malloc shm_count 1 sizeof struct shm_value_t next are the first signal values for j 0 j lt shm_count j
483. ole an den Simulator geschickt wurden sprich die Strings die sonst von den treibern kommen direkt eingeben oder man ein HW Element mit Treiber ansteuerte wozu man dann ein auf die Schnelle zusammengesetztes Kommandozeilen Tool zur nderung von SHM Werten einsetzte Erst mit Vorliegen eines lauff higen SI kurz vor dem Projekttag konnte der Simulator als Komplettsystem bzw das Zusammenspiel Simulator SI getestet werden Hier wurden vor allem Dauertests durchgef hrt d h das kombinierte System f r mehrere Stunden ohne menschlichen Eingriff betrieben KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 411 7 8 6 4 Beispieltest An dieser Stelle soll beispielhaft fiir andere ein Test aus der Reihe der Modultests de taillierter beschrieben werden Es handelt sich um einen Test zur Priifung des Beachtens von Signalen Es wurde folgende TND eingesetzt definitions rr sensors gl tg sensors g2 g3 s signals s1 routes ri coordinates g1 100 100 0 g2 20000 100 0 g3 50000 100 0 s1 20000 1000 0 signal properties sl rr straight switchtime 100 relations gi A entrance g1 B g2 A g2 B g3 A g3 B exit signal positions s1 g2 A routedefinitions rl g2 g3 request at gl conditions KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 412 clearances ri s1 straight hardwaremap Hier wird eine einfache in nur eine Richtung befahrbare Strecke ber drei Sensoren
484. oll Es er scheint ein Dialog in dem der Nutzer diese Zahl angeben kann Die Bahnen werden sich aus den in der TND definierten Routen zuf llig welche ausw hlen Die Weichen und Signale bleiben im undefined Zustand bis sie erstmalig einen Schaltbefehl erhalten Wenn eine Simulation mit dieser Option konfiguriert wurde bleibt sie auch w hrend der laufenden Simulation verf gbar so dass im Betrieb die Zahl der Bahnen ver ndert werden kann Falls die Zahl verringert wird wird allerdings keine Bahn unmittelbar aus dem Netz entfernt sondern man muss abwarten bis sie normal aus dem Netz gefahren ist Diese Option ist nur verf gbar wenn bereits ein Gleisnetz geladen wurde Die Tastenkombination f r diese Option ist Ctrl R 7 8 7 3 5 Options Configure Preset Simulation Dies ist ebenfalls eine M g lichkeit eine Simulation zu konfigurieren jedoch um einiges umfassender als die vorhe rige Option Nach der Auswahl der Bahnanzahl steht als n chstes die Festlegung von Einstellungen f r die Bahnen an diese sind e Route Die Route ist die Strecke die die Stra enbahn entlang fahren soll Es kann eine Route aus der Liste aller Routen ausgew hlt werden Nach Start der Simulation wird die Bahn an einer Einfahrt in das Gleisnetz eintreten die zu einem RR Sensor f hrt der die gew nschte Route anfordern kann Dazu ist es wichtig dass sich zwischen Einfahrt und RR Sensor keine Weiche befindet da sonst die Bahn nicht garantiert bis zum
485. ompiler 7 4 3 4 Syntaxbaum Im Folgenden werden die einzelnen Datenstrukturen beleuchtet aus denen sich der tram Syntaxbaum zusammensetzt 7 4 3 4 1 struct section_t Der Syntaxbaum des TRACS tram Compilers ist auf h chster Ebene aufgebaut als Struktur mit Verweisen auf Teilb ume die den einzelnen Bl cken der TRACS TND entsprechen Hiervon ausgenommen sind diejenigen Bl cke KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 144 die Hardwareeigenschaften einzelner Gleisnetzelemente beschreiben da diese Informa tionen innerhalb der entsprechenden Symboltabelleneintr ge gespeichert werden Abbil dung 7 31 zeigt das struct section_t also die Wurzel des tram Syntaxbaumes struct section_t definitions struct definitions_t relation struct relation_t routes struct route_t conditions struct condclearlist_t clearances struct condclearlist_t pointconflicts struct conflict_t conflicts struct conflict_t struct definitions_t hwmap struct hwmap_t l slipswitches struct slipswitch_t signalpositions struct sigpos_t 1 0 struct slipwswitch_t 2 struct condclearlist_t Abbildung 7 31 struct section_t 7 4 3 4 2 struct definitions_t Im Definitions Block der TRACS TND werden alle Gleisnetzelemente des zu steuernden Gleisnetzes definiert Zwar finden sich nach dem Parsieren einer eingegebenen TND auch alle Gleisnetzelemente in der tram Sym boltabelle allerdings i
486. on eines Route Controllers f r jede Route in konkrete Spezifikationen f r jeden zu benutzenden Route Controller des Safety Controllers umgesetzt werden Die Spezifikationen von Route Dispatcher und Safety Monitor des Steuerinterpreters k nnen auch als Spezifikationen derselben Komponenten innerhalb des Safety Control lers angesehen werden da sie immer nur einfach existieren und in beiden Spezifikationen direkt auf den Projektierungsdaten arbeiten Um gegen eine so entstandene Spezifikation eines Safety Controllers testen zu k nnen muss sie allerdings noch weiter transformiert werden Die entstandene Spezifikation ist ebenso wie die Spezifikation des TRACS Steuerinterpreters formal hierarchisch aufge baut Dies bereitet Probleme da die zu verwendende Testtheorie flache nicht hierar chische nicht parallele Statecharts ben tigt Es m ssen also alle Hierarchieebenen der Spezifikation auf eine einzelne Hierarchieebene reduziert werden Dies ist im Allgemeinen nicht trivial kann allerdings f r unsere Spezifikationen gut automatisiert werden Auf oberster Ebene eines Safety Controllers befinden sich Zust nde f r Route Dispat cher alle existierenden Route Controller und Safety Monitor Zwischen diesen Zust nden wird zyklisch gewechselt wobei dies von einer Zustandsvariable gesteuert wird die in nerhalb der einzelnen hierarchischen Zust nde der einzelnen Komponenten ver ndert wird Um diese Hierarchie aufzul sen werden jetzt alle Zust nd
487. ond amp r4_active_cond 1 r5_inactive_cond amp r5_active_cond 1 1 0 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 223 esac g4128_cond_2 case rO_inactive_cond amp rO_active_cond 1 r5_inactive_cond amp r5_active_cond 1 1 0 esac g4129_cond_2 case r2_inactive_cond amp r2_active_cond 1 r3_inactive_cond amp r3_active_cond 1 1 0 esac g4130_cond_2 case r2_inactive_cond amp r2_active_cond 1 r4_inactive_cond amp r4_active_cond 1 1 0 esac 7 6 4 5 Routenverhalten Jetzt wird beschrieben wann eine Route welchen Zustand annehmen soll 7 6 4 5 1 Allgemeines Routenverhalten Der Zustand einer Route wird durch die Variable state dargestellt die die Werte ACTIVE LOCKED und INACTIVE annehmen kann Der Initialzustand jeder Route ist INACTIVE Es werden drei Bedingungen als Parameter tibergeben Die Bedingung active_cond gibt an wann die Route den Zustand ACTIVE annehmen soll die Bedingung lock_cond wann die Route den Zustand LOCKED annehmen soll und die Bedingung inactive_cond wann die Route den Zustand INACTIVE annehmen soll Dabei ist wichtig dass die Anforderung in den Zustand ACTIVE zu wechseln eine h here Priorit t hat als die Anforderung in den Zustand INACTIVE zu wechseln Wenn also eine weitere Bahn die betreffende Route befahren m chte wird ihr dies gestattet und die Route nimmt wieder den Zustand ACTIVE an MODULE route active_cond lock_cond inactive_cond
488. ooh Ba ch ra A deat A dee 258 TTA Testyvor perenne ieoa diota whe Phe de 262 7 7 5 Test Implementierung as ee eh ete ei ec es 267 7 7 6 Testausfiihrung und auswertung 0 298 7 7 7 Vorschl ge zu Software Hardware Software und System Inte erationstest s Alo cast Ble a a a DE ra A 303 Mr Reflexion 20 5 4 ioe Bale A eed A ed 309 DIE ALOR ea er ate ee aed Nk Hee a ela hd ca Pe nell es 313 INHALTSVERZEICHNIS 1 8 ODore 26 4 ae 0000 04 5 des Aa Mt ect eee eh theta te tah A 7 8 2 Anforderungen an den Simulator 7 8 3 Weltmodell und Abstraktionen 040 7 8 4 Konzept des Simulators Eee 7 8 5 Implementierung des Simulators 2 2 2 22 a a a ROO LESTE el ane Ye lt a N ether amp at Werte es en Gules A aene Gt Ae ats TET Anet rap Gee BY Hwee ce eet ee ae ee we SS FO Reflexion a 2 Sw ake Be BRR A ee Se Wore 8 Sicherheitsnachweis 8 1 8 2 8 3 DerDlicher send g deh eS aie m ae 62 a ne A Fehlerbaumanalyse fais ele fad Be ee ee ANSWERLUNEN os ck hres Ba aR eo ee eck MS GR ae Be ed 9 Bewertung 9 1 9 2 Wissenschaftliche Leistung 2 2 aa a 9 1 1 Dom nenspezifische Beschreibungssprache 9 1 2 Wiederverwendbare Architektur des Steuerungssystems 9 1 3 Verifikation eines Steuerungssystems 0 9 1 4 Automatisierter Test von Steuerungssystemen 9 1 5 Eigene Prweiterungen 2 2 aa he ala a a a ee a Projektarbeit un
489. oords 0 tailCoords 1 TRAM_WIDTH KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 393 bis man dann tats chlich das TE erreicht auf dem der Kopf ist Nun muss noch der vordere Abschnitt der Bahn gezeichnet werden und die Bahn ist komplett dargestellt 7 8 5 4 Schnittstelle zu den Treibern Wie bereits im Konzept erw hnt wird die Kommunikation zu den Hardware Treibern und damit indirekt zum Steuerinterpreter via Netzwerk im speziellen die Internet Protokollfamilie realisiert F r jede der Kommunikationsrichtungen existiert ein eigenes Subsystem das als eigener Thread l uft Damit wird sichergestellt dass die Kommuni kation zu jeder Zeit m glich ist und nicht beispielsweise durch einen l ngeren Rechen vorgang des Simulators blockiert wird 7 8 5 4 1 Richtung Treiber Simulator Es folgt nun ein Auszug aus dem Code f r die o a Kommunikationsrichtung dabei werden die in der eigentlichen Datei vor handenen Kommentare ausgelassen auch ist der Code nicht komplett aufgef hrt Die Betrachtung beschr nkt sich auf das f r den Betrieb Wesentliche public class DriverRequestServer extends Thread private LinkedList requestlist private LinkedList driverlist private final int PORT 12345 Der Server der die Anfragen der Treiber annehmen soll verf gt ber zwei Variablen einerseits eine Liste in der die eingegangenen Anfragen zwischengespeichert werden bis der Simulator sie abruft andererseits eine ganz hnluch funktion
490. or static boolean false list static boolean false listonly static boolean false convert static boolean false w static BufferedWriter collector static NGDataCollector separator src File static boolean dataCollector blk String ent String static boolea writer tgt File static boolean elementList static boolean checkDXFExt ext String static boolean checkTNDExt ext String static boolean main args String static void Abbildung 7 13 Detailansicht Klassendiagramm TracsDXF2TND Es werden unter anderem f r die Instanziierung der einzelnen Komponenten entspre chende Methoden zur Verf gung gestellt All diese Methoden sind nicht ffentlich da sie nur innerhalb dieses Programms bzw dieser Klasse Verwendung finden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 103 7 2 3 2 12 NGSystem java Um sicherzustellen dass der Konverter nur in einer Software Umgebung l uft die der getesteten hnelt wurde eine weitere Hilfsklasse NG Systems java erstellt Diese Klasse enth lt eine Pr fmethode welche sowohl verwendetes Betriebssystem als auch die JavaTM Umgebung berpr ft und bei einer nicht getesteten Version das Pro gramm mit einer entsprechenden Fehlermeldung abbricht Der Grund f r die Einf hrung dieser Klasse waren Unterschiede oder besser gesagt Feh ler auf einer Plattform w hrend auf einem anderem System und ansonsten gleichen Daten und Klassen keine Fehler auftraten Da diese Fehler nicht offe
491. orgenommen kann danach keine Konfigurati ons nderung mehr erfolgen Erst nach Bet tigen von New Simulation oder Load TND ist dies wieder m glich Diese Option ist nur verf gbar wenn bereits ein Gleisnetz geladen wurde Die Tastenkombination f r diese Option ist Ctrl P 7 8 7 3 6 Options Start Simulation Startet die Simulation bzw setzt sie nach einer Pause fort Diese Option ist nur verf gbar wenn bereits ein Gleisnetz geladen und die Simulation konfiguriert wurde Die Tastenkombination f r diese Option ist Ctrl E 7 8 7 3 7 Options Stop Simulation Unterbricht die Simulation Die Tastenkombination f r diese Option ist Ctrl D 7 8 7 3 8 Options Create Logfile Das Aktivieren dieser Option bewirkt dass ein Logfile gef hrt wird in dem Daten zur laufenden Simulation abgelegt werden Das Logfile wird in der Datei sim log abgelegt Diese kann maximal 10 000 000 Bytes gr werden Soll dieser Wert oder der Dateiname ver ndert werden so sind die Werte f r logsize bzw logname in src sim Simulator java zu ver ndern KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 422 7 8 7 3 9 Options Random Defects Ist diese Option aktiviert k nnen Hard ware Elemente oder Bahnen spontan in Defekt Zust nde bergehen Das gilt auch f r solche die in einer etwaigen Detail Konfiguration nicht als verwundbar markiert wur den sind Zu beachten ist dass die Defekterzeugung mit drei Ebenen arbeitet Die erste ist nicht
492. ort request at und eine weitere Liste von Sen soren Jede Beschreibung einer einzelnen Route endet mit einem Semikolon Bedeutung Der RouteBlock enth lt die Informationen ber die zu den einzelnen Routen geh renden Sequenzen von Sensoren wie sie auch in einer Route Definition Table vorhanden sind Zu jeder Route wird hier die Reihenfolge der Sensoren angegeben in der die Sensoren bei der Befahrung der Route berfahren werden Au erdem werden die RR Sensoren genannt an denen die Route angefordert werden kann die zweite Sensorenliste Beispiel routes routel g101 g102 g103 gl04 request at g100 route2 g201 g202 g203 request at g200 route3 g301 g302 g303 g304 request at g300 route4 g401 g402 g403 g404 g405 request at g400 routed gi01 g105 g405 request at g100 route6 g401 g406 g304 request at g400 Dieses sind die Routenbeschreibungen des oben genannten Beispieles in Abbildung 7 1 auf Seite 63 Man kann u a erkennen dass route1 und route5 am gleichen Sensor beginnen und sich dann nach dem Sensor g101 trennen Folglich muss eine Weiche zwischen g101 und den Sensoren g102 bzw g105 sein wie auch in der Abbildung zu sehen ist 7 1 3 2 10 CondBlock lt condblock gt lt CONDITIONS gt lt conddef gt lt conddef gt lt ROUTEID gt lt condition gt lt condition gt lt condition gt lt POINTID gt lt direction gt Vor dem CondBlock
493. p NGElement aus um mit deren Daten die einzelnen Bl cke der zu erzeugenden TND Datei zusammenzusetzen Die Daten der in den Objekten ge speicherten Elemente m ssen dabei noch etwas aufbereitet werden damit sie dem in der TND geforderten Format entsprechen Da in der TND Datei die Koordinaten als Zentimeter Angabe definiert sind in der DXF Datei aber ein anderes Ma verwendet wird muss die Angabe aller Koordinaten entsprechend umgerechnet werden Als Faktor wurde hier der Wert 100 gew hlt da so die Aufl sung innerhalb der DXF Datei in einem sinnvollen Ma stab gehalten wird und die Werte nicht gro artig ver ndert werden m ssen Ein Weichenelement welches von der Einfahrtsseite zur gegen berliegenden Ausfahrtsseite somit in der DXF Datei eine relative L nge von 10 aufweist w rde somit in der Realit t eine L nge von 10 Metern also 1000 Zentimetern haben Dies erscheint als realistischer Wert Letzlich ist dies aber KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN Abbildung 7 11 Detailansicht Klassendiagramm NGElement UNSET final static int 0 LEFT final static int 1 STRAIGHT final static int 2 RIGHT final static int 3 ACTIVE_FALLBACK final static int 3 PASSIVE FALLBACK final static int 2 BREAKABLE final static int 4 PASSIVE final static int 1 ACTIVE final static int 0 UNDEF final static int final static char final static char _C final static char _D final static char _S final stati
494. pe von Funktionen die vom Steuerinterpreter f r bestimmte Hardwareelemente bei bestimmten Ereignissen aufgerufen wird Als Minimum gibt es je eine Treiberklasse f r Sensoren Signale und Weichen in der Realit t d rften es jedoch deutlich mehr sein Das Format f r die als Treiberinfo Datei bezeichnete Datei ist wie folgt lt DRV_INFO gt lt DRV_MAP gt lt DRV_CLASS gt lt DESCRIPTION gt n lt DRV_MAP gt lt DRV_CLASS gt lt HWCLASS gt lt HWCLASS gt n lt LETTER gt lt LETTER OR DIGIT gt 7 5 4 7 2 Nur Simulator Treiber verwenden Dies ist auch die Methode wie sie f r die Projekttag verwendet wurde Dazu gibt es im Compiler Verzeichnis ein Skript namens tram hw sh welches die zum Compilieren des Treiberframeworks ben tigten Header Dateien aufruft Dadurch werden den Elementen die entsprechenden Simulator Treiber zugeordnet Dem Skript wird der Name der TND Datei bergeben Marius Mauch Andreas Kemnade 7 5 5 Resumee der Zeit Anforderungen Um eine systematische Bewertung der Zeitanforderungen zu erhalten fassen wir an dieser Stelle die an anderen Stellen im Bericht aufgetretenen Echtzeitanforderungen zusammen und geben dazu eine Bewertung ab KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 201 e Zeit fiir das Durchschalten Freigeben von Routen durch den Route Controller Route Dispatcher nicht sicherheitskritisch sondern Komfortanforderung weil es kein Sicherheitsproblem darstellt wenn die Bah
495. piler Abbildung 4 2 Neuer Ansatz des Projektes Das integrierte Hardware Software System wird mittels einer automatisierten Test Suite in Bezug auf sein korrektes Verhalten gepr ft e Simulation Durch einen Simulator kann die Steuerung des jeweiligen Gleisnetzes am Computer simuliert werden Taffou Happi 4 2 Automatische Generierung Eines der Hauptziele des Projekts TRACS ist die Minimierung des Aufwandes um ein Steuerungssytem f r ein neues Gleisnetz zu erstellen Aus diesem Grund ist das von uns entwickelte System prim r auf Wiederverwendbarkeit ausgelegt so dass es f r KAPITEL 4 DER LOSUNGSANSATZ 41 m glichst viele Gleisnetze verwendet werden kann Dazu wird f r jedes Gleisnetz in mehreren Schritten aus einer graphischen Beschreibung ein fertiges Steuerungssystem generiert 4 2 1 Wiederverwendbare Komponenten Ein Grossteil der Automatisierung wird dadurch erreicht dass die meisten in TRACS verwendeten Komponenten wiederverwendbar sind also eine generische L sung f r die jeweilige Aufgabe darstellen die erst sp ter mit gleisnetzspezifischen Daten erg nzt werden 4 2 1 1 Netzgraph Konvertierungstools Der erste Schritt besteht in einer Auswertung der graphischen Beschreibung durch die von uns Netzgraph genannte Softwarekomponente welche die vom Anwender erstellte DXF Datei einliest analysiert und schliesslich eine f r unseren Compiler verst ndliche TND Beschreibung bersetzt Diese bersetzung umfa
496. plette Block nach Konflikten durchsucht werden so ist es nur eine Zeile Dies f hrt zu erh hter Fehleranf lligkeit bei der Eingabe eine Fehlerer kennung m sste allerdings durch den Compiler m glich sein KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 76 Beispiel point conflicts routei routed route4 route6 route5 routel route6 route4 Dieses sind die harten Konflikte der einzelnen Routen des oben genannten Beispieles in Abbildung 7 1 auf Seite 63 Da die Route route1 und die Route route2 sich an der Weiche w102 trennen gibt es einen harten Konflikt zwischen diesen beiden Routen 7 1 3 2 13 ConfBlock lt confblock gt lt CONFLICTS gt lt confdef gt Vor dem ConfBlock steht das Wort conflicts welches den Block identifiziert Der ge samte Block von beliebig vielen Konfliktdefinitionen wird mit geschweiften Klammern umrahmt Der ConfBlock enthalt die restlichen Informationen der Route Conflict Table die nicht im PtConfBlock beschrieben werden n mlich die weichen Konflikte Treffen mindes tens zwei aus verschiedenen Richtungen kommende Routen an einer Weiche aufeinander oder kreuzen sich zwei Routen dann tritt ein sogenannter soft conflict an der Weiche bzw Kreuzung auf Analog zum PtConfBlock werden hier die in Konflikt stehenden Routen aufgeschrieben Die Angabe der Konflikte erfolgt wiederum doppelt Erkl rung dazu findet sich beim vorhergehenden Block Beispiel conflicts rout
497. pliziert da es im Wesentlichen um Zeichnen von Kreisen und Linien an bestimmten Koordinaten geht wobei diese Elemente grafisch relativ simpel gehalten sind Am interessantesten erscheint das Zeichnen der Tram da es hier mit dem Fahren ber Hardware Elemente so dass sich die Bahn also ber mehrere TrackEle mente erstreckt eine gewisse Besonderheit gibt Grunds tzlich existieren zwei M glichkeiten Die Tram f hrt vollst ndig auf einem Gleis st ck oder Kopf und Ende befinden sich auf zwei unterschiedlichen TrackElementen 7 8 5 3 1 Zeichnen eines Bahn Abschnittes Als Bahn Abschnitt wird in diesem Zusammenhang derjenige Teil einer Bahn verstanden der sich auf einem TrackElement befindet Das kann also von einem sehr kurzen Abschnitt bis hin zur vollst ndigen Bahn alles sein Es wurde eine ganz spezielle Implementierung gew hlt um aufwendige Rechnungen beim Zeichnen zu ersparen Der Zeichenmethode werden die Koordinaten des Kopfes und des Endes eines Stra enbahnabschnittes gegeben In Abbildung 7 82 auf Seite 390 sind diese beiden Stellen durch ein x gekennzeichnet Statt auf dieser Grundlage umst ndlich die vier Ecken des roten Rechtecks zu berechnen und den Mittelpunkt des Kreises zu KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 388 berechnen wird nur der Punkt auf der Geraden zwischen Kopf und Ende berechnet bis zu dem das dunkle Rechteck der K rper der Tram reicht und der den Mittelpunkt des Kreises Kopfes bildet Stelle 2 in
498. programmiert und soll die erwarteten Ausgaben produzieren Im Checker letztlich werden nur noch Orakel Output und SUT Output verglichen Aufgrund dieses Vergleiches kann die Beurteilung des Tests erfolgen F r den Fall dass Orakel Output und SUT Output inhaltlich gleich sind gilt ein Test als bestanden andernfalls als nicht bestanden Die genaue Beschreibung der einzelnen Testprozeduren erfolgt in den folgenden Kapiteln Marcin Dysarz Arne Stahlbock 7 7 5 1 Einlesen der Projektierungsdaten Zielsetzung dieses Arbeitspaketes war es eine Repr sentation der als Bin rdatei vor liegenden Projektierungsdaten im Speicher zu erhalten Durch die SI Gruppe war das Format dieser Datei vorgegeben siehe 7 5 4 6 auf Seite 193 die hierbei verwendeten Datenstrukturen waren jedoch an einigen Stellen aus Testperspektive nicht immer g ns tig gew hlt Als Beispiel daf r lassen sich die Inline Arrays anf hren deren Verwendung zur Folge hat dass man wenn man sich am Beginn eines solchen Arrays befindet noch nicht wei wie lang dieser berhaupt ist Ben tigt man die L nge was der SI m gli cherweise nicht tut h tte man die Elementanzahl durchz hlen und dann wieder an den Anfang zur ckspringen m ssen Um dies nicht immer wieder tun zu m ssen wur de beschlossen f r die Testumgebung eigene vor allem um L ngenangaben erweiterte Datenstrukturen einzusetzen in denen dann die Projektierungsdaten abgelegt werden sollen Da allerdings au
499. pw darf ein sl signal keine wait right Anzeige haben e Im PointPropBlock muss jede PointID die im DefBlock definiert worden ist genau einmal vorkommen Der PointPropBlock darf also nur entfallen wenn im DefBlock keine PointID vorkommt e Im PointPropBlock darf einer PointID nur eine Fallback Richtung zugeordnet werden mittels Vorkommen des entsprechenden Tokens deren Richtung die zu geh rige Weiche auch hat e Im PointPropBlock d rfen einer PointID nicht gleichzeitig die Eigenschaften brea kable und passive zugeordnet werden Die so beschaffene Weiche w rde keinen Sinn machen nicht stellbar aber auch nicht von der stumpfen Seite her befahr bar e Im SlipSwitchBlock darf keine CrossID oder PointID mehrfach vorkommen e Im RelBlock darf jedes Paar lt elementid side gt nur einmal vorkommen e Im RelBlock darf jede MarkID nur einmal vorkommen e Im RelBlock darf innerhalb einer Relation nicht eine SensID mehrfach vorkommen e Im SigPosBlock muss jede SigID die im DefBlock definiert worden ist genau einmal vorkommen e Im RouteBlock muss jede RoutelD die im DefBlock definiert worden ist genau einmal vorkommen e Im ClearBlock muss jede RoutelD die im DefBlock definiert worden ist genau einmal vorkommen e Im HWBlock muss jede PointID SigID oder SensID die im DefBlock definiert worden ist genau einmal vorkommen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 79 e Im HWBlock darf jede CrossID die im
500. r proc getErrorStream InputStreamReader isr new InputStreamReader stderr BufferedReader br new BufferedReader isr String line null while line br readLine null KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 115 System out println line int exitVal proc waitFor System out println ExitCode exitVal catch Throwable t t printStackTrace Dieser Code kann an beliebiger Stelle eingebaut werden und ruft dann den Konver tiervorgang auf In der Variablen exitVal befindet sich der Exit Code des Konverters anhand dessen dann ber die weitere Ausf hrung der Software entschieden werden kann 7 2 4 5 Einschr nkungen Besonderheiten bei der TND Erzeugung Im Folgenden werden einige Einschr nkungen und Besonderheiten dieser Version des DXF CAD nach TND Konverters beschrieben 7 2 4 5 1 Slipswitches Diese Version des Konverters unterst tzt keine Slipswitches Bei der Fertigstellung dieser Version wurde aus Zeitgr nden auf eine Implementierung dieser doch etwas komplexeren Gleisnetzelemente verzichtet Dies wird aber nicht als allzu gravierend angesehen zumal sie in Stra enbahnnetzen doch auch recht selten vor kommen und somit kaum Einschr nkungen in der Nutzbarkeit diesbez glich vorhanden sein sollten Es besteht immer noch die M glichkeit diese Unterst tzung in einer Folgeversion ein zubauen zumal die CAD Elemente f r Slipswitches bereits existieren F r TRACS wird d
501. r Funktion int getSensorList struct idlist_t senslist wird ein Feld von Integern erstellt welches die SHM IDs der entsprechenden Sensoren enthalt Jetzt wird der letzte Sensor der Route ermittelt und in das Struct eingetragen ebenso wie der erste Sensor Dann mu noch der Wert f r die regsigpos ermittelt und eingetragen werden Dies wird ber folgende Hilfsfunktion erreicht struct shm_value_t setRRSignal struct condclear_t clear Damit w ren dann die Projektierungsdaten f r einen Route Controller generiert 7 4 4 3 3 Safety Monitor In diesem Abschnitt soll erl utert werden wie die Pro jektierungsdaten f r den Safety Monitor generiert werden Der Steurinterpreter ben tigt diese Daten um zu jeden Zeitpunkt der Ausf hrung zu pr fen ob sich das gesteuerte Gleisnetz in einem sicheren Zustand befindet Dazu werden Sensorrelationen Weichen und Signalstellungen und Fehlermeldungen der Hardwareelemente ausgewertet Die Pro jektierungsdaten sollen folgenderma en aussehen struct sm_data_t struct sm_condition_t sm_conditions struct hw_timeout_t hw_timeouts Hier ist smconditions ein zweidimensionales Feld f r die Sicherheitsbedingungen und hwtimeouts ein Feld f r die Timerbedingungen Damit diese Daten generiert werden gibt es folgende Funktion struct sm_data_t getSMData struct section_t syntree struct rc_data_t rcdata struct rd_data_t rddata Sie erh lt als Eingaben den Syntaxbaum die bereits
502. r Rest ist zu vernachl ssigen Dies stellte sich leider erst so sp t heraus da die urspr nglichen berlegungen noch ein anderes Arbeitspaket den TND DXF R ck Konverter Abschnitt 7 2 3 3 auf Seite 103 welches in der Zwischenzeit entfallen ist mit einbezogen Bei diesem Paket wo es um die Erstellung einer DXF Datei gegangen w re w ren andere Informationen von Bedeutung KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 91 gewesen um die Korrektheit einer DXF Datei zu gew hrleisten Die aus den DXF Daten zu gewinnenden Informationen stellen also nur als einen Bruch teil des Datenumfangs dar welche eine DXF Datei eigentlich zu bieten hat Der Aufwand zum Gewinnen der detaillierten Informationen erscheint daher mit der gew hlten Me thode auch mit geringerem Aufwand machbar Der Einsatz von Tools wie CUP Parser Generator for Java ist f r wirklich gro e Projekte sicher sehr sinnvoll Ob der Einsatz f r diese Aufgabe sinnvoll gewesen w re ist eine Frage ber welche man sicher streiten kann Nach Betrachtung der oben be schrieben Eigenschaften erschien uns dies hier nicht unbedingt sinnvoll zu sein da der Zeitaufwand enorm gewesen w re Es macht also letztlich wenig Sinn sich mit der Einarbeitung in derartige Werkzeuge zu besch ftigen wenn diese einen gr eren Zeitaufwand erfordert als der aus einer eventu ellen Anwendung des Werkzeugs resultierender Zeitgewinn ist zumal es gar nicht sicher ist dass sich in diesem Falle wirkl
503. r Stelle neue Bahnen einge setzt Bei Bahnen mit vorbestimmten Routen wird eine von diesen gestartet im anderen Fall wird eine Route zuf llig gew hlt 8 Zeitstempel holen und warten Von der Systemuhr wird die aktuelle Zeit geholt und auf das Ende des Simula torschritts gewartet Das Warten kann unterschiedlich lange ausfallen je nachdem wieviel Zeit die Berechnungen dieser Runde gekostet haben Da im Endeffekt aber KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 343 jede Runde gleich lange dauern soll wird das mit einem variablen Warteanteil ausgeglichen Die Rundenzeit ist so gew hlt dass gen gend Luft besteht 7 8 4 4 2 Bewegungsalgorithmus Zwei wichtige Voraussetzungen zur Simulation von Stra en Bahnen sind dass man bestimmen kann an welchem Ort sie sich gerade befinden und dass man die Bewegung simulieren kann Da wir uns f r eine rundenba sierte Programmablaufstruktur entschieden haben s S 368 m ssen wir die Bahnen in konstanten Schritten bewegen Nun folgen Beschreibungen ber e die Programmstruktur e und den Algorithmus die wir f r die L sung der Simulationsanforderungen verwenden Bei der Entwicklung dieses Konzeptes legen wir eine hohe Priorit t auf die zeitliche Optimierung der Be rechnungsschritte die w hrend der Simulation stattfinden bewusst vernachl ssigen wir dabei die Zeit f r die Berechnungen die vor Beginn der Simulation durchgef hrt werden m ssen und den allgemeinen Speicherverbrauch e
504. r Thread als Server vorgesehen Dieser Server schreibt die eingegangenen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 364 Nachrichten in eine Liste aus der der Simulator sie dann entnehmen und bearbei ten kann Um die ggf beim Zugriff auf die Liste auftretenden Nebenl ufigkeits probleme zu beheben darf der Zugriff jeweils nur einem Thread Simulator oder Server zum gleichen Zeitpunkt m glich sein Vor dem Ablegen einer Nachricht in der Liste wird seitens des Servers bereits ein Korrektheitscheck vorgenommen der Nachrichten die nicht dem Vorgabeformat entsprechen ohne R ckmeldung an den Steuerinterpreter verwirft Aus Gr nden der Einfachheit soll der Server jeweils nur eine Verbindung zur selben Zeit bearbeiten k nnen es werden also keine wei teren Threads erzeugt die ggf parallel Verbindungen annehmen Der Server kann allerdings mehrere Verbindungen gleichzeitig offen halten die dann eine nach der anderen abgefragt werden Da die Nachrichten jeweils nur sehr kurz sind erscheint uns dies als hinreichend e Simulator Treiber S mtliche Hardware Elemente melden ihren Status an den Steuerinterpreter wenn eine Status nderung eingetreten ist Eine Nachricht enth lt eine Kennzeichnung dass es sich um eine Statusmeldung handelt eine eindeutige Identifikation des betreffenden Hardware Elements die Angabe der Stellung die eingenommen wurde bei Weichen Signalen oder die Information ber das Ausl sen bei Sensoren
505. r Wei che entfernt sein dass eine ihn ausl sende Bahn zum Ausl sezeitpunkt garantiert diese Kreuzung oder Weiche verlassen hat Distanz Kreuzung Weiche gt Sensor ist gr er als gr te L nge der eingesetzten Bahnen Die Abfolge von Elementen am Beginn einer Route muss wie folgt sein RR Sensor oder RR Sensorengruppe Finfahrtssignal Einfahrtssensor Diese Ele mente m ssen so nah zusammenliegen dass von dem RR Sensors der RR Sensorengruppe bis zum Einfahrtssensor maximal drei Bahnen Platz haben so dass eine nachfolgende vierte Bahn erst einen RR Sensor ausl sen kann wenn die erste Bahn den Einfahrtssensor ber hrt hat und somit in das Gleisnetz einge treten ist Es k nnen also niemals mehr als drei Requests an einer RR Gruppe gleichzeitig anliegen An das Verhalten eines Bahnfahrers werden folgende Forderungen gestellt F hrt er hinter einer anderen Bahn her darf er nicht auffahren Signale sind zu beachten sofern dies noch m glich ist wird ein Signal also auf Stop gesetzt w hrend die Bahn dem Signal schon n her ist als der o a maximale Bremsweg darf nicht zwangsl ufig erwartet werden dass die Bahn noch vor dem Signal halten kann Verkehrszeichen sind zu beachten Erkennt er einen Defekt eines Gleiselementes so darf er dieses nicht befahren Erkennt er einen Defekt eines Signals so darf er daran nicht vorbeifahren ohne dass ihm dies von anderer Stelle bspw Betriebszentrale genehmigt wird An H
506. r eine Route route Rset in die angegebene Richtung direction gestellt werden soll KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 239 e Die Funktion signal_free signal_free s Sse X route Reet X direction Bool mit direction L R S gibt an ob ein Signal s S f r eine Route route Rset in die angegebene Richtung direction gestellt werden soll e Die Funktion signal_lock signallock s Sset x route Rse Bool gibt an ob ein Signal s Set auf STOP gesetzt werden soll wenn eine Route route Reet wieder gesperrt wird e Die Funktionen entrance_sensor und exit_sensor entrance_sensor route Rset g Gset exit_sensor route Rse g Gset liefern den Eingangs bzw den Ausgangssensor einer Route route R Alle oben beschriebenen Funktionen wurden in c umgesetzt Abh ngig davon welche Informationen diese Funktionen liefern wird die Model Checker Eingabedatei f r das betreffende Gleisnetz generiert Ruben Rothaupt Taffou Happi 7 6 6 berpr fung der Verschlusstabellen In diesem Abschnitt soll beschrieben werden wie die in den Verschlusstabellen gemach ten Angaben berpr ft werden k nnen Die Verschlusstabellen bestehen aus Route De finition Table Point Position Table Signal Setting Table und Route Conflict Table Die dort enthaltenen Informationen sind in der TND in folgenden Bl cken umgesetzt e Route Definition Table ro
507. r nur eines der beiden union Bestandteile vorliegen w rde auf eine Instanz eben dieses Bestandteils zeigen sollte Es wurden dann Funktionen geschrieben die das Einlesen durchf hren Auf den Ein satz von Parsergeneratoren wurde an dieser Stelle von vorn herein verzichtet da man insbesondere beim Erstellen einer Grammatik gewisse Probleme bef rchtete In einer Bin rdatei sind letztlich ausschlie lich einzelne Bytes nacheinander einzulesen niemals Zeichenketten o dabei haben allerdings die Bytes je nach ihrer Position und den Werten der vor ihnen stehenden Bytes andere Bedeutungen Da letztlich die Implemen tierung ohne Parsergeneratoren auch nicht berm ig lange gedauert hat f hlen wir uns in dieser Wahl auch best tigt Wir erkl ren nun einige nicht alle der zum Einlesen benutzten Funktionen int read_data const char filename struct test_projdata pdata config _data_t sidata int retval 0 FILE file file fopen filename r if file NULL retval 1 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 272 if read_offsets file pdata sidata 1 retval 1 if read_version file pdata sidata 1 retval 1 if read_rd_data file pdata sidata 1 retval 1 if read_rc_data file pdata sidata 1 retval 1 if read_sm_data file pdata sidata 1 retval 1 return retval Hier handelt es sich um die Hauptfunktion die dann
508. ra Benbahnen werden ggf besch digt und bleiben dann entweder stehen oder be achten Signale nicht mehr Der Bewegungsalgorithmus wird in der Folge genauer beschrieben 5 Ver nderungen der Hardware Elemente senden Wenn sich etwas im Gleisnetz ver ndert hat so sendet der Simulator nun die Ver nderungen an die Hardware Treiber Die Zustands nderungen werden zur ck gemeldet indem der Simulator von allen geschalteten ausgel sten Hardware Elementen die er sich ja beim Umschalten gemerkt hat den neuen Zustand auf nimmt und jeweils einen String gem dem daf r definierten Format zusammen setzt Diese Strings werden in eine Sendewarteliste eingetragen Ein eigenst ndiger Thread der StatusSender pr ft st ndig den Inhalt dieser Liste findet er etwas vor wird dieser String an den Treiber geschickt der seinerseits den Inhalt des Shared Memory entsprechend ab ndert so dass der Steuerinterpre ter die Schaltung erkennen kann Ein eigener Thread wurde deshalb gew hlt um im Fall von St rungen beim Senden den Simulator dennoch weiter laufen lassen zu k nnen 6 Output besch digter Sensoren generieren Da Sensoren nicht zu den stellbaren Elementen z hlen werden sie im obigen Schritt nicht aktualisiert Nichtsdestotrotz k nnen auch sie besch digt sein und Mel dungen abgeben wenn eigentlich keine erfolgen sollten Das geschieht in diesem Schritt 7 Neue Bahnen starten Falls zu wenig Bahnen im Netz sind werden an diese
509. rab lt Sicherheit Tracs PC Hardware Prozessor O Karte Abbildung 5 1 Umfang des von con TRACS gelieferten Systems Taffou Happi Deng Zhou Ruben Rothaupt berarbeitet von Andreas Kemnade 5 3 Entwicklungsschritte Anhand der Abbildung 5 2 auf der n chsten Seite wird der Ansatz zur Entwicklung der wiederverwendbaren TRACS Komponenten aufgezeigt Die folgenden Komponenten wurden im Rahmen des Entwicklungsprozesses entwickelt e CAD TND Konverter e Komponente zur Transformation der Verschlusstabellen in die TND e Komponente zur Transformation der Hardwarebeschreibung in die TND e TND Compiler e Steuerinterpreter Treiberbibliothek KAPITEL 5 ENTWICKLUNGSPROZESS 47 Tracs er CAD 01 10 2005 FEN i Konverter gt Entwicklungsschritte von Tracs Impl blau die entwickelte Komponente wird TND TransVT sp er beim Erstellungsprozess gebraucht Definition Impl weiss Zwischenprodukt dicke Elipse wiederverwendbares Produkt TransHW je gt Impl gt Compiler Weltmodell Impl Projektierungsdatenfor mat Definition o TND Definition Spezifikation SI Spezifikation Treiber Spezifikation Yy Systems gt Erstellung der sacha m gt Steuerungssystem amp spezifikation SI compilieren Treiber Quellcode Impl Treiber Impl
510. ram und damit die gesamte StraBenbahn auf dem aktuellen TE bewegt also entweder in Rich tung der kleiner werdenden Parameterwerte oder in die entgegengesetzte Richtung Ende Zwischen dem Kopf und Ende der Tram befindet sich die Bahn Die Infor mationen fiir das Ende der Tram werden getrennt festgehalten da sich die Parameterwerte aufgrund einer L nge gr er 0 der Tram unterscheiden Da sich Kopf und Ende nicht zwingender ma en auf ein und demselben TE be finden z B in dem Moment wo der Kopf gerade ein neues TE erreicht hat muss auch diese Information sowie die Richtung getrennt festgehalten wer den Die Richtung muss auf jedem TE neu bestimmt werden da Orientierung eines TEs zuf llig bzw je nach Anordnung in der TND gew hlt ist x TE Das TrackElement auf dem sich das Ende der Tram befindet x Param Der Parameter der angibt wo auf dem TE sich das Ende der Tram befindet KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 346 Direction Die Richtung in die sich das Ende der Tram auf dem aktuellen TE be wegt also entweder in Richtung der kleiner werdenden Parameterwerte oder in die entgegengesetzte Richtung Liste Diese Liste vom Typ TE enth lt alle TrackElemente auf denen sich wenn auch nur ein Teil die Stra enbahn befindet Die Visualisierung wird hier durch vereinfacht falls ein TE existiert dass vollst ndig von einer Tram be setzt ist und auf dem sich dennoch weder Kopf noch Ende der Tra
511. raphische Oberfl che am besten In der Visualisierung des Gleisnetzes erkennt der Benutzer u a Weichen Senso ren und Signale Diese drei Hardware Elemente plus die Stra enbahn en k nnen vom Benutzer gesetzt gestellt werden Die Spezifikation einer Simulation verl uft entlang der eben genannten Elemente e Stra enbahn en setzen Set Trams Das Setzen von Bahnen erfolgt in zwei Schritten Zun chst wird ein Dialog gezeigt in dem der Nutzer die gew nschte Anzahl der Bahnen festlegen kann in einem zweiten Dialog kann er dann n here Angaben zu den Bahnen eingeben Bei einer Stra enbahn gibt es folgende Spezifikationsm glichkeiten Route Die Route ist die Strecke die die Stra enbahn entlang fahren soll Es KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 304 kann eine Route aus der Liste aller Routen ausgew hlt werden Nach Start der Simulation wird die Bahn an einer Einfahrt in das Gleisnetz eintreten die zu einem RR Sensor f hrt der die gew nschte Route anfordern kann Dazu ist es wichtig dass sich zwischen Einfahrt und RR Sensor keine Weiche befindet da sonst die Bahn nicht garantiert bis zum RR Sensor gelangt da f r die Bahn kein Einfluss auf Stellung der Weiche besteht Aus gleichem Grund darf kein Signal dazwischen vorhanden sein Hat die Bahn die Route erfolgreich absolviert und das Netz verlassen wird sie kurz darauf wieder an bereits genannter Einfahrt erscheinen und ihre Route erneut absolvieren Es handelt sich a
512. rbaumanalyse Fault Tree Analysis ist ein System analyseverfahren um systematisch darzustellen wann ein unerw nschtes Ereignis auf treten kann Dazu werden alle m glichen Ursachen des betreffenden Ereignisses unter Verwendung von Boolescher Algebra miteinander verkn pft Garbage Collector Ein Garbage Collector l uft bei der Ausf hrung des Java Interpreters in regelm igen Abst nden ab und gibt Speicher der reserviert ist und nicht mehr referenziert wird wieder frei Hashing Zugriffseffiziente Verwaltung von Datens tzen Hazard Als Hazard bezeichnet man eine Situation in der eine Gefahr f r Mensch und Material besteht HW SW Integrationstest HW SW Integrationstests HSI testen ein Sub System das aus Originalhardware und integrierter Software besteht in Blackbox Form i386 Bezeichnung f r eine PC Plattform kompatibel zu einem Prozessor vom Typ 80386 der Firma Intel Java _ plattformunabh ngige Programmiersprache entwickelt von der Firma Sun Microsystems Java2TM _ Version 2 der Java Programmiersprache Java2TM Runtime Environment Laufzeitumgebung der Programmiersprache Ja va M welche zum Ausf hren von Java M Programmen ben tigt wird Java2TM_Software Developmentkit Entwicklungsumgebung f r Java zum bersetzen von Javal Quellcode ben tigt wird J2RE s Java2 Runtime Environment J2SDK s Java2 Software Developmentkit JDK JRE s Java2 Software Developmentkit und Java2 Runtime E
513. rd neten Ende wieder verlassen Als Kenngr en einer Kreuzung gibt es zwei L ngen n mlich die der beiden Strecken Auf Kreuzungen kann es durch berh hte Ge schwindigkeit zu Entgleisungen kommen insofern ist eine Maximalgeschwindigkeit vorgegeben die jedoch f r jede Richtung unterschiedlich sein kann Dar ber hinaus gibt es Kreuzungsweichen diese werden da sie zu den schaltbaren Elementen z hlen im folgenden Abschnitt ber Weichen erkl rt e Weiche Eine einfache Weiche hat auf der sogenannten spitzen Seite stem ein Ende auf der stumpfen Seite branch zwei oder drei Die Weiche kann dabei verschiedene Verbindungen herstellen das Ende der spitzen Seite kann mit einem der Enden der stumpfen Seite verbunden sein Folglich sind mehrere Strecken ber eine Weiche m glich zu einem Zeitpunkt jedoch immer maximal eine Es ist ebenso m glich dass zu einem Zeitpunkt gerade keine Verbindung geschaltet ist Eine am spitzen Ende der Weiche einfahrende Bahn wird bei fortw hrender Vorw rtsfahrt an das gerade aktiv geschaltete stumpfe Ende gelangen Ist gerade keine Verbindung geschaltet kann es zu Entgleisungen kommen Bei Einfahrt von einem stumpfen Ende sind verschiedene F lle zu unterscheiden Einfahrt von dem gerade aktiv geschalteten Ende f hrt die Bahn zum spitzen Ende Einfahrt von einem nicht aktiv geschalteten Ende kann x zur Besch digung der Weiche f hren wenn sie die Eigenschaft nicht auffahrbar hat
514. rde in HP03a ge geben Anhand dieser Beschreibung konnten bereits Konzepte zur Erstellung des physi kalischen Modells entwickelt werden Allerdings blieb zun chst relativ unklar wie das Modell des Controllers im Detail aus sehen sollte Mit Hilfe des Papers PGHDO4 das erst im Dezember 2004 zur Verf gung stand wurde das Prinzip des Controller Modells deutlicher Auch stand erst sp ter ei ne Spezifikation des Steuerungssystems zur Verf gung So konnte zu diesem Zeitpunkt noch kein sinnvolles Controller Modell erstellt werden da das Verhalten des Steuerungs systems noch nicht spezifiziert war Da auch noch keine Projektierungsdaten verf gbar waren war eine automatische Generierung des Controller Modells ohnehin noch nicht m glich Zudem existierten noch keine genauen Angaben dar ber welche Informationen die Projektierungsdaten enthalten sollten Daher haben wir zun chst eine berpr fung der Verschlusstabellen durchgef hrt Dies war m glich da f r die Verschlusstabellen berpr fung keine Projektierungsdaten und keine Spezifikation des Steuerungssystems ben tigt werden Da das System automatisch verifiziert werden sollte mussten f r jedes Gleisnetz die notwendigen Sicherheitsbedingungen automatisch abgeleitet werden und das Transiti onssystem musste automatisch erstellt werden Dazu wurden Informationen aus der TND und den Projektierungsdaten ben tigt Um die in der TND enthaltenen Informationen zu verwenden musste ein Par
515. rdwareklassen Dazu wird eine beliebige Anzahl an Deklarationen vorgenommen in denen jeweils ein Elementtyp genannt wird danach die Bezeichner f r alle vorkommenden Elemente dieses Typs Es wird dabei nach verschiedenen Arten von Elementen unterschieden Sensoren Weichen Signale Routen Markierungen Kreuzungen Hardwareklassen dabei ist f r deren jeweilige IDs ein bestimmter Anfangsbuchstabe vorgegeben Bei den Sensoren wurden die Typen an die im Weltmodell beschriebenen Typen an gepasst also rr route request td Toggle mit Richtungserkennung tg Toggle oh ne Richtungserkennung sd Zustand mit Richtungserkennung und sg Zustand ohne Richtungserkennung Bezeichner f r Sensoren beginnen immer mit g N heres zu den Typen im entsprechenden Abschnitt des Weltmodells 2 3 2 2 auf Seite 21 Bei den Weichen gibt es zwei grundlegende Typen n mlich Zwei und Dreiwegeweichen Wir unterscheiden die Weichen nach den Richtungen die sie annehmen k nnen z B sl points oder slr points Weichenbezeichner beginnen mit w N heres zu Weichen in 2 3 2 1 2 auf Seite 20 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 65 F r Signale sind zahlreiche Typen vorgesehen die Buchstaben 1 s und r in den Typ bezeichnungen stehen dabei f r die Richtungen in die das Signal die Fahrt freigeben kann Ein Ir signal beispielsweise kann demnach STOP LEFT und RIGHT anzeigen Signalbezeichner beginnen mit s N heres zu Signalen in 2 3 2 3 auf Seite 22
516. reffens hat sich herausgestellt dass H amp K nach unse rem Projektabschluss weiter mit der AGBS arbeiten m chte Es ist auch m glich dass Diplomarbeitsthemen gestellt werden an denen H amp K Interesse h tte und Projektteil nehmer h tten dadurch die M glichkeit ihre Diplomarbeiten auf Basis der vorgeschla genen Themen zu schreiben Marcin Dysarz Kapitel 3 Problembeschreibung Die Problemstellung besteht darin Stra enbahnen sicher duch ein Gleisnetz zu leiten Dabei soll auf m glichst geringe Kosten geachtet werden weshalb m glichst viele Schrit te bei der Anpassung auf ein neues Gleisnetz automatisiert werden sollen Beim Durchleiten einer Stra enbahn muss sichergestellt werden dass es nicht zu Kolli sionen zwischen Stra enbahnen kommen kann 3 1 Gleisnetzsteuerung Um das Gleisnetz zu steuern m ssen Weichen und Signale in die richtige Position gesschaltet werden so dass Kollisionen nicht geschehen Da Stra enbahnen auf Sicht fahren muss die Gleisnetzsteuerung nicht daf r sorgen dass es keine Auffahrunf lle gibt Die ben tigten Informationen ber die Positionen und gew nschten Routen der Bahnen kann das System durch Sensoren erhalten Dabei muss beachtet werden dass es verschiedene Typen von Sensoren Weichen und Signalen gibt deren Eigenschaften zusammen mit den Einfl ssen der Umwelt im Abschnitt 2 auf Seite 10 beschrieben werden 3 2 Gleisnetzsteuerungssysteme Gleisnetzsteuerungssysteme m ssen Bahnen
517. relevante Prozesse e SI init startet Treiber e SI init startet eigentlichen SI Prozess e SI init wartet auf Signale zum Runterfahren USV Ausschalter 7 5 4 2 5 Initialisierung des Safety Controller Der eigentliche SI Prozess setzt die Datenstrukturen entsprechend dem angegebenen In itialzustand und ruft danach in einer Endlosschleife wie im Architektur Kapitel beschrie ben die einzelnen Komponenten auf wie in Abbildung 7 40 dargestellt phase_master ist hierbei daf r zust ndig das Umschalten zwischen dem RC dem RD und dem SM zu regeln Steuerinterpreter projektierung phase_master RC een RC phase_master SM phase_master RD Safety Monitor _ CSsS Abbildung 7 40 SI Gesamtsystem KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 187 7 5 4 2 6 Start des Systems bestehend aus Simulator und Steuersoftware Diese Beschreibung wurde auch so verwirklicht 1 Projektierungsdaten generieren 2 Header fiir das Treiberframework generieren tram hw sh gleisnetz tnd 3 Treiber compilieren dafiir miissen im Simulator die Treiber bereits compiliert sein cd si src ddk make CC gcc g DRIVER_ARCHIVE SimTracs src drivers libsidriver a tracs drv 4 Im Simulator eine Simulation starten 5 tracs drv starten 6 SI starten si projdata Am Projekttag wurden f r jedes Gleisnetz eine passende tracs drv Datei bereitgehal ten und das Laden der TND f hrte dann direkt dazu
518. rgeordnete Ablauf mit dem n chsten sicheren Zustand aus den Projektierungsdaten Es werden dann neue united conditions gebildet usw Was in diesem Algorithmus noch fehlt ist die Verf lschung von Z hlerwerten so dass auch auf diesem Wege unsichere Zust nde hergestellt werden Ebenso werden noch keine abgelaufenen Timer benutzt um den SM auf die in diesem Fall geforderte Reaktion zu pr fen An dieser Stelle ist der Programmiervorgang beendet worden Test Orakel und Checker existieren nicht Marcin Dysarz Arne Stahlbock 7 7 6 Testausf hrung und auswertung 7 7 6 1 Generelles Es wurde ein Projekt fiir den RT Tester erstellt in das die fertigen Testprozeduren also diejenigen fiir RD und RC aufgenommen wurden Dieses Projekt ist wie folgt strukturiert e Unterverzeichnis RTC test enthalt die Testprozeduren fiir den RC KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 299 e Unterverzeichnis RTD test enthalt die Testprozeduren fiir den RD e Unterverzeichnis SUT RTC enth lt den zu testenden RC e Unterverzeichnis SUT RTD enth lt den zu testenden RD e Unterverzeichnis stubsrc enth lt Hilfsfunktionen f r Testprozeduren Im Wurzelverzeichnis der Testsuite befinden sich au erdem mehrere Konfigurationsda teien Besonderes Augenmerk ist dabei auf tracstest rtg zu richten da diese Datei f r jedes System bzw jeden Benutzer der die Testsuite einsetzen m chte ver ndert werden muss Beispielhaft kann der fragliche
519. riedenstellend Zwar gibt es auch positive Beispiele doch in diversen F llen h tte es wesentlich besser sein m ssen 9 2 6 1 5 Ein Mann Gruppen Unter den auf die Gruppenarbeit bezogenen Pro bleme am schlimmsten waren jene welche durch Teilnehmer verursacht wurden welche noch nicht einmal an der gruppeninternen Kommunikation teilnahmen und somit die Arbeit in jenen Gruppen quasi vollkommen zum Erliegen brachten Das erste Opfer war somit die Netzgraphgruppe welche seit Mitte des zweiten Semesters nur als Ein Mann Gruppe auftrat Zur H lfte des Projektes dezimierte sich dann die Anzahl der Teilnehmer auf weniger als die H lfte der urspr nglichen Zahl so dass nun auch die Gruppen Simulator und HWSW als Ein Mann Gruppen auftraten Dass in solchen Gruppen die Produktivit t nicht gerade die beste ist ist verst ndlich zumal dies auf die Motivation aller Teilnehmer dr ckt Bei der Simulator Gruppe war das Problem allerdings nur bedingt vorhanden da schon lange vor Projekthalbzeit klar war dass zwei Mitglieder das Projekt verlassen w rden da beide nicht wie der Rest der Teilnehmer das Diplom als angepeilten Abschluss anstrebten sondern den Bachelor Abschluss als Ziel hatten welcher nur ein zwei semestriges Projekt vorsah Alle anderen Gruppen hatten aber mit gr eren Problemen zu k mpfen da s mtliche Planungen auf mehr Teilnehmer ausgelegt waren und somit ein massives Problem mit der Zeitplanung auftrat Weiterhin kann in diesem
520. rierten Signals entstehen zu vermeiden e Weiche die ausgew hlten Weichen k nnen folgende fehlerhafte Verhaltensweisen simulieren Ausfall In diesem Fehlerfall reagiert die Weiche nicht mehr auf Befehle des Steuer interpreters und bleibt in ihrer aktuellen Lage stehen nur das befahren von der passiven Seite aus kann dann noch die Weiche passiv stellen Der Steuerinterpreter muss dies dann erkennen eigenm chtige Schaltungen In diesem Fehlerfall wird die Weiche sich spontan in beliebige Stellungen umschalten Wann und wie oft sie schaltet wird im Programmlauf zuf llig bestimmt Auch hier muss dann der SI reagieren e Sensor die ausgew hlten Sensoren k nnen folgende fehlerhafte Verhaltensweisen simulieren Ausfall Dieser Fehlerfall entspricht dem ersten Fehlerfall der Weiche der Sensor gibt keine R ckmeldungen mehr Dies ist vom SI allerdings nicht so leicht zu erkennen da er die Signale von den Sensoren ja nicht mit seinen eigenen Anweisungen vergleichen kann wie es bei der Weiche der Fall war liefert falsches Signal Wenn diese Option ausgew hlt wird dann reagiert der Sensor unkontrolliert und liefert falsche R ckmeldungen e Signal die ausgew hlten Signale k nnen folgende fehlerhafte Verhaltensweisen simulieren Ausfall Dies bedeutet im bertragenen Sinn das gleiche wie ein Ausfall der Weiche nur dass hier das Signal nicht mehr schaltet Abh ngig vom Zustand in der das
521. rliegt und diese dann der jeweiligen Queue hinzuf gt und einer Schleife ber alle Queues anhand der Queue Priority List in der dann gepr ft wird ob und welche Routen freigegeben werden k nnen Nun folgt eine Beschreibung der einzelnen Funktionen 7 5 4 4 3 Funktionen route_state gibt den Shared Memory Zustand des RR Sensors an hat_route gibt an ob es noch zu bearbeitende RR Sensoren gibt hat_queue gibt an ob es noch zu bearbeitende Queues gibt hat_konflikt gibt an ob eine angeforderte Route nach der RCT in Konflikt zu Routen steht die nicht im Zustand inaktiv sind zur_Queue_hinzuf gen f gt den Route Request zur in den Projektierungsdaten ange gebenen Queue hinzu und setzt den jeweiligen RR Sensor zur ck Rst_eintrag_aktiv setzt den Eintrag der jeweiligen Route auf aktiv setze_Rst_eintrag_angefordert setzt den Eintrag der jeweiligen Route auf angefor dert ink_bahn_counter_von_router inkrementiert den jeweiligen Bahnz hler f r eine Route aus_queue_l schen entfernt den Route Request aus der Queue KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 191 RD2 route_state angefordert Idle hat_route TRUE naechste_route Route J pr fen hat_Queue FALSE l Isetze_phase_RC 0 route_state angefordert setze_phase_master RC zur_Queue_hinzuf gen hat_konflikt TRUE amp amp uebersprungene_queues gt anz_queues hat_route FALSE an_den_anfang_der_qpl setze_R
522. rneuten Kontaktaufnahme Mitte Januar 2004 wur den wir nach erneuter Kurzvorstellung des Projektes TRACS weiterverwiesen an Herrn Herrmann L bbers der aber leider bis Mitte Februar telefonisch nicht zu erreichen war Herrn L bbers wurde das Projekt nochmal vorgestellt und eine Themenliste sowie der Fragenkatalog gegeben woraufhin der Besuchstermin bei der BSAG f r den 10 03 2004 vereinbart wurde Besuchsablauf KAPITEL 2 DIE DOMANE 30 Der Besuch fand statt im BSAG Zentrum Neustadt wo wir von dem bereits genannten Herrn Liibbers Bereich Schienenfahrzeugtechnik und Herrn Hatesaul Bereich Rechner gestiitztes Betriebsleitsystem empfangen wurden Nach einer kurzen Vorstellung wurde der Vortrag unterbrochen von Zwischenfragen pr sentiert Herr L bbers und Herr Ha tesaul hielten ihrerseits drei Vortr ge zum einen ber das neue Zugsteuerungssystem IMU 100 von Siemens das bis Ende des Jahres das bisherige IMU 94 abl sen soll zum anderen ber ihre rechnergest tzte Betriebsf hrung Anschliessend wurden die Fragen aus dem Fragenkatalog gestellt und gr tenteils beantwortet Pr sentation des Projektes TRACS Die Zwischenfragen beim Vortrag machten deutlich dass die Definitionen doch sehr unterschiedlich ausfallen So mussten Begriffe wie Verschlusstabellen Interlocking ta bles besonders aber der Umfang unserer Routen kleinere Gleisabschnitte mit wenigen Weichen statt die komplette Linie 6 der BSAG vom Flughafen zur Uni und die
523. ro Hardwarelement h tte man wie beim anderen Konzept auch keine Parallelit t da nie zwei Threads wirklich zeitgleich agieren sondern die Wechsel der Threads lediglich sehr oft und zu nicht festgelegten Zeitpunkten passie ren F r das Beispielnetz in Abb 7 78 auf der n chsten Seite br uchte man mindestens 27 Threads f r die Hardwarelemente zus tzlich 1 Thread pro Stra enbahn 2 Threads f r die Schnittstelle zu den Treibern und die von JavaTMselbst erzeugten Threads f r die grafische Oberfl che Zwischen diesen Threads k nnten enorme Nebenl ufigkeitseffekte erwartet werden die bei einer sequentiellen Abarbeitung v llig vermieden werden Die Behebung dieser Effekte w rde weitere Rechenleistung verschlingen die man im ande ren Fall nicht einsetzen muss Prinzipiell m sste der Rechenaufwand f r eine Runde bei beiden Verfahren zun chst einmal der Gleiche sein da die Berechnungen die Gleichen sind egal ob sie sequentiell oder quasiparallel durchgef hrt werden Bei Threads k me dann aber der Zusatzaufwand zur Bek mpfung der Nebenl ufigkeitseffekte hinzu Wir haben uns daher f r das Konzept der sequentiellen Abarbeitung entschieden welches im Folgenden n her erl utert wird Das Konzept der rundenbasierten sequentiellen Abarbeitung sieht vor dass die Hardwa relemente in einer klar definierten Reihenfolge nacheinander bearbeitet werden Jeder ausgel ste Sensor und jede berfahrene Kreuzung und Weiche werden dabei benach richtig
524. rozess hatte die Aufgabe die zwei Pro zesse Entwicklung des Gesamtsystems und Verifikation desselben zu systematisieren und somit eine wichtige Grundlage f r die weitere Arbeit und letztlich den Erfolg des Projektes zu legen Sie wurde im Laufe des zweiten Semesters eingerichtet 9 2 3 10 TND Builder Die TND Builder Gruppe war ein Ein Mann Projekt das zu Beginn des vierten Semes ters entstand und sich der Aufgabe annahm ein Eingabetool f r Verschlusstabellen und deren Integration in die TND zu entwickeln 9 2 3 11 Weltmodell FTA F r einzelne Teilbereiche gab es keine eigentlichen Gruppen Diese Teile wurden von einigen Projektteilnehmern nebenher angefertigt wobei der Hauptteil der Arbeit auf das sp te zweite und fr he dritte Semester fiel 9 2 4 Projektplenum und weitere Treffen aller Teilnehmer In der Vorlesungszeit wurde ein w chentliches Projektplenum abgehalten Auch in der vorlesungsfreien Zeit gab es Plena dann allerdings seltener zumeist zweiw chentlich KAPITEL 9 BEWERTUNG 447 Dar ber hinaus wurden wenn auch nicht h ufig weitere Treffen aller Teilnehmer au erhalb des gew hnlichen Rahmens anberaumt 9 2 4 1 Plenum Das Plenum war als das einzige regelm ige Treffen aller Teilnehmer von erheblicher Bedeutung Hier wurden vor allem Themen besprochen die f r das Gesamtprojekt von Belang waren seien es organisatorische Dinge oder konkrete Punkte in der aktuellen Arbeit Auch sollte jede Arbeitsgr
525. rrichtung die also nur manuell zu schalten ist wird als Passivweichen bezeichnet Das Verhalten einer Weiche f r den Fall dass w hrend der Umsetzung eines Schaltbefehls die Weiche ist also im Zustand gerade keine Strecke geschaltet ein weiterer Befehl eingeht ist nicht definiert Kenngr en einer Weiche sind in jedem Fall die L ngen der ber sie m glichen Strecken optional auch die o a Schaltzeit wenn eine Schaltvorrichtung vorhan den ist Eine Weiche mit Schaltvorrichtung kann abgeschaltet werden so dass sie in diesem Fall nur noch wie eine Passivweiche arbeitet Eine Weiche meldet ih ren aktuellen Zustand an das Steuersystem Auch eine Weichen gilt jeweils eine Maximalgeschwindigkeit die jedoch f r jede Richtung unterschiedlich sein kann Es gibt weiterhin Kreuzungsweichen Diese bestehen aus einer Kreuzung bei der zus tzlich zwei Einfachkreuzungsweiche EKW oder vier Doppelkreuzungswei che DKW Weichen so angebracht sind dass an dieser Kreuzung auch abgebogen werden kann Dabei ist von einem der beiden kreuzenden Gleise nur Rechtsabbie gen vom anderen nur Linksabbiegen m glich Bei der EKW besteht diese Abbie gem glichkeit nur von je einer Seite bei der DKW von beiden Seiten Das gesamte Element ist so kompakt gebaut dass es immer nur von einer Bahn gleichzeitig be fahren werden darf In diesem Sinne unterscheidet es sich von einer Kreuzung bei der Abbiegem glichkeiten in gr erem Abstand zum Kreuzungspu
526. rstellbare Anzeige gefordert wird 7 5 4 1 3 Besonderheiten des Weichentreibers Wenn mehrere Bits im Eingabebereich gleichzeitig gesetzt sind oder eine f r den Wei chentyp unm gliche Position gefordert wird dann wechselt der Treiber in den Fehlerzu stand 7 5 4 1 4 Besonderheiten des Sensortreibers Findet ein Sensortreiber ein gesetztes Reset Bit Bit 0 im Eingabeberich siehe Abschnitt 7 5 3 1 4 vor dann setzt der Sensortreiber den Zustand zur ck es geht insbesondere um Bit 10 bei Route Request Sensoren und l scht auch das Reset Bit Ausnahmsweise schreibt hier der Treiber in den Eingabebereich 7 5 4 2 Systemumgebung Im folgenden wird eine Konfiguration des Systems aufgelistet wie wir es uns vorstellen Kriterien daf r sind m glichst wenig verwenden was nicht unbedingt n tig ist aber eventuell eine zus tzliche Fehlerquelle darstellt und Vermeidung von Komponenten die KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 185 schon potentiell als unsicher ausfallgefahrdet gelten wie Festplatten stattdessen soll als zuverl ssiger geltender Flash Speicher verwendet werden Es muss dazu gesagt werden dass es sich nur um ein Konzept handelt mit teilweise grob gesch tzten Werten welches nicht umgesetzt wurde Als Abschluss folgt dann die Form wie es reell gestartet wird 7 5 4 2 1 Konzept Hardwareplattform Beispielhaftes Embedded System mit weitgehend Standard PC Hardware http www bemcom com bem_product_box3610 htm e 25
527. rt die Metho de null falls in dieser Situation eine neue Position des Endes berechnet werden soll Der R ckgabewert der Funktion bildet ein Objekt der Klasse Linkable und enth lt die berfahrenen Hardware Elemente falls in der Berechnung der Fortbewegung festge stellt wird dass ein TrackElement verlassen und ein neues betreten wurde Wurde keine Hardware berfahren so liefert die Methode null zur ck KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 379 09 pos pos dir 1 1 10 if pos gt te getLength 1 pos lt 0 amp amp C head headVanish Dann wird die Position abh ngig von der Richtung in die die Tram unterwegs ist um Eins ver ndert Ein TrackElement hat eine feste L nge und die Tram kann sich nur an den Stellen 0 L nge 1 befinden s Skizze 7 80 in diesem Beispiel L nge 5 Wenn die neue Position gr er als L nge 1 oder kleiner als 0 ist so wurde das TrackElement verlassen und die neue Position und Richtung auf dem neuen TrackElement m ssen berechnet werden Falls jedoch der Kopf das Ende des Gleisnetzes erreicht hat darf f r ihn kein neues TrackElement berechnet werden da sich in dieser Situation nur noch das Ende der Bahn weiterbewegt abgesehen davon gibt es am Ende des Gleisnetzes kein neues TrackElement mehr In headVanish ist abgelegt ob der Kopf an einem Endpunkt angekommen ist weitergerechnet werden darf nur wenn entweder nicht f r den Kopf gerechnet wird oder er nicht am
528. rten Mitgliedes bei der Arbeitsvertei lung was f r das Vorankommen des Simulators hilfreich dabei aber besagtem Mitglied die Integration unm glich gemacht h tte Man entschied sich f r die zweite M glichkeit und arbeitete bis zum Ende des Semesters praktisch zu dritt Wir sehen ein dass wir erst viel zu sp t mit dem vierten Mitglied ber die Hintergr nde KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 426 geredet haben eine fr here Diskussion dar ber h tte vermutlich die Chance auf eine gute Zusammenarbeit zu viert deutlich erh ht Die drei Mitglieder gingen davon aus dass das vierte Mitglied sie bei Problemen ansprechen w rde doch das geschah nicht Das vierte Mitglied ging aus Sicht der anderen drei davon aus dass man ihm helfen w rde auch ohne dass es darum bittet auch das geschah schon sehr fr h nicht mehr Aufgrund dieser nicht vereinbarenden Haltungen kam es sehr fr h zum Bruch innerhalb der Gruppe und eine echte Probleml sung fand nicht statt Nach Beginn des dritten Semesters schied das besagte Gruppenmitglied dann relativ schnell aus dem Projekt aus Einerseits ist es zu begr en dass auf diese Weise die doch relativ ungewisse und folglich nicht f rderliche Situation bez glich der Frage ob das Mitglied noch auf eine Weise in das Projekt bzw die Gruppe integriert werden k nnte dass eine f r das Projekt n tzliche Leistung erbracht werden w rde gekl rt wurde andererseits muss man diese Art der L sung
529. s int num_lock_sig struct test_shm_value_t lock_sig_pos int num_req_sig struct test_shm_value_t req_sig_pos int entry_sens_id int exit_sens_id END Strukturen f r RC BEGIN Strukturen f r SM struct test_sm_condition_t int type void condition union struct shm_value_t shm_value struct sensor_value_t sensor_value condition 3 struct test_sm_condition_list_t int num_cond struct test_sm_condition_t sm_conditions F struct test_hw_timeout_t int id time_t timeout struct test_sm_data_t int num_cond_list struct test_sm_condition_list_t sm_condition_lists int num_hw struct test_hw_timeout_t hw_timeouts END Strukturen f r SM 270 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 271 Hauptstruktur enth lt alle anderen struct test_projdata struct test_offsets_t offsets struct test_version_t version struct test_rd_data_t rd_data int num_rc_data struct test_rc_data_t rc_data struct test_sm_data_t sm_data Beim Vergleich mit den SI Datenstrukturen f llt auf dass unsere Datenstrukturen diesen fast entsprechen Zur Unterscheidung wurde das Namenspr fix test eingef hrt und alle eingef hrten L ngenangaben beginnen mit num Dar ber hinaus ist die einzig nennenswerte Differenz dass in struct test_sm_condition_t statt der union condition ein void condition ein gef hrt wurde der dann da ohnehin je nach Typ der condition imme
530. s Gleisst ck der Stammseite stem hervorgehoben KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 361 Gleis Kreuzung berf hrung Pi j N w a Me Weiche Sensor Signal i Y Stra enbahn mit Knick Stra enbahn PA Abbildung 7 76 Visualisierung der Gleiselemente e Sensoren Sensoren befinden sich auf einem Gleisst ck und werden daher farbig mit einer gewissen Ausdehnung gezeichnet Sie werden durch einen kolorierten ausgef ll ten Kreis visualisiert Die Farbe zeigt abh ngig vom Typ des Sensors den Zu stand an ToggleSensoren haben zwei Farben f r die beiden Toggle Stellungen Zustandssensoren sind zwei andere Farbt ne zugewiesen f r die Visualisierung des Zustands RouteRequestSensoren stellen ihren Zustand ob sie ausgel st sind oder nicht ebenfalls durch Farben wie die Zustandssensoren dar wobei im Zeitpunkt des Ausl sens neben der Zeichung des Sensors die Bezeichnung der angeforderten Route erscheint e Kreuzungen Kreuzungen auf denen es zu einem Zusammensto kommen kann m ssen sich unterscheiden von berf hrungen bei denen das eine Gleis ber eine Br cke ber das andere Gleis hin ber f hrt Eine Kreuzung wird dadurch angezeigt dass die Gleise in Kreuzungsmitte dicker gezeichnet werden Im Gegensatz dazu wird eine KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 362 berf hrung nicht extra gekennzeichnet s Abbildung 7 76 auf der vorherigen Seite erste Zeile e Stra enbahnen Stra e
531. s Steuerungssystem muss die Signale und Weichen so schalten dass keine dieser Sicherheitsbedingungen verletzt wird In welcher Situation die Signale und Weichen f r das jeweilige Gleisnetz wie geschaltet werden sollen wird in den Projektierungsdaten definiert Mit Model Checking wird ber pr ft ob die in den Projektierungsdaten definierten Anforderungen zu keinem Zustand f hren k nnen in dem eine Sicherheitsbedingung nicht erf llt ist Es wird ein formales Modell erstellt Dazu werden die Spezifikation des Systems die in der TND Netzwerkbeschreibung enthaltenen Informationen sowie die in den Projektie rungsdaten enthaltenen Informationen verwendet Model Checking wird ausf hrlich im Abschnitt 7 6 auf Seite 203 behandelt Ruben Rothaupt 4 3 2 Automatisierter Test Zur berpr fung des gesamten Hardware Software Systems wird ein automatisierter Vorgang benutzt Die Testautomatisierung erm glicht eine schnellere und sicherere Test ausf hrung als w rde es ein Mensch machen In einer k rzeren Zeit kann man eine gr ere Testabdeckung und dadurch eine Verringerung der Qualit tsrisiken erreichen Es stellt sich heraus dass bei der wiederholten Testdurchf hrung gegen ber manuellen Tests die Testprozeduren jedes Mal reproduziert werden k nnen Die Vorbereitung der Testprozeduren im Vergleich zur manuellen Testausf hrung fordert mehr Initialauf wand Der Durchf hrungaufwand ist aber gering Die Schnittstellen Definition spie
532. s der Treiber sich beendet hat e Bei Statusmeldungen status lt Element ID gt lt Zust nde gt wobei status das Schl sselwort f r ei ne Statusmeldung darstellt lt Element ID gt der eindeutige Bezeichner des HW Elements und lt Zust nde gt eine nicht leere Menge von Zust nden ist M gliche Zust nde sind left straight right undefined bei Signalen und Weichen bei Signalen kommen noch noch stop waitstraight waitleft waitright rrstraighton rrstraightoff rrrighton rrrightoff rrlefton und rrleftoff hinzu Bei Sensoren sind die Zust nde dira Sensor wurde in Richtung A berfahren dirb analog Richtung B tramon Bahn anwesend tramoff kei ne Bahn anwesend toggleon Toggle Bit gesetzt toggleoff Toggle Bit nicht KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 366 gesetzt und rr Route Request ausgel st wobei bei Letzterem auch noch die Routenbezeichnung nach einem Leerzeichen mitgeschickt wird e Initiale Meldung an den Simulator init lt Element ID gt siehe Beschreibung der Initialisierung oben 7 8 4 7 Korrektheit Die Korrektheit des Simulators kann letzten Endes sicherlich nicht vollst ndig gew hr leistet werden da der Simulator als nicht sicherheitsrelevante Software nicht in den Verifikationsprozess des Projektes eingebunden ist lediglich soll mit ihm die CAD TND Konvertierung gepr ft werden und daher kein formaler Korrektheitsbeweis oder hnli ches durchgef hrt wird Dennoch muss nat rlich auf
533. s dient dazu die Markierung von Weichenkonflikten im Route Conflict Table zu berpr fen MODULE point straight_cond left_cond right_cond VAR state UNDEFINED STRAIGHT RIGHT LEFT point_conflict boolean ASSIGN init state UNDEFINED init point_conflict 0 next state case straight_cond STRAIGHT KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 244 left_cond LEFT right_cond RIGHT 1 state esac next point_conflict case straight_cond amp left_cond straight_cond amp right_cond left_cond amp right_cond 1 1 point_conflict esac 7 6 6 2 2 Initialisierung der Variablen F r alle in einem Gleisnetz enthaltenen aktiven Weichen werden Variablen erstellt Dazu wird jeweils das Modul point aufge rufen und als Parameter werden die Bedingungen bergeben die angeben wann die Weiche den jeweiligen Zustand annehmen soll Dabei sind nur Anforderungen m glich die mit dem jeweiligen Weichentyp vereinbar sind w1022 point w1022_straight w1022_left none w1018 point w1018_straight none w1018_right w1020 point w1020_straight none w1020_right 7 6 6 2 3 Bedingungen zum Stellen der Weichen Eine Weiche soll in eine be stimmte Richtung gestellt werden wenn eine Route befahren werden soll f r die im Point Position Table die entsprechende Weichenstellung definiert wurde So soll in dem Beispiel die Weiche w1022 auf geradeaus gestellt werden wenn die Route route25 befahren
534. schieht durch folgende Regel direction LEFT RIGHT STRAIGHT gt Als n chster Block folgt der Clearances Block Dieser wird wie immer auf folgende Weise ausgewertet Dieser wird im Prinzip genause wie der Conditions Block ausgewertet nur dass hier statt der Bezeichner fiir die notwendigen Weichen die Bezeichner fiir die entsprechenden Signale ausgewertet werden miissen Der Point Conflicts Block ist der n chste auszuwertende Block Dieser ist den vorherigen auch wieder sehr hnlich und soll deswegen hier einmal ohne speziellere Erl uterungen gezeigt werden ptconfblock POINT_CONFLICTS confdeflist gt confdeflist confdef makeConflictList confdef confdeflist makeConflictList confdef ROUTEID ROUTEID kommaroutelistopt makeConflict kommaroutelistopt kommaroutelist empty kommaroutelist ROUTEID makeList ROUTEID kommaroutelist makeList KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 162 Die einzige in hnlicher Form bisher noch nicht aufgetretene Auswertungsregel ist die f r confdef Diese braucht den Bezeichner f r die entsprechnende Route die von einem oder mehreren Bezeichnern der mit ihr in Konflikt stehenden Routen gefolgt wird Der Conflicts Block sieht noch einfacher aus da er dem Point Conflicts Block nahezu gleicht confblock CONFLICTS confdeflist Er hat diese eine Auswertungsregel da das einzig
535. sen Test generator e Implementierung der Funktionalit t aus einem Testdatensatz den vom SUT er warteten Output zu bestimmen Testorakel e Implementierung der Funktionalit t den vom SUT gelieferten Output mit dem des Testorakels zu vergleichen Testchecker 7 7 9 4 1 Bestimmung einer Menge von Testf llen Hierzu betrachten wir zun chst die Parameter der zu testenden Funktion int check_safety shm_state_t shadow shm_state_t realshm struct sm_data_t sm_data Es werden also bergeben e eine von den RCs ggf ver nderte Kopie des Shared Memory e der aktuelle Ist Zustand des Shared Memory KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 292 e die zum SM geh rigen Projektierungsdaten im Wesentlichen die Sicherheitsbe dingungen Es war von vorn herein klar dass die Herstellung aller m glichen Eingabekombinatio nen nicht machbar war da jedes einzelne SHM Element 32 Bit umfasst und es davon wiederum in einem gr eren Gleisnetz recht viele geben kann Es war daher eine sinnvolle Untermenge zu finden Hierf r wurde das spezifizierte Ver halten der zu testenden Funktion betrachtet Sie soll einerseits den aktuellen Ist Zustand auf Sicherheit pr fen andererseits auch den von den RCs geforderten Soll Zustand Nur wenn beide sicher sind und gleichzeitig auch kein Timer abgelaufen ist wird der Soll Zustand in das SHM geschrieben andernfalls erfolgt der bergang in den Fehlerzustand Die Idee war nun folgende Es wird ber
536. sensor bereits erreicht wurde und der Ausgangssensor noch nicht Wenn in dem Beispiel die Route route23 befahren wird dann muss es in jedem Fall zu einem Zustand kommen in dem der Eingangssensor g4125 bereits erreicht wurde und der Ausgangssensor g4128 noch nicht Dadurch wird sichergestellt dass zuerst der Eingangssensor und erst danach der Ausgangssensor erreicht wird Zudem muss in je dem Fall ein Zustand erreicht werden in dem sowohl Eingangssensor g4125 als auch Ausgangssensor g4128 erreicht wurden SPEC route_A route23 amp route_B no gt AF g4125 reached amp g4128 reached amp KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 252 AF g4125 reached SPEC route_A route24 AF g4125 reached AF g4125 reached amp g4126 reached SPEC route_A route25 amp route_B no gt amp g4128 reached amp amp amp amp AF g4129 reached amp g4130 reached amp amp amp amp amp amp route_B no gt 184126 reached amp AF g4129 reached amp g4130 reached SPEC route_A route26 amp route_B no gt AF g4129 reached amp g4126 reached amp AF g4129 reached amp g4126 reached SPEC route_A route27 amp route_B no gt AF g4127 _reached amp g4130 reached amp AF g4127 reached amp g4130 reached SPEC route_A route28 amp route_B no gt AF g4127 reached amp g4128 reached amp AF g4127 reached amp g4128 reached Schlie lich soll noch die berein
537. ser zum Einlesen der TND implementiert werden Es wurde im Plenum beschlossen den Parser der Compiler Gruppe zu verwenden H ufige TND nderungen f hrten zudem dazu KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 254 dass auch unser Programm mehrere Male an die aktuelle Version angepasst werden musste Die Verifikation wurde f r die vier Gleisnetze ausgef hrt die im Plenum als Teststrecke anerkannt wurden Es lie sich dabei nachweisen dass alle Sicherheitsbedingungen erf llt waren Schnittstellen bestanden vor allem zu der Compiler Gruppe da die von dieser Gruppe ge nerierten Projektierungsdaten berpr ft werden sollten Zudem existierten Ber hrungs punkte mit der TND Gruppe da bestimmte Informationen aus der TND ben tigt wur den und somit dort enthalten sein m ssten Au erdem gab es eine Abh ngigkeit von der Steuerinterpreter Gruppe da diese f r die Erstellung der Systemspezifikation zust ndig war die ben tigt wurde um das Controller Modell zu erstellen Zudem wurde zur Er stellung des Entwicklungs und Verifikationsprozesses mit der Steuerinterpreter Gruppe und der Testgruppe zusammengearbeitet Am Anfang des dritten Semesters haben zwei Mitglieder der Gruppe das Projekt ver lassen Dieser Ausfall wurde von den restlichen Mitgliedern verkraftet Da das erstellte Programm automatisch berpr ft ob alle Sicherheitsbedingungen in dem Transitionssystem das das Verhalten des Systems modelliert erf llt sind sind wir mit u
538. sgangssensors sich also keine Bahnen mehr auf der Route befinden In dem Beispiel soll demzufolge die Route rO den Zustand INACTIVE annehmen wenn sie sich im Zustand LOCKED befindet das Signal s3013 auf STOP steht und der Eingangs sensor g4125 den selben Z hlerwert hat wie der Ausgangssensor g4128 rO_inactive_cond case r0 state LOCKED amp s3013 state STOP amp g4125 ctr g4128 ctr 1 1 2205 esac ri_inactive_cond case ri state LOCKED amp s3013 state STOP amp g4125 ctr g4126 ctr 1 1 0 esac r2_inactive_cond case r2 state LOCKED amp s3014 state STOP amp g4129 ctr g4130 ctr 1 1 05 esac KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 227 r3_inactive_cond case r3 state LOCKED amp s3014 state STOP amp g4129 ctr g4126 ctr 1 1 0 esac r4_inactive_cond case r4 state LOCKED amp s3015 state STOP amp g4127 ctr g4130 ctr 1 1 22203 esac r5_inactive_cond case r5 state LOCKED amp s3015 state STOP amp g4127 ctr g4128 ctr 1 1 2 0 esac 7 6 4 6 Routenanforderungen Jedem Route Request Sensor werden eine Reihe von Routen zugeordnet die an diesem Route Request Sensor angefordert werden k nnen Zudem wird jedem Route Request Sensor eine Warteschlange zugeordnet die die eingegangenen Routenanforderungen spei chert Hier wird jeweils die Anforderung ermittelt die sich an der ersten Position der betreffenden Warteschlange befindet In dem Beispi
539. sicher durch das System auf den gew nsch ten Routen durchleiten Dazu m ssen die Routen unterschieden werden es muss al so erkannt werden auf welcher Route die Bahnen das System durchfahren soll Die Gleisnetzelemente m ssen dann so geschaltet werden dass das Durchfahren der Routen m glich wird Dabei muss auf Sicherheit geachtet werden Das bedeutet dass es durch die Gleisnetz steuerung nicht zu Sach und Personensch den kommen darf Dazu m ssen Konflikte erkannt werden Angeforderte Routen d rfen also nur dann freigeschaltet werden wenn 39 KAPITEL 3 PROBLEMBESCHREIBUNG 36 sie nicht im Konflikt zueinander oder zu bereits freigeschalteten Routen stehen Es darf also nicht zu Kollisionen zwischen Bahnen kommen Dazu geh rt auch dass erkannt wird wenn Routen wieder frei sind was durch Auswertung der Sensorinformationen er folgen muss damit dazu im Konflikt stehende Routen dann auch freigeschaltet werden k nnen Weiterhin ist zu sicherzustellen dass durch geeignete Signalstellungen verhindert wird dass Bahnen nicht auf Weichen fahren die gerade geschaltet werden und es dadurch zu Entgleisungen kommen kann Au erdem ist zu gew hrleisten dass eine Bahn nicht unn tig lange wartet es muss also Fairness gew hrleistet werden Es d rfen also nicht st ndig dieselben Routen freigeschal tet werden wenn auch dazu im Konflikt stehende Routen angefordert sind In den folgenden beiden Abschnitten wird dann zwischen automatisch
540. sinroute trSignal signalsvalue String conflictroutes trRoute pointconflictroutes trRoute pointsinroute trTNDObj routes trRoute null crossings trCrossing null signals trSignal null sensors trSensor null jectStore points trPoint null marks trMark null conflicts point conflicts Abbildung 7 28 Klassendiagramm Hier werden alle wichtigen Klassen kurz erklart e trDevice trDevice ist die Oberklasse Sie ist eine Abstraktion der Hardwareele mente die im Gleisnetz existieren Zwischen den einzelnen Hardwareelementen gibt es direkte Nachbarschaftsbeziehungen Die Nachbarschaftsbeziehungen wird durch die Reihenfolge festgelegt in der sie von Bahnen befahren werden k nnen Jedem Hardwareelement ist eine Liste von direkt vorhergehenden Hardwareele menten und eine Liste von direkt nachfolgenden Hardwareelementen zugeordnet e trPoint trSignal trSensor trMark trCrossing Dies sind alle konkreten Hardwa retypen die in der TND vorkommen trPoint repr sentiert die im Gleisnetz KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 132 enthaltenen Weichen Ein Objekt von diesem Typ kann mit maximal vier anderen Hardwareelementen verbunden werden trCrossing repr entiert die im Gleisnetz enthaltenen Kreuzungen Ein Objekt von diesem Typ kann mit maximal vier an deren Hardwareelementen verbunden w
541. snetzes ben tigt N here Information befinden sich im Kapitel zum Steuerinterpreter 7 5 7 4 4 3 1 Route Dispatcher Der Route Dispatcher dient im Steuerinterpreter da zu nur Routen freizugeben ide nicht mit zu dem Zeitpunkt freigegebenen Routen in Konflikt stehen Hierzu ben tigt dieser eine Konflikttabelle die ihm der Compiler zur Verf gung stellt Zus tzlich werden noch Daten f r notwendige Warteschlangen bei meh reren Routenanforderungen generiert Der Compiler ben tigt f r diese Erstellung die Daten aus dem Syntaxbaum und der Symboltabelle Die Hauptfunktion zum Generie ren der Route Dispatcher Projektierungsdaten ist struct rd_data_t getRDData struct section_t syntree Diese erh lt als Eingabe den zum Gleisnetz geh renden Syntaxbaum und erzeugt daraus die Projektierungsdaten f r den Route Dispatcher Diese Daten sind dann im folgenden Struct enthalten struct rd_data_t int max_routes char rct int max_queues int queue_tab Hierbei ist maxroutes die Anzahl der Maximalen Routen rct beinhaltet die Zweidimen sionale Konflikttabelle die aussagt welche Route mit welcher anderen Route in einem Konflikt steht Die Anzahl der Routerequest Queues ist in maxqueues enthalten und in queuetab liegt eine Zuordnung der Routen zu den Queues vor Als erstes wird in dieser Funktion der Speicher f r die Projektierungsdaten allokiert Danach wird die Anzahl der Routen berechnet und in das Struct eingetragen Als n chster S
542. software zu erzeugen Der Abschnitt 5 3 auf der n chsten Seite gibt einen berblick ber die dazu von uns entwickelten Komponenten Der Erstellungsprozess der die ein zelnen Schritte von den Systemeingaben bis zum Endprodukt beschreibt wird in Ab schnitt 5 4 auf Seite 47 erl utert Taffou Happi Deng Zhou Ruben Rothaupt berarbeitet von Andreas Kemnade 5 2 Umfang des von TRACS gelieferten Systems Die Aufgabe von TRACS ist es eine ausf hrbare Steuerungssoftware f r ein konkre tes Gleisnetz des Stra enbahnbetreibers zu erzeugen Dazu werden bestimmte Eingaben ben tigt Man kann dabei zwischen Eingaben unterscheiden die f r jedes Gleisnetz neu gemacht werden m ssen und Eingaben die f r jedes Gleisnetz konstant sind F r jedes konkrete Gleisnetz muss eine Gleisnetzbeschreibung vorliegen die zu verwendende Hard ware muss vom Kunden spezifiziert werden und die Verschlusstabellen m ssen erstellt werden Die Verschlusstabellen enthalten Angaben ber zu befahrende Routen Routen konflikte und die f r die jeweilige Route ben tigten Weichen und Signalstellungen Die Systemanforderungen und die PC Hardware sind f r jedes Gleisnetz gleich 45 KAPITEL 5 ENTWICKLUNGSPROZESS 46 Tracs 05 10 2005 Tracs Grenzen dicke Elipse konstant f jedes Gleisnetz normale Elipse f jedes Gleisnetz neu gre Endprodukt Verschluss tabellen Netzgraph Hardware spezifikation von Kunden Systemsanforderung BOSt
543. sollte da zwar nichts ver ndert sein nach den weiteren wird das aber der Fall sein Ab dieser Stelle hat der Testvorgang dasselbe Schema Speicher kopieren einen Wert verf lschen auf test_shadow und test_real abbilden und den Testling aufrufen Es wird nun der Verf lschungs Algorithmus beschrieben int test_interrationen united_cond_size for test_loop lt test_interrationen test_loop Erstmal wird festgestellt wie viele Testiterationen f r einen sicheren Zustand gemacht werden m ssen Diese Zahl ist gleich der Anzahl der HW Elemente Die Schleife hat mehrere Zweige die hnlich arbeiten Diese werden hier nicht komplett dargestellt Ein Zweig wird als Beispiel beschrieben int tmp_id_to_test hw_to_test test_loop id if tmp_id_to_test gt 1000 amp amp tmp_id_to_test lt 2000 Zun chst wird die erste HW ID aus der Struktur hw_to_test geholt und es wird gepr ft was f r ein Hardware Element vorliegt eine Weiche ein Signal ein Sensor KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 297 if hw_to_test test_loop input_size 0 if hw_to_test test_loop input_mask 0 tue nichts else for i 0 i lt 16 i int input_mask_tmp hw_to_test test_loop input_mask if input_mask_tmp amp 1 lt lt i int setze_bit i hw_to_test test_loop input pow 2 setze_bit else ein input Bit gesetzt dann loeche for i 0 i lt 16 i int input_mask_tmp h
544. sors Welches Sensor welche Funktion hat ist dem Textfeld zu entnehmen Die Abkiirzungen entspre chen den bereits anderweitig im Bericht benutzen Bezeichnungen z B Kapitel 7 5 3 1 4 ANHANG C DXF OBJEKT BIBLIOTHEK 472 Seite 177 Abbildung C 4 Schienen Objekte Kreuzungen Die Abbildung C 4 zeigt Kreuzungs Objekte der Teil Bibliothek track AN JAN i deadend entrance exit mark Abbildung C 5 Sonstige Objekte Die Abbildung C 5 zeigt sonstige Schienen Objekte der Teil Bibliothek others Die Be deutung der Elemente ist der Abbildung zu entnehmen Henrik R hrup Anhang D Netzgraph Konfigurationsdatei D 1 Beispiel einer Netzgraph Konfigurationsdatei Es folgt ein Ausschnitt aus der Konfigurationsdatei Separator conf f r die Netzgraph Klasse DXF Separator java HHH HHH HHH HHH HH HH HH H FH OF config file for DXFSeparator class lines with leading comment char are ignored lines with only blanks dto empty lines dto line format as follows description of code code example X Coordinate 10 The value before the first is the description of the DXF control code tag Every character except is allowed The value between the first and the second is the code tag itself The value after the second is the section descriptor e for ENTITIES and b for BLOCKS No other characters are allowed The control code consists of 1 to 3 digits If the number of d
545. speichern aber der sinnvollste Zeitpunkt f r entsprechende Fehlerchecks w re Zu diesem Umstand folgt noch eine allgemeine An merkung mit einer anderen L sungsidee 7 2 5 8 auf Seite 120 Die so gewonnen Informationen werden nun von einer weiteren Klasse des Konver ters TNDCreator java Seite 98 weiterverarbeitet Dazu werden die erzeugten Objekte in ArrayLists einem Objekt Typ in Java in welchem mehrere andere Objekte ab speicherbar sind einsortiert welche als eine Art Sortiercontainer dienen Diese Array Lists oder besser gesagt Objekte vom Typ NGElementList vgl 7 2 3 2 8 auf Seite 97 werden sp ter von der Klasse TNDCreator java entprechend ausgelesen Die Detailansicht des Klassendiagramms f r die hier beschriebende Klasse siehe Abbil dung 7 8 zeigt die Liste der verwendeten Attribute und Methoden Hier werden unter anderem die angesprichenden Sortier Container defininiert in welche letztlich alle Gleis KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 96 netzelemente durch die Methode sortElements einsortiert werden Die Methoden loadBlocks und loadEntities lesen die durch den DXFSeparator er zeugten Zwischendateien entities tmp tng und blocks tmp tng ein und sammeln die In formationen zu einzlenen Zeichnungsobjekten in Objekte vom Typ NGElement siehe dazu 7 2 3 2 7 Da sich in einer DXF Datei sowohl Zeichnungsbl cke befinden welche ein Gleisnetz element enthalten als auch solche die nur zur Gruppierung von Gl
546. sprozess ist der Entwicklungsprozess Hier wurde geplant in welcher Form jeder Zwischenschritt des Entwicklungsprozess verifiziert bzw validiert werden kann Der TRACS Verifikationsprozess bildet damit die Grundlage f r einen Beweis ber die Sicherheit des TRACS Gesamtsystems 1 7 Sicherheitsnachweis Ein Bahnsteuerungssystem soll im wesentlichen einen reibungslosen und vor allem si cheren Ablauf des Bahnbetriebs gew hrleisten Um die Sicherheit des von TRACS ent wickelten Systems sicherzustellen wurden m gliche Gefahrenquellen identifiziert welche den Betrieb gef hrden k nnten Dazu wurde die Fehlerbaumanalyse als eine systemati sche Methode verwendet um alle m glichen Ursachen f r Fehlverhalten eines TRACS Controllers zu identifizieren Sie wird zus tzlich benutzt um m gliche Fehler im TRACS internen Entwicklungs und Verifikationsprozess aufzudecken Als Ergebnis der Fehler baumanalyse erh lt das Projekt TRACS eine Liste von Anforderungen an Entwicklungs und Verifikationsprozess und zu entwickelnde Controller Da die Fehlerbaumanalyse auf dem TRACS Weltmodell basiert sind diese resultierenden Anforderungen geeignet um Verletzungen der Sicherheitsanforderungen innerhalb eines des TRACS Weltmodells ent sprechenden Umgebung zu vermeiden KAPITEL 1 EINLEITUNG 9 1 8 Bewertung Das Ziel am Ende des Projekts ein Bahnsteuerungssystem zu erhalten ist weitestge hend erreicht wenn auch nicht alle Details wie urspr nglich ange
547. ss alle Eigenschaften mit true ausgewertet werden specification AG safe is true specification AG gi_reachable amp g2_reachable is true specification AF gi_reachable is true specification AF g2_reachable is true invariant safe is true invariant gi_reachable amp g2_reachable is true 7 6 3 2 2 Simulation Zudem kann man eine Simulation des modellierten Systems ausf hren Dadurch l sst sich beobachten wie sich das Modell in bestimmten Situationen verh lt Mit dem Kommando NuSMV int mc_bsp smv kann man in den interaktiven Modus wechseln Danach l sst sich mit dem Kommando go das Model einlesen und mit dem Kommando pick_state r ein zuf lliger Startzustand ausw hlen Die Simulation wird mit dem Kom mando simulate gestartet wobei angegeben werden muss wie lang der zu erzeugende Pfad sein soll und auf welche Weise er erzeugt werden soll Mit der Option r wird z B ein zuf lliger Pfad erzeugt Der aktuelle Zustand der Simulation kann mit dem Kommando print_current_state v ausgegeben werden und der erzeugte Pfad mit dem Kommando show_traces v Um eine neue Simulation zu starten l sst sich mit dem Kommando goto_state ein exis tierender Zustand als Anfangszustand der neuen Simulation ausw hlen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 213 NuSMV gt go NuSMV gt pick_state r NuSMV gt print_current_state v Current state is 1 1 safe 1 g2_reachable 0 gi_reachable 1 si GO s2 STO
548. ss es f r unsere Zwecke unzureichend ist da die vorlie gende Version zwar Bl cke einlesen und darstellen und somit auch mit unserer Objekt Bibliothek umgehen aber intern diese Elemente nicht mehr als solche Bl cke abspeichern kann sondern stattdessen diese in die einzelnen Bestandteile eines Blocks wie z B Li nien Kreise etc aufl st was das sp tere korrekte Einlesen zum Zwecke der Konver tierung nahezu unm glich machen w rde Daher haben wir uns dazu entschieden die aktuelle Version 2 x zu verwenden da diese die Unzul nglichkeiten der Vorg ngerversion KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 88 Abbildung 7 5 Gleisnetzzeichnung mit ausschlie lich Gleisen nicht aufweist Der angenehme Nebeneffekt war auch der weitaus gr ere Funktions umfang welcher bequemere Nutzungsm glichkeiten wie z B deutlich umfangreichere Men strukturen klarer formulierte Dialoge etc bereitstellte Zur Einarbeitung geh rte auch die Untersuchung des Ausgabeformates DXF da die DXF Datei letztlich die Eingabedatei f r die n chste Aufgabe ist Zum DXF Format ist folgendes anzumerken Es existieren z Z rund zwei Dutzend Ver sionen des DXF Formates da dieses Dateiformat von der selben Firma Autodesk ent wickelt worden ist welche auch die Software AutoCAD vertreibt und bei jeder nahezu j hrlich erscheinenden neuen Version dieser Software erscheint auch eine berarbeitete Version des DXF Dateiformates Bei der Untersuchung
549. ss sie diese berfahren hat da Sensoren ausl sen und Weichen passiv gestellt werden k nnen Wurde ein Sensor berfahren so muss er aktiviert werden Dabei wird das alte Gleiselement bergeben damit Richtungssensoren feststellen k nnen in welcher Richtung sie berfahren werden Wurde ein Gleisst ck von der Tram vollst ndig verlassen so muss die berfahrene Hardware als nicht mehr besetzt gekennzeichnet werden Dabei wird allerdings noch vermerkt dass sie erst in diesem Zyklus verlassen wurde um die Kollisionsab frage nicht vom Zufall welche Bahn zuerst in einem Zyklus bewegt wird abh ngig zu machen War das berfahrene Element ein Sensor so wird dieser deaktiviert Damit ist die Methode beendet 7 8 4 4 3 Initialisierung einer Simulation Bevor eine Simulation gestartet wer den kann ist es notwendig zuerst grundlegende initiale Daten festzuhalten Diese Daten dienen der Spezifikation einer bestimmten Situation die mit dem Simulator nachgestellt KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 353 Tram doFinish passed head hw passed tail hw old track of head head on new track occupy passed hardware hardware turnout sensor remember hardware hardware sensor activate sensor tail on new track occupy passed hardware hardware sensor Abbildung 7 75 Aktivit tsdiagramm Tram doFinish werden soll Zur Eingabe dieser Initial Daten eignet sich eine g
550. sst u a das Erkennen von Gleis netzelementen deren Eigenschaften und Beziehungen da diese die Grundlage unserer TND darstellen Da nicht alle f r eine vollst ndige TND ben tigten Informationen wie z B Routen informationen in einer graphischen Beschreibung sinnvoll aufgehoben sind wird diese Roh TND noch mit einem zus tzlichen Tool namens TND Builder nachbearbeitet um diese Informationen einzuf gen Das Zwischenprodukt am Ende dieses Schrittes ist eine TND die s mtliche f r das Steuerungssystem und dessen Verifikation notwendigen Daten enth lt Eine genaue Beschreibung findet sich in den Abschnitten 7 2 auf Seite 82 und 7 3 auf Seite 123 4 2 1 2 Compiler Die im ersten Schritt generierte TND stellt nicht nur den Ausgangspunkt f r die sp te re Verifikation dar sondern auch f r den weiteren Generierungsprozess durch unseren TND Compiler Dieser transformiert die in Textform vorliegende TND in ein bin res Format welches sp ter die konkreten Anweisungen f r das spezielle Steuerungssystem liefert Hierbei wird die TND auf Korrektheit gepr ft aus den vom Anwender definier ten Verschlusstabellen werden konkrete Sicherheitsbedingungen generiert und aus den Routendefinitionen werden konkrete Schaltinformationen extrahiert Ausserdem werden die notwendigen Daten gewonnen damit der Steuerinterpreter sp ter auch die richtigen Treiber f r die im Gleisnetz verwendete Hardware benutzt KAPITEL 4 DER LOSUNGSANSATZ 42 Eine
551. st total max_rst gen_rst 0 max_qpl fac pdata gt rd_data gt max_queues total max_gpl printf The QPL can have d states n max_qpl gen_qpl 0 max_left_queues 2 total max_left_queues gen_left_queues 0 max_rr pdata gt rd_data gt max_routes 1 total max_rr gen_rr 0 stop_tests 0 printf Total lld test cases n total 7 7 5 2 3 Testorakel Das Testorakel erhalt die gleichen Eingaben wie das SUT und soll die vom SUT erwar teten Ausgaben bestimmen Es muss die Eingaben allerdings nicht in exakt gleicher Form bekommen so kann z B hier auf eine Ubergabe des kompletten SHM Zustandes verzichtet und nur die Information zu den RR Sensoren gegeben werden w hrend das SUT den gesamten SHM Zustand verlangt auch wenn es ihn nicht komplett auswertet Die Eingaben m ssen nur inhaltlich bereinstimmen und korrekte Vorhersagen erm gli chen Daher muss das Orakel gem der Spezifikation des SUT implementiert werden ohne dabei allerdings das SUT zu kopieren Das erreicht man am besten indem man die SUT Implementierung nicht betrachtet bis das Orakel fertiggestellt ist Weicht man wie oben beschrieben bei den Eingaben von der Form in der das SUT sie be kommt ab folgt daraus sogar zwangsl ufig eine andere Implementierung Diesen Weg zu beschreiten ist auch im Wesentlichen gelungen das SUT wurde erst bei den ers KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 283 ten fehlges
552. st auch der Definitions Block im tram Syntaxbaum notwendig um direkten Zugriff auf Elemente nach Typ zu erhalten So k nnen durch diesen Teil des Syntaxbaumes etwa alle Links Geradeaus Weichen direkt gefunden werden ohne die Symboltabelle durchsuchen zu m ssen Abbildung 7 32 zeigt den Aufbau dieses Teilbau mes 7 4 3 4 3 struct slipswitch_t Der Slipswitch Block der TRACS TND fasst meh rere Weichen zu einer Kreuzungsweiche zusammen Diese Informationen werden inner halb der Projektierungsdatengenerierung ben tigt um erkennen zu k nnen welche Wei chen nur gemeinsam geschaltet werden k nnen Abbildung 7 33 beschreibt die resultie rende Speicherstruktur dieses Blockes innerhalb des entstehenden Syntaxbaumes KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN struct definitions_t rsensors struct idlist_t tdsensors struct idlist_t 1gsensors struct idlist_t sdsensors struct idlist_t sgsensors struct idlist_t slpoints struct idlist_t srpoints struct idlist_t Irpoints struct idlist_t sIrpoints struct idlist_t 145 OOOO r Isignals struct idlist_t ssignals struct idlist_t rsignals struct idlist_t slsignals struct idlist_t srsignals struct idlist_t Irsignals struct idlist_t sIrsignals struct idlist_t routes struct idlist_t marks struct idlist_t hwelasses struct idlist_t crossings struct idlist_t Abb
553. st ist wie die meisten anderen Listenstrukturen aufgebaut kommasenslist SENSID makeList SENSID kommasenslist makeList Als n chstes soll gezeigt werden wie der Conditions Block ausgewertet wird Das ge schieht wie sonst auch immer durch ein Schliisselwort gefolgt von einer Liste condblock CONDITIONS conddeflist Diese Liste wird auch wie blich ausgewertet conddeflist conddef makeCondClearListNode conddef conddeflist makeCondClearListNode Durch die Funktion makeCondClearListNode werden Condition Clearances Listen Ein tr ge zu einer Liste zusammengef gt Diese Funktion erh lt als Eingaben den einen Condition Clearances List Eintrag und die bereits vorhandene Condition Clearances Liste und verkn pft diese dann Zu conddef wird dann folgenderma en ausgewertet conddef ROUTEID condition kommaconditionlistopt makeCondClearList KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 161 Diese besteht also aus dem Bezeichner fiir die Route gefolgt von mindestens einer Con dition Mehrere Conditions werden genauso wie im zuvorkommenden Block erm glicht Bleibt nur noch zu nennen wie man zu condition reduziert condition POINTID direction makeCondClear Diese besteht aus einem Bezeichner f r eine Weiche und deren entsprechnde Richtung f r die Route Die Richtung ist hierbei aber ein Nichtterminal zu dem auch erst reduziert werden mu Dies ge
554. st_eintrag_angefordert Queue hat_Queue TRUE naechste_queue Route abarbeiten bearbeiten hat_konflikt FALSE zu_ende_der_qpl aus_queue_loeschen handle_uebersprungene_queues ink_bahn_counter_von_route Rst_eintrag_aktiv hat_konflikt TRUE amp amp uebersprungene_queues lt anz_queues setze_Rst_eintrag_angefordert Abbildung 7 42 Route Dispatcher Transitionssystem zu_ende_der_gpl setzt den jeweiligen Request an das Ende der Queue Priority List dekrementiere den Schleifenz hler handle_uebersprungene_queues inkrementiert den uebersprungene_queues Z hler wenn es sich nicht um die erste Queue handelt ansonsten setze den Z hler auf 0 naechste_queue gehe zur in der QPL folgenden Queue ber also inkrementiere den Schleifenz hler naechste_route gehe zur n chsten Route ber also inkrementiere den Schleifenz hler an_den_anfang_der_qp1l gehe an den Anfang der QPL also Schleifenz hler auf 0 setzen Andreas Kemnade 7 5 4 5 Route Controller In Abbildung 7 43 wird der RC in einem Statechart dargestellt Im folgenden werden jeweils die Eingangsdaten und die Ausgangsdaten und die einzelnen Funktionen beschrie ben Der Route Controller ist daf r zust ndig auf Anforderung vom Route Dispatcher f r eine Route die Weichen und Signale zu schalten und zu berpr fen ob sie geschaltet wurden und die Route wieder zu sperren wenn keine Bahnen mehr einfahren sollen 7
555. steht das Wort conditions welches den Block identifiziert Der gesamte Block von beliebig vielen Einfahrtsbedingungen wird mit geschweiften Klam mern umrahmt Jede Einfahrtsbedingung f ngt mit dem Namen der Route an auf den ein Doppelpunkt folgt Anschlie end werden alle Einfahrtsbedingungen getrennt durch KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 74 Kommata angegeben Jede Einfahrtsbedingungsbeschreibung einer einzelnen Route en det mit einem Semikolon Eine Einfahrtsbedingung besteht aus dem Weichenbezeichner und der geforderten Weichenstellung Allgemein m gliche Weichenstellungen sind left right und straight Der CondBlock beinhaltet im Prinzip die Information der Request Condition also der Einfahrtsbedingungen fiir die einzelnen Routen Es werden die Weichen angegeben ber die die Route f hrt und die Stellungen der Weichen die diese haben m ssen damit die Bahn die geforderte Route befahren kann Beispiel conditions routel wi straight route4 w4 straight routed w1 right route6 w4 right Dieses sind die Einfahrtsbedingungen des oben genannten Beispieles in Abbildung 7 1 auf Seite 63 Die Route route1 und die Route routed trennen sich folglich bei Weiche w1 7 1 3 2 11 ClearBlock lt clearblock gt lt CLEARANCES gt lt cleardef gt lt cleardef gt lt ROUTEID gt lt clearance gt lt clearance gt lt clearance gt lt SIGID gt lt direction gt Vor dem ClearBloc
556. stenz der Verschluss i tabellen gegen Netzgraph beide konsistent Rot Komponente oder Pfad wird als korrekt angenommen Dicke Elipse Wiederverwendbares Produkt Normal Elipse Nicht wiederverwendbare Daten Abbildung 6 3 Validierung der TND Routenbeschreibung Deng Zhou Ruben Rothaupt 6 4 Validierung der TND Hardwarebeschreibung Die TND Hardwarebeschreibung enth lt die Beschreibungen der vom Kunden erhalteten Hardware Dass die TND Hardwarebeschreibung tats chlich mit der vom Kunden gelieferten Hard warebeschreibung bereinstimmt wird durch einen manuellen Vergleich gepr ft Beide KAPITEL 6 VALIDIERUNGS VERIFIKATIONS UND TESTPROZESS 55 Beschreibungen werden in Form einer Review Methode durchgesehen um sicherzustel len dass sie sich nicht widersprechen Entwicklungsschritt Verifikationsschritt CAD Converter TND Builder Hardwarespezifikation von Kunden Transformation HW Spezifikation in TND TND HW Beschreibung 1 4 Manueller Vergleich gegeneinander beide identisch Rot Komponente oder Pfad wird als korrekt angenommen Dicke Elipse Wiederverwendbares Produkt Normal Elipse Nicht wiederverwendbare Daten Abbildung 6 4 Validierung der TND Hardwarebeschreibung Deng Zhou Ruben Rothaupt 6 5 Verifikation der Projektierungsdaten Es muss berpr ft werden ob die Projektierungsdaten eine sichere Steuerung
557. ster Gleisnetze Der Steuerinterpreter SI des Projektes TRACS wird aus den Informationen ber das Gleisnetz welche in Form einer Tram Network Description TND vorliegen generiert KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 315 Damit der Simulator die gleiche Menge an Gleisnetzen beherrscht und damit die Funk tionsweise des SI in allen F llen darstellen sowie m glichst vielseitig testen kann muss auch er die Gleisnetze in TND Form einlesen k nnen Dazu muss er folgende Bl cke der TND einlesen und interpretieren k nnen Definitions Block Dieser Block enth lt die Informationen welche Hardwareelemente im Gleisnetz vorhanden sind welchen Namen ID sie haben und von welchem Typ sie sind Coordinates Block Unabdingbar f r eine sinnvolle Darstellung des Gleisnetzes sind die Informationen ber die Standorte der Hardwareelemente jegliche Bewegung der Stra enbahnen ben tigt die Informationen ber Ortskoordinaten und Entfernungen im Gleisnetz Signal Properties Block In diesem Block sind funktionale Eigenschaften der im Gleisnetz vorkommenden Signale aufgef hrt Point Properties Block In diesem Block sind funktionale Eigenschaften der im Gleisnetz vorkommenden Weichen aufgef hrt Slipswitches Block Hier werden diejenigen Kreuzungen und Weichen genannt die zusammen Kreu zungsweichen slipswitches bilden Relations Block Wie die Weichen Kreuzungen und Sensoren miteinander verbunden sind bzw zwischen welchen El
558. stimmung der in clearances Block und conditions Block enthaltenen Angaben iiberpriift werden Das Signal s3013 befindet sich im Beispielgleisnetz direkt an der spitzen Seite der Weiche wi018 Wenn das Signal nun einer Bahn die Fahrt in eine bestimmte Richtung erlaubt dann muss w1018 ebenfalls in die entsprechende Richtung gestellt sein no_signal_point_contradiction s3013 state STOP gt s3013 state wi018 state amp s3015 state STOP gt s3015 state w1020 state amp s3014 state STOP gt s3014 state w1022 state SPEC AG no_signal_point_contradiction Ruben Rothaupt Taffou Happi 7 6 7 Reflexion Am Anfang des Projektes wurde vorgegeben dass mit Model Checking Techniken ber pr ft werden soll ob die Projektierungsdaten eine sichere Steuerung des jeweiligen Gleis netzes erm glichen Zu diesem Zweck wurde die Model Checking Gruppe gegr ndet Da die Projektierungsdaten gleisnetzspezifisch sind m ssen sie f r jedes zu steuernde Gleisnetz neu berpr ft werden was automatisiert werden soll Das endg ltige Pro gramm ist in der Lage festzustellen ob alle notwendigen Sicherheitsbedingungen erf llt sind Somit ist das Ziel der Gruppe erreicht worden Um dieses Ziel zu erreichen waren unterschiedliche Arbeitsschritte notwendig die im Folgenden beschrieben werden sollen Zudem sollen die Probleme betrachtet werden die bei der Realisierung des Ziels aufgetaucht sind KAPITEL 7 BESCHREIBUNG DER KOMPONENTE
559. strukturen mit nicht benutzten Bytes damit die Adres sen im Speicher bestimmten Forderungen von Teilbarkeit durch eine ganze Zahl erf llen Parser Ein Parser nimmt erkannte Token von einem Lexer entgegen und berpr ft die Abfolge der Token darauf ob sie der Grammatik des Parsers entsprechen Point Position Table Beschreibt die Stellungen von Weichen die n tig sind um eine Route befahren zu k nnen Projektierungsdaten Eingabedaten f r den Steuerinterpreter die in einem Bin rfor mat vorliegen Sie werden vom Compiler aus der DSL generiert Real Time Test Language Die Real Time Test Language RTTL ist eine durch Verified entwickelte formale Spezifikationssprache die f r die Beschreibung des Verhal tens von Parallelprozessen unter Echtzeitbedingungen entworfen wurde Route Eine Route ist ein bestimmter Weg durch ein Gleisnetz definiert ber die Ab folge der Sensoren die der Zug beim Befahren der Route passiert Route Conflict Table Enth lt die harten und weichen Konflikte zwischen den Rou ten Siehe auch Konflikt hart und Konflikt weich Route Definition Table Definiert die Reihenfolge der Sensoren und die Eintrittsbe dingungen f r jede Strecke RT Tester Das RT Tester System RealTime Tester ist zur Durchf hrung automa ANHANG F GLOSSAR 484 tischer Hardware in the Loop Tests und Software Komponententests von eingebetteten Echtzeit Systemen entworfen worden Dokumentation Ver04 RTTL s Real Time
560. t 6 start next round Abbildung 7 79 Pseudo Code f r realit tsnahe Rundenbasiertheit enth lt es wird allerdings davon ausgegangen dass die w hrend einer Simulation an der Systemuhr gemessenen Zeit der realen Zeit entspricht Diese Voraussetzung wird von der verwendeten Hardware s S 371 erf llt 7 8 4 8 3 Minimierung der Rechenzeit Ein Ziel der Simulation muss sein die Bahnen in realit tsnahen Geschwindigkeiten fahren zu lassen Die Geschwindigkeit der KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 371 Bahnen l sst sich ber die Anzahl der Schritte die sie pro Runde f hrt manipulieren die Distanz pro Schritt ist konstant die Dauer einer Runde wie oben gezeigt auch Sichergestellt werden muss also dass alle im Netz befindlichen Bahnen eine solche Zahl Schritte in einer Runde schaffen Einige hierf r unterst tzende Ma nahmen sind e Vermeidung von Berechnungen f r die Visualisierung e Vermeidung von Suchen in Mengen e Vermeidung von Schreib und Leseoperation e Vermeidung von blockierenden Aufrufen Zuerst einmal liegt bei der Form der Visualisierung keine Priorit t Die Fakten der Simu lation sollen pr sentiert werden jedwede Sch nheit der Simulation ist ein Bonus der nicht auf Kosten der Genauigkeit der Simulation gehen soll Allgemein ist die Ausgabe von Daten auf dem Bildschirm eine zeitaufw ndige Sache egal ob es sich dabei um reinen Text oder Grafik handelt Eine Sch tzung wie viel Rechen
561. t G nzlich aufgegeben wurden jedoch eine Besch ftigung mit Hardware sowohl mit zu steuernder Hardware wie auch mit der des Steuersystems der Themenbereich Fail Stop und der Einsatz von Echtzeitbetriebssystemen f r das Steuersystem Eine erfolgreichere Arbeit wurde durch diverse Faktoren gehemmt oder gar verhindert Diese Faktoren sollen im Folgenden beschrieben werden 9 2 6 1 Probleme 9 2 6 1 1 Arbeitshaltung Gelegentlich entstand der Eindruck dass sich das Inter esse von Teilnehmern vor allem auf das eigene Themengebiet innerhalb des Projektes konzentrierte Dies u erte sich z B darin dass in Plenumssitzungen nicht mitdiskutiert wurde falls es um fremde Themen ging oder dass die Protokolle nicht gelesen wurden Einige Teilnehmer wiesen auch eine betr chtliche Fehlquote auf Bei einigen Teilnehmern machte sich sehr schnell eine Art von Unlust breit So gab es bereits nach den ersten zwei Wochen das Problem dass ein Teilnehmer einer Referats gruppe keinerlei Beitrag leistete nicht zu Terminen erschien und somit mehr oder we niger aus dem Projekt entfernt wurde Zwei weitere Teilnehmer verlie en dann im Lauf des ersten Semesters freiwillig das Pro jekt Auch im weiteren Verlauf zeigte sich besonders im zweiten Semester dass einige Teilneh mer den Anforderungen wohl nicht gewachsen zu sein schienen da mehr und mehr die Mitarbeit ausblieb und auch bei leichten Dingen Verst ndnisprobleme auftraten Diese Teilneh
562. t usw Bei einem der Wartezust nde runder Punkt wird zus tzlich durch den Buchstaben S L oder R angegeben welcher Wartezustand es ist Die bis zu drei RR Anzeigen wer den durch Buchstaben unter dem Signal L S R angezeigt wenn sie aktiv sind Die Richtung aus der ein Signal zu sehen ist ist gekennzeichnet in dem die Hin tergrundfarbe des quadratischen K stchens und die des auf das Signal zuf hrenden Gleises identsch ist und von der normalen Gleisfarbe schwarz abweicht e Weitere Informationen Jedes Hardware Element kann angeklickt werden es ffnet sich dann ein Fenster mit Informationen zu diesem Element 7 8 4 6 Treiber zur Anbindung an den SI Der gesamte Kommunikationsvorgang zwischen Steuerinterpreter und Simulator stellt sich in folgenden Schritten dar Der Steuerinterpreter kommuniziert mit den Hardware Treibern ber ein Shared Memory und die Treiber ihrerseits kommunizieren mit dem KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 363 Memory Steuerinterpreter Hardware Treiber Simulator Abbildung 7 77 Kommunikation zwischen Steuerinterpreter Treibern und Simulator Simulator ber Netzwerk Das Netzwerk ist dabei das Mittel der Wahl da die Systeme Steuerinterpreter und Simulator nicht gleichzeitig auf demselben Rechner sondern auf verschiedenen Rechnern laufen Grund hierf r ist dass der Steuerinterpreter m glichst unbehelligt von anderen Systemen laufen k nnen soll Vorgesehen ist dass auf diesem Netzwerk die
563. t weil diese Klasse auch als eigenst ndiges Programm ausgef hrt werden kann neben dem eigentlichen Aufruf durch das Hauptprogramm TracsDXF2ND java Seite 102 Das detaillierte Klassendiagramm Abb 7 7 zeigt die in dieser Klasse verwendeten Me thoden und Attribute ConfigReader DXF_SEPERATOR_CONFIG final static String ng Separator conf dxfSeparatorConfig static String inFile String entityTags String blockTags String readConfig toolNo int boolean seperator boolean readError boolean DXFSeparator ENTITIES_FILE_NAME final static string entities tmp tng BLOCKS_FILE_NAME final static string blocks tmp tng DXF_FILE_EXT final static String dxf extractSections type int srcFile File void main args String void Abbildung 7 7 Detailansicht Klassendiagramm DXFSeparator und ConfigReader Im Wesentlichen gibt es hier neben der Main Methode nur eine Methode extractSecti ons welche den Vorgang der Extrahierung ausf hrt KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 94 Dieser erste Teil des DXF TND Konverters wurde gegen Ende des 2 Projektsemesters weitestgehend fertiggestellt und seitdem nur marginalen Anderungen unterworfen Die wesentlichen Tests wurden am Anfang des dritten Projekt Semesters durchgefiihrt und nach erfolgtem Bugfixing funktionierte diese Klasse wie gew nscht Im Anhang sie he B 3 1 auf Seite 465 befindet sich eine gek rzte DXF Beispiel Datei mit Ergebn
564. t drei Phasen e Modell Es wird durch Abstraktion ein formales Modell des Systems erstellt Das Modell muss in Form eines endlichen Transitionssystems beschrieben werden e Formeln Es werden durch Formalisierung Eigenschaften aus einer Spezifikation abgeleitet Diese Eigenschaften k nnen in einer temporalen Logik spezifiziert werden Mit temporalen Logiken lassen sich zeitliche Zusammenh nge ausdr cken e Model Checker Es existieren verschiedene Tools die die Verifikation mit Model Checking Techni ken unterstiitzen Das in der verwendeten Sprache des Model Checkers modellierte System und die in dem entsprechenden Formalsimus spezifizierten Eigenschaften bilden die Eingabe fiir den Model Checker der automatisch priift ob die jeweiligen Eigenschaften erf llt sind Ist eine Eigenschaft verletzt wird h ufig ein Gegenbei spiel erzeugt Durch die R ckgabe eines expliziten Gegenbeispiels k nnen m gliche Fehlerkorrekturen vereinfacht werden 7 6 1 2 Gliederung Zun chst wird im Abschnitt 7 6 2 auf der n chsten Seite das Konzept zur Verifikation der Projektierungsdaten erl utert Dann wird im Abschnitt 7 6 3 auf Seite 207 der ver wendete Model Checker NuSMV vorgestellt Wie das System modelliert wird und wie die Sicherheitsbedingungen spezifiziert werden wird im Abschnitt 7 6 4 auf Seite 213 be schrieben Der Abschnitt 7 6 5 auf Seite 233 besch ftigt sich damit wie die Eingabedatei KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 20
565. t s S 338 Alle anderen Elemente werden in der Runde nicht beachtet Eine komplette Runde ist in folgende Abschnitte unterteilt e Abfrage der Inputs vom SI KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 369 Eventuelle von den Hardwaretreibern geschickte neue Anweisungen vom SI wer den abgefragt e Verarbeitung der Inputs Die erhaltenen Anweisungen werden an die einzelnen Signale und Weichen weiter gegeben e Hardware Elemente schalten Alle HW Elemente werden aktualisiert d h solche bei denen eine Schaltung f llig ist schalten um Es erfolgen die n tigen R ckmel dungen an die Treiber e Bahnen fortbewegen Dies ist der Hauptschritt Die Bahnen fahren berfahrene Sensoren werden aus gel st von der passiven Seite aus befahrene Weichen werden gestellt und eventuelle Zusammenst e von Stra enbahnen werden ermittelt e Ver nderungen des Systemzustands der Schnittstelle melden Die Zust nde von Sensoren und Weichen die bei der Bewegung der Bahnen ver ndert wurden werden an die Treiber gesendet TRAMWAY MAIN ROUTES 1 20 G21 NORTH SOUTH 3 21 G23 SOUTH NORTH TRAM MAINTENANCE SITE Abbildung 7 78 Beispielgrafik eines Gleisnetzes KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 370 7 8 4 8 2 Echtzeit vs simulierte Zeit F r eine m glichst pr zise Simulation eines Echtzeitsystems muss die reale Zeit das ist die Zeit die f r den Anwender des Simulators vergeht mit der als vergangen berechn
566. t sind f r die Handhabung von Objekten zust ndig welche von NGDataCollec tor erzeugt und von TNDCreator ausgelesen und weiterverabeitet werden Daher sind s mtliche Methoden als protected innerhalb des Paketes ffentlich und die Attribute KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 93 als private nicht ffentlich markiert Die Pfeile zeigen welche Klasse von welcher anderen Klasse aufgerufen instanziiert wird Pfeil von A nach B Klasse A greift auf Klasse B zu 7 2 3 2 4 DXFSeparator java Die Grundiiberlegung f r diesen Konverter war es vor jeglicher weitergehenden Verarbeitung der DXF Datei erst einmal die relevanten Informationen aus dieser Datei herauszufiltern und den Rest auszusortieren um ein ge wisses Debugging zu erm glichen bzw zu vereinfachen Dazu wurde eine Klasse DXF Separator java implementiert welche die DXF Datei komplett Zeile f r Zeile einliest und dabei die weiter oben beschriebenen Sektionen ENTITIES und BLOCKS aus liest und in separate Dateien abspeichert blocks tmp tng und entities tmp tng Dabei werden au erdem alle f r uns irrelevanten Informationen verworfen Die Codes f r re levante Informationen sind in einer externen Konfigurationsdatei definiert welche mit Hilfe einer Hilfsklasse ConfigReader java Seite 94 eingelesen wird Die Realisierung ber zwei getrennte tempor re Dateien wurde auch bis zum Ende bei behalten da so auch f r den Endnutzer eine gewisse Debugging M glichkeit besteh
567. t werden 7 2 4 3 2 Nutzung der TRACS Objekt Bibliothek Das Haupt Programm Fen ster von QCad Abbildung 7 16 auf der n chsten Seite beinhaltet ein gr eres Unter fenster in dem die Zeichnung angefertigt wird sowie in der Standard Einstellung auf der linken Seite eine Werkzeugleiste Abbildung 7 17 auf der n chsten Seite Auf der rechten Seite ist unter anderem der Bibliotheks Browser zu sehen Im Bibliotheks Browser von QCad siehe auch Abbildung 7 18 auf Seite 109 sind nun KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 108 w l QCad Unbenanntes Dokument 1 ETETA Datei Bearbeiten Ansicht Selektion Zeichnen Bemassung Modifizieren Fang Info Layer Block Fenster Hilfe EEA r SEE r3 BESS e ADDI ZIRAAAAK Nach Layer x Nach Layer I Nach Layer Bblothek Browser X Block Liste x e 4 Verzeichnisse ab ia G others 8 2 te a 4 points Ten a A sensors Tk i A ii A signals track tracs EDIT oa ala at O Einf gen o TM m S L 2 g Eingabe A525 3 22 0 Selektierte Otjekte A Abbildung 7 16 QCad Hauptfenster die einzelnen Gleisnetzelement Zeichnungen ausw hlbar und k nnen nach Auswahl und Klick auf Einf gen in der Zeichnung an beliebiger Stelle per Mausklick plaziert werden a 7 A Get rd ETEO EDIT mm 4 4 Sk Abbildung 7 17 QCad Werkzeugleiste K
568. tList pointClass static NGElementList slipswitchClass static NGElementList crossingClass static NGElementList markClass static NGElementList main args String void loadBlocks srcFile File static void loadEntities srcFile File static void searchForAdditionalProperties textField String static int generateElementList static void sortElements static void rotateCoords xCoord double yCoord double dxfAngle double static String sideRecognition coords String type String static char calculateCoords static void findDirectNeighbours static void findLineNeighbours static void findNeighbours static void showElementList static boolean collectData blk String ent String static boolean Abbildung 7 8 Detailansicht Klassendiagramm NGDataCollector Teilzeichnungen Bl cke selbst zerlegt und daraus die Zusammenh nge herausgefil tert werden nicht vollkommen bedacht Dazu kam noch dass bei der Neuberechnung zwangsl ufig einige Rundungsfehler auftraten und diese erst beseitigt werden mussten Die Daten werden nach Tests mit DXF Zeichnungen kleinerer Testgleisnetze ordnungs gem ausgelesen sofern die Gleisnetzzeichung den im Handbuch 7 2 3 4 auf Seite 104 beschriebenen Regeln entspricht und der Zeichner keine Fehler produziert hat Zeichen fehler sind aber kaum abfangbar da die QCAD Software nicht von TRACS geliefert wird die Eingabe oder vielmehr das Ab
569. tches also Kreuzungsweichen in der sta bilen Version nicht unterst tzt werden da diese Funktionalit t nicht mehr ausreichend getestet werden konnte In der Test Version ist die Funktion aber mit Einschr nkungen vorhanden siehe dazu auch Abschnitt 7 2 3 2 13 auf Seite 103 7 2 3 2 7 NGElement java Zum Erzeugen der zuvor beschriebenen Objekte wird eine weitere Hilfsklasse NGElement java benutzt In einem solchen NGElement Objekt werden alle f r ein Gleisnetzelement relevanten Daten abgespeichert Name Typ Koor dinaten Nachbar Elemente sowie weitere Informationen um das Element im Gesamt kontext genau zu spezifizieren Diese Objekte werden sowohl f r Elemente Entities als auch ganze Bl cke aus der KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 97 DXF Datei genutzt aber auch als Java Objekt f r die sp ter in die TND zu schrei benden Gleisnetzelemente selbst Diese Klasse ist sozusagen eine Art Universalklasse Die Ansicht des Klassendiagramms Abb 7 11 auf Seite 99 zeigt die in dieser Klasse verwendeten Methoden und Attribute elementList ArrayList elementListIndex int 0 elementName ArrayList addElementToList element NGElement void modifyElement idx int element NGElement voi readElementListEntry index int NGElement getElementCounter int Abbildung 7 9 Detailansicht Klassendiagramm NGElementList Die Anzahl der Attribute und Methoden ist logischerweise recht gro da f r jeden er
570. te definitions route conflicts point positions und signal settings Die Informationen aus den Verschlusstabellen sind Bestandteil der TND k nnen aber nicht aus dem Netzgraphen gewonnen werden und m ssen daher anderweitig in die TND eingef gt werden siehe dazu Kapitel 7 3 auf Seite 123 Das selbe gilt f r die Definition von Hardware Klassen Der Netzgraph zeigt als Zeichnung wie die Gleisnetze mit ihren Steuerelementen aussehen er kann aber auch in einem Dateiformat DXF gespeichert werden welches als Text lesbar ist Der Netzgraph wird ben tigt um eine Repr sentation des kompletten physisch vorhan denen Gleisnetzes zu erhalten da dieses nicht zwangsl ufig aus den Verschlusstabellen hervorgeht In unserer L sungsidee war es nun die Aufgabe ein physikalisches Gleis netz mittels eines CAD Programmes in ein Dateiformat aufzunehmen und diese Datei wiederum in unsere TND Darstellung umzuwandeln Zur Validierung dieser Konvertie rung wird die TND Netzgraphbeschreibung mit Hilfe des Simulators Abschnitt 7 8 auf Seite 313 visualisiert Tritt ein Unterschied zum realen Gleisnetz auf so ist die Kon vertierung fehlerhaft Der so entstandene CAD TND Konverter ist der anspruchsvollste und komplexeste Be standteil der Eingabetools f r Gleisnetze im Projekt TRACS da nur er die M glichkeit hat ein grafisch dargestelltes Gleisnetz in die ben tigte TND Darstellung umzuwandeln berarbeitet von Henrik R hrup 7 2 2
571. te einer Produktionsregel mit der linken Seite zu reduzieren bzw durch das Symbol auf der linken Seite dieser Produktion zu ersetzen Genauer gesagt handelt es sich bei dem Parser um einen LALR1 Parser Diese Bezeichnung setzt sich folgenderma en zusammen Das LA steht f r lookahead also da der Parser voprausschauend arbeitet Das n chste L steht daf r da der Parser die Eingabe von links nach rechts abarbeitet Das R steht daf r da eine Rechtsableitung KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 149 route struct symtab_entry_t senslist struct idlist_t requestat struct idlist_t next struct route_t 5 entry struct symtab_entry_t next struct idlist_t Abbildung 7 36 struct route_t in umgekehrter Reihenfolge gebildet wird und die 1 steht daf r da ein Eingabesymbol im voraus betrachtet wird Zur genaueren Arbeitsweise eines solchen Parsers finden sich in ASU99 genauere Informationen 7 4 4 2 Syntaxbaum In diesem Abschnitt soll die Funktionsweise des Parsers genauer beschrieben werden Hierbei soll auf die Grammatikregeln und auf die vorhandenen Auswertungsregeln ein gegangen werden die letztendlich die Symboltabelle und den Syntaxbaum erstellen die zur weiteren Erzeugung der Projektierungsdaten unabdingbar sind Die Grammatik des tram Compilers entspricht ziemlich der aus der TND hierzu wurde nur eine Transfor mation von der EBNF Form zu einer BNF Form durchgef hrt
572. te vor der zu pr fenden Bahn in dieser Runde bereits von dem HW Element fortbewegt worden sein ein Zusammensto ist es aber dennoch da die Bewegungen aller Bahnen in einer Runde ja gleichzeitig sein sollen Nun der Quellcode von drivelnto 01 private boolean driveInto ArrayList trams TrackElement newHElement int newHPos Die Methode erwartet als Parameter trams eine Liste aller Trams im Gleisnetz das neue TrackElement das der Kopf der Tram bef hrt newHElement und die Position auf dem neuen Gleisst ck newHPos Der R ckgabewert sagt aus ob die Tram auf eine andere Tram auffahren w rde checkHeadCollision erwartet nur die Liste aller Stra enbahnen als Parameter Das TrackElement und die Position sind die aktuellen Werte der Tram Denn drivelnto wird vor dem Bewegen der Tram aufgerufen und die Tram dann nicht bewegt falls ein Auffahren stattfinden w rde und checkHeadCollision danach 02 Tram tram 03 for int i 0 i lt trams size i 04 tram Tram trams get i 05 if trams i equals this Als Erstes wird die Liste aller Trams durchgegangen und bei jedem Eintrag wird gepr ft ob es sich nicht um die Tram selbst handelt 04 if tram getTailElement newHElement amp amp 05 tram getTailPos newHPos 06 logger info Tram id must stop to prevent head to end collision while missingSteps pending 07 this isMoving false 08 m
573. te zwischen zwei Ele menten oder einem Element und einer Linie einfaches Gleisst ck gibt Diese m ssen genau bereinanderliegen da sonst keine Nachbarschaftsbeziehungen erkannt werden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 110 k nnen was aber fiir die sp tere Konvertierung in das TND Format zwingend notwen dig ist Dateiformat Als Dateiformat beim Speichern ist DXF zu w hlen Hierbei ist es irrelevant welche Version dieses Formats gew hlt wird 7 2 4 3 4 Zeichnen eines Gleisnetzes Beim Zeichnen eines Gleisnetzes ist darauf zu achten dass sich alle Elemente mit ihren Nachbarn in jeweils einem Punkt ber hren m ssen sog Ber hrungspunkte Diese Ber hrungen d rfen nicht an beliebiger Stelle eines Elements stattfinden sondern m ssen exakt an den Enden erfolgen Es darf au erdem kein Ende eines Elements frei bleiben d h dass es keine offenen Enden geben darf Ein und Ausfahrten eines Gleisnetzes m ssen dann ggf mit einer entsprechenden Markierung versehen werden damit das Gleisnetz korrekt ist Linienz ge also mehrere Linien in Folge ohne weitere Elemente dazwischen als Verbin dung zweier Elemente sind auch nicht gestattet stattdessen muss immer eine einzelne Linie zwei Elemente oder ein Element und eine Markierung verbinden Ein Gleisnetz muss immer mindestens einen Eingang und mindestens einen Ausgang haben welche durch entsprechende Markierungssymbole definiert sind Diese Symbole bilden den Abschluss eines G
574. ten m ssen damit keine Kollisionen auftreten safel sri amp sr2 amp sr3 e sri enth lt alle Sicherheitsbedingungen die eingehalten werden m ssen damit keine Bahnen aus unterschiedlichen Richtungen auf dieselbe Kreuzung zufahren so dass es zu einem Flankenzusammensto kommen kann e sr2 enth lt alle Sicherheitsbedingungen die eingehalten werden m ssen damit keine Bahnen aus unterschiedlichen Richtungen auf dieselbe Weiche zufahren so dass es zu einem Flankenzusammensto kommen kann e sr3 beinhaltet alle Sicherheitsbedingungen die eingehalten werden m ssen damit keine Bahnen in entgegengesetzter Fahrtrichtung aufeinander zufahren so dass es zu einem Frontalzusammensto kommen kann Diese drei Bedingungen beinhalten wiederum die Sicherheitsbedingungen der jeweiligen Kategorie die f r das jeweilige Gleisnetz gelten m ssen Die Sicherheitsbedingungen sind schon aus Abschnitt 7 6 4 7 auf Seite 228 bekannt Der einzige Unterschied besteht darin dass hier keine Sensorz hler verwendet werden sondern nur gepr ft wird ob bestimmte Sensoren bereits erreicht wurden KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 250 sri sri_1 amp sri_2 amp sri_3 sri_1 g4125 reached amp w1018 state STRAIGHT amp w1022 state LEFT amp g4129 reached sri_2 g4125 reached amp w1018 state STRAIGHT amp w1020 state STRAIGHT amp g4127 reached sr1_3 g4129 reached amp w1022 state LEFT amp w1020
575. tergegeben 3 Erzeugung der Klassenstruktur Der Best TramNetworkBuilderOfTheUNIverse bekommt die relevanten Informatio nen vom Parser und erzeugt instanziiert aus ihnen die Klassenstruktur auf der der Simulator letztendlich arbeiten kann 7 8 4 3 2 Pro und Kontra Compiler Konstruktions Werkzeuge Damit die Anforderungen aus Kapitel 7 8 2 1 auf Seite 314 erf llt werden k nnen muss eine Text KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 335 BestTramNetwork BuilderOffheUNIverse Informationen Informationen gt Klassenstruktur Informationen Zeichen t r _ Zeichen monim Parser Zeichen Grammatik I x J ZAIChRN Token gt A Information Zeichen Abbildung 7 63 Ablauf TND einlesen und verarbeiten datei deren Form in der TND festgehalten ist eingelesen werden k nnen Dieser Einle sevorgang ist kein trivialer Vorgang denn die Grammatik in der die Datei geschrieben ist ist kompliziert und damit auch nicht leicht zu berpr fen Des Weiteren m ssen Information zu ein und demselben Bauteil von verschiedenen Stellen parallel eingelesen und verarbeitet werden Dieser Einlesevorgang ben tigt demzufolge einen eigenen Compiler bzw bersetzter oder einen mit Hilfe von Compiler Konstruktions Werkzeugen Lexer und Parser Generatoren generierten Compiler Dieses Kapitel beantwortet die Frage warum die Arbeitsgruppe sich f r die Benutzung von Compiler Konstruktions Werkzeugen CKW entschiede
576. terschiede mehr Programmieraufwand Scanner mehr Einarbeitungsaufwand Einar und Parser miissen komplett von Hand beitung in die Spezifikationsdateien geschrieben werden und in die Benutzung der Generatoren theoretisch Optimierungsm glichkei geringere Fehleranf lligkeit durch ten durch individuellere Gestaltung strukturierte Generierung eingelese Grammatik nur schwer zu er eingelesene Grammatik anhand der kennen Spezifikation klar ersichtlich bei Anderungen an der einzulesenden Grammatik muss die Implementierung des Parsers ber nur die Spezifikation angepasst werden arbeitet werden keine Neuerfindung von bereits er i nur LL 1 Compiler mit angemessenem LALR 1 Compiler m glich m Gemeinsamkeiten Code Generierung muss manuell implementiert werden Tabelle 7 1 Vergleich pro und kontra Compiler Konstruktions Werkzeuge KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 337 matik Spezifikation als Grundlage fiir die Generierung benutzt wird und folglich klar erkennbar ist Bei Anderungen der zugrunde liegenden Grammatik ist es bei Benutzung von CKWs folglich ersichtlich ob die nderungen bereits eingef gt worden sind oder nicht Bei solchen nderungen muss bei einem selbst implementierten Compiler die Im plementierung angepasst werden w hrend bei einem generierten Compiler lediglich die Grammatik ge ndert werden und der Generierungsschritt neu ausgef hrt werden muss Ob mit oder ohne Compiler Generator der
577. tgenerator Da bei der Implementierung des Testgenerators im Prinzip genauso wie beim RD vorge gangen wurde soll dem Leser hier eine allzu gro e Darstellung erspart bleiben Es wird hier lediglich der Code Ausschnitt gezeigt der die fiir die einzelnen RC Instanzen re levanten Hardware Elemente aus den Projektierungsdaten gewinnt und in einer hierfiir angelegten Struktur speichert KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 289 rcinfo struct rc_info malloc sizeof struct rc_info pdata gt num_rc_data evaluate config data compute number of test cases set gen_xyz values to first test case for i 0 i lt pdata gt num_rc_data i single_total 25 printf RC Tan i rcinfo i num_sensors 2 rcinfo i sensor malloc sizeof int 2 rcinfo i sensor 0 pdata gt rc_datalil entry_sens_id rcinfoli sensor 1 pdata gt rc_data i exit_sens_id rcinfoli gen_sensor malloc sizeof int 2 rcinfo i gen_sensor 0 0 rcinfo i gen_sensor 1 0 printf Sensors d d n rcinfo i sensor 0 rcinfo i sensor 1 rcinfoli num_points pdata gt rc_datali num_point single_total pow 3 rcinfo i num_points rcinfoli point malloc sizeof int rcinfo i num_points rcinfoli gen_point malloc sizeof int rcinfo li num_points printf Points for j 0 j lt rcinfoli num_points j rcinfo i point j pdata gt rc_datal i point_pos j id rcinfo i gen_point
578. tionen und Einschr nkungen aufgestellt die f r die zu ber cksichtigende Umwelt KAPITEL 1 EINLEITUNG 7 und die zu steuernde Hardware gestellt werden miissen Zur Aufstellung dieser Weltmodelle wurden u a Experten der Bremer Stra enbahn AG und der Firma Hanning amp Kahl befragt 1 3 Problembeschreibung Ziel des Projekts TRACS war die Entwicklung eines wiederverwendbaren automatisier ten und damit Kosten sparenden Bahnsteuerungssystems sowie eines Verifikationspro zesses mit dem das System auf seine Sicherheit und Korrektheit berpr ft werden kann Das Steuerungssystem besteht dabei aus einem generischen Steuerinterpreter sowie den auf das jeweils zu steuernde Gleisnetz abgestimmten Hardwaretreibern und Projektie rungsdaten welche aus einer dom nenspezifischen Beschreibung des Gleisnetzes gene riert werden Der Verifikationsprozess benutzt Methoden des Model Checkings sowie ausf hrliche Soft und Hardware Tests um sowohl die Sicherheit der Ausgangsdaten als auch die Korrektheit des finalen Steuerungssystems zu gew hrleisten Ein Hauptziel des Projekts war dabei das System soweit wie m glich automatisiert und wiederverwendbar zu gestalten im Vergleich zu heutigen Systemen die weitgehend manuell entwickelt und gepr ft werden 1 4 Der L sungsansatz Der heute gebr uchlichen Ansatz zur Entwicklung von Gleisnetzsteuerungssystemen sieht in etwa so aus Aus den vorliegenden Daten eines Gleisnetzes wie Verschluss und Konfliktt
579. tionsweise und den benutzten Algorithmen der einzelnen Komponenten finden sich im n chsten Abschnitt 7 4 4 7 4 3 2 Parser Der tram Compiler benutzt einen automatisch generierten Parser um eine gegebene TND einzulesen Hierbei werden die Standard Compilerbau Werkzeuge flex und bison eingesetzt um einen Parser automatisch generieren zu k nnen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 141 Tracs Network Description ___ _ Dateisystem N Bin re Projektierungsdaten Zerlegung in Token Lexikalische Analyse Ausgabe in Datei N Funktionsbibilothek LS inc Aufbau Syntaxbaum _ ee rg Syntaktische Analyse Aufbau des Syntaxbaums Generierung aufrufen Aufbau der Symboltabelle Generierung der Projektierungsdaten Abbildung 7 29 Ubersicht tram Compiler Mithilfe des Werkzeugs flex wird zun chst ein Lexer zur Zerlegung der Eingabeda ten in einzelne Token generiert Hierbei entsteht die Komponente des Parsers die f r die lexikalische Analyse verantwortlich ist also Schl sselworte Elementbezeichner und Blockmarkierungen unterscheidet und diese als einzelne Token an die Parserkomponen te f r die syntaktische Analyse liefert Hierbei wird mithilfe des Parsergenerators bison automatisch ein Parser generiert welcher gem einer gegebenen Grammatik entschei det ob die vom Lexer gelieferten Token in einer grammatikalisch korrekten Reihenfolge geliefert wer
580. tisierung minimiert werden auch dadurch dass wiederverwendbare Bestandteile nur einmal verifiziert werden m ssen Im Wesentlichen m ssen nur die f r das jeweilige Gleisnetz spezifischen Daten jeweils eingegeben werden Ziel von TRACS ist es genau so eine automatische Generierung zu entwerfen Der dazu KAPITEL 3 PROBLEMBESCHREIBUNG 37 zu entwerfende Entwicklungs und Verifikationsprozess also wie das Steuersystem auto matisch generiert und verifiziert wird wird in den nachten beiden Kapiteln beschrieben Andreas Kemnade Kapitel 4 Der L sungsansatz 4 1 Architektur In diesem Abschnitt wird die Architektur des von TRACS entwickelten Gleisnetzsteue rungssystems beschrieben Die Abbildung 4 1 auf der n chsten Seite zeigt den heute gebr uchlichen Ansatz zur Entwicklung von Gleisnetzsteuerungssystemen Wie schon in der Einleitung erw hnt Abschnitt 1 4 auf Seite 7 wird das Steuerungssystem weitgehend manuell anhand der vorliegenden Gleisnetzinformationen erstellt Dadurch ist f r jeden Controller ein eigener Entwicklungsprozess notwendig Das Projekt TRACS verfolgt einen neuen Ansatz Die Abbildung 4 2 auf Seite 40 zeigt die Architektur dieses Ansatzes In der Abbildung werden alle beteiligten Komponenten und die Beziehungen zwischen den einzelnen Komponenten dargestellt e CAD Daten Es wird eine graphische Darstellung des betreffenden Gleisnetzes am Computer erstellt Dies sind die sogenannten CAD Daten e Verschlusstabellen
581. tmodellen beginnen Im spateren Verlauf ergab sich dann noch ein Treffen mit der Firma Hanning amp Kahl Hierbei wurde erhofft eine Validierung unserer Weltmodelle zu erhalten Genaueres zu den Treffen folgt Waldemar Wockenfu 2 4 2 Bremer Stra enbahn AG 2 4 2 1 berblick Anlass zur Kontaktaufnahme mit der Bremer Stra enbahn AG Die seit Beginn des Projektes TRACS im Oktober 2003 zur Verf gung stehenden Infor mationen hatten sich teilweise als zu abstrakt und theoretisch erwiesen um ein prak tisches Verst ndnis f r die Thematik zu erm glichen Um einen praktischen Einblick ber aktuell eingesetzte Bahnsteuerungssysteme eines lokalen Nahverkehrdienstleisters der Bremer Stra enbahn AG BSAG zu erhalten erfolgte erstmals Mitte November auf Einzelinitiative hin Kontaktaufnahme mit dieser Aus diesen Gr nden erfolgte dir Gr ndung der Arbeitsgruppe BSAG um sich um den Kontakt zu der Bremer Stra en bahn AG zu k mmern Arbeitsziele Zun chst sollte ein Besuchstermin ausgehandelt werden und eine allgemeine Vorstel lung des Projektes TRACS erarbeitet und im Rahmen des Besuches vorgestellt werden Auch die Sammlung eines Fragenkatalogs geh rte hierzu Im Plenum vom 30 01 2004 wurde zus tzlich vereinbart dass jede Arbeitsgruppe DSL HW SW Integration Mo delchecking und Steuerinterpreter einen Kurzvortrag ber ihren Teilbereich erstellt von der AG BSAG in den Gesamtvortrag einarbeiten l sst und beim Besuch vortr gt B
582. tor Wie dies im einzelnen funktioniert ist im Abschnitt zuvor besachrieben worden Die Funktion struct projdata_t getProjData struct section_t syntree ist ein Wrapper f r die drei zuvor genannten Funktionen Sie ruft sie alle auf um die einzelnen Projektierungsdaten zu generieren und gibt sie dann gemainsam wieder KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 169 7 4 5 3 Ausgabedaten Als zweite externe Schnittstelle dienen die Projektierungsdaten Wie diese aussehen sollen und wie sie erzeugt werden ist bereits im Abschnitt 7 4 4 abgearbeitet worden Eine genauere Beschreibung der Projektierungsdaten findet sich im Kapitel iiber den Steuerinterpreter Waldemar Wockenfu 7 4 6 Systemvoraussetzungen Fiir den TRACS tram Compiler gelten folgende Systemvoraussetzungen e Linux Betriebssystem Getestet wurde SuSE Linux 9 0 Professional Standardbibliotheken lt stdio h gt lt stdlib h gt lt search h gt e Lexergenerator flex ab Version 2 5 4 e Parsergenerator bison ab Version 1 75 e Buildwerkzeug make ab Version 3 80 C Compiler Linker gcc ab Version 3 3 1 Helge L ding 7 4 7 Bedienung Der TRACS tram Compiler wird durch folgenden Aufruf gestartet tram lt EINGABEDATEI gt lt AUSGABEDATEI gt Helge L ding amp Waldemar Wockenfu KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 170 7 4 8 Reflexion In diesem Abschnitt soll wiedergegeben werden wie unsere Arbeit an dem tram Com piler verlief Hierbe
583. tprozeduren f r den Route Controller beschrieben Dieser Vorgang erfolgte in mehreren Etappen e Bestimmung einer sinnvollen Menge von Testf llen anhand der RC Spezifikation e Implementierung der Funktionalit t aus den Projektierungsdaten diese Testf lle f r das spezifische Gleisnetz zu erzeugen und sie in das SUT einzuspeisen Test generator e Implementierung der Funktionalit t aus einem Testdatensatz den vom SUT er warteten Output zu bestimmen Testorakel e Implementierung der Funktionalit t den vom SUT gelieferten Output mit dem des Testorakels zu vergleichen Testchecker 7 7 5 3 1 Bestimmung einer Menge von Testf llen Hierzu betrachten wir zun chst die Parameter der zu testenden Funktion int process_route int route int phase shm_state_t shadow struct rc_data_t rc_data int rst int bahn_counter int entry_sensor_counter KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 288 Es werden also tibergeben e die Routennummer e der Zustand in dem sich der betreffende RC vor Aufruf befindet e der aktuelle SHM Zustand e die zu diesem RC geh rigen Projektierungsdaten e die Route State Table e der Bahnz hler f r diese Route e der Eingangssensorzahler fiir diese Route F r die Routennummer bleibt nichts anderes brig als alle im Gleisnetz m glichen Routen zu verwenden Gleiches gilt f r den RC Zustand alle Phasen m ssen getestet werden Beim SHM Zustand k nnen dagegen wieder Einschr nkungen vorgenommen werde
584. tr gt g4128 ctr amp w1020 state RIGHT st5 g4125 ctr gt g4126 ctr amp wi018 state RIGHT amp s3014 state STOP amp g4129 ctr 0 amp g4127 ctr gt g4130 ctr amp w1020 state STRAIGHT st6 s3013 state STOP amp g4125 ctr 0 amp s3014 state STOP amp g4129 ctr 0 amp g4127 ctr gt g4130 ctr amp w1020 state STRAIGHT st7 s3013 state STOP amp g4125 ctr 0 amp g4129 ctr gt g4126 ctr amp w1022 state LEFT amp s3015 state STOP amp g4127 ctr 0 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN st8 st9 g4125 g4129 s3015 g4125 g4129 s3015 ctr gt ctr gt state g4126 g4130 STOP ctr gt g4128 ctr gt g4130 STOP state ctr amp w1018 ctr amp w1022 amp g4127 ctr ctr amp w1018 ctr amp w1022 state state 0 state state 232 RIGHT amp STRAIGHT amp STRAIGHT amp STRAIGHT amp amp g4127 ctr 0 st10 s3013 g4129 s3015 state STOP ctr gt g4130 STOP 0 amp state 0 amp g4125 ctr ctr amp w1022 amp g4127 ctr STRAIGHT amp state ctr amp wi018 amp g4129 ctr amp g4127 ctr stil g4125 RIGHT amp s3014 s3015 ctr gt g4126 STOP STOP state state 0 amp state st12 g4125 s3014 s3015 ctr amp w1018 amp g4129 ctr amp g4127 ctr gt g4128 STRAIGHT amp STOP STOP state state ctr st13 s3013 s3014
585. trings durch entsprechende Funktionsaufrufe einen Syntaxbaum und eine Symboltabelle erstellen Hierbei existiert f r jedes nicht triviale Nicht Terminal der Grammatik eine Funktion die f r das erkannte Nicht Terminal seine Entsprechung innerhalb des Syntaxbaums er stellt Die in tram y definierte Grammatik entspricht der in Abschnitt 7 1 angegebenen Grammatik der TRACS TND Allerdings ben tigt bison eine Grammatikdefinition in Form einer Backus Naur Form w hrend die TRACS TND in Form einer Erweiterten Backus Naur Form definiert wurde Eine entsprechende Transformation wurde vorge nommen Folgendes Beispiel zeigt eine Grammatikregel in der einer Weiche eine Richtung zuge ordnet wird Innerhalb der Auswertungsregel wird ein entsprechender Teilbaum des Syn taxbaumes angelegt und zur Weiterverarbeitung an ein h hergelegenes Nicht Terminal weitergegeben condition POINTID direction makeCondClear 1 2 3 Genauere Informationen zu den Werkzeugen flex und bison sowie Informationen zu Grammatikdefinitionen und Auswertungsregeln finden sich in ASU99 7 4 3 3 Symboltabelle Die Symboltabelle des tram Compilers enth lt als Eintr ge einzelne Gleisnetzelemen te in Form von Elementbezeichnern gem der eingelesenen TRACS TND sowie de ren zugeordnete Hardware Eigenschaften Diese Hardware Eigenschaften gehen aus den Properties Bl cken der TRACS TND hervor Die tram Symboltabelle wird durch die POSIX Standardfunktionen zum H
586. truct relation_t relations struct sigpos_t signalpositions struct route_t routes struct condclearlist_t conditions struct condclearlist_t clearances KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 151 route struct symtab_entry_t conflicts struct idlist_t next struct conflict_t entry struct symtab_entry_t next struct idlist_t Abbildung 7 38 struct conflict_t struct conflict_t conflicts struct conflict_t pointconflicts struct hwmap_t hwmap Als Regel die einen Block optional macht sei hier nur die fiir die point conflicts auf gef hrt da die anderen optionalen Bl cke exakt auf die selbe Weise optional gehalten werden ptconfblockopt ptconfblock empty 2 Diese Regel sagt nur aus da ein ptconfblock vorkommen kann und dann zu ptconf blockopt reduziert wird oder ansonsten ptconfblockopt leer ist Als n chstes folgen die Auswertungen der einzelnen Bl cke angefangen bei den defini tions defblock DEFINITIONS typedeflist Wenn das Schliisselwort Definitions gefolgt von einer in geschweiften Klammern stehen den typedeflist erkannt wird wird diese zum defblock reduziert Dazu mu zun chst aber erst einmal eine typedeflist erkannt werden Dies geschieht dann durch folgende Regel KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 152 structhwmapt class struct symtab_entry_t elements struct idlist_t next struct hwmap_t 6 entry
587. tung Go f r diese Richtung Wait f r diese Richtung Stop Wait ist also wie Gelb bei einer normalen Verkehrsampel zu verstehen Von allen Wait und Go Anzeigen eines Signals darf zu einem Zeitpunkt maximal eine aktiv sein Da ein Signal f r mehrere Richtungen vor einer Weiche steht und diese Weiche nur in eine Richtung gleichzeitig geschaltet sein kann macht alles andere auch keinen Sinn selbst wenn also auch andere Zust nde prinzipiell anzeigbar w ren darf das Steuersystem sie nicht erreichen Ist f r eine Richtung Wait oder Go angegeben bedeutet dies f r alle anderen Richtungen automatisch Stop Ein Signal kann optional au erdem ber mehrere Anzeigezust nde A verf gen Diese bedeuten Anforderung eingegangen und signalisieren dem Fahrer dass seine Rou tenanforderung im Steuersystem angekommen ist und umgesetzt werden wird Ein Zu stand A wird dabei parallel zu einem der brigen Zust nde Stop Go Wait einge nommen Die verschiedenen A Zust nde korrespondieren mit den Richtungen die das Signal freigeben kann ein Signal das Go right und Go left anzeigen kann k nnte entsprechend auch A right und A left haben um anzuzeigen welche Richtung an gefordert worden ist Physisch verf gt das Signal ber entsprechend viele A Leuchten die entsprechend ihrer Bedeutung left straight right nebeneinander angeordnet sind Es muss nicht f r jede Richtung die das Signal fre
588. tzen k nnen in eine Hardwareklasse gliedern Diese Informationen ordnen den Gleisnetzele menten die zu nutzenden Treiber zu Abbildung 7 39 zeigt die Struktur dieser Daten innerhalb des Syntaxbaumes KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 147 entry struct symtab_entry_t 0 1 struct relation_t elem1 struct elementid_side_t elem2 struct elementid_side_t marklist struct idlist_t next struct idlist_t een int 4 next struct relation_t 1 1 elem struct symtab_entry_t side_elem int Abbildung 7 34 struct relation 7 4 3 5 Projektierungsdaten Die zu generierenden bin ren Projektierungsdaten werden vom tram Compiler zun chst innerhalb des Speichers erzeugt Hierbei wird die selbe Speicherstruktur erzeigt wie sie vom TRACS Steuerinterpreter eingelesen und genutzt wird Allerdings werden Inline Pointer und Offsets erst zum Zeitpunkt des Schreibens der Projektierungsdaten in das Dateisystem errechnet Genauere Informationen zur Speicherstruktur der zu generierenden Projektierungsdaten eines TRACS Steuerinterpreters finden sich daher im entsprechenden Abschnitt 7 5 Helge L ding 7 4 4 Algorithmen In diesem Abschnitt soll nun das Vorgehen des tram Compilers bei der Erzeugung der Projektierungsdaten gezeigt werden Dabei wird jeder Verarbietungsschritt des tram Compilers vorgestellt und den einzelnen Komponenten des tram Compilers zugeordnet Als erstes wird d
589. tzt wurde Die Distribution spielt eine sekund re Rolle Wir hatten drei Distributionen Debian Gentoo SuSE im Einsatz und keine Probleme bei der Testerstellung und durchf hrung festgestellt Die Hardwareanforderungen an diesen Rechner sind nicht weiter bestimmt Auf Grund von Versp tungen bei der Bereitstellung des Systems und halbierter An zahl der Teilnehmer im Vergleich zum Anfang des Projektes war nur Software Test Durchf hrung m glich Zum Verlauf der Hardware Tests wird daher nur ein Vorschlag gemacht Die erste f r das Testen der TRACS Steuerungssoftware notwendige Aufgabe bestand darin eine solche Testumgebung aufzusetzen so dass erforderliche Tests in die Testumge bung integriert und dort ausgef hrt werden konnten Dazu musste zun chst das Betriebs system installiert werden War auf dem Testrechner ein entsprechendes Betriebssystem eingerichtet konnte der RT Tester installiert werden Die beiden Aufgaben bereiteten keine weiteren Probleme Um mit dem RT Tester verschiedene Testf lle auszuf hren und auswerten zu k nnen musste f r das TRACS Steuersystem ein Testprojekt erstellt werden in dem alle Tests f r die Steuerungssoftware logisch zusammengefasst wurden Im Testprojekt sind An gaben enthalten die alle auszuf hrenden Tests gemein haben also zum Beispiel Umge bungsvariablen und Pfadangaben der Testumgebung und des Testlings Marcin Dysarz 7 7 3 1 Verified s RT Tester In diesem Kapitel beschreibe
590. tzung der Gruppe aus dem ersten Semester war zudem niemand mehr in der Gruppe vertreten KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 118 7 2 5 4 Zeitnot durch Personalverluste Das Ergebnis ist folglich nicht das erwartete und s mtliche urspr nglich gemachten Zeit absch tzungen mussten somit auf eine Person umgerechnet werden was den Zeitrahmen g nzlich ins Wanken brachte Einzig die Absch tzung zur Einarbeitung in das CAD System von 8 16 MW konnte den Zeitraum von rund eineinhalb Monaten betrachtet halbwegs eingehalten werden Die effektiv ben tigte Zeit war dabei allerdings deutlich geringer als die gesch tzte was ja aber aufgrund der oben genannten Probleme keinen wirklichen Gewinn darstellte und nach au en hin nicht auffiel Die zu Beginn gemachte Absch tzung des Arbeitsaufwandes von 60 MW f r den CAD TND Konverter w re vermutlich realistisch gewesen wenn genannte gruppeninterne Probleme nicht aufgetreten w ren Da die Netzgraphgruppe ab dem dritten Projekt Semester auch offiziell nur noch mit einer Person weitergearbeitet hat und somit eigent lich nicht mehr als Gruppe bezeichnet werden konnte musste die Gesamt Zeiteinsch t zung f r den Konverter zur Halbzeit des Projektes auf rund 80 MW angehoben werden da nur die Ideen einer Person als Basis vorhanden waren Mehrere Personen erg nzen sich in der Regel gegenseitig und es w rden sich entsprechend mehr Ideen f r L sungs ans tze ergeben Entsprechend zog sich d
591. u ert sich in fehlerhaften Nachbarschaftsbeziehungen Daher ist in dieser Version des Konverters leider dazu zu raten diese Beziehungen noch einmal anhand der Zeichung manuell zu berpr fen Interessanterweise ist durch L schen des betreffenden Blockes Element incl Benen nung und erneutem Einf gen des Elementes Neubenennung desselben und Erzeugung eines neuen Blockes aus diesen beiden Teilen dann aber evtl unter einem anderen Namen als bei dem zuvor gel schten der Name ist f r die Weiterverarbeitung und Re pr sentation in der TND vollkommen irrelevant das Problem oftmals behebbar Diese Beobachtung l sst eher darauf schlie en dass die Speicherung einer umfangreicheren DXF Datei mittels QCad nicht ganz fehlerfrei zu sein scheint Was dabei genau passiert KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 117 ist aber leider nicht endg ltig kl rbar gewesen so dass durchaus auch ein kleiner Fehler innerhalb des Konverters die Ursache sein kann Leider kann es dabei auch passieren dass die Konvertierung als solches abbricht da intern eine Ausnahmesituation aufgetreten ist die die weitere Ausf hrung unm glich macht Die Ursache ist dieselbe hat nur aufgrund der internen Programmstruktur in gewissen Situationen eben diese Auswirkung Henrik R hrup 7 2 5 Reflexion 7 2 5 1 berblick In dem folgenen Abschnitt soll die Arbeit in der Netzgraphgruppe allgemein bewertet und die aufgetretenen Probleme aufgezeigt werden 7 2 5 2 B
592. uch im Wesent lichen eingehalten werden Die noch aufgetretenen leichten Abweichungen sind durch Einbindung des zu dem Zeitpunkt letzten verbliebenen Gruppenmitgliedes in andere Aktivit ten innerhalb des Projektes genannt seien Weltmodell und TND nderungen die zu den jeweiligen Zeitpunkten als wichtiger erschienen auch sinnvoll zu begr nden Ohne diese zus tzlichen Dinge h tte der Zeitplan vermutlich gehalten werden k nnen Nach dem dritten Projektsemester war der Simulator quasi fertiggestellt nur die Anbin dung an den SI konnte noch nicht getestet werden Dies und die Behebung der dabei entdeckten Fehler Problemstellen wurde nach Fertigstellung eines betriebsf higen SI im vierten Semester durchgef hrt ohne dass hierf r noch einmal ein Zeitplan aufgestellt wurde was aber auch nicht n tig erschien 7 8 8 1 2 Anforderungen erst w hrend der Implementierung aufgestellt Wir haben vers umt rechtzeitig die Anforderungen an den Simulator und damit auch den Sinn und Zweck im Rahmen des Projektes TRACS zu spezifizieren Dies hatte zur Folge dass wir vieles nachtr glich einbauen mussten und dass wir zum Teil auch Features implementiert haben die gar nicht notwendig gewesen w ren Eine vorherige Spezifikation der Anforderungen h tte uns die Arbeit folglich erleichtert da nachtr gli che nderungen immer mehr Zeit zum Einbau in Anspruch nehmen Das gesamte Projekt TRACS hat es verpasst sich um ein physikalisches Weltmodell was der
593. uch schon weiter mit der Automatisierung war Die Deutsche Bahn AG zu besuchen machte aufgrund der unter schiedlichen Verfahrensweisen keinen Sinn 2 4 3 Hanning amp Kahl 2 4 3 1 berblick W hrend der Suche nach Informationen ber Hardware Elemente die im Bereich Stra Benbahnsteuerung genutzt werden ist ein Mitglied der SI Gruppe auf die Homepage von H amp K gesto en Dies hat einen E Mail Verkehr ausgel st durch den uns wichtigen Informationen zugeschickt wurden und von unserer Seite hat die Firma H amp K Auskunft ber unser Projekt bekommen KAPITEL 2 DIE DOMANE 33 Nach einiger Zeit hat sich herausgestellt dass unser Projekt von Interesse fiir die Leute von H amp K ist so dass sie Kontakt mit unserem Lehrstuhl aufnehmen wollten Das ist auch passiert Als Ergebnis hat sich herausgestellt dass H amp K Interesse an unserem Projekt hat und gerne zum Besuch kommen wollte Ein Termin wurde vereinbart 2 4 3 2 Besuch von H amp K Am 9 Februar 2005 kam ein Treffen zwischen dem TRACS Projekt und H amp K zustande Das Treffen war in drei Teile gegliedert e Vortrag der AGBS e Vortrag von H amp K e Vortrag von TRACS 2 4 3 2 1 Vortrag der AGBS Prof Dr Jan Peleska als Leiter der AGBS stellt die Aufgaben der Forschungsgruppe Betriebsysteme Verteilte Systeme vor Die entsprechenden Folien befinden sich im Verzeichnis docs lectures h k und auf der TRACS Webseite 2 4 3 2 2 Vortrag von H amp K R diger Mesterheide Mitarb
594. uf Gruppenruf berfallruf und direkten Sprechfunk per Funkger t f r den Da tenfunk ist ein Zeitschlitz von 50ms vorgesehen 2 4 2 3 Reflexion Das Ergebnis des Besuches war zwiesp ltig Fest stand dass die Informationen nicht f r alle Gruppen ausreichend waren teilweise sogar dem Ansatz widersprachen Da die BSAG aber nicht der einzige Anbieter ist wurde der bisherige Ansatz weiterverfolgt und nach geeigneter Hardware gesucht Hier wurden uns von der BSAG die Firmen Siemens BBR und Hanning amp Kahl empfohlen Trotzdem hat es sich gelohnt einen Einblick in die Praxis zu bekommen Diese ist bislang aber noch sehr auf den Fahrer abgestimmt Er hat die volle Kontrolle ber die Bahn damit aber auch die volle Verantwortung Kein System verhindert das ein Fahrer nach links abbiegt und in eine entgegenkom mende Bahn f hrt Da er wie ein Kfz Fahrer der StVO unterliegt und auch mit anderen Verkehrsteilnehmern interagieren mu kann es keine vollkommen automatisierte Soft waresteuerung geben was auch nie unser Ziel war Den Fahrer von einem Teil seiner Arbeit zu entlasten und damit konzentrationsf higer f r andere Verkehrsteilnehmer zu machen war unsere Auslegung die der BSAG wohl eher dass der Fahrer verantwor tungsloser oder weniger konzentriert handelt So erschien die Kontaktaufnahme mit der Berliner Stra enbahn sinnvoll da die uns damals vorliegenden Informationen von Prof Dr Jan Peleska von dort stammten und diese Firma wohl a
595. ungsdaten Aus der TND und der Softwarespezifikation werden Testprozeduren f r die Steuerungs software entwickelt Daf r wird eine formale Spezifikation ben tigt die das zu testende Verhalten der Software beschreibt Dann wird getestet ob die Steuerungssoftware die KAPITEL 6 VALIDIERUNGS VERIFIKATIONS UND TESTPROZESS 57 Spezifikation auch tats chlich erf llt Der Testvorgang wird im Abschnitt 7 7 auf Sei te 255 beschrieben Entwicklungsschritt Verifikationsschritt C sofware D a P SI Spezifikation Testprozedurentwicklung Software testprozeduren Softwaretest gegen Softwarespezifikation gleicher Input f hrt zu gleichem Output Rot Komponente oder Pfad wird als korrekt angenommen Dicke Elipse Wiederverwendbares Produkt Normal Elipse Nicht wiederverwendbare Daten Abbildung 6 6 Softwaretest gegen Softwarespezifikation Deng Zhou Ruben Rothaupt 6 7 Test der Treiberbibliothek Die Treiber bernehmen die Rolle der Schnittstelle zwischen der Software und der Hard ware Es wird eine Bibliothek von allen gegebenen Treibern mit deren jeweiligen Beson derheiten definiert Das richtige Verhalten der Treiber wird durch Tests auf allen Integrationsebenen gepr ft Deng Zhou Ruben Rothaupt KAPITEL 6 VALIDIERUNGS VERIFIKATIONS UND TESTPROZESS 58 6 8 Test des fertigen Steuerungssystems Schlie lich muss noch das fertige Steuerungssystem getestet werden Dabei h
596. uppe seltener auch die Verwaltungsgruppen hier regelm ig Bericht ber ihre Arbeitsfortschritte erstatten Dar ber hinaus wurden wo es sich anbot bzw n tig erschien Vortr ge einzelner Teilnehmer oder von Kleingruppen gehalten Das Plenum wurde jeweils von einem Vertreter des aktuellen Projektmanagements mo deriert Das PM erstellte auch die jeweilige Tagesordnung Au erdem wurde von jedem Plenum ein Protokoll angefertigt die Pflicht zu protokollieren wechselte dabei reihum ber alle Projektteilnehmer 9 2 4 2 Projektwochenende Gegen Ende des ersten Semesters fand das einzige Projektwochenende des Projektes im Naturfreundehaus Nienburg statt Hier sollten m glichst viele Teilnehmer des Projektes sich ein Wochenende lang intensiver mit der Materie befassen als dies in gewohnter Umgebung m glich erschien Im Wesentlichen bestand dieses Wochenende aus mehreren Plena und dazwischen einge schobenen Kleingruppentreffen in denen an der konkreten Thematik gearbeitet wurde Dar ber hinaus sollte dieses Wochenende auch dem besseren Zusammenwachsen des Projektes dienen 9 2 4 3 TRACS Tag Unter dieser Bezeichnung lief ein Tag an dem ber das normale Plenum hinaus gemein sam gearbeitet wurde Er stellte im Prinzip eine Mischung zwischen normalem Plenum und vollem Projektwochenende dar 9 2 4 4 Besuch der Ausstellung Das Depot Im Vorfeld eines Besuches bei der BSAG fand auch ein Besuch in der Ausstellung Das D
597. us der Gleisnetzbeschreibung in der TND Der Compiler erzeugt aus Routen und Hardwarebeschreibung die Projektierungsdaten f r das jeweilige Gleisnetz Die Informationen welche zum Erstellen des Controller Mo dells ben tigt werden erh lt man aus den Projektierungsdaten und der Spezifikation des Systems TND Routebeschreibung TND Netzwerkbeschreibung TND Hardwarebeschreibung SI Projektierungsdaten ie Spezifikation y Y x Physikalisches Modell Controller Modell a gt Eingabedatei Model Checker Abbildung 7 45 Model Checking Entwurfsprozess Der Model Checker pr ft dann ob alle spezifizierten Eigenschaften erf llt sind Ruben Rothaupt Taffou Happi KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 207 7 6 3 NuSMV New Symbolic Model Verification Als Model Checker wird NuSMV eingesetzt NuSMV verwendet zur Erstellung seiner Eingabedatei eine eigene Eingabesprache deren Hauptfunktionalit ten vorgestellt wer den Zudem wird anhand eines Beispiels beschrieben wie ein modelliertes System ber pr ft werden kann Eine ausf hrliche Beschreibung von NuSMV ist in CCO zu finden 7 6 3 1 Eingabesprache Ein NuSMV Programm besteht aus einer beliebigen Anzahl von Modulen Das nach dem Schl sselwort MODULE folgende atom ist der Name des Moduls In Klammern k nnen einem Modul Parameter bergeben werden Das Modul mit dem Namen main ist ein spezielles Modul das keine Parameter haben darf Es dient als Evaluator f r den Nu
598. uss nehmen hier ist wieder der Fahrer gefragt Einen weiteren Einflu auf die Sicht des Fahrers sind die gegebenen Lichtverh ltnisse wobei der Fahrer zum Beispiel geblendet werden kann Desweiteren z hlen wir zum Umfeld auch gesperrte Teilgleisnetze da diese kurzfristig durch Unf lle oder Hindernisse gesperrt sein k nnen aber auch l ngerfristig durch z B Baustellen Hier sollte eine Umplanung der Routen m glich sein d h es muss m glich sein auf m glichst unkomplizierte Art neue Routen zu integrieren KAPITEL 2 DIE DOMANE 17 2 2 2 3 Verhalten Sowohl der Fahrer als auch die Passagiere und auch andere Verkehrsteilnehmer unterlie gen nat rlich der gesamten Spannbreite menschlichen Verhaltens und sind von unserem System nicht weiter beeinflussbar 2 2 2 4 Wettereinfliisse Das Wetter kann auch die sichere Fahrt der Bahn beeinflussen Zumeist passiert dies indem das Wetter einen der anderen zuvor beschriebenen Einfl sse ausl st Da gibt es zum einen den Wind der z B B ume zum Umst rzen bringen kann die dann die Gleise versperren oder gar die Stromleitungen abreissen Ein weiterer extremer Wettereinflu w ren da berschwemmungen die das Befahren des Gleisnetzes unm glich machen k nnen Extreme Temperaturen k nnen sich auch auf das Gleisnetz auswirken und zus tzlich auch noch dem Fahrer und den Passagieren zu schaffen machen was dann deren Ver halten beeinflussen kann Es gibt aber auch weniger extreme Wetterinf
599. utedefinitions Block e Point Position Table conditions Block e Signal Setting Table KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 240 clearances Block e Route Conflict Table conflicts Block point conflicts Block Diese f nf Bl cke m ssen also berpr ft werden Im routedefinitions Block wird f r jede Route definiert in welcher Reihenfolge welche Sensoren passiert werden sollen Der routedefinitions Block kann nun berpr ft werden indem alle m glichen Routen einzeln befahren werden Ein Fehler wird erkannt wenn die Sensoren nicht in der definierten Reihenfolge passiert werden Dies w rde bedeuten dass die jeweilige Route nicht so befahrbar ist wie sie definiert wurde Beim berpr fen des routedefinitions Blocks wird auch gleichzeitig berpr ft ob die im conditions Block enthaltenen Angaben richtig sind Der conditions Block enth lt die f r eine Route ben tigten Weichenstellungen W re dort eine Weichenstellung f r eine Route falsch definiert k nnte die betreffende Route ebenfalls nicht in der beabsichtigten Weise durchfahren werden Wenn alle Routendefinitionen als richtig erkannt werden dann wurde gezeigt dass im routedefinitions Block und im conditions Block keine Fehler enthalten sind Es soll gepr ft werden dass conditions Block und clearances Block keine Widerspr che enthalten Befindet sich ein Signal direkt an der spitzen Seite einer aktiven Weiche dann darf es nicht m glich sein dass si
600. verstehen e f r Sensoren ein Punkt der sich genau in der Mitte zwischen den beiden zu einem Gleis geh renden Schienenstr nge befindet in L ngsrichtung an der Stelle die eine Bahn erreichen muss um eine Ausl sung des Sensors zu bewirken e f r Weichen ebenfalls ein Punkt in der Mitte zwischen den zwei Schienenstr ngen in L ngsrichtung an der Stelle an der die Verzweigung beginnt bzw endet auf H he dieses Punktes wechseln die R der der Bahn das Gleis e f r Signale der Punkt an dem das Signal steht an dem der Signalmast aus dem Boden kommt handelt es sich um ein h ngendes Signal dann die Projektion des Signals auf den Boden e f r Kreuzungen der Mittelpunkt der Kreuzung e f r Markierungen ein Punkt in der Mitte zwischen den zwei Schienenstr ngen KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN Beispiel coordinates g100 5000 8500 0 g101 5000 8000 0 g102 5000 6000 0 g103 5000 4000 0 g104 5000 2000 0 g105 6000 6000 0 g200 8000 3200 0 g201 7000 3200 0 g202 4000 3200 0 g203 1000 3200 0 g300 3000 500 0 g301 3000 2000 0 g302 3000 4000 0 g303 3000 6000 0 g304 3000 8000 0 g400 0 4800 0 g401 500 4800 0 g402 2000 4800 0 g403 4000 4800 0 g404 6000 4800 0 g405 8000 4800 0 g406 2000 6000 0 w1 5000 7500 0 w2 3000 7500 0 w3 7000 4800 0 w4 1000 4800 0 s1 5200 8000 0
601. w 08 boolean sigExists 1 hasSignal te Anhand der Position und Fahrtrichtung der Tram wird das n chste Linkable Hardware Element gesucht und gepr ft ob dort ein Signal steht das f r die Richtung der Bahn zust ndig ist 09 if sigExists 10 int state 1 getSignal te getState 11 if state Signal POS_STOP 12 route isSignalPositionCorrect 13 l getSignal te state 14 if dir pos lt length 1 steps 15 pos gt steps getIsMoving 16 if mustStop iter 42 0 17 logger info Tram id 18 Wrong signal percepted in iter 19 iteration 20 mustStop iter 21 22 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 383 Ist dem so wird dessen Zustand gepriift steht es auf Stop oder in einer Stellung die zwar Fahrt erlaubt aber nicht der f r die Route der Bahn n tigen Richtung entspricht das wird mittels route isSignalPositionCorrect gepriift und ist die Tram ent weder noch weit genug vom Signal entfernt d h das Signal ist weiter entfernt als die minimale Vorausschau Weite oder steht die Tram gerade dann kann sie ein Signal in jedem Fall beachten so wird der Stop Zustand als erkannt gespeichert Dies geschieht in der Integer Variablen mustStop Diese ist als Bitmap codiert das nullte Bit steht hierbei f r das n chste Linkable Hardware Element das erste f r das darauf folgende usw Befindet sich am jeweiligen Linkable Element ein Signal d
602. w_to_test test_loop input_mask if input_mask_tmp amp 1 lt lt i int setze_bit i printf n setze_bit d d n setze_bit pow 2 setze_bit hw_to_test test_loop input pow 2 setze_bit break if hw_to_test test_loop output_size 0 if hw_to_test test_loop output_mask 0 tue nichts J else analog wie beim input F else KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 298 analog wie beim input I Mit diesen Abfragen wird festgestellt wie viele Bits im Input bzw Output Bereich gesetzt sind und was f r Bit Masken g ltig sind Wenn ein Bit in Input oder Output Bereich gesetzt ist dann wird es gel scht und die Schleife wird abgebrochen Wenn die Bit Masken so gesetzt sind dass kein Bit berhaupt betrachtet wird dann wird nichts gemacht Wenn die Bit Masken nicht Null sind und kein Bit in Input oder Output Bereich gesetzt ist dann wird das erste von der Bit Maske betrachtete Bit gesetzt und die Schleife wird abgebrochen Der so verletzte Zustand wird dann nachdem hw_to_test auf test_real und test_shadow abgebildet wurde dem Testling als n chster Testfall bergeben Danach wird hw_to_test wieder mittels copy_mem dem Original des sicheren Zustan des angeglichen und der Verf lschungsalgorithmus auf das n chsten HW Element in diesem Zustand angewandt Ist letztlich f r jedes HW Element eine Korrumpierung des sicheren Zustandes durch gef hrt worden beginnt der be
603. weitere Entwicklung des TND Builders KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 134 7 3 5 1 Verlauf in den einzelnen Semestern Mit der Arbeit am TND Builder wurde erst im vierten Projektsemester begonnen Der Grund daf r war dass ein graphisches Werkzeug f r Routendefinitionen entstehen sollte Bei der Entwicklung des TND Builders wurden teilweise Komponenten von anderen Gruppen bernommen um den Entwicklungsaufwand zu reduzieren z B der DXF2TND Konverter und der TND Parser Aufgrund von Anmerkung im Plenum wird im TND Builder auch die G ltigkeit der Routen gepr ft 7 3 5 2 Weitere Entwicklung des TND Builders Der TND Builder kann weiter entwickelt werden So k nnte er eine zentrale Rolle im Entwicklungsprozess spielen Der Benutzer k nnte im TND Builder den Compiler aufru fen um die Projektierungsdaten f r das jeweilige Gleisnetz zu erzeugen Danach k nnte durch Integration mit der generischen Steuerungssoftware und der Treiber Bibliothek die gesamte Steuerungssoftware generiert werden Das ist der einfachste und bequemste Weg ein Gleisnetz Steuerungssystem f r den Kunden zu generieren Deng Zhou KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 135 7 4 Compiler Der TRACS Compiler tram dient zur bersetzung von Gleisnetzinformationen in bin re Projektierungsdaten welche vom TRACS Steuerinterpreter eingelesen und benutzt wer den k nnen um ein entsprechendes Gleisnetz sicher zu steuern Da der Compiler dem TRACS Steuerinterpret
604. wenn die Weiche w1018 nach rechts gestellt ist Daher darf kein Zustand auftreten in dem die Z hler der Sensoren g4125 und g4129 gr er als 0 sind die Weiche w1022 nach links gestellt ist und die Weiche w1018 nach rechts gestellt ist Dies wird durch die Sicherheitsbedingung sr2_1 ausgedr ckt sr2 sr2_1 amp sr2_2 amp sr2_3 sr2_1 g4129 ctr gt 0 amp w1022 state LEFT amp w1018 state RIGHT amp g4125 ctr gt 0 KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 230 sr2_2 g4125 ctr gt O amp w1018 state STRAIGHT amp w1020 state RIGHT amp g4127 ctr gt 0 sr2_3 g4127 ctr gt 0 amp w1020 state STRAIGHT amp w1022 state STRAIGHT amp g4129 ctr gt 0 7 6 4 7 3 Dritte Sicherheitsbedingung Wenn eine Weiche von einem Sensor er reichbar ist und sich eine Bahn an dem Sensor befindet dann darf es nicht sein dass die Weiche nicht auffahrbar ist Eine aktive Weiche ist nicht auffahrbar wenn sie noch nicht gestellt wurde Au erdem kann es sein dass ein Befahren von einer nicht gestellten stumpfen Seite nicht m glich ist F r das Beispiel wird u a eine Bedingung erstellt dass wenn eine Bahn bereits den Sensor g4129 passiert hat oder der Sensor erreichbar ist sich die Weiche w1022 nicht mehr im Zustand UNDEFINED befinden darf sr3 sr3_1 amp sr3_2 amp sr3_3 sr3_1 g4129 ctr gt 0 g4129_cond_1 gt w1022 state UNDEFINED sr3_2 g4125 ctr gt 0 g4125_cond_1
605. werden soll werden die Vor und Nachteile beider Sprachen gegen ber gestellt die Schnittstellen zu anderen Arbeitsgruppen betrachtet und die pers nlichen Erfahrungen der Mitglieder der Arbeitsgruppe Simulator miteinbezogen 7 8 4 1 1 Vor und Nachteile von Java gegen ber C Jede Programmier sprache hat ihre Vorteile und Nachteile Anhand der wichtigsten Unterschiede zwischen den beiden Sprachen JavaTMund C soll untersucht werden welche Sprache sich in Hinsicht auf unseren Simulator besser eignet Java wurde auf der Grundlage der Sprachen C und C mit dem Ziel entwickelt die Vorteile beider Sprachen zu bernehmen und die Nachteile dieser Sprachen m glichst zu vermeiden Dadurch entstanden u a Unterschiede in der Speicherverwaltung Porta bilit t Grafikprogrammierung Rechenzeit und Vererbung Die genannten Unterschiede werden jetzt genauer untersucht e Vorteile von Java gegeniiber C Unter dem Gesichtspunkt einen Simulator mit grafischer Oberfl che zu program mieren bietet Java in den Bereichen Speicherverwaltung Portabilit t und Gra fikprogrammierung Vorteile gegen ber C Speicherverwaltung In C muss f r Datenstrukturen explizit Speicher reserviert und auch wie der freigegeben werden Dadurch treten besonders leicht Programmierfehler auf In JavaT muss man sich nicht darum k mmern bei der Erstellung eines Objekts wird automatisch gen gend Speicher zur Verf gung gestellt Au er dem muss man sic
606. wir die Anforderungen nicht bewerten Zusammenfassend l sst sich sagen dass sich in den meisten F llen hieraus klar kein Bedarf f r ein Hard Realtime System erkennen l sst da es sich nur um Komfortanfor derungen handelt die in etwa so kritisch sind wie die fl ssige Reaktion eines normalen Programms auf Maus oder Tastatureingaben Das bedeutet wenn es manchmal etwas l nger dauert dann ist das noch nicht schlimm es sollte eben nur nicht zu oft passieren Es ist fraglich ob f r die restlichen F lle spezielle Echtzeitsysteme erforderlich sind da der Steuerinterpreter sowieso nur so gut wie als einzigstes Programm auf dem Steuer rechner laufen soll Dieser Standpunkt kann sich jedoch ndern wenn die Treiber selbst harte Echtzeitanforderungen haben auf Grund der daran angeschlossenen Hardware Dieser Punkt konnte jedoch auf Grund fehlender Informationen ber reale Hardware nicht mehr abschlie end behandelt werden Andreas Kemnade Deng Zhou KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 202 7 5 6 Reflexion In diesem Abschnitt wird zun chst dargestellt was in den einzelnen Semestern erreicht wurde und dann erfolgt eine Zusammenstellung der wichtigsten Probleme 7 5 6 1 Verlauf in den einzelnen Semestern Im ersten Projektsemester erfolgte die Aneignung von einigem Grundlagenwissen und es erfolgten erste Experimente mit Shared Memory und Transitionssystemen teilwei se wurde das auch in Assembler implementiert Daneben wurde die Sh
607. wo die einzelnen Bereiche die jeweils verschiedene Langen haben k nnen beginnen struct offsets_t struct version_t version_offset struct rd_data_t rd_data_offset struct rc_data_t rc_data_offset struct sm_data_t sm_data_offset struct version_t int major time_t build struct projdata struct offsets_t offsets struct version_t version struct rd_data_t rd_data struct rc_data_t rc_datal struct sm_data_t sm_data Andreas Kemnade Marius Mauch KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 199 7 5 4 7 Hardwarekonfiguration F r die vollst ndige Beschreibung eines Gleisnetzes werden hardwarespezifische Infor mationen ben tigt um auf Ereignisse richtig reagieren zu k nnen So wird f r jedes Hardwareelement eine eindeutige am besten numerische ID sowie die zugeh rige Hard wareklasse ben tigt F r jede Hardwareklasse werden wiederum der Treibertyp die Treiberklasse sowie Hardwaredaten wie z B Reaktionszeiten die f r den Treiber oder den Steuerinterpreter wichtig sind angegeben Im Projekt wurden zwei Wege bearbei tet Zum einen eine L sung die aus zus tzlichen Textdateien dann die entsprechenden Header Dateien erzeugt Zum anderen eine L sung die nur die jeweiligen Simulator Treiber verwendet Die Vorteile der ersten L sung konnten nicht ausgenutzt werden da nur Simulator Treiber zur Verf gung standen Im folgenden werden beide Ans tze beschrieben 7 5 4 7 1 Flexible Auswahl der Treiber
608. ystem Dazu gesellte sich auch noch die Tatsache dass in neueren Versionen des DXF Formats zahlreiche Zusatzinformationen haupts chlich zur Formatierung einzelner Elemente Farbcodierungen Linientypen etc und weiterer nicht n her untersuchte Informa tionen vorkommen welche bei uns absolut keine Verwendung finden Die Menge an Informationen hat sich innerhalb weniger Versionsschritte vervielfacht so dass das ak tuelle DXF Format insgesamt letzlich etwas undurchschaubar und verworren anmutet Im Zuge der berarbeitungs Phase wurde auch versucht eine mehr oder weniger exakte DXF Grammatik aufzustellen was sich aber aufgrund der zuvor genannten Eigenschaf ten des DXF Formats und der hohen Anzahl an verschiedenen Versionen nicht gerade als einfach und eher als kaum realisierbar herausgestellt hat Daher ist die im Anhang dieses Berichts enthaltene DXF Grammatik siehe Anhang B 2 auf Seite 461 verein facht und beschr nkt sich nur auf die f r den Netzgraphen direkt relevanten Sektionen Wie erw hnt stellte sich ebenfalls im Laufe des dritten Projekt Semesters heraus dass von den insgesamt f r die grafische Darstellung relevanten Informationen der DXF Datei nur ein geringer Teil f r die interne Weiterverarbeitung relevant ist Koordinaten sowohl die des gesamten Elements als auch die der Ber hrungspunkte mit anderen Elementen und der Name eines Elements aus der erstellten DXF Bibliothek sowie ggf das eine oder andere Textfeld De
609. z aus der Gleisnetzspezifikation abgeleitet werden siehe auch Kapitel 4 3 2 auf Seite 43 TND Beschreibung Test Suite Compiler Projektierungsdaten Steuerungssoftware f I 1 I 1 I I I I I I I I 1 I l Abbildung 7 49 Projektierungsdaten Generierung und Verwendung System Wie man in Abbildung 7 49 sieht werden aus der TND Beschreibung automatisch mit Hilfe des Compilers die Projektierungsdaten f r die Steuerungssoftware generiert Diese sind auch als Ausgangs Konfigurationsdatei f r die Testprozeduren benutzt wor den Da alle f r die Steuerung relevanten Gleisnetzinformationen in dieser Datei vor handen sind m ssen diese Daten zwangsl ufig auch ausreichen das Steuerungssystem zu testen Anhand dieser Informationen und der Systemspezifikation wurden entsprechende Mo dule Testgenerator Testorakel Testchecker im Testvorgang vorbereitet und benutzt Hierbei stellt sich allerdings auch die Frage der Korrektheit der Projektierungsdaten Sind schon diese Projektierungsdaten fehlerhaft so kann ein Test keine sinnvollen Er gebnisse ber die Korrektheit der Software liefern Um die Testprozeduren ganz unabh ngig vom System zu machen sollte man einen se paraten Compiler programmieren der die Ausgangs Konfigurationsdatei aus der TND KAPITEL 7 BESCHREIBUNG DER KOMPONENTEN 257 Beschreibung erstellt Aufgrund einer nicht ausreichenden Anzahl von Projekttei
610. zu gew hrleisten Sie bestehen aus e Route Definition Table Definiert die Routen die die Bahnen durch das Netz zur cklegen sollen ber die Reihenfolge der zu berfahrenden Sensoren e Conflict Table Identifiziert die Konflikte zwischen Routen Dabei unterscheidet man zwischen point conflicts schlie en sich durch unterschiedliche Weichenstel lungen aus und conflicts anderweitige Ausschl sse e Point Position Table Definiert die Positionen der Weichen die f r die jeweilige Route n tig sind e Signal Setting Table Enth lt die entsprechende Richtungsangabe des Ein gangssignals der Route um die Einfahrt freizugeben Die Verschlusstabellen beinhalten also diejenigen Informationen die ein Steuerungssys tem ben tigt um zu wissen welche Routen es gibt welche Weichen und Signalstellun gen f r welche Route geschaltet werden m ssen und um zu entscheiden welche Route wann freigegeben werden kann 7 1 2 3 Hardware Beschreibung Die im Gleisnetz vorkommenden Hardware Elemente m ssen bez glich ihrer Funktio nalit t n her beschrieben werden um die Steueraufgabe ausf hren zu k nnen Ben tigt werden die folgenden Informationen e fiir Weichen Richtungen die die Weiche schalten kann e fiir Weichen Zeit die nach einer Schaltanforderung maximal vergehen darf bis die Schaltung erfolgt ist e f r Weichen zus tzliche Eigenschaften wie aktiv passiv R ckfallweiche ja nein und in welche Richtung auffahrbar

Download Pdf Manuals

Related Search

Related Contents

  Tennant 5700 Japanese Operator Manual  安全データシート  Panasonic KX-PRS110  Porsche Driver`s Selection  受入施設等運用マニュアル - かながわ福祉情報コミュニティ    crédits : Patrick Roy  Sistema de Ósmosis Inversa HY-3032  South Shore Furniture 3359213 Instructions / Assembly  

Copyright © All rights reserved. Failed to retrieve file