ERTMS Driver Interface Simulering

Transkript

1 ERTMS Driver Interface Simulering Hovedprosjekt i informasjonsteknologi våren gruppe 6 Hallgeir Are Olsen Hasan Akin

2 PROSJEKT NR: Studieprogram: Bachelorstudium i informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergsplass, Oslo TILGJENGELIGHET: ÅPEN Telefon: Telefaks: Hovedprosjekt HOVEDPROSJEKT TITTEL: ERTMS Driver Interface Simulering DATO: 31. mai 2010 ANTALL SIDER: 180 PROSJEKTDELTAKERE: Hallgeir Are Olsen: s Hasan Akin: s INTERN VEILEDER: Alexander Yngling OPPDRAGSGIVER: NSB skolen KONTAKTPERSON Inger Altun SAMMENDRAG: ERTMS Driver Interface Simulering er et program som er laget til opplæring av lokførere i det nye felleseuropeiske signal- og trafikkstyringssystemet for jernbane, ERTMS. Programmet viser togframføring under ERTMS sett fra lokførerens side. Programmet er tenkt brukt av instruktører ved NSB skolen. 3 STIKKORD 3D ERTMS TOG

3 FORORD Dette dokumentet er en sammenslåing av den dokumentasjon som er laget i forbindelse med faget Hovedprosjekt i Bachelorstudium i informasjonsteknologi ved Høgskolen i Oslo vårsemesteret Dokumentet består av fire hoveddeler: Prosessrapport med kravspesifikasjon og prosjektdagbok - arbeidsprosessen Produktrapport - programmets oppbygging og virkemåte Testrapport - testing av programmet Brukermanual hvordan programmet brukes Dette er selvstendige dokumenter med egne innholdslister, referanser og sidenummereringer. Gruppen takker sin veileder Alexander Yngling ved HiO for konstruktiv og god veiledning og NSB skolen for utfordrende, spennende og interessant prosjekt. Høgskolen i Oslo, 31. mai 2010 Hallgeir Are Olsen Hasan Akin

4 ERTMS Driver Interface Simulering Prosessrapport

5 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering FORORD Denne rapporten er laget i forbindelse med Hovedprosjekt i Bachelorstudium i informasjonsteknologi ved Høgskolen i Oslo, våren Den beskriver prosessarbeidet av prosjektet ERTMS Driver Interface Simulering. Dette dokumentet inneholder også kravspesifikasjon og prosjektdagbok. Rapporten er beregnet for sensor, veileder og oppdragsgiver, men kan også leses av andre som skulle finne den interessant. Det forutsettes at leseren har kjennskap til programmering og utvikling. For den tekniske oppbygningen av programmet henvises det til produktrapporten. 2

6 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering INNHOLD Forord... 2 Innhold Innledning Om gruppen Om bedriften Bakgrunn for oppgaven Kort presentasjon av ERTMS ERTMS dokumentasjon og informasjon Mål og rammebetingelser Presentasjon av programmet Planlegging og metode Innledning Forprosjekt Fremdriftsplan Arbeidsplan Valg av programmeringsspråk og utviklingsverktøy Utviklingsmodeller Innledning Iterativ evolusjonær modell Spiralmodell (B. Boehm) User Centered Design Test Driven Development (TDD) Risikoanalyse Innledning

7 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 4.2 Risikoadministrasjonsprosess Risikoadministrasjon Risikoplanlegging Risikoovervåkning Utviklingsprosessen Innledning Arbeidsfordeling og arbeidsmåte Spiralmodellen for prosjektet Risikoanalyse for prosjektet Risikoidentifikasjon Risikovurdering Risikoplanlegging Risikoovervåking Kravspesifikasjon Planlegging av iterasjon Iterasjon Målsetting og krav Risikoovervåking Utvikling: Test Dokumentasjon på utført arbeid dag for dag Tilbakemeldinger fra oppdragsgiver Planlegging av iterasjon Iterasjon Målsetting og krav

8 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering Risikoovervåking Utvikling: Test Dokumentasjon på utført arbeid dag for dag Tilbakemelding fra oppdragsgiver Planlegging av iterasjon Iterasjon Målsetting og krav Risikoovervåking Utvikling Test Dokumentasjon på utført arbeid dag for dag Tilbakemelding fra oppdragsgiver Planlegging av iterasjon Iterasjon Målsetting og krav Risikoovervåking Utvikling Test Dokumentasjon på utført arbeid dag for dag Tilbakemelding fra oppdragsgiver Planlegging og forslag til finpussen fram mot levering Informasjon til oppdragsgiver om ERTMS-dokumentasjon og videreutvikling av programmet Konklusjon Hva så gruppen for seg i faget hovedprosjekt data ved HIO?

9 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 7.2 Hvordan har det gått? Hvordan har resultatet blitt? Prosjektdagbok Forarbeid UKE UKE UKE UKE UKE UKE UKE UKE UKE UKE UKE UKE UKE UKE UKE UKE UKE UKE UKE UKE Referanser

10 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 1 INNLEDNING 1.1 OM GRUPPEN Gruppen består av Hallgeir Olsen og Hasan Akin. Medlemmene er jevngamle og har lik familiesituasjon med barn og jobb ved siden av skolen. Gruppedeltakerne har samarbeidet i flere fag tidligere og valgte også å utføre hovedprosjekt sammen. 1.2 OM BEDRIFTEN Oppdragsgiver er NSB skolen. Dette er NSB sin opplæringsinstans for bl.a. utdanning og etteropplæring (resertifisering) av lokførere. NSB skolen har 5 desksimulatorer og 1 replica type 72 simulator som benyttes til trening og opplæring. I tillegg til simulatorbasert opplæringsvirksomhet, driver simulatorsenteret ved NSB skolen også med utviklingsarbeid. Dette går på f.eks. bygging av strekninger og utvikling av øvelser til simulatortrening. Simulatorsenteret prøver også å tenke nytt innen opplæringsverktøy samt å være oppdatert på framtidige løsninger innen jernbanedrift. 1.3 BAKGRUNN FOR OPPGAVEN I dag foregår togframføring ved hjelp av lyssignalsystemer. Disse systemene er til dels svært ulike fra land til land i Europa. Gradvis vil eksisterende signal-/sikringsanlegg bli erstattet med ERTMS (1). Dette vil etter hvert gi et mer felles system for togframføring i hele Europa og i øvrige land som satser på ERTMS systemet. Simulatorsenteret ved NSB skolen ønsker å utvide sin kunnskap om systemet samt å få utviklet et program som viser prinsippet for hvordan togframføring foregår under ERTMS nivå 2 sett fra lokføreren. Gruppemedlem Hallgeir har tatt deler av utdanningsløpet ved QUT (2), Brisbane, Australia der noe av fokuset var 3D-grafikk-programmering og prinsipper for dette. Materiale og kunnskap fra dette og JAVA-programmering generelt utgjør et utgangspunkt for å lage et visuelt program i den retning oppdragsgiver ønsker. 7

11 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 1.4 KORT PRESENTASJON AV ERTMS ERTMS er en forkortelse for The European Railway Traffic Management System (1). Dette er et nytt felleseuropeisk trafikkstyrings- og kommunikasjonssystem for jernbane. ERTMS = ETCS + GSM-R ETCS er det nye signaleringssystemet og GSM-R jernbanens mobilnett for overføring av tale og data. Til sammen utgjør disse ERTMS. ERTMS er en standard, en definisjon. Utvikling og produksjon av komponenter og implementering utføres av ulike aktører. 1.5 ERTMS DOKUMENTASJON OG INFORMASJON ERTMS har en egen nettside (1) med en del generelle opplysninger om systemet. Informasjon og spesifikasjoner for ERTMS er tilgjengelig på The European Railway Agency (ERA) sine nettsider (3). Her vises en del generell informasjon om ERTMS og fordelene med systemet. Ved å velge ERTMS Current Baseline og deretter reference documents får man opp linker til lister over ERTMS spesifikasjoner. ERTMS kommer til å bli implementert i Norge. Første strekning vil få dette systemet i løpet av få år (4). 8

12 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 1.6 MÅL OG RAMMEBETINGELSER ERTMS er et komplekst og sammensatt system som kan vises og ses på fra ulike sider. Målet med oppgaven er å utvikle et program som simulerer togframføring med ERTMS nivå 2 sett fra lokførers synspunkt. Programmet skal vise det lokføreren ser foran seg av infrastruktur/omgivelser samt det som vises i ERTMS skjermen i førerrommet under togframføring. Programmet skal kunne vises på projektor eller skjerm i klasserom ved hjelp av en bærbar PC for bruk i en klasseromsundervisningssituasjon eller ved en presentasjon. Programmet skal kunne kjøres på Windows plattform. Klare rammebetingelser er tid og ressurser. Prosjektet skal være ferdig inn og gruppen består av to medlemmer. Gruppemedlemmene har jobb og familie å ta hensyn til i tillegg til prosjektarbeidet. 9

13 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 1.7 PRESENTASJON AV PROGRAMMET For at leseren skal få en bedre forståelse av programmet ønsker gruppen å gi en kort beskrivelse. Systemets brukergrensesnitt består 4 vinduer. 1. Lokfører-vindu, med utsikt til infrastruktur og omgivelser 2. ERTMS skjerm-vindu 3. Trafikkstyring-vindu 4. Togkontroll-vindu Se Figur Figur 1: Programmets vinduer Vindu 1 viser det lokføreren ser ut av sitt frontvindu under togframføring. Når toget er i bevegelse vil toget her følge sporet og passere omgivelser og infrastruktur underveis. Togets hastighet styres fra vindu 4. I vindu 2 finner vi ERTMS-skjermen eller DMI (Driver Machine Interface) som er det offisielle navnet. DMI er der lokføreren får opp informasjon over hva som ventes på strekningen foran og hva som gjelder av tillatte hastigheter. I vindu 3 simuleres en enkel trafikkstyringssentral. Her settes opp kjøretillatelser og togveier til toget. 10

14 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 2 PLANLEGGING OG METODE 2.1 INNLEDNING Første møte ble holdt i HiO sine lokaler i 4 etg. etter semesterstart høsten På daværende tidspunkt hadde gruppen ingen konkret prosjektoppgave. Et av ønskene var å finne en prosjektoppgave der gruppemedlemmene kunne bruke kunnskap og eksempler opparbeidet i fag tidligere i utdanningsløpet. Å sette seg inn i for mye nytt ville kreve for mye tid og ressurser. I løpet av høsten 2009 ble det brukt en del tid på finne en prosjektoppgave som passet gruppens ønsker. Medlemmene var i dialog med sine arbeidsgivere på utkikk etter hovedprosjekt. Gruppemedlem Hallgeir Olsen er ansatt som instruktør/rådgiver på NSBskolen sitt simulatorsenter for lokføreropplæring. I denne forbindelse kom det frem at simulatorsenteret ved NSB skolen ønsket seg et program som simulerte hvordan togframføring foregår med ERTMS sett fra lokførers synspunkt. Begge gruppemedlemmene synes dette virket spennende, og gruppen bestemte seg for å satse på denne prosjektoppgaven. 2.2 FORPROSJEKT Så snart intern veileder var tildelt begynte gruppen å jobbe med forprosjektrapporten. Det ble holdt møte med veileder og videre møter ble avtalt. Fremdriftsplan og arbeidsplan ble utarbeidet for resten av prosjektperioden. Figur 2 viser fremdriftsplan og Tabell 1: Arbeidsplan, viser arbeidsplan. 11

15 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 2.3 FREMDRIFTSPLAN Figur 2: Fremdriftsplan 12

16 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 2.4 ARBEIDSPLAN Forfase / forprosjekt: Oppgave: Frist / periode: Statusrapport fredag 30. oktober 2009 Prosjektskisse fredag 4. desember 2009 Forprosjekt fredag 29. januar 2010 Egenlæring januar 2010 Teknologier: Java/Java3D Utviklingsverktøy: Eclipse, Milkshape 3D Utviklingsmetodikk: Spiralmodell, User- Centered Design, Evolutionary protyping, Test Driven Development 13

17 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering Utvikling, testing og implementasjon: Oppgave: Frist / periode: Iterasjon / 2010 Start uke 5. I løpet av iterasjon 1 skal det utvikles et skall, et kjørbart program som henger sammen. Programmet skal på dette tidspunkt bestå av flere av de ulike delene, men delene vil ikke være fullført. Avsluttes i uke 7, med overlapping til iterasjon 2 Enkelt 3D landskap og enkle omgivelsesobjekter (tre, bygning) Enkle 3D infrastrukturobjekter som spor, sporveksel, signal, skilt Vindu for å vise det føreren ser foran seg under togframføring (3D landskapet, infrastrukturen, omgivelsene) Vindu for å kontrollere toget System for et togs bevegelse langs et spor gjennom et 3D landskap samt kommunikasjon mellom infrastruktur langs sporet System for å importere og lagre objekter samt koble sammen de ulike vinduene med resten av systemet. Fra tidligere fag som gruppemedlemmene har tatt ved HIO/QUT finns det kode/eksempler/prinsipper som kan rebrukes / omskrives til flere av oppgavene i iterasjon 1. 14

18 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering Iterasjon 2 I løpet av iterasjon 2 skal de påbegynte delene videreutvikles, samt de delene som mangler skal etableres. ERTMS skjerm (DMI) Trafikkstyringsvindu / 2010 Start uke 7. Avsluttes uke 10, med overlapping til iterasjon 3 Iterasjon 3 I løpet iterasjon 3 skal alle delene videreutvikles og nærme seg ferdig / 2010 Start uke 10. Avsluttes uke 13, med overlapping til iterasjon 4 Iterasjon 4 I løpet av iterasjon 4 skal alle deler ferdigstilles / 2010 Start uke 13. Avsluttes uke 17 Sluttfase / 2010 Finpussing 15

19 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering Dokumentasjon: Oppgave: Frist / periode: Alle disse utgjør til sammen prosjektrapporten Prosjektdagbok Daglig, leveres sammen med resten av dokumentasjonen mandag den, 31. mai 2010 Prosessrapport Dokumentasjon av prosessen Leveres mandag den, 31. mai 2010 Produktrapport Leveres mandag den, 31. mai 2010 Testrapport Leveres mandag den, 31. mai 2010 Brukermanual Leveres mandag den, 31. mai 2010 Avslutning: Oppgave: Frist / periode: Forberede presentasjon juni 2010 Presentasjon juni 2010 Tabell 1: Arbeidsplan 16

20 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 2.5 VALG AV PROGRAMMERINGSSPRÅK OG UTVIKLINGSVERKTØY Som nevnt ønsket gruppen å bruke kunnskap opparbeidet i fag tidligere i utdanningsløpet. Gjennom studiet på HiO har det hovedsakelig blitt undervist i Java og brukt Eclipse som utviklingsverktøy. Derfor var det naturlig å bruke disse også i denne prosjektoppgaven. I tillegg trengte gruppen et program for å lage 3D modeller, her falt valget på Milkshape3D, da dette er et enkelt og billig alternativ. Til rapporter og illustrasjoner har gruppen brukt WORD 2007 og PAINT. JAVA Java er et objektorientert programmeringsspråk med klasser, metoder, objekter, variabler, tester etc. Java brukes til å utvikle alt fra små program til store applikasjoner (5). ECLIPSE Eclipse er et kraftig programmeringsmiljø skrevet i Java. Prosjektet ble utviklet av IBM og deretter gjort tilgjengelig for Open Source miljøet. Den største fordelen med Eclipse er at det er i stand til å bruke et stort antall plugins, slik at du enkelt kan utvide funksjonaliteten (6). MILKSHAPE3D Milkshape3D er et program for å lage 3D modeller, det er ikke så avansert som andre ledende 3D-modelleringsprogrammer. Men det er enkelt, billig og mer enn godt nok til vårt formål (7). 17

21 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 3 UTVIKLINGSMODELLER 3.1 INNLEDNING Gruppen har i dette prosjektet brukt innslag fra flere utviklingsmodeller. Her er en generell beskrivelse av modellene gruppen har vært innom. 3.2 ITERATIV EVOLUSJONÆR MODELL Modellen innebærer stadig gjentakelse av aktivitetene. Et produkt lages fra en spesifikasjonsskisse. Dette systemet forbedres med stadige innspill fra kunden. Resultatet er til slutt et system som tilfredsstiller kundens behov (8). Starte med et sterkt forenklet system som kan utvikles fort Lage stadig nye versjoner etter innspill fra kunden helt til et tilstrekkelig system er utviklet Spesifikasjon, utvikling og validering er ikke separate faser, men gjøres om igjen og om igjen, med stadig tilbakemelding fra kunden 3.3 SPIRALMODELL (B. BOEHM) Utviklingsprosessen ses som en spiral, der hver runde er en fase i utviklingsprosessen. Dette er en risikodrevet modell (9). Målsetting med mål og begrensninger for fasen, samt styringsplan. Risikoer monitoreres og alternative strategier vurderes Planlegging, prosjektet blir gjennomgått og det besluttes mål og strategi for neste iterasjon 3.4 USER CENTERED DESIGN Brukersentrert design (UCD) innebærer aktiv involvering av brukere gjennom hele utviklingsprosessen. Når en prototype er utviklet blir denne evaluert og brukertestet, deretter blir svakheter og mangler avdekket og forbedret. Denne prosessen blir gjentatt over flere iterasjoner og prototypen kontinuerlig forbedret (10). 18

22 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 3.5 TEST DRIVEN DEVELOPMENT (TDD) I test drevet utvikling begynner hver ny funksjon med å skrive en test. Den første testen mislykkes alltid, fordi den er skrevet før funksjonen er implementert. For å skrive en test må utvikleren forstå funksjonen, spesifikasjoner og krav, dette betyr at utvikleren må ha fokus på kravene før han skriver koden (11). TDD kan ses på som en spiral, skriv testen, implementer koden, test passert. Skriv ny test, implementer koden osv. Se Figur 3. Figur 3: Test Driven Development 19

23 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 4 RISIKOANALYSE 4.1 INNLEDNING Dette kapittelet beskriver risikoanalyse generelt basert på referansen (12). Gruppens tilnærming til risikoanalyse for dette prosjektet står beskrevet i kapittelet RISIKOADMINISTRASJONSPROSESS 1. Risikoidentifikasjon: Identifisere prosjekt, produkt og gruppe risikoer 2. Risikovurdering: Eventuelle konsekvenser disse risikoene vil ha 3. Risikoplanlegging: Planer for å finne risikoene enten ved å unngå dem eller minske effekten dems på prosjektet 4. Risikoovervåking: Konstant overvåking av risikomomenter, og fornying av planer for risikoadministrasjon fortløpende etter hvert som risikoen skulle bli mer aktuelt Risikoidentifikasjon Risikoanalyse Risikoplanlegging Risikoovervåking Liste over mulige risikoer Priotert risikoliste Kriseplan og planer over mottiltak Risikovurdering Figur 4: Risikoanalyse (12) (figur 5.10 i referansen) 4.3 RISIKOADMINISTRASJON Dokumentere resultatene fra risikoanalysen sammen med en analyse av konsekvensene for at en risiko kan inntreffe i prosjektplanen. En risiko er en uønsket tilfeldighet som kan skje. Risikoen kan true prosjektet, programvaren som er under utvikling eller gruppen. En definisjon på disse kategoriene er følgende: 1. Prosjektrisiko: Risiko som skade prosjektet eller ressursene 2. Produktrisiko: Brukervennligheten av programvaren eller kvaliteten til den kan ta skade av risikoen 20

24 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 4.4 RISIKOPLANLEGGING Tiltak mot risikoer. Gruppen har tre strategier. Det er risikoomgåelse, skademinimering og kriseplaner. 1. Risikoomgåelse: Dersom disse strategiene følges, da er sannsynligheten for at en risiko skal oppstå minske 2. Skademinimering: Ved å følge disse strategiene vil innflytelsen risikoen har bli minsket 3. Kriseplaner: Planer klare dersom risikoen er i ferd med å bli en krise for prosjektet 4.5 RISIKOOVERVÅKNING Dette begrepet innebærer å sjekke de identifiserte risikoene, avgjøre om effektene disse risikoene fører med seg har endret seg og eventuelt sette i gang tiltak. 21

25 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 5 UTVIKLINGSPROSESSEN 5.1 INNLEDNING Planen har vært å ha noen få faste målpunkt underveis med mange småiterasjoner imellom og alltid kjørbar kode. De få faste målpunktene har gruppen lagt opp som 4 hovediterasjoner. Disse er satt opp ved hjelp av en spiralmodell. Spiralmodellen gir et greit bilde av den formen for gjentagende syklus som gruppen har hatt i prosjektet. Ved hver iterasjon har oppdragsgiver kommet med tilbakemeldinger. Basert på dette og har oppdragsgiver og gruppen kommet til enighet om hva som skal endres på og implementeres ved neste iterasjon. Denne måten å operere på har elementer fra Iterativ Evolusjonær Modell og User Centered Design. Spiralmodellens risikostyring er fulgt opp ved å definere risikoer som har blitt monitorert ved hver iterasjon. Mellom hovediterasjonene har målet vært å jobbe med veldig små iterasjoner og kjørbart program hele tiden. Gruppen ønsker mest mulig direkte jobbing med programkoden, utføre en liten endring (eller implementering), kjøre programmet, sjekke at det funker og utføre ny endring (eller implementering). Dette stemmer tildels overens med Test Driven Development, men det har ikke blitt fokusert mye på å skrive automatiske enhetstester da store deler av programmet er visuelt og vanskelig og teste med kode. Den evolusjonære modellen er med også her. Det startes med et enkelt kjørbart skall som det kontinuerlig bygges videre på. 22

26 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 5.2 ARBEIDSFORDELING OG ARBEIDSMÅTE På grunn av arbeidssituasjonen og familiesituasjonen til gruppemedlemmene hadde de ikke mulighet til å møtes på fast sted og tid flere ganger i uken. Derfor bestemte gruppen at arbeidet hovedsakelig måtte foregå distribuert med tildelte oppgaver og ha jevnlige koordineringsmøter for å sammenflette det som hadde blitt gjort siden sist. Gruppen var også klar over en ikke ubetydelig nivåforskjell i programmeringskompetanse mellom gruppemedlemmene. En ansvarsfordeling i forhold til dette var ansett som nødvendig. Hovedansvarsområder: Programmering: Hallgeir Olsen Dokumentasjon: Hasan Akin Bygging av 3d-objekter: Hasan Akin Administrasjon: Hasan Akin Gjennom ansvarsfordelingen ble Hallgeir hovedansvarlig for programmets oppbygging og arkitektur. Dette innbar også at det meste av programmeringen ble Hallgeir sin oppgave, men med mulighet for å fordele deler av jobben til Hasan. Hasan fikk en mer administrativ lederrolle eksempelvis med ansvar for at riktig dokumentasjon ble produsert og tidsfrister overholdt. Under gjennomføringen har gruppemedlemmene beholdt hovedfokus på de tildelte ansvarsområder, men i en gruppe på to personer har begge deltatt aktivt i alle elementer av prosjektarbeidet. 23

27 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 5.3 SPIRALMODELLEN FOR PROSJEKTET Tid 1. Planlegging Planlegge iterasjon 4 4. Evaluering Planlegge iterasjon 3 Tilbakemelding Figur 5: Spiralmodellen for prosjektet Sette opp mål for iterasjon 4 Planlegge iterajon 2 Tilbakemelding Sette opp mål for iterasjon 3 Sette opp mål for iterasjon 2 Forprosjekt Tilbakemelding Sette opp mål for iterasjon Planlegge iterasjon 1 Avsluttet Risikoidentifikasjon / Risikoanalyse START Statusrapport Prosjektskisse Dokumen tasjon Test Dokumentasjon Dokumentasjon Risikomonitorering Utvikle Dokumentasjon Test Risikomonitorering Test Utvikle Test 2. Risikoanalyse Risikomonitorering Utvikle Utvikle 3. Programmering Som modell for prosessen er det brukt en spiralmodell. Den gir et bilde av måten arbeidet overordnet har foregått på. Den viser 4 iterasjoner med ulike faser innenfor hver iterasjon. 24

28 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 5.4 RISIKOANALYSE FOR PROSJEKTET RISIKOIDENTIFIKASJON Gruppens tilnærming til risikoanalysen har gått ut på å finne risikoer (farer) som kunne virke negativt på gjennomføring og resultat av arbeidet. Av disse ønsket gruppen å plukke ut de som hadde stor sannsynlighet for å slå til og de som ville medføre betydelige konsekvenser. Gruppen endte opp med tre definerte risikoer som skulle overvåkes gjennom prosjektet. 1 Ulikt nivå på gruppemedlemmene 2 Ufortusett fravær 3 Tid Risikoene ble monitorert i hver iterasjon ved å sette opp en status for hvor vidt risikoen hadde slått til og blitt et problem. Dersom den hadde det, ble planlagte tiltak iverksatt. Forklaringer til de enkelte risikoene: 1 Ulikt nivå på gruppemedlemmene Gruppen er klar over medlemmenes programmeringsferdigheter er på ulikt nivå. Samme gruppemedlem som kan sies å være den sterkeste programmereren vil kanskje også ha den største tilhørigheten til prosjektet gjennom sin tilknytning til oppdragsgiver. Fare for ujevn fordeling av arbeidsmengden er til stede. Gruppen prøver å kompensere dette med en klart definert ansvarsfordeling mellom programmering og administrasjon. 2 Uforutsett fravær Begge gruppemedlemmene er i jobb og har familie. Egen-, barns- og ektefelles sykdom samt ekstra belastning fra arbeidsgiver kan føre til uforutsett fravær for medlemmene. 3 Tid Faren for å få knapt med tid til å levere det som er planlagt innen en tidsfrist er alltid tilstede. 25

29 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering RISIKOVURDERING Gruppen har vurdert sjansen for at hver risiko ville oppstå og eventuell følge av at så skulle skje. Sannsynlighetsskalaen har disse nivåene: lav, moderat, høy Virkningsskalaen har disse nivåene: uvesentlig, tolererbar, alvorlig, katastrofal Risiko Sannsynlig Virkning Ulikt nivå på medlemmene Høy Tolererbar Uforutsett fravær Høy Alvorlig Tid Moderat Alvorlig Tabell 2: Risikovurdering 26

30 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering RISIKOPLANLEGGING Planlagte tiltak mot hver av de definerte risikoene. Risiko Risikoomgåelse Skademinimering Kriseplaner Ulikt nivå på medlemmene Delegere oppgaver til gruppemedlemmene som de behersker. Kommunisere om programmets oppbygning slik at man settes i stand til å dokumentere også de delene av programmet man ikke har programmert selv. Sette Hasan inn i prinsipper for jernbanedrift og togframføring for å skape en større forståelse for programmets rolle i systemet. Tiltaket skal bidra til større forutsetninger for å lage dokumentasjon. Overføre noe dokumentasjonsansvar til Hallgeir. Produktdokumentasjon er den mest nærliggende. Uforutsett fravær Tid Oppfordre arbeidsgiver til minst mulig overtid i prosjektperioden. Være åpen for mer overtid etterpå. Det viktigste som kan gjøres for å unngå tidsnød er å ikke legge lista før høyt når prosjektet planlegges. Viktigste minimering vil være å ha kalkulert med dette på forhånd slik at noe redusert tid og fokus til prosjektet ikke får stor betydning Samarbeide med oppdragsgiver underveis. Se hva som er fornuftig å implementere i forhold til tid igjen. Omprioritere tidsbruk fra fritid til prosjektarbeid. Redusere arbeidsmengden ved å redusere på funksjonalitet i programmet. Har mulighet til dette gjennom jevnlig kontakt med oppdragsgiver og justering av kravspesifikasjon underveis. Tabell 3: Risikoplanlegging 27

31 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering RISIKOOVERVÅKING I hver iterasjon ble de definerte risikoene monitorert. Det ble konkludert med en status og tiltak iverksatt om nødvendig. 28

32 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 5.5 KRAVSPESIFIKASJON På oppstartsmøtet ble det diskutert hvordan prosjektarbeidet skulle legges opp. Oppdragsgiver og gruppen kom fram til å først sette opp en overordnet kravspesifikasjon. Denne overordnede kravspesifikasjonen skulle fungere som et utgangspunkt for hoveddelene og hovedfunksjonaliteten til programmet. Videre ble det planlagt møter underveis i prosessen slik at representanter fra oppdragsgiver kunne komme med tilbakemeldinger, innspill, forslag og krav til videre utvikling av programmet. Overordnet kravspesifikasjon: Programmet skal demonstrere togframføring med ERTMS nivå 2 sett fra lokføreren Programmet skal ha 4 uavhengige vinduer som kan flyttes og minimeres/maximeres, men ikke nødvendigvis endres størrelse på. Disse 4 vinduene skal inneholde: 1 ERTMS skjerm (Driver Machine Interface, DMI), med de mest sentrale funksjonene 2 Det lokføreren ser foran seg under togframføring (infrastruktur/omgivelser) 3 Enkel signal-/trafikkstyrings funksjonalitet 4 Enkel betjening av toget (kontrollere hastighet og trekkraft/bremsekraft) Togframføring skal skje på en enkelt framstilt jernbanestrekning. Strekningen kan være fiktiv, men skal være infrastrukturmessig realistisk med hensyn på togframføring under ERTMS. Programmet skal kunne kjøres på en laptop med Windows operativ system 29

33 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 5.6 PLANLEGGING AV ITERASJON 1 Hver iterasjon ble avsluttet med planlegging av neste iterasjon i samarbeid med oppdragsgiver og på bakgrunn av de tilbakemeldinger representanter fra oppdragsgiver hadde kommet med. På oppstartsmøtet med oppdragsgiver ble iterasjon 1 planlagt. Det ble her tatt hensyn til den overordnede kravspesifikasjonen og hva som ble ansett som hensiktsmessig å starte prosjektarbeidet med. Gruppen hadde også en del kode fra oppgaver og eksempler fra tidligere fag som kunne være med på å danne et grunnlag for programmet. Følgende hovedpunkter ble planlagt for iterasjon 1: Togkontroll: forslag fra oppdragsgiver om å lage en enkel kontroll av et tog som kjøres i automat. Det vil si at føreren setter en skalhastighet og toget justerer seg automatisk inn til denne hastigheten. 3D landskap/omgivelser og system for togs bevegelse langs et spor: Planlegger å bruke mest mulig prinsipper, eksempler og oppgaver fra tidligere fag og sette dette sammen. Materiale fra Modelling and Animation Techniques-faget ved QUT er spesielt aktuelt. Oppdragsgiver sier at infrastruktur, omgivelser og togsammensetning bør være konfigurerbart og editerbart. Gruppen foreslår å bruke XML for å lese nødvendig informasjon om disse tingene inn i programmet. Enighet om å lage en strekning på ca 20 km. Strekningen kan være fiktiv (i motsetning til en modell av en virkelig strekning). Strekningen trenger ikke ha kontaktledningsanlegg da dette ikke er vesentlig for ERTMS og vil kreve mye ekstra tid og ressurser. 30

34 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 5.7 ITERASJON MÅLSETTING OG KRAV Målsetting: Utvikle et skall av systemet som består av de ulike delene, delene vil ikke være fullført. Men programmet skal være kjørbart. Krav: Kravene til iterasjon 1 fremkommer av den overordnede kravspesifikasjon (se kap. 5.5) og punktene under planlegging av iterasjon 1 (se kap. 5.6) RISIKOOVERVÅKING Risiko Status Tiltak Ulikt nivå på medlemmene Tiltak fra risikoomgåelse utført Ingen Uforutsett fravær Tiltak fra risikoomgåelse utført Ingen Tid Tiltak fra risikoomgåelse utført Ingen Tabell 4: Risikomonitorering iterasjon 1 31

35 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering UTVIKLING: I løpet av iterasjon 1 ble det utviklet et enkelt landskap, enkel infrastruktur og opprettet vindu for dette med navn 3D. Omgivelsene består av grønn plen og enkle bygninger i form av bokser. Av infrastruktur ble spor, sporveksel, og ERTMS-skilt etablert. Kommunikasjon mellom delene ble satt opp. Node-systemet for bevegelse av toget langs sporet ble implementert. Togkontroll-vindu ble opprettet. Se Figur 6. Mye av dette er basert på materiale fra faget Modelling and Animation Techniques ved QUT. 1 2 Figur 6: Vinduer opprettet i iterasjon 1 1. Lokførervindu med infrastruktur og omgivelser 2. Togkontroll TEST Se testrapport DOKUMENTASJON PÅ UTFØRT ARBEID DAG FOR DAG Se prosjektdagbok 32

36 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering TILBAKEMELDINGER FRA OPPDRAGSGIVER Endre tittel på 3D-vindu fra 3D til Infrastruktur og omgivelser Oppdragsgiver tilfreds med gruppens enkle 3D-landskap som består av grønn plen og noen firkantete bokser som forestiller bygninger med jevne mellomrom. Likevel forespørsel om litt mer terreng på en liten del av strekningen for å gi et innblikk i hva som kan gjøres PLANLEGGING AV ITERASJON 2 Enkel endring av tittel i et vindu Forslag om å lage ca 2 km med et lite dalføre med en elv i bunnen, noen trær på sidene og berg/stein mot toppen av dalføret på motsatt side av der jernbanen går. Dette ble vedtatt. ERTMS-skjerm skal påbegynnes i iterasjon 2. Oppdragsgiver har lite dokumentasjon. Ber gruppen søke etter informasjon på internett. Finner denne referansen (13) som blir utgangspunkt for implementasjonen av ERTMS-skjermen Trafikkstyring-vinduet skal påbegynnes i iterasjon 2. Gruppemedlem Hallgeir har gjennom sin bakgrunn kjennskap til hvordan en togleders skjermbilde kan se ut med piler som marker blokkskiller og streker som markerer spor. Oppdragsgiver ønsker en enkel framstilling av dette. 33

37 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 5.8 ITERASJON MÅLSETTING OG KRAV Målsetting: Videreutvikle de påbegynte delene og etablere de vinduene som mangler. Krav: Kravene til iterasjon 2 bygger videre på kravene til iterasjon 1 (se kap ). Under møtet med oppdragsgiver etter iterasjon 1 ble iterasjon 2 planlagt. Punktene under planlegging av iterasjon 2 (se kap ) beskriver krav til iterasjon RISIKOOVERVÅKING Risiko Status Tiltak Ulikt nivå på medlemmene Ansvarsfordeling fungerer greit Ingen Uforutsett fravær Ikke utover forventet Ingen Tid Ligger greit an Ingen Tabell 5: Risikomonitorering iterasjon 2 34

38 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering UTVIKLING: I denne fasen fortsatte utviklingen med de påbegynte delene og i tillegg ble ERTMS skjerm og trafikkstyringsvindu etablert ERTMS er en standard, en definisjon. Ved etablering av ERTMS skjermen ble det tatt utgangspunkt i dette bildet. Figur 7: DMI - hentet fra kilde (13) 35

39 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering I løpet av iterasjon 2 var grensesnittet med de fire delene etablert (se Figur 8) Figur 8: Alle 4 vinduer er etablert TEST Se testrapport DOKUMENTASJON PÅ UTFØRT ARBEID DAG FOR DAG Se prosjektdagbok 36

40 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering TILBAKEMELDING FRA OPPDRAGSGIVER Endre tittel på ERTMS-skjerm (DMI) fra ERTMS-skjerm til det offisielle navnet DMI. Oppdragsgiver ønsker at dette vinduet skal ha tittel DMI som er det offisielle navnet i steden for ERTMS-skjerm Oppdragsgiver tilfreds med dalføret som ble lagt inn som variasjon til det svært enkle og flate landskapet. Påpeker at noen trær vises foran andre trær selv om de står lengre bak Gruppen melder til oppdragsgiver etter noe research på internett at det ser ut til at DMI er en fleksibel enhet som kan inneholde svært mye funksjonalitet. Noe er obligatorisk og noe er frivillig. Gruppen mener at den gjennom dette prosjektets rammer ikke har tid/ressurser hverken til grundig nok research eller implementering til å lage en komplett DMI gjengivelse. Oppdragsgiver sier at dette heller aldri har vært meningen. Det som ønskes vist er ting som har direkte relevans til selve framføringen av toget i henhold til tilgjengelig dokumentasjon. Det sies også fra oppdragsgiver at hvordan noe framstår eller fungerer kan antas dersom dokumentasjon mangler. Det som er viktig er å få etablert et prinsipp for hvordan ting kan se ut. Uansett må detaljer rettes på og ting videreutvikles utenfor dette prosjektet etter hvert som dokumentasjon kommer på bordet PLANLEGGING AV ITERASJON 3 Enkel endring av tittel i et vindu Legger i første omgang opp til å fjerne trærne som vises i feil rekkefølge i stedet for å gå inn i en tidkrevende feilsøkingsprosess på dette. Etter belysningen av DMI ens omfang og fleksibilitet nevnt under tilbakemeldinger, blir gruppen og oppdragsgiver enige om følgende konkretisering av DMIimplementeringen: Dokumentasjon: referansen (13) ERTMS-systemet befinner seg alltid i nivå 2 med full supervision. Faste verdier angitt som konstanter i kildekoden for togets egenskaper. Togets egenskaper er tilsetningstid (sek.), retardasjonsverdi (m/s/s) og toglengde. Kjøretillatelse til toget gis ved å sette nærmeste blokkskille til kjør (grønn pil). Største tillatte hastighet på det stedet der toget står skal da indikeres Felt A Distansepanelet skal implementeres med avstandsvisning i henhold til dokumentasjon 37

41 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering Felt B Hastighetspanelet skal implementeres med hastighetsvisning og CSG (Circular Speed Gauge) i henhold til dokumentasjon. I felt B7 settes fast symbolet for Full Supervision Felt C tillegginformasjon: Her settes felt C8 til å fast vise symbolet for ERTMS nivå 2. C9 viser symbol for bremseingripen når det skjer med blinkende ramme når brems kan løses Felt D Planning implementeres med logaritmisk avstandsskala og blått felt for visning av tillatte hastighet. Restriktive hastighetspunkter vises med symbol og ved stopp vises en 0 i tillegg til symbolet. Felt Eright viser simulert tid i felt E17 Felt Eleft og felt F har trykkbare knapper uten tilknyttet funksjonalitet Lydsignal s_info når ny informasjon dukker opp i DMI 38

42 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 5.9 ITERASJON MÅLSETTING OG KRAV Målsetting: Videreutvikle alle deler av programmet. Få etablert dokumentasjonsdokumenter. Krav: Under forrige iterasjonsmøte kom det fram at kravene til ERTMS-implementeringen måtte klargjøres. Under planlegging av iterasjon 3 (se kap ) er disse punktene pluss noen til listet opp og utgjør krav til iterasjon RISIKOOVERVÅKING Risiko Status Tiltak Ulikt nivå på medlemmene Merkbart problem. Tiltaket fra risikominimering iverksettes. Det settes av en dag hos oppdragsgiver. Hasan settes inn i prinsipper rundt jernbanedrift og togframføring. Kjører simulator. Uforutsett fravær Ikke mer enn forventet Ingen Tid Ligger greit an Ingen Tabell 6: Risikomonitorering iterasjon 3 39

43 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering UTVIKLING I denne fasen fortsatte utviklingen av de fire vinduene og systemer bak. Viktig klargjøring i forhold ERTMS i forkant. ERTMS-systemet ferdigutvikles i stor grad. Mindre endringer på trafikkstyring TEST Se testrapport DOKUMENTASJON PÅ UTFØRT ARBEID DAG FOR DAG Se prosjektdagbok TILBAKEMELDING FRA OPPDRAGSGIVER Ved bremseinngripen av ERTMS-systemet er det mulig å justere skalhastighet, denne bør låses på 0 Ved bremseingripen av ERTMS-systemet går toget i enkelte tilfeller forbi målpunktet. Toget bør stoppe før målpunktet Oppdragsgiver foreslår å legge inn en hastighetsendring til, gjerne mellom stasjon 2 og dobbelspordelen Oppdragsgiver oppdaget under testkjøring en liten feil ved tillatt hastighet ved kjøring gjennom overkjøringssløyfa midt på dobbelspordelen. Toget ble korrekt tatt ned i 80 km/h før sporvekselen i avvik. Tillat hastighet spratt imidlertid opp igjen til 200km/h før hele toget hadde kjørt gjennom sporvekselen. Skiltflaten på noen av ERTMS-marker-skiltene som er plassert langs sporet ved blokkskillene er for mørke Spørsmål fra representanter hos oppdragsgiver om hva som er korrekt oppførsel til DMI ved kjøring fram mot et blokkskille som markerer stopp. Her dukker flere problemstillinger opp. Blant annet sammenlignes det med dagens sikringssystem ATC som tillater å kjøre fram mot et stoppsignal i 40 km/t og som vil gripe inn med brems dersom det passeres. - Hva er maks hastighet fram mot et punkt som viser stopp? - Er det mulig å passere eller vil ikke ERTMS tillate dette? - Hva skjer hvis det passeres? 40

44 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering PLANLEGGING AV ITERASJON 4 Endring i programmet slik at skalhastighet låses på 0 km/h til bremseinngripen er opphevet Endre fast angitt retardasjonsverdi i ERTMS-systemet til en lavere verdi slik at denne blir noe lavere enn den retardasjonen toget faktisk har. Dette vil føre til tidligere bremseinngripen Gruppen og oppdragsgiver er enige om å legge inn en økning til 130 km/h etter stasjon 2 og en reduksjon til 110 km/h før en kurve gjennom dalføret mellom stasjon 2 og dobbelspordelen Feilen ved overkjøringssløyfen på dobbelspordelen må fikses. Gruppen prøver å finne årsaken til feilen og rette denne Gruppen forklarer oppdragsgiver prinsippet for lyssetting i en 3d scene. Programmet er laget med en punktlyskilde (en sol) i et gitt punkt pluss en ambientlyskilde. Alt etter retningen på skiltet vil de reflektere mer eller mindre sollys. Skiltplaten blir derfor noen steder mørkere enn andre steder. Det blir enighet om å øke ambientbelysningen noe for å gi en jevnere belysning uavhengig av retning og posisjon. Ambientbelysning er det generelle lysnivået i en scene. Diskusjonen angående kjøring fram mot et stopp-punkt konkluderes med følgende: Hverken gruppen eller oppdragsgiver klarer å stille tilstrekkelig dokumentasjon om dette tilgjengelig i løpet av kort tid. Her kan det også komme inn nasjonale bestemmelser som ikke er definert på nåværende tidspunkt. Systemets håndtering av dette blir derfor uforandret. Det vil si at overvåkingsmodusen RSM (Release Speed Monitoring) ikke implementeres. Bremsekurve mot stopp gjelder helt ned til 0 km/h og toget bør stoppes like før stopp-punktet. Når kjøretillatelse forbi punktet kommer, endres indikering i DMI til gjeldende hastighet på stedet og toget kan fortsette. Dersom toget skulle passere stopp-punktet i stopp slettes stopp-punktet fra systemet. Ny kjøretillatelse må gis ved å sette neste blokkskillepunkt til kjør. Gruppen har nå ca 6 uker til prosjektet skal leveres. Det planlegges å bruke mer tid på å få laget og satt sammen nødvendig dokumentasjon i denne iterasjonen enn de forrige 41

45 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 5.10 ITERASJON MÅLSETTING OG KRAV Målsetting: Ferdigstille systemet og dokumentasjon. Krav: Gjennom iterasjon 4 skal systemet ferdigstilles innefor de rammer som er satt i prosjektet. Kravene til systemet er den overordnede kravspesifikasjonen (se kap. 5.5) og det som har kommet frem og blitt enighet om på iterasjonsmøtene med oppdragsgiver. Disse kravene er beskrevet i kapitlene planlegging av iterasjon (1,2,3 og4) se kap. (5.6, 5.7.7, og 5.9.7). 42

46 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering RISIKOOVERVÅKING Risiko Status Tiltak Ulikt nivå på medlemmene Fortsatt merkbart problem Anses ikke for noen krise, men tiltak iverksettes for krisehåndtering. Hallgeir overtar produktrapport Uforutsett fravær Ikke mer enn forventet Ingen Tid Hallgeir får noe mindre tid til programmering etter overføring av dokumentasjonsansvar Ingen konkret, men Hallgeir kunne antagelig planlagt flere implementasjoner i programmet dersom han ikke hadde fått dokumentasjonsansvar Tabell 7: Risikomonitorering iterasjon 4 43

47 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering UTVIKLING Det er utført noen endringer i forbindelse med bremseinngripen. Dette går på låsing av skalhastighet og retardasjonsverdi. Det er lagt inn en ny hastighetsseksjon på strekningen. Lysforholdene er endret for å lage skiltene litt lysere. Videre har dokumentasjon (rapporter) hatt en stor rolle i denne iterasjonen TEST Se testrapport DOKUMENTASJON PÅ UTFØRT ARBEID DAG FOR DAG Se prosjektdagbok 44

48 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering TILBAKEMELDING FRA OPPDRAGSGIVER Konkrete endringer som ble etterspurt etter iterasjon 3 er gjennomført. Oppdragsgiver mener programmet stort sett nå er i henhold til den overordnede kravspesifikasjonen og de spesifikasjonene oppdragsgiver og gruppen har havnet på underveis i prosessen. Programmet viser på en visuell og levende måte hvordan føreren opplever det å framføre et tog under ERTMS nivå 2. Både fra gruppen og oppdragsgiver konkluderes det med at ERTMS-systemet og presentasjonen på DMI ikke er komplett, men viser de viktigste detaljene i forhold til togframføringen. Å lage en bortimot fullstendig ERTMS-maskin og DMI i dette prosjektet har aldri vært tema og ville heller aldri vært realistisk. Til det har tids-, ressurs- og dokumentasjonsgrunnlaget vært for knapt. Oppdragsgiver ser for seg at det i nærmeste framtid vil bli satt av tid og ressurser til å gå dypere inn i eksisterende dokumentasjon samt å oppsøke mer dokumentasjon om ERTMS-systemet og DMI spesielt. Programmet som er laget danner da basisen for et utvidet og oppgradert system som vil være viktig i framtidig opplæring av førere i ERTMS. Med begrenset tid igjen er det få endringsforslag i iterasjon 4. Representanter for oppdragsgiver er likevel litt nysjerrige på hvordan man kan gjøre endringer i infrastruktur, omgivelser og konfigurasjoner. Gruppen forklarer litt om at objekter i prinsippet kan lages i Milkshape3d og importeres til programmet. Objekter som skal importers defineres i XML-filer. Disse kan enkelt editeres i en tekstbehandler. De parametere som kan konfigureres er også definert i XML-filer og kan endres her PLANLEGGING OG FORSLAG TIL FINPUSSEN FRAM MOT LEVERING Det viktigste for gruppen nå er å få på plass den dokumentasjon som skal leveres innen tidsfrist. Programmet fungerer og oppdragsgiver er tilfreds med resultatet i forhold til forutsetningene. Se igjennom programkoden og sørge at den er ryddig og enhetlig. Få på plass tilstrekkelig med kommentarer i Javadoc-stil I forhold til tilbakemeldingen om endringer og konfigurering bør det ses litt på programmets håndtering av feil/umulig informasjon i XML-filene. 45

49 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 6 INFORMASJON TIL OPPDRAGSGIVER OM ERTMS-DOKUMENTASJON OG VIDEREUTVIKLING AV PROGRAMMET ERTMS er et ungt system i stadig utvikling. I avslutningsfasen av prosjektet har gruppen forsøkt å forske litt på ERA (3) sine nettsider om ERTMS. Gruppen har sett på hva som finnes av oppdatert ERTMS-dokumentasjon og hvordan man finner denne. Gruppen håper dette kan være nyttig for oppdragsgivers videre arbeid med å- tilegne seg ERTMS-kompetanse og videreutvikle programmet. Som grunnlag for å utarbeide en simulering av DMI i dette prosjektet ble gruppen og oppdragsgiver enige om å bruke dokumentet (13) fra ERA. Dette dokumentet er fortsatt tilgjengelig på angitte direkte referanse, men gruppen finner det ikke lenger i ERA sine lister over ERTMS-dokumenter. Under ERA, ERTMS current baseline (14) ligger et menyvalg reference documents. Her finnes linker til 3 lister. Det ser ut til at i disse 3 listene ligger ERTMS-dokumentene som er tilgjengelige fra ERA. I listen List of Informative Specifications finner man et dokument med navn B34 ERA ERTMS ERTMS/ETCS Driver Machine Interface. Dette dokumentet inneholder, som vårt referansedokument, spesifikasjoner av DMI, men er mye mer omfattende, spesifikt og detaljert. I tillegg medfølger bmp-filer for DMI symboler og wav-filer for DMI lyder. Det har dessuten en adskillig nyere publiseringsdato. Ettersom begge heter B34 kan det tyde på at dette dokumentet erstatter det dokumentet vi har brukt under prosjektet. 46

50 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 7 KONKLUSJON 7.1 HVA SÅ GRUPPEN FOR SEG I FAGET HOVEDPROSJEKT DATA VED HIO? Gruppen så for seg et programmeringsprosjekt. Gruppen ønsket å bruke materiale, teknikker og kunnskap opparbeidet gjennom tidligere fag i utdanningsløpet. Gruppen ville ha et tema som var interessant for seg og oppdragsgiver. Gruppen ønsket å ha en holdbar arbeidssituasjon med normale arbeidstider både underveis og i innspurten. 7.2 HVORDAN HAR DET GÅTT? Det har i stor grad gått slik gruppen ønsket. Materiale fra oppgaver, innleveringer og eksperimentering fra faget Modelling and Animation Techniques ved QUT ble et svært viktig utgangspunkt for programmet. Kunnskap og materiale fra Java og programutviklingsfag fra QUT og HIO har også vært viktig å ha med seg i prosessen. Vil i denne sammenheng også nevne faget Algoritmer og datastrukturer. Programmet benytter flere prinsipper herifra. 3D- og grafikkprogrammering har vært spennende. Temaet har vært interessant for gruppen og spesielt for Hallgeir gjennom hans jobb hos oppdragsgiver. For oppdragsgiver er ERTMS et viktig tema og blir det i økende grad i framtiden. Gjennom et godt utgangspunkt, måten å jobbe på og ikke for høye forventninger fra starten av har gruppen hatt greit med tid og unngått stress, også fram imot innleveringsfristen. 47

51 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 7.3 HVORDAN HAR RESULTATET BLITT? Programmet viser på en enkel, visuell og levende måte hvordan føreren opplever det å framføre et tog under ERTMS nivå 2. Både gruppen og oppdragsgiver konkluderer med at ERTMS-systemet og presentasjonen på DMI ikke er komplett, men viser de viktigste detaljene i forhold til togframføringen utifra tilgjengelig dokumentasjon og antagelser som er gjort. Å bygge en komplett ERTMS-maskin og DMI-visning i dette prosjektet har aldri vært meningen og heller ikke realistisk innenfor rammene for tid, ressurs og dokumentasjonsgrunnlag. ERTMS kommer til å bli innført i Norge i løpet av få år. Opplæring på systemet blir nødvendig. Programmet som er laget i dette prosjektet kan danne et godt utgangspunkt både for undervisning i temaet og andre presentasjoner av ERTMS. 48

52 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8 PROSJEKTDAGBOK 8.1 FORARBEID DAG DATO TIMER ARBEID UTFØRT 19.okt 4 Jobbing med statusrapport 30.okt 2 Redigering og innlevering av statusrapport 02.des 15 Jobbing med prosjektskisse. Diskuterte plattform og utviklingsverktøy. Endte opp på Java/Java3D, Eclipse og Milkshape3D 04.des 15 Opprettet hjemmeside og leverte prosjektskisse 49

53 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.2 UKE 2 DAG DATO TIMER ARBEID UTFØRT ma 11.jan ti 12.jan on 13.jan 15 to 14.jan 7 fr 15.jan 16 Oppstartsmøte med oppdragsgiver. En overordnet kravspesifikasjon blir lagt fram. Arbeidsmåter ble diskutert. Kommer fram til å jobbe i iterasjoner der oppdragsgiver kan komme med tilbakemeldinger og forslag/krav til programmet videre. Første iterasjon planlagt. Starter å finne fram skisser, kodeeksempel, oppgaver, eksperimenteringskode og 3D-objekt frå tidligere fag. Har en del som kan brukes i forbindelse med 3D-landskap, infrastruktur, omgivelser og system med noder for å forflytte toget langs sporet. Møte. Lastet ned Milkshape3D og eksperimenterte med dette programmet. Startet arbeid med forprosjektrapport. Kontaktet veileder for å avtale møte. lø 16.jan sø 17.jan 50

54 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.3 UKE 3 DAG DATO TIMER ARBEID UTFØRT ma 18.jan ti 19.jan 15 Startet implementering av sporveksel som 3D objekt. Objektet basert på tidligere opprettet rettspor-klasse. Jobbet videre med forprosjektrapport on 20.jan 16 Møte. Fortsatte med forprosjektrapport. Fortsatte egenlæring av MilkShape3D. to 21.jan 7 Fortsatte med sporvekselen og startet å lage en kurve som 3D objekt. fr 22.jan 7 Fortsatte med forprosjektrapport. lø 23.jan sø 24.jan 51

55 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.4 UKE 4 DAG DATO TIMER ARBEID UTFØRT ma 25.jan 14 Avslutta arbeid med sporveksel og kurve. Starta å tenke ERTMS. Tenker et system med ERTMSPunkt som representerer tillatt hastighet ulike posisjoner langs strekningen. Egenlæring av MilkShape3D. ti 26.jan 8 Etablerte hovedklasse for DMI(DMIFrame). Starta på klasse som representerer speedometerdelen av DMI skjermen. Laga hastighetsnål med tilhørende metoder for å sette hastighet og farger on 27.jan 15 Møte: Ferdigstillelse av forprosjektrapport og møte med veileder. to 28.jan 16 Fortsatte med speedopanel klassen. Etablerte CSG (Circular Speed Gauge) med tilhørende metoder. Redigerte forprosjektrapport og la den ut på web. Videre egenlæring av MilkShape3D. fr 29.jan 17 Intensiv researchvirksomhet for å finne info om hva DMI viser i ulike situasjoner under togframføring. Finn dokument B34-06E225 1 (Operational DMI information) under ERA sine nettsider. Starta implementering av ErtmsPunkt klassen og kommunikasjon mellom denne og ERTMS systemet. Videre egenlæring av MilkShape3D. lø 30.jan 3 Fortsatte med ErtmsSystem. ErtmsSystem samler alle kjente ErtmsPunkt i en ErtmsPunktSet klasse og finn gjeldende Vperm, Vtarget, Starget og aktuell status. 52

56 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering sø 31.jan 2 Fortsatte med ErtmsSystemet og kobling av info frå ErtmsPunktSet til visuell visning i DMI. Lar nå ERTMS-delen ligge ettersom vi gjennom forprosjektet planla at denne delen ikke kommer før i iterasjon 2. 53

57 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.5 UKE 5 DAG DATO TIMER ARBEID UTFØRT ma 01.feb 5 Videre egenlæring av MilkShape3D. Prøvde å få til figurer som kan brukes som pynt i prosjektet. ti 02.feb 16 Møte: Så på eksempel på JUnit (enhetstesting) og eksempel på Javadoc og autogenerering av Javadoc. on 03.feb 10 Fortsatte oppnøsting av eksisterende materiale og sette dette sammen. Har vindu for infrastruktur og omgivelser gjennom Univer3d og UniversPanel-klassene. Framebehavior for oppdatering ved hver frame. Har også Java-klasse som representerer et spor og noen objekter som signaler og skilt. Sporveksel og kurve ble laget i januar Fant Milkshapetutorial på nettet for å bygge et fly startet på dette. Håper å kunne benytte flyet som pynt langs strekningen vi skal lage samtidig som det er trening i Milkshape. to 04.feb 9 Fortsatte å sette sammen og refaktorere kode fra tidligere. Ser på systemet for bevegelse langs sporet. Har et system med noder der toget forflytter seg frå node til node og interpolerer imellom. Klassen SNode er den sentrale her. Fortsatte med flyet. fr 05.feb 4 Fortsatte å sette sammen og refaktorere kode fra tidligere. lø 06.feb 1 Oppretter vindu for å kontrollere toget sø 07.feb 54

58 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.6 UKE 6 DAG DATO TIMER ARBEID UTFØRT ma 08.feb 11 Fortsetter arbeidet med togkontrollen Ferdig med flyet. ti 09.feb 5 Har fra faget Advanced Java Programming noe materiale med innlesing av informasjon frå XML-filer. Begynner å se på om dette kan brukes til innlesing av informasjon til programmet. Velger å bruke dette systemet som bygger på en JAVA SAXBuilder. on 10.feb 7 Begynner på omgivelsene til strekningen som skal lages. to 11.feb 8 Forsetter på omgivelsene. Det blir enkle omgivelser bestående av grønn plen og noen bokser som store bygninger langs. fr 12.feb 7 Kopierer ut 20 omgivelses-seksjoner, 1km hver for å dekke de 20 km med strekning som skal lages. lø 13.feb sø 14.feb 55

59 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.7 UKE 7 DAG DATO TIMER ARBEID UTFØRT ma 15.feb 7 Oppretter XML klasser til de data som skal leses inn. Elementer som skal være synlige i 3d-verdenen får en XMLklasse som oppretter et objekt av den ordinære klassen under lesing av XML-filen ti 16.feb on 17.feb 7 Prøvde å lage en klasse som leser Milksshape3D objekter inn i Java3D. to 18.feb 7 Forsatte med Milkshape-leser klassen og startet med et lite hjelpeprogram som justerer Milkshape3D-objekter til å følge trasèen i programmet fr 19.feb 8 Fortsatte med traseprogrammet. lø 20.feb sø 21.feb 56

60 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.8 UKE 8 DAG DATO TIMER ARBEID UTFØRT ma 22.feb 7 Etter at innlesing gjennom XML nå er etablert, startet arbeidet med infrastrukturen til den 20 km-strekningen. En del prøving og feiling for å få spor, sporveksler og kurver til å henge sammen og passe oppå omgivelsene som er laget tidligere i februar. ti 23.feb 20 Møte. Diskuterte videre framdrift. Så på arbeid som er gjort. Snakka om klassediagram og UML, om vi trenger dette i dok. Ingen av oss gode i UML. Gav Hasan innføring i hvordan programmet henger sammen så langt. Møte med oppdragsgiver etter iterasjon 1. on 24.feb to 25.feb 6 Starta tankevirksomhet og jobbing med trafikkstyring fr 26.feb 6 ITERASJON 1 AVSLUTTET - Jobbing med trafikkstyring. Utfordringer rundt uttegning av sporkart basert på noder. Ønsker en representasjon av sporene som rette streker på trafikkstyringpanelet. SNodenes punkter følger trasèen og vil dermed svinge. Løsning med å lagre nodepunktet i et ekstra datafelt etter spor-transform, men før trase-transform lø 27.feb 1 Endret tittel i 3D vindu etter tilbakemelding. sø 28.feb 57

61 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.9 UKE 9 DAG DATO TIMER ARBEID UTFØRT ma 01.mar 5 Fortsatte arbeidet med ERTMS fra tjuvstarten i januar. Videre implementering av Circular speed gauge - få denne til å reagere korrekt med farger og hast. Visning i forhold til gjeldande status, Vperm og Vtarget. Justering av ErtmsSystem for å ta hensyn til opptelling av toglengde når Vperm blir større. ti 02.mar 14 Tankevirksomhet rundt logaritmisk avstandsskala område A på DMI. Prøvde å finne formel for antall pixler basert på en avstand on 03.mar 14 Implementering av logaritmisk avstandsskala. DMI område A. to 04.mar 11 La inn panel Eright og klokke. Fortsatte å med 20 kmstrekningen ved å legge inn ERTMS relaterte elementer. Testkjørte på strekningen og fiksa ERTMS system bugs som blei oppdaga under testkjøring. fr 05.mar 7 La inn 2 km med mer forseggjort terreng. Fiksa litt på strekningen ellers. lø 06.mar sø 07.mar 58

62 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.10 UKE 10 DAG DATO TIMER ARBEID UTFØRT ma 08.mar ti 09.mar 16 Møte. Jobbing med trafikkstyringvinduet og funksjonalitet her on 10.mar 8 Jobbing med øvrige områder på ERTMS-skjerm. Disse får mest sannsynlig ingen funksjonalitet med skal vises i DMI. to 11.mar 5 Videre jobbing med øvrige områder på DMI. fr 12.mar 15 Videre jobbing med trafikkstyring Jobbing med prosessrapport lø 13.mar 8 Jobbing med prosessrapport sø 14.mar 8 Jobbing med prosessrapport 59

63 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.11 UKE 11 DAG DATO TIMER ARBEID UTFØRT ma 15.mar 10 Jobbing med prosessrapport Feilretting/justering av bremselengder ved bremseinngripen ti 16.mar 16 Møte med oppdragsgiver etter iterasjon 2 on 17.mar 16 Møte. Gikk igjennom dokumenter som skal leveres ved prosjektslutt. Prosessrapport, produktrapport, testrapport og brukerveiledning. Møte med veileder. to 18.mar fr 19.mar ITERASJON 2 AVSLUTTET lø 20.mar sø 21.mar 60

64 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.12 UKE 12 DAG DATO TIMER ARBEID UTFØRT ma 22.mar 12 La inn fast ERTMS nivå2 og full supervision ved oppstart. La inn symbol for full supervision og nivå 2. Endret tittel på vindu til DMI. Enighet om dette på siste møte. Jobbing med prosessrapport ti 23.mar 12 Laget ErtmsPosisjonBalise. Synlige baliser i spor. Ingen funksjonalitet knytta til. Jobbing med prosessrapport on 24.mar 12 Ertmssystem: Tankevirksomhet rundt statusene OvS, WaS og IntS. Startet implementering to 25.mar 14 Fortsatte implementering status OvS, WaS og IntS. Finner ut at OvS og WaS har akkurat samme visning i DMI. Tar bare med OvS. Startet å se på bremseingripen ved for stor hastighet. Utfordringer rundt retardasjon av tog, symbol for bremseingripen og symbol når brems kan løses. Står flashing frame i B34, men ingen tegning hva det betyr. Må anta implementering av dette. Ble hvit blinkende firkant rundt symbolet. Ack ved å trykke på symbol. fr 26.mar 12 Fortsatt implementering av bremseinngripen. Begynte å tenke på planning area i DMI. Ser at ErtmsPunktSet med sine ErtmsPunkt er den informasjonen som trengs for dette. lø 27.mar sø 28.mar 61

65 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.13 UKE 13 DAG DATO TIMER ARBEID UTFØRT ma 29.mar ti 30.mar 5 Fortsatte implementasjon av planning area. on 31.mar 5 Fikset på trær langs den mer forseggjorte delen av strekningen. Tok vekk de som ble vist feil. to 01.apr fr 02.apr lø 03.apr sø 04.apr 62

66 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.14 UKE 14 DAG DATO TIMER ARBEID UTFØRT ma 05.apr ti 06.apr 8 Etablerte produktrapport. Se på hva vi har av dokumentasjon, hva produktrapporten skal inneholde og hvordan den skal settes sammen on 07.apr 7 Fortsatte implementasjon av planning area. to 08.apr 8 Videre jobbing med produktrapport fr 09.apr 7 Videre jobbing med produktrapport lø 10.apr sø 11.apr 63

67 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.15 UKE 15 DAG DATO TIMER ARBEID UTFØRT ma 12.apr ti 13.apr 16 Møte med oppdragsgiver etter iterasjon 3 on 14.apr to 15.apr fr 16.apr 7 Fikset på marker-skiltet slik at det blir lysere. Økte ambient light på skiltet og i universet. Eksperimenterte med Text2d med tanke på litrering. Har ikke implementert litrering. Fikset på omgivelsene. lø 17.apr 3 Feilsøking på oppdaget feil ved overkjøringssløyfen på dobbelspordelen. Fant feilplassert hastighetspunkt. sø 18.apr 64

68 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.16 UKE 16 DAG DATO TIMER ARBEID UTFØRT ma 19.apr ti 20.apr 8 Startet jobbing med brukerveiledning on 21.apr 15 Møte og møte med veileder: Konkluderer med at det er bra kontroll på programmet. Viktigste nå er dokumentasjonen. Tips til word: innholdsfortegnelse, automatisk avsnittsnummerering, referanser. to 22.apr 7 Endringer i programmet etter tilbakemeldinger. Låsing av skalhastighet, endre retardasjonsverdi og et nytt hastighetsavsnitt på strekningen fr 23.apr lø 24.apr sø 25.apr 2 Jobbing med produktrapport. Hovedsaklig det som går på ERTMS-Systemets oppbygging 65

69 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.17 UKE 17 DAG DATO TIMER ARBEID UTFØRT ma 26.apr 14 Gått igjennom klasser for å sjekke kommentering. Ikke alle er like godt kommentert. Fjernet noen klasser som ikke er i bruk og gjort enkelte endringer i noen. ti 27.apr 3 Fortsatte gjennomgang av klasser for kommentering og litt refaktorering on 28.apr 5 Fortsatte gjennomgang av klasser for kommentering og litt refaktorering to 29.apr 10 Etablerte testrapport. Enige om å bygge den opp som en samling av manuelle enhetstester. Startet fylle inn tester i denne som har blitt gjort underveis. Testene utført etter hvert som de ble lagt inn i rapporten. fr 30.apr 7 Jobbet videre med brukerveiledning lø 01.mai sø 02.mai 66

70 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.18 UKE 18 DAG DATO TIMER ARBEID UTFØRT ma 03.mai 14 Jobbet videre med testrapport og produktrapport ti 04.mai 7 Jobba videre med produktrapport. on 05.mai 14 Jobbing med dokumentasjon, hovedsaklig prosessdokumentasjon og testrapport Fant en feil på visning i DMI. Gikk rett i overspeed-status ved stopp i ett gitt ertmspunkt. to 06.mai 4 Jobbing videre med prosessdokumentasjon fr 07.mai 12 Jobbing med dokumentasjon, hovedsaklig med brukerveiledning lø 08.mai 2 Så på feilen fra onsdag i DMI. Fant feilen. Viste seg at det ble overvåket mot det punktet med lavest vperm, uavhengig om dette faktisk er et retriktivt punkt. Endret slik at det nå er det punktet med lavest vperm av de med høyast status som er gjeldende for visning. sø 09.mai 67

71 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.19 UKE 19 DAG DATO TIMER ARBEID UTFØRT ma 10.mai ti 11.mai on 12.mai 14 Møte. Gikk igjennom dokumentasjon som er laget og gjorde mindre endringer der vi fant det nødvendig. Møte med veileder. Veileder i hovedsak fornøyd. Kom med tilbakemeldinger på rapportene. to 13.mai fr 14.mai 14 Fikset på dokumentasjonen etter tilbakemeldingene fra veileder og ting vi selv har oppdaget som bør endres på. Finpuss på dokumentene med topptekst, bunntekst og andre kosmetiske ting. lø 15.mai 6 Fortsatte retting og finpuss på dokumenter. Så over programmet og kommentarer i programmet. sø 16.mai 68

72 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.20 UKE 20 DAG DATO TIMER ARBEID UTFØRT ma 17.mai ti 18.mai on 19.mai 5 Møte med veileder: Veileder så over dokumentene for siste gang før trykking. Bare noen få enkle endringer nødvending. Setter av 21 og 24 mai for korrekturlesing og 25 mai for trykking av rapporten to 20.mai fr 21.mai 12 Korrekturlesing lø 22.mai sø 23.mai 69

73 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering 8.21 UKE 21 DAG DATO TIMER ARBEID UTFØRT ma 24.mai 12 Korrekturlesing ti 25.mai 12 Korrekturlesing on 26.mai Trykking av prosjektrapporten to 27.mai fr 28.mai lø 29.mai sø 30.mai 70

74 Hovedprosjekt HiO 2010 Prosessrapport ERTMS Driver Interface Simulering REFERANSER 1. [Internett] [Sitert: 27 januar 2010.] 2. QUT - Queensland University of Technology. [Internett] [Sitert: 12 mai 2010.] 3. ERA, ERTMS. [Internett] [Sitert: 14 mai 2010.] Activities/ERTMS. 4. Jernbanemagasinet nr [Internett] [Sitert: 12 mai 2010.] df. 5. Wikipedia, Java. [Internett] [Sitert: 14 mai 2010.] 6. Wikipedia, Eclipse. [Internett] [Sitert: 5 mai 2010.] 7. CUMBALUMSOFT. [Internett] [Sitert: 12 mai 2010.] 8. Wikipedia, Evolutionary Prototyping. [Internett] [Sitert: 14 mai 2010.] 9. Wikipedia, Spiralmodell. [Internett] [Sitert: 14 mai 2010.] Wikipedia, User Centered Design. [Internett] [Sitert: ] Wikipedia, Test Driven Development. [Internett] [Sitert: ] Sommerville. Software Engineering. Harlow, Essex, England : Pearson Education Limited, OPERATIONAL DMI INFORMATION - ERTMS/ETCS Driver Machine Interface. [Internett] [Sitert: 22 april 2010.] ERA, ERTMS current baseline. [Internett] [Sitert: 19 mai 2010.] 71

75

76 ERTMS Driver Interface Simulering Produktrapport

77 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

78 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

79 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

80 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 7.2 Trase.xml TraseVertikal.xml Spor.xml Infra.xml Omg.xml Scenario.xml MilkshapeTraseTransform Ordforklaringer Referanser

81 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

82 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

83 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

84 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

85 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

86 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

87 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

88 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

89 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

90 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

91 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

92 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

93 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

94 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

95 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

96 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

97 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

98 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

99 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

100 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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 ErtmsStopp SNode snode SNodeTog Tog tog SNode SNode neste SNode forrige UniversElement parent 1 JButton TrafikkstyringPanel 1 1 TrafikkstyringFrame Peker til første node(r) FrameBehavior UniversPanel 1 Univers3d 1 1 Figur 23: Oppbygging av systemet under bruk 25

101 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

102 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

103 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

104 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

105 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

106 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

107 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

108 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

109 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

110 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

111 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

112 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

113 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

114 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

115 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

116 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

117 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

118 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

119 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

120 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

121 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

122 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

123 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

124 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

125 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

126 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

127 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

128 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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

129 Hovedprosjekt HiO 2010 Produktrapport ERTMS Driver Interface Simulering 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,

130 ERTMS Driver Interface Simulering Testrapport

131 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering FORORD Denne rapporten inneholder testrapport laget i forbindelse med hovedprosjekt i Bachelorstudium i informasjonsteknologi ved Høgskolen i Oslo, våren Rapporten beskriver testingen av programmet ERTMS Driver Interface Simulering. Rapporten er beregnet for sensor og veileder og for de som eventuelt skal videreutvikle programmet, men kan også leses av andre som skulle finne den interessant. 2

132 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering INNHOLD Forord... 2 Innhold... 3 Beskrivelse av testrapporten Oppstart av programmet Vinduene i programmet som opprettes ved oppstart Innhold i vinduet infrastruktur og omgivelser etter oppstart Innhold i vinduet DMI etter oppstart Innhold i vinduet Togkontroll etter oppstart Innhold i vinduet Trafikkstyring etter oppstart Kjøre toget Kjøre toget ved å øke hastigheten fra 0 til 50 km/h Stoppe toget ved å redusere hastigheten fra 50 til 0 km/h Sporveksel Omlegging av sporveksel til avvik Omlegging av sporveksel til rettspor Kjøring gjennom sporveksler i rettspor Kjøring gjennom sporveksler i avvik Togets startposisjon Togets plassering ved oppstart spornummer Togets plassering ved oppstart spornummer ERTMS og DMI Kjøretillatelse ut i fra rettspor Kjøretillatelse ut i fra avvikespor Kjøring fram mot blokkskillepunkt i stopp

133 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 5.4 Kjøring fram mot punkt med punkt med lavere tillatte hastighet Passering av punkt med høyere tillatte hastighet ERTMS-bremseinngripen i høy hastighet fram mot blokkskillepunkt i stopp ERTMS-bremseinngripen i lav hastighet fram mot blokkskillepunkt i stopp Brukerscenarioer Innledning Brukerscenario Brukerscenario Ordforklaringer Referanser

134 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering BESKRIVELSE AV TESTRAPPORTEN Testene beskrevet i denne rapporten er lagt opp som manuelle enhetstester. For hver test utføres en handling under eventuelle forutsetninger. Ved utførelse av denne handlingen med de gitte forutsetninger forventes et resultat. Dette resultatet er kravet som skal oppfylles ved testen. Dersom dette skjer er testen godkjent. Hver test gis et navn og settes opp i en tabell der parametrene forutsetninger, handling, resultat og godkjent har hver sin rad. Tabellen har også en rad der det kan angis en henvisning til en figur som forbindes med testen. Det deles opp i hovedkategorier for testene slik at hver test tilhører en kategori og nummereres i forhold til dette. Siste del av rapporten inneholder to tester som er lagt opp som brukerscenarioer. Her testes kjøring gjennom strekningen som en helhet. 5

135 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 1 OPPSTART AV PROGRAMMET 1.1 VINDUENE I PROGRAMMET SOM OPPRETTES VED OPPSTART Forutsetninger Utførelsen av testen Forventet resultat (krav) Programmet lagt inn som prosjekt i Eclipse Starter programmet fra Eclipse 4 uavhengige vinduer med følgende navn kommer opp: Instrastruktur og omgivelser DMI Togkontroll Trafikkstyring Godkjent JA Figur henvisning Figur 1 Tabell 1 6

136 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 1.2 INNHOLD I VINDUET INFRASTRUKTUR OG OMGIVELSER ETTER OPPSTART Forutsetninger Scenario.xml Togposisjon: 1110 (spor 0) som er i enden av første stasjon på strekningen Kamera posisjonert i fronten av toget i retning framover 0.7 m til høyre for midten Utførelsen av testen Forventet resultat (krav) Starter programmet fra Eclipse 3D framstilling av infrastruktur og omgivelser foran toget. I denne posisjonen skal det foran toget være to spor, toget skal stå på det høyre med senter litt til høyre for midten av sporet. Det skal være et ERTMS-skilt utenfor hvert spor. De to sporene skal samles i en sporveksel litt lenger fram. Sporet skal gå inn i en høyrekurve. Omgivelsene skal være grønn plen med i alle fall èn synlig firkantet bygning Godkjent JA Figur henvisning Figur 1 Tabell 2 7

137 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 1.3 INNHOLD I VINDUET DMI ETTER OPPSTART Forutsetninger Utførelsen av testen Forventet resultat (krav) Godkjent Starter programmet fra Eclipse Mørkeblå bakgrunn med de ulike områdene som skal være på DMI med hastighetsmåler og den logaritmiske avstandsskalaen i planning area som de mest markerte. Henviser til referansedokumentet (1) kapittel 2, figur 1 og 2 for bilde av DMI. JA Figur henvisning Figur 1 Tabell INNHOLD I VINDUET TOGKONTROLL ETTER OPPSTART Forutsetninger Utførelsen av testen Forventet resultat (krav) Starter programmet fra Eclipse Speedometer med svart bakgrunn. Gul nål for erhastighet fra senter og ut til skala. Rød markør for skalhastighet på hastighetsskala. To knapper: + og Godkjent JA Figur henvisning Figur 1 Tabell 4 8

138 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 1.5 INNHOLD I VINDUET TRAFIKKSTYRING ETTER OPPSTART Forutsetninger Scenario.xml Togposisjon: 1110 (spor 0) som er i enden av første stasjon på strekningen Utførelsen av testen Forventet resultat (krav) Starter programmet fra Eclipse Vindu med stor bredde og lav høyde. Grafisk framstilling av spor i form av streker. Røde/grønne piler i form av små knapper som markerer blokkskiller. Gule piler med tall som marker hastigheter. Hvite loddrette piler i form av små knapper som markerer sporveksler. Toget markert som rød firkant i høyre ende på nederste spor på første stasjon på strekningen. Scrollbar for å navigere langs strekningen. Godkjent JA Figur henvisning Figur 1 Tabell 5 9

139 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering Figur 1: Vinduer ved oppstart 10

140 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 2 KJØRE TOGET 2.1 KJØRE TOGET VED Å ØKE HASTIGHETEN FRA 0 TIL 50 KM/H Forutsetninger Programmet er startet Scenario.xml Togposisjon: 1110 (spor 0) som er i enden av første stasjon på strekningen Utførelsen av testen Trykker på pluss-knapp 10 ganger Forventet resultat (krav) Skalhastighetsmarkør skal flytte seg 5 km/h pr trykk og ende opp på 50 km/t Toget skal akselerere med verdi fastsatt i HastighetKontroll-klassen 0.6 m/s/s fra 0 til 50 km/h. Gul hastighetsmålerpil i Togkontroll og hastighetsmåler i DMI skal bevege seg mot 50 km/h t takt med togets akslerasjon. Toget skal forflytte seg langs sporet i Infrastruktur og omgivelser og langs streken i trafikkstyringvinduet med økende hastighet opp til 50 km/h Godkjent JA Figur henvisning Tabell 6 11

141 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 2.2 STOPPE TOGET VED Å REDUSERE HASTIGHETEN FRA 50 TIL 0 KM/H Forutsetninger Programmet er startet. Toget kjører i 50 km/h Utførelsen av testen Trykker på minus-knapp 10 ganger Forventet resultat (krav) Skalhastighetsmarkør skal flytte seg 5 km/h pr trykk og ende opp på 0 km/t Toget skal retardere med verdi fastsatt i Hastighetskontrollklassen. Denne er satt til 0.9 m/s/s. Retardasjonen er fra 50 til 0 km/t. Settes dette inn i formelen S = v 2 vmål 2 / 2 * retardasjon skal toget stå stille etter ca 107 meter. T = S / V tilsier da at dette skal ta 15.4 sekunder Måling: 15.6 sek Gul hastighetsmålerpil i Togkontroll og hastighetsmåler i DMI skal bevege seg mot 0 km/h i takt med togets retardasjon Toget skal forflytte seg langs sporet i Infrastruktur og omgivelser og langs streken i trafikkstyringvinduet med synkende hastighet ned til stopp. Godkjent JA Figur henvisning Tabell 7 12

142 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 3 SPORVEKSEL 3.1 OMLEGGING AV SPORVEKSEL TIL AVVIK Forutsetninger Programmet er startet. Scenario.xml: Togposisjon 4480 Utførelsen av testen Forventet resultat (krav) Godkjent Trykker på pilknapp som representerer første sporveksel ved stasjon 2 på trafikkstyringpanelet Pilen i pilknappen skal endre fra pil opp til pil ned. Sporvekseltungene i vinduet for omgivelser og infrastruktur skal flytte seg fra kjøring i rettspor til kjøring i avvik. JA Figur henvisning Figur 2 Tabell 8 Figur 2: Før og etter omlegging av sporveksel 13

143 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 3.2 OMLEGGING AV SPORVEKSEL TIL RETTSPOR Forutsetninger Programmet er startet. Scenario.xml: Togposisjon 4480 Sporvekselen er lagt over til avvik Utførelsen av testen Forventet resultat (krav) Godkjent Trykker på pilknapp som representerer første sporveksel ved stasjon 2 på trafikkstyringpanelet Pilen i pilknappen skal endre fra pil ned til pil opp. Sporvekseltungene i vinduet for omgivelser og infrastruktur skal flytte seg fra kjøring i til avvik kjøring i rettspor. JA Figur henvisning Figur 3 Tabell 9 Figur 3: Før og etter omlegging av sporveksel 14

144 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 3.3 KJØRING GJENNOM SPORVEKSLER I RETTSPOR Forutsetninger Programmet er startet. Scenario.xml: Togposisjon: 4480 Utførelsen av testen Forventet resultat (krav) Setter skalhastighet på 80 slik toget begynner å kjøre. Kjører helt til toget er kommet gjennom neste sporveksel på andre siden av stasjonen Toget skal bevege seg gjennom sporvekselen, videre gjennom stasjonen i det venstre sporet og ut av sporvekselen i andre enden. Dette skal også vises på trafikkstyringspanelet ved at den røde firkanten følger det øverste sporet gjennom stasjonen Godkjent JA Figur henvisning Tabell 10 15

145 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 3.4 KJØRING GJENNOM SPORVEKSLER I AVVIK Forutsetninger Programmet er startet. Scenario.xml: Togposisjon: 4480 Utførelsen av testen Trykker på piltastene i begge ender av stasjonen slik at sporvekslene legger seg til kjøring i avvik Setter skalhastighet på 80 slik toget begynner å kjøre. Kjører helt til toget er kommet ut neste sporveksel på andre siden av stasjonen Forventet resultat (krav) Toget skal bevege seg gjennom sporvekselen, videre gjennom stasjonen i det høyre sporet og ut av sporvekselen i andre enden. Dette skal også vises på trafikkstyringspanelet ved at den røde firkanten følger det nederste sporet gjennom stasjonen. Godkjent JA Figur henvisning Tabell 11 16

146 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 4 TOGETS STARTPOSISJON 4.1 TOGETS PLASSERING VED OPPSTART SPORNUMMER 0 Forutsetninger Scenario.xml: Togposisjon: Spornummer: 0 Utførelsen av testen Forventet resultat (krav) Starter programmet fra Eclipse I vinduet for infrastruktur og omgivelser skal toget stå på det høyre sporet på dobbelspordelen et stykke ute på strekningen. I vinduet for trafikkstyring skal den røde firkanten stå på det nederste sporet litt over halvveis langs strekningen Godkjent JA Figur henvisning Tabell 12 17

147 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 4.2 TOGETS PLASSERING VED OPPSTART SPORNUMMER 1 Forutsetninger Scenario.xml: Togposisjon: Spornummer: 1 Utførelsen av testen Forventet resultat (krav) Starter programmet fra Eclipse I vinduet for infrastruktur og omgivelser skal toget stå på det venstre sporet sporet på dobbelspordelen et stykke ute på strekningen. I vinduet for trafikkstrying skal den røde firkanten stå på det øverste sporet litt over halvveis langs strekningen Godkjent JA Figur henvisning Tabell 13 18

148 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 5 ERTMS OG DMI 5.1 KJØRETILLATELSE UT I FRA RETTSPOR Forutsetninger Scenario.xml: Togposisjon: 1130 Spornummer: 0 Her står toget inne på stasjon 1 i rettspor. Største tillatte hastighet er 110 km/h. Utførelsen av testen Trykker på blokkskillepil ut fra spornummer 0, stasjon 1 Forventet resultat (krav) Circular Speed Gauge på DMI skal gå opp til 110 km/h med mørkegrå farge Planning area skal vise lyseblått felt fram til neste blokkskillepunkt i stopp og restriksjonsymbol med 0-markering ved stopp-punktet. Blokkskillepunktet står i posisjon 2250 (se infra.xml). Toget står i pos Stopp-punktet skal da vises i planning area rett over 1000 meter fram. Godkjent JA Figur henvisning Figur 4 Tabell 14 Figur 4: Kjøretillatelse ut fra rettspor 19

149 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 5.2 KJØRETILLATELSE UT I FRA AVVIKESPOR Forutsetninger Scenario.xml: Togposisjon: 1130 Spornummer: 1 Her står toget inne på stasjon 1 i avvikespor. Største tillatte hastighet er 60 km/h Utførelsen av testen Trykker på blokkskillepil ut fra spornummer 1, stasjon 1 Forventet resultat (krav) Circular Speed Gauge på DMI skal gå opp til 60 km/h med mørkegrå farge Planning area skal vise lyseblått felt fram til neste blokkskillepunkt i stopp og restriksjonsymbol med 0-markering ved stopp-punktet. Blokkskillepunktet står i posisjon 2250 (se infra.xml). Toget står i pos Stopp-punktet skal da vises i planning area rett over 1000 meter fram. Godkjent JA Figur henvisning Figur 5 Tabell 15 Figur 5: Kjøretillatelse ut fra avvikespor 20

150 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 5.3 KJØRING FRAM MOT BLOKKSKILLEPUNKT I STOPP Forutsetninger Scenario.xml: Togposisjon: 1130 Spornummer: 0 Utførelsen av testen Setter opp togvei utifra stasjon, forbi første blokkskillepunkt. Kjører toget fra stasjon 1 i 110 km/h fram mot stopp-punktet. Bremser manuelt slik hastigheten følger CSG ned mot 0 km/h Forventet resultat (krav) Circular Speed Gauge på DMI er i utgangspunktet mørkegrå til 110 km/h. Framover mot stopp-punktet skal ERTMS-systemet endre statuser og indikeringer i DMI endres i henhold til det: 1. PreStatus: lydsignal s_info høres og CSG endres til lysegrå 2. IndStatus: lydsignal s_info høres CSG endres til gul, og avstandsmåling mot målpunktet blir synlig grafisk og med tall i felt A (distansepanelet). Grafisk visning er maks 1000 meter. CSG skal jevnlig indikere lavere og lavere tillatte hastighet fram mot stopp-punktet. Restriksjonspunktet i planning area skal jevnlig forflytte seg mot 0 meter og indikere samme avstand som distansepanelet. Godkjent JA Figur henvisning Figur 6 Tabell 16 21

151 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering Figur 6: Kjøring framover mot blokkskille som ikke kan passeres 22

152 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 5.4 KJØRING FRAM MOT PUNKT MED PUNKT MED LAVERE TILLATTE HASTIGHET Forutsetninger Utførelsen av testen Scenario.xml: Togposisjon: 1130 Spornummer: 0 Setter opp togvei ut ifra stasjon 1 og forbi blokkskillepunktene mellom stasjon 1 og stasjon 2 og inn i avvikesporet i stasjon 2. Dette skal gi en hastighetsrestriksjon på 60 km/h gjennom avvikesporet. Kjører toget fra stasjon 1 i 110 km/h fram mot stasjon 2 Bremser manuelt slik hastigheten følger CSG ned mot 60 km/h Forventet resultat (krav) Circular Speed Gauge på DMI er i utgangspunktet mørkegrå til 110 km/h. Framover mot hastighetspunktet-punktet skal ERTMS-systemet endre statuser og indikeringer i DMI endres i henhold til det: 1. PreStatus: lydsignal s_info høres og CSG endres til lysegrå ned til 60 km/h 2. IndStatus: lydsignal s_info høres CSG endres til gul ned til 60 km/t, og avstandsmåling mot målpunktet blir synlig grafisk og med tall i felt A (distansepanelet). Grafisk visning er maks 1000 meter. CSG skal jevnlig indikere lavere og lavere tillatte hastighet fram mot stopp-punktet. Restriksjonspunktet i planning area skal jevnlig forflytte seg mot 0 meter og indikere samme avstand som distansepanelet. Det lyseblå feltet skal etter restriksjonspunktet ha en en bredde tilsvarende 60 km/h i forhold til 110 km/h Når punktet passeres går status tilbake til NoStatus og CSG viser 60 km/h med mørkegrå Godkjent JA Figur henvisning Figur 7 Tabell 17 23

153 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering Figur 7: Kjøring fram mot et punkt med lavere tillatte hastighet 24

154 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 5.5 PASSERING AV PUNKT MED HØYERE TILLATTE HASTIGHET Forutsetninger Scenario.xml: Togposisjon: 1130 Spornummer: 1 Utførelsen av testen Setter opp togvei ut ifra avvikesporet på stasjon 1. Her er maks hastighet 60 km/h, men den øker til 110 km/t etter sporvekselen. Kjører toget ut igjennom sporvekselen. Forventet resultat (krav) Circular Speed Gauge på DMI viser største tillatte hastighet 60 km/h. CSG skal etter at hele toget har kommet gjennom sporvekselen øke tillatte hastighet til 110 km/t Godkjent JA Figur henvisning Tabell 18 25

155 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 5.6 ERTMS-BREMSEINNGRIPEN I HØY HASTIGHET FRAM MOT BLOKKSKILLEPUNKT I STOPP Forutsetninger Scenario.xml: Togposisjon: Spornummer: 0 Toghastighet: 200 Utførelsen av testen Setter opp togvei slik at det kommer et punkt i stopp et stykke lenger framme. Foretar ingen manuell bremsing Forventet resultat (krav) Framover mot hastighetspunktet skal ERTMS-systemet endre statuser og indikeringer i DMI endres i henhold til det: PreS og IndS er som i tidligere tester: OverspeedStatus: lydsignal s_info høres, hastighetsmålerpil blir oransje og CSG får rød indikering av overspeed IntervensionStatus: lydsignal s_info høres, hastighetsmålerpil blir rød, ERTMS-systemet iverksetter bremseingripen, skalhastighet låses på 0 km/h, Bremseinngripen indikeres med symbol i felt C9 Toget skal nå stoppe før blokkskillepunktet passeres Godkjent JA Figur henvisning Figur 8 Tabell 19 26

156 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering Toget har stoppet før blokkskille Bremseinngripen Stopp før blokkskille Figur 8: Bremseinngripen i høy hastighet 27

157 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 5.7 ERTMS-BREMSEINNGRIPEN I LAV HASTIGHET FRAM MOT BLOKKSKILLEPUNKT I STOPP Forutsetninger Scenario.xml: Togposisjon: Spornummer: 0 Toghastighet: 40 Utførelsen av testen Setter opp togvei slik at neste punkt står i stopp Foretar ingen manuell bremsing Forventet resultat (krav) Framover mot hastighetspunktet skal ERTMS-systemet endre statuser og indikeringer i DMI endres i henhold til det: PreS og IndS er som i tidligere tester: OverspeedStatus: lydsignal s_info høres, hastighetsmålerpil blir oransje og CSG får rød indikering av overspeed IntervensionStatus: lydsignal s_info høres, hastighetsmålerpil blir rød, ERTMS-systemet iverksetter bremseingripen, skalhastighet låses på 0 km/h, Bremseinngripen indikeres med symbol i felt C9 Toget skal nå stoppe før blokkskillepunktet passeres Merk: Dersom hastigheten er svært lav når systemet griper inn med brems, vil toget kunne gå forbi punktet. Problemstillingen er diskutert under iterasjon 3 Godkjent JA Figur henvisning Figur 9 Tabell 20 28

158 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering Toget har stoppet før blokkskille Figur 9: Bremseinngripen i lav hastighet 29

159 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering 6 BRUKERSCENARIOER 6.1 INNLEDNING En normal bruk av programmet vil være å plassere toget ved starten av strekningen og kjøre det gjennom til slutten. Underveis kan toget kjøres gjennom forskjellige togveier ved å sette blokkskillepunkter i stopp eller kjør og legge over sporveksler. I denne seksjonen testes to scenarioer der toget kjøres fra starten til slutten av strekningen. 6.2 BRUKERSCENARIO 1 Forutsetninger Scenario.xml: Togposisjon: 1130 Spornummer: 0 Toghastighet: 0 Momenter - Kjøring i avvik ved kryssingsporet på enkeltspordelen - Stopp i blokkskille på dobbelspordelen - Stopp i blokkskille ut fra siste stasjon med bremseinngripen fra systemet Utførelsen av testen 1. Bruker setter opp togvei fra toget og inn i avvik på kryssingsporet. Stopp ut. 2. DMI skal presenter e kjøretillatelse med 110 km/t 3. Bruker kjører toget opp i 110 km/t 4. DMI skal etter hvert som toget nærmer seg kryssingssporet presentere en venthastighet på 60 km/t i CSG og i planning area 5. Bruker bremser ned toget til 60 km/t 6. DMI skal etter hvert som toget nærmer enden av kryssingssporet presentere en venthastighet på 0 km/t i CSG og i planning area 7. Bruker stopper toget før ERTMS-marker skiltet i enden av kryssingsporet. 8. Bruker setter opp togvei videre inn til blokkskillet like før overkjøringssløyfen midt på dobbelspordelen. 9. DMI skal presentere kjøretillatelse på 60 km/t 10. Bruker kjører toget opp i 60 km/t 11. DMI skal når hele toget har kommet ut av sporvekselen presentere kjøretillatelse på 130 km/t 12. Bruker kjører toget opp i 130 km/t 13. DMI skal nå etter hvert nå presentere en venthastighet på 110 km/t. 14. Bruker bremser toget ned i 110 km/t 15. DMI skal når toget nærmer seg dobbelspordelen presentere en 30

160 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering kjøretillatelse på 160 km/t 16. Bruker kjører toget opp i 160 km/t 17. DMI skal når toget har passert overkjøringssporvekslene ved starten av dobbelsporet presentere en kjøretillatelse på 200 km/t 18. Bruker kjører toget opp i 200 km/t 19. DMI skal nå i god avstand til overkjøringssløyfen midt på dobbelsporet en venthastighet på 0 km/t i CSG og i planning area 20. Bruker bremser toget ved å følge CSG ned mot 0 km/t og stoppe det før skiltet. 21. Bruker setter opp togvei fram til det nest-siste blokkskillet på strekningen 22. DMI skal presentere kjøretillatelse på 200 km/t 23. Bruker kjører toget opp i 200 km/t 24. DMI skal nå i god avstand før nest-siste blokkskille presentere en venthastighet på 0 km/t i CSG og i planning area 25. Bruker skal nå ikke foreta seg noe 26. DMI skal presentere overspeed og systemet skal gripe inn og bremse toget slik at det stopper før blokkskillemarkeringen Godkjent JA Tabell BRUKERSCENARIO 2 Forutsetninger Programmet er startet Scenario.xml: Togposisjon: 1130 Spornummer: 0 Toghastighet: 0 Momenter - Kjøring ut på venstre hovedspor på dobbelspordelen - Overkjøring til høyre hovedspor i overkjøringssløyfen - Stopp i blokkskille ut fra siste stasjon Utførelsen av testen 1. Bruker setter opp togvei fra toget, i rettspor gjennom kryssingsstasjonen og inn i avvik til venstre hovedspor på dobbelspordelen. Videre settes opp togvei over til høyrespor gjennom overkjøringssløyfen og fram til nest siste blokkskille. 2. DMI skal presentere kjøretillatelse med 110 km/t 3. Bruker kjører toget opp i 110 km/t 4. DMI skal når toget har passert kryssingsstasjonen presentere 31

161 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering kjøretillatelse med 130 km/t 5. Bruker øker hastighet til 130 km/t 6. DMI skal etter hvert som toget nærmer høyrekurven inn dalføret en venthastighet på 110 km/t i CSG og i planning area 7. Bruker bremser toget ned i 110 km/t 8. DMI skal når toget nærmer seg dobbelspordelen presentere en kjøretillatelse på 160 km/t 9. Bruker øker hastighet mot 160 km/t, men må ned igjen med hastighet før 160 km/t nås 10. DMI skal i tilstrekkelig avstand til sporvekselen ved overgangen til dobbelspor presentere en venthastighet på 80 km/t i CSG og i planning area 11. Bruker bremser toget ned i 80 km/t før sporvekselen 12. DMI skal når toget har passert sporvekselen ved starten av dobbelsporet presentere en kjøretillatelse på 160 km/t 13. Bruker øker hastighet til 160 km/t 14. DMI skal når toget har passert overkjøringssporvekslene ved starten av dobbelsporet presentere en kjøretillatelse på 200 km/t 15. Bruker øker hastighet til 200 km/t 16. DMI skal i tilstrekkelig avstand til overkjøringssløyfen midt på dobbelspordelen presentere en venthastighet på 80 km/t i CSG og i planning area 17. Bruker bremser toget ned i 80 km/t før sporvekselen ved å følge CSG 18. DMI skal når hele toget har passert overkjøringssporvekslene presentere en kjøretillatelse på 200 km/t 19. Bruker kjører toget opp i 200 km/t 20. DMI skal nå i god avstand før nest-siste blokkskille presentere en venthastighet på 0 km/t i CSG og i planning area 21. Bruker bremser toget ved å følge CSG ned mot 0 km/t og stoppe det før skiltet. Godkjent JA Tabell 22 32

162 Hovedprosjekt HiO 2010 Testrapport ERTMS Driver Interface Simulering ORDFORKLARINGER Togvei togvei er den veien toget har fått tillatelse til å kjøre gjennom spor og sporveksler. CSG Circular Speed Gauge, den sirkulære søylen rundt speedometeret i DMI. Venthastighet En hastighet som toget må ned i på ett gitt punkt framover langs strekningen REFERANSER 1. OPERATIONAL DMI INFORMATION - ERTMS/ETCS Driver Machine Interface. [Internett] [Sitert: 22 april 2010.] 33

163

164 ERTMS Driver Interface Simulering Brukermanual

165 Hovedprosjekt HiO 2010 Brukermanual ERTMS Driver Interface Simulering FORORD Denne rapporten inneholder brukermanual laget i forbindelse med Hovedprosjekt i Bachelorstudium i informasjonsteknologi ved Høgskolen i Oslo, våren Rapporten beskriver bruken av ERTMS Driver Interface Simulering. Brukermanualen er laget for sensor, veileder og oppdragsgiver, men kan også leses av dem som skulle finne den interessant. 2

166 Hovedprosjekt HiO 2010 Brukermanual ERTMS Driver Interface Simulering INNHOLD Forord... 2 Innhold Innstallasjon og oppstart Innledning Innstallasjon Konfigurasjon Start av programmet Beskrivelse av vinduene Trafikkstyringpanelet Innledning Sette opp togvei Togkontrollen Innledning Regulere hastigheten til toget Kjøring av toget med ERTMS Kjøretillatelse Tog i bevegelse ERTMS varsel om nedsatt hastighet Første hastighet varsel Andre hastighet varsel ERTMS varsel om økt hastighet Hastighetsøkning på strekningen ERTMS Bremseinngripen Innledning Systemet griper inn og bremser toget

167 Hovedprosjekt HiO 2010 Brukermanual ERTMS Driver Interface Simulering 8 Ordforklaringer Referanser

168 Hovedprosjekt HiO 2010 Brukermanual ERTMS Driver Interface Simulering 1 INNSTALLASJON OG OPPSTART 1.1 INNLEDNING ERTMS Driver Interface Simulering er et system som er laget til opplæring i- og presentasjoner av det nye felleseuropeiske signal- og trafikkstyringssytemet for jernbane, ERTMS. Programmet viser ERTMS sett fra lokførerens synspunkt. Programmet er tenkt brukt av instruktører ved NSB skolen. Programmet består visuelt av fire vinduer. ERTMS- panel Førervindu med utsikt til infrastruktur og 3D landskap Togkontrollpanel Trafikkstyringpanel 1.2 INNSTALLASJON For å kjøre programmet må JAVA og JAVA 3D være installert på maskinen. JAVA kan lastes ned fra: (1) Banen til Java-installasjonens bin mappe må legges inn i systemets miljøvariabel path for å kunne kjøre java-programmer fra hvor som helst i filstrukturen. JAVA 3D kan lastes ned fra: (2) Litt nede på denne siden er det en link til binary downloads. Her kan man velge å laste ned zip-fil eller installasjonsfil. Programmet finnes i mappen ERTMSDIS. Kopier denne mappen fra vedlagte cd eller webside til ønsket plassering på maskinen. 5

169 Hovedprosjekt HiO 2010 Brukermanual ERTMS Driver Interface Simulering 1.3 KONFIGURASJON Fra brukersynspunkt har programmet noen få parametere som er konfigurerbare. Disse finnes i filen scenario.xml som ligger i mappen xml. Taggene i denne filen er i stor grad selvforklarende. Viktige parametre som kan konfigureres er: Togets startposisjon Togets starthastighet Kameraets posisjon og eventuelle tilknytning til toget Siste punkt trenger en liten forklaring. Under både TogXML og KameraXML finnes en tagg NavnXML. Dersom verdien i NavnXML er den samme i TogXML og KameraXML knyttes kameraet til toget. La oss nå anta at VognIndexXML er lik 0. Da vil punktet oppgitt i Punkt3dXML være kameraets posisjon i forhold til midten av den fremste vognen (loket) i toget. Dersom id-nummeret angitt i NavnXML og i Kamera ikke stemmer overens med tilsvarende tagg i toget vil kameraet plasseres statisk i 3d-verdenen. Punkt3dXML angir da en koordinat i 3d-verdenen hvor kameraet står. Merk: Det er ingenting i scenario.xml som trenger å endres på for at programmet skal virke. Ved å bruke innstillingene uforandret vil toget ved oppstart stå ved enden av første stasjon på strekningen i sporindex 0 (rettspor). Toget vil stå stille (0 km/t). Kameraet vil være tilknyttet fronten av toget med posisjon litt til høyre for midten av sporet og vise det lokføreren ser foran seg på strekningen. 6

170 Hovedprosjekt HiO 2010 Brukermanual ERTMS Driver Interface Simulering 1.4 START AV PROGRAMMET Programmet startes med følgende kommando med utgangspunkt i ERTMSDIS-mappen: java classpath bin program.program Figur 1: Oppstart av programmet fra kommandolinje Dette kan kjøres direkte fra kommandolinje eller legges inn i en snarvei på skrivebordet. Ved start av programmet kommer vinduene over hverandre (se Figur 2). Vinduene kan komme rett bak hverandre slik at ett eller flere ikke er synlige. Alle er tilgjengelige på oppgavelinjen nederst. DMI og Togkontroll har fast størrelse. De to andre har justerbar størrelse. Alle kan flyttes og alle kan minimeres. Tilpass/Skaler vinduene til skjermen etter eget ønske (se Figur 3). Det anbefales ikke å legge et annet vindu over nedre del av Infrastruktur og omgivelser vinduet. Gjøres dette reduseres den visuelle fartsopplevelsen når toget beveger seg gjennom omgivelsene. Figur 2: brukergrensesnittet til programmet, de 4 vinduene om hverandre 7

171 Hovedprosjekt HiO 2010 Brukermanual ERTMS Driver Interface Simulering 1.5 BESKRIVELSE AV VINDUENE Figur 3: Vinduene tilpasset/skalert til skjermen 1. Førervindu med infrastruktur/omgivelser 1.1. ERTMS-marker markerer et blokkskille - på hver blokk er det kun tillatt å ha et tog 1.2. jernbaneskinne 2. ERTMS panel 2.1. distansepanel avstand til målpunkt 2.2. hastighetspanel med CSG (Circular Speed Gauge) hastighet, tillatt hastighet og målhastighet 2.3. Planleggingsområde hva som ligger framfor deg så langt du har kjøretillatelse 2.4. Meny funksjonalitet ikke implementert i programmet 2.5. Felt for symboler symboler for ERTMS-nivå2 og bremseinngripen er implementert 2.6. Symbol betyr full supervision 2.7. Tekstfelt mottar meldinger fra trafikkstyringssentral ikke implementert 2.8. Klokke viser simulert tid 3. Trafikkstyring 3.1 Tog 3.2 Sporveksel trykkbar for å legge over sporvekselen 3.3 Blokkskillemarkering trykkbar for å sette kjøretillatelse forbi punktet 4. Togkontroll pluss og minusknapp for å sette skalhastighet 8

172 Hovedprosjekt HiO 2010 Brukermanual ERTMS Driver Interface Simulering 2 TRAFIKKSTYRINGPANELET 2.1 INNLEDNING Det er trafikkstyringssentralen som styrer togtrafikken og gir kjøretillatelser. I dette programmet gjøres dette fra trafikkstyringvinduet. Dette vinduet brukes til å legge om sporveksler og sette opp kjøretillatelser forbi blokkskiller. 2.2 SETTE OPP TOGVEI Prosessen med å legge om sporveksler slik at de ligger riktig for toget og sette opp kjøretillatelser forbi blokkskiller for toget kan sammenfattes i begrepet å sette opp togvei for toget. 1. Legg over sporvekslene slik de ligger slik toget skal kjøre ved å trykke på sporvekselsymbolene. 2. Sett opp kjøretillatelse forbi de blokkskillene toget skal kjøre forbi ved å trykke på blokkskillesymbolene. 2. Sett opp kjøretillatelse 1. Legg over sporveksel Figur 4: Sette opp togvei og legge over sporveksel VIKTIG! Angitte rekkefølge her er essensiell. Feil rekkefølge her kan føre til at sporvekslene ligger feil i forhold til der toget skal kjøre. Det kan dessuten skje at informasjonen som går langs sporet ikke når fram på riktig måte og det som vises i DMI blir feil. 9

173 Hovedprosjekt HiO 2010 Brukermanual ERTMS Driver Interface Simulering 3 TOGKONTROLLEN 3.1 INNLEDNING Togkontrollvinduet benyttes til å regulere hastigheten til toget. Hastigheten reguleres ved å stille inn en skalhastighet eller ønsket hastighet om man vil. Toget vil automatisk regulere hastigheten inn mot denne skalhastigheten. 3.2 REGULERE HASTIGHETEN TIL TOGET Trykk på + knappen for å øke skalhastigheten med 5 km/t Trykk på knappen for å redusere skalhastigheten med 5 km/t 2. Reduser skalhastighet med 5 km/t 2. Øk skalhastighet med 5 km/t Figur 5: Togkontroll 10

174 Hovedprosjekt HiO 2010 Brukermanual ERTMS Driver Interface Simulering 4 KJØRING AV TOGET MED ERTMS 4.1 KJØRETILLATELSE Det er trafikkstyringssentralen som styrer togtrafikken og gir kjøretillatelser. Figur 6 viser gitt kjøretillatelse. På trafikkstyringssentralen ser vi at det er gitt tillatelse ved at blokkskillene er grønne. Sporvekselsymbolene viser hvilke spor toget skal kjøre i. Når trafikkstyringssentralen gir klarsignal for kjøring, dukker informasjonen opp på ERTMS skjermen hos lokfører. Circular Speed Gauge på hastighetspanelet viser hva er som gjeldende tillatte hastighet (i dette tilfellet 110 km/t), denne øker og minker etter hva hastigheten er. Planleggingsområdet til høyre har logaritmisk avstandsskala og viser hva som venter framfor deg. Lenger fremme på den blå søylen er det dukket opp et flagg og et hakk. Dette viser at i underkant av ca 4000 m framme må hastigheten ned. Kjøretillatelse vises ved at CSGsøylen går opp til maks tillatte hastighet Circular Speed Gauge (CSG) Speedometer Planleggingsområde Blokkskiller Tog Blokkskiller Sporveksel Togkontroll Figur 6: Kjøretillatelse gitt fra trafikkstyringssentralen 11

175 Hovedprosjekt HiO 2010 Brukermanual ERTMS Driver Interface Simulering 4.2 TOG I BEVEGELSE Figur 7 viser toget i bevegelse med gjeldende hastighet på 110 km/t. Når toget passerer blokkskiller blir blokken besatt og blokkskillene blir røde. Figur 7: Tog i bevegelse 12

176 Hovedprosjekt HiO 2010 Brukermanual ERTMS Driver Interface Simulering 5 ERTMS VARSEL OM NEDSATT HASTIGHET 5.1 FØRSTE HASTIGHET VARSEL På Figur 8 ser vi at det har dukket opp et varsel på ERTMS systemet. Systemet befinner seg nå i PreStatus. Den mørkegrå søyla har blitt lysgrå mellom 60 og 110 km/t. Dette betyr at gjeldende hastighet er 60 km/t fra et punkt lenger framme. I dette tilfellet er det sporvekselen som ligger til kjøring i avvik som er målpunktet. Dette er en beskjed til lokfører at han etter hvert må begynne å senke hastigheten., Tog Sporveksel Figur 8: Første varsel fra ERTMS systemet om å senke hastigheten til 60 km/t PreStatus (preparation) 13

177 Hovedprosjekt HiO 2010 Brukermanual ERTMS Driver Interface Simulering 5.2 ANDRE HASTIGHET VARSEL På Figur 9 har lokføreren fått advarsel nr. 2. Ut i fra figuren ser vi at det lysegrå området har blitt gult og feltet til venstre viser gjenstående avstand til målpunktet der hastigheten skal være nede i målhastigheten (60 km/t). Gul farge på CSG og hastighetsnål viser at systemet nå er i IndStatus. Nå må toget bremses ved trykke på minus-knappen gjentatte ganger til skalhastigheten når målhastigheten på 60 km/t Betjene minusknappen Tog Sporveksel Figur 9: Varsel nr. 2 - IndStatus (indication) 14

178 Hovedprosjekt HiO 2010 Brukermanual ERTMS Driver Interface Simulering 6 ERTMS VARSEL OM ØKT HASTIGHET 6.1 HASTIGHETSØKNING PÅ STREKNINGEN Langs strekningen ligger punkter med største tillatte hastighet. Hastigheten gjelder til neste punkt. Figur 10 viser kjøring fram mot en hastighetsøkning fra 110 km/t til 130 km/t. En hastighetsøkning gjelder ikke før hele toget har passert punktet som innholder en høyere hastighet. Gjeldende hastighet 110 km/t Ny hastighet 130 km/t som snart passeres Figur 10: Like før hastighetsøkningen 15

179 Hovedprosjekt HiO 2010 Brukermanual ERTMS Driver Interface Simulering I det hele toget har passert punktet for 130 km/t oppdateres CSG i DMI slik største tillatte hastighet nå er 130 km/t. Pluss-knapp kan nå betjenes for å øke togets hastighet. Gjeldende hastighet nå er 130 km/t Hele toget er forbi hastighetspunktet på 130 km/t Betjene pluss knappen Figur 11: Like etter hele toget har passert hastighetsøkningen 7 ERTMS BREMSEINNGRIPEN 7.1 INNLEDNING Når et varsel om lavere hastighet kommer opp i DMI er det førerens ansvar å bremse toget til målhastigheten i tide. Dersom føreren ikke gjør dette vil ERTMS-system gå inn og bremse toget. Dette er ingen autopilot, men en sikkerhetsanordning. Bremsen går på og står på helt til føreren utfører en handlig for å løse den. Den er ikke løsbar før systemet anser det som sikkert å løse bremsen. 16

180 Hovedprosjekt HiO 2010 Brukermanual ERTMS Driver Interface Simulering 7.2 SYSTEMET GRIPER INN OG BREMSER TOGET Avsnittene 5.1 og 5.2 viser varsel om redusert hastighet. Dersom føreren ikke reagerer på disse varslene vil ERTMS-systemet først gå inn i OverSpeed-status. Dette markeres med rødt felt på CSG i forlengelse av den gule. Dersom hastigheten nå overstiger det røde feltet, går systemet over i IntervensionStatus og griper inn med brems. Dette markeres med symbol nede til venstre i DMI (se Figur 12) Bremseinngripen Figur 12: Bremsesystemet koblet inn Når systemet anser det som sikkert å løse bremsen vil dette markers med en hvit blinkende ramme rundt bremsesymbolet. Denne kan da trykkes på og bremsen løser ved at skalhastighet ikke lenger er last på 0 km/t. Hvit blinkende ramme. Bremsen kan løses Figur 13: Bremsen er løsbar 17