Mobilt övervakningssystem System för internetkommunikation mellan sensorer, webbsida, server och databas

(1)

MITTUNIVERSITETET

Institutionen för informationsteknologi och medier (ITM) Examinator: Dr. Ulf Jennehag, ulf.jennehag@miun.se Handledare: Dr. Ulf Jennehag, ulf.jennehag@miun.se Författare: Ingela Stålberg ingela.stalberg@stalrose.de

Utbildningsprogram: Internetbaserat data- och elektroingenjörsprogram, 180 hp Omfattning:7357 ord inklusive bilagor

Datum: 2012-12-19

Examensarbete inom Datateknik GR (C) 15 hp

Mobilt övervakningssystem

System för internetkommunikation mellan sensorer, webbsida, server och databas

Ingela Stålberg

(2)

Mobilt övervakningssystem ‐ System för internetkommunikation

Sammanfattning 2012‐12‐19 mellan sensorer, webbsida, server

och databas Ingela Stålberg

Sammanfattning

Detta projekt har utförts i samarbete med ett företag som utvecklar mobila sensorplattformar. Sensorerna sänder sina mätvärden till en server genom internet. Mätvärdena ska sparas i en databas och bevakningen ska styras genom en webbsida. Projektets syfte har varit att utveckla detta system och implementera en server med databas, en webbsida och ett klientprogram som simulerar sensorsignalerna.

Dessutom skulle serverns prestanda mätas och ett användartest genomföras. För att mäta prestandan användes olika varianter av klient‐

programmet som kontinuerligt skickade data från ett ökande antal klienter till servern. I användartesten fick testpersonerna lösa ett antal uppgifter och sedan besvara en enkät och bli intervjuade. Resultatet blev ett kommunikationssystem som fungerar enligt kraven och ett klientprogram som även används för att testa servern. Undersökningen av serverns prestanda visade att den maximala bandbredd var cirka 370 kb/s vid upp till 70 klienter. Vid ökande klientantal sjunker bandbredden. Hantering av databasen utgjorde den största tidsåtgången för servern. Vid användartestet fann de tekniskt utbildade webbsidan enkel och logisk, medan de andra hade lite svårigheter i början. För denna applikation fungerade en trådad server bra, men om projektet ska vidareutvecklas i större skala bör en asynkron server användas.

Skrivning av data till databasen (MySQL) bromsade bandbredden betydligt och där bör det om möjligt optimeras.

Nyckelord: server, client, Java, socket, MySQL, threads.

(3)

Abstract 2012‐12‐19 mellan sensorer, webbsida, server

Abstract

This thesis has been carried out in cooperation with a company which develops mobile sensor platforms. The sensors measure different types of data such as temperature, pressure etc.. They will communicate through the internet with a server that stores data in a database. This system will be controlled and monitored through a web page. The projectʹs aim has been to develop this system and to implement a server, a database, a website and a client application that simulates sensor signals. In addition, the performance of the server should be measured and a usability test should be performed. To measure the performance of the server, different variants of the client program, which continuously sent data from an increasing number of clients to the server, were developed. In the usability test the participants had to solve a number of tasks after which they answered a survey and were interviewed.The result is a communication system that works according to the requirements and a client program that is also used for testing the server. The investigation of the server performance showed a maximum bandwidth of about 370 kb/s while serving up to 70 clients. The database consumed 95% of the bandwith. However, with a rising number of clients there was a continous decline in the performance. In usability tests, there was a big difference in how people perceive computer programs depending on their experience and education. For this application, the server worked well, but if the project is to be developed into a large scale, it then becomes relevant to move onto an asynchronous working server instead of a thread‐server. Queries to a database (MySQL) considerably decreases bandwidth and should be optimized where possible.

Keywords: server, client, Java, socket, MySQL, threads.

(4)

Mobilt övervakningssystem ‐ System för internetkommunikation mellan sensorer, webbsida, server och databas Ingela Stålberg

Förord 2012‐12‐19

Förord

Tack till alla som bidragit till framgången med projektet:

Företagaren och uppdragsgivaren Per‐Olov Thorén och projektgruppen:

Joanna Lilliequist, Mattias Gaunitz och David Stübner har varit mycket hjälpsamma och positiva under projektets utveckling. Det var trevligt att delta i fredagsmöten och intressant att se hur det går till när en idé utvecklas till ett företag.

Dr. Rüdiger Lincke (vd Softwerk, Växjö) har givit bra tips angående programmet och webbsidan. Detlef Plehn har givit proffessionella råd angående databasen. Jan‐Erik Derr och Eva Gamberg Axelsson ställde upp som testpersoner i användartestet.

Även handledare och examinator dr. Ulf Jennehag vill jag tacka för handledning via e‐post.

(5)

Innehållsförteckning 2012‐12‐19 mellan sensorer, webbsida, server

Innehållsförteckning

Sammanfattning... ii

Abstract ...iii

Förord ... iv

Innehållsförteckning...v

Terminologi... vii

Förkortningar... vii

1 Inledning ...1

1.1 Bakgrund och problemmotivering ...1

1.2 Övergripande syfte ...2

1.3 Avgränsningar...3

1.4 Konkreta och verifierbara mål ...3

1.5 Översikt ...4

2 Teori...5

2.1 MD5...5

2.2 Iterativ programutveckling ...5

2.3 Vattenfallsmodellen...5

2.4 MVC – Model View Control...6

2.5 Relationsdatabas ...7

2.6 Normalisering av databas...7

2.7 SQL Injection attack ...8

2.8 Bandbredd för server...8

2.9 Internet of Things (IoT) ...8

2.10 Definition av termer och förkortningar ...8

3 Metod...9

3.1 Metod för användartesten ...9

3.2 Metod för servertesten ...10

4 Konstruktion...13

4.1 Kravspecifikation ...13

4.2 Algoritmer...15

4.2.1 Lösningförslag för servern 15

4.2.2 Lösningsförslag för simulator – programmet ‐ klienten 16

4.2.3 Databasen 17

4.2.4 Webbsidan 18

(6)

Innehållsförteckning 2012‐12‐19

5 Resultat ...19

5.1 Resultat av enkät ...19

5.2 Resultat av prestandatest för servern...20

6 Slutsats ...22

6.1 Kritisk granskning av resultaten...23

6.2 Förslag på vidare utveckling av systemet ...25

Källförteckning ...27

Bilaga A: Användarhandledning ...29

Bilaga B: Diagram från undersökningar av serverns bandbredd...31

Bilaga C: Dokumentation av egenutvecklade program...34

Flödesschema för webbsidan ...34

Webbsidans användargränssnitt ...35

Flödesschema för servern (förenklad version) ...37

Användargränssnitt för klientprogrammet ...38

Bilaga D: Databasens organisation...39

Bilaga E: Resultat av enkät ...40

(7)

Terminologi 2012‐12‐19 mellan sensorer, webbsida, server

Terminologi

Förkortningar

ACK Acknowledge är en kvittering av ett korrekt överfört meddelande.

GUI Graphical User Interface är ett grafiskt användargränssnitt.

IoT Internet of Things är internetkommunikation mellan föremål.

LAN Local Area Network är ett mindre datornätverk som oftast håller sig inom samma byggnad.

MD5 Message‐Digest algorithm 5 är en kryptografisk hashfunktion.

MVC Model View Control är en designmodell för dataprogram.

SQL Structured Query Language är ett programspråk för databaser.

SSL Secure Sockets Layer är en säkerhetsmekanism för krypterad datakommunikation.

TCP Transmission Control Protocol är det vanligaste dataöverföringsprotokollet som används för internet‐

kommunikation.

WAN Wide Area Network är ett större datornätverk, till exempel Internet .

(8)

1 Inledning 2012‐12‐19

1 Inledning

Internetkommunikation mellan föremål, så kallat ‐ ʺInternet of Thingsʺ blir allt mer utbrett i samhället. Det blir vanligt att kommunikations‐

funktioner integreras i föremål. Genom att även den mobila internet‐

kommunikation blir snabbare och bättre genom utbyggnaden av 3G‐

och 4G‐näten öppnas nya möjligheter för kommunikation mellan portabla objekt. Företaget där projektet genomförs vill skapa en applikation som kan inordnas inom denna teknik: mobila sensoranläggningar som kommunicerar genom trådlöst internet.

I detta arbete beskrivs uppgiften att skapa en modell/prototyp av ett internetbaserat kommunikationssystem där mobila sensorgrupper skickar mätvärden till en server. Servern ska spara inkommande data i en databas och reagera vid larmsituationer då något mätvärde överskrider en förinställbar gräns. Användaren ska följa kommunikationen och styra sensorerna genom en webbsida som visar förloppet av inkommande information direkt från databasen.

1.1 Bakgrund och problemmotivering

ʺInternet of Thingsʺ – kommunikation mellan föremål är ett nytt teknikområde som samhället redan idag använder med stor acceptans.

Denna typ av kommunikation kan stödja samhällets utveckling genom att användas inom det allmänna och privata livet ‐ t.ex. brandskydd, larm inom äldrevård, lokalisation av nödställd, livsmedelförvaring (temperatur, lagernivå), logistik (miljövinst genom optimering av körsträckor) m.m. Nackdelen med detta kan vara en utveckling mot ett övervakningssamhälle med intrång i människors privatsfär. Det gäller därför att använda denna teknik ansvarsfullt.

(9)

1 Inledning 2012‐12‐19

Det innebär bl.a. tekniska förutsättningar och lagstiftning som förhindrar/begränsar möjligheter till felaktig användning av ʺInternet of Thingsʺ liksom kriminella syften.

Uppdragsgivaren hade sedan flera år funderat över hur sensorer skulle kunna användas vid övervakning av speciella arbetsmiljöer¹. Utvecklingen av ʺInternet of Thingsʺ öppnar idag möjligheten att realisera detta övervakningssystem med användning av mobilt internet.

Idén bestod av en utrustning för mobila sensorgrupper för teknisk bevakning. Sensorerna ska skicka data genom trådlöst internet och följas och styras genom en webbsida. Den praktiska nyttan för dessa tillämpningar kan exempelvis vara att ett företag kan placera en sensorgrupp i ett bevakningsområde och styra och följa bevakningen från sitt kontor. Detta kan avsevärt minska kostnader för företaget genom att det sparar in på personal. En konstruktiv användning av detta system skulle kunna förhindra eldsvådor, förhindra inbrott, förebygga vattenskador och varna vid fel temperatur i kylsystem.

1.2 Övergripande syfte

Syftet med projektet är att skapa ett system för internetkommunikation mellan mobila sensorenheter och en server. Sensorerna sänder data som servern ska spara i en databas. Kommunikationsdelen för sensorerna är ännu inte konstruerad och därför ingår även i projektet att skapa ett klientprogram som simulerar sensornas signaler. Vidare ska en webbsida skapas därifrån användaren har åtkomst till databasen och servern. Fokus läggs på att åstadkomma en första prototyp för detta kommunikationssystem mellan server – klient – databas – webbsida.

Systemet ska kunna byggas vidare och det ska kunna läggas till fler funktioner när de första testkörningarna har bedömts. Därför ska koden vara uppbyggd så att det ska vara lätt att senare genomföra förändringar i programmet.

1 beskrivs inte närmare p.g.a. sekretessavtal

(10)

1 Inledning 2012‐12‐19

En undersökning av serverns prestanda och gränser avseende förhållandet bandbredd/antal klienter med eller utan lagring av data i databasen skulle genomföras. Vilka faktorer som belastar serverns prestanda och om dessa kan optimeras är frågor som undersökningen förhoppningsvis ska ge svar på. Har en trådad server tillräcklig kapacitet och var finns begränsningen?

För webbsidan och simulationsprogrammet fokuseras på användar‐

vänlighet. Därför genomförs ett användartest. Kan vem som helst intuitivt använda applikationer eller krävs inledande anvisningar?

1.3 Avgränsningar

Undersökningen är avgränsad till att testa servern i LAN med 100Mb hastighet. Datorn har processorn Via Eden 1200MHz 1,20GHz 960MB RAM och operativsystemet Microsoft WINDOWS XP (32bit). Serverns prestanda gäller endast under dessa förhållanden. Säkerhetsfunktioner för användning i WAN är inte implementerade i programmen (men finns förberedda att läggas till senare). Systemet ska tills vidare endast användas i LAN för tester av sensoranläggningar.

1.4 Konkreta och verifierbara mål

Konkreta mål för projektets utförande är följande:

Programmen som ska implementeras:

1. Skapa en server som tar emot data från klienter/sensorer, kontrollerar data och sparar i en databas och sänder alarm till andra klienter vid larmsignal.

2. Skapa ett klientprogram som simulerar en sensorgrupp med fyra sensorer som skickar data till serven. I detta program ska ett användargränssnitt (GUI) finnas där användaren kan reglera signaler/data som sändes.

3. Skapa en webbsida där kunder och administratörer kan logga in sig och följa övervakningen genom kontakt med databasen.

4. Skapa databasen där servern sparar data från sensorerna och där kunddata, användardata m. fl. läggs in genom webbsidan.

5. Skapa olika versioner av klient‐ och serverprogram för att testa serverns prestanda.

(11)

1 Inledning 2012‐12‐19

Två olika undersökningar ska utföras:

1. Undersöka användarvänligheten hos systemet genom att göra ett användartest för simulationsprogrammet och webbsidan.

2. Undersöka serverns prestanda: Undersökningen ska testa servern när ett antal klienter kontinuerligt skickar en viss mängd data.

Servern ska spara dessa data i databasen och därefter skicka svaret ʺACKʺ till klienten. Testen ska visa hur mycket data som servern maximalt kan ta emot per sekund – dvs. bandbredden.

En uppskattning ska eventuellt göras över hur många klienter som servern kan vara uppkopplad mot maximalt utan att prestandan påverkas negativt genom context‐switching (kontext‐

växling) mellan trådarna [1]. Testerna bör också visa vilka delar av programmet som belastar servern mest och som kan optimeras.

1.5 Översikt

I kapitel 2 förklaras den teoretiska bakgrunden till funktioner som systemet innehåller. I kapitel 3 beskrivs metoderna för att undersöka servens prestanda och göra användartestet. Kapitel 4 återger konstruktionen av programmen och databasen. I kapitel 5 redogörs för resultat av systemets implementation, användartesten och undersökningen av servens prestanda. I kapitel 6 återges slutsatserna av resultaten.

(12)

2 Teori 2012‐12‐19

2 Teori

2.1 MD5

Message‐Digest Algorithm 5 (MD5) är en allmänt använd kryptografisk hashfunktion som genererar ett 128‐bitars hash‐värde (checksumma) av ett godtyckligt meddelande. Den 128‐bitars MD5 hashkoden brukar anges som ett 32‐siffrigt hexadecimalt tal. MD5 kan användas för att kontrollera integriteten hos ett meddelande. Sändaren skickar då meddelandet samt hashkoden i MD5 och mottagaren beräknar även hashkoden för meddelandet. Får mottagaren samma resultat som sändaren visar det att meddelandet var korrekt. [2]

2.2 Iterativ programutveckling

Ordet iterativ kommer ursprungligen från matematiken och betyder upprepning. Vid iterativ utveckling följs en upprepande process.

Inledningsvis tas en vision fram över systemet som ska utvecklas, och därefter sker regelbundet möten för analys, design, utvärdering och återkoppling. Mellan varje möte implementeras ett fungerande program eller en fungerande del av ett system. Största delen av tiden finns det därmed ett fungerande program som med tiden byggs ut. Vid varje möte bedöms det hittills åstadkomna resultatet och systemkraven kan därefter modifieras och anpassas. Sedan sätts mål för nästa möte. Först när kraven börjar realiseras och presenteras kan användarna bättre förstå vad de egentligen behöver och under hela utvecklingstiden kan de förändra sin specifikation. Vattenfallsmodellen innebär däremot att programmet utvecklas bitvis och först i slutet kan resultatet testas. [3]

2.3 Vattenfallsmodellen

Traditionellt var vattenfallsmodellen tidigare en vanlig utvecklings‐

modell för systemutveckling. Metoden är mer än 30 år gammal. Enligt vattenfallsmodellen gäller följande: Först görs en analys. Problemet undersöks och kraven bestäms, och därefter kommer designfasen; en teknisk lösning utformas och till slut följer konstruktion; systemet realiseras i kod. Nackdelen med metoden är att det är omöjligt att återgå till en fas eller ändra kraven under utvecklingens gång. Det kan även hända att omvärlden förändras under tiden och därigenom behöver kraven ändras men detta blir då svårt och tidskrävande. [4]

(13)

Mobilt övervakningssystem ‐ System för internetkommunikation mellan sensorer, webbsida, server

2 Teori 2012‐12‐19 och databas Ingela Stålberg

2.4 MVC – Model View Control

MVC är ett design‐mönster som indelar ett program är i tre olika delar:

model, view och controller. Se figur 2.1.

Figur 2.1: MVC‐pattern [5]

MVC skiljer logiken från det grafiska gränssnittet (GUIn) vilket gör det enklare att ändra en av delarna utan att påverka de andra. Idén med MVC innebär att dela applikationen i tre delar som kan bytas ut utan att påverka varandra.

• Model innehåller data och logik för att ändra data. Modellen kan delas av olika view och control objekt.

• View presenterar datan från modellen ‐ vanligtvis på bildskärmen.

(14)

2 Teori 2012‐12‐19

• Controller innehåller alla funktioner som styr programmet. Den känner av användarens interaktion, t.ex. musklick i view och ger återkoppling till modellen, vanligtvis genom att data ändras.

När MVC design modell används blir det enklare att senare genomföra ändringar i en del av programmet utan att påverka en annan del.

Logiken är separerad från GUIn (Graphical User Interface) och Controller är som en styrenhet som känner av GUI och ger instruktioner till Model. Initialt kräver MVC lite extra planering och kodning, men de långsiktiga fördelarna är väl värt det.

De olika delarna har i genomförandet av MVC‐mönstret oftast endast referenser till de andra delarna. En View‐klass har t.ex. ingen direkt åtkomst till objekt i Model‐klassen.

Oftast implementerar View‐klassen interfacet Observer och Model‐klassen ärver Observable, så att när data ändras i modellen observerar View‐

klassen ändringen och uppdaterar data på skärmen. [5][6][7]

2.5 Relationsdatabas

Enligt Svenska Wikipedia [8] är en databas en samling information som är ordnad på ett systematiskt sätt så att det är lätt att finna och hämta enskilda bitar information, samt ofta även att ändra informationen. En relationsdatabas består strängt taget av tabeller. Tabellerna binds samman av relationer och restriktioner vilket ger en strukturerad mängd information. MySQL är t.ex. en populär relationsdatabas som är gratis.

[9]

2.6 Normalisering av databas

Normalformer och normalisering av relationsdatabaser används för att strukturera databasen så att den blir effektiv. Därmed avlägsnas redundans och oönskade bieffekter, till exempel att data måste lagras dubbelt. Oftast leder normalisering till att tabeller delas upp i flera mindre tabeller. [10]

(15)

2 Teori 2012‐12‐19

2.7 SQL Injection attack

SQL Injection Attack innebär manipulation av en databas genom att skicka strängar som innehåller skadlig kod istället för data till databasen. Koden kan sedan utföra olika oönskade operationer. Den kan t.ex. radera data eller låta någon logga in sig som superuser. [11]

2.8 Bandbredd för server

I sammanhanget data och internet avser bandbredden summan av data som transporteras över ett nätverk under en viss tid. Det kan även kallas trafik. Ofta anges bandbredden i kb/sek = kilobit/sekund och i vilken riktning data överförs. Upload betecknar dataström som går från den egna datorn till en främmande dator. Download betecknar dataström som går till den egna datorn. [12]

2.9 Internet of Things (IoT)

ʺSakernas Internetʺ (IoT) är en integrerad del av framtidens Internet. Det kan definieras som en dynamisk global nätverksinfrastruktur där fysiska och virtuella föremål har identiteter, fysiska attribut och virtuella personligheter. Dessa IoT‐saker kan interagera och kommunicera med varandra och omgivningen genom att utbyta data. Samtidigt kan de reagera självständigt på händelser i den fysiska världen och skapa tjänster med eller utan medverkan av människor. Interaktioner med dessa föremål kan ske genom Internet. [13]

2.10 Definition av termer och förkortningar

Ett kit betecknar i den här uppsatsen en grupp sensorer/detektorer som samarbetar och är uppställda inom samma område. De startas och stoppas gemensamt. Detektorerna i samma grupp är numrerade 1‐4.

Om en detektor slår larm utlöses akustiskt och optiskt larm i alla andra detektorer i gruppen.

(16)

3 Metod 2012‐12‐19

3 Metod

3.1 Metod för användartesten

Användartesterna har genomförts med sex personer i Växjö 2012‐09‐21.

Personerna har olika bakgrund avseende utbildning, arbetslivserfarenhet och ålder. Urvalet av testpersonerna skedde genom att personer som tillfälligt befann sig på arbetsplatsen tillfrågades, men samtidigt skedde ett urval för att få personer med olika bakgrund. Två experter ingick i testgruppen – de var uppdragsgivare och hade definierat systemkraven. Se tabell 1.

Tabell 1: Försökspersoner

Ålder kön yrke

45 man systemutvecklare

54 kvinna affärsutvecklare

60 kvinna barnmorska ‐ företagare 42 man egen företagare, tekniker

33 man montör, tekniker

40 man affärsutvecklare, f.d. tekniker

Testpersonerna skulle utföra följande uppgifter:

1) Starta webbsidan xxx.

2) Registrera sig själv som användare 3) Logga in som administrator med

username=xxxxx password=xxxxx

4) Koppla ett kit till sig själv som användare.

(17)

3 Metod 2012‐12‐19

5) Lägga till en ny kund i databasen.

6) Lägga in ett nytt kit i databasen och välja kunden som ägare till kitet.

7) Prova att se olika listor i databasen.

8) Starta detectorsimulatorn och ange namnet på ditt detectorkit 9) Starta alla fyra detektorerna och kör dem en stund, ändra under

tiden data som skickas .

10) Stoppa detektorerna och stänga fönstret.

11) Gå tillbaka till internetsidan mobilAdmin igen.

12) Logga in som användare med det tidigare skapade lösenordet och användarnamnet.

13) Se efter vilka data från detektorn som har sparats i databasen under körningen.

Som hjälp fick de använda användarmanualen i bilaga A. Efter att de utfört dessa uppgifter fick de svara på en enkät med flervalsfrågor om hur de hade upplevt testkörningen. Inspiration till testfrågorna kom från WAMMI [14]. Sedan blev testpersonerna enskilt intervjuade och fick med egna ord besvara följande tre frågor:

• Vad är det bästa med webbsidan och simulationsprogrammet?

• Vad är det sämsta?

• Har du några förslag till förbättringar av programmen?

3.2 Metod för servertesten

För att kunna mäta bandbredden behövs flera klienter som parallellt sänder data till servern snabbare än vad servern kan ta emot data. För denna uppgift ändrades simulationsprogrammet till ett automatiskt testprogram. Programmet testade hur många meddelanden som kunde skickas till servern per sekund ifrån klienterna och sparade resultaten i en fil. Vid starten av programmet kunde antal klienter anges. Varje klient representerades i simulationsprogrammet av en tråd som

oupphörligt sände en datasträng till servern, sedan inväntade serverns svar (ʺACKʺ) och därefter sände nästa datasträng. När 10 000 datasträngar hade sänts (totalt från alla klienter) beräknades antal meddelanden/sek och skrevs till en textfil. Innan tidtagningen startades skapades alla socket‐anslutningar till servern och lades i en lista. Klientobjekten fick ärva klassen Observable och Controllklassen implementerade interfacet Observer.

(18)

3 Metod 2012‐12‐19

På så sätt kunde klientklassen meddela Controller när sändningen av data var klar. Datasträngarna bestod av 752 bits i varje textsträng.

Testerna genomfördes med 1‐500 klienter.

Pseudokod för testklienten:

• läs in från användaren önskat antal klienter vid start av test

• läs in från användaren önskat antal klienter vid slutet av testen

• initiera alla objekt av klient och gör socket till servern för varje

• starta tråden för varje klient

• start loop

• starta timer

• set pause=false

• alla klienter startar då följande oändliga loop: skicka datasträng, inväntar ack, tills pause==true

• 10 000 rader har skickats till databasen

• stoppa timer, stoppa klienterna ‐ set pause=true, skriv resultatet = 752(bits)*10 000/(tiden) till fil

• om ej antalet maximala klienter uppnåtts: radera tabellen i databasen, lägg till en klient och fortsätt loopen

• loop slut programmet avslutas

För att jämföra med bandbredden när data inte sparades i databasen testades det även att skicka samma data men med ett ändrat server‐

programmet ändrades som inte sparade data i databasen.

Omgivning för server‐testen:

Serverns dator hade följande konfiguration:

• Operativsystem: Microsoft Windows XP Professional, version 2002, servicepack 3

• CPU: Via Eden 1200 MHz 1.2 GHz, 960 MB RAM (DDR‐2 / 533 MHz)

(19)

3 Metod 2012‐12‐19

Nätverket som användes var eget LAN med 100Mb hastighet Klientprogrammet för testerna kördes från en dator med:

• Operativsystem: Microsoft Windows XP Professional (32bit), Version 2002, Service Pack 3.

• CPU: Intel(R) Core(TM) i7‐3770K @ 3.50GHz 3,47 GB RAM (DDR‐3 / 1 600 MHz)

På både serverdator och klientdator kördes samma operativsystem.

Eftersom datorn för klientprogrammet har mycket högre prestanda än den för servern antogs att klientdatorn förmådde sända data snabbare än vad servern hann ta emot.

Vid testerna uppmärksammades att MySQL tillåter endast 100 eller 151 anslutningar (beroende på version). Eftersom servern använde en anslutning för varje klient skulle klientantalet därigenom begränsas. För att lösa detta och kunna testköra programmet för fler klienter ökades antalet anslutningar i MySQL genom inställning (i serverprogrammet) av MySQL system‐variabel max_connections:

ResultSet rs = stmnt.executeQuery("set global max_connections=501");

Om alla dessa anslutningar används ökar också det totala antalet trådar som CPU:n måste styra eftersom varje anslutning till databasen också är en tråd. Varje ny anslutning till databasen är en tidsödande process, och därför gjordes alla anslutningar till databasen i förväg och lades i en lista ‐ en anslutnings‐pool. Sedan ʺlånarʺ varje klient‐tråd en ledig anslutning endast när den ska skriva till databasen. Därefter lämnas anslutningen tillbaks till anslutnings‐poolen. Nackdelen med denna metod är att om antal klient‐trådar överstiger antalet anslutningar kan det bli kö till poolen och fördröjning (se bilaga B Diagram 3 ). Fördelen är att det är möjligt att ha fler klienter än antalet anslutningar till databasen. Vid de flesta applikationer som inte skickar oupphörligt data från alla klienter samtidigt borde denna metod fungera bra.

För testerna har båda dessa metoder använts i kombination. Poolen och variabeln max_connections i MySQL har succesivt ökats i storlek för att kunna matcha varandra.

(20)

4 Konstruktion 2012‐12‐19

4 Konstruktion

4.1 Kravspecifikation

I den första fasen (analysfasen) gjordes en analys av systemet tillsammans med uppdragsgivaren. För att bättre förstå projektet utarbetades ett användarfall diagram (use case diagram) som visas i figur 4.1. Diagrammet visar hur de olika parterna i systemet ska agera.

Figur 4.1: Användarfall diagram (Use case diagram).

Projektet utvecklades i fortsättningen iterativt genom att examenskandidaten träffade uppdragsgivarna varje vecka för att sätta upp nya delmål. Uppdragsgivaren önskade att systemet, som finns avbildat i figur 4.2, skulle uppfylla följande krav:

1. Servern: Servern ska ta emot meddelanden från ett antal sensorer och spara dessa i en databas. Vid varje mottaget meddelande ska textsträngen ʺACKʺ (Acknowledge) skickas som svar. Om någon sensor ger larmsignal ska servern sända en larmsignal till de andra sensorerna i samma ʺkitʺ. TCP‐protokollet ska användas.

(21)

2. Klientprogrammet: Detta program ska simulera ett ʺkitʺ i figur 4.2 och skicka data med inställda tidsintervall till servern.

Användaren ska kunna ändra data genom ett grafiskt gränssnitt.

3. Databasen: I databasen ska all data som sensorerna sänder sparas.

Dessutom ska kunddata, användardata, servicedata, vilka kit som tillhör vilka användare och vilka kit en kund har köpt finnas i databasen.

4. Webbsidan: Det ska i webbsidan finnas en login‐funktion med olika rättigheter för användare och administratorer.

Administratorn ska kunna se alla kits, användare, kunder och kunna utfärda rättigheter att använda kiten till registrerade användare. Användare ska endast kunna se tabeller över sina egna kit. Användare och kunder ska själva registrera sig och välja användarnamn och lösenord. Administratorer kan ej registreras via webbsidan utan detta ska endast kunna göras internt från företaget. Webbsidan ska vara användarvänlig och lätt att förstå.

5. Programspråken: Programmen ska fungera i operativsystemen Windows och Unix och vara gratis.

6. Flexibiliteten: Det ska vara lätt att snabbt genomföra framtida ändringar i programmen. Efter tester mot reella sensorer tillsammans med kunder kommer systemkraven att behöva ändras.

Figur 4.2: Systemet för kommunikation.

(22)

4.2 Algoritmer

För att uppfylla kravet 5, på gratisprogram och operativsystem, valdes programspråket Java för serverprogrammet och för simulationsprogrammet. För webbsidan användes html, PHP, Javascript och för databasen MySQL‐server.

4.2.1 Lösningförslag för servern

Servern skulle i det första modell/prototyp‐stadiet endast betjäna högst 60 klienter för tester. Den implementerades genom att en tråd skapades för varje ny klient‐anslutning. Varje klient‐socket representerades av ett objekt av klassen IOtoClientThread som ärvde Thread. För att hålla reda på alla klienter lades de i en lista:

static IO_Thread tDetect[] = new IO_toDetectorThread[MAXDETECTORS];

Denna lista var också parameter till tråden själv.

public IO_toDetectorThread(Socket clientSocket, IO_Thread[] t2)

För att undvika tidsfördröjningar när nya klienter etablerar kontakt med servern skapades anslutningarna till databasen i förväg i en lista, s.k.

connectionpool:

Listan: static DBclass dbConn[] = new DBclass[MAXCONNECTIONS];

DBclass innehöll alla funktioner för databasen och skapade anslutningen till denna vid starten. När data skulle sparas i databasen valde klient‐

tråden en ledig anslutning i listan dbconn. Även att skicka querys till databasen var tidskrävande. Därför undveks att upprepa querys till databasen, och istället sparades svaren för att återanvändas. MySGL begränsade antalet anslutningar till databasen till 100. Antalet räckte för applikationen men för testerna till undersökningen användes fler anslutningar. Ett förenklat flödesschema finns i bilaga C: Flödesschema för servern (förenklad version)

(23)

4.2.2 Lösningsförslag för simulator – programmet - klienten

Simulatorn kommer ofta att ändras och anpassas efter nya krav när konstruktionen av sändarenheten blir klar för att testköras.

En design‐modell som uppfyller dessa krav är MVC‐modellen (se figur 4.3), där programmet delas i tre strikt åtskilda moduler som lätthanterligt kan ändras utan att de påverkar varandra.

Simulationsprogrammet implementerades därför enligt denna modell.

Klassen View representerar ett grafiskt gränssnitt där användaren kan ändra data, klassen Model: innehåller data och klassen Controller: känner av ändringar i GUI och realiserar dessa genom att ändra data i Modul.

Figur 4.3: MVC‐modellen [6]

För den specifika applikationen användes en modifierad version av MVC‐modellen enligt Robert Eckstein [7]. View har en referens till Controller som avlyssnar alla user input i View. Controller uppdaterar sedan data i Model‐klassen.[15]

Till GUI används Java Swing och användarens valda data visas direkt på skärmen. Då data ej skulle omräknas av Model var Observer och Observable onödigt att använda i denna version av programmet.

Vid programstarten skapas i main en instance av Model:

KitModel model=new KitModel(connectArgs[2]);

(24)

Därefter startas programmet genom att en instance av View med Model som argument skapas:

new KitView(model,connectArgs);

Inne i Klassen View skapas en privat instance av Controller som av‐

lyssnar user input från GUIn. I View‐klassen:

private Controller controller;

new Controller(model, this, args);

View gör Controller till en lyssnare av användarens aktioner i GUIn.

Klassen View delegerar till andra klasser som innehåller reglage (sliders) och knappar (buttons).

slider3.getSlider().addChangeListener(controller);

decimalSpinnerN.getSpinner().addChangeListener(controller);

startButton.getbutton().addActionListener(controller);

Klassen Detector används gemensamt av servern och simulationsprogrammet. Klassen innehåller alla data som sensorer/detektorer sänder och funktioner för dessa data. I simulationsprogrammet använder Model klassen Detector‐klassen genom delegation.

4.2.3 Databasen

En databas behövdes för att förvalta kunder, användare, sensorenheter (kits), meddelanden från kits och servicedatum.

En bra strukturerad databas innehåller inte samma information på flera ställen. Istället skapas förhållanden mellan relationer mellan tabellerna genom gemensamma nyckelattribut – normalisering. Att från början skapa de bästa relationena och förhållandena i databasen är viktigt eftersom en senare ändring av förhållandena kan bli kostsam, efter att databasen väl tagits i drift. [9]

För att få en effektiv struktur på databasen och för att avlägsna redundans och olika oönskade bieffekter, till exempel att data måste lagras dubbelt eller att den inte går att lagra alls används normalisering [10].

(25)

Databasen som uppfyllde tredje normalformen [16] innehöll följande tabeller:

• user: användarlista

• customer: kundlista

• kits: namn på kit och en främmande nyckel till kundlistan

• roles: roller, t.ex. user, administrator

• kits_user: kits + användare. Tabellen innehåller endast två främmande nycklar till user och till kits

• service: datum för service för kits

• clientdata: data som skickats från sensorer

Bilaga D visar dessa tabeller och deras förhållande till varandra genom förbindelselinjer mellan nyckelattributen.

4.2.4 Webbsidan

Webbsidans uppgift är att nya kunder och användare ska kunna registrera sig och se olika listor i databasen. Administratorn ska också kunna lägga in kits och koppla kits till användare. Med tiden kommerl webbsidan att utvidgas med ytterligare funktioner. Formulären för registrering är skrivna i Javascript och funktionerna med databas‐

anknytning är skrivna i PHP. Ett förenklat flödesschema visas i bilaga C Flödesschema för webbsidan. Användargränssnittet visas i bilaga C Webbsidans användargränssnitt.

(26)

5 Resultat 2012‐12‐19

5 Resultat

5.1 Resultat av enkät

Användartest har genomförts med sex personer i Växjö 2012‐09‐21.

Personerna har olika bakgrund avseende utbildning, arbetslivserfarenhet och ålder. Se kapitel 3. Personerna skulle enligt metodbeskrivningen provköra systemet med simulation och webbsida. Till hjälp hade de användarhandledningen enligt bilaga A. I figur 5.1 visas resultatet av användartesten.

5=instämmer helt, 0=instämmer inte alls

Figur 5.1: Resultat av enkät

Efter testen intervjuades testpersonerna om hur de upplevde systemet.

Sammanfattningvis gav intervjuerna följande resultat:

Alla testpersoner ansåg att designen för webbsidan och programmet var en enkel, avskalad och tydlig, och att detta var bra. Några ansåg dock att det var svårt att veta var på webbsidan de befann sig.

(27)

5 Resultat 2012‐12‐19

Två personer önskade att webbsidan och programmet skulle vara på svenska istället för på engelska, och några hade inledningsvis svårigheter att förstå hur ʺshowʺ‐funktionen fungerade.

Det visade sig att de testpersoner som hade en teknisk utbildning ansåg att webbsidan fungerade logiskt och intuitivt medan andra hade vissa svårigheter i början att förstå hur webbsidan fungerade. I diskussion med testpersonerna framkom följande förbättringsförslag: Byt färger och öka tydligheten. Namnet på den inloggade borde synas i hörnet.

Använd tooltips (i Java) och F1 kopplad till hjälp‐manual. Eftersom två av testpersonerna var uppdragsgivare kunde de samtidigt bedöma om de ansåg att systemet uppfyllde deras krav. De ansåg båda att systemet fungerade mycket bra och enligt deras förväntningar, förutom de små korrigeringarna för webbsidan. Se bilaga E för resultatet av enkäten.

5.2 Resultat av prestandatest för servern

Bandbredden för servern uppnådde maximalt cirka 370kb/sek vid 1‐70 klienter och avtog därefter med stigande antal klienter. Testen mätte bandbredden för inkommande data (download) när servern tog emot och sparade 752 kb i databasen och skickade ʺACKʺ till klienten.

En trendlinje visade att serverns bandbredd avtog med cirka 150b/sek per ny klient. Se figur 5.2 och diagram 4 i bilaga B.

Utan att spara data i databasen var serverns bandbredd c:a 6Mb/sek (och avtagande). Se diagram 2 i bilaga B.

Då servern ej sparade data i databasen avtog bandbredden med cirka 2.46kb/klient. Se diagram 2 i bilaga B.

Serverns bandbredd blev cirka 95 procent lägre då den sparade data i databasen än när den inte gjorde det. Se diagram 1 i bilaga B.

Optimering kunde göras genom att upprätta anslutningarna till databasen i förväg till en lista: connectionpool.

När klientantalet översteg storleken av connectionpool avtog däremot bandbredden betydligt. Se diagram 3 i bilaga B.

(28)

5 Resultat 2012‐12‐19 mellan sensorer, webbsida, server

Problem vid mätningarna var de varierande resultaten, men en tydlig tendens kunde trots detta urskiljas. Fler mätningar bör göras.

0 50 100 150 200 250 300 350 400 450

1 19 37 55 73 91 109 127 145 163 181 199 217 235 253 271 289 307 325 343 361 379 397 415 433 451 469 487

Antal klienter

Bandbredd kb/sek

Pool=200 Pool=400 Pool=500 Linear (Pool=400)

Figur 5.2: Diagram för bandbredd med trendlinje

(29)

6 Slutsats 2012‐12‐19

6 Slutsats

I målformuleringen angavs att ett system för kommunikation skulle skapas och att de tillhörande programmen skulle implementeras. Nedan följer en genomgång av dessa mål och deras lösningar:

1. Skapa en server som tar emot data från klienter/sensorer, kontrollerar data och sparar i en databas och sänder alarm till andra klienter vid larmsignal.

En server implementerades som kommunicerar med klienter, sända alarm och spara data i databasen.

2. Skapa ett klientprogram som simulerar en sensorenhet med fyra sensorer som skickar data till serven. I detta program ska ett

användargränssnitt (GUI) finnas där användaren kan reglera data som sändes.

Simulationsprogrammet är klart och användaren kan göra inställningar av alla data genom GUI och även reglera sändningshastigheten.

3. Skapa en webbsida där kunder och administratörer kan logga in sig och följa övervakningen genom kontakt med databasen.

Webbsidan fungerar och är testad i användartesten där mindre förändringar föreslogs som nu redan är genomförda.

4. Skapa databasen där servern sparar data från sensorerna och där kunddata, användardata m. fl. läggs in genom webbsidan.

Ordningen av data i databasens tabellerna fungerar mycket bra.

5. Skapa olika versioner av klient‐ och serverprogram för att testa serverns prestanda.

Det finns nu ett tiotal olika varianter av testprogram. Dessa kan användas i framtiden för att mäta prestandan av servern då den körs på olika datorer med olika konfiguration.

6. Det skulle vara lättöverskådligt och enkelt att införa ändringar i programmen.

Genom att använda designmodellen MVC för klientprogrammet innebar detta lite mer arbete vid själva programmeringen och mer kod. Detta lönade sig väl vilket märktes vid ändringarna till olika slags testprogram. Modulerna i programmet var väl avgränsade och det var lätt att hitta var variabler och funktioner fanns.

(30)

6 Slutsats 2012‐12‐19

Två olika undersökningar skulle utföras:

3. Undersöka användarvänligheten hos systemet genom att göra ett användartest för simulationsprogrammet och webbsidan.

Undersökningen genomfördes enligt metodbeskrivningen och testpersonerna fann systemet till största delen användarvänligt med reservation för en par förbättringsförslag som var enkla att införa.

4. Undersöka serverns prestanda avseende bandbredd och påverkan av antal klienter. Undersöka vilka andra faktorer som påverkar prestandan.

Undersökningarna visade resultaten som redovisats i kapitel 5.2.

Det visade sig att det var databasen som mest påverkade prestandan och att det var möjligt att optimera programmet på några ställen.

6.1 Kritisk granskning av resultaten

Genom mätresultaten kan storleken av connectionpool anpassas till datasändningen för att uppnå högsta möjliga bandbredd. Den drastiska försämringen vid överbelastning och ʺköʺ till connectionpool visar hur viktigt det är att optimera dess storlek.

Mätningarna är gjorda med maximal belastning och kontinuerlig sändning av data till servern. I verklighetens applikationer kommer det inte att sändas data oupphörligt från sensorerna, utan det kommer att sändas med visst tidsintervall. I dessa fall kommer connectionpool att fungera bättre och ej bli överbelastad.

Resultatet av mätningen för bandbredden varierade mycket p.g.a. det alltid finns minst några bakgrundsprocesser som inte kan stängas av då de är nödvändiga för operativsystemet. Ojämnheten försökte att kompenseras genom att göra ett stort antal tester. Trots variationen visade testerna tydligt trenden att bandbredden avtog i relation till att klientantalet ökade. Eftersom detta resultat var förväntat fanns det ändå anledning att tro att mätningarna var någorlunda tillförlitliga. För ett jämnare utfall hade det varit nödvändigt med längre och fler tester men detta var inte tidsmässigt möjligt.

(31)

6 Slutsats 2012‐12‐19

Test av maximala antalet klienter som servern kunde klara av gjordes ej eftersom datorn vid överbelastning körde fast och RAID‐systemet bröts isär. Om trendlinjen skulle fortsätta oförändrat (i diagrammet 4 bilaga B) skulle bandbredden 0 nås då klientantalet är cirka 2 000, men detta är endast en spekulation. Troligtvis slutar servern att fungera tidigare och trendlinjen fortsätter inte oförändrat. Vid en grov beräkning sjunker bandbredden med cirka 0,04‐0,05 procent för varje ytterligare klient.

Se bilaga B Diagram 1, 2 och 4.

Mätningsresultaten kan inte generaliseras då de beror på lokala faktorer såsom datorernas konfiguration och CPU. I undersökningen som gjordes i ett 100Mb LAN orsakades den största fördröjningen av skrivningen till databasen som upptog 95 procent av tiden. I andra omgivningar kan istället fördröjningen uppstå i nätverket. Dessutom gjordes inte mätningen längre än till 500 klienter.

Klienten som testades mot servern fanns på en dator av senaste generationen (Intel Core i7 / 3.5 GHz) medan servern fanns på en dator av den äldre generationen (Via Eden / 1.2 GHz). Därför kunde klient‐

programmet skicka data tillräckligt snabbt till servern för testerna.

I annat fall hade det behövs flera klienter på flera datorer.

I användartesten var det intressant att skillnaden i uppfattningen av programmen var så tydlig mellan de tekniskt utbildade och dem med annan utbildning. Det var en liten grupp testpersoner, varför inga allmänna slutsatser kan dras av resultatet. Om det verkligen stämmer i allmänhet, krävs det att programmeraren tar hänsyn till detta för att hans program eller webbsidor ska kunna bli förstådda av båda dessa grupper.

(32)

6 Slutsats 2012‐12‐19

6.2 Förslag på vidare utveckling av systemet

Systemet är en grundläggande modell i ett större system som med tiden ska utvecklas vidare med många fler funktioner För att se till att bevakningen sker under ansvar och inte inkräktar på människors privatsfär

• ska varje användare registreras av serverns administrator

• ska systemet endast kunna startas då användaren har loggat in sig genom SSL

• ska det vid varje användning registreras i databasen vem som startar bevakning. Genom detta kan olämplig användning förebyggas och den skyldige spåras.

När systemet ska användas i WAN föreslås säkerhetsåtgärder som nämns i kapitel 1.3. De säkerhetsfunktioner som åsyftades är följande:

• använda SSL‐kryptering vid inloggning till webbsidan

• skydd mot SQL Injection attack i databasen: för webbsidan i PHP använd mysql_real_escape_string i frågesträngar mot MySQL

• databasen ska inte innehålla några lösenord från användare. När en användare registrerar sig ska hans lösenord göras om till hashkod och endast denna hashkoden ska databasen spara.

• för att upptäcka fel i data från klienten och kontrollera

integriteten hos avsändaren ska en MD5 checksumma sändas i slutet av varje meddelande från klient/sensor till servern. (MD5 anses inte vara kryptografisk säker, men fel i data som skickats kan åtminstone upptäckas )

• använda prepared statements i MySQL för att undvika SQL Injection attack

(33)

6 Slutsats 2012‐12‐19

Övriga förslag till vidareutveckling:

• För att lagra datamängden som inkommer till databasen vid storskalig drift behövs en lösning för att ta ut dem ur databasen efter en viss tid eller radera dem.

• Vid larm från en detektor ska som tilläggstjänst ett sms och/eller e‐post sändas till användarna. E‐post och sms har användarna angett när de registrerat sig i databasen.

• Vid starten av en sensorklient ska användaren först logga in sig till servern. Därefter ska servern kontrollera i databasen om användaren har rättighet att använda sensorn. Detta blir först aktuellt då sensorerna programmeras.

• För inloggning av användare till servern kan en annan LAN‐port användas med en annan IP‐adress och med lägre prioritet.

• Många fler funktioner ska läggas till webbsidan: radering, val att se listor från visst datum, välja olika sortering av listor, välja enskilda element i listor.

(34)

Mobilt övervakningssystem ‐ System för internetkommunikation mellan sensorer, webbsida, server och databas

Ingela Stålberg

Källförteckning 2012‐12‐19

Källförteckning

[1] Microsoft Technet, ʺMonitoring context switchesʺ.

http://technet.microsoft.com/en‐us/library/cc938606.aspx.

Hämtad 2012‐10‐14.

[2] Svenska Wikipedia, ʺMessage‐Digest Algoritm 5ʺ.

http://sv.wikipedia.org/wiki/Md5.

Hämtad 2012‐10‐10.

[3] Gulliksen Jan, ʺAnvändbar IT, Användarcentrerad IT‐utveckling i den statliga sektornʺ, Kungliga tekniska högskolan, KTH.

http://www.fungerandemedier.se/sites/fungerandemedier.se/files /anvandbar_it.pdf.

Hämtad 2012‐10‐05.

[4] The AGILE project, ʺVattenfallsmodellenʺ

http://theagileproject.wordpress.com/vattenfallsmodellen/

Hämtad 2012‐12‐08.

[5] Best‐practice software engineering, ʺModel View Controllerʺ.

http://best‐practice‐software‐

engineering.ifs.tuwien.ac.at/patterns/mvc.html.

Hämtad 2012‐08‐12.

[6] Rainer Friesen, Markus Stollenwerk & Daniel Valentin, ʺMVC patternʺ.

http://public.fh‐trier.de/~rudolph/gdv/cg/node46.html.

Publicerad 2007‐03‐06. Hämtad 2012‐08‐25.

[7] Robert Eckstein, ʺJava SE applications with MVCʺ.

http://www.oracle.com/technetwork/articles/javase/mvc‐

136693.html#1.

Publicerad 2007‐03. Hämtad 2012‐08‐15.

(35)

Ingela Stålberg

[8] Svenska Wikipedia, ʺDatabasʺ

http://sv.wikipedia.org/wiki/Databas.

Hämtad 2012‐10‐21.

[9] Svenska Wikipedia, ʺRelationsdatabasʺ

http://sv.wikipedia.org/wiki/Relationsdatabas.

Hämtad 2012‐10‐21.

[10] LabWiki, ʺNormalformer och normaliseringʺ

http://mt.sh.se/informatik/labwiki/index.php/Normalformer_och _normalisering.

Hämtad 2012‐10‐21.

[11] Raymond R. Panko, Corporate Computer and Network Security, second edition. Prentice Hall 2010. Sid. 356‐357.

[12] TechTerms.com, ʺBandwidthʺ

http://www.techterms.com/definition/bandwidth.

Hämtad 2012‐12‐07.

[13] Internet of Things, Europe, ʺIntroductionʺ http://www.internet‐of‐things.eu/introduction.

Hämtad 2012‐11‐19.

[14] Wammi, ʺWebsite Analysis and Measurement Inventory (WAMMI). Demo survey – Company Zʺ.

http://www.wammi.com/samples/index.html.

Hämtad 2012‐10‐24.

[15] The Ohio state university college of engineering, ʺMVC design‐

modellʺ

http://www.cse.ohio‐

state.edu/~rountev/421/lectures/lecture23.pdf.

Hämtad 2012‐10‐18.

[16] Rejas, ʺKapitel 6, Normaliseringʺ

http://www.rejas.se/fritis/databashantering/normalisering.html.

Hämtad 2012‐10‐21.

(36)

Ingela Stålberg

Bilaga A: Användarhandledning

Manual för Detector simulation-system.

Systemet består av tre program:

servern som tar emot data

detektor-simulatorn som skickar data till servern webbsidan mobilAdmin, där olika data visas

Med ett "kit" menas en enhet som sänder data från fyra sensorer/detektorer.

Detektorsimulatorn simulerar ett "kit".

Servern:

servern kör i bakgrunden och har host adress: localhost och port: 2222

Detektor-simulation:

Starta simulations-programmets genom att klicka på ikonen Mobil detektor.

I fönstret som öppnas kan man fylla i host för server, port och detektornamn.

Server host och port är redan ifyllt, det är endast detektornamn som ev.

behöver ändras. Om detektornamnet inte finns registrerat i databasen kan inte detektorn simuleras.

Fyll i data och tryck på "start simulation".

Nu öppnas ett fönster där olika data för fyra detektorer visas. Till vänster kan man, genom att dra ett reglage, ställa in mellan vilket tidsintervall (i sekunder) som data ska sändas. Som default sänds data var 6:e sekund.

För varje detektor kan man ställa in data genom att dra i de olika reglagen och gps-inställningrn kan finjusteras med pilarna.

För att starta en detektor trycker man på "start sending". Stoppa sändningen gör man med samma knapp "stop sending". Avsluta alltihopa gör man genom att stänga fönstret.

Webbsidan mobilAdmin:

sidan startas genom dubbelklick på ikonen.

De olika knapparnas betydelse:

(37)

Ingela Stålberg

• Login: här kan en användare eller administrator logga in sig till databasen.

• Register new user: en ny användare kan här registrera sitt namn adress och övriga data och skapa sitt användarnamn och lösenord.

• Register new customer: en ny kund kan här registrera sitt namn adress och övriga data och skapa sitt användarnamn och lösenord.

• Attach kit to user: här bestämmer en administrator till vilket kit en användare blir registrerad för. Detta kan endast en administrator göra.

• Add kit: lägg in ett nytt kit i databasen, endast tillåtet för administratorn.

• Show:

Till höger om "show" finns en rullgardinslista där man kan välja vilka data man önskar se. Efter att ha valt vad man vill se klickar man på show.

-Users:andra användare till det eller dom kit man är registrerad som användare av.

-Users and kits: användare plus vilka kit de använder. (För användare samma lista som Users.)

-Kits: alla kits.

-Detector messages:meddelanden från egna detectorer.

-Customers: kunder.

-Service dates: service datum och inköpsdatum.

OBS: För vanliga användare visas endast data som gäller egna kits.

Administratorn ser all data för alla användare. Är man ny användare och inte har något kit kan man inte se några listor alls.