ERTMS Driver Interface Simulering. Produktrapport

Transkript

1 ERTMS Driver Interface Simulering Produktrapport

2 FORORD Denne rapporten inneholder produktrapport gjort i forbindelse med Hovedprosjekt i Bachelorstudium i informasjonsteknologi ved Høgskolen i Oslo, våren Den beskriver den tekniske oppbygningen til programmet. Rapporten er beregnet for sensor, veileder og oppdragsgiver, men kan også leses av andre som skulle finne den interessant. Rapporten vil være nyttig for den som eventuelt skal utvikle programmet videre. Det forutsettes at leseren har kjennskap til programmering og utvikling. For å forstå det som beskrives i rapporten og oppbyggingen av programmet trengs det i tillegg til kunnskap om JAVA også kompetanse innen prinsipper for 3D-programmering generelt og JAVA 3D spesielt. Denne rapporten sammen med kildekodens kommentarer og resulterende JAVADOC utgjør den totale dokumentasjonen av programmets oppbygging og virkemåte. 2

3 INNHOLD Forord... 2 Innhold Innstallasjon for utvikling Programmets 3D-del Innledning d-verdenen Elementer i 3d-verdenen Programmets oppstartsforløp Innledning Innlesing og kalkulering av data Main-metoden Les inn trase Les inn spor Koble noder Les inn infrastruktur og omgivelser Les inn scenario Sett inn noder Rekalkuler etter spor Rekalkuler etter trasè Resulterende Elementorganisatorobjekt Opprettelse av togobjekt og tilhørende vinduer Opprettelse av øvrige vinduer TrafikkstyringFrame Univers3d

4 3.5 Programmets struktur etter oppstart Systemets sammensetning og virkemåte ved bruk Innledning Sammensetning av programmet Overordnet sammensetning Univers3d Trafikkstyring Tog Kommunikasjon ERMTS-systemet Informasjonspunktene Innhenting av informasjon ERTMS overvåking og status ErtmsPunkt-klassen ErtmsPunktSet-klassen ErtmsSystem-klassen og DMI Oppdater DMI-oppbygging DMI-oppdatering Togets forflyttning langs sporet i 3d-verdenen Innledning Beregning av togets pos (antall meter kjørt fra strekningens start) Beregning av togets punkt i 3d-verdenen XML-filene Innledning

5 7.2 Trase.xml TraseVertikal.xml Spor.xml Infra.xml Omg.xml Scenario.xml MilkshapeTraseTransform Ordforklaringer Referanser

6 1 INNSTALLASJON FOR UTVIKLING For å endre eller videreutvikle programmet foreslås å opprette programmet som et prosjekt i Eclipse (1). Java og Java3D må være installert på maskinen på forhånd. Java kan lastes ned fra: (2) Java3D kan lastets ned fra: (3) Eclipse kan lastes ned fra Kopier mappen ERTMSDIS fra vedlagte CD eller webside til ønsket plassering (workspace) på maskinen. Start Eclipse og trykk på J-symbolet for å opprette et prosjekt. Velg Create Project from existing source og finn fram ERTMSDIS mappen ved hjelp av browse. Se Figur 1. Trykk finish. Figur 1: Opprette prosjekt av programmet 6

7 2 PROGRAMMETS 3D-DEL 2.1 INNLEDNING 3D delen av programmet skal vise infrastruktur og omgivelser i ett uavhengig vindu. Denne delen er programmert i Java3D. Dette er en samling med klasser som er relevante for 3D programmering. For å ha fullt utbytte av den følgende beskrivelsen av 3d delen i dette programmet bør man ha en del forhåndskunnskap om 3d-programmering generelt og JAVA3D spesielt. Dette dokumentet er ikke ment som noen innføring i 3d programmeringens prinsipper og konsepter. For dette henvises til bøker og nettsteder som har dette som tema. I dette dokumentet presenteres hvordan 3d verdenen bygges opp og hvordan programmet henger sammen. 7

8 2.2 3D-VERDENEN 3d-verdenen er et begrep det jevnlig refereres til i teksten. 3d-verdenen er et koordinatsystem med 3 akser, 3 dimensjoner. I prinsippet kan man si at X- aksen er sideveis, Y-aksen opp/ned og Z-aksen er lengderetningen. Dersom man står i origo og ser langs den positive Z-aksen, vil positiv X være utover mot venstre og negativ X utover mot høyre i dette programmet. Positiv Y er oppover og negativ Y er nedover. Figur 2: 3D verden Et 3d objekt består av 2 eller flere punkter. Et objekt bygges og plasseres ut i rommet ved å angi punktenes koordinater. I Java3d representeres et punkt av klassen Point3d. Point3d double x double y double z Figur 3: Point3d-klassen 8

9 2.3 ELEMENTER I 3D-VERDENEN Elementer i 3d-verdenen er synlige objekter som kan plasseres ut i 3d-verdenen i en 3dposisjon. Dette angis med X, Y og Z verdier. X, Y og Z oppgis i meter i dette programmet. Alle elementer i dette programmet som skal være synlige i 3d-verdenen representeres av subklasser av interfacet UniversElement. Dette skaper et hierarki av elementer som har mer eller mindre til felles med hverandre. Programmet kan forholdsvis enkelt utvides med flere elementer ved å opprette nye klasser og henge seg på i hierarkiet på hensiktsmessig plass. <<interface>> UniversElement ArrayList<Node> noder() AbstraktElement AbstraktSpor RettSpor Material Kurve Material Sporveksel Material ErtmsHast ErtmsStopp Figur 4: Elementer i 3D-verdenen Som Figur 4 viser, vil alle klasser i dette hierarkiet ha metoden ArrayList<Node> noder(). Klassen Node (4) er en abstrakt klasse i Java3D som representerer et synlig element i 3dverdenen. Objekter av Node-klasser kan addes til Java3D sin trestruktur (scenegraph) for alle synlige objekter. 9

10 3 PROGRAMMETS OPPSTARTSFORLØP 3.1 INNLEDNING Her følger, i kronologisk rekkefølge, en beskrivelse av det som skjer når programmet starter fram til nødvendige datastrukturer er satt opp, vinduer vises og programmet er oppe og går. 3.2 INNLESING OG KALKULERING AV DATA MAIN-METODEN Programmets main-metode er i klassen Program i pakken med samme navn. Main-metoden oppretter et objekt av Univers3d-klassen. Konstruktøren i Univers3d-klassen står nå for resten oppstartsforløpet. Det første som skjer er at et objekt av ElementOrganisator-klassen blir opprettet. Konstruktøren i denne klassen utfører en rekke innlesings- og kalkuleringsoperasjoner. Alle elementer og objekter leses inn fra XML-filer og plasseres i datastrukturer. For beskrivelse av XML-filene og konfigurering av disse henvises til kapittel 7. Figur 5: Trase bestående av rette og kurvede segmenter 10

11 3.2.2 LES INN TRASE Trasèen leses fra XML-filen trase.xml. En trase er en sammenhengende linje normalt bestående av rette segmenter og kurvede segmenter i 3 dimensjoner (se Figur 5). Dette kan sammenlignes med en vei eller en jernbane gjennom et landskap. Vi kan tenke oss posisjonsverdier langs trasèen som avstanden i meter fra starten av trasèen. Begrepet pos eller posisjon benyttes om denne endimensjonale verdien i teksten og i programmet. Hver posisjon langs en trasè vil ha en koordinat (et punkt) i 3d verdenen. Begrepet punkt, koordinat eller 3d-posisjon benyttes et punkt i 3d-verdenen. En trase i dette programmet er representert gjennom klassen Trase. Denne klassen har blant annet metoden finn3dpunktipos(double pos). Denne metoden returnerer 3d-punktet som ligger ved angitt posisjon (antall meter fra starten av trasèen). En trasè blir plassert i listen over trasèer: ArrayList<Trase> traseliste i klassen ElementOrganisator. Programmet er forberedt for å kunne håndtere mer enn en trasè, men i denne versjonen forholder vi oss til kun en trasè. Klassen Trase inneholder datastrukturer (lister) over de spor-, infrastruktur- og omgivelseselementer som skal være synlige og funksjonelle langs trasèen. Trase public Point3d finn3dpunktipos(double pos) Figur 6: Trase-klassen 11

12 3.2.3 LES INN SPOR Spornettet leses fra XML-filen spor.xml og legges inn i ArrayList<AbstraktSpor> sporliste i klassen Trase Ett punkt langs ett spor har en posisjon. Dette er en double-verdi som representerer antall meter fra starten av sporet. Dersom flere spor går parallelt nummereres disse med indeks fra 0 og oppover. 0 er sporet lengst til høyre dersom man ser oppover positiv Z-akse. Figur 7: Spor med indeks 0 og 1 Sporene legges i utgangspunktet ut langs Z-aksen. Et sporavsnitt er et objekt av klassen RettSporMaterial Figur 8: To parallelle spor (objekter av RettSporMaterial) langs Z aksen RettSporMaterial Point3d startpunkt Point3d sluttpunkt Figur 9: RettSporMaterial-klassen 12

13 3.2.4 KOBLE NODER SNode-objektene i enden av hvert sporelement kobles sammen med neste- og forrigepekere. Dette må gjøres for at toget skal kunne forflytte seg fra et sporelement til det neste. Det muliggjør også informasjonsflyt gjennom hele spornettet. Nestepekeren i enden av en spordel peker på noden i enden av neste tilstøtende spordel. Forrigepekeren i enden av en spordel peker på noden i enden av forrige tilstøtende spordel. Merk at disse nodene er objekter av klassen SNode og må ikke forveksles med Java3D sin Node-klasse og objekter av denne. Se kapitelet for togets forflyttning for beskrivelse av SNode-klassen. Figur 10: Sammenkobling av noder 13

14 3.2.5 LES INN INFRASTRUKTUR OG OMGIVELSER Infrastruktur og omgivelser leses fra XML-filene infra.xml og omg.xml og legges inn i ArrayList<UniversElement> elementliste i klassen Trase Infrastruktur- og omgivelsesklasser er subklasser av UniversElement interfacet. Dette sikrer at de har en liste over Java3d noder (objekter som er synlige i 3d verdenen). Alle disse nodene er tilgjengelige gjennom allenoder() metoden i ElementOrganisator-klassen når alt er lest inn. <<interface>> UniversElement ArrayList<Node> noder() Figur 11: UniversElement, superinterfacet til alle infrastruktur og omgivelsesklasser Infrastruktur- og omgivelsesklasser kan velge å implementere TraseAvhengigElementinterfacet, SporAvhengigElement-interfacet eller ingen av disse. Se avsnittene og for mer informasjon om sporavhengighet og traseavhengighet. <<interface>> TraseAvhengigElement void rekalkettertrase(trase t) <<interface>> SporAvhengigElement void rekalketterspor(trase t) Figur 12: Alle sporavhengige elementer er også traseavhengige 14

15 3.2.6 LES INN SCENARIO Videre leses scenarioet fra XML-fil. Scenario er startverdiene til programmet. Dette innbefatter følgende parametere: Togets posisjon, hastighet og sammensetning Kameraets posisjon, retning og tilknytning til tog Simulert tid (klokkeslett) Innleste tog lagres i ArrayList<Tog> togliste i Elementorganisator-klassen. Programmet er forberedt for å kunne håndtere flere enn ett tog. I denne versjonen brukes bare ett. Kameraet er representert som et objekt av klassen Kamera. Kameraet har eget datafelt i ElementOrganisator-klassen. Tid er representert som et objekt av GregorianCalendar (standard Java-klasse). Tid har også eget datafelt i ElementOrganisator-klassen SETT INN NODER Klasser som representerer infrastrukturelementer kan implementere SNodeElementinterfacet. Dette gjelder f. eks ErtmsStopp-klassen. Alle SNodeElement-objekter vil blir iterert gjennom og få muligheten til å plassere sitt SNode-objekt inn i den lenkede listen av SNode-objekter som strekker seg gjennom spornettet. <<interface>> SNodeElement void settinnsnode(trase t) ErtmsStopp Figur 13: ErtmsStopp er et SNodeElement og vil ha sin SNode i den lenkete listen 15

16 3.2.8 REKALKULER ETTER SPOR Elementer som implementerer sporavhengighet oppgir sin 3d posisjon i forhold til ett angitt spor og i forhold til en avstand langs dette sporet. Den oppgitte Z verdien tolkes som avstanden langs sporet, mens X og Y verdien blir addert til sporets 3d-posisjon i den angitte Z verdien. Denne nye posisjonen kalkuleres. Figur 14: Skilt med sporavhengighet før og etter rekalkulering På Figur 14 er et eksempel der et skilt har oppgitt posisjon 2.5, 0, 1150 og spornummer 1. Skiltet plasseres i utgangspunkt på denne posisjonen i 3d-verdenen. Skiltet implementerer SporAvhengigElement-interfacet og blir rekalkulert til posisjon 7.5, 0, 1150 fordi spornummer 1 ligger parallelt langs z-aksen med x-verdi 5. Skiltet får nå sin korrekte 3dposisjon i forhold til sporet. 16

17 3.2.9 REKALKULER ETTER TRASÈ Alle elementer som implementerer traseavhengighet kalkuleres i nå forhold til trasèen. Et SporAvhengigElement er også et TraseAvhengigElement (se Figur 12). Sporet selv er traseavhengig. Figur 15: Et skilt med sporavhengighet er også traseavhengig På Figur 15 fortsetter eksempelet fra Figur 14. Vi tenker oss en trase som i starten følger Z- aksen og deretter bøyer av mot venstre. Skiltet som i Figur 14 ble flyttet i forhold til sporet blir nå også justert i forhold til trasèen. Sporet selv er traseavhengig og følger trasèen. 17

18 RESULTERENDE ELEMENTORGANISATOROBJEKT Når ElementOrganisator-objektet er konstruert, er all data lest inn, evt. rekalkulert og plassert i datastrukturer (lister). Disse dataene er nå tilgjengelig gjennom tilgangsmetoder i ElementOrganisator-objektet. ElementOrganisator ArrayList<Tog> gettogliste ArrayList<Trase> gettraseliste Kamera getkamera ArrayList<Node> allenoder() ArrayList<Node> getstartnoder(int traseindex) ArrayList<TransformGroup> allelokvognfigurer() Figur 16: Tilgangsmetoder i ElementOrganisator 18

19 3.3 OPPRETTELSE AV TOGOBJEKT OG TILHØRENDE VINDUER Et tog representeres av klassen Tog. Tog-objektet opprettes av ElementOrganisator-klassen når togets data leses fra XML-fil. Figur 17 viser at når et Tog-objekt opprettes vil også et ErtmsSystem med en DMIFrame opprettes. DMIFrame er vinduet som inneholder ERTMS-skjermen (DMI). Et Tog har også en TogKontroll og en KontrollFrame. KontrollFrame er vinduet der toget kjøres (kontrolleres) fra. Tog ErtmsSystem DMIFrame 1 1 JFrame 1 TogKontroll 1 KontrollFrame Figur 17: Et Tog-objekt har to vinduer, DMIFrame og KontrollFrame 19

20 3.4 OPPRETTELSE AV ØVRIGE VINDUER TRAFIKKSTYRINGFRAME Vinduet for trafikkstyring blir nå opprettet. Alle SNode-objekter i starten av trasèen (startnoder) og toglisten blir hentet fra ElementOrganisator og sendt med i TrafikkStyringFrame sin konstruktør og lagret som datafelter i TrafikkstyringFrame. Strekningen som er laget til dette programmet har enkeltspor ved starten av trasèen. Den vil da bare ha en startnode. Ved å starte i denne kan hele spornettet traverseres og man vil underveis treffe på de SNodene som er tilknyttet infrastrukturelementer langs sporet som f.eks ErtmsStopp- og ErtmsHast-objekter. Ved å tegne en strek fra SNode-objekt til SNodeobjekt og legge til de symboler som er tilknyttet infrastrukturobjektene vil vi få en grafisk visning av spornettet med de ulike elementer lagt inn. Det er SNoden s posisjon før traserekalkulering som benyttes. Resultatet blir da en visning med rette streker og ikke streker som følger trasèens kurver. Symbol fra toget Symbol fra ErtmsStopp Symbol fra Sporveksel Material Streker mellom SNodene Symbol fra ErtmsHast Figur 18: Vindu for trafikkstyring De infrastrukturobjektene som skal tegnes må implementere SporPlanElement-interfacet. Disse vil da ha en JComponent sporplancomponent-metode der et symbol som representerer elementet returneres fra. Tog-objektet hentes fra toglisten. Det har også et slikt symbol og vises grafisk i trafikkstyringsvinduet i korrekt posisjon. JFrame TrafikkstyringFrame TogListe togliste ArrayList<SNode> startnoder Figur 19: TrafikkstyringFrame 20

21 3.4.2 UNIVERS3D Til slutt opprettes Univers3d-vinduet. Dette er vinduet som viser spor, annen infrastruktur og omgivelser som er plassert i 3d-verdenen. Det normale er å sette kameraet mot denne verdenen i fronten av toget med retning framover. Vinduet vil da vise det lokføreren ser ut av sitt frontvindu av infrastruktur og omgivelser. Kameraet kan imidlertid plasseres hvor man vil i 3d-verdenen i den retning man ønsker. Det kan også plasseres hvor som helst i forhold til toget. Dette justeres i XML-filen scenario.xml. Innholdet i Univers3d-vinduet programmeres ved hjelp av klassene i Java3D. JFrame JPanel ViewPlatformBehavior (Java3d klasse) Univers3d UniversPanel SimpleUniverse su (Java3D-klasse) FrameBehavior Kamera kamera TogListe togliste Figur 20:Oppbygging av Univers3d, vinduet mot 3d-verdenen Alle Java3D noder (synlige objekter i 3d verdenen) blir hentet fra ElementOrganisatorobjektet og sendt inn i UniversPanelet. Her blir de lagt inn i Java3D sin scenegraph. En scenegraph er en trestruktur, vanlig brukt i grafikkapplikasjoner for lagring av objekter i en 3d-verden. Klassen FrameBehavior er en subklasse av Java3D sin ViewPlatformBehavior-klasse (4). Som navnet antyder er det her kameraoppførselen styres. Data om kameraet hentes fra Elementorganisator-klassen i form av et Kamera-objekt. Dette Kamera-objektet blir sendt inn og lagret i Framebehavior. Det samme gjelder toglisten. FrameBehavior vil for hver nye frame kalle togets tick() metode for kalkulering av ny posisjon. Se kapitelet om togforflyttning for mer info om dette. Tog void tick() Figur 21: Et Tog-objekt har en tick-metode for oppdatering av posisjon for hver frame 21

22 3.5 PROGRAMMETS STRUKTUR ETTER OPPSTART Når de 4 vinduene er opprettet blir Elemetorganisator-objektet slettet og oppstartsførløpet er avsluttet. Det er nå de 4 vinduene som holder programmet kjørende. De nødvendige datastrukturene er hentet ut fra ElementOrganisator og blir tatt vare på av de levende vindu-objektene. Programmets dynamiske natur med elementer som beveger seg, skifter farge osv opprettholdes med Java TimerTask-tråder som ved jevne mellomrom kaller oppdatermetoder. Visning mot 3D-verdenen oppdateres av processstimulus-metoden i FrameBehavior-klassen. Denne kalles for hver nye frame. 22

23 4 SYSTEMETS SAMMENSETNING OG VIRKEMÅTE VED BRUK 4.1 INNLEDNING Når programmet har gått gjennom prosessen beskrevet i forrige kapittel, er 4 vinduer opprettet og systemet er klart til bruk. Figur 22: Alle fire vinduer opprettet Toget kjøres ved å sette skal-hastighet med + og knappen i togkontrollvinduet. Toget vil da akslerere/retardere med fastsatte akslerajon og retardasjon(m/s/s). Togvei settes opp ved å trykke på sporvekselsymboler (hvite piler opp/ned) og blokkskillesymboler(røde/grønne piler). Ulike informasjoner vil komme i DMI (Ertms-skjermen i førerbordet) avhengig av oppsatt togvei og togets forflyttning langs sporet. 23

24 4.2 SAMMENSETNING AV PROGRAMMET OVERORDNET SAMMENSETNING På Figur 23 vises hvordan programmets enheter henger sammen. Figuren inneholder ikke samtlige klasser, men viser den overordnede sammenhengen mellom de ulike komponentene. Programmets grensesnitt mot brukeren består av 4 vinduer. Dette er Univers3d, TrafikkstyringFrame, TogFrame og DMIFrame. Alle disse er subklasser av JFrame (vinduer i Java swing). Så lenge programmet kjører så lever ett objekt av hver av disse klassene. 24

25 TogFrame DMIFrame TogKontroll 1 ErtmsSystem ErtmsPunktSet Tog void legginnertmspunkt( ArraList<ErtmsPunkt> liste) 1 void legginnertmspunkt( ArraList<ErtmsPunkt> liste) SNodeTog tognodeend JLabel EndSymbol <<interface>> SNodeElement <<interface>> ErtmsSignal <<interface>> SporplanElement void settinnsnode( Trase t) void settinnsnode( Trase t) ErtmsStopp SNode snode void settinnsnode(tr ase t) SNodeTog Tog tog SNode SNode neste SNode forrige UniversElement parent 1 JButton SNodeTog tognodeend TrafikkstyringPanel 1 1 TrafikkstyringFrame Peker til første node(r) 1 FrameBehavior UniversPanel Univers3d 1 1 Figur 23: Oppbygging av systemet under bruk 25

26 4.2.2 UNIVERS3D Univers3d er vinduet som inneholder 3d grafikken. Univers3d har et UniversPanel som igjen har en FrameBehavior (se nederst Figur 23). UniversPanel lagrer alle de visuelle 3d objektene gjennom Java3d sin scenegraph. Dette er en trestruktur av Java3d noder. Java3d sine klasser Branchgroup (4), TransformGroup (4) og Shape3D (4) er subklasser av Node (4) og kan addes til scenegraphen. I Univers3d vinduet vises vanligvis det lokføreren ser foran seg av infrastruktur og omgivelser. Kameraet kan imidlertid settes opp hvor som helst i hvilken som helst retning i denne 3d-verdenen. Kameraet styres av FrameBehavior klassen. Framebehavior har en peker til toget. Toget rekalkulerer sin posisjon langs traseèn og sin plassering i 3d-verdenen for hver nye frame. Dette skjer ved at Framebehavior kaller toget sin tick-metode. Figur 24: Univers3D-vinduet, visning av infrastruktur og omgivelser ved å bruke Java3D 26

27 4.2.3 TRAFIKKSTYRING Vinduet for trafikkstyring er representert av TrafikkstyringFrame-klassen. Denne klassen har et TrafikkStyringPanel. Det sentrale her er at TrafikkstyringPanel objektet har en peker til det første eller de første SNode-objektene i den lenkete listen som går gjennom hele spornettet. Det er vert å merke seg at det kan være flere dersom det f.eks er dobbelspor ved starten av trasèen. Den strekningen som er laget til dette prosjektet har imidlertid bare ett spor og følgelig bare èn SNode som startnode. Med en peker til starten av listen kan TrafikkStyringPanel traversere gjennom hele spornettet. Ved å tegne en strek mellom hver SNode vil hele spornettet tegnes ut. Som illustrert med ErtmsStopp klassen som eksempel (se ca midt på Figur 23) kan objekter være tilknyttet disse SNode-objektene ved å implementere SNodeElement-interfacet. Videre kan SporPlanElement-interfacet implementeres og komponenten får dermed muligheten til å tilgjengeliggjøre et symbol som kan tegnes på trafikkstyringspanelet under traverseringen. 27

28 4.2.4 TOG Tog-klassen er på mange måter et bindeledd i systemet. To av vinduene er logisk knyttet direkte til Tog-klassen. Det ene er TogFrame. Her styres toget fra. TogFrame er tilknyttet Tog gjennom TogKontroll. TogKontroll inneholder togstyringslogikken. Figur 25: Togkontroll Det andre er DMIFrame. DMIFrame er koblet mot toget gjennom ErtmsSystem-klassen. Dette vinduet representerer ERTMS-skjermen (DMI Driver Machine Interface) som lokføreren har foran seg i førerrommet. ErtmsSystem er hjernen i togets Ertms-utrustning. ErtmsSystem bestemmer hva som skal vises på DMI. For å finne ut dette har ErtmsSystem et ErtmsPunktSet. Dette er en samling av de ErtmsPunkt (informasjonspunkt med en tillatt hastighet) som ligger foran toget på strekningen. ErtmsPunktSet utfører kontinuerlig beregninger mot disse punktene i forhold til avstander og hastigheter. Figur 26: DMI (Driver Machine Interface) 28

29 Toget er også tilknyttet den lenkete listen av Snode-objekter som går gjennom spornettet. Dette skjer gjennom togets SnodeTog-objekt. SNodeTog-objektet vil forflytte seg gjennom den lenkete listen etter hvert som toget kjører. Ettersom toget er tilknyttet den lenkete listen på denne måten, vil toget hele tiden vite hvilke SNoder det passerer. SNoder kan dermed sende informasjon til toget ved passering KOMMUNIKASJON Komponenter som er koblet mot den lenkete listen, eksempelvis ErtmsStopp fra Figur 23, kan sende informasjon til andre objekter langs listen ved å ta utgangspunkt i sin SNode og traversere gjennom listen derifra. ErtmsStopp representerer et blokkskillepunkt, dvs et punkt på strekningen toget kan eller kan ikke passere. Dette tilsvarer rødt eller grønt lys i et tradisjonelt signalsystem. Et ErtmsStopp-objekt langs strekningen som har endret status fra stopp til kjør kan sende en melding til Tog-objektet via den lenkete listen. Dette benyttes aktivt av ErtmsSystem for å innhente informasjon om status på strekningen foran toget. Dette tas opp i neste kapittel. 29

30 5 ERMTS-SYSTEMET 5.1 INFORMASJONSPUNKTENE ERTMS-systemet skal presentere hastigheter, kjøretillatelser og andre relevante opplysninger om togframføringen til føreren av toget. For å kunne gjøre dette må det hentes inn informasjon om status på linjen foran toget. Med dette menes at ERTMS-systemet må vite hvor langt fram toget har kjøretillatelse og hvilke hastigheter som er tillatt på ulike deler av strekningen så langt kjøretillatelsen gjelder. I den virkelige verden foregår dette via mobilnettet for jernbane, GSM-R. I programmet er dette er løst ved å plassere hastighetspunkter langs strekningen, i praksis langs den lenkete listen av SNode-objekter som følger spornettet. Tillatt hastighet i punktet gjelder fram til neste punkt passeres og en ny hastighet registreres. <<interface>> ErtmsSignal ErtmsPunkt getertmspunkt() ErtmsPunkt double vtargetkmh void oppdater( ) ErtmsStopp ErtmsHast Figur 27: Klassene ErtmsStopp og ErtmsHast er et ErtmsSignal og har et ErtmsPunkt Disse hastighetspunktene implementerer ErtmsSignal-interfacet. Det innbærer at de må ha en getertmspunkt()-metode. I praksis betyr det at disse klassene har et ErtmsPunkt slik Figur 27 viser. ErtmsStopp er et punkt toget enten må stoppe ved eller kan passere. Et objekt av denne typen vises i 3d-verdenen som et blått skilt med gul pil (5) definert av ERTMS. ErtmsHast er en gitt tillatt hastighet. Disse er eksempler på hvilke ErtmsSignal vi kan ha og det er disse to som er implementert i denne versjonen av programmet. Et eksempel på en aktuell utvidelse ville være ErtmsMidlertidigHast som representerer i midlertidig nedsatt kjørehastighet. 30

31 5.2 INNHENTING AV INFORMASJON ErtmsSystem vedlikeholder et ErtmsPunktSet. ErtmsPunktSet er en samling av alle de ErtmsPunkt-objekter toget har foran seg så langt toget har kjøretillatelse (fram til neste ErtmsStopp-objekt som har status stopp). DMIFrame 1 1 ErtmsSystem ErtmsPunktSet Tog SNodeTog tognodeend 1 1 void legginnertmspunkt( ArraList<ErtmsPunkt> liste) 1 void legginnertmspunkt( ArraList<ErtmsPunkt> liste) void oppdaterertmspunkt Liste() ErtmsStopp SNode snode 1 SNodeTog Tog tog 1 JButton Figur 28: Informasjonsflyt mellom ErtmsStopp og Tog Trykkes på og skifter til grønn 31

32 Informasjonspunktene ligger langs den lenkete listen som følger sporet. Figur 28 illustrerer hvordan ErtmsPunkt-objektene blir hentet inn i ErtmsSystem og lagret i ErtmsPunktSet. 1. Knappen på trafikkstyringspanelet trykkes. Denne knappen vil gjennom en lytter aktivere endrestatus()-metoden i ErtmsStopp. rød pil 2. ErtmsStopp vil nå starte i sin SNode og søke langs den lenkete listen på leting etter et SNodeTog objekt. Det tilhørende tog sitt oppdaterertmspunktliste() metode kalles. lilla pil. 3. Toget vil nå starte et søk motsatt vei langs listen og samle opp alle ErtmsSignal fram til det møtes på et ErtmsStopp med status stopp. rosa pil 4. ErtmsPunkt-objektene som ble hentet ut av ErtmsSignalene langs sporet blir samlet i en ArrayList og sendt inn i togets ErtmsSystem og videre til ErtmsPunktSet. grønn pil Traverseringen beskrevet i punktene over foretas ved hjelp av klassen SignalMelding. Hver gang status endres i et ErtmsStopp-objekt vil dette gjenta seg og en oppdatert liste av ErtmsPunkt-objekter vil bli lagret i ErtmsSystemets ErtmsPunktSet 32

33 5.3 ERTMS OVERVÅKING OG STATUS Under kjøring vil ERTMS-systemet befinne seg i en av tre overvåkingsmoduser og i en av flere statuser innenfor overvåkingsmodusen. Overvåkingsmoduser: CSM Ceiling Speed Monitoring TSM - Target Speed Monitoring RSM Release Speed Monitoring Statuser: NoS No Status PreS PreStatus IndS - IndicationStatus OvS OverspeedStatus WaS WarningStatus IntS IntervensionStatus Ikke alle statuser er aktuelle for alle overvåkingsmoduser. ERTMS-systemet viser hvilken av disse overvåkingsmodusene og statusene det befinner seg i ved hjelp av ulike farger og visninger i DMI. CSM Ceiling Speed Monitoring er normal kjøring der det er langt igjen til hastighetsrestriksjoner for toget. Toget overvåkes her mot en takhastighet. Normal status er NoS, men kan skifte til OvS, WaS og IntS dersom tillatte hastighet overskrides, evt. overskrides så mye at ERTMS griper inn og bremser toget. TSM Target Speed Monitoring er kjøring mot et punkt med lavere hastighet enn gjeldende tillatte hastighet. Her overvåkes man mot bremsekurver og status vil endre seg avhengig av hastighet og etter hvert som toget nærmer seg målpunktet. RSM Har gruppen ikke fått studert som en del av prosjektet og finnes ikke i denne versjonen av programmet. Det henvises til offisiell ERTMS dokumentasjon for ytterligere forklaringer av dette. Gruppen har brukt dokumentet OPERATIONAL DMI INFORMATION - ERTMS/ETCS Driver Machine Interface (6) som referanse under utviklingen av ERTMS systemet i gruppens program: 33

34 5.4 ERTMSPUNKT-KLASSEN ErtmsPunktSet har som vist tidligere, til en hver tid en liste over alle aktuelle ErtmsPunktobjekter. Et ErtmsPunkt er enkelt forklart et punkt langs sporet med en maks tillatt hastighet. Videre har ErtmsPunkt en oppdater(..)-metode. public void oppdater(double postog, double toghastkmh, double toghastms, double vpermkatkmhglobal) En TimerTask i ErtmsSystem trigger oppdater-metoden i ErtmsPunktSet som igjen kaller oppdater i hvert ErtmsPunkt i listen DMIFrame ErtmsSystem ErtmsPunktSet ErtmsPunkt TimerTask oppdater() oppdater() //tilgangsmetoder 1.. oppdater() //tilgangsmetoder Figur 29: Oppdatering av ErtmsPunkt-objektene i ErtmsPunktSet Oppdater-metoden utfører, ved hjelp av en rekke private metoder, beregninger basert på blant annet tillatt hastighet i punktet, togets hastighet, togets bremseegenskaper, togets posisjon og gjeldende tillatte hastighet. Det beregnes flere kurver mot punktet. Basert på hvor toget befinner seg i forhold til disse kurvene bestemmes gjeldende overvåkingsmodus og status. 34

35 Figur 30: Kurver fram mot 2 påfølgende målpunkt, bildet hentet fra referansen (6) Figur 30 viser prinsippet med kurver og de ulike overvåkingsmoduser og statuser under to påfølgende hastighetsreduksjoner. For å beregne disse kurvene brukes formler. Gruppen antar at disse formlene er standard formler definert av ERTMS. Gruppen har imidlertid ikke lykkes gjennom dette prosjektet å finne sikker dokumentasjon på disse. Basert på forklaringer av systemets virkemåte i referansedokumentet (6) har vi utarbeidet egne formler for disse kurvene. Dette er enkel matematikk med utgangspunkt i S = V * T. private double bremseavstand(double toghastms) { double s = ((toghastms * toghastms) - (vtargetms) * (vtargetms)) / (2 * driftbremsretardasjon); } return s; Denne metoden fra ErtmsPunkt sier at avstanden fra brems tilsettes til toget har oppnådd målhastigheten (bremseavstanden) er: vtog 2 vmål 2 / 2 * retardasjon 35

36 Kurvene for PreS og IndS forflyttes ytterligere ved å addere bremseavstanden med denne avstanden: vtog * (DEFINERT TIDSMARGIN + Tiden det tar for toget å tilsette bremser) Den totale avstanden finnes av denne metoden: private double distancetopres(double togpos, double toghastms) { // formel for dette er sjølvantatt etter // prinsippet for ATC bremsekurver int t = TIDSMARGIN_BREMSEKURVE_TIL_PRE_STATUS; double s = bremseavstand(toghastms); s += (toghastms * (t + tilstid)); } return pos - s - togpos; En tilsvarende metode finnes for IndS Andre verdier som kalkuleres av oppdater-metoden er største tillatte hastighet ved kjøringen fram mot punktet og ved hvilken hastighet ERTMS-systemet skal gripe inn og bremse toget automatisk. Det foregår også en sjekk av hvorvidt ErtmsPunktet medfører en reduksjon av gjeldende hastighet eller ikke. Nødvendige omkalkuleringer mellom m/s og km/h foretas også. 36

37 5.5 ERTMSPUNKTSET-KLASSEN Forrige avsnitt viste at hvert ErtmsPunkt foretar sine egne kalkuleringer av hastigheter, avstander, overvåkingsmoduser og statuser. ErtmsPunktene i ErtmsPunktSet sin liste har ulik avstand til toget og ulik tillatte hastighet. De vil dermed ofte ha ulik overvåkingsmodus og status. ERTMS-systemet kan derimot bare ha en overvåkingsmodus og en status på et gitt tidspunkt. Det blir da ErtmsPunktSet-klassen sin oppgave å finne ut hvilket av ErtmsPunktene som skal gjelde til en hver tid. Hovedregelen er at det er det ErtmsPunktet som er mest restriktivt som bestemmer. PreStatus og IndStatus hentes fra gjeldende ErtmsPunkt (aktuellkurvestatus). private int finnstatus(int aktuellkurvestatus, double vtogkmh) { if (!erovervperm(vtogkmh)) return aktuellkurvestatus; if (!erovervint(vtogkmh)) return ErtmsSystem.OVS; } return ErtmsSystem.INTS; Statusene OverspeedStatus og IntervensionStatus blir aktivert på bakgrunn av største tillatte hastighet (vperm) og hastighet for bremseinngripen (vint). VPerm og vint bestemmes av det mest restriktive ErtmsPunkt sine bremsekurver sammenlignet gjeldende tillatte hastighet. private double finnvperm() { if (vpermkatkmh < vpermkurvekmh) return vpermkatkmh; } return vpermkurvekmh; Tilsvarende metode for vint finnes. 37

38 Videre tar ErtmsPunktSet seg av å slette de ErtmsPunktene som passeres og ikke er interessante mer. ErtmsPunktSet vedlikeholder en array: double[] vpermkat. Et ErtmsPunkt har en hastighetskategori. I denne versjonen av programmet er det definert 3 hastighetskategorier. Signalkategori Hastighetkategori Tempkategori Hver av disse har en definert int-verdi (konstant i ErtmsSystem-klassen). Ved passering av et ErtmsPunkt vil hastigheten til den kategorien som passeres oppdateres. Det er den til en hver tid laveste av kategorihastighetene som er gjeldene takhastighet (vpermkatkmh). Videre er det den til en hver tid laveste av gjeldende takhastighet og mest restriktive kurvehastighet som er største tillatte hastighet (vperm). Dette ser vi i metoden finnvperm() over. Alle sentrale verdier som ErtmsPunktSet-klassen får fra sine ErtmsPunkt eller beregner gjennom sin oppdater-metode blir gjort tilgjengelig for ErtmsSystem-klassen gjennom tilgangsmetoder. 38

39 5.6 ERTMSSYSTEM-KLASSEN OG DMI OPPDATER ErtmsSystem har en oppdater-metode som blir kontinuerlig trigget av en TimerTask. Her kalles oppdater-metoden i ErtmsPunktSet som igjen kaller oppdater i ErtmsPunkt. Det som skjer videre i ErtmsSystem sin oppdater-metode har med oppdatering av DMI å gjøre DMI-OPPBYGGING SpeedoPanel //Metoder for å utføre endringer i panelet DistancePanel //Metoder for å utføre endringer i panelet CPanel ErtmsSystem void dmioppdater() void dmioppdater hast() void dmioppdater planning() DMIFrame //delegate metoder DMIPanel //delegate metoder //Metoder for å utføre endringer i panelet ELeft //Metoder for å utføre endringer i panelet FPanel //Metoder for å utføre endringer i panelet PlanningPanel //Metoder for å utføre endringer I panelet ERight Figur 31: ErtmsSystem-klassen og oppbygging av DMI, kilde for bilde: (6) //Metoder for å utføre endringer i panelet 39

40 Figur 31 viser hvordan DMI er bygd opp. DMI er definert av ERTMS og består av adskilte deler. Disse delene er representert med hver sin JPanel-klasse som er navngitt etter funksjon. Hver av disse delpanelene har en rekke metoder for å utføre visuelle endringer i panelet. Visningene i disse panelene er bygget opp av Java Swing komponenter og Graphicsklassen sine tegnemetoder. Hele DMI er representert av klassen DMIPanel. Her samles alle delpanelene. DMIPanel har delegate-metoder for metodene i delpanelene slik at alle endringer på hele panelet kan utføres ved hjelp av metoder i DMIPanel-klassen. De samme delegate-metodene finner man i DMIFrame-klassen. ErtmsSystem kan dermed ha full styring på hele DMI ved å kalle delegate-metodene i DMIFrame-klassen. Det er hovedsaklig metoder for de endringene som er aktuelle i denne versjonen av programmet som er lagt inn. Ved utvidelse av funksjonalitet legges det inn nye metoder i de aktuelle delpanelet. Videre må de nye metodene gjenspeiles som delegate-metoder i DMIPanel og DMIFrame DMI-OPPDATERING I ErtmsSystem finner vi de private metodene dmioppdater, dmioppdaterhast og dmioppdaterplanning. Disse blir kjørt kontinuerlig av en TimerTask gjennom oppdatermetoden. dmioppdater: Metoden dmioppdater henter informasjon fra ErtmsPunktSet gjennom dens tilgangsmetoder og oppdaterer innholdet i DMI på bakgrunn av dette. Det som oppdateres i dmioppdater er relatert til panel A og B i DMI (DistancePanel og SpeedoPanel). Dette innbærer hastigheter, avstander, status og overvåkingsmodus. Hastighetene vperm, Vtarget og Vint settes direkte inn mot DMI. Informasjon om status og overvåkingsmodus hentes fra ErtmsPunktSet. Dersom det har skjedd endringer her siden forrige oppdatering, kalles henholdsvis metodene dmistatusendring og dmiovmodusendring. Disse metodene utfører endringer i visningen av vperm, Vtarget og vint samt avstand til målpunkt. Dette skjer ved hjelp av farger og grafiske framstillinger definert i ERTMS dokumentasjonen (6) kapittel 2. 40

41 dmioppdaterhast: Her sendes togets hastiget inn i DMI. dmioppdaterplanning: Her sendes gjeldende takhastighet, arrayen med kategorihastigheter og samlingen av gjeldende ErtmsPunkt-objekter inn i DMI. Denne informasjonen brukes i DMI planning area til å vise lokføreren hva som forventes framover langs strekningen. Gruppen har ikke gjennom prosjektet funnet noe detaljert beskrivelse av hvordan DMI planning area er bygd opp. Gjennom bilder som for eksempel bildet i Figur 31 og samtaler med oppdragsgiver har gruppen antatt en virkemåte og oppbygging for denne delen av DMI. Gjeldende takhastighet representeres av et blått felt som dekker hele høyre, nedre del av planning area. Hastighetsreduksjoner opp til 4000 meter framover langs linjen markeres med en pil ned langs en logaritmisk avstandsskala. Bredden på det blå feltet der hastighetsreduksjonen gjelder fra samsvarer med forholdet mellom gjeldene takhastighet og den nye takhastigheten. 41

42 6 TOGETS FORFLYTTNING LANGS SPORET I 3D-VERDENEN Tog LokVogn LokVogn LokVogn Boggi double pos Point3d point? Boggiens 3d-punkt beregnes ved å interpolere mellom de to SNode objektene SNode SNode Point3d point double pos Point3d point double pos Figur 32: Boggien beregner sitt punkt i 3d-verdenen 42

43 Når vognens to boggier vet sine 3dpunkt, kan LokVogn objektet plasseres og roteres korrekt på sporet Figur 33: Vognens to boggier kjenner sitt punkt, da kan vognen plasseres og roteres korrekt 43

44 6.1 INNLEDNING Som nevnt flere steder tidligere ligger det en lenket liste av SNode-objekter langs sporet. Hvert SNode-objekt har et punkt (en 3d-posisjon i 3d verdenen) og en pos (en 1d-posisjon som er antall meter fra starten av strekningen). Når man vet boggiens pos (avstanden det har kjørt fra starten av strekningen), vet man også hvilke to SNode-objekter boggien befinner seg mellom. Boggien befinner seg langs en tenkt strek mellom de to SNode-objektene. Pos-verdien til begge SNode-objektene og til boggien er kjent. Punktet i 3d-verdenen til begge SNode-objektene er kjent. Da kan punktet til boggien enkelt beregnes. SNode SNode neste SNode forrige Point3d point double pos Figur 34: SNode-klassen har pekere til neste og forrige samt en pos langs trasèen og et punkt i 3d-verdenen 44

45 6.2 BEREGNING AV TOGETS POS (ANTALL METER KJØRT FRA STREKNINGENS START) Ved hver oppdatering (frame) beregner toget sin nye posisjon. Programmet måler tiden det har tatt fra forrige oppdatering. Hastigheten til toget er kjent. Det er da enkelt å beregne togets nye posisjon. S = V * T Strekning kjørt siden forrige oppdatering (m) = Togets hastighet (m/s) * Tiden siden forrige oppdatering (s). Når dette adderes med den forrige posisjonen får man den nye posisjonen. Posisjonen er antall meter fra strekningens nullpunkt (pos = 0). For hver nye frame kalles tick() metoden i alle Tog-objekter. Denne beregner da togets nye posisjon. Togets tick() metode kaller hver vogn sin tick() metode. Hver vogn har en fast offsetposisjon i forhold til togets posisjon og denne kalkuleres da enkelt. Videre har hver vogn 2 Boggi-objekter. Disse har på samme måte en offsetposisjon i forhold til sin vogn. På denne måten har alle boggier i toget til enhver tid en oppdatert posisjon. Det vil si at alle Boggi-objekter vet hvor mange meter den har kjørt fra strekningens posisjon 0. Tog void tick() LokVogn void tick() Boggi Point3d oppdaterpos(double pos) Figur 35: Oppdatering av posisjoner i tog, hver vogn (lok) og hver boggi 45

46 6.3 BEREGNING AV TOGETS PUNKT I 3D-VERDENEN Langs sporet ligger det en lenket liste av SNode-objekter. Disse har en 1 dimensjonal posisjon (double pos) og en 3 dimensjonal posisjon (Point3d point). Disse er kjente verdier. Et boggi-objekt har også en pos og et point. I avsnitt 6.2 beskrives hvordan pos beregnes. Denne er nå en kjent verdi. Ettersom boggien vet sin pos og alle SNode-objekter også har en pos, kan boggien alltid vite hvilke to SNode objekter den befinner seg mellom. Dette vedlikeholder Boggi-objektet i datafeltene startnode og endnode. I metoden oppdaterpos interpolerer boggien mellom startnode og endnode ved hjelp av de kjente posisjonene og boggiens 3D posisjon kalkuleres (se Figur 32). Java3D sin Point3d klasse har en interpolate metode som gjør dette. Begge boggiene i en vogn gjør denne operasjonen. Vognen har nå 3D posisjonen til sine to endepunkter. Vognen kan nå transformeres til sin 3d-posisjon og rotasjon. Vektoren mellom punktene utgjør vognens retningsvektor. Dette blir også kameraets retning dersom et kamera knyttes til vognen. Dette illustreres på Figur

47 7 XML-FILENE 7.1 INNLEDNING Strekningen bygges og settes sammen ved hjelp av XML-filer. Disse finnes i mappen XML og har faste navn. Se Figur 36. Figur 36: XML-filene Hver tagg i en XML-fil har en tilhørende klasse i programmet. Når en tagg leses opprettes et objekt av tilhørende klasse. En tagg kan være et datafelt i en klasse eller representere et objekt (ofte et element i 3d-verdenen) som skal legges inn en liste over slike objekter. (Liste over omgivelsesobjekter) (Omgivelsesobjekt) (Datafelter) Figur 37: Utdrag fra omg.xml 47

48 7.2 TRASE.XML Trase.xml inneholder traseèn sporet og de fleste infrastruktur- og omgivelsesobjekter følger. Trasèen er bygd opp av avsnitt som går rett fram i en retning og avsnitt som kurver fra en retning til en annen retning. Kurvene beregnes automatisk mellom rettavsnittene. KurveTraseXML-taggene har derfor ingen data tilknyttet Figur 38: Utdrag fra trase.xml 3 KurveTrase beregnes i mellom RettTrase ene 2 KurveTrase beregnes i mellom RettTrase ene 1 Figur 39: Trasèen fra Figur 38 tegnet i koordinatsystem Dersom det ikke lar seg beregne en enkel kurve mellom to RettTrase er, vil det komme en feilmelding om dette under oppstart. 48

49 7.3 TRASEVERTIKAL.XML Her kan man legge inn punkter langs trasèen som har en gitt høyde for å skape en høydeprofil langs trasèen. Det er ikke lagt inn høydepunkter på strekningen som er laget i dette prosjektet. 7.4 SPOR.XML I spor.xml legges inn de spor som strekningen skal bestå av. Spor legges inn langs z-aksen ved hjelp av taggene RettSporMaterialXML, KurveMaterialXML og SporvekselMaterialXML. Figur 40: Utdrag fra spor.xml Ett rettspor angis med startpunkt og sluttpunkt. Sporveksel og kurve angis med startpunkt og kurveradius. Sluttpunkt for disse vil da beregnes. Angis her punkter med høyere z-verdi enn lengden på trasèen vil det komme en feilmelding under oppstart og programmet avsluttes. Når en tagg av eksempelvis RettSporMaterialXML påmøtes, vil det opprettes et objekt av klassen RettSporMaterialXML. Denne vil igjen opprette et objekt av klassen RettSporMaterial. RettSporMaterial er klassen som representerer elementet som vises i 3d-verdenen. Dette prisippet benyttes for alle spor, infrastruktur og omgivelseselementer som hentes fra de respektive xml-filer. 49

50 7.5 INFRA.XML Fra infra.xml leses øvrig infrastruktur. Dette kan i prinsippet være hva som helst av for eksempel skilter og signaler langs en strekning. I dette prosjektet er dette objekter av ErtmsStopp, ErtmsHast og ErtmsPosisjonBalise. Disse er traseavhengige objekter og startpunktet som angis i xml-filen er i forhold til trasèen. Plasseres: -2.5 meter fra senter av trasèen 0 meter opp eller ned 300 meter langs trasèen Figur 41: Utdrag fra infra.xml Det vil også her produseres en feilmelding dersom angitt posisjon ikke finnes i trasèen. 7.6 OMG.XML Filen omg.xml inneholder omgivelsesobjekter som landskapet rundt sporet. På Figur 37 vises innlesing av et MilkshapeAsciiObjekt med navn seksjon_trase1.txt. Dette er omgivelsene for den første kilometeren av strekningen og er modellert i programmet Milkshape3D (7). Alle punkter i seksjon_trase1.txt er rekalkulert til å følge trasèen ved hjelp av programmet MilkshapeTraseTransform. Se kapittel 7.8 for informasjon om dette programmet. Selve byggingen av landskapet er gjort som et helt rett landskapsstykke i Milkshape3D og lagret i filen seksjon1.txt. Milkshape3D figurer lagres fra mappen milkshapeascii og kan åpnes i programmet Milkshape3D ved å benytte menyvalget import- Milkshape3D ascii. 50

51 7.7 SCENARIO.XML Denne xml-filen skiller seg litt ut fra de andre ved at den ikke innholder oppbygging av strekningen. Den har med startforutsetningene for programmet å gjøre. Her kan det for eksempel konfigureres hvor langs strekningen toget står når programmet starter. Det henvises til brukerveiledningen for mer info om denne filen. 7.8 MILKSHAPETRASETRANSFORM I pakken hjelpeprogrammer ligger en klasse med navn MilkshapeTraseTransform. Dette er en selvstendig kjørende klasse med egen main-metode. Den er tenkt bare benyttet i en utviklingssituasjon og kjøres direkte fra Eclipse. Parametere konfigureres direkte i mainmetoden. Det dette programmet benyttes til er å rekalkulere en serie landskapsseksjoner laget i Milkshape3D slik at de følger trasèen. Landskapsseksjonene navngis på en standardisert måte med nummer til slutt for eksempel seksjon1.txt, seksjon2.txt osv. MilkshapeTraseTransform vil da produsere filene seksjon_trase1.txt, seksjon_trase2.txt osv. I tillegg produseres automatisk filen spor.xml med de opprettede filnavnene lagt inn samt hvor i 3d-verdenen de hører hjemme. 51

52 ORDFORKLARINGER Takhastighet Dette er høyeste tillatte hastighet i en gitt posisjon langs strekningen. Dersom toget er på vei mot en mer restriktiv hastighet kan det hende at toget må holde en lavere hastighet en takhastigheten for å tidsnok komme ned til den nye takhastigheten. Status ERTMS-utrustningen i et tog vil på et ditt tidspunkt befinne seg i en status. Dette vises til fører med ulike farger og grafiske framstillinger i DMI (6) Overvåkingsmodus (Monitoring mode) - ERTMS-utrustningen i et tog vil til en hver tid befinne seg i en overvåkingsmodus.. Dette vises til fører med ulike farger og grafiske framstillinger i DMI (6) Skalhastighet Dette er den hastigheten føreren stiller inn at toget skal ha. Toget sin automatiske hastighetsregulering vedlikeholder denne hastigheten ved å styre trekkraft eller bremsekraft etter behov. Prinsippet benyttes også i flere typer virkelige tog/lokomotiver, men da med en betjeningsspak til å stille inn skalhastigheten og ikke knapper. Erhastighet Dette er den faktiske hastigheten til et tog på et gitt tidspunkt Posisjon (pos) I dette programmet og i dette dokumentet er begrepet brukt om den avstanden i meter fra starten av strekningen eller trasèen et element befinner seg i og vil være en double verdi. Punkt I dette programmet og i dette dokumentet er begrepet brukt om den 3- dimensjonale koordinaten til et sted i 3d-verdenen og vil være et objekt av Java3D-klassen Point3d 3d-posisjon Samme som punkt Framover Strekningen eller trasèen strekker seg fra posisjon 0 og utover. Framover betyr i dette programmet og dette dokumentet den retningen som posisjonsverdien øker. Dette blir mot høyre på trafikkstyringpanelet Bakover Strekningen eller trasèen strekker seg fra posisjon 0 og utover. Bakover betyr i dette programmet og dette dokumentet den retningen som posisjonsverdien minker. Dette blir mot venstre på trafikkstyringspanelet. Transformasjon Dette er en fornorsking av det engelske transformation og er i dette programmet og dette dokumentet brukt i betydningen geometric transformation i 3Dprogrammering. Dette er operasjoner utført mot geometrien til et objekt for å endre objektets plassering, retning eller størrelse (8). I Java3D lagres en slik transformasjon i et objekt av klassen Transform3D (4). 52

53 GSM-R Dette står for GSM-Rail og er et felleseuropeisk mobilnett for jernbane. GSM-R er en av to hoveddeler som ERTMS består av. ERTMS = ETCS + GSM-R. GSM-R utfører kommuniksjon (både tale og data) mellom tog og mellom tog og driftssentraler (trafikkstyring) 53

54 REFERANSER 1. Eclipse. [Internett] [Sitert: 11 mai 2010.] 2. JAVA SE DOWNLOADS. [Internett] [Sitert: 11 mai 2010.] [Internett] [Sitert: 9 mai 2010.] 4. Overview Java3d [Internett] [Sitert: ] 5. ETCS Marker boards definition. [Internett] [Sitert: 14 mai 2010.] 6. OPERATIONAL DMI INFORMATION - ERTMS/ETCS Driver Machine Interface. [Internett] [Sitert: 22 april 2010.] 7. CUMBALUMSOFT. [Internett] [Sitert: 12 mai 2010.] 8. Baker, Hear and. Computer Graphics with OpenGL third edition. Upper Saddle River, NJ : Pearson Prentice Hall,