Forprosjektrapport ERTMS Driver Interface simulering Prosjektets tittel: ERTMS Driver Interface simulering Gruppe medlemmer: Hallgeir Are Olsen s141454, 3IA Hasan Akin s141460, 3IA Oppdragsgiver: NSB skolen Skogliveien 4 3047 Drammen Kontaktperson: Øivind Aarre Mobil: +47 48144376 Veileder, HiO: Alexander Yngling Alexander.Yngling@iu.hio.no Sammendrag Hovedprosjekt data våren 2010, gjennomføres ved Høgskolen i Oslo for NSB skolen. Oppgaven går ut på lage en simulering av hvordan togframføring foregår med ERTMS sett fra lokførerens synspunkt. Det vil bli laget et program med skjermbilder som viser det som skjer på ERTMS skjerm i førerrom, mens toget forflytter seg langs en 3D jernbanestrekning. Oppdragsgiver 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 av lokførere I tillegg til simulatorbasert opplæringsvirksomhet, driver også simulatorsenteret ved NSB skolen 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
Dagens situasjon 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 etterhvert gi et mer felles system for togframføring i hele Europa og i øvrige land som satser på ERTMS systemet. ERTMS står for The European Railway Traffic Management System. Dette er et felleseuropeisk signalerings- og kommunikasjonssystem for jernbane. ETCS + GSM-R = ERTMS ETCS er det nye signalstyringssystemet og GSM-R er det nye kommunikasjonssystemet. Tilsammen utgjør disse ERTMS som er det nye felles signalering og kommunikasjonssystemet for jernbanen i Europa. ERTMS er en standard, en definisjon. Utvikling og produksjon av komponenter og implementering utføres av ulike aktører. ERTMS kommer til å bli implementert i Norge. Første strekning vil få dette systemet i løpet av få år. NSB skolen ønsker å utvide sin kunnskap om systemet samt få utviklet et program som viser hvordan systemet opptrer for lokføreren. Mål og rammebetingelser ERTMS er et komplekst system som kan vises og ses på fra ulike sider. Oppdragiver vil ha et program som simulerer togframføring med ERTMS systemet sett fra lokføreren. 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å prosjektor i klasserom ved hjelp av en bærbar PC. Programmet skal kunne kjøres på Windows plattform. Prosjektet skal leveres 31. mai 2010. 1 www.ertms.com. Sist besøkt 27.01.2010 2
Løsninger Det er ønskelig å lage et skjermbilde med 4 hoveddeler. Disse blir uavhengige vinduer som kan flyttes og minimeres/maximeres, men ikke nødvendigvis endres størrelse på. ERTMS skjerm (Driver interface, DMI), med de mest sentrale funksjonene. Det lokføreren ser foran seg under togframføring (infrastruktur/omgivelser) Enkel signal-/trafikkstyrings funksjonalitet. Enkel betjening av toget (kontrollere hastighet og trekkraft/bremsekraft). Toget kjøres på en strekning gjennom et 3D landskap. Det planlegges å lage 20 km strekning til dette prosjektet. Strekningen blir en fiktiv strekning, men jernbaneteknisk realistisk. Gjennom studiet på HiO har det hovedsakelig blitt undervist i java og eclipse. Derfor er det naturlig å bruke disse også i dette prosjektet. I tillegg trengs det et program for å lage 3D modeller. Gruppen ble enige om å bruke Milkshape3D, da dette er et enkelt og billig alternativ. Teknologier: Utviklingsverktøy: Utviklingsmetodikk: Java/Java3D Eclipse, Milkshape 3D User-Centered Design, Evolutionary protyping 3
Arbeidsmåte Vi ønsker å bruke en utviklingsmetodikk som har elementer fra User Centered Design 2 og Evolutionary Prototyping 3 i prosjektet. I det legger vi at oppdragsgiver jevnlig får presentert det vi har implementert så langt. Oppdragsgiver kommer med tilbakemelding, vi korrigerer og fortsetter med neste implementasjon. Vi har kjørbar kode hele tiden. Med å jobbe på denne måten får oppdragsgiver være med i prosessen hele veien. Sjansen er større for at resultatet blir som ønsket. Der det er hensiktsmessig bør utviklingen i stor grad foregå testdrevet. Dette foregår i prinsippet som en rundgang der en ny funksjonalitet blir definert, tilhørende test blir laget og deretter selve koden. Figur 1 Av praktiske grunner kommer gruppemedlemmene til å jobbe en del hver for seg med tildelte oppgaver. For eksempel kan en skrive programkode mens den andre skriver test. Prosjektet vil også bestå av oppgaver som ikke er direkte programmering. Dette kan f.eks være bygging av 3D modeller eller tegning av symboler og figurer. Det eksisterer også noe kode/eksempler/eksperimentering/prinsipper fra tidligere fag ved HiO/QUT (Queensland University of Technology) som er aktuelt å bruke. Disse faktorene gjør det vanskelig å bruke testdrevet prinsippet slavisk hele tiden. 2 http://en.wikipedia.org/wiki/user-centered_design. Sist besøkt 27.01.2010 3 http://en.wikipedia.org/wiki/software_prototyping#evolutionary_prototyping. Sist besøkt 27.01.2010 4
Analyse av virkninger Oppdragsgiver får et program som kan brukes under opplæring av lokførere i ERTMS samt presentasjoner av ERTMS systemet. Programmet viser på en visuell måte hvordan ERTMS fungerer sett fra lokførerens synspunkt. Som instruktør ved NSB skolen vil gruppemedlem Hallgeir ha stor nytte av å sette seg grundig inn i ERTMS systemet. Gruppe medlemmene vil få erfaring med: Gjennomføring av større prosjekt 3D grafikk Smidige utviklingsteknikker Vedlegg: Fremdriftsplan Arbeidsplan Oslo den 28.01.2010 Representanter for studentgruppen Hallgeir Are Olsen Hasan Akin 5
Fremdriftsplan Gjøremål: Måned: Okt Des Januar Februar Mars April Mai Juni Uke: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Forfase: Statusrapport 30 Prosjektskisse 4 Forprosjekt: Forprosjektrapport 29 Arbeidsplan 29 Fremdriftsplan 29 Egenlaring Utvik. og testing: Iterasjon 1 Iterasjon 2 Iterasjon 3 Iterasjon 4 Sluttfase Dokumentasjon: Prosjektdagbok Prosessrapport Prosjektrapport Levere rapport 31 Avslutning: Forberede pres. Presentasjon 14-17 6
Arbeidsplan Forfase / forprosjekt: Oppgave: Frist / periode: Statusrapport fredag 30. oktober 2009 Prosjektskisse fredag 4. desember 2009 Forprosjekt fredag 29. januar 2010 Egenlæring Teknologier: Java/Java3D Utviklingsverktøy: Eclipse, Milkshape 3D Utviklingsmetodikk: User-Centered Design, Evolutionary protyping 15. 29. januar 2010 Utvikling, testing og implementasjon: Oppgave: Iterasjon 1 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. Frist / periode: 01.02 26.02 / 2010 Start uke 5. Avsluttes i uke 8 Enkelt 3D landskap og enkle omgivelsesobjekter (tre, bygning) Enkle 3D infrastrutur objekter 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 7
har tatt ved HIO/QUT finns det kode/eksempler/prinsipper som kan rebrukes/omskrives til flere av oppgavene i iterasjon 1. Iterasjon 2 I løpet av iterasjon 2 skal de påbegynte delene videreutvikles, samt de delene som mangler skal etableres. ERTMS skjerm Trafikkstyrings vindu Iterasjon 3 I løpet iterasjon 3 skal alle delene videreutvikles og nærme seg ferdig Iterasjon 4 22.02 19.03 / 2010 Start uke 8. Avsluttes uke 11 15.03 16.04 / 2010 Start uke 11. Avsluttes uke 15 12.04 07.05 / 2010 I løpet av itersjon 4 skal alle deler ferdigstilles Start uke 15. Avsluttes uke 18 Sluttfase 10.05 21.05 / 2010 Finpussing Dokumentasjon: Oppgave: Frist / periode: Prosjektdagbok Prosessrapport Daglig, leveres sammen med resten av dokumentasjonen mandag den, 31. mai 2010 Dokumentasjon av prosessen Leveres mandag den, 31. mai 2010 Prosjektrapport Leveres mandag den, 31. mai 2010 Avslutning: Oppgave: Frist / periode: Forberede presentasjon 01. - 13. juni 2010 Presentasjon 14. - 17. juni 2010 8