ERTMS Driver Interface Simulering. Prosessrapport

Transkript

1 ERTMS Driver Interface Simulering Prosessrapport

2 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

3 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

4 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

5 5.8.2 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?

6 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

7 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

8 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

9 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

10 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

11 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

12 2.3 FREMDRIFTSPLAN Figur 2: Fremdriftsplan 12

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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

24 5.3 SPIRALMODELLEN FOR PROSJEKTET Tid 1. Planlegging Planlegge iterasjon 4 4. Evaluering av kunde 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 1 iterasjon 1 Overordnet kravspek 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

25 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

26 5.4.2 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

27 5.4.3 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

28 5.4.4 RISIKOOVERVÅKING I hver iterasjon ble de definerte risikoene monitorert. Det ble konkludert med en status og tiltak iverksatt om nødvendig. 28

29 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

30 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

31 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

32 5.7.3 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

33 5.7.6 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

34 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

35 5.8.3 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

36 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

37 5.8.6 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

38 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

39 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

40 5.9.3 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

41 5.9.7 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

42 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

43 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

44 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

45 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

46 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

47 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

48 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

49 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

50 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

51 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

52 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

53 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

54 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

55 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

56 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