V¨
aster˚
as, Sweden
Examensarbete f¨
or h¨
ogskoleingenj¨
orsexamen i n¨
atverksteknik, 15hp
INSAMLING AV DIAGNOSTIK
FR˚
AN ¨
ALDRE T˚
AGFLOTTOR
Andreas M¨
akil¨
a
E-post: ama17002@student.mdh.se
Examinator: Johan ˚
Akerberg
M¨alardalens H¨ogskola, V¨aster˚as, Sweden
Handledare: Conny Collander
M¨alardalens H¨ogskola, V¨aster˚as, Sweden
F¨
oretagshandledare: Lars Johansson
Eduro AB, V¨aster˚as, Sweden
Sammanfattning
Nutidens t˚ag har en livsl¨angd p˚a ungef¨ar 40 ˚ar, och m˚anga av de t˚ag vi har i drift ¨ar runt 20 ˚ar. Under denna tid har mycket utveckling skett inom insamling och analys av diagnostik som dessa ¨aldre t˚ag inte har kunnat ta del av. Detta projekt startades med syftet att skapa ett system som kan kopplas till databussarna i dessa ¨aldre t˚ag, samt expanderas med extra sensorer, och d¨arefter samla data, konvertera den till ett mer anv¨andbart format, och skicka den effektivt och kryptografiskt s¨akert till en central server f¨or insamling och analys. En f¨orstudie genomf¨ordes f¨or att kartl¨agga vilka system som finns i ¨aldre t˚ag, samt vilka nuvarande standarder som finns och skulle kunna anv¨andas f¨or v˚ara syften. Fr˚an den samlade informationen i f¨orstudien designades ett system med en eller flera noder i varje t˚ag som samlade ihop b˚ade cyklisk processdata och sporadiska meddelanden fr˚an t˚agets databuss. Dessa skickades sedan till en central server via en s¨aker VPN-tunnel. Den mottagna cykliska och sporadiska datan sparades sedan i en round-robin databas respektive en loggfil, varifr˚an den kunde avl¨asas. Systemet implementerades i en testmilj¨o och visade sig fungera utan problem. Vi kunde inte implementera systemet i ett riktigt t˚ag, men v˚ara test visar att den ¨overg˚angen borde kunna hanteras med minimala problem.
Inneh˚
allsf¨
orteckning
1 Inledning 3
2 Bakgrund 4
2.1 T˚agstruktur och metadata . . . 4
2.2 Train Communication Standard . . . 4
2.3 Systemkrav . . . 5 2.4 Ethernet . . . 6 2.4.1 Ethernet-frame . . . 7 2.5 TCP/IP . . . 7 2.6 JSON . . . 7 2.7 OpenVPN . . . 8 2.8 RRDtool . . . 8 2.9 Raspberry Pi . . . 8 3 Tidigare arbeten 9 4 Fr˚agest¨allning 10 5 Metod 11 6 Etik och samh¨alleliga aspekter 12 7 Design av systemet 13 7.1 Indata . . . 13
7.2 Milj¨oeffekter . . . 13
7.3 Topologi . . . 14
7.4 Val och design av protokoll . . . 14
8 Implementation av systemet 16 8.1 Version Ett . . . 16 8.2 Version Tv˚a . . . 16 9 Resultat 18 10 Diskussion 19 11 Slutsatser 20 12 Framtida arbete 21 13 Referenser 22
Figurlista
1 Termer som anv¨ands f¨or t˚ag . . . 42 OSI-modellen . . . 6
3 En ”frame” i Ethernet . . . 7
4 Den gamla designen f¨or n¨atverket . . . 13
5 De tv˚a nya designerna f¨or n¨atverket . . . 14
1
Inledning
Idag har t˚ag en normal livsl¨angd p˚a cirka 40 ˚ar [1]. Detta ¨ar en v¨aldigt l˚ang drifttid, och det ¨ar d¨arf¨or vanligt att ge t˚agen diverse uppdateringar under deras livscykel f¨or att h˚alla j¨amna steg med ny teknik. Ett omr˚ade som har utvecklats mycket under de senaste ˚aren och ¨ar v¨aldigt attraktivt f¨or m˚anga f¨oretag ¨ar insamling och analys av diagnostik, och det ¨ar l¨att att f¨orst˚a varf¨or. Med hj¨alp av diagnostik kan operat¨orer enkelt utf¨ora inspektioner, hitta problem, och planera ˚atg¨arder f¨or dessa innan de hinner bli v¨arre, vilket ¨
ar mycket anv¨andbart f¨or att h˚alla t˚ag i drift. Moderna t˚ag designas med dessa system implementerade, men det ¨ar bara under de senaste ˚aren som detta har funnits med vid typiska kravst¨allningar p˚a nya t˚ag. Det finns v¨aldigt m˚anga ¨aldre t˚agflottor som skulle kunna kompletteras med utrustning f¨or insamling av diagnostik.
Ett uppenbart problem med att s¨atta moderna diagnostiksystem i ¨aldre t˚agflottor ¨ar kostnaden. Att im-plementera de efterfr˚agade n¨atverken och sensorerna och se till att de inte orsakar problem med nuvarande system kr¨aver b˚ade tid och pengar. De flesta ¨aldre t˚ag som ¨ar i drift idag har n˚agon form av diagnostiksystem inbyggt, ¨aven om dessa inte n˚ar upp till moderna standarder i termer av sammankoppling och ˚atkomlighet. Skulle data fr˚an dessa system kunna avlyssnas och skickas till n˚agon form av central enhet f¨or samling och analys s˚a skulle en stor del av kostnaden att skapa ett helt nytt system kunna undvikas.
Detta projekt startades d˚a i syftet att skapa ett system som kan installeras i ¨aldre t˚agflottor, kopplas till deras diagnostiksystem och ge dem modern funktionalitet f¨or insamling, analys, och presentation av diagnostikdata. Ifall befintliga diagnostiksystem ¨ar bristf¨alliga s˚a ska sensorer kunna kopplas till systemet direkt f¨or att ut¨oka dess kapacitet.
Figur 1: Termer som anv¨ands f¨or t˚ag. P˚a engelska ¨ar dessa termer, i ned˚atg˚aende storleksordning, ”Train”, ”Vehicle”, och ”Car”
2
Bakgrund
I det implementerade systemet anv¨andes ett flertal olika standarder och program f¨or att koppla samman n¨atverket och skicka data. Vissa standarder beh¨ovde ocks˚a hanteras f¨or att kunna samla in data fr˚an t˚agen s˚a det sedan kunde skickas i n¨atverket. Dessa enheter och standarder n¨amns h¨ar.
2.1
T˚
agstruktur och metadata
F¨or varje bit data som tas emot och hanteras finns det en stor m¨angd metadata som ¨ar v¨ard att veta ut¨over de insamlade datapunkterna. Dessa ¨ar, exempelvis, vilken typ av sensor datan kom ifr˚an (accelerometer, termometer, variabel resistor, etc.), vilket system det kom fr˚an (TCN, FIP, CAN, etc.), vilken vagn det kom fr˚an (vagnens ordningsnummer i ett fordon, dess serienummer, etc.), vilket fordon det kom ifr˚an, och vilket t˚ag det kom fr˚an. Vad dessa begrepp betyder visas i figur 1. Om dessa datapunkter ¨ar k¨anda kan det ge en b¨attre id´e av hur systemet ¨ar uppbyggt, hur viktig en given datapunkt ¨ar, samt hur systemet felar om mottagen data avviker fr˚an normen. Om en abnorm datapunkt tas emot och kan begr¨ansas till en specifik sensor i en specifik vagn, s˚a kan datapunkten b¨attre tolkas och problemet blir enklare att l¨osa, eftersom det finns mer data f¨or fels¨okning av problemet.
2.2
Train Communication Standard
Train Communication Standard (TCN) ¨ar en standard som anv¨ands i ett flertal moderna t˚ag f¨or kommu-nikation mellan enheter [2]. Den ¨ar i sin tur uppdelad i tv˚a mindre standarder, Multifunctional Vehicle Bus (MVB) och Wire Train Bus (WTB). MVB-standarden anv¨ands f¨or att koppla samman ett flertal enheter i ett fordon. Exempel p˚a s˚adana enheter kan vara diagnostikdatorer, radios¨andare, motorkontroller, bromsar, med mera. Dessa kopplas in i bussen och kan d˚a skicka tv˚a olika typer av data: processvariabler (process variables) och meddelanden (messages), som skickas periodiskt respektive sporadiskt. B˚ada dessa typer av data skickas under en ”period” p˚a mediet, som ¨ar uppdelad i en periodisk fas, d¨ar huvudenheten f¨or bussen (master) efterfr˚agar alla processvariabler i ordning, och en sporadisk fas, d¨ar enheter efterfr˚agar tid p˚a mediet och kan s¨anda data om det finns tid kvar innan n¨asta period. Dessa perioder varar runt 1-2 ms. WTB-standarden ¨ar generellt mycket lik MVB, d˚a de b˚ada anv¨ander samma Real Time Protocol (RTP) f¨or kommunikation, men WTB anv¨ands f¨or att koppla samman olika fordon s˚a att data samlad fr˚an MVB kan skickas vidare i t˚aget. Den prim¨ara skillnaden ¨ar att enheter efterfr˚agar tid i den sporadiska fasen genom att aktivera en flagga i sitt paket under den periodiska fasen, samt att hela perioden tar plats under l¨angre tid, ungef¨ar 25 ms.
En annan, nyare version av WTB ¨ar Ethernet Train Backbone (ETB) [3]. Denna version av standarden anv¨ander Ethernet som grundl¨aggande protokoll i backbone. Detta ¨ar till stor del p˚a grund av Ethernets breda anv¨andning i marknaden och dess h¨oga hastigheter j¨amf¨ort med m˚anga andra n¨atverksbussar. Denna nya standard var ocks˚a designad f¨or att kunna kopplas till flera olika Consist Networks (CN) i vagnarna, som exempelvis klassiska MVB-n¨atverk, OpenCAN, WorldFIP, eller den nya Ethernet Consist Network (ECN),
som ¨ar gjord f¨or att anv¨andas p˚a liknande s¨att som MVB, men ocks˚a fungera b¨attre tillsammans med ETB ¨
an andra standarder.
2.3
Systemkrav
F¨or olika typer av inbyggda system finns olika krav p˚a viktiga kvalit´eer. Vissa system kan ha krav p˚a kort f¨ordr¨ojning, andra p˚a h¨og fels¨akerhet, och andra p˚a att vara milj¨ot˚aliga. Dessa kallas generellt icke-funktionella krav, f¨or att skilja dem fr˚an funktionella krav som beskriver vilka funktioner systemet m˚aste utf¨ora. Termen icke-funktionella krav ¨ar relativt bred, och det finns ingen universellt accepterad definition, som visas av Martin Glinz [4]. Det finns dock n˚agra vanliga exempel p˚a icke-funktionella krav. N˚agra av dessa f¨oljer: • Delay • Reliability • Safety • Security • Maintainability • Availability • Durability • Fault tolerance • Energy efficiency • Cost
F¨or ett givet system beh¨over en analys utf¨oras f¨or att utreda vilka av dessa (och andra) kvaliteter som ¨ar viktiga f¨or att systemet ska fungera optimalt. Vissa system (till exempel internetbanker) kr¨aver att all data garanterat kommer fram helt of¨or¨andrad. Dessa har d˚a krav p˚a h¨og tillf¨orlitlighet (reliability). Andra system (s˚asom videostr¨ommar) kan beh¨ova mycket snabb ¨overf¨oring, vilket d˚a leder till krav p˚a kortare f¨ordr¨ojning (delay). Det ¨ar ocks˚a m¨ojligt f¨or olika delar av ett system att ha olika krav. Exempelvis s˚a beh¨over betalningar f¨or en videostr¨ommnings-service (som Netflix) utf¨oras utan n˚agon som helst felkommunikation varje g˚ang de utf¨ors. Videon som spelas kan d¨aremot hantera n˚agra mindre st¨orningar s˚a l¨ange den laddas in snabbt och inte anv¨ander f¨or mycket av n¨atverkets bandbredd.
N˚agot som g¨or uppgiften att balansera systemkrav extra sv˚ar ¨ar faktumet att m˚anga krav ¨ar i konflikt med varandra. Till exempel s˚a kan tillf¨orlitligheten av ett system ¨okas genom att skicka om trafik flera g˚anger eller genom att skicka konfirmation om att ett paket tagits emot. Detta resulterar dock i l¨angre f¨ordr¨ojningar p˚a grund av m¨angden kontroller som utf¨ors innan paketet accepteras. Samma princip g¨aller f¨or andra krav s˚asom energieffektivitet och tr˚adl¨os r¨ackvidd, eller h˚allbarhet och kostnad.
En annan typ av systemkrav ¨ar deadlines. De tv˚a prim¨ara typerna ¨ar “mjuka deadlines” och “h˚arda dead-lines”. Om en deadline ¨ar mjuk betyder det att skickad data inte f¨orlorar allt v¨arde om den blir f¨orsenad, utan endast f¨orlorar en viss m¨angd v¨arde beroende p˚a exakt hur sen den ¨ar. Exempelvis om en t˚agbroms styrs av en dator och t˚agf¨oraren n¨odbromsar s˚a ¨ar det s˚aklart b¨ast om systemet reagerar direkt; men ¨aven om det tar l¨angre tid ¨an vanligt f¨or bromsarna att aktiveras s˚a kan de fortfarande g¨ora s˚a att en krock undviks eller blir mindre farlig. Det finns dock ofta en gr¨ans p˚a hur f¨orsenade dessa kan vara. Om t˚aget redan har krockat och st˚ar still s˚a ¨ar det inte v¨art n˚agot att aktivera bromsarna. H˚arda deadlines ¨ar simplare ¨
an mjuka deadlines. Om data med en h˚ard deadline g˚ar ¨over sin tidsbegr¨ansning s˚a kastas de bort, d˚a de inte l¨angre ¨ar anv¨andbara. Dessa kan exempelvis vara uppdateringar f¨or hastighetsm¨ataren i ett t˚ag. Om ett nytt uppm¨att v¨arde kommer in f¨oljt av ett ¨aldre s˚a ignoreras det ¨aldre d˚a det inte l¨angre ¨ar aktuellt. T˚agf¨oraren har ingen anv¨andning av att veta hur snabbt t˚aget ˚akte f¨or tv˚a sekunder sedan, de vill veta hur snabbt t˚aget ˚aker just nu.
Figur 2: OSI-modellen. Vissa lager har f¨orstorats d˚a de ¨ar viktigare att f¨orst˚a enskilt i denna rapport. Exempel har givits f¨or protokoll och n¨atverksstrukturer i de olika lagren.
2.4
Ethernet
Ethernet ¨ar ett protokoll som anv¨ands f¨or att skicka data inom n¨atverk genom ett n¨atverksmedia. Mediet ¨
ar vanligtvis en ”Twisted Pair” (TP)-kabel, men ¨aven andra medier kan anv¨andas, s˚asom coaxial-kablar (prim¨art i ¨aldre n¨atverk), fiberoptiska kablar (f¨or h¨ogre ¨overf¨oringshastigheter och mindre elektromagnetisk st¨orning) och tr˚adl¨os kommunikation. Ethernet-protokollet ligger i lager tv˚a av OSI-modellen, som kan ses i figur 2, vilket betyder att det anv¨ands f¨or kontroll av det fysiska mediet. M˚anga applikationer och standarder, exempelvis TCP/IP-standarderna som ligger till grund f¨or en stor del av moderna n¨atverk, anv¨ander Ethernet f¨or s¨andning genom media. Typiska n¨atverk f¨or privatpersoner, s˚asom ”Local Area Networks” (LAN) och internet anv¨ander det n¨astan exklusivt f¨or att koppla samman enheter och skicka data.
Ethernets breda anv¨andningsomr˚ade betyder att Ethernet-kompatibla enheter, s˚asom TP-kablar och ”Net-work Interface Cards” (NICs), ¨ar l¨attillg¨angliga och billiga, vilket g¨or dem attraktiva f¨or industriella ap-plikationer [5]. Det finns dock ett flertal problem med att anv¨anda Ethernet i dessa system. Ett av de st¨orsta problemen ¨ar att Ethernet ¨ar ett s˚a kallat ”contention based” media, specifikt ”carrier-sense multiple access” (CSMA), vilket betyder att alla noder som vill skicka data via mediet m˚aste v¨anta p˚a att mediet blir tyst. Om en kollision intr¨affar m˚aste de ocks˚a konkurrera ¨over vem som f˚ar skicka f¨orst. Processen f¨or att best¨amma vilken enhet som f˚ar skicka f¨orst har ingen best¨amd maxtid och kan d¨armed, teoretiskt sett, p˚ag˚a i flera minuter. Detta betyder att periodisk trafik, prim¨art s˚adan med korta cykler och sn¨ava deadlines, ¨ar sv˚ar att hantera p˚a Ethernet, vilket kan f¨orv¨antas d˚a det var designat f¨or m¨anskliga anv¨andare, inte industriella system. Dessa problem har till stor del r¨attats till med introduktionen av Ethernet-switchar, som reducerar m¨angden trafik p˚a mediet och, om full duplex anv¨ands, fullst¨andigt eliminerar risken f¨or kollisioner. F¨or de flesta switchar m˚aste dock paket k¨oas innan de kan skickas vidare, vilket kan skapa problem f¨or industriella applikationer. M˚anga varianter av industriellt Ethernet har d˚a skapats f¨or att g¨ora Ethernet-standarden mer kompatibel med industriella applikationer, genom att exempelvis undvika k¨ouppbyggnad.
Figur 3: En ”frame” i Ethernet 2.4.1 Ethernet-frame
N¨ar Ethernet-protokollet ska skicka ett meddelande p˚a mediet s˚a delas det f¨orst upp i mindre delar, s˚a kallade ”frames”[6]. Dessa delar blir sedan inkapslade (”encapsulated”) mellan dataf¨alt som inneh˚aller mer information om paketet. Denna information inkluderar MAC-adressen f¨or k¨all- och destinationsenheternas NIC-kort, vilket ¨ar en globalt unik adress som kan anv¨andas f¨or att identifiera en enhet i ett n¨atverk. Det inkluderas ocks˚a information om vilket protokoll som har inkapslats, genom ”Ethertype”-f¨altet, och en feldetekterande kod i ”Frame check sequence”-f¨altet i slutet av ”framen”. Strukturen kan ses i figur 3.
2.5
TCP/IP
TCP/IP ¨ar en familj av internetprotokoll som bygger p˚a Ethernet-protokollet och t¨acker lager tre och fyra i OSI-modellen i figur 2. Familjen best˚ar av tv˚a grundl¨aggande protokoll: IP-protokollet, som ligger i lager tre i OSI-modellen och bland annat ger varje internet-interface en unik adress f¨or att till˚ata ”routing” mellan n¨atverk, samt TCP och UDP, som ligger i lager fyra och ger instruktioner och metoder f¨or att transportera data mellan olika punkter p˚a ett effektivt s¨att.
TCP-protokollet till˚ater s¨aker ¨overf¨oring av data genom ett flertal olika funktioner. Dessa inkluderar num-rering av paket s˚a de alltid kan s¨attas samman i r¨att ordning, samt en form av ”handskakning” som verifierar att all data har skickats och tagits emot korrekt. Dessa funktioner kommer dock p˚a bekostnad av ¨okad band-bredd och ¨overf¨oringstid f¨or att kunna utf¨ora alla n¨odv¨andiga funktioner. Detta betyder att TCP ¨ar v¨al ¨
amnat f¨or applikationer d¨ar s¨aker ¨overf¨oring utan f¨orluster kr¨avs, och d¨ar det inte finns n˚agot risk att mediet blir fyllt av paket fr˚an handskakningar eller oms¨andningar, som exempelvis fil¨overf¨oring. UDP-protokollet ¨
ar, till skillnad fr˚an TCP, fokuserat p˚a snabb ¨overf¨oring och att anv¨anda s˚a lite extra bandbredd som m¨ojligt. F¨or att uppn˚a detta m˚aste dock UDP-paket skickas utan n˚agon form av verifiering eller handskakning, vilket s˚aklart leder till att vissa paket kan bli korrupta, f¨orlorade, eller tas emot i fel ordning. UDP passar d˚a b¨ast om dataf¨orluster ¨ar acceptabla men h¨oga hastigheter och fri bandbredd ¨ar ett krav, som exempelvis i live-video. TCP och UDP protokollen kan d˚a j¨amf¨oras med kraven p˚a tillf¨orlitlighet (reliability) och f¨ordr¨ojning (delay) som n¨amnts i kapitlet Systemkrav ovan, och de ¨ar ofta anv¨anda f¨or dessa typer av kommunikation ¨
over internet.
2.6
JSON
JSON ¨ar en ¨oppen standard f¨or filformatering, skapad f¨or att till˚ata fri s¨andning av data mellan olika program och enheter. JSON-data ¨ar uppdelat i tv˚a typer av dataobjekt: nyckel-v¨arde par och arrayer, som d˚a ocks˚a kan lagras inom varandra. Dessa objekt kan inneh˚alla flera olika typer av v¨arden, s˚asom nummer, text, eller boolesk data. ¨Aven om JSON ¨ar baserat p˚a JavaScript s˚a ¨ar det designat f¨or att vara en helt frist˚aende datatyp, och m˚anga programmeringsspr˚ak har implementerat egen kod f¨or att kunna avl¨asa och skriva till JSON-formatet.
2.7
OpenVPN
OpenVPN ¨ar mjukvara med ¨oppen k¨allkod som skapar s¨akra Virtuella Privata N¨atverk (VPN) fr˚an nod-till-nod eller n¨atverk-till-n¨atverk. OpenVPN till˚ater enheter att autentisera sig mot varandra genom certifikat, anv¨andarnamn och l¨osenord, och/eller “Pre-Shared Keys”(PSK). I VPN-n¨atverk med en nod utvald som server kan denna agera som en “Certificate Authority” (CA) och hantera signering, utdelning, och autenti-sering av certifikat i klienterna. De olika metoderna f¨or autentisering har olika f¨ordelar och nackdelar, men generellt rekommenderas att alltid anv¨anda en CA och anv¨anda de andra metoderna som en andra faktor i autentiseringen.
Ut¨over att koppla ihop flera enheter eller n¨atverk genom tunnlar s˚a de agerar som om de var direkt ihop-kopplade s˚a ger OpenVPN (och m˚anga andra VPN:er) ocks˚a ¨okad s¨akerhet genom att kryptera all trafik i dessa tunnlar. OpenVPN krypterar data- och kontrolltrafiken som skickas i tunnlarna med hj¨alp av OpenSSL, en implementering av SSL med ¨oppen k¨allkod. Detta betyder att OpenVPN kan anv¨andas f¨or att enkelt introducera funktioner s˚asom kryptering och autentisering till en tidigare os¨akrad datastr¨om.
2.8
RRDtool
RRDtool (Round-Robin Database Tool) ¨ar ett databasverktyg designat f¨or att effektivt lagra periodisk och kontinuerlig data, s˚asom bandbreddsanv¨andning, temperaturer, CPU-anv¨andning, med mera. Denna data lagras i en databas som anv¨ander en cirkul¨ar buffert, ibland kallad en ”round robin”. Detta betyder att ny data kommer att sparas i databasen tills en gr¨ans n˚as, och bufferten ¨ar full. Vid denna punkt kommer den ¨aldsta datapunkten skrivas ¨over med den nyaste, f¨oljt av den nu ¨aldsta, och s˚a vidare. Detta betyder att databasens totala storlek h˚aller sig konstant ¨over tid, p˚a bekostnad av att data ¨over en given ˚aldergr¨ans kommer att g˚a f¨orlorad. RRDtool inneh˚aller ocks˚a verktyg f¨or att extrahera data fr˚an databasen och skapa grafer fr˚an denna.
2.9
Raspberry Pi
Raspberry Pi (RPi) ¨ar en simpel, popul¨ar, och omkonfigurerbar enkortsdator, vilken agerar mer som en f¨orenklad persondator ¨an en enkortsdator. Den ¨ar speciellt popul¨ar f¨or projekt d¨ar skr¨addarsydda enkorts-datorer inte kan skapas specifikt f¨or ett givet syfte, och budgeten eller utrymme inte till˚ater att vanliga datorer anv¨andas. En av de stora sakerna som skiljer RPi fr˚an andra enkords-datorer, s˚asom Arduinos, ¨ar att den ¨ar ett s˚a kallat ”System-on-a-chip” (SoC), med f¨orm˚agan att anv¨anda konventionella operativsystem s˚asom Linux, ge ljud- och video, och generellt fungera mer som en vanlig dator ¨an ett inbyggt system [7]. Eftersom den anv¨ander ett operativsystem s˚a ¨ar den inte begr¨ansad till att endast k¨ora program i ett visst programmeringspr˚ak, som exempelvis C, utan kan ocks˚a hantera program skrivna i andra spr˚ak, exempelvis Python, samt konventionella skrivbordsprogram.
3
Tidigare arbeten
Ett av de tidigaste arbeten som kunde hittas om samling och uppvisning av t˚agdata var Railway Open System Interconnect Network (ROSIN) projektet, d¨ar ett flertal firmor arbetade tillsammans f¨or att definera profiler f¨or olika applikationer av TCN som d˚a kunde interoperera med enheter fr˚an andra tillverkare[2]. Datan som d˚a kunde samlas upp och avl¨asas visades i en demonstration genom en webbkoppling till fordonen som kallades ROSIN Maintenance (RoMain). Detta liknar vad vi vill g¨ora i detta projekt, men deras arbete var begr¨ansat av den l˚aga bandbredden i d˚atidens radiol¨ankar. N˚agot som idag inte ¨ar ett lika stort problem.
Ett annat arbete som hittades f¨or signaluppf˚angst och ¨overvakning av t˚agdata var “An MVB signal capturer based on microcontrollers for metro train on-line health monitoring system”[8]. I detta arbete anv¨andes en mikrokontroller f¨or att avlyssna data fr˚an en MVB-buss och sedan skicka den vidare till b˚ade en lokal dator via USB och en fj¨arrdator via 3G. Detta liknar ocks˚a v˚art slutm˚al, men vi kommer att anv¨anda mer moderna bussar och ge m¨ojligheten att l¨agga till extra sensorer ut¨over att l¨asa av de som redan existerar. V˚art system kommer ¨aven minska m¨angden trafik som skickas till servern och ¨andra hur denna trafik ¨ar formaterad, d˚a detta tidigare arbete skickade varenda mottaget MVB-paket direkt till servern via TCP, vilket skulle skapa sv˚arigheter med databearbetning och arkivering om flera hundratals t˚ag avl¨ases.
N˚agot b˚ada av dessa tidigare arbeten har gemensamt ¨ar att de inte har funktionalitet f¨or att l¨agga till andra sensorer eller kunna avlyssna n˚agra vagn-lokala bussar. Att dessa funktioner saknas kan ha orsakats av att l¨osningarna ¨ar sv˚ara att implementera eller f¨or att de inte ¨ar speciellt attraktiva. Avsaknaden av den senare kan dock ocks˚a vara p˚a grund av att det inte finns s˚a m˚anga vagn-lokala bussar i t˚ag.
4
Fr˚
agest¨
allning
M˚alet med v˚ar uppgift var att skapa ett system som kan kopplas till diagnostiksystemen i ¨aldre t˚agflottor, avlyssna och tolka trafiken utan att p˚averka den, och sedan samla all diagnostikdata p˚a en plats d¨ar den kan avl¨asas, sparas, och anv¨andas f¨or senare analys. F¨or att kunna uppfylla m˚alet beh¨ovde vi svara p˚a f¨oljande fr˚agest¨allningar:
1. Vilka befintliga system finns p˚a t˚ag (befintliga kommunikationsbussar, seriella serviceportar, etc.) och hur kan man avl¨asa data fr˚an dessa?
2. Hur kan fler sensorer l¨aggas till i systemet om behovet skulle finnas?
3. Vilka kommunikationsstandarder finns f¨or att skicka denna typ data och vilka passar b¨ast f¨or detta scenario?
4. Hur ska n¨atverket struktureras f¨or att skicka denna data p˚a ett s¨akert och effektivt s¨att?
Syftet bakom v˚ar uppgift var att, genom att g¨ora diagnostikdatan i t˚ag mer l¨attillg¨anglig, s˚a kan t˚ ag-tillg¨anglighet ¨okas d˚a b¨attre uppsikt kan h˚allas p˚a t˚ag och dess kondition. Eftersom systemet ¨aven kan skicka data ¨over internet till en server s˚a kan t˚agtillg¨anglighet f¨ors¨akras p˚a en global skala, d˚a data kan samlas fr˚an t˚ag runt om v¨arlden.
5
Metod
F¨or att designa och implementera detta n¨atverk kommer f¨orst en bred litteraturstudie utf¨oras om befintliga n¨atverk i t˚ag som kan avlyssnas och anv¨andas, samt vilka faktorer som ¨ar viktiga f¨or n¨atverk i t˚ag. Efter det kommer en m¨ojlig version av systemet designas och implementeras i en simulerad t˚agmilj¨o. Prestandan av denna kommer att utv¨arderas och ¨andringar g¨ors baserat p˚a resultaten. Denna process repeteras tills systemet uppfyller kraven som st¨allts.
F¨or att utv¨ardera systemets prestanda kommer indata simuleras i noderna, och deras f¨orm˚aga att skicka data till servern kommer att utv¨arderas baserat p˚a ett flertal faktorer s˚asom tappade paket, korrupta paket, och paketf¨ordr¨ojning.
Vi valde arbetsmetoden ovan, den s˚a kallade ”agila”-metoden, d˚a den ger en bra blandning av teoretiskt och praktiskt arbete, vilket ¨ar viktigt d˚a detta projekt till stor del ¨ar praktiskt. Den ger ocks˚a b¨attre m¨ojlighet att hitta och implementera nya funktioner under projektets g˚ang.
6
Etik och samh¨
alleliga aspekter
En viktig sak att t¨anka p˚a i det designade systemet var hur data fr˚an anv¨andare hanteras. Eftersom det ¨ar m¨ojligt att internettrafik fr˚an privatpersoner ocks˚a skickas igenom de l¨ankar vi avlyssnar s˚a var det viktigt att filtrera ut dessa i tidigaste stadiet, s˚a de inte kan l¨asas ut och m¨ojligtvis orsaka en risk f¨or personen som skickade den.
En viktig anledning till att detta arbete startades ¨ar faktumet att, om r¨att str¨omk¨alla anv¨ands, s˚a ¨ar t˚ag milj¨ov¨anligare ¨an andra transportmedel s˚asom flygplan och bilar. Att kunna uppgradera existerande system s˚a de har nyare funktionalitet skulle g¨ora t˚ag mycket enklare att underh˚alla, vilket borde leda till b¨attre tillf¨orlitlighet och f¨arre stopp, vilket i sin tur leder till att fler personer anv¨ander t˚ag.
Figur 4: Den gamla designen f¨or n¨atverket, med en Raspberry Pi installerad i varje vagn och sammankopplad med Ethernet-kablar.
7
Design av systemet
I designen av systemet fanns det ett flertal faktorer att t¨anka p˚a. Dessa var • Hur ser systemets indata ut? Vad ¨ar strukturen? Periodisk eller sporadisk? • Hur kan milj¨on n¨atverket befinner sig i orsaka problem och begr¨ansa v˚ara val? • Hur kommer n¨atverkets topologi att se ut? Kan vi anv¨anda nuvarande kopplingar? • Vilka nuvarande protokoll kan anv¨andas? Hur mycket beh¨over g¨oras om eller skapas?
7.1
Indata
Strukturen och perioden av indata var viktig att t¨anka p˚a vid designen av n¨atverket, d˚a den har en p˚averkan p˚a hur data fr˚an noderna skickas och hur ofta. MVB och WTB, som ¨ar huvudfokus i detta arbete, skickar data periodiskt i intervaller av 1-2 ms och 25 ms respektive, och vi kan anta at ETB-standarden liknar detta d˚a den ¨ar baserad p˚a TCN. Att skicka data periodiskt kan orsaka mindre problem f¨or konventionella IP-n¨atverk, d˚a de ¨ar b¨ast ¨amnade f¨or sporadisk s¨andning av data, men det ¨ar absolut m¨ojligt. Att g¨ora detta varje eller varannan millisekund ¨ar dock ett st¨orre problem, speciellt d˚a koden som anv¨ands i detta system inte kommer vara extremt optimerad. Med tanke p˚a att WTB anv¨ander ¨okade intervaller av 25 ms s˚a kan detta ocks˚a ha varit ett problem f¨or TCN-standarden. Vi kommer d¨arf¨or anv¨anda l¨angre intervaller, runt 250 ms, f¨or att skicka data, d˚a detta ger en god ”uppl¨osning” p˚a datan utan att vara ¨overv¨aldigande f¨or n¨atverket.
¨
Aven om TCN prim¨art skickar data periodiskt s˚a kan viss trafik i de periodiska cyklerna vara sporadisk; s˚a kallade “meddelanden”. Dessa skickas endast en g˚ang n¨ar de genereras, och extra omsorg m˚aste tas f¨or att f¨ors¨akra att de skickas n¨ar de f¨orst l¨ases av, samt att de inte tappas p˚a v¨agen till sin slutdestination. Olikt den periodiska datan s˚a kan dessutom dessa meddelanden vara intressanta att spara ¨over l¨angre tider, d˚a de kan inneh˚alla v¨ardefull data f¨or underh˚all av t˚agen s˚asom varningar och felmeddelanden.
7.2
Milj¨
oeffekter
En stor faktor i implementationen var milj¨on som n¨atverket skulle implementeras i. Olikt m˚anga typiska lokala n¨atverk, d¨ar det ofta finns plats f¨or nya kopplingar att l¨aggas till d¨ar de beh¨ovs, s˚a ¨ar t˚agvagnar generellt isolerade fr˚an varandra, och de modifieringar som kr¨avs f¨or att l¨agga till extra kablar kr¨aver tid och pengar. Detta innebar d˚a att vi var begr¨ansade till de kablar och kopplingar som redan fanns installerade i t˚agen. Detta kom med f¨ordelar och nackdelar. Den st¨orsta nackdelen var s˚aklart faktumet att vi inte kunde veta vad dessa kablar anv¨andes f¨or och d¨arav inte kunde veta vad de bar f¨or typ av trafik, s˚a vi visste d˚a inte med s¨akerhet ifall vi kunde skicka v˚ar egna trafik genom dem. En stor f¨ordel med detta var dock att, eftersom dessa kablar designades och testades f¨or anv¨andning p˚a t˚ag, s˚a kunde vi garantera att ¨ovriga milj¨oproblem (EM-st¨orningar, chock, slitage, etc.) var minimala j¨amf¨ort med vad vi kunde ha implementerat.
Figur 5: De tv˚a nya designerna f¨or n¨atverket. ¨Overst visas hur layout ser ut d˚a ETB ¨ar backbone. Underst visas layout ifall det inte finns ett Ethernet-baserad n¨atverk p˚a t˚aget.
7.3
Topologi
Den initiala id´een f¨or topologin, och den som anv¨andes i version 1, var att anv¨anda en RPi per vagn och sedan s¨atta n¨atverkskopplingar mellan varje vagn. Varje RPi skulle d˚a samla data fr˚an vagnlokala databussar och sedan skicka dessa genom n¨atverket till en central enhet i t˚aget, varifr˚an de skickas vidare till en extern global server. Denna design kan ses i figur 4. Id´en med denna l¨osning var att minska kostnaden av mobilabonnemang per t˚ag (d˚a endast ett skulle kr¨avas f¨or den centrala enheten), samt att g¨ora l¨osningen mycket kompatibel med alla t¨ankbara diagnostiksystem. Problemet med denna l¨osning var dock att den skulle kr¨ava att kablar dras mellan varje vagn i t˚aget vilket, som n¨amns ovan, inte ¨ar ett realistiskt m˚al. Om kablarna byttes ut med tr˚adl¨os s¨andning ¨over den korta distansen mellan vagnarna s˚a skulle ist¨allet ett nytt problem skapas med att etablera och uppeh˚alla tr˚adl¨osa kopplingar mellan vagnarna. Ut¨over detta s˚a har TCN-standarden, den mesta popul¨ara t˚agstandarden, redan ett n¨atverk som str¨acker sig ¨over hela t˚aget, varifr˚an vi kan l¨asa av data.
Eftersom det inte var m¨ojligt, varken ekonomiskt eller strukturellt, att l¨agga till v˚ara egna kopplingar i t˚agen, s˚a var vi begr¨ansade till de som redan fanns. T˚ag som anv¨ander ETB blir till stor hj¨alp h¨ar, eftersom ETB ¨ar baserad p˚a Ethernet-standarden, som l¨att kan avl¨asas f¨or nuvarande diagnostikdata, samt anv¨andas f¨or att skicka och ta emot extra data fr˚an andra RPis installerade i t˚aget utan st¨orre st¨orningar. Denna data kan d˚a skickas genom ETB till en gateway, varifr˚an den kan skickas till den globala servern. Om t˚agen inte anv¨ander ETB eller n˚agon annan form av Ethernet-baserat n¨atverk f¨or att l¨anka samman vagnar s˚a kan m¨ojligtvis vagn-lokala Wi-Fi n¨atverk anv¨andas ist¨allet f¨or att skicka meddelanden. Denna uppdaterade topologi kan ses i figur 5.
7.4
Val och design av protokoll
I version 1 av n¨atverket s˚a planerades endast Ethernet anv¨andas, med all annan funktionalitet skapad av oss. Detta gjordes eftersom m˚anga funktioner som gavs av TCP/IP, s˚asom komplex routing och fl¨odeskontroll, inte ans˚ags vara viktiga f¨or ett n¨atverk som endast bredde ut sig i en riktning. Nya protokoll designades d˚a f¨or att skicka data, synkronisera klockorna, och etablera en standard-gateway. Dessa n¨amns ej h¨ar, d˚a de inte hann l¨amna teststadiet och inte har n˚agon influens p˚a version 2 av n¨atverket.
Eftersom alla n¨atverk f¨or version 2 av systemet kommer att anv¨anda sig av Ethernet och Internet f¨or att skicka data s˚a ¨ar TCP/IP protokollen ¨onskv¨arda, d˚a de redan ¨ar etablerade inom dessa omr˚aden och ¨ar l¨atta att implementera i de flesta enheter. UDP-protokollet anv¨ands f¨or all periodisk trafik, d˚a denna har starka krav p˚a att komma fram i tid och inte f˚ar anv¨anda f¨or mycket bandbredd, men ocks˚a kan tappas utan st¨orre problem och d¨arf¨or inte beh¨over skickas om. TCP-protokollet anv¨ands f¨or sporadisk trafik, d˚a denna har striktare krav p˚a att bli mottagen och mottagning m˚aste vara s¨aker, men d¨ar bandbredden inte ¨ar ett lika stort problem d˚a de inte skickas lika frekvent.
under varje nyckel inneh˚aller all sensordata f¨or ett visst fordon, vagn, eller system. Data f¨or dessa sensorer inneh˚aller ocks˚a sensorns namn, dess enhet, och en beskrivning. Detta hj¨alper till att h˚alla datan organiserad och g¨or det ocks˚a enkelt att ut¨oka vilken data som kan skickas. En typisk avl¨asning av ett v¨arde kan se ut p˚a f¨oljande vis:
pckt["data"]["4763-6573-111"]["TCN Bus 1"]["Cabin Temperature"]["value"]
Var och en av dessa nycklar begr¨ansar m¨angden data som ges. ”data” pekar p˚a alla uppm¨atta datav¨arden, ”4763-6573-111” pekar p˚a en specifik vagn, ”TCN Bus 1” pekar p˚a en viss databuss, ”Cabin Temperature” pekar p˚a en viss sensor, och ”value” pekar p˚a v¨ardet som uppm¨ats av denna sensor. Detta ger en god f¨orm˚aga att se varifr˚an ett givet v¨arde kommer.
F¨or att spara cyklisk data p˚a servern anv¨ands RRDTool, och all data av denna typ som tas emot sparas i dess cykliska databas-filer, med en fil automatiskt skapad f¨or varje fordon, s˚a det inte finns en enda fil som blir helt ¨overfylld. Om en ny datak¨alla f¨or ett fordon kommer in s˚a l¨aggs denna till i den databas-fil som passar dess fordon. Faktumet att RRDTool anv¨ander cykliska databaser betyder att sparad data kommer att ¨overskrivas efter att tillr¨ackligt med tid har passerat. Eftersom dessa paket endast inneh˚aller sensoravl¨asningar medans varningar hanteras av den sporadiska trafiken anses dock detta acceptabelt. Eftersom RRDTool har begr¨ansningar p˚a hur l˚anga variabelnamn f˚ar vara s˚a beh¨ovde originalnamnet f¨orkortas. Vi valde att g¨ora detta genom att generera en hash av originalnamnet och anv¨anda denna f¨or variabeln. RRDTool kr¨aver dessutom minst en sekund av v¨antetid mellan uppdateringar p˚a variabler. Vi valde att skicka in nya v¨arden varannan sekund f¨or att undvika m¨ojliga problem som kan skapas n¨ar man f¨ors¨oker stoppa in v¨arden s˚a n¨ara varandra som m¨ojligt. Vi best¨amde dock att fortfarande skicka upp-dateringar till servern varje fj¨ardedels sekund, d˚a detta minskar risken att ett paket tappas och ett h˚al skapas i grafen.
Sporadisk trafik loggas i en loggfil f¨or arkivering och senare avl¨asning. Dessa loggar inneh˚aller information s˚asom mottagningstid och varningsniv˚a, vilket hj¨alper f¨or att hitta kritiska problem. Baserat p˚a hur kritiska dessa loggar kan vara s˚a tas ˚atg¨arder f¨or att f¨orhindra dem fr˚an att bli tappade. Att skicka via TCP ¨ar en av dessa, men ut¨over den s˚a l¨aggs ocks˚a paket som misslyckats att s¨andas i en k¨o. Noden f¨ors¨oker d˚a att skicka dessa paket i j¨amna intervall av runt 0.25 sekunder, s˚a att de n˚ar servern. Eftersom dessa paket har mjuka deadlines s˚a ¨ar de v¨arda att f¨ors¨oka skicka, ¨aven om mycket tid har passerat sedan de borde skickats. F¨or att s¨akra kommunikation mellan noder och servern, samt f¨or att till˚ata dessa enheter att autentisera sig mot varandra, s˚a anv¨andes OpenVPN f¨or att skapa krypterade tunnlar mellan enheterna. F¨or denna version valdes en relativt simpel implementation av OpenVPN. Exempelvis s˚a genererades alla klientcertifikat p˚a servern och beh¨ovde sedan manuellt exporteras till klienterna. I ett riktigt n¨atverk b¨or denna process automatiseras.
8
Implementation av systemet
Systemet gick igenom tv˚a prim¨ara versioner. Version 1 var baserad p˚a id´en av att l¨asa den lokala bussen i varje vagn med en RPi och sedan koppla samman alla dessa i ett eget n¨atverk. Version 2 var ist¨allet baserad p˚a att anv¨anda redan existerande n¨atverk i t˚ag f¨or att l¨anka samman alla RPi:er, och blev den slutliga designen f¨or n¨atverket.
8.1
Version Ett
F¨or att test-implementera version ett s˚a skapades b˚ade ett exempeln¨atverk och ett python-program. Exempel-n¨atverket var uppbyggt av tre RPis, med l¨ankar fr˚an den centrala RPin till de tv˚a ”utspretande” RPierna. Detta skulle d˚a simulera layouten i ett t˚ag, med en enhet i f¨oren, en eller flera enheter i de centrala vagnarna, och en enhet i aktern.
Python-programmet som skapades f¨or n¨atverket var designat f¨or att endast anv¨anda Ethernet-frames, utan n˚agra protokoll p˚a h¨ogre niv˚a s˚asom IP eller TCP/UDP. Det var designat p˚a s˚a vis att enheter konstant lyssnade efter trafik taggad med EtherType 4554, 4555, eller 4550. N¨ar denna trafik togs emot s˚a utf¨ordes en kontroll p˚a vilken MAC-adress den hade som destination. Om MAC-adressen inte var enhetens egna s˚a f¨ors¨okte den skicka vidare paketet genom det andra interfacet, om det fanns ett s˚adant installerat. Om det matchade enhetens MAC-adress s˚a avl¨astes hela paketet och instruktioner utf¨ordes beroende p˚a vilken specifik EtherType som var given. Om EtherType var 4554 (Eduro Train, ET) s˚a skrevs den mottagna t˚agdatan till en fil. Om EtherType var 4555 (Eduro Unix, EU) s˚a utf¨ordes det steg av tidsynkroniseringen som specificerades i paketet. Om EtherType var 4550 (Eduro Ping, EP) s˚a utf¨ordes funktionen som specificerats i paketet (i v˚arat protokoll var detta endast funktionen som hittade n¨atverkets server).
Programmet var dessutom designat med en specifik handlingssekvens. N¨ar en nod (f¨orutom servern) startade ig˚ang s˚a f¨ors¨okte den f¨orst hitta serverns MAC-adress via EP-paket. N¨ar den v¨al hittat denna s˚a synkronis-erade den sin klocka med servern via EU-protokollet. Efter detta s˚a b¨orjade den skicka ET-paket till servern med exempeldata. Test utf¨ordes dessutom i regulj¨ara intervall f¨or att se om servern fortfarande var n˚abar och f¨or att ˚atersynkronisera tiden.
Systemet implementerades och testk¨ordes p˚a de tre sammankopplade RPierna, d¨ar en av de utspretande noderna var satt att agera som server, s˚a att forwarding av paket ocks˚a kunde testas. Det fungerade utan st¨orre problem, men innan vi utf¨orde n˚agra vidare test ins˚ag vi att den skapade l¨osningen var orealistisk att implementera i ett riktigt t˚ag p˚a grund av den milj¨o som finns ombord p˚a t˚ag, som n¨amns under rubriken ”Milj¨oeffekter”, samt p˚a grund av att det p˚a m˚anga t˚ag redan finns n˚agon form av ”backbone”-n¨atverk. Systemet designades d¨arf¨or om efter dessa nyuppt¨ackta krav och m¨ojligheter.
8.2
Version Tv˚
a
F¨or test-implementationen av version tv˚a skapades ˚aterigen ett n¨atverk och ett python-program; men dessa var ¨andrade efter den nya designen. N¨atverket bestod av en n¨atverksswitch (v˚ar ers¨attare f¨or ett ETB-n¨atverk) med tv˚a noder kopplade till sig, samt en koppling till en router. En nod agerade som en sj¨alvst˚aende sensor och hanterade ocks˚a att skicka ETB-exempeldata till den andra noden, som agerade lyssnare f¨or n¨atverket. Dessa noder skickade sedan sin data ¨over internet till en server, som sammanst¨allde den mottagna datan.
Python-programmet var simplare denna g˚ang, med alla enheter uppdelade i servers och klienter. Klienter kan skicka tv˚a typer av trafik: tillf¨orlitlig TCP-trafik och os¨aker UDP-trafik. All sporadisk data, s˚asom meddelanden, skickas tillf¨orlitligt, medans periodisk data skickas os¨akert utan verifikation. Servrar kan ta emot data och d¨arefter spara det f¨or senare inspektion. Data sparas som tv˚a olika typer, beroende p˚a vilken typ av data det ¨ar. Aperiodisk data sparas i en loggfil, medans periodisk data sparas i en cyklisk ”round-robin” databas via RRDTool.
Under implementationens g˚ang uppt¨acktes dock att namnen f¨or varje variabel som sparades, vilket inkluderar fordon, vagn, och system, var f¨or l˚anga f¨or att kunna anv¨andas i databasen. Det var inte heller m¨ojligt att lagra annan information om variabler (s˚asom enhet och beskrivning) i databasen. D¨arf¨or anv¨andes ist¨allet ”hasher” av variabelnamnen, som kan kortas ned till maxl¨angden p˚a variabler och ¨and˚a vara unika nog f¨or att inte kollidera. Dessa hasher sparades sedan i en lista tillsammans med andra variabler s˚asom enhet och beskrivning, och anv¨andes n¨ar ett nytt v¨arde kom in och variabelnamnet beh¨ovde hittas, eller n¨ar en graf beh¨ovde ritas.
Systemets f¨orsta implementation och testk¨orning gick utan st¨orre problem. All periodisk data sparades i RRD-databaserna, medans all aperiodisk data skrevs till loggfilen. Ett test gjordes ocks˚a att koppla ur en av enheterna och sedan koppla in den igen, vilket resulterade i ett tillf¨alligt avbrott i s¨andningen av data f¨oljt av att s¨andningen ˚aterupptogs, som f¨orv¨antades. I det f¨orsta stadiet genererade dock den lyssnande noden sin egna trafik. Detta ¨andrades snabbt till uppf˚angad trafik fr˚an den andra noden, och systemet fungerade lika bra. Systemet designades ocks˚a om s˚a att det sparade data fr˚an varje fordon i en egen RRD-fil, samt att varje fordons grafer sparades i en egen mapp, s˚a att systemet inte blir f¨or sv˚art att navigera d˚a fler fordon l¨aggs till. Metoden f¨or att skicka aperiodisk trafik ¨andrades ocks˚a s˚a att alla paket som inte kunde s¨andas lades i en k¨o och skickades n¨ar kopplingen gick upp igen. Datan som skickades var ¨annu inte formaterad som ETB-trafik, d˚a vi inte visste hur trafiken s˚ag ut, men systemet var designat s˚a att det skulle vara relativt enkelt att g¨ora det kompatibelt med den sanna trafiken n¨ar specifikationerna togs emot.
F¨or att f¨ors¨akra att data skickades s¨akert mellan de olika enheterna s˚a anv¨andes OpenVPN f¨or att skapa tunnlar mellan noderna och servern. Detta anv¨andes prim¨art f¨or att skapa en s¨aker uppkoppling men kan till viss del hj¨alpa till att h˚alla n¨atverket strukturerat, d˚a noder kan ges statiska adresser utan att beh¨ova k¨opa s˚adana fr˚an en ISP. OpenVPN till˚ater kryptering av all trafik, vilket g¨or avlyssning mycket sv˚arare, samt autentisering av b˚ade klient och server, vilket f¨orhindrar overifierade enheter fr˚an att skicka data till servern. M˚anga av dessa funktioner skulle teoretiskt kunna implementeras utan att etablera en VPN, d˚a systemet ¨ar designat s˚a att adresser f¨or noder inte beh¨over k¨annas till. Men att skapa alla dessa funktioner och testa att de fungerar skulle kr¨ava mycket tid och pengar f¨or v¨aldigt lite returv¨arde.
Figur 6: Topologin f¨or det slutliga n¨atverket. Den ¨ovre bilden visar v˚ar implementation och den undre visar hur den skulle se ut i ett t˚ag.
9
Resultat
Den slutliga topologin av testn¨atverket, samt dess ekvivalenta implementation i ett riktigt t˚ag, kan ses i figur 6. Den h¨ogra noden agerade som en ¨overs¨attare f¨or t˚agn¨atverket (i detta exempel ETB) och hanterade att avl¨asa data, g¨ora om den till ett ¨onskat format, och sedan skicka den till servern. Den v¨anstra noden agerade ist¨allet som en ut¨okningsnod. Den hade en egen sensor (eller sensorer) f¨or vilken den skickar data till servern. All data som var periodisk skickades via UDP, f¨or att minska m¨angden trafik som genererades eftersom denna data inte hade starka krav p˚a att f˚a igenom varje paket. All sporadisk data skickades ist¨allet via TCP, f¨or att f¨ors¨akra dess s¨andning. B˚ada dessa datatyper skickades i JSON-format, uppdelade efter fordon, vagn och system, f¨or att underl¨atta avl¨asning och arkivering. Mellan varje nod och servern etablerades ocks˚a en OpenVPN-tunnel. Dessa tunnlar till¨at nod och server att autentisera sig mot varandra, f¨or att f¨orhindra “impersonation”-attacker, och krypterade dessutom trafik som skickades mellan enheterna, f¨or att f¨orhindra avlyssning av andra partier.
Ett test utf¨ordes d¨ar enheter p˚a n¨atverket kopplades ur och sedan in igen, f¨or att se hur de reagerade. Efter ˚ateranslutning till n¨atverket s˚a lyckades dessa enheter ˚ateretablera VPN-tunneln och skicka data igen. All UDP data skickad under denna tid ans˚ags korrekt vara f¨orlorad, medans all TCP-data lades i en k¨o och skickades ¨over till servern d˚a kopplingen ˚ateruppr¨attades.
10
Diskussion
I det slutliga systemet (version tv˚a) valde vi att prim¨art anv¨anda existerande mjukvara och standarder f¨or allt ifr˚an s¨andning till lagring. Det skulle teoretiskt sett vara m¨ojligt att skapa dessa standarder sj¨alv s˚a att de b¨attre passar f¨or applikationen (exempelvis s˚a beh¨ovs egentligen ingen logisk tunnel mellan nod och server, och RRDTool’s begr¨ansning p˚a max en uppdatering per sekund kan ocks˚a vara ett problem beroende p˚a krav f¨or datauppl¨osning). Att g¨ora detta skulle dock kr¨ava en stor m¨angd tid och pengar, mot en marginell f¨orb¨attring i prestanda. Det ¨ar ocks˚a tveksamt om dessa n˚agonsin skulle n˚a kvaliteten av de etablerade system vi anv¨ander just nu, d˚a dessa har haft ˚ar av anv¨andning, testning och buggfixar, medans v˚ara program och standarder troligtvis endast skulle anv¨andas och testas av de som anv¨ander v˚art specifika system. Att anv¨anda etablerade standarder ger ocks˚a f¨ordelen att v˚art system b¨attre kan samverka med andra system.
Eftersom vi ville f¨ors¨akra oss om att autentiserade enheter fanns p˚a b˚ada sidor av VPN-tunneln s˚a anv¨ande vi klient-certifikat, som rekommenderas av utvecklarna. Vi valde dock att inte anv¨anda PSK eller anv¨ andar-namn/l¨osenord, d˚a dessa antagligen ¨ar menade f¨or tillf¨allen d¨ar fler ¨an en anv¨andare kan anv¨anda systemet och man vill undvika att s˚av¨al fel enhet som fel person kan koppla upp sig. Eftersom v˚ara enheter inte har mer ¨an en anv¨andare s˚a ¨ar dessa ¨overfl¨odiga och skulle inte ge en noterbar ¨okning av s¨akerheten i tunneln.
¨
Aven om huvudfokus l˚ag p˚a att g¨ora ett system som kan implementeras i t˚ag med ETB s˚a f¨ors¨okte vi g¨ora systemet flexibelt nog att kunna anv¨andas med alla typer av databussar. Avlyssnare och extra sensorer kan l¨aggas till oberoende av vilken buss som anv¨ands f¨or att koppla samman t˚aget; det enda kravet ¨ar att dessa har n˚agon form av uppkoppling till internet, samt att avlyssnaren kan l¨asa och f¨orst˚a trafiken som skickas via bussen.
11
Slutsatser
¨
Aven om systemet i sitt nuvarande tillst˚and inte ¨ar direkt redo f¨or implementation i stor skala s˚a anser vi att det prim¨ara syftet, att skapa en s¨aker och expanderbar n¨atverksstruktur som kan anv¨andas f¨or att avl¨asa och spara t˚agdata, ¨ar uppfyllt. Alla delar som beh¨ovs f¨or att uppfylla syftet, s˚asom noder, databas, och kryptering, ¨ar dokumenterade, och det som nu kvarst˚ar ¨ar att f¨orb¨attra hur dessa delar samarbetar f¨or att skapa n¨atverket. ¨Aven om det skulle varit v¨aldigt intressant att kunna implementera v˚art system p˚a ett riktigt t˚ag med riktig input-data s˚a anser vi ¨and˚a projektet vara v¨aldigt lyckat eftersom det utf¨or alla uppgifter det var designat f¨or p˚a ett simpelt och standardiserat s¨att. Att ¨overs¨atta mellan olika, potentiellt mycket skilda n¨atverksprotokoll ligger utanf¨or mitt personliga kompetensomr˚ade, och ¨ar en uppgift b¨attre l¨ampad till n˚agon som vet mer om t˚agn¨atverk och n¨atverksavlyssning.
12
Framtida arbete
P˚a grund av begr¨ansningar i tid och testmilj¨oer s˚a kunde det utvecklade systemet inte implementeras och testas p˚a riktig h˚ardvara med riktig input-data. Detta betyder d˚a att, ¨aven om systemet var designat f¨or att kunna hantera olika inputs, s˚a har inga funktioner skapats f¨or att avl¨asa data fr˚an databussar, och dessa m˚aste skapas av de som anv¨ander systemet, eller de som kommer s¨alja systemet kommersiellt. Funktioner f¨or att filtrera ut trafik genererad av privatpersoner (som n¨amns under Etik och samh¨alleliga aspekter) har inte heller implementerats, och m˚aste hanteras av anv¨andare eller f¨ors¨aljare.
Effektiviteten av det system som utvecklats ¨ar s˚aklart begr¨ansat av mina egna f¨orm˚agor. Python ¨ar ett utm¨ark spr˚ak f¨or att skapa l¨asbar kod, men ¨ar dessv¨arre inte snabbt som till exempel C++, vilket kan skapa problem f¨or en server som m¨ojligtvis m˚aste hantera hundratals fordon som alla skickar data samtidigt. Processen av att skapa VPN-tunnlar borde ocks˚a f¨orenklas vid en implementering i en riktigt milj¨o.
13
Referenser
[1] A. Weiss and U. Kucharzyk, “Generic ground side interface for remote train access,” in 2009 9th Inter-national Conference on Intelligent Transport Systems Telecommunications, (ITST), pp. 320–324, 2009. [2] Hubert Kirrmann and Pierre A. Zuber, “The IEC/IEEE Train Communication Network,” IEEE Micro,
Mars–April 2001.
[3] A. Zuloaga, A. Astarloa, J. Jimenez, J. Lazaro, and J. A. Angel Araujo, “Cost-effective redundancy for ethernet train communications using HSR,” in 2014 IEEE 23rd International Symposium on Industrial Electronics (ISIE), pp. 1117–1122, 2014.
[4] M. Glinz, “On Non-Functional Requirements,” in 15th IEEE International Requirements Engineering Conference (RE 2007), pp. 21–26, 2007.
[5] Z. Gong, B. Liu, S. Yang, and X. Gui, “Analysis of industrial ethernet’s reliability and realtime perfor-mance,” in 2009 8th International Conference on Reliability, Maintainability and Safety, pp. 1133–1136, 2009.
[6] “IEEE Standard for Ethernet Redline,” IEEE Std 802.32018 (Revision of IEEE Std 802.32015) -Redline, pp. 1–8275, Aug. 2018.
[7] E. Upton and G. Halfacree, Meet the Raspberry Pi. John Wiley & Sons, Juli 2012.
[8] H. Zaijun, H. Fengchen, S. Jie, and C. Zhao, “An MVB signal capturer based on microcontrollers for metro train on-line health monitoring system,” in 2015 6th IEEE International Conference on Software Engineering and Service Science (ICSESS), pp. 255–258, Sep. 2015.
