Rapporteringstjänst för operatör och förare
Albin Byström Niklas Lindqvist
K T H R O Y AL I N S T I T U T E O F T E C H N O L O G Y
E L E K T R O T E K N I K O C H D A T A V E T E N S K A P
Abstract
Sveriges järnvägsnät utgör en viktig del i landets infrastruktur och transporterar både människor och stora mängder gods. Järnvägsnätet är dock störningskänsligt och då stora delar av infrastrukturen är enkelspårig blir alla fordon som trafikerar samma linje beroende av varandra och en försening på ett tåg resulterar ofta i följdförseningar till övriga tåg på samma linje. Idag sker uppföljning av förseningsorsaker manuellt och ofta lång tid efter att det hänt vilket resulterar i osäkra och opålitliga data.
Målet med detta projekt är att utveckla en prototyp för ett rapporteringssystem som skulle kunna implementeras i Sveriges järnvägsnät för att möjliggöra realtidsuppföljning på förseningar som uppstår. Förutom att rapporteringen ska ske i realtid ska även användaren direkt notifieras när en försening uppstår och på så sätt inte själv behöva ha koll på det.
Resultatet av projektet var en prototyp som i realtid upptäcker förseningar och då notifierar den berörda användaren om att en försening uppstått, vid vilken station det skett och förseningens omfattning i antal minuter.
Användaren har då möjlighet att rapportera orsak till förseningen. Prototypen upptäcker även följdförseningar.
Nyckelord
Rapporteringssystem; Prototyp; Rapporteringstjänst; Tågtrafik;
Abstract
The Swedish rail network constitutes an important part of its infrastructure and transports both people and large quantities of goods. Unfortunately, the rail network is susceptible to disruptions since a large amount of the rail network consists of one-track sections. Trains that traffic these sections are dependent on each other. One delay may result in subsequent delays for other trains. The follow-up of causes of delays is today done manually and often weeks after it occurred which may results in uncertain and unreliable data.
The goal of the project is to develop a prototype of a reporting system which could be implemented into the Swedish railway network to enable real time monitoring of delays that occurs. The prototype should notify the user when a new delay has occurred.
The result of the project was a prototype which in real time detects delays and notifies the affected users that a delay has occurred, at which station it happened and the extent of the delay is presented in minutes. The user then has an opportunity to report cause of delay. The prototype also detects subsequent delays.
Keywords
Reporting system; Reporting Service; Prototype; Train Traffic
i
Innehållsförteckning
1 Introduktion ... 1
1.1 Bakgrund ... 1
1.2 Problem ... 2
1.3 Syfte ... 2
1.4 Mål ... 2
1.4.1 Samhällsnytta, Etik och Hållbarhet ... 2
1.5 Metodologi / Metoder ... 3
1.6 Uppdragsgivare ... 4
1.7 Avgränsningar ... 4
1.8 Disposition ... 4
2 Applikationsutveckling och Rapporteringssystem ... 5
2.1 Trafikverkets orsakskoder ... 5
2.2 Applikationsprogrammeringsgränssnitt ... 6
2.3 Model-View-Controller ... 7
2.4 Webbprogrammeringsspråk ... 8
2.5 Ramverk ... 8
2.6 Databaser ... 9
2.7 Realtidskommunikation ... 11
2.8 Relaterat Arbete ... 11
3 Metodologier och Metoder ... 13
3.1 Metoder ... 13
3.2 Scrum ... 13
3.3 Framtagande av kravspecifikation ... 14
3.4 Implementeringsprocess ... 15
4 Systemkrav ... 16
4.1 Kravspecifikation ... 16
Krav som måste finnas:...17
Krav som bör finnas: ...18
Krav som kan finnas: ...18
5 Systemdesign ... 20
5.1 Phoenix ... 20
5.2 Rapporteringsformat ... 21
5.3 Trafikverkets Öppna API ... 21
5.4 Prototypens Struktur ... 22
6 Utveckling av prototyp ... 24
6.1 Hämta realtidsdata ... 24
6.2 Försening och Rapportering ... 26
6.3 Användargränssnitt ... 27
6.4 Datalagring ... 29
7 Resultat ... 32
7.1 Prototypen ... 32
7.2 Diskussion ... 34
8 Slutsatser ... 36
ii 9 Framtida Arbete ... 37 Referenser ... 38 Appendix A ... 1
1
1 Introduktion
Tågnätet är en viktig del i Sveriges infrastruktur och transporterar både människor och stora mängder gods. Tågtrafiken skiljer sig dock från övriga trafikslag på flera sätt och detta har både sina för- och nackdelar. En nackdel är att alla tåg som trafikerar samma sträcka är beroende av varandra. Detta beror på att stora delar av de tågsträckor som finns i Sverige idag är enkelspåriga [1]. Det innebär att om ett tåg råkar ut för någon störning eller annan avvikelse som orsakar en försening kommer med hög sannolikhet flera efterkommande tåg också att påverkas [2].
Ett tillvägagångssätt för att minimera risken för störningar är att identifiera orsaker till tidigare händelser som har gett upphov till störningar och analysera storleken av dessa händelsers påverkan. Den informationen kan sedan användas för att åtgärda orsakerna och minimera riskerna för framtida störningar och bidra till att optimera nätverket.
Störningar och andra avvikelser inom tågtrafik ger ofta upphov till förseningar. För att kunna effektivisera och undvika förseningar är en viktig del att kunna kartlägga orsakerna. För att kartlägga orsakerna behöver information om förseningar insamlas. Informationen måste vara korrekt och pålitlig för att det ska vara möjligt att identifiera orsaker.
Vid informationsinsamling av tidigare händelser finns flera kriterier att ta hänsyn till för att avgöra informationens pålitlighet [3]. Av dessa kan tre aspekter anses vara relevanta för informationsinsamling med syftet att kartlägga orsaker till förseningar.
Den första är tid, det vill säga hur lång tid efter att förseningen har inträffat som informationen samlas in [4]. En längre period innebär opålitligare data.
Den andra aspekten som har stor relevans vid informationsinsamling är hur detaljerad informationen är. Med mer detaljerad data finns större chans att dra relevanta slutsatser. Den sista aspekten som har betydelse är möjlighet till klassificering av insamlad data. Kan data klassificeras och grupperas ihop ges större möjligheter till att finna samband mellan återkommande förseningar och orsaker.
1.1 Bakgrund
Idag sker rapportering av förseningsorsaker manuellt och ofta lång tid efter att förseningen inträffade, upp till tre veckor. Vissa förare dokumenterar direkt vad orsaken till försening är och kan då med hög pålitlighet beskriva orsaken till förseningen när uppföljningen sker. Andra förare gör inte denna dokumentation och deras beskrivningar av orsaken är inte alltid pålitliga.
Speciellt om många förseningar skett från att en försening sker tills en uppföljning görs på den [5].
Den långa uppföljningstiden för rapportering av en försening gör modellen bristfällig ur ett tidsperspektiv. Dagens rapporteringsmodell använder
2 däremot Trafikverkets standardiserade orsakskoder [6] vilket gör orsaksrapporteringen detaljerad och samtidigt ger möjligheter till att sammanställa och analysera historik.
På grund av den långa uppföljningstiden är det svårt att få en pålitlig överblick av vad orsakerna är och kartlägga dem för att i sin tur veta vad som bär ansvaret för en händelse. Denna typ av information är värdefull för att kunna effektivisera dagens tågtrafik och användning av resurser.
1.2 Problem
Bristande och opålitlig information som dagens rapporteringsmodell förser skapar problem då det inte går att kartlägga vilka händelser som orsakar förseningar. Kan inte det göras går det inte att på förhand vidta åtgärder för att förebygga att systematiskt återkommande förseningar sker. Hur kan rapporteringsprocessen effektiviseras genom att i realtid notifiera lokföraren att en försening uppstått?
1.3 Syfte
Syftet med den här rapporten är att beskriva utvecklingen av en prototyp för ett rapporteringssystem för tågtrafiken. Rapporten kommer även beskriva hur avvikelser i tågtrafiken kan identifieras i realtid och notifiera lokföraren och möjliggöra rapportering. Vidare är syftet med rapporten att presentera hur händelser som uppkommit av samma orsak kan grupperas för att se totala påverkan i tågtrafiken. Slutligen är rapportens syfte att beskriva konstruktionen av den föreslagna lösningen till problemet.
1.4 Mål
Målet med projektet är att utveckla en prototyp som enkelt skulle kunna implementeras i dagens järnvägssystem i Sverige. Prototypen ska ge realtidsinformation till lokförare när deras fordon är försenade och göra det möjligt att på några sekunder kunna rapportera om förseningen beror på till exempel fordonsfel, förlängt uppehållstation eller stoppsignal. Prototypen ska kunna gruppera ihop förseningar som beror på samma händelse för att minska rapporteringsprocessen.
1.4.1 Samhällsnytta, Etik och Hållbarhet
Syftet med prototypen som ska utvecklas är att vara ett proof of concept och ligga till grund för utveckling av ett fullständigt system. Syftet för ett fullständigt system skulle vara att göra rapporteringen av förseningsorsaker enklare och mer pricksäker än vad den är idag genom att rapporteringen kommer ske i realtid. Med mer och säkrare statistik över förseningsorsaker kan dessa kartläggas och möjliggöra förebyggande åtgärder mot kommande förseningar i tågtrafiken. Ett sådant system kommer att kunna ha både direkt och indirekt påverkan på hållbarhet. Hållbarhetsproblemet delas vanligtvis upp i tre olika områden; ekologisk hållbarhet, social hållbarhet och ekonomisk hållbarhet [7].
3 Ett ekologiskt hållbart system definieras som ett system vars konsumtion av jordens resurser ej kompromissar miljöns förmåga att hinna återskapa uttagna resurser [8]. Ur ett miljöperspektiv kommer framtagandet av produkten inte ha någon direkt påverkan på miljön då produkten är ett mjukvarusystem. Däremot kan underhållning av systemet komma att ha viss indirekt påverkan på miljön. Idag kör 4 000 tåg per dag i Sverige [9] vilket innebär att stora mängder data kommer att samlas in och måste lagras på databasservrar. Databasservrar är energikrävande och producerar även en hel del värme och ljud [10]. Om systemet ska integreras i dagens tåg kan det även innebära att gamla elektronikkomponenter i tågen måste bytas ut eller blir onödiga vilket skulle leda till elektroniksvinn vilket har en direkt negativ miljöpåverkan [11].
Social hållbarhet definieras som möjligheten att tillgodose planeten och alla människors möjlighet att uppfylla sina fysiska och psykiska behov. På global nivå kopplas social hållbarhet ofta ihop med rättvisa, makt och rättigheter [12]. Arbetet har inte en direkt påverkan på social hållbarhet men kan ha en indirekt påverkan genom att transporter via tåg blir pålitligare.
Ekonomisk hållbarhet kan definieras på två olika sätt [13]. Det första är ekonomisk utveckling utan bekostnad på naturkapital eller socialt kapital [13].
Den andra definitionen av ekonomisk hållbarhet är ekonomisk utveckling utan hänsyn till naturkapital och socialt kapital [13]. Ur ett ekonomiskt perspektiv finns inte heller så mycket direkt ekonomisk påverkan bortsett från utvecklingskostnaden för systemet och hårdvaran som systemet kommer köras på. Indirekt kommer ekonomiska besparingar kunna göras hos tågoperatörer som idag betalar böter när deras tåg är försenade [5, 14]. Detta system kommer därför kunna främja ekonomisk hållbarhet hos tågoperatörer med hänsyn till båda definitionerna av ekonomisk hållbarhet.
1.5 Metodologi / Metoder
Forskningsmetoder kan delas in i två grundläggande kategorier; kvalitativ och kvantitativ [15]. Den kvalitativa forskningsmetoden kan användas för att få en djupare förståelse för åsikter, mening och beteende. Den forskningsmetoden använder ofta mindre uppsättning data som samlas in genom observationer, tidigare arbeten och intervjuer [15]. Den kvantitativa forskningsmetoden använder experiment och testning för att mäta variabler för att stödja eller förkasta hypoteser eller för att validera funktionaliteter i mjukvarusystem.
Den forskningsmetoden kräver större uppsättning data och att det som ska undersökas är kvantitativt mätbart [15]. Ibland kan inte en forskningsmetod väljas utan istället tillämpas då en blandning av de två, så kallat triangulation [15].
När forskningsmetod har valts gäller det att välja vilket tillvägagångssätt man vill använda för att dra slutsatser från den data eller information som samlats in. Detta kan göras på flera sätt men de vanligaste är induktivt och deduktivt [16]. Induktivt tillvägagångsätt innebär att man formar teorier och hypoteser utifrån den information som samlats in. Det induktiva tillvägagångssättet
4 tillämpas nästan alltid på data insamlad genom en kvalitativ forskningsmetod [15]. Deduktivt tillvägagångssätt testar teorier för att verifiera eller förkasta hypoteser. Det deduktiva tillvägagångssättet tillämpas oftast på en stor uppsättning data insamlad genom en kvantitativ forskningsmetod [15].
I detta arbete användes en kvalitativ forskningsmetod i form av en induktiv litteraturstudie i syfte att samla information om ämnet. Litteraturstudien kompletterades med en kvalitativ intervju/diskussion med uppdragsgivaren för att därefter kunna sammanställa en kravspecifikation.
1.6 Uppdragsgivare
Detta arbetet utförs på uppdrag av Wennberg Magnusson Consulting (WMC).
WMC är ett konsultföretag som inriktar sig på Sveriges järnvägar och framförallt inom projektledning och teknik. Företaget utför idag uppdrag för både SJ och SL [17].
1.7 Avgränsningar
Användningsområdena för ett rapporteringssystem är många men projektet är avgränsat till rapportering av förseningar och orsaker i järnvägstrafiken.
Järnvägsnäten i Sverige hanteras och underhålls av olika aktörer vilket gör att den tillgängliga datan kommer från olika källor och mängden data kan variera [18]. Därför har projektet vidare avgränsats till att utveckla en prototyp som endast avser ett tågnätverk. Det valda tågnätverket för detta projekt är Stockholms pendeltåg. Stockholms pendeltåg består av 8 linjer [19] och prototypen avser att vara kompatibel och kunna implementeras på samtliga tåglinjer.
1.8 Disposition
I kapitel 2 presenteras en teoretisk bakgrund till problemet och hur dagens tekniker används och fungerar samt tekniker som kommer att användas under utvecklingen av prototypen. Kapitel 3 beskriver och motiverar de metoder som tillämpats under projektet. I kapitel 4 presenteras den kravspecifikation som tagits fram. Kapitel 5 beskriver hur prototypen har designats och vilket ramverk som valdes att användas. I kapitel 6 beskrivs detaljerat hur prototypen har implementerats. Kapitel 7 presenterar projektets resultat.
Slutligen i kapitel 8 presenteras slutsatser och i kapitel 9 ges förslag på framtida arbete baserat på resultaten.
5
2 Applikationsutveckling och Rapporteringssystem
I detta kapitel presenteras en teoretisk bakgrund till prototypen. Sektion 2.1 beskriver Trafikverkets orsakskoder som idag används för att kategorisera förseningsorsaker inom tågtrafiken. Sektion 2.2 presenterar de applikationsprogrammeringsgränssnitt som skulle kunna användas för att utveckla prototypen. Sektion 2.3 presenterar modellen Model-View- Controller. Sektion 2.4 presenterar programmeringsspråk som används vid webbutveckling. Sektion 2.5 presenterar ramverk och webbramverk. Sektion 2.6 beskriver databaser och sektion 2.7 beskriver realtidskommunikation.
Sektion 2.8 presenterar relaterade arbeten.
2.1 Trafikverkets orsakskoder
Trafikverket har idag en standardiserad tabell med orsakskoder till alla möjliga förseningar i tågtrafiken [6]. I denna tabell finns totalt tre nivåer av förseningsorsaker med unika koder. Första nivån består av 5 olika orsaker;
driftledningsorsaker, följdorsaker, infrastruktursorsaker, järnvägsföretags- orsaker samt olyckor och tillbudsorsaker. Andra nivån består av totalt 35 olika underkategorier som i sin tur har 175 förseningsorsaker på detaljnivå.
Tabell 1 visar hur denna tabell är strukturerad med orsakskoder under Olyckor och tillbudsorsaker.
Tabell 1. Orsakskodstabell för Olyckor och tillbud (O). Skapad av författarna.
Beskrivning av Orsak Kodnivå 1 Kodnivå 2 Kodnivå 3
Olyckor och tillbud O - -
Broöppning O BÖ -
Broöppningstid överskriden O BÖ 1
Planerad broöppning O BÖ 2
Djur O DJ -
Vilt O DJ 1
Tamdjur O DJ 2
Renar O DJ 3
Människa O MÄ -
Påkörd person O MÄ 1
Obehöriga i spåret O MÄ 2
Polis/sjukdom O MÄ 3
Sabotage/hot O MÄ 4
Naturhändelser O NA -
Brand O NA 1
6
Översvämning O NA 2
Storm/Snöstorm O NA 3
Lavin O NA 4
Skred O NA 5
Kyla O NA 6
Avsyning av bana/fordon O SY -
Bana O SY 1
Fordon O SY 2
Tåg/arbetsrörelse O TÅ -
Urspårning/kollision O TÅ 1
Plankorsningsolycka O TÅ 2
ATC-nödbroms O TÅ 3
Otillåten stoppsignal-passage O TÅ 4
Uppkörd växel O TÅ 5
Sent till/från utland eller annan
infrastrukturförvaltare O UT -
Pass/tull O UT 1
Dessa olika nivåer av förseningsorsaker ger en detaljerad bild av vad den verkliga orsaken till en försening är. Samtidigt möjliggör det enkelt kategorisering och gruppering av olika nivå-3-orsaker som kategoriserats under samma nivå-2 eller nivå-1-orsak. Detta är mycket fördelaktigt för att kunna sammanställa statistik av förseningsorsaker.
2.2 Applikationsprogrammeringsgränssnitt
Ett applikationsprogrammeringsgränssnitt (API) är en specifikation på hur applikationsprogram kan använda och kommunicera med en specifik programvara som ofta är kopplade till ett dynamiskt bibliotek [20]. Det innebär att man genom funktionsanrop kan få data om exempelvis tågtrafiken. Det finns flera applikationsgränssnitt som ger tillgång till tåginformation i realtid och samtliga tillhandahålls av Trafikverket [21] eller Trafiklab [22]. Av dessa API:er finns två olika som tillhandahåller tillräcklig information för att kunna identifiera förseningar i pendeltågstrafiken, Trafiklabs SL Realtidsinformation 4 [23] och Trafikverkets Trafikverkets Öppna API [24].
SL Realtidsinformation 4 förser användaren med realtidsinformation om bussar, tunnelbana, pendeltåg, lokalbana och båtar i Stockholm. För att kunna använda API:et krävs en API-nyckel som kan fås genom att skapa ett konto och starta ett projekt på Trafiklabs hemsida. Det finns även en del begränsningar på mängden anrop som går att göra per minut och per månad.
7 Dessa begränsningar beror på vilken nivå av på sin nyckel man har och kan variera från 30–60 anrop per minut och mellan 10 000 och 1 500 000 anrop per månad. Vid ett anrop kan svaren ges på formaten Extensive Markup Language (XML) [25] eller JavaScript Object Notation (JSON) [26] vilka båda är två standardiserade format för att lagra och transportera data.
Trafikverkets Öppna API består av flera olika objekttyper inom olika områden vilket även inkluderar tågtrafiken. Tre av objekttyperna innefattar någon information om tågtrafiken och dessa är TrainMessage, TrainStation och TrainAnnouncement. Objekttypen TrainMessage förser användaren med tågmeddelanden och när dessa ändras och är inte relevant för detta projekt.
Likaså med TrainStation som ger information om tågstationer. Slutligen objekttypen TrainAnnouncement ger information om var tåg befinner sig, var de har varit, vilket tåg det är, vilken tid den varit där och om någon planerad försening skett. Detta API tillhandahåller all den data som krävs för att kunna identifiera en försening och veta var den skett och vilket tåg som är inblandat.
För att kunna använda Trafikverkets Öppna API krävs en API-nyckel som kan fås genom att registrera ett konto på trafikverkets hemsida. Trafikverkets Öppna API har inga begränsningar på maximalt antal anrop varken per minut eller per månad. Även trafikverkets Öppna API ger svarkoden från API-anrop på formaten XML eller JSON.
2.3 Model-View-Controller
Målet för många program är visualisering och ge möjlighet till manipulering av lagrad information för användare av programmet. Användargränssnitt ger användare möjlighet att bruka ett programs funktioner och filtrerar information utifrån användarens preferenser. Utveckling av användargränssnitt och den bakomliggande logiken för informationshantering skiljer sig. De är två olika områden som kräver olika kunskaper och verktyg [27]. Vid utveckling av program kan därför utvecklingen delas upp i moduler där varje modul har en specifik uppgift.
Model-View-Controller (MVC) är ett utvecklingsmönster för att modellera och modulera utvecklingen av ett program [27, 28]. MVC består av 3 moduler;
Model, View och Controller. Se figur 1 för hur modulerna integrerar med varandra.
Figur 1. Struktur för Model-View-Controller. Skapad av författarna.
8 Den bakomliggande logiken för att hantera lagrad information samlas i modulen Model och all logik för användargränssnittet är en del av modulen View. Logiken för att hantera användarintegration och informera Model och View om förändringar samlas i modulen Controller.
En fördel med att använda MVC som utvecklingsmodell är att utvecklingen kan delas upp i de tre modulerna och ske oberoende från varandra.
Utvecklingen av användargränssnittet kan baseras på exempeldata under utvecklingsprocessen utan att den bakomliggande logiken är färdig.
Utvecklingsprocessen kan alltså ske i parallell mellan de olika modulerna utan att de direkt påverkar eller blockerar varandra [28]. Inom webbutveckling används oftast MVC för att dela upp utvecklingen [29].
2.4 Webbprogrammeringsspråk
Vid utveckling av webbsidor och webbapplikationer finns tre olika programmeringsspråk som tillsammans lägger grunden. Dessa tre är HyperText Markup Language (HTML), Cascading Style Sheets (CSS) och JavaScript (JS) [30].
HTML är ett standardiserat märkspråk som tillsammans med Transmission Control Protocol/Internet Protocol (TCP/IP) och HyperText Transfer Protocol (HTTP) utgör grunden för World Wide Web (WWW) [30]. HTML används för att beskriva strukturen på websidor genom att använda olika markeringar (rubriker, paragrafer, tabeller et cetera). HTML används även för att specificera websidors metadata såsom titel, språk och författare [31].
CSS är ett stilarksspråk som används för att beskriva hur ett dokument skrivet i ett märkspråk (exempelvis HTML) ska presenteras. Stilarket kan användas för att sätta bland annat fonter, färger och layout på dokumentet [32]. CSS är precis som HTML en av grundstenarna tillsammans med JavaScript för World Wide Web [30].
JS är ett scriptspråk som möjliggör interaktivitet på websidor vilket är en grundläggande funktion för nästan alla webapplikationer [33]. Med interaktivitet menas att olika event (exempelvis knapptryckning) kan generera olika följder. Dessa följder är ofta ändringar av HTML-objekts CSS eller generering av nya HTML-objekt.
2.5 Ramverk
Ett ramverk är en samling av källkod eller bibliotek som förser funktionalitet som är gemensam för stora mängder applikationer [34]. Skillnaden mellan ett biliotek av funktioner och ett ramverk är att ett bibliotek oftast ger specifik funktionalitet medan ett ramverk erbjuder ett bredare utbud med flera funktionaliteter som alla är vanligt förekommande inom en viss typ av applikation [34].
9 Fördelarna med ramverk är många. Att använda kod som är färdigutvecklad, testad och använd av andra programmerare ökar tillförlitligheten samtidigt som tid sparas för att skriva koden själv [34, 35]. Då ramverk är utvecklade för att användas inom en typ av applikation följs ofta standarder, konventioner och vanliga designmönster för den typen av applikation och underlättar därför för utvecklaren att också följa dessa. Förutom fördelar med ramverk finns även vissa nackdelar. Ofta kan prestanda kompromissas när koden som används inte är skräddarsydd för en enda funktionalitet och ett enda användningsområde [34]. Detta problem kan däremot lösas genom att överskrida (eng. override) ramverkets metoder/funktioner med sina egna [35]. Ramverk har även ofta en hög inlärningskurva för att kunna användas korrekt vilket gör det väldigt tidskrävande att börja använda ett ramverk man saknar tidigare erfarenheter ifrån.
Ett webramverk är ett typ av ramverk som är speciellt designade för att underlätta för utveckling av webapplikationer [36]. Dessa ramverk har ofta stöd för användar-sessioner, datalagring och ett skal för systemet [36].
2.6 Databaser
Det finns två olika typer av information, ostrukturerad information och strukturerad information. Ostrukturerad information är information som inte har en fördefinierad struktur. Informationen kan bestå av olika typer av information som text, datum eller nummer. Eftersom att strukturen inte är definierad är det svårt att analysera informationen och se relationer inom informationen. Ett exempel är inom en mängd olika texter är det svårt att hitta relationer mellan texterna eftersom att texten eftersom att en relation inte är uppenbar [37, 38, 39].
Strukturerad information är information som modelleras utifrån ett behov.
Strukturen på informationen är fördefinierad vilket medför att informationen är lättare att analysera och hitta relationer. Strukturerad information är lättare att mäta [38].
Databaser kan användas för att lagra en mängd information. Databaser har funktioner för att lägga till, ta bort och uppdatera information [40]. Databaser har också stöd för att hämta lagrad information med hjälp av sökkommandon.
Relationsdatabaser används för att lagra strukturerad information där relationer inom information behöver lagras [41]. En relation kan exempelvis vara en mailadress som är kopplat till ett användarnamn. I relationsdatabaser lagras information oftast i relationer i form av tabeller. Relationer kan ha flera attribut där varje attribut representeras som en kolumn i tabellen. För att identifiera en relation behövs en nyckel. En nyckel är ett unikt värde som används för att identifiera relationer [41].
Vid design av relationsdatabaser kan Entity–relationship-diagram (ER- diagram) användas [42]. ER-diagram används för att modellera hur information relaterar till varandra. Först delas information upp i entitetstyper
10 där varje entitetstyp har attribut [42]. Entitetstyper kan ha samband mellan varandra. Ett samband betyder att entitetstyperna är sammankopplade och relaterar till varandra. En speciell grupp av entitetstyper som är beroende av samband till andra entitetstyper är svaga entitetstyper. Svaga entitetstyper är entitetstyper som inte kan existera utan en annan entitetstyp [42]. Se figur 2 för beskrivning av ett ER-diagram.
Figur 2. Beskrivning av ER-diagram. Skapad av författarna.
I ER-diagram representeras entitetstyper av rektanglar med namnet på entitetstypen. Cirklar som är kopplade till entitetstypen är tillhörande attribut. Ett understreckattribut är en eller en del av nyckeln för entitetstypen.
Samband mellan entitetstyper visas genom en romb som sammankopplar entitetstyper. Svaga entitetstyper illustreras genom en ram runt entitetstypen.
Från ER-diagram kan tabeller skapas som sedan används i en databas [43].
Varje entitetstyp blir en tabell med kolumner motsvarande attributen tillhörande entitetstypen där nyckel blir nyckelkolumn i tabellen. För svaga entitetstyper läggs nycklarna till för entitetstyperna som de beror på.
De flesta relationsdatabaser använder sig av programspråket Structured Query Language (SQL) för att hämta och redigera information i databasen.
SQL är en standardiserat programspråk som kan användas för att hämta och modifiera data från flera relationer eller tabeller och filtrera resultatet med ett kommando [44].
11 2.7 Realtidskommunikation
Det finns flera olika metoder och verktyg för att kommunicera mellan flera enheter samtidigt. En programmeringsmodell som bygger på idén att kommunicera mellan olika processer eller enheter genom att skicka och ta emot meddelanden är Message Passing (MP). I MP har varje process sitt egna lokala minne och är oberoende av andra processer bortifrån att de kan skicka information mellan varandra [45]. Fördelen med MP är att det är en distribuerad modell.
Elixir är ett funktionellt programmeringsspråk som kan används för att utveckla skalbara distribuerade system [46]. Elixir använder sig av Erlang virtuella maskin och delar många av funktionaliteterna med Erlang. I Elixir finns stöd för att skapa parallella processer och stöd för att skicka meddelande mellan processer. Elixir lämpar sig därför att utveckla utifrån MP modellen.
En speciell typ av processer i Elixir är en generic server process (GenServer) [47]. Andra processer kan anropa en GenServer-process med hjälp av två funktioner call och cast. Funktionen call skickar en förfrågan till en GenServer-process och anropande process väntar på ett svar [48]. Funktionen cast skickar ett meddelande till en GenServer-process och väntar inte på ett svar [49]. Vid både call och cast avslutas anropet med att tillståndet för GenServer processens bestäms. Mellan anrop är en GenServer-process i ett väntande läge och exekverar ingen kod [50].
En metod för att implementera kommunikation mellan flera enheter är Sockets [51]. Med hjälp av Sockets kan tvåvägskommunikation ske över ett nätverk mellan processer eller program. För att identifiera avsändare och mottagare används en kombination av IP-adresser och portnummer. IP- adressen används för att identifiera den mottagande enheten. Ett portnummer används för att den mottagande enheten ska kunna identifiera den mottagande processen [52]. Kommunikation sker genom att avsändaren skriver till mottagarens socket som mottagaren sedan läser från.
HTML5 WebSocket är en Socket-implementation för webbapplikationer som möjliggör tvåvägskommunikation mellan applikationer [53]. WebSocket har inbyggt stöd för att skicka meddelanden mellan klienter och mellan klient och server [54].
2.8 Relaterat Arbete
De relaterade arbeten som kan sägas vara mest relevanta för detta projekt är tidigare arbeten som på något sätt analyserar tågtrafik i realtid. På trafiklabs hemsida finns listor med projekt som gjorts där de olika API:erna de tillhandahåller använts. Bland dessa finns ett som heter Tåg.Info [55] som använder Trafikverkets Öppna API för att i huvudsyfte kunna söka efter tåg och se var de befinner sig. Sidan visar också dagens punktlighet bland alla tåg i Sverige samt listar de tåg och stationer som har mest förseningen under den nuvarande dagen.
12 Tåg.Info är ett projekt utvecklat av en privatperson och ingen rapport eller annan dokumentation om sidan finns tillgänglig. Detta gör det svårt att använda Tåg.Info som grund för prototypen men däremot kan tips och idéer hämtas från sidan för hur förseningar kan presenteras på ett tydligt och användarvänligt sätt.
13
3 Metodologier och Metoder
I detta kapitel beskrivs några av de arbetsmetoder som finns och vilka av dem som tillämpats under detta projekt. Sektion 3.1 beskriver kategorier av mjukvaruutvecklingsmetoder och motiverar dess för- och nackdelar. Sektion 3.2 beskriver sedan den agila arbetsmetoden Scrum och hur denna anpassats för att på bästa sätt kunna tillämpas på detta projekt. Sektion 3.3 beskriver hur kravspecifikationen tagits fram följt av sektion 3.4 där implementations- processen beskrivs översiktligt.
3.1 Metoder
För att kunna ha kontroll och struktur vid mjukvaruutveckling finns olika arbetsmetoder att tillämpa. Dessa arbetsmetoder fungerar som ett ramverk för hur utvecklingsarbetet ska gå till, när och hur saker ska planeras och hur funktionaliteter ska testas. Två vanliga typer av arbetsmetoder vid mjukvaru- utveckling är agila arbetsmetoder och vattenfallsmodellen [56].
Agila arbetsmetoder består av ett flertal metoder baserade på ett iterativt arbetssätt [57]. Arbetet delas då in i iterationer där varje iteration har sina egna mål och delmål och kan ses som ett eget litet projekt. Agila arbets- metoder tillåter även att mål och krav kan komma att ändras under projektets gång [57].
Vattenfallsmodellen är en sekventiell arbetsmetod där arbetet delas upp i två huvudsakliga delar; design och test [56]. I designfasen bestäms vad som ska göras ner på detaljnivå medan testfasen specificerar hur systemet ska testas.
Mellan dessa faser ligger själva utförandet av projektet. Denna metod är enkel att implementera men kan begränsa ett projekt då kraven som satts i början av projektet inte kan ändras [56].
Under detta projekt har en agil arbetsmetod valts dels för att utvecklarna sedan tidigare är bekanta med arbetssättet. Dessutom underlättar det att genom projektets gång kunna omvärdera de krav som satts och eventuellt ändra krav som visat sig vara onödiga eller omöjliga att uppfylla.
3.2 Scrum
Den agila arbetsmetod som utvecklarna har tidigare erfarenheter ifrån är Scrum [58]. Förutom det iterativa arbetssätt som agila arbetsmetoder tillämpar så innefattar Scrum ytterligare roller såsom en Scrum Master och en Product Owner. En Scrum Master verkar som en coach för utvecklingsteamet och Product Owner är den person eller företag som äger produkten. Andra saker som utmärker Scrum från andra agila arbetsmetoder är Product Backlog, Sprint Backlog, Sprint, Daily Scrum samt Sprint Retrospective och Sprint Planning [58].
Varje iteration i det agila arbetssättet kallas i Scrum för en sprint. Product Backlog är en samlingsplats för alla önskemål om förändring av produkten eller produktens slutfunktionalitet. Denna ägs och hanteras av produktägaren.
14 En Sprint Backlog är den del av Product Backlog som utvecklingsteamet åtar sig att genomföra under nästkommande sprint. Daily Scrum är ett möte som hålls varje dag där varje medlem i utvecklingsteamet berättar vad hen gjort sedan igår, vad som ska göras till imorgon och om några problem har uppstått. Sprint Retrospective är ett möte som hålls efter varje sprint där den gångna sprinten utvärderas och några förbättringsområden identifieras till nästkommande sprint. Slutligen Sprint Planning är ett möte där näst- kommande sprint diskuteras och alla önskemål gås igenom och prioriteras.
Därefter översätts önskemålen till krav som sedan estimeras hur lång tid de kommer ta att genomföra [58].
Under detta projekt kommer en modifierad version av Scrum att användas.
Anledningen till att Scrum inte tillämpas full ut är att utvecklingsteamet består av två personer vilket skulle innebära att flera av formaliteterna som kommer med Scrum skulle vara överflödiga. Rekommenderad storlek på utvecklingsteamet vid Scrum som arbetsmetod är 5–11 personer inklusive Scrum Master och produktägare [59]. Därför valdes att inte ha någon Scrum Master och istället bestämdes det att allt ansvar skulle delas lika mellan de båda utvecklarna. En Product Backlog sammanställdes direkt till en krav- specifikation som sprintarna sedan utgick ifrån. Sedan modifierades även möten som Sprint Retrospective och Sprint Planning till mer informella möten mellan utvecklarna.
3.3 Framtagande av kravspecifikation
För att kunna utveckla en prototyp av ett mjukvarusystem är det viktigt att innan utvecklingsarbetet påbörjas att det finns en tydlig mall på vilka funktionaliteter prototypen ska ha. En sådan mall kommer ofta i formen av en kravspecifikation. En kravspecifikation tas oftast fram direkt av uppdrags- givarna eller utvecklarna själva eller en kombination av de båda. I detta projekt kommer en tvåstegsvariant av kombinationen att användas [56].
Inledningsvis hölls ett möte mellan utvecklarna och arbetsgivarna där en diskussion av olika funktionaliteter hölls. Under mötet diskuterades vilka funktionaliteter som var mest önskvärda, vad som är rimligt att göra under den period som kontraktet löper samt vilka funktionaliteter som inte ska prioriteras.
Därefter satte sig utvecklarna tillsammans och började ta fram en krav- specifikation utifrån de funktionaliteter som diskuterades under mötet. Vid framtagandet av kravspecifikationen användes en mall där det för varje krav specificerades med ett nummer. Det specificerades även vem som var ansvarig för att kravet satts in i kravspecifikationen (WMC eller utvecklarna). Även hur prioriterat kravet är i form av stämplarna måste finnas, bör finns, kan finns och bör ej finnas [56] inkluderas.
Måste finnas innebär att prototypen måste ha dessa funktionaliteter för att uppfylla arbetsgivarens krav. Krav som specificeras som bör finnas är krav som nödvändigtvis inte behöver uppfyllas för en acceptabel prototyp. Kan
15 finnas innebär att funktionaliteten kan finnas på prototypen men att fokus ej ska ligga på dessa krav. Slutligen bör ej finnas specificerar krav som i detta projekt ej ska uppfyllas men som i framtida projekt kan komma att bli relevanta krav [56].
Nästa attribut av kravspecifikationen är kravets namn och en förklaring av vad som ska vara uppnått för att kravet ska anses vara uppfyllt. Slutligen fanns en kolumn där kravets nuvarande status specificerades. I denna kolumn anges ej uppfyllt eller uppfyllt för att i slutet av projektet enkelt kunna avgöra vilka krav som uppfyllts och vilka som ej uppfyllts och eventuellt kan bli framtida arbete.
För att säkerställa att båda parter var nöjda med den framtagna krav- specifikationen hölls ytterligare ett möte när kravspecifikationen var sammanställd av utvecklarna. Under mötet gick uppdragsgivarna igenom kravspecifikationen och eventuella krav eller förslag på förändringar presenterades. Därefter godkändes kravspecifikationen av både utvecklare och uppdragsgivare.
3.4 Implementeringsprocess
Under implementationsprocessen tillämpades den anpassade version av Scrum som beskrivs i sektion 3.2. Totalt utformades 6 iterationer av prototyputveckling där varje iteration gjordes till en arbetsvecka. Varje sprint startade med att välja ut vilka krav från kravspecifikationen som skulle bli den kommande sprintens mål. Därefter delades krav upp i delkrav som sedan sattes på en virtuell anslagstavla med kolumnerna ”ej påbörjat”, ”pågående”
och ”färdig”. Detta underlättade att se vad den andra personen höll på med och också få en överblick över allt som skulle göras under den aktuella sprinten.
16
4 Systemkrav
Projektets huvudsyfte var att utveckla en prototyp för ett rapporteringssystem som skulle kunna implementeras i Sveriges järnvägsinfrastruktur. För detta krävdes enkla funktionaliteter som att användaren kan rapportera en orsak och att denna rapportering sedan lagras i exempelvis en databas. Förutom dessa enkla funktionaliteter krävdes mer avancerade funktioner för att göra systemet användarvänligare och mer funktionellt.
För att kunna sammanställa en kravspecifikation är det viktigt att veta hur uppdragsgivaren prioriterar olika funktionaliteter. Det är även viktigt att varje kravs omfattning uppskattas för att utvecklarna därefter ska kunna göra en rimlighetsuppfattning.
Uppdragsgivarens högsta prioriteringar av funktionalitet är ett rapporterings- system som automatiskt ska detektera förseningar och då notifiera berörda användare om denna försening. Orsaken till förseningen ska sedan kunna rapporteras och lagras i exempelvis en databas. Uppdragsgivaren ansåg även att möjligheten till att enkelt kunna demonstrera prototypen för tredje part var viktig. Hur denna demonstration skulle gå till ansågs inte lika viktigt men gärna att det ska gå att köra på en iPad eller annan surfplatta. Lägre prioriterad funktionalitet från arbetsgivaren var möjligheten till att kunna se statistik på både förseningar och orsakerna till dessa förseningar samt möjligheten till att kunna gruppera ihop förseningar som orsakats av samma händelse.
Då uppdragsgivaren inte ställde några krav på hur funktionaliteten skulle implementeras gavs utvecklarna fria händer till att välja verktyg som kunde motiveras lämpliga. Utvecklarna ansåg trots att projektet endast avser en prototyp att möjligheterna till att skala upp prototypen på flera enheter ska vara möjligt vilket låg till grund för vilka verktyg som valdes att användas.
4.1 Kravspecifikation
För att säkerställa prototypens vision sammanställdes en kravspecifikation i dialog mellan utvecklare och uppdragsgivare. Alla funktionaliteter som ansågs vara relevanta funktioner för ett rapporteringssystem finns i denna kravspecifikation. De krav som fastställdes fick sedan klassificeringen måste finnas, bör finnas eller kan finnas. Några krav av typen bör ej finnas togs inte fram. I denna sektion kommer dessa krav att presenteras.
Alla dessa krav och deras klassificeringar används vid design och utveckling av prototypen. Det underlättar också att prioritera vad som ska implementeras först för att inte lägga tid på fel saker. Därmed minskar risken att prototypen kommer sakna viktiga funktionaliteter. En fullständig kravspecifikation med fler attribut på tabellform finns i bilaga A.
17 Krav som måste finnas:
• Systemet ska använda realtidsdata för att logga alla tåg och kunna avgöra om ett tåg är försenat.
• Vid en försening ska systemet notifiera användaren för det försenade tåget om att en försening uppstått och möjliggöra rapportering av orsaken till förseningen.
• Systemet ska lagra historik av tidigare händelser. Denna historik ska vid ett senare tillfälle kunna visas.
• Systemet ska genom lagrad historik kunna visa upp statistiska data över förseningar.
• Systemet ska vara anpassat till en standardiserad rapportering av orsaker. Exempelvis som Trafikverkets orsakskoder för rapportering av förseningsorsaker [6].
• Prototypen ska kunna simulera förseningar för att kunna användas vid en demonstration av prototypen.
• Prototypen ska implementera ett användargränssnitt som ska kunna användas på en surfplatta för att rapportera förseningsorsaker.
• Prototypen ska vara utvecklad på ett sätt att den enkelt kan skalas upp och användas på ett flertal enheter.
För att prototypen ska kunna verka som ett rapporteringssystem är det viktigt att den i realtid kan upptäcka förseningar för att rapporteringen ska kunna ske i direkt samband med förseningen. Att systemet ska notifiera användaren går ihop med kravet om att upptäcka en försening i realtid. Dessa krav tillsammans ställer krav på systemet att användaren själv inte ska behöva ha koll på när en försening skett utan ska bara bli tillbedd att rapportera orsaken när det sker. Lagring av historik är en grundläggande funktion för att kunna kartlägga förseningar i tågtrafiken och uppfylla WMC:s långsiktiga mål med systemet. Visa statistik av historik ansågs nödvändig för att på ett bra sätt kunna presentera den historik som systemet ska lagra.
På vilket format orsaker rapporteras är en viktig del för att senare kunna analysera den data som samlas in. Där önskades ett genomtänkt format som ska kunna göra detta möjligt. När prototypen ska demonstreras är det viktigt att kunna visa att den fungerar och även kunna visa på alla dess funktionaliteter och därför måste någon form av simulering av prototypen finnas. För att prototypen ska kunna demonstreras på ett tåg som idag inte har någon teknik installerad för att kunna rapportera orsaker ansågs en surfplatta som en lämplig enhet att köra prototypen på. Slutligen eftersom en slutgiltig produkt ska kunna användas samtidigt på flera enheter och att
18 denna slutprodukt kommer att grundas i denna prototyp ansågs det nödvändigt att prototypen ska vara implementerad på ett sätt som enkelt kan skalas och användas på flera enheter.
Krav som bör finnas:
• Systemet ska kunna uppvisa statistiska data över förseningar för en vald tidsperiod.
• Systemet ska automatiskt gruppera ihop förseningar som beror på samma orsak.
• Prototypen ska teoretiskt kunna implementeras på Stockholms pendeltågslinje. Med andra ord ska den vara kompatibel med den realtidsdata som finns tillgänglig för Stockholms pendeltåg.
Att systemet ska kunna visa statistiska data över en vald tidsperiod är inget krav som prototypen på något sätt är beroende av men denna funktionalitet fyller ändå viss viktig funktion. Denna funktionalitet skulle göra det möjligt att direkt i prototypen kunna finna mönster av olika förseningar. Exempelvis kan periodiserat återkommande förseningsorsaker identifieras om någon tidsperiod större andel förseningar med en viss orsak.
Gruppering av förseningar är heller inte någon funktionalitet som prototypen beror på men det skulle underlätta rapporteringen om prototypen kan identifiera förseningar och gruppera ihop dessa istället för att användaren ska rapportera varje försening manuellt. Då en slutprodukt kommer att baseras på denna prototyp är det önskvärt att prototypen är implementerad på ett sätt som gör det lätt att utöka systemet och fungera för hela Sveriges tågtrafik.
Krav som kan finnas:
• Prototypen ska utifrån statistik från tidigare förseningar genom statistiska modeller eller maskininlärning kunna göra smarta antaganden om orsaken till en försening och då ge förslag till användaren om förseningsorsak i samband med notifieringen om en försening.
• Prototypen ska kunna simulera verkliga förseningar för att kunna användas vid en demonstration av prototypen.
Genom att analysera historik av förseningar och orsaker kan statistiska modeller eller maskininlärning användas för att prototypen ska kunna gissa vad orsaken till en försening är. Den funktionaliteten skulle göra rapporteringsprocessen kortare då användaren endast skulle behöva bekräfta att den gissade orsaken är korrekt istället för att själv rapportera orsaken.
Skulle inte detta krav uppfyllas så är det ett område för vidareutveckling av prototypen.
19 Ytterligare en funktionalitet som ej är av högsta prioritet men som skulle anses vara en förbättring är om demonstration av prototypen kunde ske på verkliga händelser istället för att skapa egna förseningar.
20
5 Systemdesign
I sektion 5.1 presenteras det webramverk som valdes att användas till utvecklingen av prototypen. Sektion 5.2 motiverar det val av rapporteringsformat som gjordes. Vidare i sektion 5.3 presenteras de applikationsprogrammeringsgränssnitt som användes för att hämta realtidsdata om Stockholms pendeltåg. Slutligen i sektion 5.4 presenteras översiktligt den struktur av olika moduler som prototypen byggdes av. Dessa moduler och hur de implementerades behandlas djupare i kapitel 6.
5.1 Phoenix
Ett viktigt krav på prototypen är kommunikation i realtid. Det låg till grund i valet av plattform som prototypen utvecklades på. Plattformen som valdes var webbramverket Phoenix [60]. Phoenix är ett ramverk för att utveckla websidor och applikationer och är byggt på programmeringsspråket Elixir [61]. Denna rapport kommer inte ge en full beskrivning av webbramverket Phoenix, för det hänvisas läsaren till dokumentation för Phoenix [62]. Istället kommer funktionalitet som är relevant för arbetet som beskrivs i rapporten att presenterats.
Phoenix grundar sig i utvecklingsmönstret Model-View-Controller (MVC) [63]. I Phoenix används Controller för att hämta och hantera information innan det skickas vidare till View modulen [64]. En Controller anropas när servern får ett anrop från en klient. Svaret som sedan skickas formateras i View modulen [65].
För att hantera processer finns en funktion som Elixir tillhandahåller kallad Supervisor. En Supervisor är process som har i uppgift att övervaka underliggande processer eller i andra ord barnprocesser och deras tillstånd.
Om en barnprocess skulle få problem kan dess Supervisor starta om barnprocessen i ett stabilt tillstånd. Idén är om en process får ett fel eller inte kan fortsätta exekveras så låter en supervisor processen dö för att sedan starta om den utan att påverka andra processer. Se figur 3 för hur förhållandet mellan Supervisor och barnprocesser kan se ut.
Figur 3. Exempel på Elixir Supervisor. Skapad av författarna.
21 Eftersom att en Supervisor är en vanlig process kan en Supervisor vara en barnprocess till en annan Supervisor. Det betyder att även fast en Supervisor skulle sluta fungera kan den startas om [66].
Phoenix tillhandahåller funktionalitet för att kommunicera mellan klient och server i realtid. Funktionaliten kallas för Channel [67]. En process kan lyssna på en Channel för nya meddelanden eller skicka meddelande till alla som lyssnar på en specifik Channel. Både klienter och processer inom servern kan skicka och lyssna på Channels.
För datalagring har Phoenix inbyggd stöd för databasen PostgreSQL [68].
PostgreSQL är en relationsdatabas som använder standarden Structured Query Language (SQL) som språk för att hämta och modifiera databasen [69]
[70].
5.2 Rapporteringsformat
En rapportering av en händelse kan liknas vid att den berörda lokföraren ska fylla i och skicka iväg ett formulär där orsaken anges. Hur en förseningsorsak anges kan antingen vara i fritext eller genom förutbestämda alternativ. Fritext har fördelen att mer detaljerad information kan skickas men nackdelen blir istället att det blir svårt att kategorisera och undersöka statistik då fritext är ostrukturerad information. Exempelvis kan samma orsak kan beskrivas på flera sätt. En mall med förutbestämda svarsalternativ passar därför bättre för ett rapporteringssystem eftersom att informationen är strukturerad och syftet är att samla stora mängder data för att kunna analyseras.
Alternativet att rapportera förseningsorsaker i fritext utesluts trots fördelen med den detaljerade information som kan samlas in. Nackdelarna med ostrukturerad information är att det försvårar möjligheten att göra analyser och sammanställa statistik på insamlade data då detta skulle behöva göras manuellt av en person. Då återstår alternativet med strukturerad information genom förutbestämda orsaker eller orsakskoder.
Valet blev att använda den standard av orsakskoder som Trafikverket har idag då det ökar möjligheten för flera tågaktörer att kunna implementera ett system baserat på den prototyp som detta projektet tar fram. Då utvecklarna av systemet gör prototypen på uppdrag av WMC och själva saknar kompentens inom tågbranschen fanns inte heller kompentens för att själva sammanställa alla möjliga förseningsorsaker.
5.3 Trafikverkets Öppna API
Två olika API:er fanns som kan tillförse den information som krävs för att kunna utveckla prototypen; Trafikverkets Öppna API och SL Realtidsinformation 4. Till utvecklandet av prototypen valdes Trafikverkets Öppna API av två huvudskäl.
22 Det första var att Trafikverkets Öppna API inte har några begränsningar på antalet anrop som kan göras, varken per minut eller månad vilket SL Realtidsinformation 4 har. Det andra skälet till att Trafikverkets Öppna API valdes framför SL Realtidsinformation 4 är att det kan ge information om alla Sveriges tåg och inte bara de tåg som kör i Stockholm. Detta gör att Trafikverkets Öppna API är kompatibelt för en slutprodukt som kan implementeras på hela Sveriges tågnät.
5.4 Prototypens Struktur
Efter att ramverk och API valts togs en modell fram för hur strukturen på prototypen skulle vara. Då Phoenix har stöd för att köra flera processer parallellt gjordes det så att strukturen för prototypen bestod av flera moduler som har olika uppgifter och syften men kan köra oberoende av varandra.
Programeringsmodellen Message Passing användes för ta fram strukturen för prototypen. Modulerna delades sedan in i tre kategorier för att tydliggöra vilken typ av funktion modulen har. De tre kategorierna var API, Phoenix och Klient. API avser de modulerna som hämtar och processar data från API:et.
Kategorin Phoenix avser moduler som Controller, databas och Report Handler. Klienten består av en modul, användare, som bygger upp användargränssnittet. Se figur 4 för prototypens struktur.
Figur 4. Struktur över prototypen. Skapad av författarna.
Prototypens API-moduler består av en modul vars funktionalitet är att hämta tidsplaner för alla aktiva pendeltåg. Den andra modulen som hämtar data från API:et är en modul ”Hämta händelse” som hämtar data om var pendeltågen befinner sig i realtid. Dessa moduler skickar sedan informationen vidare till databasen. Modulen ”Hämta händelse” kommunicerar sedan med Phoenix- modulen Report handeler som avgör om en försening uppstått och dess omfattning.
23 Report handler är modulen som upptäcker förseningar. Report handler meddelar användaren om att tåget är försenat och uppmanar användaren att rapportera anledning till förseningen. Användaren är en lokförare för ett tåg.
Användaren rapporterar in förseningen och rapporten lagras i databasen.
Modulen controller är controller-modulen i MVC-modellen. Controllerns syfte är att hämta data om tåg från databasen och sedan skicka den vidare till användarmodulen för att kunna presenteras. Användarmodulen är view- modulen i MVC-modellen. Modulen får data från Controller och Report handler som den sedan presenterar i ett webbgränssnitt. När användaren har rapporterat en förseningsorsak skickar denna modul tillbaka resultatet till Controller som sedan lagrar informationen i databasen.
24
6 Utveckling av prototyp
Efter att teknikval gjorts och strukturen på prototypen bestämts påbörjades implementationen av prototypen. I detta kapitel kommer implementationen av prototypen att beskrivas. I sektion 6.1 beskrivs hur och vilka API-anrop som gjorts för att hämta önskade data. Sektion 6.2 beskriver hur förseningar rapporteras och hur följdförseningar grupperas ihop med varandra. I sektion 6.3 beskrivs användargränssnittet och vilka sidor som utvecklats samt deras olika funktionaliteter. Slutligen i sektion 6.4 beskrivs hur databasen är strukturerad.
6.1 Hämta realtidsdata
Trafikverkets Öppna API används för fyra olika funktioner i den utvecklade prototypen. Varje funktion består av ett API-anrop med en egen struktur. Den första funktionaliteten som krävdes för att kunna utveckla prototypen var att hämta tidtabeller för alla pendeltåg i realtid. För det utformades ett anpassat API-anrop som körs regelbundet, se figur 5.
Figur 5. API-anrop som hämtar tidtabeller för samtliga pendeltåg. Skapad av författarna.
Anropet specificerar en förfrågan (eng. query) med objekttypen till tågmeddelanden (eng. train announcement) och sorterar dessa efter när de ändrats sist. En filtrering görs på tåg-identiteter (i figur 5 AdvertisedTrainIdent) där en lista med alla tåg-identiteter för pendeltågen skickas som argument samt tidtabeller som redan hämtats. I frågan används
<INCLUDE> för att specificera vad svarsmeddelandet ska innehålla. För att sammanställa en tidsplan krävs för varje post att man vet vilket tåg det är
25 (tåg-id), om aktiviteten är en avgång eller ankomst, vilken station det handlar om samt vilken tid och vilket datum som aktiviteten är planerad.
För att sedan kunna identifiera huruvida ett tåg är försenat eller inte används ett annat anrop. För att kunna göra detta måste information i realtid om när tåget varit på en station hämtas. Detta kan sedan jämföras med tidsplanen och finns en avvikelse är tåget antingen före eller efter tidsplanen. Figur 6 visar strukturen på det anrop som används för att kontrollera om ett tåg passerat en station eller ej.
Figur 6. API-anrop som om ett tåg passerat en station. Skapad av författarna.
API-anropet som visas i figur 6 är nästintill identiskt med strukturen för att hämta tidsplanen med skillnaden att en post till inkluderas, TimeAtLocation.
TimeAtLocation specificerar huruvida tåget har ankommit eller avgått från den aktuella stationen och om den har också vilken tid detta skett. Dessa två funktionaliteter är tillräckligt för att kunna identifiera var och när en försening uppkommer och därmed uppfylla flera krav från kravspecifikationen. Men för att kunna uppnå kravet om simulering av prototypen implementeras ytterligare två funktionaliteter med hjälp av API- anrop.
Det ena anropet utformas för att kunna identifiera vilka tåg som är aktiva just nu för att kunna följa dem och underlätta demonstration av prototypen.
Anropet som används för detta visas i figur 7 och skiljer sig från föregående på flera sätt. En <DISTINCT> har infogats för att ej hämta flera poster för samma tåg (AdvertisedTrainIdent). Sedan har även filtrering gjorts först på att bara hämta pendeltåg. Slutligen görs en filtrering på ”planerad tid på stationen”
26 (AdvertisedTimeAtLocation). Denna filtrering görs med <GT> och <LT> som betyder ”större än” (eng. greater than) och ”mindre än” (eng. less than>. På så sätt kan alla tåg som varit eller ska vara aktiva inom en viss tidsperiod hämtas.
Figur 7. API-anrop som hämtar alla aktiva tåg. Skapad av författarna.
Det sista anropet görs en gång när servern startar för att hämta alla stationsnamn. Detta görs för att i användargränssnittet kunna skriva ut hela stationsnamn och inte bara de stationskoder som Trafikverkets Öppna API annars använder sig av. Figur 8 visar strukturen på det anrop som används för att hämta alla stationsnamn.
Figur 8. API-anrop som hämtar alla stationsnamn tillsammans med deras stationskoder. Skapad av författarna.
6.2 Försening och Rapportering
Ett försenat tåg definierades som ett tåg som är minst 3 min efter tidtabell.
När en ny försening upptäcks skapas en rapport om förseningen. Om förseningen är en följdförsening till en tidigare händelse kopplas förseningen automatisk till rapporten för den tidigare händelsen och ingen ny rapport
27 skapas. När en ny rapport skapas meddelas det berörda tåget och får möjlighet att rapportera orsak till händelsen.
För ett redan försenat tåg skapas en ny rapport om tåget blivit mer än 3 min försenat från den tidigare stationen. Alltså som tåget är 25 min försenad vid station A och vid nästa station B försenat 30 min misstänks en ny försening.
Tåget meddelas och får frågan om en ny försening har uppstått. Om det har skett en ny försening skapas en ny rapport. Om det inte skett en ny försening kopplas händelsen till den tidigare rapporten. Se figur 9 för hur händelser grupperas.
Figur 9. Exempel bild över hur händelser kan uppkomma för ett tåg. Skapad av författarna.
Det kan uppstå situationer där ett tåg kan bli försenat ytterligare efter en tidigare försening. Figur 9 visar hur en försening på en station grupperas ihop med alla efterkommande stationer så länge den totala förseningen ej blir större. Sker en ny ökning av förseningsminuter antas det att en ny försening har uppstått och kan då rapporteras. Tills att ingen försening längre finns räknas både orsak ett och orsak två som orsak till förseningen som har uppstått och kan då rapporteras. Tills att ingen försening längre finns räknas både orsak ett och orsak två som orsak till följdförseningarna till.
6.3 Användargränssnitt
Efter att valet av ramverket Phoenix gjorts bestämdes att prototypen skulle utvecklas i form av en webbapplikation. Detta beslutades då Phoenix är ett webbapplikationsramverk och har inbyggt stöd för webbapplikationer. En annan fördel med en webbapplikation gentemot en mobilapplikation är att en webbapplikation kan demonstreras på en stor variation av enheter såsom datorer, surfplattor och mobiltelefoner.
Då prototypen ska kunna möjliggöra orsaksrapportering för alla pendeltåg samt endast notifiera den berörda lokföraren måste varje tåg kunna komma åt en individuell sida. Detta löstes genom att implementera en startsida med inloggningsmöjligheter. Då endast en prototyp utvecklas gjordes en avgränsning att ej prioritera säkerhet med lösenordskyddade inloggningar.
Istället utvecklades inloggningssidan så att tåg-ID och datum anges för att kunna komma vidare till en unik rapporteringssida för det tåget. För att lättare kunna se vilka tåg som är aktiva för tillfället visas på startsidan också en lista med alla nu aktiva tåg, se figur 10.
28
Figur 10. Struktur på inloggningssidan. Skapad av författarna.
Rutan med alla aktiva tåg visas som en lista med knappar som länkar till motsvarande tågs rapporteringssida med dagens datum som förutbestämt datum. Denna funktionalitet gör de enkelt att i realtid följa tåg och se när förseningar uppstår. Om användaren istället vill se ett tåg som ej är aktivt, exempelvis från en annan dag kan tåg-ID och datum väljas manuellt. När användaren loggar in eller klickar på ett aktuellt tåg skickas användaren vidare till den individuella rapporteringssidan för det valda tåget, se figur 11.
Figur 11. Struktur för användarsidan. Skapad av författarna.
Rapporteringssidans huvudfunktionalitet är att kunna notifieras vid en uppstådd försening samt kunna rapportera förseningsorsaker. Detta åstadkoms genom att vid en uppstådd försening så dyker en ruta upp i form av ett förseningsmeddelade. Förseningsmeddelandet innehåller vilken station förseningen uppstått på, hur många minuter förseningen är samt en ruta där användaren kan välja orsak till förseningen och därefter skicka iväg rapporten. För att ge en bättre överblick över tågets sträcka och aktuella position finns på rapporteringssidan också en tidslinje som visar varje station på tågets linje samt färgkodar med rött och grönt om tåget varit i tid eller inte.
29 Tågets tidsplan finns också för att visa vilka tider som tåget förväntas vara på olika stationer.
I kravspecifikationen finns även ett krav att kunna visa statistik över förseningshistorik. För att uppnå detta krav utvecklades ytterligare en sida med syfte att presentera just statistik, se figur 12.
Figur 12. Struktur på statistiksida. Skapad av författarna.
Exakt vilken statistik som ska kunna visas har inte specificerats av uppdragsgivaren, utan endast att någon sammanställning av olika orsaker kan visas. Därför gjordes två spalter av data där den ena visar statistik den senaste dagen och den andra visar statistik på all insamlade data. Statistiken som presenteras kan delas in i två kategorier, förseningsstatistik och orsaksstatistik. Förseningsstatistiken kan idag hittas på andra sidor såsom Tåg.Info [55] medan orsaksstatistiken är unik för denna prototyp och av större vikt. Orsaksstatistiken som prototypen kan presentera är vanligaste orsak till försening i pendeltågstrafiken, vanligaste orsaken till förseningar per station samt vanligaste orsaken till försening per enskilt tåg.
6.4 Datalagring
Från kravspecifikationen identifierades informationen som behövdes lagras i databasen. Informationen som identifierades var tidsplan för varje tåg, ankommen tid till stationer, avgången tid från stationer, förseningar och orsaker till förseningar. Entity–relationship-diagram (ER-diagram) användes för att modellera informationen och relationer inom informationen. Se figur 13 för ER-diagram över databasen.
30
Figur 13. ER-diagram över databasstrukturen. Skapad av författarna.
Tåg och stationer modellerades som egna entitetstyper. Entitetstypen Tåg har ett unikt tåg-id (train ID) som attribut som även är nyckel till relationen.
Entitetstypen Station har attributen stationskod och stationsnamn där stationskod är nyckel till relationen. Entitetstyperna tåg och station ligger till grund till Tidsplan, Händelse och Försening som är svaga entitetstyper.
Tåg-id och stationskod är samma som används i trafikverkets egna gränssnitt [71]. Tåg-id är ett unikt id som endast används en gång per dag men kan återanvändas under andra dagar. Ett tåg-id är inte ett id för ett specifikt fysiskt tåg utan refererar till en tågsträcka som har en start- och slutstation med mellanstationer mellan. Därför modellerades tidsplanen som en svag entitetstyp Tidplan till entitetstyperna Tåg och Station med attributen datum, avgång/ankomst och planerad tid.
