Simulering av togtrafikk ved produksjonsendring

Torgeir Sønstabø
Simulering av
togtrafikk ved
produksjonsendring
(Simulation of rail traffic in cases of production changes)
Fakultet for Ingeniørvitenskap og Teknologi
Institutt for produksjons- og kvalitetsteknikk
20.12.10

Forord
Denne prosjektoppgaven, kalt “Simulering av togtrafikk ved produksjonsendring”, er
utarbeidet ved Norges teknisk-naturvitenskapelige universitet (NTNU) høsten 2010.
Prosjektoppgaven er et samarbeid mellom NTNU, Norges Statsbaner (NSB) og
SINTEF Teknologi og samfunn, Teknologiledelse. Ansvarlig veileder ved NTNU var
Bjørn Andersen, veileder ved NSB var Sven-Jöran Schrader mens Øivind Stokland
var veileder ved SINTEF.
Jeg vil takke Bjørn Andersen, Sven-Jöran Schrader og Øivind Stokland for verdifull
støtte og gode tilbakemeldinger gjennom utarbeidelsen av oppgaven.

Sammendrag
Denne prosjektoppgaven omhandler bruken av simulering ved produksjonsendring i
jernbanen. Jernbanedrift er et tett integrert, komplekst og dynamisk system som egner
seg til simulering. Det er utført 895 simuleringer fordelt på 10 forskjellige scenarioer.
Oppgaven er avgrenset til Drammens-området, og består av 10 kapitler.
Kapittel 1 inneholder bakgrunnen for oppgaven, oppgavebeskrivelse, avgrensinger og
omfang, mål for oppgaven samt valg av metode og oppgavens oppbygning.
Kapittel 2 gir en innføring i simulering generelt. Kapittelet starter med å definere
begrepet simulering før det gis en kort historisk bakgrunn. Videre vil vanlig/mulig
bruk av simulering bli gjennomgått, og det er sett på fordeler og ulemper med
simulering.
Kapittel 3 tar for seg simulering i jernbanen. Det vil først bli gitt en kort innføring i
vanskelighetene ved å simulere jernbanedrift før det blir sett på fordelene med
simulering. Videre vil det bli gitt en innføring i forskjellige simuleringsmetoder og
simuleringsprogrammer før kapittelet blir avsluttet med et case-studie.
Kapittel 4 introduserer en metodikk for simuleringsprosesser. Metoden består av syv
steg, hvorav fire av stegene er relevante i denne oppgaven. De fire stegene er:
konstruering av ruteplan og innhenting av operasjonell data, kalibrering og validering,
simulere drift, og evaluering. De relevante stegene av metoden blir brukt senere i
oppgaven.
Kapittel 5 introduserer simuleringsverktøyet OpenTrack. Her blir det gitt en kortfattet
innføring i oppbygningen til OpenTrack, og hvordan programmet fungerer.
Kapittel 6 gir en innføring i Drammens-området. Kapittelet gir en forklaring av
området og problemene som eksisterer der.
Kapittel 7 tar for seg første steg av metoden som ble introdusert i kapittel 4,
konstruere ruteplan og innhenting av operasjonelle data. Det blir evaluert om
ruteplanen for 2012 er konfliktfri, før det blir gitt en forklaring på hvordan
operasjonelle data ble innhentet fra NSBs avviksregister, ANNA.
Kapittel 8 er steg to av metoden fra kapittel 4. I dette kapittelet blir det forklart
hvordan NSB kalibrerte OpenTrack-modellen for Jærbanen, og det er deretter validert
statistisk inndata på to forskjellige måter. Første metode er validering av statisk
inndata hentet fra ANNA. Andre metode er validering av en innebygget funksjon i
OpenTrack som lar brukeren definere startforsinkelse på bakgrunn av togkategorier.
Kapittel 9 tilsvarer steg 3 i metoden fra kapittel 4. Togtrafikken er simulert for å
undersøke robustheten til ruteplanen for 2012. I tillegg er det gjennomført flere
simuleringer for å undersøke forskjellige scenarioer for å bedre punktligheten og
robustheten til ruteplanen.
1

Kapittel 10 inneholder en evaluering av simuleringene utført i prosjektet. Det er gitt
anbefalinger for videre arbeid samt feilkilder fra simuleringsarbeidet. Til slutt er
måloppnåelsen evaluert.
2

Ordforklaring
Ordforklaringene er hentet fra Svingheim (2006).
Baliser: Anordning med reflektorer som festes på svillene ved signalanlegg, og som
benyttes til å angi togenes posisjon og signalbeskjed til lokomotivet.
Blokkpost: Skillet mellom to blokkstrekninger.
Blokkstrekning: En sporstrekning der det til enhver tid bare kan befinne seg ett tog
av gangen.
Hovedsignal: Signal som gir beskjed om det er klart for kjøring inn på neste
blokkstrekning.
Kipptog: Et lite skiftelokomotiv, som brukes til å sette sammen og dele godstog.
Motorvognsett: Tog som består av motorvogn og styrevogn, eventuelt med
mellomvogner.
Samtidig innkjør: Signalsystem som gjør det mulig for to tog i motsatt retning å
kjøre samtidig inn på hvert sitt spor på en stasjon.
Togekspeditør (Txp): Person på stasjon som har ansvar for å ivareta nødvendig
sikkerhet i togframføring på og til/gjennom stasjonen. Har to cm bredt rødt bånd rundt
uniformslua.
Togleder: Fjernstyringsoperatør som overvåker og har ansvar for togframføring fra et
kontrollrom.
3

Innhold
1 Innledning ............................................................................................................... 9
1.1 Bakgrunn ......................................................................................................... 9
1.2 Problemstilling ................................................................................................ 9
1.3 Avgrensing og omfang .................................................................................... 9
1.4 Mål ................................................................................................................ 10
1.4.1 Effektmål: .............................................................................................. 10
1.4.2 Resultatmål: ........................................................................................... 11
1.4.3 Delmål .................................................................................................... 11
1.5 Oppgavens oppbygning ................................................................................. 11
1.6 Metode ........................................................................................................... 14
1.6.1 Kvantitative metoder:............................................................................. 15
1.6.2 Kvalitative metoder:............................................................................... 15
1.6.3 Kombinasjon av kvantitative og kvalitative metoder: ........................... 15
1.6.4 Valg av metode ...................................................................................... 16
1.6.5 Feilkilder knyttet til metodevalg ............................................................ 16
1.7 Anskaffelse av data ....................................................................................... 17
1.7.1 Foreliggende data ................................................................................... 17
1.7.2 Innsamling av data ................................................................................. 17
Del 1 ............................................................................................................................. 19
2 Innføring i simulering ........................................................................................... 19
2.1 Hva er simulering .......................................................................................... 19
2.2 Historie om simulering .................................................................................. 19
2.3 Vanlig/mulig bruk av simulering .................................................................. 20
2.4 Fordeler og ulemper ved simulering ............................................................. 21
3 Bruk av simulering i jernbane .............................................................................. 24
3.1 Bakgrunn ....................................................................................................... 24
3.1.1 Simulering i jernbane ............................................................................. 24
3.1.2 Fordeler med simulering i jernbane ....................................................... 25
3.1.3 Simuleringsmetoder ............................................................................... 25
3.1.4 Simuleringsprogrammer ........................................................................ 26
3.2 Case-studie: Italiensk jernbane...................................................................... 28
3.2.1 Hvorfor dette caset ................................................................................. 28
4

3.2.2 Introduksjon av caset ............................................................................. 28
3.2.3 Bruk av simulering ................................................................................. 28
3.2.4 Konklusjon ............................................................................................. 30
Del 2 ............................................................................................................................. 31
4 Metodikk for simuleringsprosesser ...................................................................... 31
4.1 Konstruere ruteplan ...................................................................................... 34
4.1.1 Definisjon av ruteplan ............................................................................ 34
4.1.2 Definisjon av robusthet og robust ruteplan ............................................ 34
4.2 Anskaffing og evaluering av statistisk inndata i modellen ........................... 35
4.2.1 Forsinkelse ............................................................................................. 35
4.2.2 Anskaffelse av data ................................................................................ 36
4.2.3 Evaluering av statistisk inndata ............................................................. 37
4.3 Kalibrering .................................................................................................... 39
4.4 Simulere drift................................................................................................. 41
4.5 Analyse av resultater ..................................................................................... 41
Del 3 ............................................................................................................................. 43
5 OpenTrack ............................................................................................................ 43
5.1 Inndata ........................................................................................................... 44
5.1.1 Rullende materiell .................................................................................. 44
5.1.2 Infrastruktur ........................................................................................... 45
5.1.3 Ruteplan ................................................................................................. 46
5.2 Simulering ..................................................................................................... 46
5.3 Output ............................................................................................................ 47
6 Drammens-området .............................................................................................. 48
6.1 Drammen stasjon ........................................................................................... 51
6.2 Sundland ........................................................................................................ 52
6.3 Holmen sidespor ............................................................................................ 54
6.4 Brakerøya sidespor ........................................................................................ 54
Del 4 ............................................................................................................................. 56
7 Konstruering av ruteplan og forberedelse av operasjonelle data .......................... 56
7.1 Konstruere ruteplan ....................................................................................... 56
7.2 Forberedelse av operasjonelle data ............................................................... 58
8 Kalibrering og validering av OpenTrack modell .................................................. 60
5

8.1 Hvordan NSB kalibrerte modellen ................................................................ 60
8.1.1 Bakgrunn ................................................................................................ 60
8.1.2 Kalibrering av Jærbanen ........................................................................ 60
8.1.3 Kalibrering av OpenTrack modell for prosjektoppgaven ...................... 62
8.2 Validering av statistisk inndata fra ANNA ................................................... 62
8.2.1 Persontog................................................................................................ 62
8.2.2 Godstog og kipptog ................................................................................ 69
9 Simulering av Drammens-området ....................................................................... 73
9.1 Introduksjon .................................................................................................. 73
9.2 Robusthetsvurdering av Drammens-området ................................................ 76
9.3 Effekt av kipptogkjøring: .............................................................................. 80
9.4 Sensitivitetsanalyse ....................................................................................... 84
9.5 Hvem bør vende hvor? .................................................................................. 89
10 Konklusjon ........................................................................................................ 91
10.1 Konklusjoner basert på simuleringsarbeid ................................................ 91
10.2 Feilkilder .................................................................................................... 92
10.3 Måloppnåelse ............................................................................................. 92
Referanser .................................................................................................................... 94
Vedlegg ........................................................................................................................ 97
Vedlegg A: Aktuelle ruteleier for kipptog, godstog og fjerntog.
Vedlegg B: Forstudierapport
Vedlegg C: Statusrapport per 18.10.2010
6

Figurliste
Figur 1 Oppgavens oppbygning ................................................................................... 14
Figur 2 Anskaffelse av data ......................................................................................... 18
Figur 3 Simuleringsstruktur (Astengo et al., 2000) ..................................................... 29
Figur 4 Arbeidsforløp for en simuleringsprosess (Landex & Nielsen, 2006) .............. 31
Figur 5 Seven-Step-Model (Radtke, 2006) .................................................................. 33
Figur 6 Grafisk ruteplan mellom Asker-Drammen 06:00-07:00 (Jernbaneverket,
2010a) .......................................................................................................................... 34
Figur 7 Role of theoretical probability distributions in simulations (Chung, 2004) .... 38
Figur 8 Working scheme (Lindfeldt, 2010) ................................................................. 39
Figur 9 Kalibreringsskjema (Lindfeldt & Sipilä, 2009)............................................... 40
Figur 10 Oppbygning av OpenTrack (Huerlimann & Nash, 2010) ............................. 43
Figur 11 Edge og Vertices (Huerlimann & Nash, 2010) ............................................. 45
Figur 12 Kart over Drammens-området (Finn.no AS, 2010)....................................... 48
Figur 13 OpenTrack modell ......................................................................................... 49
Figur 14 Drammens-området i OpenTrack .................................................................. 50
Figur 15 Drammen stasjon med sidespor (Jernbaneverket, 2010b) ............................. 51
Figur 16 Spor på Drammen stasjon (Jernbaneverket, 2010b) ..................................... 51
Figur 17 Drammen stasjon i OpenTrack (spor 1 er nærmest stasjonshuset) ............... 52
Figur 18 Sundland skiftestasjon (Jernbaneverket, 2010b) ........................................... 53
Figur 19 Sundland & Sundhaugen i OpenTrack .......................................................... 54
Figur 20 Holmen stasjon i OpenTrack ......................................................................... 54
Figur 21 Brakerøya sidespor i OpenTrack ................................................................... 55
Figur 22 Toggraf mellom Kobbervik og Brakerøya i perioden 07:30 – 08:30 ............ 57
Figur 23 Kumulativ forsinkelse ved endestasjon for alle tog ...................................... 58
Figur 24 Kumulativ forsinkelsesfordeling ved stasjoner for Jærbanen (SMA, 2010) . 61
Figur 25 Forsinkelsesfordeling OpenTrack & ANNA for 5xx-tog ved Eriksrud i
perioden 11-14 ............................................................................................................. 63
Figur 26 Forsinkelsesfordeling OpenTrack & ANNA for Fjerntog ved Daler i
perioden Ettermiddag ................................................................................................... 63
Figur 27 Årsak til forkastning 1 ................................................................................... 67
Figur 28 Årsak til forkastning 2 ................................................................................... 68
Figur 29 Årsak til forkastning 3 ................................................................................... 68
Figur 30 Årsak til forkastning 4 ................................................................................... 68
Figur 31 Initial Delay - OpenTrack ............................................................................. 70
Figur 32 Train Categories - OpenTrack ....................................................................... 70
Figur 33 Kumulativ forsinkelsesfordeling – Robusthetsvurdering av Drammensområdet
........................................................................................................................ 77
Figur 34 Kumulativ forsinkelsesfordeling – Effekt av kipptog ................................... 83
Figur 35 Endring i punktlighet for ulike forsinkelsesfordelinger ................................ 85
Figur 36 Endring i forsinkelsestimer for ulike forsinkelsesfordelinger ....................... 86
Figur 37 Frekvens av forsinkelsesintervaller ............................................................... 87
Figur 38 Kumulativ forsinkelsesfordeling - Sensitivitetsanalyse ................................ 88
7

Figur 39 Kumulativ forsinkelsesfordeling - Hvem bør vende hvor ............................. 90
Tabelliste
Tabell 1 Metodevalg .................................................................................................... 16
Tabell 2 Test for homogenitet - 5xx-tog ved Eriksrud i perioden 11-14 ..................... 64
Tabell 3 Test for homogenitet - 5xx-tog ved Eriksrud i perioden 11-14 med forventet
frekvens ........................................................................................................................ 65
Tabell 4 Resultat av test for homogenitet .................................................................... 66
Tabell 5 Resultat av simulering for kipptog ................................................................ 72
Tabell 6 Resultat av simulering for godstog ................................................................ 72
Tabell 7 Simuleringsoversikt, hvor √ betyr at hendelsen er brukt. .............................. 75
Tabell 8 Tilleggsforsinkelse ......................................................................................... 78
Tabell 9 Prosentvis tilleggsforsinkelse etter retning .................................................... 79
Tabell 10 Kumulativ forsinkelse ved endestasjon for alle tog ved forskjellige
scenarioer ..................................................................................................................... 82
Tabell 11 Prosentvis antall tog i rute ........................................................................... 84
Tabell 12 Forskjell i punktlighet og forsinkelsestimer for ulike forsinkelsesfordelinger
...................................................................................................................................... 85
8

1 Innledning
NSB har på bakgrunn av trafikktallene fra 2005 estimert at trafikken vil øke med over
30 % på flere strekninger. I desember 2012 skal Norges Statsbaner (NSB) derfor
innføre en ny grunnrutemodell for østlandsområdet som utnytter kapasiteten som er
bygget ut gjennom de siste årene (Bårdstu, 2008).
Rapporten omhandler Drammens-området som er en viktig del av den nye
grunnrutemodellen og vurderer om togtrafikken kommer til å fungere tilfredsstillende
etter implementering av den nye grunnrutemodellen.
Rapportens første kapittel tar for seg bakgrunn, problemstilling, avgrensing og
omfang samt mål, oppgavens oppbygning og metodebruk.
1.1 Bakgrunn
Jernbanedrift er et tett integrert og komplekst system, som egner seg godt til
simulering. Jernbanesimulering brukes til robusthetsvurderinger av fremtidig
togproduksjon, spesielt rutetabellen. NSB har derfor gått til anskaffelse av
simuleringsverktøyet OpenTrack for å undersøke robustheten til den nye
grunnrutemodellen. Oppgaven vil inkludere bruk av OpenTrack for å se på
trafikkavviklingen i Drammens-området.
Oppgaven er gjennomført ved Norges Teknisk-Naturvitenskapelige Universitet
(NTNU) i samarbeid med NSB og SINTEF Teknologi & Samfunn.
1.2 Problemstilling
I forbindelse med den nye grunnrutemodellen skal det undersøkes om togtrafikken for
Drammens-området kommer til å fungere tilfredsstillende etter planendringen. Dette
gjøres gjennom en robusthetsvurdering av den nye ruteplanen.
Arbeidet består av følgende punkter:
- Gjennomføre et litteraturstudie for bruk av simuleringsverktøy som verktøy
ved robusthetsvurdering ved omlegging i jernbane- og transportsektoren
- Beskrive vanlig/mulig bruk av simuleringsverktøy
- Beskrive metodikk for gjennomføring av robusthetsanalyser ved simulering av
nye ruteplaner i jernbanen.
- Vurder statistiske inndata i modellen
- Vurder metoder for evaluering av output, datakvalitet, tolkning/verifisering av
resultater
- Gjennomføre en simulering av togtrafikken i Drammens-området, og
identifisere problemer ved planlagt løsning
1.3 Avgrensing og omfang
Ruteplanen som skal implementeres i 2012 gjelder for hele østlandsområdet, men for
denne oppgaven fokuseres det kun på Drammens-området. Omfanget med oppgaven
ville blitt for omfattende dersom hele østlandsområdet skulle vurderes, og Drammens-
9

området er som tidligere nevnt kritisk for implementering for den nye ruteplanen.
Avgrensing av modellen blir forklart i oppgaven der hvor det er relevant.
Dette prosjektet teller 15 studiepoeng av totalt 30 for et semester. Dette betyr en
arbeidsbelastning på 24 timer i uken. Prosjektoppgaven ble utlevert 23.8.2010 og
sluttdato er 21.12.2010. Prosjektets varighet er på 17 uker, med estimert 24 timer i
uken tilsvarer det 408 timer totalt. I tillegg til prosjektoppgaven er det utarbeidet en
forstudierapport og en statusrapport.
1.4 Mål
I følge Rolstadås (2006) kan ofte mislykkede prosjekter spores tilbake til upresise
mål. Det er derfor definert hovedmål, effektmål, resultatmål og delmål for oppgaven.
Rolstadås (2006, s.44) sier at “mål må være konkrete og etterprøvbare hvis vi skal
være i stand til å utøve god prosjektstyring”. Wysocki (2007) definerer kriterier for et
mål som SMART.
Spesifikk – være spesifikk i å oppnå formålet
Målbart – Etablere målbare indikatorer
Ansvarlig – Må være en person som er ansvarlig for fullførelse
Realistisk – Erklære hva som realistisk er mulig å oppnå med tilgjengelige ressurser
Tid – Erklære når formålet kan bli nådd, altså varigheten.
Interessenter for denne oppgaven er NTNU, NSB, SINTEF og forfatter.
Hovedmålet for prosjektoppgaven er: å levere en rapport som har nytteverdi både for
NTNU, NSB og SINTEF innen 21.12.2010.
For å definere nytteverdien for de forskjellige interessentene er det også definert
resultatmål og effektmål for oppgaven.
Resultatmål er konkrete mål for prosjektet. Resultatmålene definerer hva som skal
oppnås ved hjelp av prosjektoppgaven. Effektmål er de mål som settes for bruk av
prosjektets resultater, for eksempel bruk av de anlegg som er ferdigstilt (Rolstadås,
2006).
1.4.1 Effektmål:
For interessenter:
NSB:
- Økt kunnskap og kvalitet for ruteplan 2012 for Drammens-området
- Forbedring av nåværende prosedyrer ved implementering av ny ruteplan
- Nye metoder for evaluering av output og tolkning/verifisering av resultater
10

NTNU & SINTEF
- Få en innføring i bruken av simulering generelt, og jernbane spesielt
For forfatter:
- Økt forståelse for prosjektstyring og rapportskriving
- Bedre innsikt i jernbanedrift, spesielt robusthetsvurderinger av ruteplan
- God kunnskap om simuleringsverktøyet OpenTrack
1.4.2 Resultatmål:
For interessenter:
NSB:
- Vurdering om togtrafikken kommer til å fungere tilfredsstillende etter en
planendring.
- Evaluering av konfliktfri ruteplan
- Vurdering av statistisk inndata
- Undersøke robustheten til Drammens-området
NTNU & SINTEF
- Skape kunnskap gjennom oppgaveskriving
For forfatter:
- Få en oversikt over litteratur og informasjon angående simulering, med
hovedfokus på simulering innenfor jernbane
1.4.3 Delmål
1 Skrive forstudierapport
2 Gjennomføre litteraturstudie
3 Skrive statusrapport
4 Gjennomføre simulering
5 Vurdering av simuleringsoutput
6 Ferdigstilling av oppgave
1.5 Oppgavens oppbygning
Oppgaven er delt inn i 4 deler med totalt 10 kapitler. Det vil først bli gitt en
gjennomgang av hvert kapittel før det blir gitt en strukturert oppbygning av oppgaven.
Kapittel 1:
Kapittel 1 inneholder en innledning til oppgaven. Bakgrunnen for oppgaven,
oppgavebeskrivelse, avgrensinger og omfang, mål for oppgaven samt valg av metode
og oppgavens oppbygning og innhold blir vurdert.
11

Del 1
Del 1 består av kapittel 2 og 3. Del 1 skal gi en innføring i bruken av
simuleringsverktøy generelt og i jernbanen spesielt.
Kapittel 2 Innføring i simulering
Kapittel 2 gir en innføring i simulering generelt. Her defineres begrepet simulering og
det gis en kort historisk bakgrunn. Videre vil vanlig/mulig bruk av simulering bli
gjennomgått for å se på fordeler og ulemper med simulering.
Kapittel 3 Bruk av simulering i jernbane
Kapittel 2 tar for seg simulering generelt, mens kapittel 3 tar for seg simulering i
jernbanen. Det vil først bli gitt en kort innføring i vanskelighetene ved å simulere
jernbanedrift før det blir sett på fordelene med simulering. Videre blir det gitt en
innføring i forskjellige simuleringsmetoder og simuleringsprogrammer før kapittelet
blir avsluttet med et case-studie.
Del 2
Del 2 er en metodedel som gir en metode for utførelse av et simuleringsprosjekt.
Metoden består av syv steg, hvorav fire er relevante for utførelsen av denne
oppgaven. Metoden som blir introdusert i Del 2 brukes i Del 4
Kapittel 4 Metodikk for simuleringsprosesser
Kapittel 4 tar for seg metodebruken ved simulering i jernbane. Det vil først bli gitt en
altomfattende metode for arbeid med mikroskopisk simulering, deretter gjennomgås
de relevante stegene for denne oppgaven.
Del 3
Del 3 består av kapittel 5 og 6. Her introduseres simuleringsverktøyet OpenTrack som
brukes i oppgaven og det gis en innføring i Drammens-området. Del 3 gir en
innføring i programmet som brukes for å løse problemet ved Drammens-området og
fungerer som en bakgrunn for del 4.
Kapittel 5 OpenTrack
Kapittel 5 gir en innføring i simuleringsverktøyet OpenTrack. Det vil bli forklart
hvordan OpenTrack er bygd opp og hvordan programmet fungerer. Det vil også bli
forklart hva som er endret i NSB sine originalfiler for denne oppgaven.
Kapittel 6 Drammens-området
Kapittel 6 gir en innføring i Drammens-området med de forskjellige stasjonene og
vanskelighetene som eksisterer der.
12

Del 4
Del 4 er simuleringsdelen. Her brukes metoden som ble introdusert i kapittel 4 og
informasjonen fra del 3.
Kapittel 7 Konstruering av ruteplan og innhenting av operasjonelle data
Kapittel 7 er første del av metoden som ble forklart i kapittel 4. Den tar for seg
konstruering av ruteplan og innhenting av operasjonelle data som senere vil bli
validert i kapittel 8.
Kapittel 8 Kalibrering og validering av OpenTrack modell
Kapittel 8 begynner med en forklaring av hvordan NSB kalibrerte OpenTrackmodellen
for Jærbanen, og tar deretter for seg hvordan simuleringen ble brukt for å
vurdere statistisk input i modellen.
Kapittel 9 Robusthetsvurdering av Drammens-området
I dette kapittelet gjennomføres simuleringer for å undersøke robustheten til
Drammens-området.
Kapittel 10 Konklusjon
Kapittel 10 inneholder rapportens konklusjon, med anbefalinger for videre arbeid
samt feilkilder. Til slutt er måloppnåelse evaluert.
Under er en skjematisk figur for oppbygningen av oppgaven.
13

Del 3
Kap 5
Kap 6
Figur 1 Oppgavens oppbygning
Innledning
Del 1
Kap 2
Kap 3
Del 2
Kap 4
Del 4
Kap 7
Kap 8
Kap 9
Konklusjon
1.6 Metode
Valg av forskningsmetode/-metodikk er viktig for å oppnå et godt resultat og går ut på
gjennomføringen av datainnsamling og analyse. Som regel avgjøres metodevalget på
bakgrunn av problemstillingen. Typiske forskningsmetodikker er
survey/spørreundersøkelse, simulering/modellering, casestudier og aksjonsforskning
(Romsdal, 2010).
Det er vanlig å skille mellom kvantitative og kvalitative metoder. En forklaring av
kvantitative og kvalitative metoder er inkludert, og en kombinasjon av metodene
diskuteres. Til slutt blir det angitt hvilken metode som ble brukt i denne
prosjektoppgaven.
14

1.6.1 Kvantitative metoder:
I denne metoden granskes og testes konseptet gjennom klare spesifikasjoner av
indikatorer (variabler) som er observerbare, konkrete og klart definerte. Testing av
årsakssammenheng mellom variablene er oppnådd gjennom kontrollerte målinger,
ved hjelp av nedlagte prosedyrer og protokoller. Derfor er resultatet av slik forskning
evaluert i henhold til validiteten av prosessen av forskningen og vil ofte være støttet
av resultatene, for eksempel ved hjelp av et signifikansnivå. Evnen til å gjenskape, og
dermed validere, kvantitativ forskning er sett på som en kritisk indikator av
validiteten av forskningen. Kvantitative metoder kan bli sett på som en metode som i
bunn og grunn innlemmer en prosess av observasjoner, med datasamling gjennom for
eksempel laboratorieeksperimenter eller strukturert undersøkelse (Croom, 2009).
1.6.2 Kvalitative metoder:
Kvalitative metoder er, i motsetning til kvantitative metoder, for å sette det på spissen
mer interessert i konstruktivisme, tolkning og oppfatning enn med identifisering av en
rasjonell, objektiv sannhet. Fokuset er en sosialt konstruert natur av virkeligheten.
Kvalitative metoder kjenner igjen og forsøker å redegjøre for betydningen av
tolkning, innsikt og interaksjon i prosessen av definering, samling, og analysering av
forskningsbevis (Croom, 2009).
1.6.3 Kombinasjon av kvantitative og kvalitative metoder:
Som regel deles metode opp i to deler, kvalitative og kvantitative metoder. Men
(Croom, 2009), Bell (2005) og Holme & Solvang (1996) hevder at det ikke er noe
absolutt skille mellom de to metodene og at metodene prinsipielt sett heller ikke står i
et konkurranseforhold til hverandre. Det kan ofte med en fordel kombineres
kvalitative og kvantitative elementer innenfor én og samme undersøkelse.
Videre skriver Holme & Solvang (1996) at den grunnleggende likheten mellom disse
to metodesystemene er at de har et felles formål. Både den kvalitative og den
kvantitative tilnærmingsmåten har som mål å bidra til en bedre forståelse av det
samfunnet vi lever i, og hvordan enkeltmennesker, grupper og institusjoner handler og
samhandler innenfor dette.
Den største forskjellen på kvalitative og kvantitative metoder er det faktum at det i
kvantitativ metode omformes data til tall og mengdestørrelser. Ut fra det
gjennomføres deretter statistiske analyser. Innenfor kvalitative metoder er det
forskerens forståelse eller tolkning av informasjon som står i forgrunnen, for
eksempel tolkning av meningsrammer, motiver, sosiale prosesser eller sammenhenger
(Holme & Solvang, 1996).
Grønmo (1982, referert til i Holme & Solvang, 1996, s.82-83) anbefaler fire
forskjellige strategier for å kombinere kvalitative og kvantitative metoder:
- Kvalitative undersøkelser som forberedelse til kvantitative undersøkelser
- Kvalitative undersøkelser som oppfølging av kvantitative undersøkelser
15

- Parallell utnytting av kvalitative og kvantitative tilnærminger under både
datainnsamling og analyse
- Innsamling av kvalitative data som kvantifiseres under analysen
1.6.4 Valg av metode
Som forklart i 1.5 er oppgaven delt opp i 4 deler med 9 kapitler. Valg av metode vil
avhenge av problemstillingen for hver del og i hvert kapittel. Det vil brukes en
kombinasjon av både kvalitative og kvantitative undersøkelser hvor oppbygningen
tilsvarer den første strategien fra Grønmo (1982, referert til i Holme & Solvang, s.82-
83) “Kvalitative undersøkelser som forberedelse til kvantitative undersøkelser”.
Bruken av kvalitative undersøkelser vil i hovedsak bli benyttet i teorikapitlene som en
metode for å samle informasjon. Som metode for innsamling av informasjon er det
brukt søk etter litteratur gjennom NTNUs biblioteksdatabase og samtaler med
veiledere.
Kvantitative metoder er i hovedsak benyttet i simuleringsdelen, del 4, gjennom bruk
av simuleringsprogrammet OpenTrack og statistiske utregninger.
Under følger et detaljert skjema som forklarer hvilken metode som er brukt i hvert
kapittel.
Kapittel Metode
1 Kvalitativ
2 Kvalitativ
3 Kvalitativ
4 Kombinasjon
5 Kombinasjon
6 Kombinasjon
7 Kvantitativ
8 Kvantitativ
9 Kvantitativ
10 Kvalitativ
Tabell 1 Metodevalg
1.6.5 Feilkilder knyttet til metodevalg
Det kan i del 4 bli for stort fokus på kvantitativ metode, uten at det brukes noe av
informasjonen anskaffet i den kvalitative del 1. Fokuset kan bli for mye rettet mot den
kvantitative delen slik at resultatene blir for ensidige uten at det vises til alternative
metoder. En tettere integrering mellom disse delene kunne vært med i bekreftelsen
eller avkreftelsen av påstandene gjort i del 4. En annen feilkilde kan være bruken av
både kvalitativ og kvantitativ metode i del 2. I del 2 introduseres metoden som
benyttes i del 4. Bruken av begge metodene i del 2 kan føre til at man i
datainnsamlingen i del 4 ser bort i fra den harde strukturen som kvantitativ metode
forutsetter.
16

1.7 Anskaffelse av data
Etter valg av forskningsstrategi og oppgavens design er neste steg i følge Ringdal
(2007) å anskaffe data. Ringdal (2007) forklarer to mulige metoder for å anskaffe
data: Benytte foreliggende data eller innsamling av data.
1.7.1 Foreliggende data
Foreliggende data er i følge Ringdal (2007) alt fra brev og dagbøker til
spørreundersøkelser fra Statistisk sentralbyrå.
For denne oppgaven er det naturlig å bruke foreliggende data i litteratursøkdelen, altså
del 1 og del 2. Dette gjøres gjennom litteratursøk i biblioteksdatabasen til NTNU.
I del 3 vil det også være naturlig å bruke foreliggende data, men her vil søket ikke
foregå gjennom NTNUs biblioteksdatabase. Det vil her i stor grad bli brukt ressurser
hos NSB og Jernbaneverket (JBV) i tillegg til manualen for simuleringsprogammet
OpenTrack.
1.7.2 Innsamling av data
Innsamling av data kan i følge Ringdal (2007) være spørreundersøkelser,
samtaleintervju eller observasjon. I denne prosjektoppgaven vil det være naturlig å
bruke samtaleintervju og observasjon.
Samtaleintervju
Ringdal (2007) deler samtaleintervju opp i besøksintervju og telefonintervju. Det vil
for denne oppgaven bli brukt telefonintervju med personer i NSB og JBV for å
innsamle data til Del 3 og Del 4. I tillegg vil også e-mail benyttes.
Observasjon
Observasjon deles i følge Ringdal (2007) opp i feltobservasjon og
laboratorieobservasjon, hvor feltobservasjon defineres som en typisk kvalitativ
datainnsamlingsteknikk. Laboratorieobservasjon er egnet til en kvantitativ
forskningsstrategi og benyttes i undersøkelser av samspill eller problemløsning i små
grupper.
Laboratorieobservasjon vil bli benyttet for denne oppgaven og vil bli tatt i bruk i Del
4. Jernbanedrift er et samspill mellom mennesker, rullende materiell, signaler, spor
osv. OpenTrack tilbyr brukeren å analysere jernbanedriften og fungerer som
laboratorieobservasjon.
I Figur 2 er det gitt en oversikt over hvilke metoder som er brukt for hvert kapittel i
oppgaven. For kapittel 8 vil det være nødvendig med samtaleintervju og observasjon.
17

Kap 1
Innledning
Figur 2 Anskaffelse av data
Del 1
(Kap 2-3)
Bruk av foreliggende
data
(Kap 2-3)
Del 2
(Kap 4)
Bruk av foreliggende
data
(Kap 4)
Oppgavens oppbygning
Del 3
(Kap 5-6)
Bruk av foreliggende
data
(Kap 5)
Samtaleintervju
(Kap 6)
Del 4
(Kap 7-9)
Samtaleintervju
(Kap 7-8)
Observasjon
Kap (8-9)
18

Del 1
2 Innføring i simulering
I dette kapittelet gis det en innføring i simulering. Kapittelet begynner med en
definering av begrepet simulering før det gis en kort historisk bakgrunn. Videre vil
vanlig/mulig bruk av simulering bli gjennomgått for så vurdere på fordeler og
ulemper med simulering.
2.1 Hva er simulering
Merriam-Webster (2010, [Internett]) definerer simulering som”the imitative
representation of the functioning of one system or process by means of the functioning
of another”
I følge Guizani et al. (2010, s.1) er simulering”the imitation of a real-world system
through a computational re-enactment of its behavior according to the rules
described in a mathematical model. Simulation serves to imitate a real system or
process. ”
Videre hevder Guizani et al. (2010) at simulering av et system vanligvis medfører å
undersøke noen nøkkelegenskaper og deres atferd i systemet, som ellers ville vært for
komplekse og detaljerte.
Simulering tillater oss å undersøke hvordan systemet reagerer på forskjellige
scenarioer gjennom å endre på variabler i modellen. Dette gjør at man gjennom
simulering kan undersøke forskjellige løsninger på problemer som man ikke ville hatt
muligheten til å gjøre i virkeligheten.
2.2 Historie om simulering
Guizani et al. (2010) peker på to viktige faktorer som har gjort simulering mulig;
utviklingen av nye og bedre datamaskiner og NASA sitt romprogram. Før den tid var
bruken av simulering lite utbredt, og dersom et design skulle testes var eneste
mulighet å konstruere designet. Utviklingen av datamaskiner gjorde det mulig å utføre
krevende matematiske utregninger hurtig. Denne utviklingen gjorde det mulig for
NASA å simulere utskytning og innreise, to kritiske faser i romprogrammet. Dette
reddet både liv og millioner av dollar som ville vært brukt på tradisjonell rakettesting.
I dag er bruken av modellering og simulering svært utbredt. De blir ikke bare brukt
for å finne ut om et systemdesign fungerer, men til å finne det designet som fungerer
best. Enda viktigere er det at modellering og simulering brukes som en billig teknikk
for å utføre unntak og ”what-if” analyser, spesielt når kostnaden ville blitt høy ved å
bruke det faktiske designet (Guizani et al., 2010).
19

2.3 Vanlig/mulig bruk av simulering
White & Ingalls (2009) deler simulering grovt inn i to kategorier. Den første
kategorien, ”man-in-the-loop”-simulering, er brukt for trening og/eller underholdning.
Piloter bruker flysimulatorer for å lære seg å fly, operatører i kjernefysiske anlegg
simulerer forskjellige scenarioer i kontrollrommet, leger lærer ved hjelp av simulerte
pasienter. I tillegg finnes det dataspill som simulerer alt fra kjøring av tog til
fantasispill. Hovedpoenget med ”man-in-the-loop”-simulering er å eksperimentere og
få til et såkalt ”learning by doing”.
Den andre kategorien er analyse og design av prosesser. Prosessene er komplekse og
lar seg ikke løse ved hjelp av en analytisk fremgangsmåte.
Banks (2009) deler bruken av simulering inn i analyse, eksperimentering og trening,
men kommer frem til nesten samme konklusjon som White & Ingalls (2009), der
analyse går ut på å undersøke hvordan modellen oppfører seg, eksperimentering skjer
når modellen er dynamisk og endrer seg ut over grensene av modellen, mens trening
er brukt for å øke kunnskap og ferdigheter ved hjelp av modellen.
Pidd (2009) karakteriserer systemene som er best egnet for simulering som:
Dynamiske – varierer over tid
Interaktive – inneholder flere komponenter som påvirker hverandre
Kompliserte – systemet består av flere dynamiske og interaktive objekter
Axelrod (2003) hevder at nytten av simulering kan utnyttes på syv forskjellige måter.
Disse måtene er: prediksjon, prestasjon, trening, underholdning, læring, bevis og
oppdagelser.
1. Prediksjon – simulering gjør det mulig å ta kompliserte inndata og generere
data som brukes som en forutsigelse gjennom antakelser.
2. Prestasjon – simulering kan også brukes til å utføre visse handlinger. Dette er
typisk innenfor området ”artificial intelligence”.
3. Trening – mange av de tidligste og mest suksessrike simuleringssystemene var
designet med hensikt i opptrening av mennesker. De skulle med en rimelig
nøyaktighet gi en representasjon av virkeligheten. Flysimulatorer for piloter er
et eksempel.
4. Underholdning – fra trening er det bare et lite steg til underholdning.
Flysimulatorer er et eksempel også her.
5. Læring – det viktigste bruksområdet innenfor lærling er at brukeren skal lære
hvordan et system henger sammen og prinsippene ved systemet selv.
6. Bevis – Simulering kan bli brukt til å bevise forekomster
7. Oppdagelser – Man kan ved hjelp av simulering oppdage nye sammenhenger
og relasjoner. Som en vitenskapelig metode består simulering i prinsippet av
20

prediksjon, bevis og oppdagelser. Prediksjon er den bruken av simulering flest
tenker på, men oppdagelser er minst like viktig.
Guizani et al (2010) beskriver de viktigste simuleringsteknikkene som:
Emulering – Prosessen av å designe og bygge hardware eller firmware som etterligner
funksjonaliteten til det ekte systemet
Monte Carlo Simulering – Hvilken som helst simulering som ikke har tidsakse. Monte
Carlo simulering er brukt til å modellere sannsynlighetsfenomen som ikke endrer seg
over tid
Trace-driven simulation – Enhver simulering som bruker en ordnet liste av ekte utfall
som inndata
Continuous-event simulation – I enkelte systemer skjer endringer kontinuerlig, ikke
bare ved et punkt. I sånne tilfeller er ”continuous simulation” riktig å bruke
Discrete-event simulation – En diskret simulering er karakterisert av to egenskaper.
(1) Innenfor et hvert tidsintervall kan man finne et subinterval hvor ingen hendelse
skjer og tilstanden til variablene ikke endrer seg. (2) antall hendelser er begrenset.
Alle discrete-event simulations har de følgende komponentene.
- Event queue - en liste som inneholder alle hendelsene som venter på å
inntreffe (i fremtiden).
- Simulation clock - en global variabel som representerer den simulerte tiden.
- State variables - variabler som til sammen fullstendig beskriver tilstanden til
systemet
- Event routines - rutiner som kan håndtere forekomst av hendelser
- Input routines - rutine som tar inndata parametere fra brukeren inn i modellen
- Report generation routine - Kalkulerer resultat og presenterer de for brukeren
- Initialization routine - en rutine som starter verdiene til startvariablene,
globalvariablene og statistiske variabler i starten av simuleringen
- Main program - programmet som kaller på de forskjellige ”routines”.
2.4 Fordeler og ulemper ved simulering
Greasley (2008) begrunner følgende årsaker til hvorfor en bør bruke simulering som
bistand til å forbedre prosessen:
- Tillater forutsigelse – Muligheten til å teste mange forskjellige senarioer
- Stimulerer kreativitet – Stimulerer kreativitet gjennom å tillate mange testing
av mange forskjellige muligheter raskt og billig
- Unngå oppbrudd – Tillater å evaluere mange forskjellige løsninger uten å
måtte stanse produksjon
- Reduserer risiko – Tillater å evaluere mange forskjellige løsninger og
gjennom det finne uforutsette hendelser og dermed redusere risiko
21

- Gir ytelses målinger – Kan bli integrert inn i ytelsesmåling systemer som kan
gi yteevne og kostnads estimater for bedriften
- Fungere som et kommunikasjonsverktøy – Resultatet og dataanimasjon kan
fungere som et forum for å forstå systemets oppførsel. Dynamikken til
systemet kan bli visualisert over tid, noe som hjelper på forståelsen av
interaksjonen i systemet.
- Bistå med aksept av endring – Man kan forutse effekten av endring, dermed få
aksept for endring og forståelsen øker.
- Oppfordrer til datainnsamling – Systematisk innhenting av data fra
forskjellige kilder for å bygge modellen kan i seg selv lede til økt innsikt i
driften før modellen har blitt bygd og simulering begynt.
- Tillater oversikt over hele prosessen – Bruk av simulering på tvers av
avdelinger tillater forbedringer av hele prosessen i stedet for bare hver enkelt
avdeling
- Verktøy for trening – Tillater trening av personell uten ekstra kostnader og
stans av produksjon, fungerer også som en visuell demonstrasjon av
operasjonen.
- Hjelp til design – Tillater observasjon av prosessens oppførsel og dermed
muligheten til å optimere prosessens design på et tidlig stadium
Reynolds (2009) nevner mange av de samme fordelene som Greasley (2008).
Samtidig peker Greasley (2008) på en del ulemper ved bruken av simulering. Selv om
simulering har mange bruksområder vil det være lite hensiktsmessig å bruke tid og
ressurser på å løse et ubetydelig problem. På tross av at simulering er et verktøy som
brukes til å spare penger i forhold til å bygge systemet, er det fremdeles kostbart og
det kan derfor være hensiktsmessig og heller se på alternative metoder for å løse
problemet som ”spreadsheet analysis” og lineær programmering.
Guizani et al (2010) peker på de vanligste feilene som gjøres ved modellering og
simulering, som kan lede til unøyaktige og villedende resultater
- Upassende detaljeringsgrad – simulering foregår som regel ved hjelp av
datamaskiner og det er derfor ofte fristende å inkludere flere detaljer. Dette vil
føre til at simuleringen tar mye lengre tid. Viktigere er det at en
uforholdsmessig detaljert modell kan føre til vanskeligheter med å fastslå og
isolere effekten parameterne har på systemet
- Feilaktig valg av programmeringsspråk – valg av programmeringsspråk har
stor innvirkning på utviklingstiden av modellen. Spesialsimulatorerspråkene
krever kortere utviklingstid mens universellspråkene er mer effektive under
selve simuleringen
- Ikke-verifisert modell – dersom et simuleringsprogram ikke er verifisert kan
det føre til villedende resultater og konklusjoner
- Feil modell – selve simuleringsprogrammet kan være riktig men modellen
representerer ikke oppførselen til virkeligheten
22

- Feilaktige startbetingelser – feilaktige startbetingelser kan føre til konvergens
til atypiske startbetingelser, som igjen kan føre til feilaktige konklusjoner om
systemet
- Korte ”run times” - personen som simulerer kan spare tid ved å redusere
simuleringstiden. Dette fører til feilaktige resultater som ikke reflekterer
virkeligheten
- Dårlig generator for tilfeldige tall– det er viktig å bruke en generator for
tilfeldige tall som har blitt testet og analysert. Frøtallene som brukes i
generatoren bør velges slik at det ikke er noe korrelasjon mellom de
forskjellige prosessene i systemet
- Utilstrekkelig tidsestimat – de fleste simuleringsmodeller gir ikke tilstrekkelig
tid for utvikling og implementering av modellen. Utvikling, implementering
og testing er en tidkrevende prosess.
- Ikke oppnåelige mål – det er viktig å sette et oppnåelig mål før utviklingen av
simuleringsmodellen for å oppnå ønsket resultat
- Bred kompetanse – bred kompetanse er viktig for at prosjektet skal lykkes.
Man trenger prosjektledere, programmerere, personer med kunnskap om
statistikk og modellering og personer som har kunnskap om området som skal
modelleres.
- Utilstrekkelig brukerdeltakelse - modeller som er utviklet uten deltakelse av
sluttbruker blir som regel dårlig. Det trengs regelmessige møter mellom
sluttbruker og utvikler for å få et bra produkt
- Manglende evne til å håndtere simuleringsprosjektet – de fleste
simuleringsprosjekter er ekstremt komplekse, og det er derfor viktig å anskaffe
programvare for å holde rede på funksjonaliteten på prosjektet
23

3 Bruk av simulering i jernbane
Dette kapittelet gir en grundigere innføring i bruken av simulering i jernbanedrift.
Kapittelet begynner med en forklaring av vanskeligheten ved simulering av
jernbanedriften. Videre blir fordelene med simulering diskutert, og forskjellige
simuleringsmetoder og simuleringsprogrammer blir forklart. Til slutt presenteres et
eksempel på hvordan jernbanen i Italia brukte simulering ved omlegging av
jernbanen.
3.1 Bakgrunn
3.1.1 Simulering i jernbane
Siefer (2008, s.155) skriver at ”for en del år siden trodde en at det var umulig å
simulere jernbanenettverket fordi det var for komplekst og det var for mange
grensebetingelser, men i dag finnes det kraftig nok programvare og maskinvare til at
jernbanenettverket lar seg simulere på en realistisk måte”
Kompleksiteten i bruken av simulering i jernbanen utdypes av Krueger et al. (2000).
Noen miljøer lar seg representere ved hjelp av matematiske formler eller standard
”Queuing Models” men dette er ikke tilstrekkelig for jernbanen. Noen kjennetegn ved
jernbanen gjør simulering spesielt vanskelig. De følgende lister Krueger et al. (2000)
som noen av de mer unike karakteristikkene ved jernbanen som trenger og innlemmes
i en modell:
- Store områder må modelleres - ofte et spenn over flere hundre kilometer,
kanskje over 1000
- Togledelse – mennesker må ta avgjørelser under dynamiske tilstander
- Avstand mellom kontrollpunkt – Kan være så lite som et par hundredeler eller
så stort som flere tog lengder
- Dynamisk prioritering – Prioritering endrer seg etter hvor forsinket et tog er,
eller om det er før rute
- Besetning – maksimal arbeidstid må overholdes for besetningen
- Trenger informasjon om forbigående tilstand – togtrafikken er sjelden i en
stabil tilstand
Videre forteller Krueger et al. (2000) at jernbanedriften kan deles opp i forskjellige
lag som må bli tatt med i betraktningen i en komplett simuleringspakke, disse er:
- Ytelsen til toget over den spesifikke topografien som helning, kurver,
fartsrestriksjoner, tilstanden på skinner etc. gitt en sammensetning av
trekkraft, vekt, lengde og motstand (vind, friksjon fra skinnene)
- Fysisk bevegelse som er mulig basert på layouten av spor og veksler
- Bevegelse som er mulig basert på signalanlegget
- Karakteristikk for hvert togs kjøreplan, foretrukket rute, obligatoriske stopp
etc.
- Interaksjon mellom tog bevegelse og stasjonsområde
24

- Rullende materiell og besetningsrestriksjoner
- Togledelse som prøver å optimere togbevegelser gjennom systemet
3.1.2 Fordeler med simulering i jernbane
I følge Martin (1999) kan simulering være et viktig verktøy i design av ny
infrastruktur. Simuleringsverktøyet kan også brukes i mange former:
- Som et verktøy for å måle trekkraft til et tog ved en gitt infrastruktur
- Vurdere signalanlegget for å finne optimal løsning, eller
- Evaluere foreslått ruteplan og interaksjon mellom togene ved en kompleks
stasjon eller knutepunkt.
Siefer (2008) utdyper videre og sier at simulering et verktøy for både planlegging og
optimering, og har følgende fordeler for jernbanen: Penger kan spares fordi
konstruksjon av ny infrastruktur for jernbanen er en stor investering og tar lang tid.
Det er som regel ikke mulig å bygge en prototype. Når infrastrukturen er bygget må
den brukes, uten endring, i en lang periode. Simulering tillater å undersøke og
verifisere nytten på forhånd.
I virkeligheten kreves det en detaljert analyse av stasjonsbelegg og utleveringsdata for
å kunne vurdere vekselvirkningen mellom forskjellige tog, eller mellom tog og
infrastruktur. Konfliktkombinasjoner skjer sjelden, bare noen få ganger i løpet av en
dag. Gjennom simulering kan en lage utallige togkombinasjoner og resultatet kan lett
evalueres.
Under daglig drift gis det ingen rom for eksperimentering. I en simulering kan man
kjøre alle togtyper til alle tider og undersøke forskjellige mulige løsninger for
operasjonen. Det gir muligheten for en evaluering av interaksjon for forskjellige tog.
Dersom dagens ruteplan skulle modifiseres er avvik grunnet eksperimentering
uønsket. Ideer for endring av dagens ruteplan kan undersøkes ved hjelp av simulering
før en bruker den i virkelig drift uten å skape forstyrrelser.
Påvirkningen fra infrastrukturendringer, rullende materiell-endringer og modifisert
layout av sporene kan simuleres. I tillegg kan simulering med forstyrrelser bevise
stabiliteten til ruteplanen. Hvis stabiliteten til ruteplanen ikke oppfyller
forhåndskravene må endring av ruteplanen eller infrastrukturen skje for å få en
realistisk ruteplan.
3.1.3 Simuleringsmetoder
Grunnet forskjellige vitenskapelige teorier finnes det forskjellige simuleringsmåter for
jernbanen (Siefer, 2008).
Makroskopiske modeller beskriver jernbanenettet og ruteplanen som direkte grafer av
enkle noder (stasjoner) og linker inkludert frekvensen av togene og kjøretiden mellom
stasjonene for de enkelte linjene. Mikroskopiske modeller består av en spesifisering
av antall, lengde og plassering av sporavsnitt, signalanlegget, tekniske egenskaper til
25

ullende materiell, ankomsttid, avgangstid, akselerasjon, retardasjon, bremsetid og
buffertid mellom togene.
Deterministiske modeller estimerer ankomst-, avgangs- og kjøretid i henhold til
kjøreplanen og kan bare bli brukt som en innledende design av ruteplanen.
Stokastiske modeller bruker fordelinger av ankomst-, avgangs- og kjøretid for
detaljert design av ruteplanen, estimering av robustheten til ruteplanen mot
fordelingene og for modellering av individuelle togbevegelser som automatisk
kontrolleres av signalanlegget.
De fleste modeller som brukes i praksis er basert på teorien om synkron simulering.
Synkrone modeller simulerer alle hendelser i jernbanenettet samtidig i korte tidssteg.
En synkron simulering kan beskrives som en dynamisk prosess, hvor alle tog kjører
etter en kjøreplan. Derfor er det mulig at enkelte tog påvirker andre tog, som
resulterer i forsinkelse eller inngrep fra togledelse. I motsetning vil asynkron
simulering kjøre alle tog etter en hierarkisk struktur og kjøre ett og ett tog etter
hverandre etter prioritet, hvor høyt prioriterte tog kjører først, deretter tog med lavere
prioritet. Det er klart, og har blitt bevist, at bare synkron simulering kan gi indikatorer
som ”on-time-running” pålitelighet eller nøyaktig beskrive spredningen av forsinkelse
i jernbanenettet (Radtke, 2006).
Synkron simulering kan brukes til to typer undersøkelse. Den første er simulering av
en ruteplan for å undersøke effekten av iboende konflikter som spres i nettverket. Den
andre er driftssimulering, som inkluderer introduksjonen av forsinkelser i henhold til
statistiske regler (Radtke, 2006).
En fordel med synkron simulering er at alle tog simuleres parallelt, med en realistisk
interaksjon mellom togene. Den tar også hensyn til akselerasjon og retardasjon
grunnet konflikter i simuleringen, ekstern påvirkning som antall passasjerer, fører
reaksjon på signaler og teknisk svikt av signaler, sporveksler og rullende materiell. I
tillegg brukes togledelse for løsning av driftsproblemer. All data registreres også slik
at driften kan evalueres i etterkant av simuleringen.
3.1.4 Simuleringsprogrammer
I følge Siefer (2008) finnes det flere synkrone simuleringsverktøy. Nedenfor vil det
bli gitt en kort innføring i noen av de forskjellige verktøyene. OpenTrack vil bli tatt
for seg i større grad i kapittel 5.1.
RailSys
RailSys ble utviklet ved Leibniz Universitet Hannover og er et verktøy for simulering
av jernbanedriften. RailSys er designet for å kunne modellere store og komplekse
nettverk på et mikroskopisk nivå. Grovt forklart bruker RailSys infrastrukturdata, togdata,
sikkerhetssystem, ruteplandata, forsinkelsesfordeling og togledelse som inndata,
mens output består blant annet av gjennomsnittlig forsinkelse for alle tog over den
evaluerte perioden (Hansen, 2010).
26

SIMONE
SIMONE står for Simulation Model of Networks, altså en simuleringsmodell for
nettverk. Simone ble utviklet av Railned og konsulentfirmaet Incontrol.
Simone er delt i tre deler og består av et simuleringsbibliotek, en automatisk modellgenerator
og et kontrollsenter. I simuleringsbiblioteket legges det inn inndata for
simuleringen gjennom seks moduler:
- Simuleringsinnstillinger – inneholder simuleringsparametere
- Nettverksinnstillinger - nettverkskarakteristikk som forstyrrelser
- Statistikk – spesifikasjon av ytelse-indikatorer for output
- Ruteplan – tog aktiviteter ved stasjon, inkluderer slakk
- Stasjon – stasjoner, knutepunkt og andre relevante punkter for ruteplanen
- Forbindelse – antall spor som er tilknyttet en stasjon
Den automatiske modellgeneratoren tar inndata fra simuleringsbiblioteket og bygger
nettverket, mens det gjennom kontrollsenteret utføres simuleringseksperimenter og
analyseres output (Middelkoop & Bouwman, 2000).
FALKO
FALKO, er et simuleringsverktøy som distribueres av Siemens. FALKO er bygget
opp av et modulært designkonsept og tilbyr blant annet optimering av sporgeometri,
energiforbruk, ruteplan og passasjerflyt. Inndata består av et kontrollsystem, signal-
og sikkerhetssystem, rullende materiell og passasjerdata. Gjennom simulering gjør
Falko det mulig å validere ruteplanen (Siemens AG, 2007).
Railsim
Railsim modellerer et ubegrenset antall tog på et tilnærmet ubegrenset
jernbanenettverk. Railsim kan brukes for å undersøke blant annet ruteplan- og
driftsutvikling, validering av signalposisjon, ny infrastruktur, kapasitet og
kjøretidsberegninger. Som output tilbyr Railsim informasjon om forsinkelse, signaler,
ruteplan, tog og forskjellige diagrammer (Railsim, 2010).
RTC
Rail Traffic Controller (RTC) er et simuleringsverktøy som simulerer togledelse på
samme elementer som en ekte togleder. RTC bruker en integrert tog-ytelseskalkulator
som tar hensyn til forskjellig utstyrstyper, togsett, terreng og spor.
Simuleringsresultatene blir vist grafisk. Vanlig bruk av RTC er utvikling av
driftsplaner, finne og løse flaskehalser og evaluere fremtidig infrastruktur (Berkeley
Simulation Software, 2010).
27

3.2 Case-studie: Italiensk jernbane
All informasjon for dette caset er hentet fra Astengo et al. (2000).
3.2.1 Hvorfor dette caset
Hensikten med dette caset er å illustrere hvordan jernbaneselskaper i andre land enn
Norge har brukt simulering for å simulere fremtidige driftsituasjoner. Gjennom dette
caset dannes det en glidende overgang til neste kapittel.
3.2.2 Introduksjon av caset
Avhandlingen beskriver studiet som er utført for området rundt Firenze hvor to
høyhastighetslinjer sammenslås med syv andre linjer, og hvor trafikken blandes med
fjerntog, lokaltog og godstog.
Studiet inkluderer:
- En infrastrukturmodell av området
- Et sett med foreslått rutetabeller for området
- Modell av forskjellige togtyper
- Modell av signalsystemet
- Simulering av forskjellige trafikk scenarioer
- Simulering av bruken av plattformspor på hovedstasjon
- Simulering av effekten av avvik på trafikkapasiteten
- Evaluering av resultater
Firenze er en viktig node i den italienske jernbanen, herfra går linjer til/fra Bologna-
Milano, Roma og Pisa. Tidlig på 90 tallet ble en ny høyhastighetslinje til Roma satt i
drift og rundt 2006-2007 ville en ny høyhastighetslinje til Bologna stå klar. Videre
skulle to sekundære linjer og andre spor legges til for å møte forventet økende trafikk.
Oppgraderingen vil skje over flere år, hvor dagens situasjon (1999) vil få en betydelig
oppgradering innen 2003. Innen 2008 skal den nye høyhastighetslinjen til/fra Bologna
være i drift via stasjonen i Firenze. Samtidig vil en ny undergrunnslinje tilføyes for å
få en direkte link mellom de to høyhastighetslinjene fra Bologna og Roma. Andre
mindre stasjoner i området og en ny linje vil også tilføyes.
På grunn av at forbedringen og implementeringen skjer over flere år må den italienske
jernbanen simulere begge scenarioene (2003 og 2008) for å kunne evaluere
potensialet og gjennomførligheten av prosjektet.
3.2.3 Bruk av simulering
Simuleringsverktøyet:
For å kunne teste robustheten til det nye systemet ble det brukt et simuleringsverktøy
som kunne utføre følgende funksjoner:
- Simulering av layouten til nettverket, både i 2003 og 2008, med tilhørende
stasjoner, spor, brytere, helling, fartsrestriksjoner.
28

- Simulering av signalsystemet for hele området, inkludert samtidig innkjør,
blokkpost, baliser, osv.
- Simulering av tog parametere (trekkraftkurve, antall vogner på
motorvognsettet, makshastighet, vekt, osv.) for alle togtyper i området
(høyhastighetstog, fjerntog, lokaltog, godstog)
- Simulering av togbevegelser i hele området
- Forsørge både numerisk og grafisk output, som grafisk ruteplan og
informasjon om togforsinkelser
- Mulighet for å endre verdien på variabler for å optimere løsningen og evaluere
konsekvensene av avvik.
Figur 3 Simuleringsstruktur (Astengo et al., 2000)
Strukturen av simuleringsverktøyet består av tre forskjellige inndata
(infrastrukturmodell, rutetabell og togdata). Ved hjelp av de fem simulatormodulene
får man forskjellig typer output som grafiske ruteplaner, toggrafer, etc.
Simuleringsprogrammet ble implementert ved hjelp av C++ og ”Objective Oriented
Analysis and Design technique”. Programvaren er tilordnet i et sett med individuelle
moduler, hvor hver enkelt modul inneholder funksjonen og databasen for en spesifikk
enhet.
Simuleringen ble utført ved hjelp av forskjellige steg, fra definering av inndata til
simulering av trafikken og ruteplan optimering. Under er stegene listet opp
- Definisjon av infrastrukturmodellen
- Definisjon av tog
- Bygging av en referanseruteplan
- Simulering av trafikkavvik
29

- Definisjon av stasjonslayout
- Simulering av trafikk på stasjonsområdet
Målet med simuleringen var å evaluere kapasiteten til Firenze området og undersøke
kompatibiliteten til nettverket for årene 2003 og 2008.
For hvert scenario (2003 og 2008) ble en typisk ruteplan for hele nettverket gitt. Ved
hjelp av denne ble det generert mange ulike output. Blant annet toggrafer for hver
linje som kan utnyttes for å finne kapasiteten og skaffe en konfliktfri ruteplan. Et
annet eksempel er stasjonsbelegg diagram som viser antall tog på stasjonsområdet
over en gitt periode og ankomst og avgangstid for de forskjellige togene. Det ble også
introdusert forsinkelse (f. eks 10s, 15s, 20s) på forskjellige tog for å undersøke
effekten forsinkelsen hadde på andre tog og for å undersøke robustheten til
ruteplanen.
3.2.4 Konklusjon
Bruken av simulering har gjort det mulig å undersøke gjennomførbarheten av begge
scenarioene (2003 og 2008) med spesielt hensyn på kompatibiliteten av
høyhastighetstog med andre togtyper. Videre ble det konstatert at kapasiteten på
linjen og stasjonsbelegget på Firenze SMN stasjon ville fungere. Simuleringen av
avvik, på enkelt tog eller en lang rekke tog, har gitt muligheten til å evaluere
forstyrrelsen på andre tog i ruteplanen.
30

Del 2
4 Metodikk for simuleringsprosesser
I figuren under viser Landex & Nielsen (2006) arbeidsforløpet for en
simuleringsprosess. Det går ut på å bygge en infrastrukturmodell som enten forestiller
dagens infrastruktur eller en planlagt fremtidig infrastruktur. Deretter må en ruteplan
konstrueres. Når en konfliktfri ruteplan er oppnådd legges det på en statistisk
fordeling for å simulere forsinkelse på togene.
Figur 4 Arbeidsforløp for en simuleringsprosess (Landex & Nielsen, 2006)
Etter at simuleringen er gjennomført blir den evaluert og det bestemmes deretter om
prosessen må startes på nytt.
Problemet med et arbeidsforløp som Landex & Nielsen (2006) viser, er at det ikke tar
hensyn til hele simuleringsprosjektet, bare konstruksjonen av infrastrukturmodellen,
ruteplan, simulering og evaluering.
Dette har Radtke (2006) gjort noe med; gjennom erfaringer fra praktisk bruk av
mikroskopisk simulering har Radtke (2006) utviklet ”The Seven-Step-Model” som et
første steg for å oppnå en altomfattende metode for arbeid med mikroskopisk
simulering. Programmet RailSys ble brukt under utviklingen av metoden, men Radtke
(2006) hevder at prinsippene ikke er begrenset til RailSys, men at metoden kan brukes
til alle mikroskopiske simuleringer. Under følger de syv stegene som må oppnås for å
oppnå en suksessfull simuleringsprosess:
31

1 Definere prosjekttypen
2 Anskaffe data og essensielle elementer av modellen
3 Validere basismodellen
4 Konstruere ruteplan
5 Evaluere ruteplanen og sporbruk
6 Simulere drift
7 Evaluere og presentere resultater
Som man ser av Figur 5 under går første steget ut på å definere prosjekttypen. Her må
det defineres om det er et standardprosjekt eller ikke. I det andre steget må data
innhentes. Viktigste data å innhente er infrastrukturdata og rullende materiell data.
Det bygges deretter en modell basert på infrastrukturdata og materiell-data (lokomotiv
og togtyper). Steg tre er validering av basismodellen. Modellen må kalibreres for å
bekrefte kvaliteten av modellen. I steg fire skal ruteplanen konstrueres og innhenting
og forberedelse av operasjonelle data utføres. Etter at ruteplanen er konstruert i steg
fire må ruteplanen evalueres sammen med sporbruken. Før steg seks kan iverksettes
må modellen igjen kalibreres. Etter endt simulering må resultatene evalueres.
Evalueringen går ut på å analysere kvaliteten av driften, beleggverdier og videre
anbefalinger.
32

Time
I
II
III
IV
V
VI
VII
Iteration with
TOC
RU
Standard project
yes
Infrastructure data
Data collection
Model building
Quality assurance
Timetable construction
Timetabel conference
Timetable simulation
Results of timetable studies and slot
management
Model calibration
Figur 5 Seven-Step-Model (Radtke, 2006)
no
Model enhancement
Useful and necessary
no
yes
Vehicle data
Data collection
Model building
Quality assurance
RailSys: Infrastructure model
Vehicle data (loco and train types)
Calibration of model, quality assurance
Infrastructure and vehicle data
Collection of
operational data
Preperation of
operational simulation
Operational
simulation
Specification of software
enhancements
Results: Operational quality
Occupation values
Recommondentation
Infrastructure Interface
Iteration with
TOC
RU
Effort calculation
Programming and test
Den modellen som benyttes i arbeidet med denne prosjektoppgaven er allerede
bygget, med små unntak, og kalibrert på forhånd. I tillegg er ruteplanen konstruert av
NSB, med unntak av kipptog og godstog. Kipptog er et skiftelokomotiv, som vil si et
lokomotiv som brukes til å dele og sette sammen godstog. I denne oppgaven vil det
bare fortelles om infrastrukturen i Drammens-området i kapittel 6, generelt om
kalibrering i 4.3, kalibrering av OpenTrack modellen i 8.1 mens ruteplan og statistisk
inndata vil bli utdypet grundigere i 7.1 og 7.2. Oppgaven legges opp etter følgende
steg
1 Konstruere ruteplan og forberedelse av operasjonelle data
2 Kalibrering av modellen
3 Simulere drift
4 Evaluere og presentere resultater
I denne prosjektoppgaven er “Konstruere ruteplan og forberedelse av operasjonelle
data kapittel” diskutert i 7, “Kalibrering av modellen” er diskutert i kapittel 8,
33

“Simulere drift” er diskutert i kapittel 9 og “Evaluere og presentere resultater” drøftes
i konklusjonen i kapittel 10.
4.1 Konstruere ruteplan
4.1.1 Definisjon av ruteplan
I følge Kroon et al. (2008) består en ruteplan av to elementer: (i) ankomst- og
avgangstider for tog på stasjoner eller andre relevante steder, og (ii) kjøreplanen for
hvert tog til et riktig plattformspor og tilsvarende innkjør- og utkjør ruter til alle
relevante stasjoner.
Under er et utklipp av hvordan en grafisk ruteplan kan se ut.
Figur 6 Grafisk ruteplan mellom Asker-Drammen 06:00-07:00 (Jernbaneverket, 2010a)
Men ruteplanlegging består ikke bare av å planlegge selve ruteplanen, rullende
materiell og besetning må også tas med i betraktningen
I mange europeiske land kjører passasjertog etter såkalte sykliske eller periodiske
ruteplaner. Det vil si at hver linje kjører for eksempel hvert 30, 60 eller 120 minutt.
En fordel med en slik periodisk ruteplan er at passasjerer enkelt kan vite når togene
går, en annen fordel er at det er relativt lett å sette opp mange forskjellige overganger
for passasjerer. Siden en periodisk ruteplan ikke er fleksibel i seg selv er det vanskelig
å tilby mange direkte ruter. En annen ulempe er at det kan være potensielt ineffektivt
og kun ha en periodisk ruteplan fordi tog kjører utenom rushtid, derfor tilbys flere tog
i rushtiden, i tillegg til den periodiske ruteplanen, og slik kan man også redusere
frekvensen utenom rushperioder (Kroon et al., 2008).
4.1.2 Definisjon av robusthet og robust ruteplan
Pålitelig jernbanedrift trenger en robust og stabil ruteplan, med innebygget slakk for å
hindre eller redusere forsinkelser og forplantning av forsinkelser. I all enkelthet betyr
en stabil ruteplan at jernbanenettet stabiliserer seg uten å endre på ruteplanen, altså
referer stabilitet til graden av selvregulering en ruteplan har etter avbrudd (Goverde,
2008).
Dette bekreftes av Kroon et al. (2008) som sier at et av målene med en ruteplan er at
den skal være så robust så mulig. Det betyr at ruteplanen skal kunne håndtere relativt
små forstyrrelser i sanntidsdrift.
34

Goverde (2008) beskriver at et område kan være lokalt og globalt stabil. Med det
mener han at et åpent lokalt område er lokalt stabil hvis summen av forsinkelser ut av
området er mindre enn forsinkelsen inn i området. Her er forsinkelser inn i systemet
både tog som kommer inn i området og tog som starter i området, mens forsinkelser
ut av området er tog som forsvinner ut eller har endestasjon der. Et lukket område kan
være globalt stabilt hvis startforsinkelsene forsvinner i løpet av en begrenset
tidsperiode.
Hansen & Pachl (2008) skriver i sin konklusjon at de viktigste nøkkelegenskapene for
en kvalitetsruteplan er:
- God representasjon av spor og infrastruktur
- Innlemming av restriksjoner fra signalanlegget
- State of the art kapasitetsmodell basert på blokkstrekning
- Høy presisjon på kjøretidsestimat for togene
- Bruk av energibesparende kjørestandarder
- Stabilitets- og robusthetsanalyse som fokuserer på konflikter og flaskehalser
- Kombinasjon av deterministisk analyse, stokastisk analyse og
simuleringsmodeller
- Overvåking, analyse, evaluering og tilbakemelding fra drift
Mens Kroon et al. (2008) sier at en robust ruteplan har en eller flere av følgende
egenskaper:
- Innledende forstyrrelser kan til en viss grad bli absorbert slik at det ikke fører
til forsinkelser
- Det er få følgeforsinkelser fra et tog til et annet
- Forsinkelser forsvinner raskt
4.2 Anskaffing og evaluering av statistisk inndata i modellen
I begynnelsen av dette kapittelet ble sagt at steg 2 ”Anskaffe data og essensielle
elementer av modellen” allerede var utført for denne prosjektoppgaven, men dette
gjelder ikke for statistiske data som skal brukes som inndata for å modellere
forsinkelse. Den delen som er antatt utført gjelder infrastrukturdata og rullende
materiell data.
Det første steget for å modellere forsinkelse er å anskaffe data. Det vil gis først en
forklaring på hva forsinkelse er ulike måter å anskaffe data forklares.
4.2.1 Forsinkelse
Togforsinkelse ved stasjoner kan være forsinkelse ved både ankomst og avgang.
Ankomstforsinkelsen kan være negativ, det tilsvarer at et tog ankommer stasjonen før
ruteplanen. At et tog ankommer før tiden påvirker ikke punktligheten til tog, men kan
føre til mindre effektiv bruk av sporkapasiteten grunnet at sporet blir okkupert lenger
enn nødvendig ettersom et tog ikke kan forlate stasjonen før ruteplanen (Yuan, 2008).
35

Hansen (2004) hevder at togforsinkelser kan klassifiseres som:
- Initial delay – dette er forsinkelser som er registrert først når toget ankommer
det studerte nettverket
- Original delay – disse forsinkelsene oppstår på grunn av teknisk svikt, kjøring
ved lavere hastighet enn planlagt, forlenget påstigningstid av passasjerer, og
dårlig værforhold. Disse forsinkelsene er vanskelig å forutsi.
- Følgeforsinkelser – Når et tog er forsinket, kan det hindre andre tog. Disse
forsinkelsene som er overført fra et tog til et annet kalles følgeforsinkelser.
Lindfeldt (2010) opererer med samme klassifisering som Hansen (2004) med andre
navn på forsinkelsene, men i tillegg nevner Lindfeldt (2010) ”catch-up effects”. Det
vil si at et tog har mulighet, grunnet slakk lagt inn i ruteplanen, til å kjøre inn
forsinkelsen. Videre definerer han ”Additional delays” som “ økningen av
forsinkelse, positiv eller negativ, som en linje påføres over et område”. Med negativ
forsinkelse menes at et tog kjører inn deler av forsinkelsen slik at forsinkelsen er
redusert når toget forlater området.
Hvor
4.2.2 Anskaffelse av data
Anskaffelse av valideringsdata innebærer å hente data både fra det virkelige systemet
og simuleringsmodellen. Chuan (2004) forklarer at dette kan gjøres på to ulike måter:
Individuell enhetsdata eller hele systemet og modelldata.
Individuell enhetsdata går ut på å samle data for individuelle enheter som går
gjennom systemet og gjennom modellen. For en produksjonsbedrift kunne dette for
eksempel være å notere tiden det tar fra ordren er mottatt til produktet er ferdig det
virkelige systemet.
Den andre metoden er data for hele systemet og modellen. I denne metoden vil all
informasjon om prosessen bli observert og lagret i en gitt tidsperiode. Deretter vil et
gjennomsnitt for alle operasjonene bli utregnet. Denne måten krever mye mer data
enn den individuelle metoden.
Mens Chuan (2004) mener at det er to forskjellige måter å innhente operasjonelle data
forklarer Chung (2004) at det er mange forskjellige kilder for å anskaffe inndata
∑
36

- Historiske data
Dersom basissystemet har eksistert over en lengre periode er det
sannsynlig at historiske data er tilgjengelig. Dette er en attraktiv måte å
samle data ettersom en slipper å samle inn sanntidsdata, men bruk av
historiske data er ikke uten risiko. Basissystemet kan ha endret seg slik at
dataene ikke lenger er korrekte. Et annet problem er at historiske data ikke
er innsamlet spesifikt med tanke på simulering, og det kan bety at dataene
som behøves for simuleringsprosessen ikke er tilgjengelig.
- Spesifikasjoner fra fabrikant
Tillater brukeren å anskaffe data som andre har innhentet. De fleste
fabrikanter har teoretiske data som er tilgjengelige, men må valideres før
de kan brukes.
- Leverandører
Leverandørene vil ha kunnskap om systemet som blir vurdert og enkelte
fabrikanter krever at leverandørene lager en simuleringsmodell som
beviser utstyrets evne.
- Estimat fra operatør
Operatørene som kjenner utstyret kan estimere ytelsen av systemet som
kan brukes som inndata data.
- Estimat fra administrasjon
Brukeren kan også bruke ingeniører som har kunnskap om systemet til å få
et estimat.
- Automatisk datainnsamling
Det er mulig med automatisk datainnsamling. Dette brukes i jernbanen.
Når et tog passerer et punkt, vil det automatisk lagres i en database. Ut i
fra den kan man se om et tog er i rute eller ikke.
- Direkte observasjon
Dette er når brukeren eller andre fysisk ser på systemet og henter data.
Kan være vanskelig og kostbart.
I følge Yuan (2008) kan innsamling og forberedelse av forsinkelsesdata til statistisk
analyse av togforsinkelser skje på forskjellige måter. Manuell registrering av
ankomst- og avgangs-tider ved plattformspor er en mulighet, men metoden er mindre
nøyaktig enn automatisk registrering ved hjelp av GPS enheter om bord togene.
Problemet med automatisk registrering er at tiden ikke tas ved plattformen, men ved
innkjørs-signal og utkjørs-signal. Dette er noe som må tas hensyn til når dataene skal
brukes ettersom alle tog ikke nødvendigvis stopper på alle stasjoner. Det vil være stor
forskjell på tiden til et tog som har stoppet ved en stasjon i forhold til et tog som bare
passerer stasjonen.
4.2.3 Evaluering av statistisk inndata
I følge Law & Kelton (2000) finnes det to typer validering. Den første er såkalt face
validering som betyr at modellen, i det minste på overflaten, representerer
virkeligheten. Den andre er statistisk validering som involverer en kvantitativ
37

sammenligning mellom output fra virkeligheten og modellen. Face validering vil ikke
bli utført i denne oppgaven, men det vil i 8.1 bli forklart hvordan NSB kalibrerte
OpenTrack modellen for Jærbanen, og i 8.2 vil statistisk input i OpenTrack bli
vurdert.
Statistisk validering involverer en objektiv og kvantitativ sammenligning mellom det
virkelige systemet og simuleringsmodellen. Hvis det ikke er statistisk signifikans
mellom datasettene er modellen holdbar. Statistisk signifikans vil si at en fordeling av
observasjoner i en vitenskapelig studie som med en nærmere angitt sannsynlighet ikke
kan antas å skyldes tilfeldige variasjoner i forhold til den oppstilte nullhypotesen
(Law & Kelton, 2000).
I figuren under viser Chung (2004) at man begynner med å samle og observere data.
Etter at dataene er samlet inn er det viktig å undersøke homogeniteten til dataene.
Denne undersøkelsen kan gjøres for hver togserie, forskjellige dager og rush/ikkerush.
Det er også viktig å ta størrelsen til utvalget i betraktning, hvis ikke det er stort
nok er det ikke statistisk gyldig.
Observere Input
data
Tilpasse data til
teoretisk fordeling
Figur 7 Role of theoretical probability distributions in simulations (Chung, 2004)
Generere data fra
statistisk fordeling
for å drive
simulering
Chung (2004) forklarer viktigheten med å tilpasse data til en statistisk fordeling: Den
fundamentale årsaken er når brukeren anskaffer data blir bare deler av det totale
utvalget innsamlet. Selv om brukeren ikke observerer enkelte verdier betyr det ikke at
det finnes andre verdier som eksisterer i systemet. Ved å tilpasse dataene til en
statistisk fordeling vil alle dataverdiene fra fordelingen bli inkludert i
simuleringsmodellen. Dette gir en mye mer realistisk simulering enn hvis en bare
bruker observerte data. En svakhet med denne framgangsmåten er at det kan være at
fordelingen genererer verdier som ikke finnes i det ekte systemet, dette skjer derimot
veldig sjeldent.
For å modellere forplantningen av togforsinkelse i et jernbanenettverk defineres
”initial delay” ved grensene til nettverket som modelleres. Det er nødvendig å vite
hvilken fordeling de forskjellige forsinkelsene har. En passende fordeling av et data
sett kan bli valgt på bakgrunn av de fysiske egenskapene av de tilsvarende tilfeldige
variablene. Dette er ofte vanskelig fordi en ikke kjenner alle egenskapene når
variablene representerer et resultat av mange kompliserte prosesser påvirket av
menneskelig oppførsel. En annen måte er å se på et datasett og analysere det for å
finne fordelingen. Dette kan gjøres ved hjelp av et histogram, siden det viser formen
på fordelingen (Yuan, 2008).
38

Yuan, Goverde & Hansen (Yuan et al., 2006) skriver i sin konklusjon at log-normal
fordeling betraktes som den beste fordelingen for forsinkelse ved ankomst både ved
plattform og ved innkjørs-signal, mens det er Weibull fordeling som gir best
tilpasning for ikke-negative forsinkelse ved ankomst og avgangsforsinkelse. Men de
hevder at eksponentiell fordeling kan brukes som en tilnærming for ikke-negative
forsinkelse ved ankomst og avgangsforsinkelse hvis tettheten er minskende.
Når dataene er tilpasset en statistisk fordeling brukes de genererte dataene som
inndata i simuleringsmodellen. I kapittel 7.2 blir det forklart hvordan forsinkelsesdata
ble samlet inn for denne oppgaven.
4.3 Kalibrering
Lindfeldt & Sipilä (2009) forklarer at en generell ide av kalibreringsarbeidet er å finne
faktorer som gir god nøyaktighet under varierende drift. Hvis dette er oppnådd betyr
det at mekanismen bak operasjonen er nøyaktig tatt opp av simuleringsmodellen og
kan brukes til å evaluere effekten av alternative endringer av driften.
Kalibrering av simuleringsmodellen foregår ved å simulere med kjent infrastruktur og
kjente ruteplanparametere. Simuleringen er brukt for å kalibrere algoritmene, spesielt
de som omhandler signaler, sikkerhetssystemer og andre regler for driften. Når den
kalibrerte simuleringen ligner på infrastrukturen og driftsytelsen er det mulig å
simulere fremtidige scenarioer med endrede parametere (Siefer, 2008).
Existing
operation
Future demands
Calibration and validation of
simulated model
Operational
space
Experimental
Design
Theory
Figur 8 Working scheme (Lindfeldt, 2010)
Experiment
setup
Simulation
experiments
Metamodels
(RSMs)
Figur 8 viser et arbeidsdiagram for et studie om “Innvirkningen av infrastruktur,
ruteplan og avvik i driften av dobbeltspor jernbanelinjer med blandet trafikk”. Her ble
kunnskap fra den eksisterende driften brukt for å kalibrere og validere en
simuleringsmodell og for å generere ideer for forbedring av driftsområdet. Når det er
gjort var det mulig ved hjelp av “Experimental Design Theory” å sette opp et
39

eksperiment. Den kalibrerte simuleringsmodellen ble så brukt for å simulere
eksperimentene for å undersøke for eksempel avvik og forstyrrelser.
Lindfeldt & Sipilä (2009) fulgte prosedyren i Figur 9 når de kalibrerte vestre
hovedlinje fra Stockholm til Göteborg i den svenske jernbanen, prosedyren ble utført i
tre deler:
- Forberedelse av simuleringsmodellen og oppbygning av den første
eksperimentserien
- Suksessivt kalibreringsarbeid med forfinet eksperimentserier
- Evaluering og validering
Construction of infrastructur model
Construction of a representative timetable
Compilation of delay statistics to form
disturbance distributions
Choice of factors for initial experiment
Simulation with proposed optimal factor level
combination (calibration set up)
Simulation for validation
Figur 9 Kalibreringsskjema (Lindfeldt & Sipilä, 2009)
Choice of factors to include in the experiment
Choice of interval of variation of each other
Construction of experimental design
Simulation experiments
Evaluation through Response Surface
Methodology
Refinement of factors and intervals
No Yes
Under forberedelsen, øverst til venstre i Figur 9, ble infrastrukturen konstruert, en
representativ ruteplan utarbeidet og forsinkelsesdata innhentet. Det ble også valgt et
sett med faktorer for det første kalibreringseksperimentet, de faktorene var:
1. Forlengelse av kjøretid for passasjertog
2. Forlengelse av kjøretid for godstog
3. Tilleggs tilgjengelighet for passasjertog
40

4. Tilleggs tilgjengelighet for godstog
5. Forsinkelsesgrense for nedsetting av prioritet for høyhastighetstog
6. Forsinkelsesgrense for nedsetting av prioritet for andre passasjertog
7. Forsinkelsesgrense for nedsetting av prioritet for godstog
Selve kalibreringsarbeidet involverte valg av variasjonsintervall for hver faktor,
konstruksjon av eksperimentdesign, simulering av eksperimentene gitt designet og
evaluering ved hjelp av Response Surface Methodology. Kalibreringsloopen, høyre
del av Figur 9, ble repetert tre ganger og etter det første og andre eksperimentet ble
faktorene og deres intervaller justert for neste eksperiment.
Etter de tre eksperimentene ble et sett av faktorer akseptert og testet i den kalibrerte
modellen. Disse faktorene ble til slutt simulert i den validerte modellen, for eksempel
med en helt annen forsinkelsesfordeling.
I kapittel 8.1 vil det bli forklart hvordan NSB kalibrert OpenTrack modellen for
Jærbanen.
4.4 Simulere drift
I følge Siefer (2008) er første steg i simuleringsprosessen å konstruere en konfliktfri
ruteplan med en tidsbuffer som er stor nok til at forsinkelse fra ett tog ikke innvirker
på andre tog. Etter dette er oppnådd kan man legge på forsinkelse på den konfliktfrie
ruteplanen. Forsinkelsen kan hentes fra historiske data som er innsamlet eller på
bakgrunn av estimater fra mennesker som har kunnskap om driften.
Når dette er oppnådd starter arbeidet med å simulere om ruteplanen er robust eller
ikke. I de fleste tilfellene er det antall tog som er i rute som indikerer kvaliteten på
ruteplanen. Prosentvis andel av forsinkete tog (liten forsinkelse, medium forsinkelse,
stor forsinkelse) kan bli brukt som en indikator på robustheten til ruteplanen (Siefer,
2008).
Simulering av driften gir planleggerne muligheten til å forutse kvaliteten til driften og
punktligheten og gir også planleggerne store mengder informasjon om flaskehalser i
infrastrukturen, årsaken til forsinkelse, forplantning av forsinkelse, eller indikasjoner
på kvaliteten og stabiliteten til ruteplanen. I tillegg gir det muligheten å undersøke
forskjellige varianter av infrastrukturer og operasjonelle strategier. Fra den
konfliktfrie ruteplanen er det nødvendig å simulere et sted mellom 50 og 200 fordelte
simuleringer, hvor hver simulering representerer en dag med forskjellige avvik, for at
den skal være statistisk korrekt (Siefer, 2008).
4.5 Analyse av resultater
I mange simuleringsstudier blir masse tid og penger investert på bygging og
programmering av modellen, mens lite krefter brukes på å evaluere det som kommer
ut av simuleringen. Det er vanlig at det bare blir utført én simulering for så å gå ut i
fra at simuleringen er korrekt (Law & Kelton, 2000). Dette er ikke en statistisk
korrekt måte å utføre en analyse.
41

Law & Kelton (2000) hevder at de to viktigste objektivene med å analysere output er
å fastslå den absolutte ytelsen til et systems konfigurasjon og å sammenligne
alternative konfigurasjoner i forhold til virkeligheten.
Siefer (2008) nevner de vanligste evalueringene av en simulering som:
- Gjennomsnittlig forsinkelse per tog
- Gjennomsnittlig forsinkelse per forsinket tog
- Gjennomsnittlig sekundærforsinkelse per tog
- Antall forsinkete tog
- Prosentvis antall forsinkete tog
- Punktlighet
- Forplantning av forsinkelse mellom stasjoner
Mens Siefer (2008) fokuserer mest på forsinkelse nevner Martin (1999) noen andre
former for evaluering. Det kan være sporbruk, som gjennomsnittsfart på sporet eller
antall tog som har brukt sporet. Hvordan signalsystemet oppfører seg og maks- og
gjennomsnittshastighet til tog.
42

Del 3
5 OpenTrack
Dette kapittelet inneholder en introduksjon til OpenTrack, simuleringsprogrammet
brukt i forbindelse med denne oppgaven.
Informasjon om oppbygningen og funksjoner i OpenTrack er hentet fra
brukermanualen som følger med programmet, skrevet av Huerlimann & Nash (2010)
OpenTrack er et simuleringsprogram designet for jernbanen. OpenTrack ble utviklet i
perioden 1995-2000 som et forskningsprosjekt av Dr. Daniel Huerlimann ved ETH.
Den første versjonen, 1.0, ble utgitt i 2000. Siden den gang har OpenTrack
gjennomgått en kontinuerlig forbedring basert på tilbakemelding fra brukerne. I 2006
ble bedriften OpenTrack Railway Technology GmbH dannet som et datterselskap av
ETH.
Figur 10 viser oppbygningen til OpenTrack.
Figur 10 Oppbygning av OpenTrack (Huerlimann & Nash, 2010)
OpenTrack bruker rullende materiell (lokomotiver & vogner), Infrastruktur (skinner,
signaler etc.) og ruteplan som inndata. Etter endt simulering tilbyr OpenTrack mange
forskjellige typer output. Mange forskjellige diagrammer, toggraf, sporbeleggingstid
og diverse statistikk. Det gir ulike måter å analysere togdriften på, og gjør det lettere å
43

oppdage feil både i ruteplan og signaler. Gjennom toggrafen er det også mulig å endre
ruteplanen manuelt.
5.1 Inndata
OpenTrack bruker rullende materiell (lokomotiver og vogner), infrastruktur (skinner,
signaler, etc.) og ruteplan som inndata.
5.1.1 Rullende materiell
Et tog består av lokomotiv og vogner. OpenTrack bruker som sagt rullende materiell
som inndata i modellen, og dette gjøres gjennom tre forskjellige funksjoner. De ulike
funksjonene diskuteres i de avsnittene.
Engines
OpenTrack administrerer lokomotiver i en database som kalles Depot. Funksjonen
Engines brukes for å legge inn eller endre lokomotivdata i databasen, hvor
lokomotivdata består av trekkraftkurve, lengde, makshastighet, vekten på toget,
adhesjonsvekt, motstandskraft, etc.
For denne oppgaven har toget Z71 blitt lagt inn i Engines. Z71 er et kipptog som
kjører mellom Sundhaugen og Holmen/Brakerøya på grunn av at godstogene er for
lange for sidesporene.
Trains
I funksjonen Trains ligger alle forskjellige kombinasjonene av lokomotiv og vogner
som skal brukes i simuleringen. For eksempel ligger togtype BM69D i denne
funksjonen både som BM69D-E og BM69D-D, hvor den første er et BM69D –
enkeltsett, mens den siste er et BM69D dobbeltsett.
I Trains må togtypen defineres (Intercity, Lokaltog, Fjerntog, Godstog osv.). I tillegg
legges lengde, vekt, akselerasjon, retardasjon, og maksimal hastighet inn.
Det har i denne oppgaven blitt lagt inn tre tog i Trains kategorien som ikke var lagt
inn av NSB fra før av, disse togene er
- Z71 – Tomme vogner
- Z71 – Fulle vogner
- Godstog
Hvor Z71 – Tomme vogner er kipptog som kjører fra Sundhaugen mot
Holmen/Brakerøya, Z71 – Fulle vogner er kipptog som kjører til Sundhaugen fra
Holmen/Brakerøya, og Godstog er godstog. Årsaken til at det er laget to forskjellige
kipptog er at det gir en mer realistisk simulering, hvor togene som kommer fra
Holmen/Brakerøya kjører saktere enn tog som kjører motsatt vei.
44

Godstogene har en maksimal vekt på 750 tonn, dette skyldes at godstogene ikke
klarer å komme opp Brynsbakken hvis vekten overskrider maksimalvekten.
Godstogene har derfor i OpenTrack gitt en vekt på 750 tonn.
Train Categories
Den siste funksjonen som OpenTrack bruker for rullende materiell er Train
Categories. Ved hjelp av denne funksjonen kan man definere forskjellige
togkategorier som Intercity, Lokaltog, Fjerntog, osv. og gi de forskjellige attributter.
Man kan gi de forskjellige togkategoriene prioritet, startforsinkelse,
ytelsesfordelinger, stasjonsforsinkelse og definere forsinkelse.
I denne oppgaven har det blitt laget to togkategorier som ikke var laget av NSB på
forhånd. Disse er Kipptog og Godstog.
5.1.2 Infrastruktur
Infrastrukturdata består av en beskrivelse av den fysiske infrastrukturen som blir
simulert. Dette inkluderer virkelig infrastruktur som spor (i OpenTrack kalles disse
for “Edges” ), signaler og stasjoner, i tillegg til virtuelle elementer som vertekser og
linjer (i OpenTrack kalles disse “Vertices” og “(Routes”)
Infrastrukturen blir bygget ved hjelp av “Edges” og “Vertices”. En verteks markerer
punktet hvor minst en attributt endres (gradient, radius, hastighet) eller hvor det er et
signal.
Figur 11 Edge og Vertices (Huerlimann & Nash, 2010)
Stasjoner
OpenTrack administrerer stasjonsdata på to måter; den første er gjennom en
stasjonsdatabase som inneholder all nødvendig informasjon om stasjonen, den andre
er i selve infrastrukturen, hvor det blir definert en stasjon, som man må linke til
stasjonsdatabasen, og et stasjonsområde. En stasjon kan ikke bli plassert i
infrastrukturen før den ligger i stasjonsdatabasen.
Signaler
OpenTrack bruker forskjellige signaler; signaler som endrer informasjon (lyssignaler,
baliser), og signaler som viser stopp posisjon. Lyssignalene blir videre delt opp i
hovedsignal, forsignal, kombinert signal (kombinasjon av hovedsignal og forsignal)
og skiftesignal. Hovedsignalet kan videre deles opp i innkjør-signal, utkjør-signal og
blokksignal.
Signalene som viser stopposisjon viser posisjonen på en stasjon hvor toget skal
stoppe. Under simulering vil et tog stoppe ved dette signalet.
45

Relatert infrastruktur
Det finnes tre forskjellige relaterte termer til infrastruktur, disse er “Route”, “Path” og
“Intinerary” hvor høyere nivåer består av serier av lavere nivåer.
Route
En route er det laveste nivået for togbevegelser. Disse består av et sett med
“Verticies” og “Edges” som er forbundet. Det kan bli sett på som et sett med spor. En
route går fra et signal til et annet.
Path
Det neste nivået er path, som består av en serie med routes. Disse kan bli sett på som
en gruppe med spor innenfor et område, for eksempel sporene som et tog ville brukt
for å passere gjennom en stasjon
Itinerary
Det øverste nivået er itinerary som består av en serie med paths. Disse viser mulige
togbevegelser gjennom modellen. Et tog har gjerne flere itineraries, dette gjør at et tog
kan velge et annet spor hvis sporet er okkupert av et annet tog, for eksempel på
Drammen stasjon kan et tog bruke spor 2 hvis spor 1 er opptatt.
For denne oppgaven har Holmen sidespor, Brakerøya sidespor, Sundhaugen og
Skamarken blitt bygget på NSB sin modell, samt alle routes, paths og itineraries for
alle togene som kjører i modellen. I tillegg har stasjonene Skamarken, Sundhaugen,
Brakerøya, og Holmen blitt definert i stasjonsdatabasen og på selve infrastrukturen.
5.1.3 Ruteplan
Ruteplan består av informasjon om bevegelsene til toget, som legges inn i funksjonen
“Timetable” i OpenTrack. Denne informasjonen inkluderer ønsket ankomst- og
avgangstid på stasjoner, forbindelsesinformasjon, minimum stopp tid på stasjoner, og
hvilke stasjoner toget stopper ved.
I denne oppgaven er det brukt NSB sin foreslåtte ruteplan for 2012, i tillegg har det
blitt lagt inn godstog, kipptog og all nødvendig forbindelsesinformasjon.
5.2 Simulering
Målet med en simulering i OpenTrack er at de brukerdefinerte togene skal oppfylle
den brukerdefinerte ruteplanen på den brukerdefinerte infrastrukturen. OpenTrack
bruker en miks mellom diskret og kontinuerlig metode, hvor togbevegelsene er
kontinuerlig modellert mens signalene er diskret modellert.
Det er mulig å simulere det tidsrommet man ønsker, og man kan simulere 200
forskjellige scenarioer.
46

Simuleringen kan bli utført normalt eller animert, hvor man i animert simulering ser
togene kjøre, med de tilhørende reservasjonene av spor og signaler.
For å gjøre simuleringen mer realistisk er det mulig å gi togene en forsinkelse, enten
det er for hele togkategorier eller for hver linje. Det er også mulig å bruke en funksjon
som heter “Incidents”; som navnet tilsier er det hendelser som kan skje ved daglig
togdrift, slike hendelser kan være signalfeil som enten fører til stans i togdriften en
periode eller at et spor har nedsatt hastighet på grunn av vedlikehold på linjen. Det er
brukt forskjellige slike funksjoner for å gjøre simuleringen mer realistisk, disse
hendelsene vil bli forklart mer detaljert senere i oppgaven, hvor de er tatt i bruk.
5.3 Output
OpenTrack tilbyr forskjellige former for evaluering, og disse evalueringene kan være
fra forskjellige perspektiv som per tog, per linje eller per stasjon. For hver simulering
får hvert tog en virtuell ferdsskriver som lagres i output-databasen som for eksempel
akselerasjon, fart og distanse.
Man velger i forkant av hver simulering hvilken output man ønsker fra
simuleringsvinduet. Etter endt simulering kan man gå inn i output databasen og
evaluere simuleringen. Som tidligere nevnt er det mulig å evaluere per tog, per linje
eller per stasjon. En svakhet med OpenTrack er at det tilbyr lite output hvis man
gjennomfører flere simuleringer etter hverandre med forskjellige
forsinkelsesscenarioer, det er da bare ruteplanstatistikk som gjelder for alle
simuleringene, mens alle andre evalueringer kun gjelder for siste simulering. Som et
eksempel vil det i et tilfelle hvor man gjennomfører 20 simuleringer vil det kun være
ruteplanstatistikken som gjelder for alle simuleringer, mens all annen evaluering kun
gjelder simulering nummer 20.
47

6 Drammens-området
Det vil i dette delkapittelet bli gitt en gjennomgang av Drammen stasjon og området
rundt, før det gis en hovedproblemstilling for simuleringsdelen.
Fra oppgaveteksten heter det ”NSB skal øke produksjonen kraftig frem mot 2012 og
har blant annet kjøpt inn nye lokaltog for å møte veksten. Desember 2012 skal det
derfor innføres en ny grunnrutemodell for østlandsområdet.”
Drammens-området er en viktig del av den nye grunnrutemodellen. I tillegg til vanlig
persontogtrafikk er det også godstogtrafikk og kipptogtrafikk rundt Drammen stasjon.
Dette øker kompleksiteten ettersom det er store forskjeller på hastigheten til togene.
Passasjertog har høyest hastighet, mens kipptogene har lavest hastighet. Ifølge
Lindfeldt (2010) reduseres kapasiteten i jernbanenettverket på grunn av de
forskjellige hastighetene.
Figur 12 Kart over Drammens-området (Finn.no AS, 2010)
Bildet over viser de sentrale delene av Drammens-området. Persontogene fra Oslo
kjører gjennom Drammen stasjon, der sporet deler seg til Sørlandsbanen og
Vestfoldbanen. Godstog til Oslo kommer fra Sundhaugen gjennom Drammen stasjon.
Kipptogene kjører fra Sundhaugen gjennom Drammen stasjon til Holmen sidespor
eller Brakerøya.
Persontogene som kjører er:
Linje 002 Drammen – Eidsvoll – Lillehammer (3xx)
Linje 003 Larvik – Eidsvoll (8xx)
Linje 440 Drammen – Dal (16xx)
Linje 450 Kongsberg – Eidsvoll (5xx)
48

Flytog Gardermoen – Drammen (3xxx)
I tillegg er det fjerntog som kjører fra/til Oslo fra/til Bergen eller Kristiansand.
Figur 13 OpenTrack modell
Ovenfor vises området som skal undersøkes i denne prosjektoppgaven. Pilene viser
fortsettelsen av sporene, øverste er sporet til Sørlandsbanen, mens den andre pilen
viser sporet til Vestfoldbanen. De røde sirklene viser hvor togene introduseres i
modellen. Tog fra Sørlandsbanen introduseres ved Daler, tog fra Oslo introduseres
ved Eriksrud, og tog fra Vestfoldbanen introduseres ved Kobbervik.
49

Figur 14 Drammens-området i OpenTrack
I sin rapport om ”kipptogkjøring mellom Sundland og Holmen/Brakerøya” forklarer
Skartsæterhagen (2009) at strekningen Asker-Drammen vil få vesentlig økt trafikk og
anstrengt kapasitet med R2012, i tillegg har delstrekningen Brakerøya-Drammen
vesentlig flere tog enn strekningen Asker-Brakerøya fordi det går hyppige kipptog
mellom Sundland og havneanleggene på Brakerøya og Holmen. Anleggene på
Holmen og Brakerøya er ikke lange nok til at det kan kjøres hele tog til/fra disse
anleggene. Godstogene kjøres derfor til/fra Sundland, og det kjøres kipptog mellom
Sundland og anleggene på Holmen og Brakerøya.
Denne kipptogtrafikken slik den drives i dag, er ikke forenlig med tett rutetrafikk slik
det planlegges i R2012. Det er ganske enkelt ikke mange nok og lange nok tidsluker i
R2012. Situasjonen forverres ved at det forventes økning i godstrafikken til/fra disse
sidesporene.
50

6.1 Drammen stasjon
Figur 15 Drammen stasjon med sidespor (Jernbaneverket, 2010b)
Figur 16 Spor på Drammen stasjon (Jernbaneverket, 2010b)
På Drammen stasjon er det 6 spor, men bare spor 1-5 har adkomst til plattform. Det
vil si at spor 6 ikke kan brukes til persontogtrafikk. Modellen i OpenTrack er noe
forenklet fra virkeligheten. For eksempel er Skamarken bare ett spor i OpenTrackmodellen,
og Sundhaugen består bare av to spor. Dette er fordi det i dette prosjektet er
gått ut i fra at skiftebevegelser som gjøres på Sundhaugen ikke skaper konflikt med
andre tog.
51

Figur 17 Drammen stasjon i OpenTrack (spor 1 er nærmest stasjonshuset)
I følge Skartsæterhagen (2009) kan Drammen stasjon – togvegmessig – regnes som
delt i to deler: spor 1-3 og spor 4-6. Disse to delene kan stort sett opereres uavhengig
av hverandre. Innen hver del er det få muligheter for samtidige togbevegelser med
mindre det involveres togveg fra vest til spor 1, fordi denne har dekning v.h.a.
vekselen til Tangen sidespor.
Drammen stasjon har togekspeditør eller såkalt Txp, en Txp er: En person på
stasjonen som har ansvar for å ivareta nødvendig sikkerhet i togframføring på og
til/gjennom stasjonen. Personen som er Txp har et to cm. bredt rødt bånd på
uniformsluen (Svingheim, 2006, [Internett])
6.2 Sundland
På Sundland finnes det et verksted hvor det utføres reparasjoner, ombygging og
vedlikehold. I tillegg er det en driftsbanegård, som vil si at det er et sted for
driftpausebasert vedlikehold, mindre reparasjoner og komponentbytte
(Jernbaneverket, 2010b). Under er en skjematisk sporplan for fordelingssporgruppen.
52

Figur 18 Sundland skiftestasjon (Jernbaneverket, 2010b)
På Sundland kjører kipptogene til/fra Holmen/Brakerøya fordi godstogene er for
lange for sporene på havneterminalene. Da står godstogene og venter på at kipptogene
henter vogner på Holmen/Brakerøya før de kan kjøre videre mot Oslo. Godstog som
kommer kjørende fra Oslo kjører også inn på Sundland før de fortsetter. I tillegg skjer
det vending og hensetting av tog på disse sporene. I denne oppgaven vil ikke
Sundland være modellert i sin helhet. Kipptog og godstog starter og terminerer på
Sundhaugen, mens persontog starter og vender fra Sundhaugen, (se Figur 19).
53

Skiftebevegelser for persontogene vil ikke bli modellert på Sundhaugen ettersom de
foregår uten forstyrrelse for annen trafikk.
Figur 19 Sundland & Sundhaugen i OpenTrack
6.3 Holmen sidespor
Ved kjøring til/fra Holmen kjører kipptogene i spor 1 både til og fra Holmen. Det vil
si at på vei tilbake fra Holmen kjører de i feil spor. I tillegg er det en usikret
planovergang inne på Holmen sidespor (HMS) som, i følge kipptogførere, ikke
respekteres av bilførere. Dette medfører at kipptogene kjører i 10km/t over
planovergangen. Hvis kipptogene er lange stikker bakdelen av toget ut på hovedsporet
og reserverer sporet lenger enn nødvendig (Skartsæterhagen, 2009).
Figur 20 Holmen stasjon i OpenTrack
6.4 Brakerøya sidespor
På Brakerøya er det to sidespor, østre og vestre. Ved skifting til østre ende kan det
skifte seg inn og ut av sidesporet uten å forstyrre trafikken på hovedsporene.
I vestre ende derimot, går det ikke an å komme inn på sidesporet mens kippen står i
spor 3 fordi avgreningen til sidesporet ligger rett ved middel og utkjørs-signal mot
vest. Da må kipptoget ut i hovedsporet Drammen – Asker for å komme inn på
sidesporet, og Dermed må lokfører først ringe togleder som frigir sidesporet for lokal
skifting. Kippen kjører da ut i hovedsporet Drammen – Asker inntil hele toget er ute i
hovedsporet fordi sidesporet ligger i Drammensenden av Brakerøya. Østre og vestre
sidespor er bare forbundet via spor 3 på Brakerøya. Ofte skal kipptogene flytte vogner
mellom disse to områdene og hver gang dette skjer må det skiftes ut i hovedsporet
som omtalt ovenfor. Når og hvor mange ganger dette skal gjøres for det enkelte
kipptog vet ikke togleder noe om på forhånd. Han får kun beskjed om det på telefon
fra lokfører (Skartsæterhagen, 2009).
54

Figur 21 Brakerøya sidespor i OpenTrack
Det er klart at Drammen stasjon er en viktig stasjon når ruteplan R2012 skal
implementeres. Derfor er det viktig å undersøke robustheten til Drammen stasjon. Det
vil først bli vist hvordan NSB kalibrerte OpenTrack modellen på Jærbanen før
statistiske inndata fra ANNA blir validert. Etter dette vil det bli utført en
robusthetsvurdering av Drammens-området spesielt Drammen stasjon, med
hovedproblemstillingen ” kommer togtrafikken til å fungere tilfredsstillende etter en
planendring, og hvis ikke, hva kan vi gjøre for å bedre sannsynligheten for at det
fungerer?”
55

Del 4
7 Konstruering av ruteplan og forberedelse av
operasjonelle data
Dette kapittelet starter med å evaluere den foreslåtte ruteplanen for 2012 for så å
forklare hvordan operasjonelle data ble innhentet i denne oppgaven.
7.1 Konstruere ruteplan
NSB jobber med å konstruere ruteplanen for 2012. Men kipptog og godstog er enda
ikke lagt inn i denne ruteplanen, fjerntogene har fått tildelt en slott, men det er ikke
bestemt hvor mange fjerntog som skal gå i hver retning. Det er derfor i denne
prosjektoppgaven funnet plass for 20 kipptog, 20 godstog og 24 fjerntog. Aktuelle
ruteleier finnes i vedlegg A.
I tillegg til å finne plass for togene er det også nødvendig å legge inn såkalte
skiftebevegelser for togene. Et eksempel på dette er at et tog som ender ved Drammen
stasjon må kjøre til Sundhaugen for å snu og eventuelt sette fra seg eller legge til
vogner. Disse bevegelsene står ikke i ruteplanen, men kan hindre andre tog, og er
derfor viktig å få med i simuleringen. For denne prosjektoppgaven er det lagt inn
skiftebevegelser for flytog, 16xx-tog og 3xx-tog. Flytogene snur i spor 3 på Drammen
stasjon, 16xx- tog snur på Sundhaugen stasjon mens 3xx togene snur på Skamarken
stasjon. 16xx-togene har endestasjon på Drammen stasjon, men de må kjøre til
Sundhaugen for å snu. 3xx-togene har også vendestasjon på Drammen stasjon, men
snur på Skamarken. I tillegg må enkelte 3xx-tog kjøre til Flissporet for å hensette tog
og sette sammen tog, også disse skiftebevegelsene er lagt inn i OpenTrack. I tillegg til
at Flytoget vender i spor 3 er det noen tomtog som kjører til Drammen stasjon for å
starte ruten der. Disse tar også opp kapasitet på nettet og er derfor også lagt inn i
OpenTrack.
Første simulering i denne prosjektoppgaven er utført for å undersøke om den originale
ruteplanen er konfliktfri. Det viser seg at det er for store forsinkelser til at ruteplanen
kan kalles konfliktfri. Minimum Wait ble derfor redusert. Minimum Wait er minimum
tidslengde et tog må vente ved plattform for å slippe av/på passasjerer, så hvis et tog
har definert 60 sekunder Minimum Wait må toget i OpenTrack minimum bli stående
ved plattform i 60 sekunder. Det er innebygget slakk i ruteplanen som betyr at et tog
har mulighet til å kjøre inn forsinkelse. Denne slakken gjelder også ved
stasjonsopphold. Ved at Minimum Wait verdiene var satt som like lenge som et tog
skal, etter ruteplanen, være ved stasjonen mister togene mulighet til å nyttiggjøre seg
av denne slakken ved stasjonsopphold. Minimum Wait verdiene ble derfor redusert
med 60 sekunder på Drammen stasjon for alle tog eksklusiv de som har endestasjon
på Drammen stasjon. Alle tog som hadde Minimum Wait på 240 sekunder har nå 180
sekunder, tog som hadde 180 sekunder har nå 120 sekunder, og tog som hadde 120
sekunder har nå 60 sekunder.
56

Etter reduseringen av Minimum Wait ble antall forsinkelser redusert, men ruteplanen
er fremdeles ikke konfliktfri. Det oppstår en konflikt mellom togene 815 og 866.
Figur 22 viser toggraf mellom Kobbervik og Brakerøya i perioden 07:30 – 08:30.
Svart strek viser planlagt rute, mens oransje strek viser faktisk kjørt. For bedre
oversikt viser toggrafen i dette tilfellet kun Intercity tog. Fra toggrafen kan man se
konflikten mellom togene 815 og 866. 815 ankommer Drammen fra Oslo på rute, men
grunnet konflikten med tog 866, som ankommer fra Kobbervik må 815 vente ved
Drammen stasjon til 866 har ankommet. 815 får derfor en forsinkelse. Denne
forsinkelsen oppstår som en direkte årsak av konflikten i ruteplanen. Mellom
Kobbervik og Drammen er det enkeltspor, men i følge den planlagte ruteplanen skal
815 og 866 krysse hverandre på enkeltsporet. Noe som ikke er mulig.
Figur 22 Toggraf mellom Kobbervik og Brakerøya i perioden 07:30 – 08:30
57

Figur 23 Kumulativ forsinkelse ved endestasjon for alle tog
Konflikten med togene 815/866 er den eneste observerte konflikten. For at en ruteplan
skal være konfliktfri skal ruteplanen i seg selv ikke skape noen forsinkelser. Men som
en ser av Figur 23 er den kumulative forsinkelsesfordelingen ved endestasjon for alle
tog høyere enn den bør være for en konfliktfri ruteplan, noe som tyder på at
ruteplanen inneholder konflikter som fører til forsinkelser. Det er sannsynlig at en del
av forsinkelsene skyldes OpenTrack ettersom programmet ikke klarer å oppfylle
rollen som togleder. Det hender at OpenTrack for eksempel lar et saktegående kipptog
passere Drammen stasjon like før et persontog skal forlate Drammen stasjon, slik at
dette persontoget i tillegg til å forlate stasjonen etter ruteplan må kjøre bak det
saktegående kipptoget til Holmen eller Brakerøya. I virkeligheten ville togleder ha
holdt igjen kipptoget inntil persontoget har forlatt Drammen stasjon. OpenTrack lar
brukeren få lov til å endre på prioriteten til togkategorier gjennom såkalt Dispatching,
men denne funksjonen fungerer ikke optimalt og fører som regel til mer forsinkelse.
Det konkluderes med at ruteplanen fra NSB ikke er konfliktfri, men inneholder små
konflikter som fører til forsinkelser.
7.2 Forberedelse av operasjonelle data
Operasjonelle data er for denne prosjektoppgaven forsinkelsesstatistikk. Disse ble
hentet gjennom ANNA, NSBs automatiske system for avviksregistrering. Alle tog
som passerer en stasjon eller knutepunkt får registrert avviket fra ruteplanen i ANNA,
for eksempel vil et tog som passerer Brakerøya stasjon 8 sekunder etter ruteplanen få
registrert et avvik på 8 sekunder i ANNA. Det må tas hensyn til ved bruken av tall fra
ANNA at registreringen skjer ved innkjør- og utkjør-signaler og ikke ved selve
plattformen. Dette løses ved å trekke fra tiden det tar å kjøre fra innkjør-signalet til
plattformen. Denne forskjellen er ulike for hver linje ettersom noen linjer stopper på
stasjoner, mens andre linjer passerer.
58

Ettersom modellen er begrenset kommer togene fra Oslo inn ved Eriksrud stasjon, det
har derfor blitt hentet forsinkelser fra ANNA herfra, slik at togene som introduseres
ved Eriksrud i modellen har en forsinkelse som ville tilsvare den samme som i
virkeligheten. Eriksrud er en signalmessig stasjon, det vil si at det ikke er mulig for
på- og avstigning, men det er mulig for tog å snu og det er også et punkt hvor ANNA
registrerer avvik. For tog som kommer fra Sørlandsbanen introduseres togene ved
Daler stasjon og for tog fra Vestfoldbanen introduseres de ved Kobbervik stasjon. For
togene som vender på Drammen stasjon er det brukt NSB sine egne tall for
forsinkelsesfordelingene. Avvik for godstog og kipptog registreres ikke i ANNA
ettersom disse ikke er NSB sine tog, og de har dermed ikke tilgang på
forsinkelsesdata for disse. Hvordan dette ble løst blir forklart i punkt 8.2.2
Dataene er hentet fra perioden 1.1.2009 – 30.6.2009. Årsaken til det er at dataene må
være store nok for å være statistisk gyldige, og i tillegg er det viktig å finne et
intervall som er representativ for vanlig drift. Vinteren 2009 var en vinter med
unormalt mye forsinkelse og kansellasjoner, og ble dermed ikke valgt.
Linje 002 Drammen – Eidsvoll – Lillehammer kjører ikke den samme ruten i 2010
som planlagt i 2012, det finnes derfor ikke noe data for denne linjen. Det ble derfor, i
samtale med veileder, bestemt at Linje 002 skulle få samme forsinkelsesfordeling som
16xx togene ved Drammen stasjon og samme forsinkelse som 8xx togene ved
Eriksrud. For Linje 003 Larvik – Eidsvoll ble det ikke funnet nok data i ANNA ved
Kobbervik, og 8xx togene fikk derfor samme forsinkelsesfordeling som 16xx-togene
ved Drammen.
Dataene samlet inn fra ANNA ble sortert, og deretter plassert i prosentvis intervall
som så ble lagt inn i funksjonen “Distributions” i OpenTrack. I kapittel 8.2 vil data
hentet ut fra ANNA og lagt inn i OpenTrack sammenlignes med utdata fra
OpenTrack.
59

8 Kalibrering og validering av OpenTrack modell
Denne delen begynner med en forklaring av måten NSB kalibrerte sin OpenTrack
modell, og tar deretter for seg hvordan resultatet av kalibreringen innvirker på
modellen for Drammens-området. Til slutt blir statistisk inndata i modellen validert.
8.1 Hvordan NSB kalibrerte modellen
Informasjon om hvordan NSB kalibrerte OpenTrack modellen for Jærbanen er hentet
fra SMA (2010).
8.1.1 Bakgrunn
NSB har mest erfaring med kalibrering av Jærbanen, som går fra Egersund til
Stavanger, som de utførte i et samarbeid med et sveitsisk konsulentfirma ved navn
SMA und Partner AG.
OpenTrack-modellen for Jærbanen er basert på infrastrukturdata fra Jernbaneverket
(JBV). I modellen for Jærbanen brukes de samme materielltypene som NSB allerede
har kalibrert for modellen for Oslo-området, det er derfor naturlig å gå ut i fra at
materiellytelsen i modellen vil samsvare med virkeligheten.
Før kalibreringen beregnet NSB den akkumulerte forsinkelsesfordelingen for
endestasjonene i modellen basert på data for dagens ruteplan fra ANNA, NSBs
automatiske system for avviksregistrering. Denne fordelingen representerer dagens
situasjon som modellen skal gjenskape og danner dermed grunnlaget for
kalibreringen.
Når det gjelder forstyrrelser har NSB brukt samme variasjon på stasjonsopphold som
er observert på Østlandet. Forsinkelsesdata fra utgangsstasjonene og for tog som
kjører inn i modellområdet utenfra er hentet fra ANNA for persontogene og fra JBVs
TIOS-system for godstogene.
8.1.2 Kalibrering av Jærbanen
Målet med kalibreringen var å verifisere og sammenligne ruteplaner for den
implementerte OpenTrack modellen.
Kalibreringsarbeidet besto av å definere forsinkelsesfordelinger fra ANNA for
persontog og TIOS for godstog, hentet fra perioden 03/10 -7/10. Da det var gjort ble
det simulert 100 simuleringer med forskjellige forsinkelses scenarioer med forskjellig
total ytelse (overall performance). Etter endt simulering ble forsinkelsen på
endestasjon beregnet og sammenlignet med resultatet fra ANNA som NSB hadde
kalkulert før kalibreringsdelen.
Som man ser av figuren på neste side var den totale ytelsen som passet best med
virkeligheten 98 %.
60

Figur 24 Kumulativ forsinkelsesfordeling ved stasjoner for Jærbanen (SMA, 2010)
61

8.1.3 Kalibrering av OpenTrack modell for prosjektoppgaven
Det ble i samsvar med veileder avtalt at det ikke var nødvendig med en fullstendig
kalibrering av OpenTrack-modellen for Drammen. Dette er en tidkrevende og altfor
omfattende jobb og ettersom modellen som brukes for Drammens-området er bygd
opp på samme måte som Jærbane-modellen når det gjelder infrastruktur, materiell og
forstyrrelser vil det være rimelig å anta at modellen vil oppføre seg som Jærbanemodellen
og at vi i utgangspunktet vil få en god overensstemmelse mellom modell og
virkelighet så lenge vi nedjusterer totalytelsen i modellen. Det vil derfor for denne
prosjektoppgaven bli utført simuleringer med total ytelse på 98 %.
8.2 Validering av statistisk inndata fra ANNA
For å undersøke validiteten på forsinkelsesfordelingen lagt inn i OpenTrack ble det
simulert 194 ganger med ulike scenarioer for så å sammenligne output fra OpenTrack
med inndata fra ANNA, dette er utført i 8.2.1. Som tidligere nevnt finner man ikke
kipptog eller godstog i ANNA. Hvordan dette løses i denne prosjektoppgaven blir
forklart i detalj i 8.2.2
Ettersom kalibreringsdataene ble tilsendt forfatteren etter at simulering for validering
av statistisk inndata fra ANNA ble utført, har simuleringene for dette delkapittelet
blitt utført med total ytelse på 100 %.
8.2.1 Persontog
NSB har laget forsinkelsesfordelinger for 16xx-togene og flytogene ved Drammen
stasjon, og disse er brukt i denne prosjektoppgaven. I tillegg brukes
forsinkelsesfordelingen for 16xx-togene ved Drammen stasjon også for 8xx-togene
ved Kobbervik og 3xx-togene ved Skamarken, i henhold til forklaringen i 7.2
For de andre persontogene har hver linje fått sin egen forsinkelsesfordeling som er
delt i tre deler; morgenrush (06-09), ettermiddagsrush (15-17) og perioden 11-14,
hvor den siste delen er representativ for resten av dagen. Altså vil et tog som passerer
ankomststasjonen utenfor morgenrush eller ettermiddagsrush bli tildelt 11-14
forsinkelsesfordeling. Forsinkelsesfordelingen har blitt tildelt ved ankomststasjonen i
modellen. Etter endt simulering ble tallene fra ANNA sammenlignet med output fra
OpenTrack.
Under er en av de bedre sammenligningene, fra 5xx-togene som kjører fra Eriksrud
med forsinkelsesfordeling 11-14, som vil si i periodene utenom rush, og en av de
dårligere sammenligningene, fjerntog som starter ved Daler med forsinkelsesfordeling
Ettermiddag, som vil si ettermiddagsrush.
62

Prosentandel tog [%]
Figur 25 Forsinkelsesfordeling OpenTrack & ANNA for 5xx-tog ved Eriksrud i perioden 11-14
Prosnetandel tog [%]
12,0
10,0
8,0
6,0
4,0
2,0
0,0
25,0
20,0
15,0
10,0
5,0
0,0
ERU_5xx_11-14
10
20
30
40
50
60
70
80
90
100
110
120
130
140
150
200
250
300
400
500
750
1000
Forsinkelse [s]
DLR_Fjerntog_Ettermiddag
10
20
30
40
50
60
70
80
90
100
110
120
130
140
150
200
250
300
400
500
750
1000
Forsinkelse [s]
Figur 26 Forsinkelsesfordeling OpenTrack & ANNA for Fjerntog ved Daler i perioden Ettermiddag
Open Track (%)
ANNA (%)
OpenTrack (%)
ANNA
8.2.1.1 Goodness-of-fit – Test for homogenitet
Ettersom det er relativt store forskjeller på forsinkelsesfordelingene ble det valgt å
utføre en test for homogenitet.
Forsinkelsesfordelingene fra OpenTrack har blitt sammenlignet med tall fra ANNA
ved hjelp av en såkalt Goodness-of-fit test. Ved hjelp av en Goodness-of-fit test er det
mulig å undersøke om en populasjon har en spesifisert fordeling. Testen er basert på
hvor god passform det er mellom frekvensene av forekomster av observasjoner i den
observerte populasjonen og forventede frekvenser fra hypotesefordelingen (Walpole
et.al., 2007).
63

En Goodness-of-fit test mellom observerte og forventede frekvenser er basert på
størrelsen av
∑ )
Hvor er en verdi av en tilfeldig variabel, hvor variabelens fordeling er
tilnærmelsesvis lik Kji-kvadrat fordeling med ) ) frihetsgrader.
Symbolene og representerer observerte og forventede frekvenser, mens er
antall rader og er antall kolonner (Walpole et al., 2007).
Det er i dette tilfellet valgt å bruke testen “test for Homogenitet”, som er en
Goodness-of-fit testmetode. Her testes hypotesen at de observerte frekvensene fra
OpenTrack er de samme som de forventede frekvensene fra ANNA.
Hvis , med ) ) frihetsgrader, forkast nullhypotesen, hvis
ikke behold nullhypotesen (Walpole et al., 2007).
Under vises det hvordan denne testen ble utført for 5xx-togene fra Eriksrud med
forsinkelsesfordeling 11-14.
Anna OpenTrack Sum
Fra [s] Til [s]
[Frekvens] [Frekvens] [Frekvens]
0 50 116 701 817
50 100 104 554 658
100 150 42 249 291
150 200 20 117 137
200 250 10 84 94
250 400 15 100 115
400 1000 19 134 153
SUM[Frekvens] 326 1939 2265
Tabell 2 Test for homogenitet - 5xx-tog ved Eriksrud i perioden 11-14
I kolonnene er frekvensen av antall tog fra ANNA og OpenTrack samlet innenfor
hvert tidsintervall, det vil si antall forsinkede tog som faller innenfor tidsintervallene.
Frekvensen summeres opp, både for kolonner og rader.
Neste steg er å kalkulere forventet frekvens for ANNA og OpenTrack, det gjøres ved
følgende formel:
) )
64

Dermed blir den første forventede frekvensen for ANNA beregnet på følgende måte
I tabellen under er alle forventede frekvenser utregnet og satt i parentes.
Anna OpenTrack Sum
Fra [s] Til [s] [Frekvens] [Frekvens] [Frekvens]
0 50 116 (117,6) 701 (699,5) 817
50 100 104 (94,7) 554 (563,3) 658
100 150 42 (41,9) 249 (249,1) 291
150 200 20 (19,7) 117 (117,3) 137
200 250 10 (13,53) 84 (80,5) 94
250 400 15 (16,6) 100 (98,4) 115
400 1000 19 (22) 134 (130,9) 153
326 1939 2265
Tabell 3 Test for homogenitet - 5xx-tog ved Eriksrud i perioden 11-14 med forventet frekvens
Man kan da regne ut
)
For testen er nullhypotesen og den alternative hypotesen følgende
: Frekvensene for Anna og OpenTrack er de samme
: Frekvensene for Anna og OpenTrack er ikke de samme
Det er valgt et signifikansnivå på , med 6 frihetsgrader.
( ) ) ) ) frihetsgrader.)
Denne testen har blitt utført for alle forsinkelsesfordelingene, med varierende
testresultater, som man kan se av tabellen under.
)
)
)
65

Forsinkelsesfordeling
[Stasjon_Tognr_Periode]
Eriksrud
Forkast/Ikke forkast
ERU_5xx_Morgen Ikke forkast
ERU_5xx_11-14 Ikke forkast
ERU_5xx_Ettermiddag Ikke forkast
ERU_16xx_Morgen Ikke forkast
ERU_16xx_11-14 Ikke forkast
ERU_16xx_Ettermiddag Ikke forkast
ERU_8xx_Morgen Ikke forkast
ERU_8xx_11-14 Ikke forkast
ERU_8xx_Ettermiddag Ikke forkast
ERU_3xx_Morgen Ikke forkast
ERU_3xx_11-14 Ikke forkast
ERU_3xx_Ettermiddag Ikke forkast
ERU_Fjerntog_Morgen Ikke forkast
ERU_Fjerntog_11-14 Ikke forkast
ERU_Fjerntog_Ettermiddag Ikke forkast
ERU_Flytog_Morgen Ikke forkast
ERU_Flytog_11-14 Ikke forkast
ERU_Flytog_Ettermiddag
Daler
Ikke forkast
DLR_5xx_Morgen Forkast
DLR_5xx_11-14 Forkast
DLR_5xx_Ettermiddag Forkast
DLR_Fjerntog_Morgen Ikke forkast
DLR_Fjerntog_11-14 Ikke forkast
DLR_Fjerntog_Ettermiddag
Drammen
Forkast
DRM_16xx_Rush Forkast
DRM_16xx_IkkeRush Ikke forkast
DRM_Flytog_Rush Forkast
DRM_Flytog_IkkeRush Forkast
DRM_3xx_Rush Forkast
DRM_3xx_IkkeRush
Kobbervik
Forkast
KOB_8xx_Rush Ikke forkast
KOB_8xx_IkkeRush Ikke forkast
Tabell 4 Resultat av test for homogenitet
66

8.2.1.2 Årsaker til forkastning
Ettersom nullhypotesen for togene som starter ved Eriksrud eller Kobbervik aldri
forkastes mens hyppigheten av forkastning av nullhypotesen er høy for de andre
stasjonene, vil årsaken til denne forskjellen bli vurdert.
Forsinkelsesdataene fra ANNA er, som forklart i 7.2, registret ved innkjør- og utkjørssignaler.
Det vil si at avviket togene har fått registrert er når signalet er grønt, altså i
det de kjører inn til stasjon eller ut fra stasjon. Ved simulering i OpenTrack vil
generatoren for tilfeldige tall trekke fra en fordeling og tildele denne forsinkelsen ved
startstasjonen i modellen. Dette skaper et avvik fra posisjonen hvor
forsinkelsesdataene er hentet fra ANNA til hvor de blir implementert i OpenTrack.
Det fører til at toget som er hentet fra ANNA i virkeligheten har forlatt stasjonen,
mens i OpenTrack er toget fremdeles ved plattform. Det er gjort et forsøk på å
korrigere for dette avviket ved å trekke fra tiden det tar å kjøre fra plattform til
signalet, men det gir fremdeles ikke et riktig bilde. Ved å korrigere for denne tiden vil
forsinkelsen bli modellert riktig i de tilfellene hvor toget får lov til å kjøre
umiddelbart, men for resten av tilfellene vil togene få en høyere forsinkelse enn
registrert i ANNA.
Denne bakenforliggende årsaken gjør at forsinkelsen fra ANNA ikke blir nøyaktig
modellert i OpenTrack. Situasjoner hvor tog får ekstra forsinkelse på grunn av
hindring av andre tog vil analyseres.
Ved Daler er det enkeltspor, noe som fører til at togene har mye større sannsynlighet
for å påvirke hverandre. Et eksempel på dette er vist under, hvor togene 518 og 515
skal krysse ved Gulskogen stasjon.
Figur 27 Årsak til forkastning 1
Etter ruteplanen skal 518 ankomme Gulskogen før 515, men i dette tilfellet ankommer
515 før det forsinkede toget 518. Det fører til at 515 og 518 må krysse ved Daler i
stedet for Gulskogen, og 518 må vente på 515 på Daler i stedet for Gulskogen og blir
dermed ekstra forsinket. Men kanskje den viktigste grunnen til forkastning for 5xxtogene
ved Daler er at krysningsmønsteret er endret for 2012 ruteplanen. Det vil
67

innebære at forsinkelsesdataene hentet fra ANNA er når 5xx-togene krysset ved
Vestfossen, mens de i 2012 vil krysse ved Gulskogen.
Forsinkede kipptog fra Holmen sidespor forårsaker en del ekstra forsinkelse ettersom
de kjører i feil spor fra Holmen sidespor til Sundhaugen, og belegger hele sporet fra
Holmen sidespor til Sundhaugen, gjennom spor 1 på Drammen stasjon. Dette fører til
ekstra forsinkelse både for flytogene som vender i plattform på Drammen stasjon,
men også for 16xx-togene som vender på Sundhaugen. På figuren under ser man et
forsinket kipptog som kjører feil spor fra Holmen sidespor gjennom spor 1 på
Drammen stasjon.
Figur 28 Årsak til forkastning 2
Når kipptoget har passert Drammen stasjon kan flytoget kjøre ut fra spor 3, men med
en ekstra forsinkelse grunnet det forsinkede kipptoget.
Figur 29 Årsak til forkastning 3
Til slutt kan 16xx-toget kjøre fra Sundhaugen, også det med ekstra forsinkelse
grunnet kipptoget.
Figur 30 Årsak til forkastning 4
68

3xx-togene har bare mulighet til å bruke spor 2 på Drammen stasjon. Det hender at
forsinkede tog okkuperer spor 2 og dermed forårsaker at 3xx-togene blir ekstra
forsinket.
Slike hendelser skjer ikke like hyppig ved Eriksrud og Kobbervik. Ved Kobbervik
introduseres togene som kommer fra Vestfoldbanen. Som man kan se fra Figur 13 er
det etter Kobbervik, videre på Vestfoldbanen, en periode med dobbeltspor hvor 8xxtogene
krysser hverandre. Det er derfor lagt inn i ruteplanen at 8xx-tog fra Drammen
skal ankomme Kobbervik en stund før 8xx-tog mot Drammen ankommer Kobbervik.
Dette fører til at det sjelden blir noen slike konflikter ved Kobbervik.
Ved Eriksrud er det dobbeltspor, som gjør at togene ved Eriksrud kun er avhengig av
tog i samme retning. Nullhypotesen forkastes aldri ved Eriksrud, og mye mindre
konflikter oppstår her.
Ut i fra analysen er det vanskelig å komme med en klar konklusjon. På den ene siden
klarer OpenTrack å gjenskape tallene fra ANNA ved stasjoner med få konflikter. Men
på den annen side kan man si at OpenTrack ikke klarer å gjenskape tallene fra ANNA
ved stasjoner med hyppigere frekvens av konflikter. For å klare dette må tallene fra
ANNA tilpasses bedre. Et forslag til dette er å redusere forsinkelsen fra ANNA ved
stasjoner som har høyere hyppighet av konflikter. For denne oppgaven kunne
fordelingen blitt redusert ved Drammen og Daler, mens det kunne vært uendret ved
Eriksrud og Kobbervik.
Oppsummert vil det si at OpenTrack gir et riktig bilde på forsinkelsesdataene som
legges inn, men det gir ikke et riktig bilde på hva som kommer fra ANNA.
8.2.2 Godstog og kipptog
Grunnet manglende statistikk på godstog og kipptog i ANNA har det i disse
togkategoriene blitt brukt funksjonen “Initial Delay by Train Category” i OpenTrack.
Ved hjelp av denne funksjonen kan hele togkategorier få en definert startforsinkelse.
En eksponentiell fordeling ble valgt ettersom tog ikke kan forlate stasjonen før
ruteplan. Det som deretter defineres i OpenTrack er gjennomsnittlig forsinkelse, maks
forsinkelse og prosentvis antall tog som skal ha denne forsinkelsen. Dette kan ses på
figurene under.
69

Figur 32 Train Categories - OpenTrack
Figur 31 Initial Delay - OpenTrack
70

For godstogene og kipptogene ble det, som man ser fra Figur 31 og Figur 32, definert
at 70 % av togene skulle ha en gjennomsnittlig startforsinkelse på 300 sekunder med
maks forsinkelse på 900 sekunder. Denne forsinkelsesfordelingen er et estimat basert
på Skartsæterhagens (2009) befaring på kipptog mellom Sundland og Brakerøya
9.oktober 2009, hvor han skriver “Det toget vi var med var først klar til å gå ca.15
min. etter ruta fordi det var mer vogner å skifte sammen enn forutsatt (ev. at retur fra
Holmen var forsinket)” (Skartsæterhagen, 2009, s.10). Det ble derfor estimert at
maksimum forsinkelse på 15 minutter, eller 900 sekunder, er noe som oppstår ved
uforutsette hendelser som observert av Skartsæterhagen (2009). Videre ble det
estimert en gjennomsnittlig forsinkelse basert på maksimumsverdien.
Skartsæterhagen (2009) foreslår mulige tiltak for å bedre kipptogtrafikken frem mot
2012, hvor et tiltak er strengere overholdelse av ruter. Det tyder på at mange kipptog
kjører med forsinkelse, det ble derfor estimert at 70 % av kipptogene er forsinket.
Ettersom kipptogene og godstogene er knyttet sterkt sammen er det naturlig at de har
lik forsinkelsesfordeling. Dersom et kipptog er forsinket fra Sundhaugen på grunn av
et forsinket godstog er det naturlig at det samme godstoget blir forsinket når kipptoget
returnerer fra Holmen/Brakerøya. Det ble derfor valgt å bruke samme fordeling for
kipptog og godstog.
8.2.2.1 Kipptog
Kipptogene kjører som kjent fra Sundhaugen til Brakerøya/Holmen og tilbake. Altså
har kipptogene fra Sundhaugen fått en startforsinkelse ved Sundhaugen og tog til
Sundhaugen har fått en startforsinkelse ved Brakerøya eller Holmen. Det er kjørt 194
simuleringer, som vil si at det går totalt 1940 tog fra Sundhaugen til
Brakerøya/Holmen, men bare 1746 tog til Sundhaugen fra Brakerøya/Holmen, dette
skyldes at simuleringen ble foretatt i tidsperioden 05:00-22:00 og kipptoget 6449 fra
Brakerøya sidespor går etter ruteplanen 22:15, altså “mangler” det 194 tog fra
Brakerøya til Sundhaugen. Som output fra simuleringene får man en Excel-fil som
blant annet inneholder avgangstiden. Det er den man bruker for å undersøke om
forsinkelsen lagt inn i OpenTrack er den samme som kommer ut. For kipptogene var
det på forhånd definert at 70 % av alle togene skulle ha en forsinkelsesfordeling med
gjennomsnittlig forsinkelse på 300 sekunder og maks forsinkelse på 900 sekunder.
Det er da naturlig å anta at alle kipptog som har kjørt fra Sundhaugen eller
Brakerøya/Holmen akkurat på ruteplan, altså med en forsinkelse på 0 sekunder, er
blant de 30 % av tog som ikke skulle være forsinket. Antall tog kjørt med forsinkelse
på 0 sekunder blir summert opp og dividert på det totale antallet. Man har da definert
prosentandelen som kjører med forsinkelse. Det som gjenstår er å finne
gjennomsnittlig forsinkelse og maksforsinkelse. Dette gjøres ved å bruke funksjonene
“Average” og “Max” i Excel.
71

For kipptogene var dette resultatet av simuleringen
Sted Antall
forsinkede
tog
Antall
tog
Prosentvis
forsinkede tog
[%]
Gjennomsnitt
forsinkelse [s]
Sundhaugen 1369 1940 70,6 292 928
Holmen 687 970 70,8 269,5 900
Brakerøya 536 776 69 281,3 900
Alle 2592 3686 70,3 284,42 928
Tabell 5 Resultat av simulering for kipptog
Maks
forsinkelse [s]
Ut i fra Tabell 5 kan man se at det stemmer godt for kipptogene. Togene som kjører
fra Sundhaugen har kjørt 100 % av togene og har best tilpasning.
8.2.2.2 Godstog
For godstogene gjelder samme fremgangsmåte som for kipptogene. Her blir
forsinkelsene målt ved Sundhaugen og ved Eriksrud. Det kjører totalt 10 tog fra
Sundhaugen i retning Oslo, og 10 tog fra Oslo i retning Sundhaugen. Det vil tilsvare
1940 tog i hver retning. Simuleringen går i tidsrommet 05:00 – 22:00, noe som gjør at
tognummer 5000 og 5002 i retning Oslo og 5019 i retning Sundhaugen ikke kommer
med i simuleringen. I tillegg er det 18 senarioer hvor 5018 ikke kjører. Dette skjer når
5018 får en så stor forsinkelse at det ikke klarer å kjøre gjennom hele modellen, da
registrerer ikke OpenTrack at toget har kjørt. Det gjør at antall tog som kjører fra
Sundhaugen i retning Oslo er 1534, og antall tog som kjører fra Oslo i retning
Sundhaugen er 1746. Under er resultatene av simuleringen i OpenTrack for
godstogene.
For godstogene var dette resultatet av simuleringen
Sted Antall
forsinkede
tog
Antall
tog
Prosentvis
forsinkede
tog [%]
Gjennomsnitt
forsinkelse [s]
Sundhaugen 1066 1534 69,5 286,7 967
Eriksrud 1330 1746 76,2 250,7 923
Begge 2396 3280 73 267,5 967
Tabell 6 Resultat av simulering for godstog
Maks
forsinkelse
[s]
For godstogene er ikke tilpasningen like god som for kipptogene. Ved Eriksrud er det
spesielt dårlig. Noe av årsaken til det er antagelsen at tog med mer enn null sekunder
forsinkelse er forsinket. Denne antagelsen passer bra ved Sundhaugen spor 2, hvor det
bare er kipptog og godstog, men ikke like godt ved Eriksrud. Her kan godstoget få
følgeforsinkelse på noen sekunder, som fører til at det registreres som forsinket.
72

9 Simulering av Drammens-området
Dette kapittelet tar for seg simuleringer av forskjellige scenarioer i Drammensområdet.
Før de forskjellige simuleringene blir tatt for seg vil det forklares hvordan
funksjonen Incidents har blitt brukt. Det vil så bli gitt en oversikt over hvilke
simuleringer som er utført, før hver simulering blir forklart i detalj.
9.1 Introduksjon
OpenTrack lar, som tidligere nevnt, brukeren få mulighet til å legge inn forskjellige
hendelser i programmet gjennom funksjonen Incidents. Slike hendelser kan for
eksempel være signalfeil eller feil på skinner. For å gjøre simuleringen så realistisk
som mulig er det derfor ønskelig å inkludere så mange hendelser som mulig, men
dette er vanskelig å få simulert på en riktig måte. Hvis en kjøreledning blir revet ned
kan det føre til stans i trafikken i flere timer, i virkeligheten ville togleder ha endret
kjøremønster for togene og det ville blitt tatt i bruk buss-for-tog. Dette er ikke mulig i
OpenTrack, og togene vil dermed bli stående til problemet er ordnet før togene kjører
videre. Resultatet av en slik simulering vil ikke gi et riktig bilde av virkeligheten.
Men det finnes tilfeller hvor feil på infrastrukturen gir relativt små forsinkelser, som
for eksempel et signal som er ute av drift i en kort periode. Slike hendelser er lagt inn
i OpenTrack. Det er valgt ut 12 signaler i Drammens-området som er representative
for alle signalene i modellen. Signalene er innkjør- og utkjør-signaler for Drammen
stasjon (4), indre utkjør-signaler for hvert spor på Drammen stasjon (6), og signal
mellom Lier og Brakerøya (2). På bakgrunn av data mottatt fra Banedata er det for
perioden 1.1.2009 – 1.7.2009 funnet 33 hendelser hvor signalfeil har ført til
driftsforstyrrelser. Det vil si at signalfeil som fører til driftsforstyrrelse hendte omtrent
15,5 % av dagene. Fra samtale med Faglig leder signal i Jernbaneverket, G. Hansen
(personlig kommunikasjon, 08.desember.2010) ble det estimert at en 80-20 fordeling
vil være en god måte å gjenskape signalfeil. Hvor 80 prosent av forsinkelsene er små
forstyrrelser mens 20 prosent skaper større forsinkelser. På grunn av at OpenTrack
ikke modellerer større forsinkelser på en riktig måte, har de største forsinkelsene blitt
begrenset til 30 minutter. Signalfeilene kan forekomme når som helst i løpet av dagen,
med en sannsynlighet for feil på 1,3 % (15,5 / 12 ≈ 1,3) per signal.
For å modellere skiftebevegelser i hovedsporet ved Brakerøya er også Incidents brukt.
Som forklart i 6.4 vil kipptog som skal forflytte seg mellom østre og vestre sidespor
på Brakerøya måtte snu i hovedsporet. Ved å bruke Incidents blir denne
skiftebevegelsen modellert ved at hovedsporet blir okkupert en periode tilsvarende
tiden kipptoget ville brukt på skiftebevegelsen. Når sporet er okkupert kan tog ikke
passere Brakerøya.
Skartsæterhagen (2009) skriver om tiden slike skiftebevegelser tar: “Vi observerte
beleggstider opp til 6 ½ minutt selv om personalet da gjorde sitt ytterste for å få det til
å gå raskt. Ved lengre tog (som det vil bli hvis det blir økt trafikk som forventet) vil
tiden bli enda lengre.” (side 13), men han skriver også “Tidsbruket for denne
skiftingen inn på eller ut fra sidesporet ble anslått til minst 4 min. for lok og vogner.
73

Hvis det bare er lok, kan det gå på 3 minutter.” (side 7). Om antall tog skriver
Skartsæterhagen at “Til Brakerøya er det 3 – 6 kipptog i hver retning pr.dag, mest
dagtid” (side 5). Det ble valgt å legge seg mellom de to estimatene fra
Skartsæterhagen (2009). Derfor vil beleggstiden være på 5 minutter i OpenTrack, og
det kjører 5 tog i hver retning per dag. For kipptogene vil altså skiftebevegelsene ta
fem minutter og forekommer én gang per time et tog er inne på Brakerøya, det vil si
at hvis et kipptog er to timer på Brakerøya vil sporet bli okkupert to ganger fem
minutter, altså totalt 10 minutter.
Tabell 7 er en oversikt over alle simuleringene som er utført i forbindelse med denne
oppgaven. Totalt har det blitt utført 895 simuleringer. Simulering for konfliktfri
ruteplan og validering av statistisk inndata er allerede forklart i 7.1 og 8.2. Tabell 7
viser hvilke simuleringer som har blitt utført, antall simuleringer, total ytelse, hvilke
Incidents som er brukt og en kommentar. √ betyr at Incidents er brukt. IncidentsKIPP
betyr at hendelser med skifting i hovedsporet ved Brakerøya er brukt, mens
IncidentsSIGNAL betyr at hendelser med signalfeil er brukt. For simuleringen
“simulering med Incidents”, er det simulert 100 simuleringer med total ytelse på 98
%. Simuleringen inkluderer skiftebevegelser i hovedsporet ved Brakerøya, men det
forekommer ikke signalfeil.
En stor fordel med å bruke Incidents er muligheten til og enkelt slå av og på
hendelsen. Ved simuleringene “simulering med Incidents” er funksjonen brukt, mens
ved “simulering uten Incidents” er den ikke. Etter å ha simulert med Incidents trenger
man bare å skru av funksjonen. Man slipper dermed å legge om kjøremønsteret for
kipptoget.
Årsaken til at IncidentsSIGNAL ikke blir brukt ved alle simuleringer er fordi det tok
lang tid å anskaffe denne informasjonen, slik at en del av simuleringene var
gjennomført når informasjonen ble tilgjengelig.
74

Simulering Antall Total
ytelse
[%]
Konfliktfri
ruteplan
Validering
av statistisk
inndata
Robusthetsvurdering
av
Drammensområdet
Simulering
uten kipptog
Simulering
med
Incidents
Simulering
uten
Incidents
Simulering
uten
forsinkelse
10 % økning
av
forsinkelse
20 % økning
av
forsinkelse
Hvem bør
vende hvor?
IncidentsKIPP IncidentsSIGNAL Kommentar
1 100 - - Undersøke om
ruteplanen er konfliktfri
Undersøke om statistisk
194 100 √
- inndata blir brukt på
riktig måte av
OpenTrack
Simulering for å
100 98
√
√ undersøke robustheten
til Drammens-området
100
100
100
100
50
50
100
98
98
98
98
98
98
98
Tabell 7 Simuleringsoversikt, hvor √ betyr at hendelsen er brukt.
-
√
-
√
√
√
√
-
-
-
-
√
√
√
Kipptog kjører eget spor
fra Sundhaugen til
Brakerøya/Holmen,
modellert ved å
simulere uten kipptog
eller skiftebevegelser
Simulering av kipptog
med vending i
hovedspor ved
Brakerøya
Simulering av kipptog
uten vending i
hovedspor ved
Brakerøya
Kipptog kjører uten
forsinkelse, med
vending i hovedspor ved
Brakerøya
Undersøke om
ruteplanen er ved et
kritisk punkt for
ustabilitet
Undersøke om
ruteplanen er ved et
kritisk punkt for
ustabilitet
3xx-tog vender ved
Sundhaugen, 16xx-tog
vender ved Skamarken
75

9.2 Robusthetsvurdering av Drammens-området
For å undersøke robustheten til Drammens-området er det utført 100 simuleringer,
hvor funksjonen Incidents er brukt både for skiftebevegelser i hovedsporet ved
Brakerøya og for signalfeil. Dette for å oppnå en mest mulig realistisk simulering.
Etter endt simulering er det utregnet kumulativ forsinkelsesfordeling for alle tog ved
endestasjon for å undersøke systemets punktlighet, som man ser i Figur 33. Systemets
totale punktlighet, altså antall tog som kjører med forsinkelse mindre enn 240
sekunder er 87,8 %. Dette er 2,2 % unna Region Øst sitt måltall for punktlighet på 90
%. Dette er ikke et godt utgangspunkt for en ruteplan. Videre er det gjort flere
analyser for å vurdere robustheten til ruteplanen.
76

Figur 33 Kumulativ forsinkelsesfordeling – Robusthetsvurdering av Drammens-området
77

Forskjellen på startforsinkelse og forsinkelse ved endestasjon er utregnet i henhold til
formelen om tilleggsforsinkelse, fra Lindfeldt (2010)
Hvor
∑ )
Dette gir et bilde på om togene klarer å kjøre inn noe av startforsinkelsen de har når
de kommer inn i modellen. Tillegget på forsinkelsen er utregnet for alle persontog, i
begge retninger. Ettersom det ble simulert 100 scenarioer er det brukt en
gjennomsnittsverdi.
Sluttforsinkelse Startforsinkelse Differanse Antall
Startstasjon Endestasjon [s]
[s]
[s] tog
3xx Eriksrud Drammen 118 109 9 16
3xx Drammen Eriksrud 60 13 47 15
5xx Eriksrud Gulskogen 157 178 21 17
5xx Daler Eriksrud 178 167 11 18
8xx Eriksrud Drammen 82 118 36 20
8xx Kobbervik Eriksrud -46 20 66 18
16xx Eriksrud Drammen 178 152 26 32
16xx Drammen Eriksrud -32 21 53 31
Flytog Eriksrud Drammen 93 105 12 51
Flytog Drammen Eriksrud 49 29 20 51
Fjerntog Eriksrud Gulskogen 184 184 0 10
Fjerntog Daler Eriksrud 84 130 46 10
Tabell 8 Tilleggsforsinkelse
Differansen er gitt i absoluttverdi og de som er markert rødt har fått økt forsinkelse
gjennom modellen. Årsaken til at noen av startstasjonene ikke er de samme som
endestasjonene er at togene forsvinner ut av modellen like før Kobbervik og Daler
stasjon, og får dermed ikke registrert en ved disse stasjonene i OpenTrack.
Forsinkelsestiden er derfor registrert ved utkjør fra forrige stasjon. Antall tog er
gjennomsnittlig antall tog per dag. Grunnen til at antall tog ikke alltid er lik for hver
linje i hver retning er fordi simuleringen er utført i perioden 05:00-22:00, noe som
gjør at ikke alle tog kommer med i simuleringen.
Som man ser av Tabell 8 er det 5/12 ≈ 42 % av linjene som får en ekstra forsinkelse
gjennom modellen, men denne ekstra forsinkelsen er liten for de fleste togene. Den
78

største gjennomsnittlige tilleggsforsinkelsen er på 47 sekunder. Selv om
tilleggsforsinkelsen er liten kan det grunnet denne oppstå konflikter senere, og det er
heller ikke utelukkende positivt at tog forlater modellen med negativ forsinkelse.
Negativ forsinkelse skaper like mange konflikter som positive forsinkelser. Ettersom
tog ikke kan forlate en stasjon før ruteplanen vil et tog som ankommer før tiden
oppholde seg lenger enn nødvendig ved plattform, og dermed ta opp unødvendig
kapasitet, som igjen kan hindre andre tog.
En annen viktig faktor når det gjelder tilleggsforsinkelse er hvor mange tog som
kjøres for hver linje. Det er flytoget som har flest avganger, mens fjerntogene har
færrest. Med en gjennomsnittlig forsinkelse på 47 sekunder per 3xx-tog fra Drammen
er det linjen med høyest tilleggsforsinkelse. Med 16 avganger vil det gi en total
gjennomsnittlig forsinkelse på systemet på 705 sekunder per dag, mens flytoget, som
bare har 20 sekunder tilleggsforsinkelse fra Drammen vil, grunnet mange avganger,
skape en gjennomsnittlig totalforsinkelse på systemet på hele 1020 sekunder per dag.
Dette er ikke en nøyaktig metode for utregning av forsinkelse for systemet, men det
gir et bilde på at selv små forsinkelser kan gjøre stor skade.
Dersom Tabell 8 sorteres etter retningen togene ankommer Drammen stasjon, viser
det seg at prosentvis antall linjer som får økt forsinkelse er større for tog som kjører
mot Oslo enn tog som kommer fra Oslo.
Startstasjon Antall linjer Linjer med Tilleggsforsinkelse
tilleggsforsinkelse [%]
Fra Oslo 6 2 33, 3 %
Mot Oslo 6 3 50 %
Tabell 9 Prosentvis tilleggsforsinkelse etter retning
Sannsynligvis er det kipptog som er hovedårsaken til denne forskjellen. Det går flere
tog i hovedsporet mot Oslo enn det gjør fra Oslo. I alt går det 20 kipptog mellom
Sundland og Holmen/Brakerøya. Av dem går 15 i hovedsporet mot Oslo, mens fem
går i hovedsporet fra Oslo. Disse fem kipptogene skifter over hovedsporet mot Oslo
når de forlater Brakerøya sidespor. I tillegg kommer skiftebevegelser i hovedsporet
når kipptogene skifter mellom østre og vestre sidespor på Brakerøya.
Man ser også fra Tabell 8 at startforsinkelsen generelt er høyere for tog som starter
ved Eriksrud enn de andre startstasjonene. Det indikerer at tog får høyere forsinkelse
på Oslo-siden av modellen. Det er ikke overraskende, ettersom hyppigheten av tog
øker desto nærmere man kommer Oslo. Men ut fra det kan man se en trend at tog som
kommer fra Oslo generelt har større forsinkelser, men klarer å kjøre inn en del av
denne forsinkelsen gjennom Drammens-området. For tog som kjører mot Oslo er
trenden motsatt. De har mindre forsinkelse, men får økt forsinkelsen gjennom
Drammens-området.
Det er også brukt en annen metode for å vurdere robustheten til Drammens-området,
og denne forklares nedenfor.
79

I 2007 utførte et britisk konsulentselskap, ved navn Funkwerk, simuleringer av 2012
ruteplanen. En av Funkwerk’s viktigste måleparametere for robustheten til en ruteplan
er forholdstallet mellom det de kaller primær- og sekundærforsinkelser. Funkwerk
definerer primærforsinkelser som alle startforsinkelser ved starten av modellen, pluss
alle forsinkelser til tog som starter i modellen og ekstra forsinkelse ved
stasjonsopphold. Sekundærforsinkelser defineres som all tilleggsforsinkelse som
oppstår som følge av interaksjon mellom tog og signalsystemet. Forholdstallet
utregnes ved å dividere sekundærforsinkelser på primærforsinkelser. En ruteplan
defineres som robust hvis forholdstallet er 0,3 eller mindre og en verdi på mer enn 1
indikerer at ruteplanen ikke er robust, og at den er potensielt ustabil (Funkwerk,
2007).
Problemet med en slik analyse er at primær- og sekundærforsinkelsene definert av
Funkwerk (2007) ikke lar seg overføre til utdata fra OpenTrack. Primærforsinkelse i
OpenTrack er forsinkelsen tog har i det de ankommer modellen, og forsinkelsen tog
som starter i modellen har. Ekstra forsinkelse ved stasjonsopphold er ikke mulig å
definere i OpenTrack. Det er likevel gjennomført en slik analyse, ettersom det
indikerer om ruteplanen er robust eller ikke. Forholdstallet er utregnet for alle
passasjertog, alle tog unntatt kipptog og godstog. Resultatet ble et forholdstall på
0,91, som nok ville vært høyere hvis kipptog og godstog ble inkludert i analysen.
Ettersom ekstra forsinkelse ved stasjonsopphold i OpenTrack ikke er mulig å definere
i OpenTrack fører det til at ekstra forsinkelse ved stasjonsopphold blir for utregningen
i denne prosjektoppgaven overført fra primærforsinkelse til sekundærforsinkelse.
Forholdstallet på 0,91 er dermed for høyt. Selv om forholdstallet ikke er nøyaktig
indikerer det at ruteplanen for 2012 ikke er robust og at den potensielt er ustabil.
Ettersom det ikke er mulig å bruke Funkwerks (2007) metode nøyaktig er det
vanskelig å komme med en klar konklusjon om ruteplanen er robust eller ikke. Det er
likevel lite sannsynlig at forholdstallet ville vært 0,3 selv med riktig primær- og
sekundærforsinkelser. Fra den første analysen viser det seg at omtrent 42 % av linjene
får økt forsinkelsen gjennom Drammens-området, og selv om denne økningen er liten
kan det føre til konflikter som igjen fører til økt forsinkelse. Analysen viser også at
det er en trend at forsinkelsen øker for tog som kjører mot Oslo.
Det konkluderes derfor med at ruteplanen ikke er robust og at den er potensielt
ustabil. I de neste avsnittene er det sett på forskjellige årsaker til at ruteplanen ikke er
robust og det er gitt forslag for endringer som kan føre til en mer robust ruteplan.
9.3 Effekt av kipptogkjøring:
Kipptogkjøring i og rundt Drammen stasjon tar opp mye av kapasiteten, og
Skartsæterhagen (2009) konkluderer med at “kipptogtrafikken slik den drives i dag
ikke er forenlig med tett rutetrafikk slik det planlegges i R2012. Videre foreslår han
noen mulige tiltak som bør gjennomføres innen 2012. Disse er:
- Skifting i hovedspor Brakerøya må opphøre
80

- Kortere kjøretid for kipptogene
- Kortere togfølgetider mellom Brakerøya og Drammen
- Identifisering av alle aktuelle ruteleier for kipptog og strengere
overholdelse av ruter.
I tillegg foreslår Skartsæterhagen (2009) at kipptogene burde hatt et eget spor
Drammen-Holmen-Brakerøya hvor kipptogene kan kjøre uten å forstyrre persontog.
Det har i denne oppgaven blitt identifisert aktuelle ruteleier for kipptog til Holmen og
Brakerøya, disse finnes i vedlegg A. I tillegg er det blitt utført 100 simuleringer med
og uten skifting i hovedspor ved Brakerøya, det er også gjennomført 100 simuleringer
hvor kipptogene har et eget spor uten å forstyrre persontogene og til slutt, 100
simuleringer hvor kipptogene ikke har noe forsinkelse, altså strengere overholdelse av
rutetider.
Simuleringene har blitt gjennomført ved å simulere de samme 100 scenarioene, med
små forskjeller.
For å modellere skiftebevegelser i hovedsporet er det tatt i bruk funksjonen Incidents
Under simuleringen uten skifting i hovedsporet ble ikke funksjonen Incidents tatt i
bruk. I simuleringene hvor kipptoget har sitt eget spor, uten å forstyrre andre tog er
blitt det simulert uten å inkludere kipptogene og uten Incidents, mens det i
simuleringen for å undersøke effekten av strengere overholdelse av rutetider ble brukt
Incidents, men forsinkelsen for togkategorien “Kipptog” ble ikke brukt (se 8.2.2),
dette fører til at alle kipptog da vil kjøre på rutetid. Etter endt simulering er den
akkumulerte forsinkelsesfordelingen for alle tog, ikke bare kipptog, ved endestasjon
beregnet slik at man kan sammenligne forsinkelsene for hver simulering (Figur 34,
Tabell 10)
81

KUMULATIV
FORSINKELSE [S]
MED
KIPP_MED
SKIFTING I
HOVEDSPO
RET
UTEN
KIPP
MED
KIPP_UTE
N
SKIFTING
I
HOVEDSP
OR
KIPP UTEN
FORSINKE
LSE
20 41,07 % 43,25 % 41,64 % 43,55 %
40 54,05 % 57,33 % 54,92 % 56,67 %
60 61,44 % 64,77 % 62,47 % 63,85 %
80 66,58 % 69,51 % 67,15 % 68,92 %
100 71,05 % 73,78 % 71,62 % 73,88 %
120 75,56 % 78,38 % 76,14 % 78,54 %
140 78,20 % 80,88 % 78,78 % 81,00 %
160 80,45 % 82,98 % 81,02 % 83,10 %
180 82,59 % 84,96 % 83,10 % 85,04 %
200 84,40 % 86,62 % 84,87 % 86,66 %
220 86,03 % 87,86 % 86,25 % 88,05 %
240 87,44 % 89,26 % 87,66 % 89,35 %
260 88,38 % 90,15 % 88,62 % 90,19 %
280 89,39 % 91,14 % 89,62 % 91,11 %
300 90,01 % 91,76 % 90,26 % 91,70 %
320 90,63 % 92,30 % 90,88 % 92,27 %
340 91,26 % 92,67 % 91,30 % 92,85 %
360 91,76 % 93,13 % 91,81 % 93,30 %
380 92,29 % 93,57 % 92,32 % 93,74 %
400 92,74 % 93,97 % 92,78 % 94,12 %
420 93,17 % 94,38 % 93,21 % 94,51 %
440 93,48 % 94,65 % 93,52 % 94,77 %
460 93,86 % 94,99 % 93,89 % 95,07 %
480 94,22 % 95,28 % 94,28 % 95,36 %
500 94,60 % 95,67 % 94,67 % 95,74 %
520 94,88 % 95,92 % 94,96 % 95,97 %
540 95,19 % 96,22 % 95,25 % 96,27 %
560 95,40 % 96,41 % 95,45 % 96,45 %
580 95,62 % 96,59 % 95,66 % 96,62 %
600 95,82 % 96,75 % 95,86 % 96,78 %
>600 100,00 % 100,00 % 100,00 % 100,00 %
Tabell 10 Kumulativ forsinkelse ved endestasjon for alle tog ved forskjellige scenarioer
82

Figur 34 Kumulativ forsinkelsesfordeling – Effekt av kipptog
83

Av Tabell 11 ser man at prosentvis antall tog som er i rute (mindre enn 240 sekunder
forsinket) ved endestasjon for modellen for de forskjellige scenarioene er:
PROSENTVIS
ANTALL TOG
I RUTE
MED
KIPP_MED
SKIFTING I
HOVEDSPOR
UTEN
KIPP
MED
KIPP_UTEN
SKIFTING I
HOVEDSPOR
KIPP UTEN
FORSINKELSE
240 sek 87,4 % 89,3 % 87,7 % 89,4 %
Tabell 11 Prosentvis antall tog i rute
Overraskende nok er det ikke simuleringen uten kipptog som har best total
punktlighet, men simuleringen hvor kipptogene kjører uten forsinkelse, selv om
forskjellen er liten. Dette er overraskende fordi det gis best resultat når man simulerer
med kipptog og skiftebevegelser i hovedsporet og ikke når man simulerer uten at
togene går og uten skiftebevegelser i sporet. Det som gir dårligst resultat er slik
kipptogtrafikken drives i dag.
Man ser også man at det er et skille mellom de to beste og de to dårligste
simuleringene, som vi også ser fra Figur 34.
Ettersom løsningen med at kipptogene har sitt eget spor er en langsiktig løsning kan
man konkludere med at det som vil gi best og raskest løsning på problemet er en
strengere overholdelse av ruteplanen. Resultatet viser altså at det er mulig å
gjennomføre kipptogtrafikken, men det krever mye strengere overholdelse av
ruteplanen enn det gjøres i dagens drift.
Disse simuleringene forutsetter at kipptogene fra Brakerøya kun bruker høyre
hovedspor fra Brakerøya gjennom Drammen Stasjon spor 4 eller 5 til Sundhaugen,
det er ikke plass i ruteplanen til å la kipptogene kjøre venstre hovedspor gjennom spor
1 på Drammen stasjon.
9.4 Sensitivitetsanalyse
Det har også blitt utført en sensitivitetsanalyse for å undersøke stabiliteten til
ruteplanen i forhold til variasjon på forsinkelse.
I følge Mæhlum (2009, [Internett]) er en sensitivitetsanalyse en:
Metode for testing av en matematisk modells følsomhet for endringer i
parametere som inngår i modellen og for endringer i modellens struktur.
Analysen skjer gjennom en serie tester der parameterverdiene endres etter tur
for å se hvilken virkning hver endring har på utfallet. Slike tester er nyttig
både i selve modellbyggingen og i evaluering av en valgt modell
For sensitivitetsanalysen er forsinkelsesfordelingene økt med 10 % og 20 % for å
undersøke stabiliteten til ruteplanen. Hvis ruteplanen klarer å håndtere en økning av
forsinkelse kan man konkludere med at ruteplanen ikke er ved et kritisk punkt hvor
ruteplanen kan bli ustabil.
84

De to simuleringene med økt forsinkelse ble sammenlignet mot en simulering med
den originale forsinkelsesfordeling.
I Tabell 12 ser man at forskjellen mellom de tre scenarioene for både punktlighet og
forsinkelsestimer:
Original + 10 % + 20 %
Punktlighet 88,38 % 87,16 % 86,06 %
Forsinkelsestimer 424,00 463,375 500,05
Tabell 12 Forskjell i punktlighet og forsinkelsestimer for ulike forsinkelsesfordelinger
Fra Tabell 12 er det klart at punktligheten synker med omtrent 1 % for hver gang
forsinkelsesfordelingen økes, samtidig ser man at forsinkelsestimer øker.
Punktlighet [%]
89,00%
88,50%
88,00%
87,50%
87,00%
86,50%
86,00%
85,50%
85,00%
Punktlighet
Original + 10 % + 20 %
Forsinkelsesfordeling
Figur 35 Endring i punktlighet for ulike forsinkelsesfordelinger
Fra Figur 35 ser man at punktligheten til systemet synker tilnærmet lineært. At
punktligheten til systemet synker lineært når forsinkelsesfordelingen økes med
henholdsvis 10 % og 20 % indikerer at ruteplanen er stabil. Dersom hadde vært
høyere ville det tydet på en ustabil ruteplan.
85

At punktligheten synker er ensbetydende med at forsinkelsestimer øker. Fra figur 36
ser man at forsinkelsestimer øker tilnærmet lineært.
Forsinkelsestimer [t]
520,00
500,00
480,00
460,00
440,00
420,00
400,00
Forsinkelsestimer
Original + 10 % + 20 %
Forsinkelsesfordeling
Figur 36 Endring i forsinkelsestimer for ulike forsinkelsesfordelinger
At forsinkelsestimer øker lineært er også et tegn på at ruteplanen er stabil. Hvis
økningen av forsinkelsestimer hadde økt eksponentielt ville det tydet på en ustabil
ruteplan.
Det ble i 9.2 konkludert med at ruteplanen for 2012 ikke er robust, og at den
potensielt er ustabil. Denne analysen tyder på at ruteplanen tåler en 20 % økning av
forsinkelse uten å nå et kritisk punkt. Det konkluderes derfor med at ruteplanen ikke
er robust, men stabil.
86

Figur 37 Frekvens av forsinkelsesintervaller
87

Figur 38 Kumulativ forsinkelsesfordeling - Sensitivitetsanalyse
88

9.5 Hvem bør vende hvor?
Hvilken av linjene bør vende på Skamarken og hvilken bør vende på Sundhaugen
Flytoget, 3xx-togene og 16xx-togene vender ved Drammen stasjon. Flytogene vender
i spor 3, mens 3xx-togene og 16xx-togene må vende enten på Skamarken eller
Sundhaugen. Det er derfor interessant å undersøke hvilken av togene som bør vende
hvor for å oppnå best flyt i trafikkavviklingen. Det er simulert 100 ganger hvor 3xxtogene
vender på Sundhaugen. Deretter har den kumulative forsinkelsesfordelingen
blitt sammenlignet mot robusthetsvurderingen av Drammen, hvor 16xx-togene vender
på Sundhaugen. Som for alle andre simuleringer blir skiftebevegelser på Sundhaugen
neglisjert, mens alle skiftebevegelser på Skamarken blir simulert. Bortsett fra hvilke
tog som vender hvor er de to simuleringene identiske.
Ved simulering av scenarioet hvor 3xx-togene vender ved Sundhaugen oppstod det
noen fastlåste situasjoner. Det er situasjoner hvor to tog møtes på enkeltspor og fører
til stans i togtrafikken. Slike situasjoner ville ikke oppstått i virkeligheten, men
grunnet en feil i OpenTrack-modellen oppstod det fem slike situasjoner, alle fem var
mellom et 3xx-tog som vender ved Sundhaugen og kipptog fra Brakerøya.
Simuleringer hvor slike situasjoner oppstod ble simulert uten 3xx-toget og etter
simuleringen ble det antatt at 3xx-togene fikk samme forsinkelse ved sluttstasjon som
definert i Tabell 8.
Det var forventet at det er en fordel at 16-xx togene vender ved Sundhaugen ettersom
de har hyppigere vendinger, som fører til flere skiftebevegelser. På den måten vil
skiftebevegelsene være atskilt fra persontogtrafikken. Men fra Figur 39 ser man at i
perioden 80-180 sekunder er scenarioet hvor 16xx-togene vender ved Sundhaugen litt
bedre. Bortsett fra dette er scenarioene omtrent identiske.
Scenarioene er to ytterpunkter, og trolig er det bedre å ha en kombinasjon av de to.
Hvis skiftebevegelsene optimaliseres vil trolig punktligheten til togene og robustheten
til ruteplanen øke. Dette bør altså undersøkes videre.
For å optimalisere skiftebevegelsene bør det fokuseres på:
Å unngå skiftebevegelser ved Sundhaugen som skaper konflikt med kipptog og
godstog. Spesielt viktig er dette når det ankommer kipptog fra Holmen som kjører
gjennom spor 1. Dette forsterkes av at det ankommer et 5xx tog fra Gulskogen like
etter kipptoget, som fører til at toget som vender ved Sundhaugen må vente til 5xx
toget har passert. Altså bør et tog som har mulig konflikt med kipptog vende på
Skamarken i stedet for Sundhaugen.
Skiftebevegelsene bør også være dynamiske. Som et eksempel kan et forsinket 16xxtog
som vender på Skamarken hindre et annet 16xx-tog slik at det må vente ved
plattform, og dermed opptar kapasitet. Ved slike forsinkelser bør 16xx-toget som
venter ved plattform sendes til Sundhaugen for vending.
89

Figur 39 Kumulativ forsinkelsesfordeling - Hvem bør vende hvor
90

10 Konklusjon
Dette kapittelet presenterer konklusjoner for arbeidet gjort i prosjektoppgaven.
Kapittelet inneholder konklusjoner basert på simuleringsarbeidet, med anbefalinger
for videre arbeid samt mulige feilkilder. Til slutt er måloppnåelsen evaluert.
10.1 Konklusjoner basert på simuleringsarbeid
Det har blitt utført totalt 895 simuleringer fordelt på 10 scenarioer. Basert på disse kan
følgende konklusjoner fremstilles:
For at en ruteplan skal være konfliktfri skal ruteplanen i seg selv ikke skape noen
forsinkelser. Ruteplanforslaget NSB har utarbeidet for ruteplanen 2012 inneholder
noen konflikter som skaper forsinkelser, spesielt fremtredende er konflikten mellom
togene 815 og 866. Det konkluderes derfor med at ruteplanforslaget ikke er
konfliktfri.
Det er brukt to forskjellige metoder for å modellere togforsinkelse. Første metode er
utført ved innhenting av forsinkelsesdata fra ANNA, NSBs avviksregister. Ut fra
analysen er det konkludert med at OpenTrack gir et riktig bilde på forsinkelsesdataene
som er lagt inn i programmet, men det gir ikke et riktig bilde på forsinkelsesdataene
fra ANNA. Årsaken til det er at dataene fra ANNA er målt ved utkjør- og innkjørsignaler,
og det lar seg ikke direkte overføre til OpenTrack ettersom
forsinkelsesdataene i OpenTrack blir implementert ved stasjoner, og ikke signaler.
Andre metode er å tildele forsinkelse til togkategorier. Dette er gjort for kipptog og
godstog ettersom de ikke får registrert avvikstid i ANNA. En slik metode fungerer
godt for tog som starter ved en stasjon med lite konflikter, men ikke like godt ved
stasjoner hvor forekomsten av konflikter er høyere.
Simulering viser at forventet punktlighet for 2012 ruteplanen er 87,8 %. Det er ikke et
bra utgangspunkt for implementering av en ny ruteplan. Videre analyser av
Drammens-området viser at ruteplanen for 2012 ikke er robust. Likevel tyder
sensitivitetsanalysen at Drammens-området tåler en økning av forsinkelse på 20 %
uten å nå et kritisk punkt. Ruteplanen er derfor stabil. Videre er det utført flere
analyser som tar for seg noen av problemene i Drammens-området og resultater som
vil bedre robustheten til ruteplanen.
Kipptogtrafikk tar opp mye kapasitet i Drammens-området. Det er identifisert aktuelle
ruteleier for kipptog og godstog, og fire forskjellige scenarioer av kipptogkjøring er
evaluert. Resultatet viser at det er mulig å gjennomføre kipptogtrafikken, men det
krever mye strengere overholdelse av ruteplanen enn det gjøres i dagens drift. Det bør
derfor kreves at kipptogene overholder de tidslukene de er tildelt. Dersom de ikke
klarer dette må de vente til neste tidsluke med mindre andre tog er forsinket slik at de
dermed har skapt en ikke planlagt tidsluke. Simuleringen viser også at den langsiktige
løsningen foreslått av Skartsæterhagen (2009) ikke er nødvendig, men selv om
simuleringen tilsier at dette ikke er lønnsomt vil dette kunne skape en mulighet til å
kjøre godstog fra Gulskogen til Brakerøya uten å kjøre gjennom Drammen stasjon,
91

altså bør denne muligheten utledes for å undersøke om punktligheten vil bedres med
en slik løsning.
Det var forventet at det ville gi en bedre trafikkflyt ved en vending av 16xx-tog ved
Sundhaugen, grunnet at disse vender hyppigere enn 3xx-togene. Simuleringene viser
at det de to scenarioene er omtrent identiske, og antakelig er en kombinasjon av de to
den beste løsningen. Det oppfordres til videre undersøkelser for å optimere disse
skiftebevegelsene. For å optimere skiftebevegelsene bør det fokuseres på:
- Å unngå skiftebevegelser ved Sundhaugen som skaper konflikter med
kipptog og godstog. Spesielt viktig er dette når det ankommer kipptog fra
Holmen som kjører gjennom spor 1 på Drammen stasjon.
- Skiftebevegelsene bør være dynamiske, slik at Txp har flere muligheter for
hvor togene sendes for vending.
10.2 Feilkilder
Feilkilder i prosjektet er mest relevant når det kommer til simuleringsdelen. Både
simulering for å undersøke om ruteplanen er konfliktfri og validering av statistisk
inndata er simulert med total ytelse på 100 %. Dette er fordi kalibreringsdelen ble
tilsendt etter at disse simuleringene ble utført. Dette vil gi et bedre resultat enn det
som er realistisk.
En annen feilkilde er togledelse i OpenTrack. OpenTrack klarer per dags dato ikke å
gjenskape togledelse på en realistisk måte. Dette fører til at trafikkavviklingen ikke er
optimal og at resultatene er mer pessimistiske enn virkeligheten.
Simuleringene utført for denne prosjektoppgaven er utført med forsinkelsesdata fra
2009 simulert på infrastruktur fra 2012. Dette vil føre til en del unøyaktigheter,
spesielt når det kommer til validering av statistisk inndata.
10.3 Måloppnåelse
Det overordnede målet med oppgaven, definert i 1.4, var å lage en oppgave som
hadde nytteverdi både for NTNU, SINTEF og NSB innen 21.12.2010. Om oppgaven
har en nytteverdi for NTNU, SINTEF og NSB er for tidlig å konkludere med.
Det ble også definert en rekke effekt-, resultat- og delmål i henholdsvis 1.4.1, 1.4.2 og
1.4.3.
Det er utført et litteraturstudie om simulering generelt og jernbanen spesielt, og det er
deretter introdusere en metode for simuleringsprosesser i jernbanen. Videre er det gitt
en innføring i simuleringsprogrammet OpenTrack og problemer rundt Drammensområdet.
Til slutt er det utført en rekke simuleringer som evaluerer problemene rundt
Drammens-området.
Basert på definisjonen av resultatmål og effektmål i 1.4 konkluderes det med at
resultatmålene er oppnådd, mens det er for tidlig å dra en konklusjon rundt
effektmålene.
92

Delmålene består av milepæler som må oppnås for å utføre oppgaven. Delmålene er
oppnådd.
93

Referanser
1. Astengo, G., Cosulich, G., Marzullo, D. (2000) Introduction of a new high
speed line in a high density traffic area: a simulation exercise. I: Allen, J.
Brebbia, C. A., Hill, R.J., Sciutto, G., Sone, S., (red) Computers in Railways
VII, WIT Press.
2. Axelrod, R. (2003) Advancing the Art of Simulation in the Social Sciences,
Japanese Journal for Management System, Special Issue on Agent-Based
Modeling, 12.
3. Banedata (2010) Signalfeil. Upublisert manuskript
4. Banks, C.M., (2009) What Is Modeling and Simulation? I: Sokolowski, J.A.,
Banks, C.M, (red) Principles of Modeling and Simulation: A multidisciplinary
approach, John Wiley & Sons.
5. Bell, J., (2005) Doing your Research Project: A guide for first-time
researchers in education, health and social science, Open University Press
6. Berkeley Simulation Software, (2010) Rail Traffic Controller [Internett].
Tilgjengelig fra:
[Nedlastet: 08. November 2010]
7. Bårdstu, A. (2008) Ny verden i vest – stillstand i øst. Jernbanemagasinet nr. 4,
s.6-9. Tilgjengelig fra:
http://www.jernbaneverket.no/PageFiles/7077/Jernbanemagasinet%20nr%204
%202009.pdf> Nedlastet [17.desember.2010]
8. Chung, C.A., (2004) Simulation Modeling Handbook: A Practical Apporach,
CRC Press
9. Croom, S. (2009) Introduction to Research Methodology in Operations
Management. I: Karlsson, C. (red), Researching Operations Management,
Routledge
10. Finn.no AS (2010) Drammen [Internett]. Tilgjengelig fra:
[Nedlastet: 22.oktober 2010]
11. Funkwerk IT York LTD (2007) Final Project Report. Upublisert manuskript.
12. Goverde, R.M.P., (2008) Timetable Stability Analysis. I: Hansen, I.A. &
Pachl, J., (red), Railway Timetable & Traffic, Hamburg, Eurailpress.
13. Greasley, A., (2008) Enabling a Simulation Capability in the Organisation,
London, Springer-Verlag
14. Guizani, M., Rayes, A., Khan, B., Al-Fugaha, A., (2010) Network modeling
and simulation: a practical perspective, Chichester, John Wiley & Sons
15. Hansen, I.A., (2004) Increase of capacity through optimized timetabling. I:
Allen, J. Brebbia, C. A., Hill, R.J., Sciutto, G., Sone, S., (red) Computers in
Railways IX, WIT Press
16. Hansen, I.A.,(2010) Timetable and Planning Information Quality, WIT Press
17. Hansen, I.A. & Pachl, J. (2008) (red) Railway Timetable & Traffic, Hamburg,
Eurailpress
18. Holme, I.M. & Solvang, B.K., (1996) Metodevalg og metodebruk. 3.utg.
Oslo, TANO
94

19. Huerlimann, D. & Nash, A.B., (2010) OpenTrack: Simulation of Railway
Networks Version 1.6
20. Jernbaneverket, (2010a) Grafiske togruter f.o.m 13. juni 2010: Blad 8 Oslo S –
Drammen [Internett]
[Nedlastet: 17. oktober 2010]
21. Jernbaneverket, (2010b) Network Statement 2011 [Internett]. Tilgjengelig fra:
[Nedlastet: 23. oktober 2010]
22. Kroon, L., Huisman, D., Màroti, G., (2009) Optimisation for Railway
Timetabling. I: Hansen, I.A. & Pachl, J. (red), Railway Timetable & Traffic,
Hamburg, Eurailpress
23. Krueger, H., Vaillancourt, E., Vucko, S.J., Drummie, A.M., Bekavac, J.
(2000) Simulation within the railroad environment. I: Joines, J.A., Barton,
R.R., Kang, K., Fishwick, P.A., (red) Winter Simulation Conference.
24. Landex, A. & Nielsen, O.A., (2006) Simulation of disturbances and modelling
of expected train passenger delays. I: Allen, J., Brebbia, C.A., Rumsey, A.F.,
Sciutto, G., Sone, S., Goodman, C.J. (red), Computers in Railways X.
Southampton, Boston, WIT Press.
25. Law, A.M. & Kelton, D.W., (2000) Simulation modeling and analysis.
Boston, McGraw-Hill
26. Lindfeldt, O. (2010) Impacts on infrastructure, timetable and perturbations in
operation of double-track railway lines with mixed traffic. I: Railway
Operation Analysis: Evaluation of quality, infrastructure and timetable on
single and double-track lines with analytical models and simulation. Doctoral
Thesis in Infrastructure, Stockholm, Sweden. KTH
27. Lindfeldt, O & Sipilä, H. (2009) Validation of a simulation model for mixed
traffic on a Swedish double-track railway line. I: Railway Operation Analysis:
Evaluation of quality, infrastructure and timetable on single and double-track
lines with analytical models and simulation. Doctoral Thesis in Infrastructure,
Stockholm, Sweden. KTH
28. Martin, P. (1999) Train Performance and Simulation. I: Farrington, P.A.,
Nembhard, H.B., Sturrock, D.T., Evans, G.W. (red) Winter Simulation
Conference.
29. Merriam-Webster (2010), Simulation. [Internett]. Tilgjengelig fra:
[Nedlastet: 27.
oktober 2010]
30. Middelkoop, D. & Bouwman, M. (2000) Train network for support of network
wide planning of infrastructure and timetables. I: Allen, J. Brebbia, C. A.,
Hill, R.J., Sciutto, G., Sone, S., (red) Computers in Railways VII, WIT Press.
31. Mæhlum, L., (2009) Sensitivitetsanalyse. [Internett]. Tilgjengelig fra:
http://www.snl.no/sensitivitetsanalyse [Nedlastet:14. desember 2010]
32. Reynolds, P.F.J., (2009) The role of Modeling and Simulation. I: Sokolowski,
J.A. & Banks, C.M. (red), Principles of Modeling and Simulation: A
multidisciplinary Approach, John Wiley & Sons.
95

33. Pidd, M. (2009) Tools for thinking: modeling in management science.
Chichester, John Wiley & Sons.
34. Radtke, A. (2006) Timetable management and operational simulation:
methodology and perspectives. I: Allen, J., Brebbia, C.A., Rumsey, A.F.,
Sciutto, G., Sone, S., Goodman, C.J. (red) Computers in Railways X.
Southampton, Boston, WIT Press.
35. Railsim, (2010) Railsim Network Simulator [Internett]. Tilgjengelig fra:
[Nedlastet: 08. November 2010]
36. Ringdal, K. (2007) Enhet og mangfold: Samfunnsvitenskapelig forskning og
kvantitativ metode. 2. utg. Bergen, Fagbokforlaget
37. Rolstadås, A. (2006) Praktisk prosjektstyring. s. 42-43, s.44 Trondheim, Tapir
Akademisk Forlag
38. Romsdal, A., (2010) Forelesning om “Informasjonsmøte, IKT-basert
produksjonsledelse”, TPK4514, 08.september 2010, Norges teknisknaturvitenskapelige
universitet (NTNU)
39. Siefer, T. (2008) Simulation. I: Hansen, I.A. & Pachl, J. (red) Railway
Timetable &Traffic, Hamburg, Eurailpress, s.155-168.
40. Siemens AG, (2007) Falko Design and validation of timetables: Optimized
operational planning and control. [Internett]. Tilgjengelig fra:
[Nedlastet: 08. november 2010]
41. Skartsæterhagen, S. (2009) Kipptogkjøring mellom Sundland og
Holmen/Brakerøya: Situasjonsbeskrivelse om mulige tiltak for å kunne
beholde kipptogene ved R2012. Upublisert manuskript.
42. SMA und Partner AG. (2010) Analysis of train service on the Jæren-line
(Stavanger – Egersund): Section OpenTrack simulation. Upublisert
manuscript.
43. Svingheim, N. (23. juni 2006) Ordforklaringer [Internett]. Tilgjengelig fra:
[Nedlastet: 06. november 2010]
44. Walpole, R.E., Myers, R.H, Myers, S.L., Ye, K. (2007) Probability &
Statistics for Engineers & Scientists. 8. utg. Pearson Education International
45. White, P.K. & Ingalls, R.G. (2009) Introduction to Simulation, 2009 Winter
Simulation Conference
46. Wysocki, R.K., (2007) Effective Project Management: Traditional, Adaptive,
Extreme. John Wiley & Sons.
47. Yuan, J. (2008) Statistical Analysis of Train Delays. I: Hansen, I.A. & Pachl,
J. (red) Railway Timetable & Traffic. Hamburg, Eurailpress.
48. Yuan, J., Goverde, M.P., Hansen, I.A., (2006) Evaluating stochastic train
process time distributions on the basis of empirical detection data. I: Allen, J.,
Brebbia, C.A., Rumsey, A.F., Sciutto, G., Sone, S., Goodman, C.J. (red)
Computers in Railways X. Southampton, Boston, WIT Press.
96

Vedlegg
Vedlegg A: Aktuelle ruteleier for kipptog, godstog og fjerntog.
Vedlegg B: Forstudierapport
Vedlegg C: Statusrapport per 18.10.2010
97

Vedlegg A Aktuelle ruteleier for kipptog, godstog og fjerntog
Under er aktuelle ruteleier for kipptog, godstog og fjerntog som er brukt i oppgaven.
Det er bare oppgitt tider ved Drammen stasjon. For fjerntogene er det ikke avklart
hvilken av togene som går fra/til Bergen eller Kristiansand. Dette bør undersøkes
videre hvilken løsning som gir best punktlighet. Tiden ved Drammen stasjon er
avgangstid.
Kipptog Sundhaugen - Holmen
Tognr 6330 6332 6334 6336 6338
Materiell Z71 Z71 Z71 Z71 Z71
Kipptog Kipptog Kipptog Kipptog Kipptog
Drammen 0512 0737 0937 1216 0516
Kipptog Holmen - Sundhaugen
Tognr 6331 6333 6335 6337 6339
Materiell Z71 Z71 Z71 Z71 Z71
Kipptog Kipptog Kipptog Kipptog Kipptog
Drammen 0637 0837 1037 1537 1736
Kipptog Sundhaugen - Brakerøya
Tognr 6440 6442 6444 6446 6448
Materiell Z71 Z71 Z71 Z71 Z71
Kipptog Kipptog Kipptog Kipptog Kipptog
Drammen 0518 1118 1318 1718 2118
Kipptog Brakerøya - Sundhaugen
Tognr 6441 6441 6445 6447 6449
Materiell Z71 Z71 Z71 Z71 Z71
Kipptog Kipptog Kipptog Kipptog Kipptog
Drammen 0800 1400 1500 1900 2300
Godstog Sundhaugen - Eriksrud
Tognr 5000 5002 5004 5006 5008 5010 5012 5014 5016 5018
Materiell El19 El19 El19 El19 El19 El19 El19 El19 El19 El19
Godstog Godstog Godstog Godstog Godstog Godstog Godstog Godstog Godstog Godstog
Drammen 0337 0437 0537 1137 1237 1337 1437 1637 2037 2137
Godstog Eriksrud - Sundhaugen
Tognr 5001 5003 5005 5007 5009 5011 5013 5015 5017 5019
Materiell El19 El19 El19 El19 El19 El19 El19 El19 El19 El19
Godstog Godstog Godstog Godstog Godstog Godstog Godstog Godstog Godstog Godstog
Drammen 0900 1000 1100 1201 1300 1800 1500 2000 2100 2200

Fjerntog Eriksrud - Gulskogen
Tognr 71 61 73 63 75 77 79 81 601 83 705 605
Materiell BM73 BM73 BM73 BM73 BM73 BM73 BM73 BM73 BM73 BM73 BM73 BM73
Fjerntog Fjerntog Fjerntog Fjerntog Fjerntog Fjerntog Fjerntog Fjerntog Fjerntog Fjerntog Fjerntog Fjerntog
Drammen 0645 0745 0845 0945 1045 1445 1645 1845 1945 2045 2245 2345
Fjerntog Gulskogen - Eriksrud
Tognr 70 62 72 64 74 76 80 82 602 84 706 606
Materiell BM73 BM73 BM73 BM73 BM73 BM73 BM73 BM73 BM73 BM73 BM73 BM73
Fjerntog Fjerntog Fjerntog Fjerntog Fjerntog Fjerntog Fjerntog Fjerntog Fjerntog Fjerntog Fjerntog Fjerntog
Drammen 0620 0720 0820 0920 1020 1420 1620 1820 1920 2020 2220 2320
1

Vedlegg B Forstudierapport
2010
Forstudierapport
Torgeir Sønstabø
Fakultet for Ingeniørvitenskap og
Teknologi, NTNU
07.09.2010

Forord
Denne forstudierapporten er skrevet til prosjektet Simulering av togtrafikk ved
produksjonsendring i TPK4510 produksjons- og kvalitetsteknikk ved Norges
teknisk-naturvitenskapelige universitet, fakultet for ingeniørvitenskap og
teknologi, institutt for produksjons- og kvalitetsteknikk.
Veileder ved SINTEF Teknologi og samfunn, Teknologiledelse er Øivind Stokland,
Sven-Jöran Schrader er veileder ved NSB AS mens ansvarlig faglærer ved NTNU
er Professor Bjørn Andersen
2

Table of Contents
Forord ..................................................................................................................................... 2
Introduksjon......................................................................................................................... 4
Bakgrunn for prosjektet................................................................................................... 4
Beskrivelse av problemer og behov ..................................................................................... 4
Avgrensning og Presisering ............................................................................................ 6
Avgrensning ................................................................................................................................... 6
Presisering ..................................................................................................................................... 6
Prosjektstyring .................................................................................................................... 8
Vedlegg ................................................................................................................................... 9
POS (Project Overview Statement)........................................................................................ 9
WBS (Work Breakdown Structure) .....................................................................................10
WBS 2 .............................................................................................................................................11
KTR (Kostnad, tid, ressurs) ....................................................................................................12
Gant-Diagram ..............................................................................................................................19
3

Introduksjon
Som en del av prosjektoppgaven “Simulering av togtrafikk ved
produksjonsendring” høsten 2010 skal det utarbeides en forstudierapport.
I denne forstudierapporten vil det utarbeides en analyse av oppgavens
problemstillinger og en nærmere beskrivelse av de arbeidsoppgaver som må
gjennomføres for løsning av oppgavene. Det vil også bli utarbeidet en detaljert
aktivitetsplan med anslag over arbeidsmengde i timeverk og en WBS (Work
Breakdown Structure). I tillegg vil det bli definert milepæler.
Bakgrunn for prosjektet
Denne oppgaven er et samarbeid mellom NTNU, SINTEF og NSB og skal løses
som en prosjektoppgave for stud. techn. Torgeir Sønstabø høsten 2010.
Norges Statsbaner (NSB) skal i 2012 innføre en ny grunnrutemodell for
østlandsområdet. Ved implementering av den nye ruteplanen vil Drammen
stasjon bli et kritisk punkt. I tillegg til vanlig persontrafikk er det mye
godstogtrafikk i og rundt Drammen stasjon med kipptog som kjører mellom
Sundland og Holmen/Brakerøya, godstog til/fra Oslo som kjører gjennom
stasjonen og skiftebevegelser fra persontog som vender/hensetter som tar opp
kapasitet på stasjonen.
Som et viktig hjelpemiddel vil NSB bruke simuleringsprogrammet OpenTrack
som muliggjør testing av robustheten til ruteplan 2012.
Denne oppgaven vil ta i bruk OpenTrack for å undersøke robustheten til
Drammen stasjon i 2012.
Beskrivelse av problemer og behov
Det er for oppgaven beskrevet en hovedproblemstilling:
”Kommer togtrafikken til å fungere tilfredsstillende etter en planendring, og hvis
ikke, hva kan vi gjøre for å bedre sannsynligheten for at det fungerer?”
To andre viktige problemstillinger er definert som:
- ” Hvordan kan NSB benytte simuleringsverktøy til robusthetsvurdere
nye ruteplaner?”
- ”Hvordan skal trafikkavviklingen i Drammensområdet, som blir et
kritisk punkt når ny ruteplan implementeres, løses?”
Arbeidet skal bestå av følgende punkter:
- Gjennomføre litteraturstudie for bruk av simuleringsverktøy som
verktøy ved robusthetsvurdering ved omlegging i jernbane- og
transportsektoren.
- Beskrive vanlig/mulig bruk av simuleringsverktøy
4

- Beskrive metodikk for å gjennomføring av robusthetsanalyser ved
simulering av nye ruteplaner i jernbanen.
1. Vurder statisktiske input i modellen
2. Vurder metoder for evaluering av output, datakvalitet,
tolkning/verifisering av resultater.
- Gjennomføre en simulering av togtrafikken i Drammens-området, og
identifisere problemer ved planlagt løsning
5

Avgrensning og Presisering
I punktene under vil oppgaven bli avgrenset og det vil bli presisert mer nøyaktig
hva som vil bli gjort i prosjektet.
Avgrensning
Litteraturstudiet rundt bruken av simuleringsverktøy generelt og i jernbanen
spesielt danner grunnlaget for oppgaven.
Del 1 vil ta for seg vanlig/mulig bruk av simuleringsverktøy og fungere som en
basis for resten av oppgaven.
Det er første gang NSB tar i bruk simuleringsverktøy til robusthetsvurderinger
av fremtidig togtrafikk, det vil derfor i del 2 av denne oppgaven bli fokusert på
bruken av simuleringsverktøy til robusthetsvurderinger av fremtidig togtrafikk,
med spesielt fokus på ruteplanen.
Del 3, som er analysedelen av oppgaven, vil kun fokusere på området rundt
Drammen stasjon, som vil bli et kritisk punkt når ny ruteplan skal
implementeres. Del 3 vil være sterkt knyttet til del 2.
Presisering
Del 1:
Beskrive vanlig/mulig bruk av simuleringsverktøy
Del 2:
- Finne og lese relevant litteratur rundt vanlig/mulig bruk av
simuleringsverktøy
- Analysere litteraturen
- Beskrive kort om utviklingen av bruken av simuleringsverktøy
- Presentere vanlig/mulig bruk av simuleringsverktøy
- Beskrive nyttegraden ved bruk av simuleringsverktøy som verktøy
Gjennomføre litteraturstudie for bruk av simuleringsverktøy som verktøy ved
robusthetsvurdering ved omlegging i jernbane- og transportsektoren.
- Finne og lese relevant litteratur rundt bruken av simuleringsverktøy
- Analysere litteraturen
- Presentere generell teori om robusthetsvurdering ved omlegging i
jernbane- og transportsektoren.
6

Del 3:
- Beskrive kort om utviklingen av bruken av simuleringsverktøy som
verktøy i jernbane- og transportsektoren
- Presentere bruken av simuleringsverktøy ved omlegging
- Presentere bruken av simuleringsverktøy ved robusthetsvurdering
Beskrive metodikk for gjennomføring av robusthetsanalyser ved simulering av
nye ruteplaner i jernbanen.
- Beskrive OpenTrack
- Vurdere statistiske input i modellen
o Bruke input fra AnnaLyse i OpenTrack og etter simulering undersøke om
input er lik output
o Undersøke sensitiviteten til modellen ved å øke/minske forsinkelsen med
for eksempel 20 % å undersøke endringene.
o Andre
- Vurdere metoder for evaluering av output, datakvalitet,
tolkning/verifisering av resultater.
o Ettersom en ved simulering ikke tar med alle variabler som er i
virkeligheten må resultatene verifiseres
o Andre
- Gjennomføre en simulering av togtrafikken i Drammens-området, og
identifisere problemer ved planlagt løsning
o Undersøke hvem som bør vende på Sundhaugen og hvem som bør vende
på Skamarken
o Teste robustheten til Drammen stasjon ved å undersøke om forsinkelsen
på togene er større etter de forlater Drammen stasjon enn den var før
o Undersøke om kipptogtrafikken kan avvikles i 2012 på samme måte som
dagens trafikk
o Andre
- Presentere fremtidige løsninger og forslag
o Simulere potensielle fremtidige løsninger og forslag på bakgrunn av
Svein Skartsæterhagens rapport “Kipptogkjøring mellom Sundland og
Holmen/Brakerøya – Situasjonsbeskrivelse og mulige tiltak for å kunne
beholde kipptogene ved R2012” fra 2009, som for eksempel å simulere
hvordan det påvirker trafikken på Drammen stasjon om kipptogene kan
kjøre eget spor fra Sundhaugen til Holmen/Brakerøya utenom vanlig
trafikk.
o Kunne svare på hvilken linje som bør vende på Sundhaugen og hvilken
linje som bør vende på Skamarken
o Andre
Hvert punkt har fått en post som heter “Andre” som symboliserer andre punkter
som vil bli fylt på etter litteraturstudiet.
7

Prosjektstyring
Prosjektstyring av arbeidet er en del av prosjektoppgaven og skal gjennomføres
parallelt med de andre oppgavene.
Prosjektet er delt i tre hoveddeler. Den første er en litteraturdel som skal gi et
innblikk i bruken av simulering som et verktøy på en generell basis. Del 2 er
også en litteraturdel, men i motsetning til del 1 skal denne gå spesifikt på bruken
av simulering som et verktøy ved omlegging i jernbane- og transportsektoren.
Del 1 og del 2 skal fungere som en bakgrunn for del 3, som er en analysedel.
Del 1 & 2 vil bli arbeidet med samtidig, mens del 3 først vil påbegynnes etter at
de to første delene er avsluttet.
Prosjektets varighet er på 17 uker, med estimert 24 timer i uken tilsvarer det
408 timer totalt. For å få en oversikt over hvor mye tid som skal brukes på hver
aktivitet er det satt opp en tabell som viser de forskjellige aktivitetene, antall
timer som er satt av til hver av de, og dato for start og slutt. Gant-diagrammet
bygger på denne tabellen.
WBS nr Aktivitet Milepæl Varighet (t) Start Slutt
1.1 Forstudierapport 24 23.08.2010 13.09.2010
Forstudierapport 1 - 13.09.2010 13.09.2010
1.2 Litteratursøk 60 05.09.2010 24.10.2010
2.1 Beskrive vanlig/mulig bruk av simuleringsverktøy 24 13.09.2010 06.10.2010
Statusrapport 2 - 18.09.2010 18.09.2010
2.2 Simuleringsverktøy som verktøy ved robusthetsvurdering 72 18.09.2010 01.11.2010
2.3.1 Vurder statistisk input 48 01.11.2010 10.12.2010
2.3.2 Metoder for evaluering av output 48 01.11.2010 10.12.2010
2.3.3 Identifisering av problemer ved Drammen stasjon 48 01.11.2010 10.12.2010
3 Rapportskriving 48 11.12.2010 20.12.2010
4 Statusrapport 16 13.10.2010 18.10.2010
5 Prosjektledelse 20 23.08.2010 21.12.2010
Ferdig prosjekt 3 - 21.12.2010 21.12.2010
Totalt 408
Det er også laget en POS (Project Overview Statement) for å gi en oversikt over
prosjektet. I tillegg er det laget WBS, Gant-diagram og KTR for hver av
aktivitetene.
8

Vedlegg
POS (Project Overview Statement)
POS
Prosjekt:
Dato rev:
Simulering av togtrafikk
ved produksjonsendring
07.09.2010
Problem:
NSB skal i 2012 innføre en ny grunnrutemodell for østlandsområdet. I
forbindelse med den nye grunnrutemodellen er det klart at Drammen stasjon vil
få ytterligere trafikk.
Hovedmål:
Undersøke robustheten til Drammen stasjon ved planendring.
Delmål:
- Beskrive vanlig/mulig bruk av simuleringsverktøy
- Beskrive bruken av simuleringsverktøy ved robusthetsvurdering ved
omlegging i jernbane- og transportsektoren
- Vurdere statistiske input i modellen
- Vurdere metoder for evaluering av output, datakvalitet,
tolkning/verifisering av resultater
- Gjennomføre simulering av togtrafikken i Drammens-området, og
identifisere problemer ved planlagt løsning.
Suksesskriterier:
- Overholde milepæler
- Få B eller bedre på prosjektet
- Prosjektet har nytteverdi for NSB
Forutsetninger, risiko, hindringer:
- Tilgjengelighet på relevant litteratur
- Tilgjengelighet på ressurser hos veileder & NSB
- Sykdom
- Uforutsette hendelser med simuleringsverktøy
9

WBS (Work Breakdown Structure)
1.1 Forstudierapport
1.2 Litteratursøk
1 Forstudie
Se WBS 2
2 Hoveddel
Prosjektoppgave
Høst 2010
3 Rapportskriving
3.1 Oppbygning av
oppgaven
3.2 Ferdigstilling
3.3 Korrektur
3.4 Print &
Innbinding
4 Statusrapport
4.1
Fremdriftsdiagram
4.2 Beskrivelse av
arbeidet gjort
4.3 Eventuelle avvik
4.4 Tiltak for
korrigering av
eventuelle avvik
5 Prosjektstyring
5.1 Analyse av
problemstillinger
5.2 Beskrivelse av
arbeidsoppgaver
5.3 Tidsplan, delmål,
mål, milepæler
10

WBS 2
2.1 Beskrive vanlig/
mulig bruk av
simuleringsverktøy
2 Hoveddel
2.2 Simuleringsverktøy
som verktøy ved
robusthetsvurdering
2.3.1 Vurder statistisk
input i modellen
2.3 Simulering
2.3.2 Metoder for
evaluering av output
2.3.3 Identifisering av
problemer med
Drammen stasjon
11

KTR (Kostnad, tid, ressurs)
Aktivitet
1.1 Forstudierapport
Oppgave:
Fra oppgaveteksten heter det: ”Kandidaten skal innledningsvis gjennomføre et
forstudium av oppgavens problemer og levere en rapport som inneholder en
analyse av oppgavens problemstillinger og en nærmere beskrivelse av de
arbeidsoppgaver som må gjennomføres for løsning av oppgavene. Beskrivelsen
av arbeidsoppgavene skal munne ut i en klar definisjon av innhold og
angrepsmåte. Basert på denne skal kandidaten sette opp en (hierarkisk
strukturert) aktivitetsplan for arbeidet. Kandidaten skal videre utarbeide en
fullstendig prosjektplan med anslag over arbeidsmengde i timeverk og en
tidsplan. Opplysningene skal samles i et eget plandokument. Det skal defineres et
antall milepæler.”
Målsetning:
Få en klar definisjon på innholdet av oppgaven og angrepsmåte.
Innhold:
- Beskrivelse av oppgaven
- Mål
- Avgrensning av oppgaven
- WBS
- Gant diagram
- POS
- KTR-skjema
Arbeidsmetode:
Litteratur, samtaler, rapportskriving
Utfordringer/Vanskeligheter:
- Avgrense oppgaven riktig i henhold til arbeidsmengde og ønsket
resultat.
Resultat:
Oppnå en plan for angrepsmåte med prosjektet
Varighet:
24 timer
12

Aktivitet
1.2 Litteratursøk
Oppgave:
Finne relevant litteratur for å utføre oppgaven.
Målsetning:
Finne litteratur til litteraturstudie (del1 og del2) som skal fungere som bakgrunn
for resten av prosjektet
Innhold:
Bøker, artikler og data som er relevant for oppgaven.
Arbeidsmetode:
- Internett
- Pensumlitteratur
- Bibliotek/Bibsys
- NSB dokumenter
- SINTEF dokumenter
Utfordringer/Vanskeligheter:
- Finne tilstrekkelig informasjon om bruk av simuleringsverktøy som
verktøy ved robusthetsvurdering ved omlegging i jernbane- og
transportsektoren. I tillegg må all informasjon verifiseres, dette
gjelder spesielt informasjon funnet på internett.
- Bruke mange nok kilder
- Ta notater fortløpende
Resultat:
Skaffe det teoretiske grunnlaget for videre arbeid med oppgaven.
Varighet:
60 timer
13

Aktivitet
2.1 Beskrive vanlig/mulig bruk av simuleringsverktøy
Oppgave:
Beskrive mer generelt om bruk av vanlig/mulig bruk av simuleringsverktøy, ikke
bare i jernbane- og transportsektoren.
Målsetning:
Få en god forståelse for nyttegraden av bruk av simuleringsverktøy og bredden
av bruken.
Innhold:
- Beskrive historisk utvikling ved bruk av simulering
- Beskrive vanlig/mulig bruk av simuleringsverktøy innen forskjellige
områder
Arbeidsmetode:
Litteratur, samtaler, rapportskriving
Utfordringer/Vanskeligheter:
Finne relevant informasjon
Resultat:
En bakgrunn for bruken av simulering som ligger i bunn for resten av oppgaven
Varighet:
24 timer
14

Aktivitet
2.2 Simuleringsverktøy som verktøy ved robusthetsvurdering.
Oppgave:
Gjennomføre litteraturstudie for bruk av simuleringsverktøy som verktøy ved
robusthetsvurdering ved omlegging i jernbane- og transportsektoren.
Målsetning:
Få en god oversikt over mulighetene ved bruk av simuleringsverktøy under
spesielle forhold.
Innhold:
- Beskrivelse av bruk av simulering innen jernbane- og transportsektor
generelt.
- Beskrivelse av bruk av simulering innen jernbane- og transportsektor
ved omlegging.
Arbeidsmetode:
Litteratur, rapportskriving
Utfordringer/Vanskeligheter:
Finne tilstrekkelig informasjon
Resultat:
En beskrivelse av muligheter ved bruk av simuleringsverktøy
Varighet:
72 timer
Aktivitet
2.3.1 Vurder statistiske input i modellen
Oppgave:
Vurdere om inputen som legges inn i programmet gir et riktig bilde på
virkeligheten etter simulering.
Målsetning:
Få verifisert at OpenTrack behandler statistisk input på en korrekt måte.
Innhold:
Litteratur, OpenTrack og rapportskriving
Arbeidsmetode:
- Legge inn statistisk input i OpenTrack og verifisere output etter
simulering
Utfordringer/Vanskeligheter:
Verifisering av output
Resultat:
Om OpenTrack behandler input på en korrekt måte
Varighet:
48 timer
15

Aktivitet
2.3.2 Metoder for evaluering av output
Oppgave:
Vurdere metoder for evaluering av output, datakvalitet, tolkning/verifisering av
resultater.
Målsetning:
Presentere resultater fra simulering på en oversiktlig og informativ måte.
Innhold:
- Analyse av data
- Beskrivelse av resultat
- Diskusjon av resultat
Arbeidsmetode:
Rapportskriving
Utfordringer/Vanskeligheter:
Presentere resultatene på en måte at de er lett å forstå av leser
Resultat:
Analyse(r ) som gir et gode metoder for evaluering
Varighet:
48 timer
Aktivitet
2.3.3 Simulering av togtrafikk i Drammens-området
Oppgave:
Gjennomføre en simulering av togtrafikken i Drammens-området, og identifisere
problemer ved planlagt løsning.
Målsetning:
Beskrive eventuelle problemer med togtrafikken i Drammens-området og foreslå
alternativer
Innhold:
- Analyse av data
- Beskrivelse av resultat
- Diskusjon av resultat
Arbeidsmetode:
Simulering og rapportskriving
Utfordringer/Vanskeligheter:
Vanskelig å begrense modellen,
Resultat:
Klare identifiserte problemer ved planlagt løsning.
Varighet:
48 timer
16

Aktivitet
3 Rapportskriving
Oppgave:
Skrive ferdig de ulike delene og ferdigstille rapport
Målsetning:
Et helhetlig dokument som fremstår gjennomtenkt
Innhold:
Hele den ferdige oppgaven med riktig struktur:
- Forord, innholdsfortegnelse og sammendrag
- Introduksjon med bakgrunn for oppgaven, målsetning og
rapportstruktur
- Hoveddel
- Konklusjon og referanseliste
- Vedlegg
Arbeidsmetode:
Skriving og veiledning
Utfordringer/Vanskeligheter:
En fin flyt gjennom rapporten.
Dataproblemer
Resultat:
En ferdigstilt rapport som NSB kan bruke i sitt arbeid med implementeringen av
ruteplan 2012
Varighet:
48 timer
Aktivitet
4 Statusrapport
Oppgave:
Lage en avrapportering av prosjektet per 18. oktober 2010
Målsetning:
Beskrive hvordan arbeidet med prosjektet ligger an.
Innhold:
- Framdriftsdiagram som viser plan, forbruk og fremdrift.
- Beskrivelse av arbeidet i perioden
- Eventuelle avvik
- Tiltak for korrigering av eventuelle avvik
Arbeidsmetode:
Rapportskriving, samtaler med veileder
Utfordringer/Vanskeligheter:
Eventuelle endringer som er gjort i prosjektet
Resultat:
En statusrapport om arbeidets gang frem til 18.oktober
Varighet:
16 timer
17

Aktivitet
5 Prosjektstyring
Oppgave:
Utføre prosjektstyring av prosjektet for å holde orden på gjennomføringen av
prosjektet.
Målsetning:
Styre prosjektet slik at prosjektet oppnår sine må gjennom at arbeidet blir gjort i
riktig rekkefølge og at tidsfrister overholdes.
Innhold:
- Analyse av problemstillinger
- Beskrivelse av arbeidsoppgaver
- Oppfølging av tidsforbruk
- Gjennomgang av mål, delmål og milepæler
Arbeidsmetode:
Kontinuerlig gjennom oppgaven og forstudierapporten. Oppdatere tidsplan.
Samtaler med veileder
Utfordringer/Vanskeligheter:
Holde tidsfrister og styre oppgave i henhold til tid og målsetninger
Resultat:
Holde tidsfrister og dokumentasjon av eventuelle endringer i oppgaven
Varighet:
20 timer
18

Gant-Diagram
ID Task Name Start Finish Duration
1 1.1Forstudierapport
23.08.2010 13.09.2010
22d
2 Slutt forstudierapport (milepæl)
13.09.2010 13.09.2010
0d
3 1.2Litteratursøk
05.09.2010 24.10.2010
50d
2.1 Beskrive vanlig/mulig bruk av
4 13.09.2010 06.10.2010
24d
simuleringsverktøy
5 Statusrapport
13.10.2010 18.10.2010
6d
6 Ferdig statusrapport (milepæl)
18.10.2010 18.10.2010
0d
2.2 Simuleringsverktøy som verktøy ved
7 18.09.2010 01.11.2010
45d
robusthetsvurdering
8 2.3.1 Vurder statistisk input i modell
01.11.2010 10.12.2010
40d
9 2.3.2 Metoder for evaluering av output 01.11.2010 10.12.2010
40d
10
2.3.3 identifisering av problemer ved
Drammen stasjon
01.11.2010
10.12.2010
11 Ferdigstille prosjekt
11.12.2010 20.12.2010
10d
12 Ferdig prosjekt (milepæl)
21.12.2010 21.12.2010
0d
13 Prosjektstyring
23.08.2010 21.12.2010
121d
40d
sep 2010 okt 2010
nov 2010
des 2010
22.8 29.8 5.9 12.9 19.9 26.9 3.10 10.10 17.10 24.10 31.10 7.11 14.11 21.11 28.11 5.12 12.12
19

Vedlegg C: Statusrapport per 18.10.2010
Statusrapport 18.10.2010 - Torgeir Sønstabø
Arbeidet så langt har gått greit, det var litt vanskeligheter med å komme i gang
med skrivingen, men etter samtaler med veiledere ble det utarbeidet en
disposisjon som gjorde arbeidet mer oversiktlig og har ført til at oppsettet av
oppgaven har blitt endret siden arbeidet med forstudierapporten.
I følge fremdriftsdiagrammet skulle jeg ha ferdigstilt følgende:
- Forstudierapport
- Beskrive vanlig/mulig bruk av simuleringsverktøy
I tillegg skulle
- Simuleringsverktøy som verktøy ved robusthetsvurdering være 67%
ferdigstilt.
Per dags dato er følgende gjort på prosjektoppgaven:
- Forstudierapport utformet og levert
- Beskrive vanlig/mulig bruk av simuleringsverktøy (100%)
- Bruk av simulering i jernbane (50%)
- Robusthetsanalyser ved simulering av nye ruteplaner (20%)
Avvik:
Avviket fra planen skyldes at oppsettet er omgjort en del. Del 1, vanlig/mulig
bruk av simuleringsverktøy, har ikke fått noen endringer på grunn av endring av
disposisjonen. Hensikten med denne delen er å gi en innføring i simulering
generelt, og gi en kort beskrivelse av vanlig bruk av simuleringsverktøy, samt
fordeler og ulemper ved bruken av simulering.
Videre har oppgaven blitt omgjort fra å bestå av ”Simuleringsverktøy som
verktøy ved robusthetsvurdering” med noen undergrupper, til å bli delt opp i tre
deler. Hvor den første delen ”Bruk av simulering i jernbane” skal være en
videreføring av Del 1, men gå mye mer spesifikt inn på bruken av simulering for
å simulere jernbanenettverk. Den neste delen ”Robusthetsanalyser ved
simulering av nye ruteplaner” tar for seg metodikken for gjennomføring av
robusthetsanalyse av ruteplanen ved hjelp av simulering. Den siste delen vil
teorien fra forrige delkapittel bli utøvd ved simulering av togtrafikken i
Drammens-området.
Det kan hende at oppdelingen av fakta om simulering generelt etterfulgt av
simulering i jernbane ikke er en gunstig løsning. Det kan tenkes at det kan gi en
uoversiktlighet i rapporten og at løsningen må omgjøres, men dette vil bli sett på
når begge delene er ferdigskrevet.

Endring av tidsplan:
Ettersom det har blitt en del endringer i forhold til oppsettet av oppgaven har
det blitt utarbeidet en ny WBS for hoveddelen og et nytt Gantt-diagram som
viser endringene av oppsettet og tidsplan.
Endring av oppgaven:
Det er ikke gjort noen endringer i oppgaveteksten per dags dato.
Vedlegg
WBS
1.1 Forstudierapport
1.2 Litteratursøk
1 Forstudie
Se WBS 2
2 Hoveddel
Prosjektoppgave
Høst 2010
3 Rapportskriving
3.1 Oppbygning av
oppgaven
3.2 Ferdigstilling
3.3 Korrektur
3.4 Print &
Innbinding
4 Statusrapport
4.1
Fremdriftsdiagram
4.2 Beskrivelse av
arbeidet gjort
4.3 Eventuelle avvik
4.4 Tiltak for
korrigering av
eventuelle avvik
5 Prosjektstyring
5.1 Analyse av
problemstillinger
5.2 Beskrivelse av
arbeidsoppgaver
5.3 Tidsplan, delmål,
mål, milepæler

WBS 2
2.1
Innføring i simulering
2.1.1
Hva er simulering
2.1.2
Historie om simulering
2.1.3
Vanlig/mulig bruk av
simulering
2.1.4
Fordeler og ulemper ved
simulering
Gantt-diagram
Opprinnelig tidsplan:
2.2
Bruk av simulering i
jernbane
2.2.1
Bakgrunn
2.2.2
Case-study: Italiensk
jernbane
2.2.3
Case-study: Nederlands
jernbane
2 Hoveddel
2.2.1.1
Simulering i jernbane
2.2.1.2
Fordeler med simulering i
jernbane
2.2.1.3
Simuleringsmetoder
2.2.1.4
Simuleringsprogrammer
ID Task Name Start Finish Duration
1 1.1Forstudierapport
23.08.2010 13.09.2010
22d
2 Slutt forstudierapport (milepæl)
13.09.2010 13.09.2010
0d
3 1.2Litteratursøk
05.09.2010 24.10.2010
50d
2.1 Beskrive vanlig/mulig bruk av
4 13.09.2010 06.10.2010
24d
simuleringsverktøy
5 Statusrapport
13.10.2010 18.10.2010
6d
6 Ferdig statusrapport (milepæl)
18.10.2010 18.10.2010
0d
2.2 Simuleringsverktøy som verktøy ved
7 18.09.2010 01.11.2010
45d
robusthetsvurdering
8 2.3.1 Vurder statistisk input i modell
01.11.2010 10.12.2010
40d
9 2.3.2 Metoder for evaluering av output 01.11.2010 10.12.2010
40d
10
2.3.3 identifisering av problemer ved
Drammen stasjon
01.11.2010
10.12.2010
11 Ferdigstille prosjekt
11.12.2010 20.12.2010
10d
12 Ferdig prosjekt (milepæl)
21.12.2010 21.12.2010
0d
13 Prosjektstyring
23.08.2010 21.12.2010
121d
40d
2.3
Robusthetsanalyser ved
simulering av nye
ruteplaner
2.3.1
Definisjon av ruteplan
2.3.2
Metodikk for
gjennomføring av
robusthetsanalyse
2.3.3
Evaluering av input i
modellen
2.3.2.1
Konstruere ruteplan
2.3.2.2
Kalibreringav modellen
2.3.2.3
Simulere drift
2.3.2.4
Evaluere og presentere
resultater
sep 2010 okt 2010
nov 2010
des 2010
22.8 29.8 5.9 12.9 19.9 26.9 3.10 10.10 17.10 24.10 31.10 7.11 14.11 21.11 28.11 5.12 12.12
2.4
Simulering
2.4.1
Kort om OpenTrack
2.4.2
Problemstilling
2.4.3
Kalibrering/validering av
OpenTrack modell
2.4.4
Simuleringsanalyse

Oppdatert tidsplan:
ID Task Name Start Finish Duration
1 1.1 Forstudierapport
23.08.2010 07.09.2010
16d
2 Slutt forstudierapport (milepæl)
13.09.2010 13.09.2010
0d
3 1.2 Litteratursøk
05.09.2010 24.10.2010
50d
4
5
6 2.1.3 Vanlig/mulig bruk av simulering 13.09.2010 06.10.2010
24d
8
9
2.1.1 Hva er simulering
2.1.2 Historie om simulering
Statusrapport
Ferdig statusrapport
10 2.2.1.1 Simulering i jernbane
13.09.2010
13.09.2010
13.10.2010
18.10.2010
06.10.2010
06.10.2010
06.10.2010
17.10.2010
18.10.2010
01.11.2010
24d
24d
5d
0d
27d
% Complete
7 2.1.4 Fordeler og ulemper ved simulering 13.09.2010 06.10.2010
24d
100%
11
2.2.1.2 Fordeler med simulering i
jernbane
12 2.2.1.3 Simuleringsmetoder
13 2.2.1.4 Simuleringsprogrammer
14 2.2.2 Case-study: Italiensk jernbane
06.10.2010 01.11.2010
27d
50%
15 2.2.3 Case-study: Nederlands jernbane 06.10.2010 01.11.2010
27d
0%
16 2.3.1 Definisjon av ruteplan
10.10.2010 15.11.2010
37d
60%
17 2.3.2.1 Konstruere ruteplan
21 2.3.3 Evaluering av input i modellen
22 2.4.1 Kort innføring i OpenTrack
23 2.4.2 Problemstilling
24 2.4.3 Kalibrering av OpenTrack modell
25 2.4.4 Simuleringsanalyse
28 5 Prosjektstyring
06.10.2010
06.10.2010
06.10.2010
10.10.2010
10.10.2010
20.10.2010
20.10.2010
25.10.2010
20.11.2010
23.08.2010
01.11.2010
01.11.2010
01.11.2010
15.11.2010
18 2.3.2.2 Kalibrering av modellen
10.10.2010 15.11.2010
37d
30%
19 2.3.2.3 Simulere drift
20 2.3.2.4 Evaluere og presentere resultater
10.10.2010
10.10.2010
15.11.2010
15.11.2010
15.11.2010
30.10.2010
15.11.2010
20.11.2010
10.12.2010
26 3 Ferdigstilling og redigering
11.12.2010 20.12.2010
10d
0%
27 Innlevering prosjekt
21.12.2010 21.12.2010
0d
0%
21.12.2010
27d
27d
27d
37d
37d
37d
37d
11d
27d
27d
21d
121d
100%
100%
90%
100%
100%
100%
100%
100%
80%
90%
80%
75%
50%
30%
20%
40%
0%
0%
0%
0%
50%
sep 2010 okt 2010 nov 2010 des 2010
22.8 29.8 5.9 12.9 19.9 26.9 3.10 10.10 17.10 24.10 31.10 7.11 14.11 21.11 28.11 5.12 12.12