Övervakningssystem för tåg
Insamling och presentation av data via ett grafiskt gränssnitt
Monitoring system for trains
Gathering and presentation of data via a graphical interface
Karl Hansson Ivan Toma
Fakulteten för hälsa, natur- och teknikvetenskap Datavetenskap
C-uppsats 15 hp
Handledare: Lothar Fritsch
Examinerande lärare: Johan Eklund Datum: 2019-01-16
iii
Sammanfattning
I dagsläget finns en del problem vid beslutsprocesser som trafikledningen inom tågtrafiken dagligen får handskas med. Dessa beslutsprocesser kan effektiviseras genom ett förbättrat stöd och underlag och tanken med projektet var att skapa detta stöd.
Detta projekt har resulterat i ett enkelt system som samlar in och presenterar data över tåg i ett grafiskt gränssnitt i form av en karta. Systemet är utvecklat för att enkelt kunna få fler funktioner applicerade i framtiden och var från början tänkt att bestå av högre utbud funktioner än vad det har i dagsläget. Projektet har tagit form med hjälp av tågbolaget SJ med information om de hinder de stöter på, och riktlinjer satta från vår handledare under projektet.
Vi kommer i denna rapporten att beskriva mer detaljerat hur projektet tagit form, vilka problem vi fått handskas med och hur systemet är utvecklat.
iv
v
Abstract
Currently there exists several problems with the decision-making processes that the traffic management within train traffic daily must put up with. The decision processes can be made more efficient by having a good support and structure, and the goal of this project was to create this support.
This project has resulted in a simple system that collects and presents train data on a graphical interface in the form of a map. The system is designed to be expandable with new features and functionalities with relative ease and was initially supposed to include some of these extra features. The project has taken shape with help from the train company SJ with information about problems they’ve encountered, and guidelines set by our supervisor during the project
In this report we will describe how the project has taken shape, what problems we have dealt with and how the system is developed.
vi
vii
Tack
Vi vill tacka alla inblandade på Softcode som bidragit med stöd, expertis och även en mycket trevlig arbetsplats. Vi vill även tacka Anders Åslund som genom Softcode har bidragit med råd på vägen. Ett tack vill vi även ge till Christoffer Andersson som tog emot oss på SJ och visade oss runt.
Vi vill även tacka vår handledare Lothar Fritsch för rådgivning, och Katarina Asplund för tiden hon tog för att bidra med extra stöd.
viii
ix
Innehållsförteckning
1 Inledning ... 1
1.1 Syfte ... 1
1.2 Mål ... 2
1.3 Uppdragsbeskrivning ... 2
1.4 Disposition ... 4
Kapitel 2 – Bakgrund ... 4
Kapitel 3 – Projektdesign ... 4
Kapitel 4 – Implementation ... 4
Kapitel 5 – Utvärdering ... 4
Kapitel 6 – Slutsats ... 4
2 Bakgrund ... 5
2.1 Språk ... 5
SQL ... 5
C ... 5
C++ ... 5
Java ... 6
C# ... 6
PHP ... 6
HTML ... 7
JavaScript ... 7
2.2 Verktyg ... 8
Microsoft Azure ... 8
Apache Kafka ... 8
Kubernetes ... 9
Docker ... 10
Git ... 10
MySQL Workbench ... 11
Open Street Map ... 11
Mapbox ... 11
Leaflet ... 11
Google Maps ... 12
Pubnub ... 12
XAMPP ... 13
NMEA GPRMC ... 13
AJAX ... 14
JSON ... 15
2.3 Reguljära uttryck ... 17
2.4 Existerande lösningar ... 17
Utplacerade avläsningspunkter ... 18
Kommunikation via ombord personalens mobiler ... 19
GPS-enheter på tåg ... 19
3 Projektdesign ... 20
3.1 Projektets grundidé ... 20
3.2 Planering ... 20
Möten med olika trafikledningar ... 20
Möten med handledare ... 21
x
Vägledning på Softcode ... 22
3.3 Motivering och mål kring projektändringarna ... 22
3.4 Användarfall ... 23
3.5 Generell design ... 23
Databas ... 24
Dataomvandlare ... 25
Grafiskt gränssnitt ... 25
3.6 Val av språk ... 25
3.7 Testning och validering av verktyg ... 25
3.8 Design av databasen ... 26
3.9 Design av dataomvandlarna ... 27
3.10 Design av det grafiska gränssnittet ... 28
4 Implementation ... 29
4.1 Introduktion ... 29
Mjukvara och programspråk som använts under implementationen ... 29
4.2 Lokalisering av tågstationer och mötespunkter på järnvägen ... 30
Inhämtning av data och felhantering ... 30
Formatering av inhämtade data ... 32
Stationstabellens SQL-struktur och inmatning av data ... 33
4.3 Lokalisering av aktiva och inaktiva fordon ... 33
Inhämtning av data och felhantering ... 33
Formatering av inhämtade data ... 35
Tågtabellens SQL-struktur och inmatning av data ... 37
4.4 Databas och versionshantering ... 38
Utvecklingsmiljö ... 38
Produktionsmiljö ... 38
4.5 Visualisering av data ... 39
5 Utvärdering ... 43
5.1 Resultat ... 43
5.2 Problem ... 44
GDPR-skyddade data och tillgång till API:er ... 44
API:er som inte ville fungera ... 45
6 Slutsats ... 48
6.1 Helhetsbild av projektet ... 48
6.2 Vidareutveckling av systemet ... 48
Referenser ... 50
Informationskällor ... 50
Bildkällor ... 53
A Bilagor ... 54
A.1 Stationsdataomvandlaren ... 54
xi
A.2 Tågdataomvandlaren ... 59
A.3 Webbgränsnittet ... 65
A.3.1 Index ... 65
A.3.2 Trains ... 72
A.3.3 Stations ... 73
xii
Figurförteckning
Figur 1.1 Översikt av projektet ... 3
Figur 2.1 SQL-exempel ... 5
Figur 2.2 Exempel på PHP och HTML ... 7
Figur 2.3 JSON-objekt ... 15
Figur 2.4 JSON-array ... 16
Figur 2.5 JSON-värde ... 16
Figur 2.6 JSON-sträng ... 16
Figur 2.7 JSON-nummer ... 17
Figur 2.8 RFID-tekniken ... 18
Figur 3.1 Visualisering av systemet ... 22
Figur 3.2 Generell design av systemet ... 24
Figur 3.3 Databasens tabeller ... 27
Figur 3.4 Första gränssnittsdesignen ... 28
Figur 4.1 Frågan som skickas till Trafikverkets API ... 31
Figur 4.2 Utdrag ur svaret Trafikverkets API ... 31
Figur 4.3 Reguljärt uttryck för tolkning av Trafikverkets JSON-data ... 32
Figur 4.4 Utdrag ur stationstabellen ... 33
Figur 4.5 Exempel på inhämtad data från Oxyfi ... 34
Figur 4.6 Reguljärt uttryck för tolkning av Oxyfi:s data ... 34
Figur 4.7 Utdrag ur det reguljära uttrycket för tolkning av Oxyfi:s data ... 36
Figur 4.8 Utdrag ur tågtabellen ... 38
Figur 4.9 Utdrag ur JSON-strängen som kartan hämtar för att rita ut tågen ... 39
Figur 4.10 Utdrag ur JSON-strängen som kartan hämtar för att se tåg vid trafikplatser .. 39
Figur 4.11 Sveriges alla trafikplatser ... 40
Figur 4.12 Värmlands (med omnejd) alla trafikplatser ... 41
Figur 5.1 Översikt över de aktiva tågen i Värmland ... 43
xiii
Tabellförteckning
Tabell 2.1 NMEA GPRMC ... 14
1
1 Inledning
I en allt mer digitaliserad värld förväntar sig konsumenter som leverantörer större, bättre och smidigare systemlösningar. Någonting som dock inte hängt med ordentligt är Sveriges järnvägar och kringliggande system. I dagsläget finns inte en komplett vy över var Sveriges alla järnvägsoperatörer har sina fordon, både parkerade och resande, samt annan nyttig information som kringliggande terräng. Detta projekt syftade till att bygga upp ett grundläggande system som knyter ihop relevant (och tillgänglig) data för att sedan kunna användas till en lämplig systemlösning, för att i sin tur kunna användas för att övertyga operatörer att se fördelarna och användbarheten med ett sådant system.
1.1 Syfte
SJ, som idag är en marknadsledande tågoperatör, knyter samman Sverige och likaså Skandinaviens huvudstäder Stockholm, Köpenhamn och Oslo. [1] Detta skapar idag möjligheter för människor att kunna bo, arbeta och studera på platser och även kunna resa på ett enkelt sätt. Med 1200 dagliga avgångar, 284 trafikerade stationer, cirka 4500 anställda och en summa på ca 47,5 miljoner resenärer varje år, placeras en stor vikt på säkerhet och framkomligheten för att resenärerna ska känna trygghet i att välja SJ som tågoperatör.
För att kunna garantera denna trygghet behöver trafikledningen på SJ diverse stöd för att försäkra sig om att de hela tiden värnar om säkerheten för resenärer och även personal som finns på tågen och även att framkomligheten är god så att resenärerna kommer fram enkelt och i tid. Ett exempel på detta är att ha god vetskap om terrängen runt om ett tåg för att vid evakuering kunna flytta resenärer och personal från ett tåg, på ett säkert och smidigt sätt. Ett annat exempel är att kunna se när ett tåg står stilla på ett spår där det inte borde. I nuläget så tar den beslutprocess och det arbetet för att lösa uppkomna problem inom de två exempel som precis har givits, betydligt längre tid än vad som önskas. Det krävs att man letar inom flera olika system och även förlitar sig på kommunikation mellan personalen på tåget och trafikledningen.
Inom vissa områden har man till och med inget underlag alls för att tackla problemen.
2
Att inte ha all data samlat på ett ställe och samtidigt inte ha en översikt över tågen i realtid är det som tar tid och markant påverkar beslutsprocesserna. Syftet med detta projekt var att underlätta och effektivisera dessa beslutsprocesser genom att skapa ett underlag i form av ett system som kan knyta ihop den utspridda datan och ge en visuell överblick över tågens position.
Systemet kommer att fungera som ett demo för framtida implementationer.
1.2 Mål
Målet med detta projektet var att skapa ett system som kan fungera som underlag och upplysa om de behov och möjligheter som finns för att utforma ett liknande system storskaligt. Tanken var att samla in data i en databas, anpassat för att kunna användas till att bygga flertalet lager med funktionalitet på en karta som kan användas till att underlätta beslutskrävande processer.
1.3 Uppdragsbeskrivning
Arbetet var tänkt att agera som underlag för framtida implementationer av ett liknande system.
Systemet skulle kunna använda sig av den insamlade datan för att presentera detta i ett grafiskt gränssnitt. Datainsamling skulle ske från ett antal olika API:er. Datan som hämtas kunde innehålla sådant som anses vara onödigt och även data som är trasigt. På lämpligt sätt skulle den data som är nödvändig för det uttänkta systemet filtreras från resterande data och sedan läggas in i en databas. Därefter skulle funktionalitet byggas för att kunna presentera ett antal användarfall i ett grafiskt gränssnitt.
Figur 1.1 visar ett exempel på hur detta systemet var tänkt att se ut och användas. Användaren var i detta fall tänkt att vara en trafiksamordnare eller annan ledningspersonal på trafikverket.
Data samlas in från ett antal API:er in i en omvandlare. Omvandlaren filtrerar och gör om datan så den är i rätt format, och därefter lägger in datan i en databas. Från databasen hämtas data ut till ett antal användarfall. Dessa användarfall skulle fungera som tilläggsprogram till ett grafiskt gränssnitt, i detta fall fungera som lager på en karta med olika funktionaliteter.
3
För att ha förståelse för vilka användarfall som var av nytta och även vilken data som var av värde att samla in så skulle följande göras:
• Möten med SJ och trafikledningen för att samla information över de beslutsprocesser och problem som påverkar arbetet negativt.
• Studera befintliga lösningar som används för att underlätta dessa beslutsprocesser.
Utöver detta utvärderades och testas flera verktyg och tekniker som kunde användas vid implementationen av systemet.
Figur 1.1 Översikt av projektet
4
1.4 Disposition
Kapitel 2 – Bakgrund
Kapitel 2 avser att introducera olika programmeringsspråk och verktyg som kommer att nämnas i andra kapitel. De existerande lösningar som finns hos trafikledningen idag presenteras också.
Kapitel 3 – Projektdesign
I kapitel 3 ges en tydligare introduktion till projektet, hur projektet utformats och även de mål som sattes för projektet. Här presenteras även test och utvärdering av olika verktyg och språk för att ge en klar bild av varför projektet tog den form det gjorde.
Kapitel 4 – Implementation
Kapitel 4 presenterar systemet och dess komponenter. Här presenteras både systemets inhämtning av data, filtrering av onödiga och nödvändiga data och det grafiska användar- gränssnittet i detalj.
Kapitel 5 – Utvärdering
I kapitel 5 utvärderas projektet och systemet analyseras. Utvärderingen ska styrka de mål som satts för projektet och ett helhetsresultat ges. I kapitlet presenteras även de problem och hinder som uppstod under projektets gång och som påverkat slutprodukten.
Kapitel 6 – Slutsats
Kapitel 6 knyter samman projektet och ger en summering av hur arbetet har gått. Vidare ges även förslag på hur systemet kan vidareutvecklas.
5
2 Bakgrund
Syftet med detta kapitel är att ge en kort introduktion till de olika språk som under projektets gång har använts eller övervägts att användas. Vidare presenteras de verktyg som testades och även en kort presentation av de lösningar som trafikledningen använder sig av idag. Även reguljära uttryck presenteras kort, då det kan vara av användning för att förstå delar av implementationen. I kapitel 3.6 står det om vilka av språken som valdes för projektet och i kapitel 3.7 så står det om vilka verktygen som valdes.
2.1 Språk
SQL
SQL är ett programspråk som används för att hantera data i relationsdatabaser, och började utvecklades av IBM på 1970-talet [2]. Exempel på SQL-kommando (Figur 2.1):
Hämta ut värdena namn och nummer från tabellen Kontakter där värdet favoriter är lika med ja, sorterat efter värdet namn i bokstavsordning.
C
C är ett ALGOL-baserat (ALGOL, programspråk från 1958) imperativt programspråk [3].
Programspråket B, som C är baserat på, var inte plattformsoberoende, utan skrevs på PDP-7, och hade endast en datatyp (word). C skapades därefter med kravet på att kunna fungera på mainframe-, mini- och mikrodatorer. C släpptes för första gången 1970 och var skrivet i assembler. C är idag ett av de mest populära programspråken och näst intill varje plattform har C-kompilatorer.
C++
C++ är ett programspråk som stödjer objektorienterad programmering, generisk programmering, dataabstraktion samt lågnivå hårdvarunära programmering [4]. Språket är
Figur 2.1 SQL-exempel
6
baserat på C, och omfattar stora delar av språket, men har också många semantiska skillnader.
C++ används mer och mer idag på områden där C traditionellt använts. C++ är idag, likt C, ett av de mest populära språken och hittas ofta i produkter som datorspel, konsumentelektronik och allt däremellan.
Java
Java är ett objektorienterat programspråk [5]. Språket skapades som ett alternativ till C och C++, och dess syntax kommer därifrån. Javakod kompileras till Java-bytekod som senare kan exekveras på alla enheter som stödjer Java, då bytekoden körs på virtuella Java-maskiner. Java är, likt de två föregående språken, även det ett av de mest använda språken på marknaden.
C#
C# är ett objektorienterat programspråk [6]. Språket är i grunden baserat på C++, men har stora liknelser med Java. C# är dock inte plattformsoberoende, då fria implementationer av språket är ofullständiga och saknar vissa komponenter ur .NET-ramverket som C# är en del av. C#
använder, likt Java, bytekod som körs i en virtuell maskin. De olika bytekoderna är dock inte kompatibla med varandra.
PHP
PHP är en förkortning för ”PHP: Hypertext Preprocessor” och är ett öppet generellt skriptspråk som huvudsakligen är lämpat för webbutveckling och kan mycket smidigt integreras med HTML [7]. PHP är väldigt enkelt för nybörjare samtidigt som det erbjuder avancerade funktioner för utvecklare med mer erfarenhet. Fördelarna med PHP är att istället för att ha flera rader med HTML kommandon så kan de ersättas med PHP. I Figur 2.2 ges exempel av kod skriven i PHP. Koden är omsluten av instruktioner som avser start och slut av PHP. ’<?php’
anger starten av PHP-blocket och ’?>’ slutet. I exemplet så kommer ”Exempel på PHP” att skrivas ut på skärmen.
7 HTML
HTML står för ”Hypertext Markup Language” och är ett sidbeskrivningsspråk för att skapa webbsidor och webbapplikationer [8]. Ett sidbeskrivningsspråk är ett slags format för dokument. Webbläsare får dessa HTML-dokument från en webbserver eller en lokal lagring.
Dessa dokument översätts till multimediasidor.
Grunden och byggstenarna i HTML-sidor är HTML-element. Dessa element är representerade av taggar. Varje tagg beskriver olika delar av innehållet på en webbsida som tillexempel
”Header”, ”Paragraph” och ”Table”. Webbläsarna visar i sin tur inte dessa taggar utan använder de för att rendera innehållet av webbsidorna. Taggarna är element som är omslutna av vinkelparenteser och kommer i par med en start och en sluttagg.
JavaScript
JavaScript är ett skriptspråk som gör det möjligt att implementera mer komplexa funktioner på en webbsida än HTML [9]. Med JavaScript kan man dynamiskt uppdatera innehållet på en webbsida, kontrollera media, animera bilder, kontrollera fält innan data skickas vidare och en mängd andra funktioner. Utöver detta så används JavaScript även i andra användningsområden som till exempel: Tillämpningar på serversidan för att arbeta med olika databasanslutningar, skicka data över nätet och liknande tillämpningar.
Figur 2.2 Exempel på PHP och HTML
8
2.2 Verktyg
Microsoft Azure
Microsoft Azure är en uppsättning med molntjänster från Microsoft skapta för att bygga och hosta webbapplikationer [10]. Dessa görs via Microsofts egna datacenter. Bland dessa molntjänster finns ”Azure SQL Database” som är en relationsdatabastjänst. ”Azure SQL Database” har stöd för strukturer som JSON och XML och ska enligt Microsoft vara högpresterande, tillförlitlig och en mycket säker databas [11]. Microsoft Azure utlovar även en tillgänglighet på 99,99%. Tillgängligheten är väldigt viktig när man bygger ett realtidssystem då man inte vill att det sker någon förlust av data. Bland alla funktioner finns alternativ som kolumnlagringsindex för en enklare och effektiv analytisk analys, minnesintern OLTP för bättre transaktionell bearbetning och elastiska pooler för att lösa problem som kan uppkomma för företag med oförutsägbara användningsmönster. En elastisk pool innebär att prestandaresurser allokeras till en enda pool istället för en databas. Detta gör att användarna inte behöver reglera databasprestanda upp och ner efter behov.
Apache Kafka
Apache Kafka är en open-source-strömningsplattform [12]. Kafka är vanligtvis användbart inom två väldigt breda användningsområden. Det ena är utveckling av datapipelines i realtid som på ett säkert sätt hanterar och får data mellan olika system eller applikationer. Det andra är utveckling av realtidsströmmande applikationer som omvandlar eller reagerar på olika dataflöden.
För att förstå Kafka så behöver man ha vetskapen om att:
• Kafka körs på en eller flera servrar, som ett kluster, och kan ha ett span över multipla datahallar.
• Kafka klustret lagrar flöden av poster i olika ämnen / kategorier.
• Varje post har en nyckel, ett värde och en angiven tidpunkt.
Därefter är det även viktigt att veta att Kafka består av fyra API:er:
• Producer API som tillåter en applikation att publicera en ström av olika register till en eller flera antal Kafka kategorier,
• Consumer API som tillåter en applikation att prenumerera på en eller flera antal ämnen och därefter bearbeta strömmen av poster som applikationen mottager.
9
• Streams API som tillåter en applikation att fungera likt en strömprocessor och omvandlar en ingångström av poster från en eller flera ämnen till en utgångström för en eller flera utgångsämnen.
• Connector API som gör det möjligt att bygga och köra återanvändbara producenter eller prenumeranter som ansluter en eller flera Kafka ämnen till befintliga applikationer.
I kärnan av Kafka finns ämnen. Ett ämne är en kategori som poster publiceras till [13]. Ett ämne kan ha inga, en eller flera prenumeranter på den data som skrivs till ämnet. Varje ämne blir tilldelat en partitionerad logg. De partitionerade loggarna distribueras över Kafka-klustrets olika servrar, där varje server hanterar data och förfrågningar för att läsa från loggarna. Sedan kopieras partionerna till ett antal konfigurerbara servrar för felhantering.
Varje partion har en server som agerar som huvudserver och därefter noll, en eller flera servrar som kan tänkas agera som ”följare”. Huvudservern hanterar partionernas alla läs och skrivförfrågningar medan ”följarna” har i uppgift att hela tiden replikera huvudservern. Skulle huvudservern misslyckas så kommer en av följarna att bli den nya huvudservern. Belastningen är välbalanserad inom klustret just för att varje server fungerar som en huvudserver för några av dess partitioner samtidigt som den är en ”följare” för andra servrar.
Kubernetes
Kubernetes är en portabel open-source-plattform som är till för hantering av tjänster och arbetsbelastningar i containrar [14]. Kubernetes kan kortfattat ses som en mikroservice- plattform eller en container-plattform och den tillhandahåller en container-centrerad förvaltningsmiljö där den anpassar data, nätverk och lagring baserat på användarens arbetsbelastningar. Målet med Kubernetes är att automatisera skalning, implementering, drift och resurstilldelning av containrar över kluster. Kubernetes används främst tillsammans med Docker (se delkapitel 2.2.4 för beskrivning av Docker).
Kubernetes centrala schemaläggningsenhet kallas för pod [15]. En pod består av en eller flera containrar som kan dela resurser. Varje pod har en unik IP-adress inom klustret för att göra det möjligt för applikationer att använda portar utan risk för att problem ska uppstå. Inom en pod kan alla olika containrar referera till varandra på localhost men ingen av dessa containrar kan direkt referera till en container inom en annan pod. Detta görs istället genom IP-adressen alla podar blivit tilldelade.
10 Docker
Det Docker gör är att sätta upp containrar [16]. Detta görs baserat på virtualisering på operativsystemnivå snarare än på hårdvarunivå. Detta innebär att containrarna är isolerade ifrån varandra. De har sina egna filsystem och deras användning av datorresurser kan begränsas.
Samtidigt som de är enklare att sätta upp än virtuella maskiner så är de även bärbara över molnet och operativsystemsfördelningar, då de inte är kopplade till det underliggande filsystemet och infrastrukturen. Containrar gör det möjligt för en utvecklare att packa ner en applikation tillsammans med alla de delar som den behöver [17]. Exempelvis så kan de bibliotek och inställningar applikationen behöver, skickas med i en container. Detta gör att det går att leverera allting som ett enda paket och försäkra sig om att applikationen kan köras på vilken annan maskin som helst oavsett den nya maskinens inställningar.
Git
Git är ett versionshanteringssystem som är utformat för att hantera allt från små till stora projekt [18]. Versionshantering har en rad med fördelar. En av de största fördelarna är att alla ändringar av en kod lagras i en databas och hålls koll på. Detta gör det möjligt för utvecklare att jämföra olika versioner med varandra och vid fel kunna gå tillbaka till en tidigare version av koden.
Det som även möjliggörs är att utvecklarna kan arbeta på samma kod utan att påverka varandra [19]. För att ge en enkel överblick kan Git beskrivas med följande: En utvecklare skriver kod, en annan ändrar på kod och den tredje tar bort kod och detta kan de göra samtidigt utan att påverka varandra genom att befinna sig på olika brancher. En branch är en kopia av koden där den enskilde utvecklaren kan arbeta med koden och därefter göra en merge, det vill säga, slå ihop sina ändringar med huvudkoden och samtidigt kontrollera att inga konflikter uppstår med ändringarna.
Ett annat exempel är att en utvecklare skapar en branch från version 1.5 av exempelprogrammet
”X” [20]. Syftet här är att förbereda publiceringen av version 1.6. Utvecklaren gör sina ändringar och bestämmer sig för att göra en commit på dessa ändringar. En commit innebär att ändringarna sparas till repositoryt och ett repository är ett förråd som lagrar metadata för bland annat ändringar i koden. Utvecklaren bestämmer sig sedan för att hoppa till branchen för version 1.3 av ”exempelprogrammet ”X. Här skapas en branch för att hantera en bugg som bara
11
påverkar version 1.3 av programmet. Buggen löses och branchen mergas tillbaka in i branchen för version 1.3, detta utan att påverka ändringarna som skett i branchen för version 1.6.
MySQL Workbench
MySQL Workbench är ett verktyg som visuellt tillhandahåller datamodellering, SQL- utveckling och annan databashantering [21]. MySQL Workbench underlättar databashantering markant genom att möjliggöra hantering, generering modellering och design av databaser visuellt. Här finns det även möjlighet för att kunna skapa, exekvera och optimera SQL- kommandon samtidigt som färgmarkering av syntax, automatiskt slutförande, kortkommandon och historik över tidigare SQL-kommandon förenklar arbetet med databaserna. Här kan utvecklaren även visuellt strukturera sina databaser, sätta upp nya tabeller, redigera kolumner och primärnycklar.
Open Street Map
Open Street Map är ett projekt framtaget och byggt av kartografer för att distribuera geografiska data gratis [22]. Denna data kan i sin tur sedan användas för att skapa allt från vägkartor till kartor för att presentera GPS-data till kartor över sevärdheter och en mängd andra användningsområden. Open Street Maps data uppdateras och underhålls tack vare kartografer men även bidragsgivare så som GIS-proffs, ingenjörer och frivilliga med hjälp av flygbilder, GPS-enheter och lågteknologiska fältkartor.
Mapbox
Maxbox är en stor och växande leverantör av anpassningsbara kartor online för webbsidor och mobilapplikationer [23]. Bland dessa finns giganter som Facebook och Snapchat. Mapbox startades upp 2010 som en del av projektet Development Seed, där målet var att kunna erbjuda anpassningsbara kartor till ej vinstgivande kunder. Mapbox använder sig av data hämtat från en rad öppna datakällor, bland dessa finns Open Street Map. Det Mapbox också gör är att använda data som kommer från användare på applikationer som använder sig av Mapbox för att med hjälp av automatiserade funktioner upptäcka data som troligtvis saknas i Open Street Map.
Därefter rapporterar Mapbox-utvecklarna in detta till underhållarna av Open Street Map eller själva hjälper till med att gå in och fixa problemen.
Leaflet
Leaflet är ett stort öppet JavaScript-bibliotek som används för att bygga applikationer för webbkartläggning [24]. Leaflet stödjer de flesta mobilapplikationer och datorprogram med
12
HTML5 och CSS (se kapitel 4.1.1 för beskrivning av CSS). Leaflet är en av de mest populära JavaScript-biblioteken för kartläggning och används av stora sidor som bland annat Pinterest.
Leaflet gör det möjligt för utvecklare med en bakgrund inom geografiska informationssystem att enkelt och snabbt anpassa och visa ”tile maps” på publika servrar. ”Tile maps”-kartor som presenteras i webbläsaren är byggda genom att limma ihop flera individuella bilder som bildar en karta och är det mest populära sättet att visa och navigera i kartor på nätet. En bonus här är möjligheterna att ladda in data från GeoJSON-filer för att kunna anpassa och skapa interaktiva lager på kartan så som markörer, punkter som rör sig i realtid och klickbara områden med popup-fönster.
Google Maps
Google Maps är en öppen webbkartläggningstjänst från Google som har allt från satellitbilder till 360 graders panoramavy av gator till realtidsinformation av trafiksituationer [25]. Det började som ett datorprogram utvecklat av ”Where 2 Technologies”, skrivet i C++. Programmet köptes sedan upp av Google som vidareutvecklade programmet till en webbapplikation som är byggt med en front av XML, JavaScript och Ajax. De kartor och satellitbilder som Google Maps använder sig av täcker nästintill hela världen och det finns möjligheter för att zooma in och ut utan problem. Flertalet av kartorna kommer ifrån olika leverantörer, bland annat Tele Atlas och Transnavicom. Upptäcks fel i kartan av användarna kan det rapporteras in och i vissa fall till och med rättas till direkt. Detta gör att kartorna håller sig uppdaterade och uppehåller god kvalitet. Google Maps API som lanserades i juni 2005 gjorde det möjligt för utvecklare att integrera Google Maps med sina webbsidor.
Pubnub
Pubnub är ett stort dataströmningsnätverk framtaget för utvecklare för att underlätta och ge stöd för utveckling av realtidsapplikationer [26]. Med hjälp av PubNub kan man tillämpa en rad med funktioner till sitt program så som till exempel:
• Strömma geografiska platsdata från valfri mängd av källor och anpassa denna efter behov innan det presenteras på en karta.
• Lägga till dynamiska kartfunktioner.
• Skicka notifikationer till mobil- och dataplattformar.
• Aktivera SMS-baserade händelser baserat på olika event eller larm.
• Presentera aktioner, börs, poängställningar och liknande i realtid.
13
Utöver detta så har man tagit fram EON [27]. EON är ett projekt framställt för att stärka utvecklingen av kartor med realtidsdata. EON är ett JavaScript-ramverk för grafer och realtidskartor och fungerar på flera enheter. EON kopplar C3 diagram och Mapbox kartfunktioner till Pubnubs dataströmningsnätverk och skapar tack vare detta ett enkelt sätt att visualisera realtidsdata på grafer, diagram eller kartor.
XAMPP
XAMPP kan ses som en webbserverlösning som kommer i ett packet med flera undersystem [28]. XAMPP består huvudsakligen av Apache HTTP-server, MariaDB-databas och ett antal programtolkar för att exekvera instruktioner skrivna i PHP eller Perl. Då majoriteten av faktiska webbservrar använder sig av samma komponenter som XAMPP tillhandahåller så möjliggörs en enkel övergång av att sätta upp en lokal testserver till att vara en live-server. Målet med XAMPP är att göra det enkelt för utvecklare att sätta upp en Apache HTTP-webbserver och installeras med alla de funktioner som behövs där varje funktion är konfigurerat för att kunna startas upp och köras direkt.
NMEA GPRMC
NMEA kan vara förvirrande då det är en förkortning för ”National Marine Electronics Association” och är från början en förening som bildades 1957 av en grupp elektroniska återförsäljare, vars syfte var att skapa en bättre kommunikation mellan dem och tillverkare [29].
Idag är NMEA ett standardiserat dataformat inom GPS-världen som stöds av alla GPS tillverkare.
NMEA:s syfte är att ge användare möjlighet att själva blanda hårdvara och mjukvara. Ett standardiserat dataformat gör det också möjligt för utvecklare att enklare skriva mjukvara för en stort mängd av olika sorters GPS-mottagare.
Det man måste förstå om NMEA är att det inte bara finns ett enda NMEA-meddelande. Olika NMEA meddelanden har olika funktioner och förmågor precis som GPS-mottagare har olika kapaciteter. NMEA-data kan skickas över en stor mängd av olika kommunikationssätt, allt från USB till WIFI.
$GPGGA är det grundläggande GPS NMEA meddelandet som innehåller GPS-koordinater.
Utöver detta finns det NMEA-meddelanden som innehåller ytterligare information som till exempel $GPVTG som även inkluderar hastigheten över marken.
$GPRMC är ett alternativ till $GPGGA, och avser att täcka position, hastighet och tid.
14 Ett exempel på ett $GPRMC meddelande är:
$GPRMC, 111443.00, A, 4737.123,N, 2035.44,E, 60.4, 293.2, 241218, 002.2,W*6A Meddelandet består av olika fält och betyder följande:
Tabell 2.1 NMEA GPRMC
AJAX
AJAX är en förkortning av ”Asynchronous JavaScript And XML” [30]. Och består kortfattat av 7 steg:
1. En händelse sker på webbsidan. Tillexempel så laddas sidan in eller någon form an knapptryckning sker på sidan.
2. JavaScript skapar ett XMLHttpRequest objekt.
3. XMLHttpRequest objektet skickar en förfrågan till en webbserver.
4. Servern tar emot och bearbetar förfrågan.
Del av meddelande Betydelse
$GPRMC Meddelandets ID. Alla NMEA meddelanden startar med ett $. GP säger här att det är GPS positioner som meddelandet avser.
111443.00 UTC. Tidsstämpel för positionen. 111443.00 tolkas som 11:14 och 43.0 sekunder
A GPS-status. A = Active (Indikerar att en signal mottages och att det fungerar som det ska). V = Void. (Indikerar att någonting kan vara fel med den mottagna datan)
4737.123,N Anger latituden. Tolkas som 47 grader 37.123 minuter i norra hemisfären.
Ett S anges istället för N vid södra hemisfären.
2035.44,E Anger longituden. Tolkas som 20 grader 35.44 minuter i östra hemisfären. Ett W anges istället för E vid västra hemisfären.
60.4 Anger hastigheten i knop
293.2 Spårningsvinkel i grader. Riktningen GPS:en rör sig i förhållande till norr som är 0 grader.
241218 Datum. Tolkas som 24/12/18.
002.2,W Anger den magnetiska variationen.
*6A Kontrollsumma av datan. Börjar alltid med *.
15
5. Servern skickar därefter ett svar tillbaka till webbsidan.
6. Svaret hanteras och tolkas av JavaScript.
7. JavaScript utför rätt funktion. Till exempel sidan uppdateras eller en punkt på webbsidan förflyttas.
AJAX använder sig alltså av ett XMLHttpRequest-objekt inbyggt i webbläsaren för att begära data från en webbserver och JavaScript och HTML för att presentera eller använda sig av datan.
Att tänka på är att AJAX kan vara väldigt missledande. Namnet avser användning av XML för överföring av data medan det samtidigt är vanligt att används sig av JSON eller vanlig text istället för XML.
Fördelarna med AJAX är att utvecklare kan läsa data från en webbserver även efter att webbsidan har laddats in, webbsidan kan uppdateras utan att en omladdning av webbsidan krävs och data kan skickas till webbservern. Detta är stora fördelar vid implementering av webbsidor som ska presentera realtidsdata.
JSON
JSON (JavaScript Object Notation) är ett datautbytesformat [31]. Lätt att läsa för användare, och lätt att läsa och generera för datorer. JSON är ett textformat som är helt programspråks- oberoende men använder konventioner från C-familjen (så som C, C++, C#, Java, JavaScript etc).
JSON består av två strukturer: En samling av namn/värde-par (objekt), och en ordnad lista (array). En JSON-sträng kan börja med både ett objekt eller en array. Ett objekt är, som redan nämnt, en oordnad uppsättning av namn/värde-par och omsluts av ett klammerparentespar
”{ }”, namnet är en sträng som följs av ett kolon ”:” och sedan av värdet. Varje par separeras med ett kommatecken ”,” ifall det finns fler än ett par i objektet (se Figur 2.3).
Figur 2.3 JSON-objekt [37]
16
En array är en ordnad uppsättning av endast värden och omsluts av ett hakparentespar ”[ ]”.
Värden separeras med ett kommatecken ”,” vid fler än ett värde (se Figur 2.4).
Ett värde kan vara en sträng, ett nummer, ”true”, ”false” eller ”null” (utan citationstecken), ett objekt eller en array (se Figur 2.5). Objekt och arrayer kan alltså nästlas i varandra.
En sträng är en sekvens av noll eller fler Unicode-karaktärer, omslutna av citationstecken ” ” (se Figur 2.6).
Figur 2.4 JSON-array [38]
Figur 2.6 JSON-sträng [40]
Figur 2.5 JSON-värde [39]
17
Ett nummer är uppbyggd som ett vanligt nummer, där en punkt ”.” används som decimaltecken (se Figur 2.7).
2.3 Reguljära uttryck
Reguljära uttryck är en notation till att beskriva mängder av strängar [32], och ett uttryck består av en sträng med särskilda syntaxregler. Ett reguljärt uttryck med endast ett tecken ”t” matchar tecknet ”t” i order ”tryck”. Man kan bygga ihop uttryck med operatorer för att matcha komplicerade mönster där strängar med olika innehåll kan matchas av samma uttryck.
Exempelvis så kan ”[0-9]” matcha en godtycklig siffra, medan ”[0-9]*” matchar allt från inga till oändligt många godtyckliga nummer. ”Regulj(a|ä)r” matchar antingen ”Reguljar” eller
”Reguljär”, ”G(äv|ef)le” matchar antingen ”Gävle” eller ”Gefle”. En punkt ”.” används som jokertecken och matchar alla typer av tecken. ”a{0-5}” matchar ”a”, ”aa”, ända till ”aaaaa”.
”.*” matchar inga till oändligt antal godtyckliga tecken. För att matcha en punkt måste ett omvänt snedstreck placeras framför ”\.”.
Exempel: ”(Hej|Hallå), jag är 2[0-9] år gammal” matchar en sträng som börjar antingen med
”Hej” eller ”Hallå” och fortsätter med ”, jag är 2” följt av godtycklig siffra mellan 0 och 9, och sedan ” år gammal”. ”2[0-9]” matchar alltså tal mellan 20 och 29.
2.4 Existerande lösningar
I nuläget har trafikledningen tillgång till en rad olika verktyg för att kunna följa tågen på ett eller annat sätt. Vissa av verktygen är mer pålitliga än andra medan flertalet av lösningarna inte täcker de behov eller tillför det stöd som trafikledningen behöver. Under ett studiebesök som
Figur 2.7 JSON-nummer [41]
18
gjordes hos SJ under projektets gång så presenterades tre sätt som används mest för att följa tågen.
Utplacerade avläsningspunkter
Tack vare trafikverket kan man idag veta tågens position på järnvägen med hjälp av RFID- teknik [33]. RFID som är en förkortning av ”Radio Frequency Identification”, är en teknik som använder sig av trådlös informationsöverföring mellan en RFID-tagg och en RFID-läsare. RFID har många användningsområden i dagens samhälle bland dessa går det att hitta busskort, passering genom tullar, stöldskydd i butiker och passagesystem i byggnader. Inom tågtrafiken finns ett stort nät av RFID-läsare där möjligheten att spåra och följa enskilda fordon ges. I början på 2018 fanns det cirka 300 RFID-läsare runt om i landet och utbyggnad av dessa har och pågår än idag.
Med RFID-tekniken så finns även möjligheten att koppla detektormätvärden och larm ihop med fordonen (se Figur 2.8). Detta möjliggör att man får aktuell status och aktuella mätvärden för varje individuellt fordon för att snabbt upptäcka fel och behov av service. Utöver RFID-läsarna finns cirka 180 detektorer utplacerade. Data hämtas genom att RFID-taggar finns placerade på varsin sida av ett fordon. När tågen passerar en RFID-läsare så registreras taggen och data sparas i trafikverkets databas. Exempel på data är fordonets ID, vilken plats fordonet passerat, fordonets hastighet, tidpunkt, skador på hjulen och inbromsningar. Denna information finns tillgänglig som prenumerationsunderlag och används bland annat av SJ. För att få en bättre bild av tågens position använder man sig av ett par algoritmer som räknar ut var tåget borde befinna sig med tanke på hastighet och tidpunkt som tåget hade vid passering av en specifik RFID- läsare. De problem som kan uppstå här är att man inte vet exakt var tågen befinner sig. Då varje
Figur 2.8 RFID-tekniken [42]
19
RFID-läsare kan befinna sig flera kilometer från varandra så går det inte att avgöra var på spåret tåget är, hur terrängen runtom tåget ser ut och hur den faktiska tågsituationen är vilket i vissa fall kan orsaka flera problem.
Kommunikation via ombord personalens mobiler
Personalen ombord på tågen har idag möjlighet att logga in genom en applikation på deras mobiltelefoner och på så sätt dela med sig av GPS-data via den mobila enheten. Till skillnad från tekniken att beräkna tågets position med hjälp av avläsningspunkter så är denna variant mer tillförlitlig och täcker de områden som idag saknar avläsningspunkter. När personalen för en specifik tågresa först befinner sig på tåget så ska de logga in via deras mobila enheter. När de gör detta så börjar den mobila enheten att skicka GPS-data till de uppsatta databaserna.
Samtidigt som de loggar in så anger personalen även vilket tåg de befinner sig på, detta för att kunna identifiera vilket tåg GPS-informationen avser. Därefter finns ett visuellt gränssnitt uppsatt hos trafikledningen där personalen kan följa tågen. Ett problem som blir mycket tydligt vid användningen av denna teknik är när tågen plötsligt inte befinner sig på tågrälsen utan förflyttar sig åt annat håll. Orsaken till detta är att personalen kan glömma att stänga av applikationen som skickar GPS-data och tar med sig mobilen hem, vilket även gör att tåget följer med hem enligt det grafiska gränssnittet.
GPS-enheter på tåg
GPS-enheter finns på de modernare tågen idag som till exempel X40-tågen. Dessa skickar GPS- data om det fordon de sitter på och datan lagras och presenteras i ett visuellt kartgränssnitt.
Detta är den absolut bästa lösningen och den lösning som man gärna ser appliceras på alla fordon.
20
3 Projektdesign
I detta kapitel presenteras hur projektet har tagit form. En kort beskrivning av projektets grundidé presenteras och därefter hur projektet formades och motivering till den nya projektspecifikationen ges. Här presenteras också de val som gjorts kring de verktyg och språk som använts för projektet och även hur systemets design var tänkt att se ut.
3.1 Projektets grundidé
Projektet påbörjades med en väldigt bristande förståelse om vad för sorts system som skulle utvecklas och vad för möjligheter som fanns. Grundtanken var att det skulle utvecklas ett system som skulle agera som underlag och stöd för att effektivisera beslutsprocesser av operativa problem inom tågtrafiken. Systemet som skulle utvecklas var även tänkt att effektivisera beslutsprocesserna genom att med hjälp av machine learning automatisera flödet och påskynda besluten.
Under projektets första vecka hade följande tre frågeställningar utformats:
• Kan man med hjälp av en eller flera systemlösningar effektivisera och förenkla beslutsprocessen för trafikledning inom tågtrafik?
• Kan man med denna lösning samla in data och statistik som på sikt kan vara användbart för att effektivisera andra processer?
• Kan man med hjälp av denna/dessa lösningar, i framtiden, fatta beslut per automatik genom att göra systemet självgående, t.ex. med hjälp av machine learning?
Dessvärre föll dessa bort rätt fort och nedan presenteras hur och varför projektet formades om.
3.2 Planering
Möten med olika trafikledningar
För att förstå vilka operativa problem som trafikledningen fick handskas med dagligen så gjordes ett besök hos trafikledningen på SJ och Nobina redan första veckan. Målet med detta var att lokalisera resurskrävande problem som skulle kunna automatiseras och lösas genom någon typ av applikation. Besöken visade sig inte vara lika givande som önskat, då ingen tydlig bild gavs av vad som kunde lösas som inte var internt inom trafikledningen. SJ:s personal
21
fokuserade på problem med existerande programvara, och besöket på Nobina resulterade inte i något givande för det arbete som skulle genomföras. Resultatet var i grund och botten en rundtur genom Nobina:s kontor, och en genomgång av vad de arbetar med.
Således fick ett nytt besök på SJ:s trafikledning göras i tredje veckan, där taktiken i problemsökandet ändrades. En diskussion och genomgång av de problem som hade upptäckts under första besöket som trafikledningen inte tänkte på genomfördes. Strategin var nu att istället komma med förslag på funktionalitet som ansågs kunna hjälpa personalen och göra deras jobb enklare. Detta i sin tur gjorde att personalen själva började komma med idéer och förslag på vad de skulle vilja få stöd till. Det andra mötet gav mycket att arbeta med och funktionalitet som till sist kunde anses som bra att ha var följande:
1. Realtidspositionering av tåg på karta, deras planerade körväg, samt planerade passeringar av trafikplatser (där användaren kunde markera en trafikplats och få ut rätt information).
2. Varningar för tåg som inte håller sitt planerade körschema och vid stillastående fordon på plats där låga hastigheter inte ska uppstå.
3. Information om varje sträcka såsom hur många och vilka tåg som kör på vald plats.
4. Beräkning av sparad resetid vid ersättningstrafik.
Dessa funktioner fick senare omformuleras och begränsas på grund av de problem som presenteras längre fram i kapitel 5.
Möten med handledare
I början av projektet hölls regelbunden kontakt med universitetets handledare, med möten varannan vecka. Efter det andra mötet hos trafikledningen kunde en klarare bild av projektets mål presenteras för handledaren som i sin tur informerade om vad för något han ville se i projektet. Under veckan informerade handledaren om följande:
1. Ett datahanteringssystem som hämtar in data från olika källor och klistrar ihop det.
2. Användarfall i form av tilläggsprogram som använder sig av datan och presenterar den i någon form för användaren.
22
Utöver detta så tillhandahöll handledaren även en visuell bild över hur systemet exempelvis skulle kunna se ut (se Figur 3.1). Projektet och den omgjorda specifikationen tog form efter de tolkningar som gjordes av handledarens riktlinjer för ett godkänt arbete.
Vägledning på Softcode
På Softcode skedde avstämning minst en gång varje vecka. Dessa möten bestod av diskussion och vägledning från utvecklare på företagen och även hjälp med att få tillgång till servrar och utrustning. Softcode hjälpte till med att få kontakt med SJ:s trafikledning och även besöket hos Nobina. Softcode gjorde det även möjligt att komma i kontakt med externa parter som tidigare arbetat med liknande system, detta för att hjälpa projektet att gå vidare. Under dessa möten sattes det upp en rad olika användarfall. Även en del tips om olika verktyg och en del vägledning i vilka verktyg som vore enklast att använda för projektets syfte kom från Softcode.
3.3 Motivering och mål kring projektändringarna
Trafikledningen har i nuläget fortfarande en del problem som går att lösa. Efter andra mötet hos trafikledningen valdes det att inte arbeta med machine learning utan att istället utveckla ett system för inhämtning och hantering av data som sedan presenteras visuellt. I kapitel 2 presenterades de existerande lösningar trafikledningen har idag. Tanken med projektet var att
Figur 3.1 Visualisering av systemet
23
utveckla ett program som tar emot tågdata från externa parter och sedan presenterar datan på en karta i realtid. Tanken var att motivera trafikledningen till att införskaffa GPS-enheter på alla fordon och att ge dem ett underlag till de problem de har idag. Systemet var tänkt att även lösa följande problem som trafikledningen stöter på idag:
• Sätta prioritering på sena tåg, tåg som är ute och kör och tåg ska börja köra.
o Lösningsförslag: En visuell översikt över tågen i realtid skulle göra det möjligt att enklare sätta prioriteringar på tågen då man kan se hur tågen förhåller sig till varandra.
• Evakuering av personal och resenärer.
o Lösningsförslag: En visuell översikt över tågen i realtid skulle göra det möjligt att se miljön runtom tågen och på så sätt enklare och snabbare planera in evakuering och ersättningstrafik.
• Se mötesplatser och tågens förhållande till dessa.
o Lösningsförslag: En visuell översikt över tågen i realtid skulle göra det möjligt att snabbare planera in ett nytt möte längs en sträcka.
3.4 Användarfall
De användarfall som sattes för projektet är:
• Följa tåg i realtid på en karta
• På lämpligt sätt se om ett tåg står stilla.
• Se tåg som ankommer, avgår eller har varit på en specifik trafikplats.
Dessa användarfall var även de mål som satts upp för att bedöma resultatet av systemet i slutet av projektet. Projektet skulle komma använda sig av dessa användarfall som riktlinjer vid utveckling av systemet och datainhämtningen.
3.5 Generell design
Huvudkomponenten i programmet skulle vara ett databassystem med kringliggande data- omvandlare som förbereder inkommande data för att lagras i databasen. Ett grafiskt gränssnitt som refererar till databasen för att få ut nödvändig information skulle också vara en del av programmet (se Figur 3.2).
24 Databas
Databasen skulle kunna hantera både stationer och tåg. Stationerna skulle komma in via en statisk lista, och behövde lagras med namn, ID, och koordinater. Tågen skulle komma in via en konstant dataström och behövde lagra fordons-ID, annonserade/publika och tekniska/interna nummer, hastigheter, koordinater och tidpunkter. Då tågens data konstant uppdaterades behövde gamla data antingen slängas, skrivas över, eller sparas undan. Datan beslutades om att sparas utifall man ville kunna gå tillbaka till en viss tidpunkt för att se var tåget vid en viss tidpunkt.
Figur 3.2 Generell design av systemet
25 Dataomvandlare
För att stations- och tågdatan skulle kunna läggas in i databasen behövdes en omvandlare för att kunna ta ut rätt och relevant information från den inkommande datan, då de olika källorna som användes matade ut sin data på olika format. Dessutom behövdes en datauppladdare för att faktiskt få in datan i databasen. Dessa två skulle kombineras så att omvandlaren även laddade upp datan till databasen.
Då datan från stationerna inte kom från samma källa som datan från tågen (då de hade olika attribut, och då stationsdatan inte behövde uppdateras lika frekvent som tågdatan) bestämdes det att två olika omvandlare skulle köras separat.
Grafiskt gränssnitt
Förutom databassystemet skulle även ett grafiskt gränssnitt implementeras. Anledningen var att ha någonting som använde sig av det underliggande systemet och kunde påvisa dess funktionalitet, och samtidigt något att testa systemet med för att se så att den inkommande datan inte hade bristande frekvens eller dåliga mätvärden som skulle kunna visa tåg på platser där de inte skulle vara.
3.6 Val av språk
Språk som valdes för den grundläggande arkitekturen var C#, med tillägg för stöd av SQL. C#
valdes då det bedömdes vara det som var bäst lämpat för projektet och det systemet som var tänkt att utvecklas. Webbgränssnittet skulle skrivas i PHP och HTML då kunskaperna inom språken var goda. JavaScript skulle även användas för att rita ut kartan och dess innehåll.
Utöver detta testades och övervägdes C, C++ och Java. Dessa valdes dock bort väldigt fort. C valdes bort på grund av språkets komplicerade kompilerings-, och felhanteringsprocess. I C++
saknades essentiella kunskaper om språkets syntax och funktioner. Java som är likt C# valdes bort då kunskaperna ansågs vara bredare inom C#.
3.7 Testning och validering av verktyg
De verktyg som testades för kartbygget var Open Street Map, MapBox, Leaflet, Google Maps och PubNub. Leaflet är i grund och botten byggt med delar från MapBox, och när MapBox
26
testades uppstod stora bekymmer som länge troddes kunde lösas. Då Leaflet dock skiljer sig en del från MapBox på vissa håll men liknar på många andra så gjordes antaganden att samma problem skulle uppstå även i Leaflet vilket gjorde att det valdes att inte lägga mer tid på det.
Valet stod sedan länge mellan MapBox och Google Maps. MapBox hade en rad användbara funktioner som Google Maps inte hade, vilket gjorde att sökandet efter en lösning pågick väldigt länge. PubNub upptäcktes sent in i projektet, i början på december, med stöd för både MapBox och Google Maps. Efter att PubNub testats med MapBox, som kunde ha löst problemet, visade det sig att PubNub:s kod för MapBox var utdaterad och kvar återstod alternativet att använda Google Maps, trots att Google Maps inte erbjöd samma funktionalitet som önskades (se kapitel 5.2.3 för mer djupgående beskrivning på problemet). Open Street Map testades i början men eftersom att MapBox är byggt med hjälp av Open Street Map och dessutom tillhandahöll mer funktionalitet så gjordes ingen djupgående testning med Open Street Map.
Git valdes för versionshantering av koden och Docker och XAMPP för databashantering och servrar. MySQL Workbench valdes för att visuellt presentera innehållet i databasen. Microsoft Azure, Apache Kafka och Kubernetes valdes bort och detta på grund av verktygens komplexitet och brist på kunskap om verktygen. Efter testning valdes det att fortsätta med Docker och XAMPP då dessa var smidigare och snabbare att sätta upp, samt på grund av den tidspress som projektet redan hade på sig i detta stadiet.
3.8 Design av databasen
Efter en undersökning på indatan från Trafikverket och Oxyfi (som är ett företag som bland annat tillhandahåller realtidspositioneringsdata över tåg [34]), bestämdes databasens design, de tabeller som skulle användas och hur tabellerna skulle vara uppbyggda. Databasen skulle bestå av två tabeller. En för trafikplatserna, och en för tågen och deras positioner.
Trafikplatstabellen ”trainstations” skulle innehålla fem attribut, varav en primärnyckel. De fem attributen skulle vara trafikplatsens namn ”AdvertisedLocationName”, trafikplatsens ID/signatur ”LocationSignature” (som även var primärnyckel), trafikplatsens typ
”Prognosticated” (sant om station, falskt om mötespunkt), samt latitud ”Y” och longitud ”X”
(se Figur 3.3).
27
Tågtabellen ”trainlocations” skulle innehålla nio attribut, varav ett primärnyckelpar som omfattade två av attributen. Tågets/fordonets ID-nummer ”Vehicle” och tidsstämpel för avläsningen ”Time” (som tillsammans utgör primärnyckeln), annonserat/publikt nummer
”PublicNumber”, tekniskt/internt nummer ”InternalNumber”, status på tågets GPS-signal
”Active”, tågets latitud ”Y” och longitud ”X”, hastigheten ”Speed” samt riktningen tåget åker i ”Angle” (som dock inte användes till något i denna lösning) (se Figur 3.3).
3.9 Design av dataomvandlarna
Dataomvandlarna skulle ha kontakt med varsin tabell i databasen samt varsin källa där indatan kom från. Databasuppkopplingen skulle ske genom en MySQL-uppkoppling, och stations- dataomvandlaren skulle skicka en förfrågan till Trafikverket om hämtning av stationsdata.
Detta skulle sedan tolkas och konverteras till SQL-vänlig kod som skrev till databasen. I händelse av att kontakten bröts med databasen skulle omvandlaren stoppa uppladdningen och upprepa uppkopplingsförsöket tills en återanslutning hittats och kommunikationen med databasen kunde fortsätta. Tågdataomvandlaren skulle istället lyssna på Oxyfi:s dataström för att kunna hämta tågdatan. För varje meddelande skulle detta tolkas och konverteras till SQL- vänlig kod som sedan skrev till databasen. I händelse av att kontakten bröts skulle omvandlaren kasta det uppladdade meddelandet och göra ett återuppkopplingsförsök. Detta skulle göras en gång per meddelande då det handlar om realtidsdata och inte statiska data som för stationerna.
Figur 3.3 Databasens tabeller
28
3.10 Design av det grafiska gränssnittet
Det grafiska gränssnittet var ett komplement till databassystemet (databasen och omvandlarna) och skulle presentera datan på ett snyggt men smidigt sätt. De första redan existerande kartor som övervägdes att användas var MapBox eller Google Maps. MapBox valdes då dess redigeringsmöjligheter för olika kartdesigner var mycket bättre än vad Google erbjöd.
Dessvärre gjordes ändringar i slutskedet av projektet och MapBox bytes bort mot Google Maps på grund av problem med MapBox (se Kapitel 5.2.2).
Båda API:erna (MapBox och Google Maps), var gratis att använda. MapBox hade en begränsning på hur ofta man kunde ladda in kartan, men begränsningen låg högt nog för att inte skapa en oro för att behöva betala för överflödet av användning. Google Maps var gratis i ett år för utvecklare.
För denna prototypversion valdes det att endast ha kartan på webbsidan utan någonting annat (se Figur 3.4). Framtida möjligheter skulle kunna vara tabeller med tågens/valda tågs information, så som hastighet, och förseningar.
Se även Figur 1.1 för hur systemet är tänkt att se ut och användas.
Figur 3.4 Första gränssnittsdesignen
29
4 Implementation
Hur implementationen genomfördes beskrivs utförligt i detta kapitel. Då flera olika mindre program är delaktiga i hela processen, och då flera tidigare implementationer tvingats skrotas, så delas dessa beskrivningar in i mindre delkapitel, där var och en genomgående beskriver en huvudsaklig del i implementationen. Alla de problem som stöttes på under projektets gång tas upp i kapitel 5.
4.1 Introduktion
Grundfunktionaliteten hos programmet var att lättvindigt kunna hämta in data från flera olika källor och spara dem i en enda gemensam databas. Andra program skulle därefter kunna hämta denna data för att enkelt kunna göra beräkningar på de tåg som datan avser och kunna skapa grafiska lösningar för att förenkla lokalisering och informationshämtning för operatörer och eventuellt resenärer. En sådan grafisk lösning är även inkluderad i detta program.
Källkod för stationsdataomvandlaren hittas i Bilagor A.1, tågdataomvandlaren hittas i Bilagor A.2 och webbgränssnittet hittas i Bilagor A.3.
Mjukvara och programspråk som använts under implementationen
Då hela projektet bestod av mindre program som utförde olika typer av operationer har flertalet olika språk använts.
1. De två programmen som kommunicerade med Trafikverket och Oxyfi skrevs båda i C#.NET för att hämta in nödvändiga data, och använder SQL-kommandon för att kommunicera med projektets databas.
2. Den grafiska klienten skrevs i HTML, PHP, SQL, JavaScript. Även lite CSS användes, vilket kan ses som stilmallar för att beskriva hur HTML-element ska presenteras [35].
3. XAMPP Control Panel 3.2.2 användes för att kunna köra en lokal Apache server tillsammans med en MariaDB-modul, där den inhämtade datan förvarades, när den dedikerade databasen inte var tillgänglig.
4. Visual Studio Community 2017 användes som IDE (Integrated Development Environment).
5. Git användes för versionshantering.
30
4.2 Lokalisering av tågstationer och mötespunkter på järnvägen
Inhämtning av data och felhantering
Namn, koordinater, signaturer och urskiljning av stationer och mötespunkter hämtades från Trafikverket med deras egna API (se Figur 4.1), och lades in i en egen tabell i databasen. Denna funktion kördes en gång då värdena den får in var statiska platser och behöver inte automatiskt uppdateras. Skulle det dock hända att förändringar skedde genom exempelvis att en ny järnväg lades till kunde man manuellt köra operationen igen.
När operationen sätts igång kan flera olika saker hända vid dataöverföringen då databasen kan vara både tillgänglig eller otillgänglig
1. Operationen startas, men databasen är otillgänglig.
När operationen startas så etableras en anslutning till databasen. Skulle en sådan inte hittas repeteras anslutningsförsöket utan automatiskt stopp tills att en anslutning hittats.
Skulle en anslutning aldrig hittas måste programmet stängas av manuellt, skulle beslutet tvingas att fattas.
2. Operationen startas, och databasen är tillgänglig.
När operationen startas så etableras en anslutning till databasen. Operationen genomförs och en eventuellt äldre variant av tabellen tas bort och ersätts med en ny version (skulle tabellens struktur ha behövt ändras). Värdena laddas sedan upp i tabellen.
3. Operationen kör, men anslutningen till databasen avbryts mitt i dataöverföringen.
Skulle databasen plötsligt bli otillgänglig (till exempel vid strömavbrott, nätverksfel, systemkrasch m.fl.) försöker programmet återansluta till databasen och dataöverföringen pausas tills att en återanslutning kunnat genomföras. Dataöverföringen fortsätter sedan som normalt från där den slutat fungera utan att hoppa över missade överföringar.
31
Figur 4.2 Utdrag ur svaret Trafikverkets API Figur 4.1 Frågan som skickas till Trafikverkets API
32 Formatering av inhämtade data
Datan som hämtades från Trafikverket (se Figur 4.1) var i ett JSON-format (se Figur 4.2) och behövde först tolkas för att kunna extrahera värdena så de kunde skickas in till databasen. För att tolka JSON-datan användes ett reguljärt uttryck (se Figur 4.3). Parenteserna i uttrycket är grupper som sedan går att anropa för att få in just den data som finns mellan parenteserna.
Första gruppen som hämtas in är ”AdvertisedLocationName” och matchar bara om JSON-datan innehåller just den textsträngen, följt av ”.{0,40}” vilket betyder att upp till och med 40 godtyckliga tecken grupperas in till ett ord eller mening. Detta är själva namnet på trafikplatsen och kan innehålla mer än ett ord.
Grupp tre matchar ”Geometry” och visar att trafikplatsens koordinater kommer.
Matchningen måste även här vara exakt. Grupp fyra och fem är båda ”[0-9.]*” vilket matchar godtyckligt antal tecken som är antingen siffror eller punkter. Detta motsvarar trafikplatsens koordinater i longitud och latitud.
Grupp sex matchar ”LocationSignature” och måste vara en exakt matchning. Följt kommer då trafikplatsens signatur. Exempelvis så har Stockholm Central signaturen ”Cst”, Karlstad C har signaturen ”Ks”, och Göteborg C har signaturen ”G”. Detta är då matchningen i grupp sju där signaturen kan vara ett till och med tjugo godtyckliga tecken, men vanligtvis är det inte mer än fyra till fem tecken som mest. Signaturen är unik för varje trafikplats.
Grupp åtta matchar ”Prognosticated” och måste vara en exakt matchning. Grupp nio matchar antingen ”true” eller ”false”. En prognostiserad trafikplats är en tågstation eller mötespunkt där av- och påstigning antas vara tillåten. En ej prognostiserad trafikplats är en mötespunkt där på- och avstigning vanligtvis inte tillåts enligt föregående antagande. Detta antagande har gjorts då, vid kontroll av markörplacering på kartan, prognostiserade trafikplatser hamnat på tågstationer, och ej prognostiserade trafikplatser hamnat på enbart mötespunkter.
Den skarpsynte kan se att det reguljära uttrycket använder apostrofer (’) medan JSON-strängen som hämtas från Trafikverket använder citationstecken (”). Stationslokaliseraren formaterar om JSON-strängen då det reguljära uttrycket blir lättare att hantera i koden.
Figur 4.3 Reguljärt uttryck för tolkning av Trafikverkets JSON-data
33
Stationstabellens SQL-struktur och inmatning av data
Stationstabellen är den tabell som har hand om alla trafikplatser, där deras namn, koordinater, signaturer och trafikplatstyp sparas. Signaturen är alltid unik och används därför som primärnyckel (flera rader kan inte ha samma värde i sin primärnyckel) i databasen.
Koordinaterna är av WGS84-format [36], där heltalen representeras av grader och decimaler.
Trafikplatstyperna är i det här fallet antingen är prognostiserade eller inte. Se Figur 4.4 för utdrag från stationstabellen.
Stationslokaliserarens enda uppgift är att formatera den inhämtade JSON-datan, så att den kan laddas upp till databasen. Uppladdningen sker med SQL-kommandon, där den eventuellt äldre versionen av tabellen tas bort. Anledningen är att tabellens struktur kan ha uppdaterats.
Exempel på anledningar kan vara att Trafikverket helt byggt om sin egen struktur på sin data, vilket eventuellt kan innebära att tabellens struktur också måste uppdateras.
4.3 Lokalisering av aktiva och inaktiva fordon
Inhämtning av data och felhantering
Fordonsnummer (statiskt nummer knutet till just det fordonet), annonserat nummer (det nummer som resenärer ser), tekniskt nummer (internt nummer som trafikledningen ser, då ett tåg kan ha olika tekniska nummer om det kör på fler än en sträcka), koordinater, tidpunkter och hastighet hämtades genom Oxyfi och deras realtidspositionerings-API. Den inhämtade datan lades in i en egen tabell i databasen. Denna funktion var byggd för att köras oavbrutet och stannar vid manuell avstängning.
Figur 4.4 Utdrag ur stationstabellen
