EXAMENS ARBETE
Högskoleingenjör i Datorteknik, 180hp
Bokningssystem för laddstolpar
Richard Solti och Christoffer Lindström
Examensarbete, 15hp
Halmstad 2015-10-21
Sammanfattning
Projektet handlar om att utveckla ett bokningssystem för laddstationer för elbilar.
Målet är att skapa en prototyp som kan användas för att boka laddstationer och utnyttja bokningar.
Målet uppnås genom att kombinera en databas, webbplats, server och laddstationer så att de kommunicerar med varandra.
Resultatet av detta är ett öppet bokningssystem som kan anpassas för andra ändamål än bokning av laddstationer.
II
Förord
Vi vill säga ett tack till vår handledare Erik Hertz som har hjälpt oss med att få en struktur på denna rapport.
III
1 Inledning... 1
1.1 Bakgrund... 1
1.1.1 Liknande lösningar... 1
1.2 Syfte... 2
1.3 Mål... 2
1.4 Frågeställning... 3
1.5 Avgränsning... 3
2 Teori... 5
2.1 Systembeskrivning... 5
2.1.1 Webbplats... 5
2.1.2 Databas... 5
2.1.3 Server... 6
2.1.4 Simulation av Laddstation... 6
2.2 Mjukvaruprogrammering... 6
2.2.1 Objektorienterad programmering... 6
2.2.2 Procedurell programmering... 7
2.3 Webbplats... 8
2.3.1 Interaktiv karta……….. 8
2.3.2 Webbserver... 10
2.4 Databaser... 10
2.4.1 Databashanterare... 10
2.5 Server... 11
2.5.1 KlientServer förhållandet... 11
2.5.2 Flera samtidiga anslutningar... 11
2.5.3 Kommunikation... 12
3 Metod... 15
3.1 Webbplats... 15
3.1.1 Valet av webbplats framför mobilapplikation... 16
3.1.2 Leafletjs... 16
3.2 Databas... 16
3.3 Server... 16
3.3.1 Trådning... 16
3.4 Kommunikation... 17
3.4.1 Kommunikation mellan server och databas... 17
3.4.2 Kommunikation mellan server och laddstation... 17
3.4.3 Kommunikation mellan server och webbplats... 17
3.4.4 TCP... 17
3.5 Simulering av laddstation... 17
4 Testning... 19
4.1 Bokningssystemet... 19
4.2 Testerna på alla delsystem... 19
4.2.1 Tester på servern... 19
4.2.2 Tester på databasen... 19
4.2.3 Tester på simulationen av laddstation... 19
4.2.4 Tester på webbplatsen... 19
4.2.5 Dokumentation av tester... 19
IV
5 Resultat ... 21
5.1 Webbplats... 21
5.1.1 Registrering och inloggning... 23
5.1.2 Använding av kartan... 23
5.2 Simulering av laddstation... 24
5.3 Server... 26
5.3.1 Databasanslutning... 26
5.3.2 Klientanslutning... 26
5.4 Databas... 27
5.5 Bokning/hela systemet... 27
5.6 Laddning... 29
5.7 Analys... 29
5.7.1 Analys av tester... 29
5.7.2 Svar på frågeställningar... 30
6 Diskussion... 33
6.1 Delsystem... 33
6.1.1 Webbplats... 33
6.1.2 Databas... 33
6.1.3 Server... 33
6.1.4 Simulation av laddstation... 33
6.2 Projektets påverkan på samhället... 34
6.2.1 Miljöpåverkan... 34
6.2.2 Ekonomi... 34
6.3 Vidareutveckling... 34
6.3.1 Databas... 34
6.3.2 Webbplats... 34
6.3.3 Server... 35
6.3.4 Simulation av laddstation... 35
7 Slutsats... 37
8 Referenser... 39
Appendix ... 43
A Krav på systemet... 43
B Testspecifikation för generella krav... 44
B forts... 44
V
1 Inledning
Detta kapitlet beskriver bakgrund, syfte, avgränsning och metoder som användes för att genomföra examensarbetet.
Det här projektet är gjort i samarbete med utvecklingsingenjörerna Anna Ekelund och Eric Standár från Högskolan i Halmstad åt företaget Mutual Benefits som är belagda i Göteborg.
1.1 Bakgrund
De första elbilarna producerades runt 1880 [1,2] och var väldigt populära tills nya tekniker inom förbränningsmotorer upptäcktes på tidigt 1900talet. Populariteten avtog radikalt och elbilar slutade produceras redan vid 1920talet då bilar med förbränningsmotorer dominerade 99% av bilproduktionen [1,2]. Från och med sent 1990tal började elbilar återigen bli
populära för att nya batteritekniker upptäcktes och på grund av det ökande bekymret [1,2]
med ökande bränslepriser och växthuseffekten. Olika orter har även satt upp mål för elbilar, bland annat Stockholm som siktar på en fossilbränslefri stad vid år 2050 [3].
Flera biltillverkare lägger mycket resurser [4,5,6] på elbilar och därmed ökar även intresset för elbilar. Tävlingssporten Formel 1 [7] har även fått en elbilsversion där tävlande använder bilar som liknar en Formel 1 bil men körs enbart på elektricitet. Den nya sporten kallas Formel E [8]och den första säsongen startades i 2014. Den stora satsningen beror till viss del på rejält minskade batteripriser [9]. I Sverige, som till stor del använder förnybar energi [10], sker det en stor satsning på elbilar och infrastruktur för elbilar bland annat genom bidrag från staten [11].
Att ha en elbil kan även bli miljövänligare i framtiden eftersom det bidrar till ett oberoende av fossila bränslen, huvudsakligen i länder där vatten, vind och solkraft står för större delen av energiproduktionen. I sådana länder skulle utsläppet som personbilar orsakar minska då mindre mängder av fossila bränslen används. I andra länder, som använder främst kolbaserad elproduktion är det inte lika miljövänligt. Detta är på grund av att hela förloppet från råvara till el för elbilar kan ha en högre kostnad än produktionen av fossila bränslen[12]
Eftersom elbilar blir allt mer populära [13] så måste även infrastrukturen hänga med. Det finns alltså för få laddstationer i Sverige [13] och det är en möjlighet att en elbilsägare väljer att inte använda sin elbil på grund av oron att det inte finns möjlighet till att ladda elbilen [14].
1.1.1 Liknande lösningar
En tjänst som tillåter bokning av laddstationer finns inte i Europa. Liknande men ofullständiga lösningar finns däremot många av. Laddinfra.se [15] har en databas av alla laddstationer som har en intelligens i sig. Databasen används av många olika karttjänster i Sverige. Dessa karttjänster är bland annat Eniro [16] och Fortum [16].
I USA finns ChargePoint [17] som tillåter bokning av laddstationer. Systemet är fortfarande under utveckling och har endast ett fåtal laddstaioner som är bokningsbara. Förutom
bokningsbara stationer så finns även ickebokningsbara stationer med i ChargePoints system.
Personen som vill ladda hos en av ChargePoints laddstationer måste ha antingen ett
“ChargePoint Card” eller ChargePoints app på mobilen. Kortet fungerar så att användaren
Appen kan användas för att göra samma sak som kortet. ChargePoint har även lagt till laddstationer som inte är deras.
Det finns, precis som i Sverige, även andra karttjänster som visar laddstationer på en karta.
Karttjänsten från US Energy Department [18] är en sådan.
Denna karttjänst är inte begränsad till laddstationer för elbilar utan innehåller även bensinmackar, vätgasmackar mm.
1.2 Syfte
Syftet med bokningssystemet är att underlätta resor för elbilsägaren som vill resa längre sträckor med elbilen genom att erbjuda möjligheten att boka laddstationer.
Bokningsystemet är avsett att kunna standardisera och samla alla laddstationer i Sverige under ett och samma system. En standardisering innebär att elbilsägaren endast använder en typ av identifiering och betalning.
Norge har problem med att det är för få laddstationer för antalet elbilar och köer bildas på många ställen med laddstationer [14]. Samma problem är sannolikt att hända i Sverigen men förmodligen i mindre omfattning. Problemet reduceras till en viss mån genom att elbilsägaren kan planera sin resa i förväg och säkerställa att det kommer finnas en plats att ladda på.
1.3 Mål
Målet är att utveckla ett bokningssystem som nya laddstationer kan kopplas upp mot och som möjliggör bokning av redan uppkopplade laddstationer. Laddstationerna som är tillagda i systemet ska kunna bokas av en användare som har registrerat sig. Användare registrerar sig i systemet via en hemsida. Bokningssystemet ska vara öppet i den meningen att olika de i framtiden utvecklade applikationer för smarta mobiler kan fungera med bokningssystemet.
Bokningssystemet i sig ska inte ändras för att förut nämnda applikationer ska fungera.
Bokningssystemet är uppdelad i fyra delsystem.
De fyra delsystemen är:
● Webbplats
○ Webbplatsen låter användare registrera, logga in och visuellt interagera med bokningssystemet och utnyttja dess funktioner. Webbplatsen ska ha en interaktiv karta som låter användaren se laddstationer i Sverige, deras status och boka laddstationer. En “Min Sida” webbsida ska lista alla bokningar och även låta användaren avboka laddstationer.
● Databas
○ Databasen lagrar data som behövs för att bokningssystemet ska fungera.
Databasen lagrar bland annat information om laddstationernas fysiska koordinater, bokningar och användare. Bokningssystemet använder datan för inloggningar, bokning och diverse funktioner.
● Server
○ Servern hanterar all kommunikation mellan webbplatsen, databasen och laddstationerna som är registrerade i systemet. Hanterar även annan kommunikation som exempelvis förut nämnda applikationer.
● Simulation av laddstation
○ En enkortsdator som härmar en laddstation och använder visuella signaler för att indikera dess tillstånd.
De fyra delsystemens teori och genomförande kommer förklaras mer ingående under stycken Teori respektive Metod.
För att projektet ska ses som klart ska den uppfylla alla kraven som är nedskrivna i en kravspecifikation som är bifogad som Appendix A.
1.4 Frågeställning
Dessa frågeställningar har ställts på projektet. Frågeställningarna besvaras i Resultatdelen.
1. Hur kan en person identifieras när hen vill använda en bokad laddstation?
2. Är det möjligt att standardisera redan aktiva laddstationer så att de fungerar med bokningssystemet?
○ Vilket är bästa sättet att göra det på?
3. Vad innebär att systemet är öppet i avseendet att det kan användas till att boka annat än laddstationer?
○ Finns det en nivå för hur öppet ett system är?
○ Finns det nackdelar med att ett system är öppet?
4. Är en mobilvänlig hemsida bättre än applikationer för mobiler?
○ Nackdelar och fördelar med hemsida respektive applikation?
5. Vad gör ett bokningssystem färdig?
○ Vilka är de karaktäristiska funktionerna som gör bokningssystemet till ett bokningssystem?
6. Skulle man kunna göra ett bokningssystem utan en central server?
7. Hur kan en databas effektivt utformas för att lätt komma åt data?
1.5 Avgränsning
Saker som inte tas hänsyn till i det här projektet är:
● Design
Hemsidans design kommer att vara minimalistisk men annars läggs inte mer tid än nödvändigt på hemsidans design.
● Betalningsmetoder
Betalning och penninghantering kommer ingår inte i projektet.
● Säkerhet
Säkerhetsfrågor, exempelvis kryptering av data, ingår inte i projektet.
● Byggnad av laddstation
Byggnad av laddstation ingår inte i projektet.
● Begränsad till Sverige
Bokningssystemet är utvecklad med endast Sverige i tanken och därför kommer större hänsyn inte tas till andra länder.
● Kommunikationssätt för laddstationer
Eftersom det finns väldigt många olika sätt att kommunicera med laddstationer så antas det att laddstationerna kommunicerar med systemet via internet. Avgränsningen är då att
kommunikationssätt som inte är via internet iaktas inte.
● Utveckling av webbserver
En egen webbserver kommer inte att utvecklas utan befintliga program kommer att utnyttjas.
2 Teori
2.1 Systembeskrivning
En längre beskrivning av hur systemet är uppbyggt med avsikten att skapa en relevans för resten av Teoridelen.
Förklaring av systemet
Figur 2.1. Figuren visar hur delsystemen är kopplade med varandra. Ponera att webbplatsen behöver information som är lagrad i databasen. Webbplatsen måste då göra det via Servern.
Systemet består av fyra delsystem. Figur 2.1 visar hur de är i relation till varandra.
Webbplatsen kan endast komma åt information i databasen och laddstationerna via Servern.
Servern, som är en slags mellanhand, har en förbindelse med alla andra delsystemen.
Laddstationerna och webbplatsen skickar förfrågningar till servern och servern tillhandahåller dem. Dessa fyra delsystem är:
2.1.1 Webbplats
Webbplatsen är användarens verktyg för att interagera med systemet. Den är utrustad med en karta som visar laddstationerna. Dessa ska då gå att trycka på för att boka inom en önskad tidsram.
2.1.2 Databas
En databas krävs för att kunna lagra data som är långlivad. Data som lagras är användare, laddstationer och bokningar i så kallade tabeller. Eftersom data som lagras är relaterade till varandra så är det lämpligt att en relationsdatabas används för att lagra data. Databasens enda kommunikation i systemet är med Servern som manipulerar databasen.
2.1.3 Server
En anslutning till en databas är prestandakrävande att skapa [19]. Detta är på grund av att databasen bland annat reserverar minne för varje anslutning och dessa steg är tidskrävande.
Delsystemet “Server” är en central server som samlar alla anslutningar från laddstationer och webbplatsen till att använda en och samma databasanslutning.
2.1.4 Simulation av Laddstation
En laddstation kan efterliknas genom att programmera en enkortsdator till att härma en laddstations beteende.
Enkortsdatorn upprätthåller en anslutning till servern och begär information om dess status.
Olika visuella signaler används beroende på vad statusen är. Förutom att inte kunna ladda en elbil så uppför sig enkortsdatorn som en laddstation förväntas att uppföra sig. Detta delsystem är endast för demonstration som görs för att visa att bokningssystemet fungerar.
2.2 Mjukvaruprogrammering
För att utveckla ett program som är effektivt kodad så är det fördelaktigt att använda sig av en eller flera programmeringsmetoder. Endast två metoder, objektorienterad och procedurell programmering, tas upp då det finns från tidigare kunskaper inom dessa.
2.2.1 Objektorienterad programmering
Objektorienterad programmering [22] lämpar sig bäst när programmet hanterar stora mängder av data som är olika med har likadana egenskaper. Egenskaperna som skiljer sig åt kan sparas i instanser av en klass [23]. Ett exempel kan vara ett program som visar många bollar som studsar på skärmen.
Figur 2.6. Bollar som har olika färger och studshöjder
I figur 2.6 har bollarna egenskaper som är gemenesamma och egenskaper som inte är gemensamma.Alla bollar är runda, har samma storlek och samma hastighet. Alla bollar har olika färger, studshöjder, rör sig antingen upp eller ner och har olika höjdpositioner. En klass vars attribut är olikheterna och metod som uppdaterar bollen kan då skapas.
Figur 2.7. Exempel på hur en klass för en boll kan se ut
Alla bollar är då samlade, som i figur 2.7, under deras egna datatyp som heter “Ball”.
Objektorienterad programmering är väldigt unik med det att klasser kan ofta återanvändas i
andra program utan större ändringar och den tillåter även abstrahering och modularitet.
Detsamma gäller för klassen Ball som i andra program kan abstraheras till exempelvis
“BasketBall”, “FootBall” och “PingPongBall”.
Denna metod används främst när det finns många liknande ‘saker’ i programmet och programmeraren vill generalisera dessa ‘saker’. På så sätt slipper programmeraren skriva samma kod igen varje gång en annorlunda ‘sak’ läggs till i programmet. Om man substituerar
‘sak’ med ‘boll’ som använder koden som visas i figur 2.7 så behöver programmeraren endast ändra de fyra attributen som finns i figuren. Programmeraren slipper skriva metoderna
“DrawBall” och “MoveBall”.
2.2.2 Procedurell programmering
Kod som är strukturerad med klasser och funktioner men är inte objektorienterad kallas för procedurell [24]. I sådan kod är klasserna ofta statiska [25].
I samma exempel som i figur 2.7 hade en array skapats för varje attribut.
Figur 2.8. Exempel på hur koden i figur 2.7 kan se ut med procedurell programmering
Som det märks i figur 2.8 så blir koden genast svårare att förstå. Det finns inget som riktigt antyder att det är bollar som kodsnutten i figur 2.8 handlar om. Slutsatsen att det handlar om bollar kan inte dras utan kommentarerna i koden.
Statiska klasser och metoder (eller funktioner) i procedurell programmering används ofta endast för att strukturera koden. Funktionerna i klasserna är subrutiner som utför operationer på primitiva datatyper [26]. En subrutin kan exempelvis vara en funktion som omvandlar grader till radianer eller en funktion som räknar ut en rätvinklig triangelns hypotenusa.
Ett procedurellt program kan ses som en produktionslinje där de olika stegen av
produktionslinjen är subrutinerna. Procedurell programmering är lämplig då programmet ska utföra en process enligt löpandebandprincipen [27] eller liknande.
2.3 Webbplats
En webbplats består av en eller flera webbsidor som visas i en webbläsaren. Nästan alla webbplatser är skrivna i HyperText Markup Language (HTML)[28] som är en standard.
HTML kan dock användas i kombination med andra språk och metoder.
HTML bestämmer en webbsidas struktur och till en viss del innehållet.
Cascading Style Sheet (CSS) [29] kan användas för att generalisera strukturen för alla webbsidor så att de använder en och samma struktur. Eftersom innehållet som HTML kan visa är begränsad så måste andra metoder användas. Hypertext PreProcessor [30] (PHP) och Javascript [31] används vanligen ihop med HTML.
PHP används till att bestämma innehållet på en webbsida innan den laddas i webbläsaren.
Javascript används för att bestämma och ändra innehållet efter att webbsidan har laddats i webbläsaren.
JavaScript kan användas för att lägga till interaktiva moment eller animationer på webbsidan.
2.3.1 Interaktiv karta
Att skapa en interaktiv karta med funktioner och objekt kräver mycket arbete, för detta finns redan färdiga tjänster, bland annat Leafletjs [32] och Google Maps [33].
Exempel på funktioner som dessa tjänster bidrar med är kartan i sig men de bidrar även med markörer, former, zoom och drag funktioner. De populäraste karttjänsterna är Leafletjs, OpenLayers, Google Maps.
Leafletjs
Leafletjs är en gratis, opensource karttjänst som går att anpassa till smartphones och tablets och har stöd för HTML 5, CSS3 och är skriven i JavaScript vilket gör det enkelt att integrera på webbsidor.Tjänsten är skapad för att göra det enkelt att implementeras av utvecklare som inte har omattande kunskaper inom geografiska informationssystem [34].
Figur 2.9 visar hur en typisk karta byggd med Leafletjs kan se ut.
Figur 2.9. Exempel på en leafletjs karta med markör (blå i mitten) och popupfönster (vit ruta).
OpenLayers
Openlayers är en gratis, opensource karttjänst som liknar Leafletjs. Den är större och har fler fördefinierade verktyg vilket gör tjänsten mer flexibel men kan uppfattas som lite mer komplicerad.
Figur 2.10 visar hur en typisk karta byggd med OpenLayers kan se ut.
Figur 2.10. Exempel på en OpenLayers karta med ett popupfönster som visar Halmstads koordinater.
Google maps
Google maps är en annan karttjänst som kan användas gratis så länge webbplatsen inte används för att generera vinst eller har under 25000 besökare dagligen. Den är heller inte opensource vilket gör att programmeraren blir låst till Googles verktyg utan att kunna modifiera den så som programmeraren vill, oftast så vill man kunna modifiera och skapa egna verktyg och då är det ett hinder att det inte är opensource.
Användarvänligheten hos Google maps är mycket lägre då den har ett mer omfattande utbud av funktioner. Det gör att Google maps kan anses mycket svårare att integrera i webbsidor för.
Figur 2.11 visar hur en typisk karta byggd med Google Maps kan se ut.
Figur 2.11. Exempel på Google Maps API med markörer (röda nålar)
2.3.2 Webbserver
En webbläsare är en klient för webbservern [35]. Webbservern är en server för webbplatsen och används till att tillhandahålla webbsidor för webbläsaren. Innan en webbsida skickas till webbläsaren så läser webbservern av webbsidans kod och processerar PHPkod som finns i webbsidan. Efter det skickas webbsidan till webbläsaren för att visas för användaren.
2.4 Databaser
En relationsdatabas [36] används främst när olika typer av data har relationer till varandra. En sådan databas består av flera tabeller som är uppdelade i kolumner och rader. Figur 2.12 visar ett exempel på hur en tabell kan se ut.
Figur 2.12. Exempel på hur en tabell kan se ut. An tabell kan förstås ha fler kolumner och rader.
Data kan manipuleras i databasen med hjälp av språket Structured Query Language [37]
(SQL) som är ett standardiserat språk för relationsdatabaser. SQL använder deklarativ programmering [38] som innebär att koden specifierar vad resultatet ska vara istället för att specifiera hur något ska göras. En query är en kodrad som beskriver vad resultatet önskas vara som beskriver vad resultatet önskas vara. En simpel query är selectkommandot som hittar och hämtar data. Figur 2.13 visar några exempel på selectkommandot och vad för slags data en query med select hämtar. På vänster sida är tre olika queries. I mitten visas vilken tabell queryn skickas till och till höger visas resultatet.
Figur 2.13. Exempel på flera queries. Uppifrån neråt betyder dessa: Hämta alla rader där åldern är 26, Hämta alla rader där förnamnet är Doe, Hämta alla rader där förnamnet är Jane men visa endast ålder i de raderna.
Det brukar vanligtvis finnas en kolumn i tabellen som är den primära nyckeln för varje rad.
Nyckeln ska vara unik och kan användas till för att exempelvis hämta data från andra tabeller.
2.4.1 Databashanterare
En databashanterare är ett program som användaren kan bygga databaser med. Dessa program sköter allt ifrån installering av en server för databasen till manipuleringen av databasen.
De 3 mest populära databashanterarna är Oracle Database, Microsoft SQL Server och MySQL. Alla tre uppfyller till stor del samma funktion, vilket är att hantera databaser.
Oracle Database används främst av företag och är till för att hantera en objektorienterad relationsdatabas.
Microsoft SQL Server är en äldre relationsdatabashanterare som är utvecklad av Microsoft.
MySQL är en populär relationsdatabashenterare bland privata utvecklare och småprojekt som inte är monetiserad.
2.5 Server
En server är, i datakommunkationens mening, ett datorsystem som servar klienter över ett nätverk.
2.5.1 KlientServer förhållandet
Som konstaterat innan, så är det dyrt prestandamässigt att skapa en anslutning till databasen då databasen gör flera steg som exempelvis allokering av mycket minne. Servern är skapad för att samla alla anslutningar, som laddstationer och webbplatsen gör, och sedan använda en och samma anslutning med databasen för att hämta informationen som begärs via
anslutningarna.
En anslutning mellan servern och en laddstation eller webbplatsen kräver mindre resurser av datorn än en anslutning till en databas.
I ett klientserver förhållande så är det databasen som servar servern och servern är en klient för databasen. Alla andra anslutningar från laddstationer och webbplatsen är klienter för servern. Figur 2.14 illustrerar detta.
Figur 2.14. Visar förhållande mellan databas, server och laddstationer/webbplats.
2.5.2 Flera samtidiga anslutningar
Om servern ska hantera flera anslutningar samtidigt så snabbt som möjligt så är det fördelakigt att programmera in stöd för det. I C++ finns två sätt att uppnå detta. Den ena är funktionen select [39] och den andra är trådning [40].
Select
Select [39] är en funktion som kan inkluderas i programmet. Funktionen läser genom ett eller flera socket [41] objekt för att låta användaren kolla om det finns ett meddelande som har mottagits av klienterna. Funktionen fungerar endast för sockets.
En socket är ett objekt som beskriver en förbindelse mellan en klient och en server.
Trådning
Trådning [40] används i många program. Den används för att dela upp ett program så att olika delar kan processeras samtidigt. I serverns fall skulle trådning användas till att skapa en tråd för varje anslutning.
Svårigheterna med trådning är bland annat att de måste synkroniseras om de har använder en global variabel. Ett sådant problem kan illustreras med tankeexperimentet “Ätande Filosofer”
[42].
Figur 2.15 . De fem filosoferna kan ses som trådar och gafflarna är resurser, eller variabler, som används av trådarna/filosoferna som är bredvid.
Problemet är, kort skrivet, att varje filosof, eller tråd, kan endast arbeta vidare om den
använder både den vänstra och högra gaffeln, eller variabeln. Alla trådar tar den högra gaffeln först och detta resulterar i att alla gafflar blir tagna och alla filosofer väntar på att kunna ta gaffeln från vänster. Alla trådar fastnar då och väntar i all evighet.
2.5.3 Kommunikation
Servern kommer att kommunicera via internet och därför finns två dataöverföringsprotokoll att välja bland. Dessa är Transmission Control Protocol (TCP) [43] och User Datagram Protocol (UDP) [44]. Eftersom alla delsystem är beroende av varandra så måste de använda samma typ av kommunikation som servern.
TCP Transmission Control Protocol
TCP[43] används när pålitlighet prioriteras framför hastighet. En fil som överförs med TCP är garanterad att överföras felfritt mot kompromissen att det tar längre tid. På vänster sida av figur 2.15 illustreras hur TCP skickar samma data igen när den inte får en bekräftelse. Genom att bekräfta varje sändning så garanteras det att filen, eller det som skickas, kommer fram hel.
UDP User Datagram Protocol
UDP[44] används när snabbhet prioriteras framför pålitlighet. En fil som överförs med UDP går oftast snabbare än TCP men kompromissen är att filen som överförs saknar vissa delar. På högra sida av figur 2.16 illustreras hur UDP ignorerar att data inte kommer fram. “Data 3” blir förlorad, men UDP fortsätter med att skicka “Data 4”.
Figur 2.16. Figuren visar ett väldigt förenklad exempel på hur TCP skickar samma data igen om den inte får en bekräftelse och hur UDP inte bryr sig om att data förlorades.
3 Metod
När ett större system skapas så är det fördelaktigt att dela upp det i flera mindre delsystem.
Det underlättar arbetet och gör det även lättare att presentera systemet i sin helhet. Figur 3.1 illustrerar hur det här projektet är uppdelad i mindre system.
Figur 3.1. Figuren visar hur delsystemen är kopplade med varandra. Ponera att webbplatsen behöver information som är lagrad i databasen. Webbplatsen måste då göra det via Servern.
Servern är hjärnan av bokningssystemet och de andra kretsar runt servern. Detta är för att bokningssystemet skulle vara så öppet som möjligt. Ponera att kunden vill använda bokningssystemet till något annat än för elbilsladdstationer. Då sitter inte systemet fast i någon hemsida utan det är öppet att implementeras på ett annat håll utan att behöva skrivas om från grunden.
3.1 Webbplats
För programmering av webbplatsen finns endast ett alternativ. Det är HyperText Markup Language (HTML) [28] som är standarden för alla webbsidor och därför kommer HTML användas när webbplatsen skapas.
Webbplatsen är strukturerad med en kombination av HTML och CSS kod.
Webbplatsen har utvecklats i utvecklingsmiljön Aptana [45]. Det finns flera andra
utvecklingsmiljöer men av erfarenhet fungerar Aptana bäst för projektets ändamål på grund av dess inbyggda webbserver som bland annat tillåter att PHP filer kan exekveras direkt.
Webbplatsen är anpassad för att fungera på Google Chrome [46]. Anledningen är att Internet Explorer [47] inte alltid har haft stöd för alla nödvändiga funktioner till projektet.
Då webbplatsen endast är för att bevisa att bokningssystemet fungerar så är det acceptabelt att den inte en kompatibel med andra webbläsare än Google Chrome pga deras brister.
3.1.1 Valet av webbplats framför mobilapplikation
Det ansågs vara lämpligast att utveckla en hemsida då kunskap redan fanns om
hemsideskapande. Hemsidor går även att nås via både smartphones och datorer, medan mobilapplikationer ofta är begränsade till smartphones.
Hade en mobilapplikation skapats så hade fokus och tid behövts för att lära sig de olika operativsystemen som finns för smartphones och vad för språk respektive utvecklingsmiljö de använder sig utav. De olika försäljningstjänsterna har även olika avtal om vad som gäller för att sälja sin mobilapplikation.
3.1.2 Leafletjs
Leafletjs var det lämpligaste valet framför google maps och OpenLayers.
Eftersom LeafletsJS är ett mycket mindre bibliotek än OpenLayers så är det lämpligare.
Anledningen till att det är lämpligare att det är mindre är att webbplatsens karta endast ska visa var laddstationernas koordinater och status är och till detta skulle OpenLayers ta onödigt mycket plats. Det är främst i hänsyn till de kunder som använder smartphones.
LeafletJS är även lämpligare än Google docs då kunskap och erfarenhet om geografiska informationssystem system saknas. LeafletJS är enklare att förstå och det går snabbare att sätta sig in i.
Det som gör LeafletJS mest intressant är att det är både gratis och opensource vilket ger kartan potential till större flexibilitet.
3.2 Databas
Databashanteraren MySQL [48] valdes för projektet. MySQL tillåter hantering av relationsdatabaser och är färdigutvecklade verktyg för databashantering.
Valet att lagra all data i en färdig relationsdatabas istället för ett eget databassystem gjorde pga att MySQL har utvecklats med fokus på att lätt och snabbt kunna hantera en databas. Att lagra samma data i egna filer skulle kräva tid och fokus på att skapa en struktur för lagring och sedan ett sätt att manipulera data. Allt detta finns redan tillgängligt i MySQL.
3.3 Server
Servern som hanterar all kommunikation inom systemet har utvecklats med
utvecklingsverktyget Visual Studio Express 2013 [49]. Det fanns andra val men Express var redan tillgänglig. Servern är programmerad i C++ [50] för att även här fanns resurser tillgängliga från tidigare projekt och erfarenhet inom språket från tidigare. C# [51] eller Java [52] kunde ha använts likvärdigt men i det här fallet var C++ det snabbare valet på grund av redan tillgängliga resurser och bättre kunskaper inom språket. Programeringsmetoden som användes är till en stor del procedurell programmering [24] och liten del objektorienterad programmering [22]. Objektorienterad programmering användes endast till att strukturera koden i statiska klasser. Procedurell programmering är mest lämpad för servern då den endast arbetar med primitiva datatyper.
3.3.1 Trådning
För att servern ska kunna hantera flera anslutningar samtidigt så valdes trådning framför selectfunktionen. Båda metoder kunde ha använts likvärdigt men trådning var det smartare valet eftersom man får ut mer av att lära sig trådning då det kan användas till annat än bara datakommunikation.
3.4 Kommunikation
3.4.1 Kommunikation mellan server och databas
Databasen måste först acceptera serverns anslutning innan den upprättas. Servern skickar med ett inloggningsnamn och lösenord när den ansluter till databasen. Databasen kollar då om servern angav rätt info och antingen accepterar eller nekar anslutningen. Det är så här MySQL fungerar.
3.4.2 Kommunikation mellan server och laddstation
Då fysiska laddstationer som är kompatibla med bokningssystemet inte finns så gjordes antagandet att de kommunicerar med servern via internet med TCP. Andra metoder för laddstationen vore att använda telefonnätverket eller en radiofrekvens för att kontakta ett annat system. Detta “annat system” skulle kunna kontakta servern via internet och
vidarebefordra laddstationens meddelande. Det är delvis på detta sättet som systemet är öppet, genom att andra system kan kopplas till servern.
3.4.3 Kommunikation mellan server och webbplats
Webbplatsen kommunicerar med servern på samma sätt som exempelvis laddstationerna gör.
Servern har således ingen kännedom om att webbplatsen är en webbplats utan behandlar den som en vanlig klient. Det är webbplatsen som använder datan från servern för att visuellt presentera datan för användaren.
3.4.4 TCP
TCP används när servern kommunicerar med laddstation och hemsidan. Detta är på grund av TCPs egenskap att den kan garantera att det som skickas kommer fram utan någon förlust av data. Att kunna garantera att en laddstation är bokad eller ledig på hemsidan är en prioritet för att kunna ge hög kundservice. Samma sak gäller när en kund vill boka en laddstation, då måste systemet garanterat ha gjort en bokning och på rätt laddstation.
3.5 Simulering av laddstation
Enkortsdatorn som valdes är en UDOO [19, 20] för att den uppför sig som en vanlig dator och har en inbyggd programmerbar processor som kan användas för att manipulera de in och utgångar som är anslutna till den. Observera att simuleringen är en utgångspunkt för hur en laddstation förväntas att fungera.
Högskolan i Halmstad hade redan tillgång till UDOO [19,20] och därför valdes den.
Flera lampor och en switch har kopplats till UDOOn och dessa kan användas för att signalera användaren vad som händer.
UDOOs vanliga datordel användes till att skapa en klient som kan ansluta till servern.
Klienten hämtar statusen för laddstationen från servern och skickar vidare det till den inbyggda processorn. Den inbyggda processorn programmerades så att den tänder lampor i olika kombinationer, beroende på vad statusen är. När switchen switchas så skickar den inbyggda processorn en signal till klienten.
4 Testning
Beskriver hur testning är relevant, hur det utfördes, varför det utfördes som det utfördes och vad det betyder för projektet. Slutligen beskriv hur krav på bokningssystemet uppfylldes.
4.1 Bokningssystemet
● Bokningssystemet ska ha uppfyllt en kravspecifikation för att projektet ska anses vara klar. Dessa kraven är nedskrivna i en tabell i Appendix A.
4.2 Testerna på alla delsystem
Testning på delsystem gjordes så att in parametrar antogs vara rätt. Som ett exempel så testades en funktion i servern genom att funktionen anropades med parametrar som den förväntar. Då bokningssystemet endast arbetar med data som är hämtad från databasen så är det osannolikt att de olika delsystemen får felaktig data. Användare av systemet, dvs personer som använder webbplatsen, ser endast sådan information som kommer från databasen.
4.2.1 Tester på servern
Det fanns två olika typer av tester som utfördes på servern. Den första typen var små löpande tester för funktioner och dylikt i programkoden. Dessa små tester gjordes genom att
funktioner anropades med olika parametrar och sedan felsöktes funktionen om det behövdes.
De olika parametrarna var bland annat funktionens förväntade parametrar och även parametrar som inte är rätta.
4.2.2 Tester på databasen
Det var inte möjligt att testa databasen då MySQL är i princip ett program som installeras på datorn.
Tester som är relaterade till databasen, som exempelvis tester för servern, kontrollerades genom MySQLs egna grafiska användargränssnitt som man kunde enkelt kontrollera om data har lagts till eller tagits bort från databasen.
4.2.3 Tester på simulationen av laddstation
Eftersom simulationen, använder lampor för att indikera dess status så kunde samma visuella indikatorer användas till att testa och felsöka kod.
4.2.4 Tester på webbplatsen
Tester på webbplatsen skedde på samma vis som för simulationen av laddstation, men med popup fönster istället för lampor.
4.2.5 Dokumentation av tester
Dokumentering har endast skett då testningen gjordes för krav på projektet.
Ett integrationstest gjordes efter tester på delsystemens krav. Integrationstestet innebär att generella krav testas. De generella kraven som finns beskrivna i Appendix A är krav som kan endast testas då alla delsystemen är klara eftersom generella krav innefattar kraven för delsystemen. Testerna som gjordes för generella krav kan läsas i Appendix B.
5 Resultat
I resultatkapitlet samlas de resultat, som uppnåtts med de metoder som beskrivits tidigare.
Även frågeställningarna i Inledning.
5.1 Webbplats
Webbplatsen är registrerad på domänen ecgocharge.tk och på denna kan en användare registrera sitt konto, boka en laddstation på kartan och se över sina bokningar.
Figur 5.1 visar hur hemsidan ser ut med karttjänsten och figur 5.2 visar hur sidan ser ut där man kan se över sina bokningar.
Figur 5.1. Webbplatsens hemsida tar dig direkt till kartan som visar var laddstationer finns. I det här exemplet så finns det en laddstation där den gröna cirkeln markerar. Klickar användaren på cirkeln så får användaren välja tid och datum för en bokning.
Figur 5.2. Webbplatsens “Min sida” tar användaren till en sida där användaren kan se över dina bokningar i en tabell och där den också ger användaren möjlighet att avboka en laddstation eller aktivera en laddstation när användaren är vid stationen vid sin bokade tid för att autentisera sig.
Webbplatsen kommunicerar med servern med hjälp av TCP. Figur 5.3 visar med en enkel bild hur kommunikationen sker med alla delarna.
Figur 5.3. Figuren visar enkelt hur processen sker för hela kommunikationskedjan när man interagerar med
kartan.
5.1.1 Registrering och inloggning
För att en användare ska kunna använda funktioner som att hitta stationer på kartan, boka eller avboka en laddstation så måste personen registrera sig på webbplatsen. Registreringen går till på så sätt att användaren skriver in tre uppgifter, visningsnamn, namn som personen vill logga in med och lösenord. När denne är registrerad så tas den automatiskt till den inloggade varianten av sidan där loginfunktionerna är borttagna och ersatta med en logga utknapp.
5.1.2 Använding av kartan
För att kunden ska kunna boka en laddstation så finns det en interaktiv karta på en av webbsidorna på webbplatsen. Efter att användaren har zoomat in på rätt nivå så ska webbsidan visa laddstationer inom en viss radie. Dessa laddstationer är markerade med färgerna grön, gul eller röd för att visa användaren om stationen är ledig, bokad inom närmaste timmen respektive bokad eller upptagen.
När användaren har bestämt sig för vilken station denne vill ha och klickar på dess markör så kommer ytterligare information om stationen upp så som koordinater. Detta är en mall som ska utökas med gatunamn, ägare och energikälla. Användaren får även välja tidsramen för bokningen.
Hemsidan är ett instrument för att visa att bokningssystemet fungerar. Fler verktyg och funktioner kommer att implementeras och säkerheten av behandlingen av konton kommer att förstärkas.
5.2 Simulering av laddstation
Simulering av laddstation sker med en UDOO, fyra leds och en switch.
Figur 5.4. Figuren visar enkelt hur processen sker för kommunikationskedjan från servern, till ARM processorn som tänder/släcker lampor.
UDOOs datordel skapar en klient som ansluter till servern. Klienten hämtar närmsta bokningstid från servern och använder sedan tiderna för att räkna ut vilket tillstånd den befinner sig i. Den kan befinna sig i 5 olika tillstånd som är:
● Ledig, första bilden i figur 5.5
○ Laddstationen kan användas fritt för att ladda bilen.
● Bokad inom en timme, andra bilden i figur 5.5
○ Samma som “Ledig” men indikerar att det finns en bokning inom en timme.
● Bokad, tredje bilden i figur 5.5
○ Laddstationen är bokad och kan inte användas
● Bokad & Aktiverad, fjärde bilden i figur 5.5
○ Laddstationen är bokad och kan användas eftersom användaren som gjorde bokningen har aktiverat den.
● Upptagen & Laddar, femte bild i figur 5.5
○ Laddstationen används till att ladda en elbil.
Figur 5.5. Från vänster: Ledig, Bokad inom en timme, Bokad, Bokad och aktiverad, Upptagen och Laddar
Hur tillstånden ändras visualiseras i figur 5.6.
Figur 5.6. Bubblorna respresenterar tillstånden och pilarna visar hur tillstånd kan ändras.
5.3 Server
Server hanterar kommandona som skickas från webbplats och laddstation och använder sedan parametrarna som den får därefter. Beroende på vilka kommandon den får så skickar den olika meddelanden till databasen. Databasens svar skickas sedan till klienten som gjorde begäran.
5.3.1 Databasanslutning
Anslutningen till databasen sker via ett av MySQLs bibliotek som heter Connector/C++ [53]
som är till för att kunna ansluta till och hantera en MySQL databas. Koden för
databasanslutning är kapsulerad i sin egen statiska klass som heter Connector. Klassen har två funktioner: Init och Query.
Funktionen Init initialiserar anslutningen så att servern blir uppkopplad mot databasen.
Funktionen Query skickar ett querymeddelande till databasen som sen även tar emot svaret från databasen.
Svaret från databasen är lagrad i en datatyp som heter ResultSet [54] som är inkompatibel med de andra delsystemen. På grund av inkompatibeliteten måste ResultSet formateras till en annan datatyp som de andra delsystemen känner till och det är en sträng [55].
ResultSet använder en struktur med rader och kolumner. Varje kolumn i varje rad måste läsas från ResultSet för att formatera till en sträng. Eftersom en sträng är endast en samling av karaktärer så saknar den en struktur som efterliknar rader och kolumner. För att lösa det så måste specialtecken användas för att åtskilja rader och kolumner. Tecknena “ “ (mellanslag) och “\n” (radbrytning) används för att åtskilja kolumner respektive rader.
Figur 5.7 visualiserar hur ResultSet kan se ut och den formaterade strängen till höger.
Algoritmen läser först in värdet av Kolumn 1 i Rad 1, sedan Kolumn 2 i Rad 1 och så vidare tills alla kolumner har blivit lästa. När alla kolumner är lästa så görs samma procedur igen med nästa rad.
Figur 5.7. <R1 K1> är värdet av Kolumn 1 i Rad 1. Till höger visas den formaterade strängen.
Strängen returneras sedan tillbaka till den funktion som anropade Query.
5.3.2 Klientanslutning
Klientanslutningen är en samlingsnamn för alla anslutningar som kommer från laddstationer och webbplatsen. Det som ansluter till servern ses alltid som en klient och en tråd [36] skapas för varje klient för att fler än en klient ska kunna ansluta. En klient förväntas skicka
kommandon tillsammans med de parametrar som behövs. Det är ett krav att alla anslutningar sker med TCP eftersom det är viktigt att begäran och svar från och till klienten är felfri.
Varje klientanslutning består av två delar, dessa är tråden och kommandohanteraren.
