Institutionen för datavetenskap
Department of Computer and Information Science
Examensarbete
Implementation av mätsystem för
dricksvattenkvalitet
av
Fredrik Larsson, Hannes Snögren, Sebastian Gustafsson,
Magnus Qvigstad, Hugo Lindholm, Rasmus Eriksson
LIU-IDA/LITH-EX-G--15/023--SE
2015-05-27
Linköpings universitet Institutionen för datavetenskap
Examensarbete
Implementation av mätsystem för
dricksvattenkvalitet
av
Fredrik Larsson, Hannes Snögren, Sebastian
Gustafsson, Magnus Qvigstad, Hugo Lindholm, Rasmus
Eriksson
LIU-IDA/LITH-EX-G--15/023--SE
2015-05-27
Handledare: Jonas Lindgren
Examinator: Kristian Sandahl
PROJEKTIDENTITET
VT, 2015, Grupp 4 Link¨opings Tekniska H¨ogskola, IDA
Gruppdeltagare
Namn Ansvar E-post
Fredrik Larsson Gruppledare, Kvalitetssamordnare frela412@student.liu.se Magnus Qvigstad Analysansvarig magqv734@student.liu.se Sebastian Gustafsson Arkitekt sebgu182@student.liu.se Rasmus Eriksson Utvecklingsansvarig raser891@student.liu.se Hannes Sn¨ogren Testledare hansn314@student.liu.se Hugo Lindholm Dokumentansvarig hugli113@student.liu.se
Kund: Hans Sundgren
Kontaktperson hos kund: Hans Sundgren Kursansvarig: Kristian Sandahl
Sammanfattning
F¨oljande rapport behandlar konstruktionen av ett system som kontinuerligt ska analysera kvalite-ten p˚a vatten. Systemet ¨ar uppdelat i m¨atenheter som utf¨or sj¨alva m¨atningen och en centraliserad server som man kan koppla upp sig mot f¨or att ¨overvaka/justera sina m¨atenheter.
Uppdragsgivaren till projektet var forskare fr˚an IFM p˚a Link¨opings universitet. De hade sedan tidigare ett fungerande system f¨or att analysera vatten kontinuerligt. V˚ar uppgift var att ers¨atta deras system med ett nytt, som var baserat p˚a mindre och billigare h˚ardvara. Vi har visat att systemet g˚ar att implementera p˚a den ¨onskade h˚ardvaran.
Rapporten skildrar ¨aven hur projektgruppen tog designbeslut under utvecklingsfasen. Denna de-signbeslutsprocess och de konsekvenser den fick f¨or slutprodukten analyseras.
1 Inledning 1
1.1 Syfte . . . 1
1.2 Bakgrund till fr˚agest¨allningar . . . 1
1.3 Fr˚agest¨allning . . . 1 1.4 Avgr¨ansningar . . . 1 1.5 Ordlista . . . 2 2 Bakgrund 2 2.1 Befintligt system . . . 2 2.2 Problematik . . . 2 3 Teori 2 3.1 M¨atning av vattenkvalitet . . . 2 3.2 Databaser . . . 3 3.3 N¨atverkskommunikation . . . 3 3.4 Packet-Framing . . . 3 3.5 Node.js . . . 4 3.6 Websocket . . . 4 3.7 D3 . . . 4 3.8 BeagleBone . . . 4 3.8.1 BeagleBone Black . . . 4 3.8.2 ARM Cortex-A8 . . . 5 4 Metod 5 4.1 Utveckling av system . . . 5 4.1.1 Kravs¨attning . . . 5 4.1.2 Organisation . . . 5 4.1.2.1 Projektgrupp . . . 6 4.1.2.2 Handledare . . . 7 4.1.2.3 Kund . . . 7 4.1.2.4 Projektets faser . . . 7 4.1.2.5 Dokumentation . . . 8 4.1.3 Arbets¨att . . . 8 4.1.3.1 M¨oten . . . 9 4.1.3.2 Gitlab . . . 9 4.1.3.3 Redmine . . . 9 4.1.4 Uppsamling av erfarenheter . . . 9
4.1.5 J¨amf¨orelse med f¨org˚aende system . . . 9
4.2 Designbeslutsprocess . . . 10
4.2.1 Identifiera problem med designbeslutsprocess . . . 10
4.2.2 Analys av designbeslutsprocess . . . 10
5 Resultat 10 5.1 Kravh¨amtning . . . 10
5.2 Overgripande l¨¨ osning . . . 10
5.3 H˚ardvara . . . 11
5.3.1 D/A- och A/D-omvandlare . . . 11
5.3.2 Realtidsdator . . . 11
5.4 M¨atenhet . . . 11
5.4.1 Programstruktur . . . 11
5.4.2 Programvara PRU . . . 12
5.4.4 Gr¨anssnitt mot PRU . . . 14 5.4.4.1 prussdrv . . . 14 5.4.4.2 mio . . . 14 5.4.4.3 libpru . . . 14 5.4.4.4 pru interface . . . 14 5.4.4.5 PruHandler . . . 15 5.4.5 M¨atklient . . . 16 5.4.5.1 N¨atverkshantering . . . 16 5.4.5.2 M¨atningshanteraren . . . 16 5.4.5.3 Filsystemet . . . 17 5.5 Server . . . 18 5.6 Serverarkitektur . . . 18 5.6.1 TCP . . . 19 5.6.2 Webb . . . 19 5.6.2.1 API . . . 19 5.6.2.2 WebSocket . . . 20 5.6.3 MongoDB vs MySQL . . . 20 5.6.4 Databasmodeller . . . 21 5.6.4.1 Unit collection . . . 21 5.6.4.2 User collection . . . 22 5.7 Webbgr¨anssnitt . . . 22 5.7.1 Bootstrap . . . 22 5.7.2 DataTables . . . 22 5.7.3 Interaktiv graf . . . 23 5.7.4 Jade . . . 24 5.8 Designbeslutsprocess . . . 24 5.8.1 Plotly . . . 24 5.8.2 TCP-protokoll . . . 24 5.8.3 Measurehandler . . . 25 5.8.4 V˚ar designbelutsprocess . . . 25 5.9 Tidsf¨orbrukning . . . 25 5.9.1 Medlem hoppar av . . . 25 5.9.2 F¨orbrukad tid . . . 25 5.10 Gemensamma erfarenheter . . . 25 6 Diskussion 26 6.1 Nya systemet . . . 26 6.1.1 Resultat . . . 26 6.1.2 Metod . . . 26 6.2 Designbeslutsprocess . . . 27 6.2.1 Resultat . . . 27 6.2.2 Metod . . . 27 7 Slutsatser 27 7.1 Fr˚agest¨allning 1 . . . 28 7.2 Fr˚agest¨allning 2 . . . 28
7.3 Arbetet i ett vidare sammanhang . . . 28
7.3.1 Etiska och samh¨alleliga aspekter . . . 28
7.3.2 Milj¨oaspekter . . . 28
8 Fortsatt arbete 28 8.1 Analys i matlab . . . 28
8.2 Varningar i webbgr¨anssnitt . . . 28
A. Hugo - Analys av utvecklingsmetodik
30
A.1 Inledning 30
A.1.1 Syfte . . . 30
A.1.2 Fr˚agest¨allning . . . 30
A.1.3 Avgr¨ansningar . . . 30
A.2 Bakgrund 31 A.3 Metod 31 A.3.1 Utvecklingsmetodiker . . . 31
A.3.2 Analys av projektarbetet . . . 31
A.3.2.1 Enk¨at . . . 31
A.3.2.2 Projekt dokument . . . 31
A.3.3 Vald utvecklingsmetodik . . . 31
A.4 Resultat 31 A.4.1 Utvecklingsmetodiker . . . 32
A.4.1.1 Vattenfallsmodellen . . . 32
A.4.1.2 Unified Process (UP) . . . 32
A.4.1.3 Scrum . . . 33
A.4.1.4 eXtreme Programming (XP) . . . 33
A.4.2 Analys . . . 33
A.4.2.1 Enk¨ater . . . 34
A.4.2.2 Krav . . . 34
A.4.2.3 Kommunikation . . . 34
A.4.2.4 Analysens resultat . . . 35
A.5 Diskussion 35 A.5.1 Analys av projektet . . . 36
A.5.1.1 Krav . . . 36
A.5.1.2 Kommunikation . . . 36
A.5.1.3 Kod . . . 37
A.5.1.4 Process . . . 37
A.5.1.5 Fallerande punkter . . . 38
A.5.2 V¨ardematris . . . 38
A.5.3 Vald utvecklingsmetod . . . 39
A.5.4 Resultat . . . 39 A.5.5 Metod . . . 39 A.6 Slutsatser 40
B. Rasmus - Node.js
41
B.1 Inledning 41 B.1.1 Syfte . . . 41 B.1.2 Fr˚agest¨allning . . . 41 B.1.3 Metod . . . 41 B.1.4 Avgr¨ansningar . . . 41 B.2 Teori 42 B.2.0.1 Server-klient arkitetkur . . . 42B.2.0.2 En tr˚ad/process per anslutning . . . 42
B.2.0.4 Node.js . . . 43
B.3 Resultat 44 B.3.0.5 Prestandatester . . . 44
B.3.0.5.1 Test mot popul¨ara alternativ . . . 44
B.3.0.5.2 Test mot Apache och liknande eventsystemet EventMachine . . . 44
B.3.0.6 Kodstruktur . . . 44 B.3.0.7 Pakethanterare . . . 44 B.3.0.8 S¨akerhet . . . 45 B.3.0.9 L¨arande . . . 45 B.4 Diskussion 45 B.5 Slutsatser 46
C. Fredrik - Kvalitetsplan
48
C.1 Inledning 48 C.1.1 Syfte . . . 48 C.1.2 Fr˚agest¨allning . . . 48 C.1.3 Avgr¨ansningar . . . 48 C.2 Bakgrund 48 C.3 Teori 49 C.4 Metod 50 C.5 Resultat 50 C.5.1 Risker . . . 50C.5.2 Team Risk Management . . . 50
C.6 Diskussion 51 C.6.1 Resultat . . . 51
C.6.1.1 Riskhantering . . . 51
C.6.1.2 Team Risk Management . . . 52
C.6.2 Metod . . . 52 C.7 Slutsatser 53
D. Hannes - Enhetstestning
54
D.1 Inledning 54 D.1.1 Syfte . . . 54 D.1.2 Ordlista . . . 54 D.1.3 Fr˚agest¨allning . . . 54 D.1.4 Avgr¨ansningar . . . 54 D.2 Bakgrund 55 D.3 Teori 55 D.3.1 Agil arbetsmetodik . . . 55 D.3.2 Enhetstest . . . 55 D.3.3 Modultest . . . 55D.3.4 Integrationstest . . . 55 D.3.5 Regressionstest . . . 55 D.3.6 Systemtest . . . 55 D.4 Metod 56 D.5 Resultat 56 D.5.1 Arbetss¨att . . . 56 D.5.2 Testplan . . . 56 D.5.3 Enhetstest . . . 56 D.5.4 Integrationstest . . . 57 D.5.5 Systemtest . . . 57 D.5.6 Effektivitet . . . 57 D.6 Diskussion 57 D.6.1 Resultat . . . 57 D.6.2 Metod . . . 58 D.7 Slutsatser 59
E. Sebastian - Implementation av realtidsfunktionalitet
60
E.1 Inledning 60 E.1.1 Syfte . . . 60E.1.2 Fr˚agest¨allning . . . 60
E.1.3 Avgr¨ansningar . . . 60
E.2 Bakgrund 60 E.3 Teori 60 E.3.1 Tidskritisk kod under normalt operativsystem . . . 60
E.3.2 Realtidsoperativsystem - RTLinux . . . 61
E.3.3 Extra h˚ardvara - FPGA . . . 61
E.3.4 BeagleBone Black - PRUSS . . . 61
E.4 Metod 61 E.4.1 Implementation av sampling p˚a PRU . . . 62
E.4.2 J¨amf¨orelse av PRUSS mot andra implementationer . . . 62
E.5 Resultat 62 E.5.1 1 kHz sampling med PRU . . . 62
E.5.2 Resultat av vald implementation . . . 62
E.6 Diskussion 62 E.6.1 Resultat . . . 63
E.6.1.1 1 kHz sampling med PRU . . . 63
E.6.2 Metod . . . 63
E.6.2.1 Val av PRUSS . . . 63
E.7 Slutsatser 63
F. Magnus - Kravframst¨
allning
64
F.1.1 Syfte . . . 64 F.1.2 Fr˚agest¨allning . . . 64 F.1.3 Avgr¨ansningar . . . 64 F.2 Bakgrund 64 F.3 Teori 64 F.4 Metod 65 F.5 Resultat 65 F.5.1 Analys av projektet . . . 65
F.5.2 Kraninh¨amtnings inverkan p˚a mjukvaruprojekt generellt . . . 65
F.6 Diskussion 66 F.6.1 Resultat . . . 66 F.6.2 Metod . . . 67 F.7 Slutsatser 67 Referenser 68 Bilaga A Bilagor 71 F.1.1 Bilaga enk¨at kund . . . 71
F.1.2 Bilaga enk¨at grupp . . . 76
F.1.3 Bilaga enk¨at kund . . . 85
F.1.4 Bilaga enk¨at grupp . . . 90
F.1.5 Bilaga enk¨at risker . . . 98
Bilaga B Fredriks enk¨at 98 F.2.1 Bilaga enk¨at Node.js . . . 99
1
Inledning
Under v˚aren 2015 utf¨orde sju studenter vid Link¨opings universitet sina kandidatarbeten i form av ett gemensamt projekt i kursen TDDD77. Projektgruppen fick v¨alja mellan ett antal olika upp-gifter, och valde projektet Dricksvattenkvalitet.
Den h¨ar rapporten dokumenterar detta gemensamma kandidatarbete och behandlar den process som ersatte ett befintligt system med ett nytt. Ut¨over det unders¨oks hur designbeslutsprocessen fungerade under utvecklingen av detta system.
1.1
Syfte
Syftet med rapporten ¨ar att unders¨oka om det ¨ar m¨ojligt att ers¨atta ett befintligt system f¨or att m¨ata dricksvattenkvalitet med ett nytt. Vi kommer ¨aven redovisa v˚ara erfarenheter fr˚an utveck-lingen av detta system. Vidare s¨oker vi f˚a djupare f¨orst˚aelse f¨or hur designbeslut tas p˚a ett bra s¨att.
1.2
Bakgrund till fr˚
agest¨
allningar
Kund som best¨allde projektet var intresserad av att veta huruvida det ¨ar m¨ojligt att utveckla ett nytt system kring ny h˚ardvara som kan ers¨atta det befintliga. Det befintliga systemet beskrivs n¨armare i avsnitt 2.
I projekt d¨ar man utvecklar ett system kr¨avs det att man tar en m¨angd designbeslut. Dessa designbeslut har stor inverkan p˚a slutprodukten. D¨arf¨or ¨ar den process som leder fram till dessa beslut s¨arskilt intressant.
1.3
Fr˚
agest¨
allning
• ¨Ar det m¨ojligt att ers¨atta det befintliga systemet med ett nytt system? – Kan en m¨atstation implementeras p˚a en Beaglebone Black? – Kan systemet f¨ardigst¨allas p˚a avsatt antal timmar?
• Hur kan vi f¨orb¨attra v˚ar designbeslutsprocess?
1.4
Avgr¨
ansningar
Projektet avgr¨ansas till att endast utveckla mjukvara. Det avgr¨ansas ocks˚a till att endast imple-mentera den funktionalitet som projektgruppen kommer ¨overens med kund om.
G¨allande den andra fr˚agest¨allningen avgr¨ansas utredningen till att samla in och j¨amf¨ora erfaren-heter fr˚an detta projekt med andra beslutsmetoder.
1.5
Ordlista
REST Representational State Transfer (REST) ¨ar ett arkitekturbegrepp f¨or att beskriva hur kommunikation mellan maskin till maskin struktureras.
API Applikationsprogrammeringsgr¨anssnitt (API), specifierar hur program kan anv¨anda och kommunicera med en specifik programvara.
ODM Object document modeling (ODM), ¨ar oftast ett verktyg som hj¨alper till att ¨
overs¨atta kod till databasstrukturer.
SVG Vektorgrafik-format f¨or tv˚adimensionella bilder som st¨odjer animationer och in-teraktivitet. Kan embeddas i webbsidor.
FPGA Field-Programmable Gate Array. En integrerad krets som kan programmeras. Prob H˚ardvara med fyra elektroder som anv¨ands vid m¨atning av vattenkvalitet. MsSQL Microsoft SQL-databas.
IFM Institutionen f¨or Fysik, Kemi och Biologi. IDA Institutionen f¨or Datavetenskap.
Token En unik identifierare som kan anv¨andas f¨or exempelvis autentisering
Collection En databas inneh˚aller flera ’collections’. Dessa collections inneh˚aller sedan doku-ment.
JSON Ett ¨oppet standardiserat format f¨or att skicka data. PRU Enhet som anv¨ands f¨or realtids programmering.
2
Bakgrund
En grupp forskare p˚a IFM vid Link¨opings universitet har tagit fram ett system f¨or att utf¨ora m¨atningar som uppt¨acker f¨ororeningar i dricksvatten. Dessa m¨atningar utf¨ors genom att m¨ata str¨ommen i tre olika elektroder d˚a man belastar en fj¨arde med en serie sp¨anningar. Denna prob har drivits av omfattande h˚ardvara, inkluderande bland annat FPGA-kort och realtidsdatorer. Dessa forskare ville unders¨oka m¨ojligheten att byta ut den befintliga h˚ardvaran mot n˚agot mindre och betydligt billigare i form av en BeagleBone Black.
2.1
Befintligt system
Det befintliga systemet bet˚ar av ett chassi p˚a ca 70x70x20 cm. Kostnaden f¨or h˚ardvaran l˚ag ¨over 20 000 kronor. Inuti finns ett antal h˚ardvarukomponenter som analog-till-digital och digital-till-analog-omvandlare, realtidsdator, FPGA, n¨atverkskort och 3G-koppling. P˚a denna h˚ardvara k¨ors mjukvara som ser till att m¨atningar utf¨ors och skickas iv¨ag. Det finns ocks˚a en central server som k¨or en MS SQL-databas d¨ar m¨atningar lagras.
2.2
Problematik
Det finns flera argument f¨or att bygga ett nytt system. H˚ardvaran ¨ar stor, dyr och ¨overdimensionerad f¨or uppgiften. M¨atningar utf¨ors och sparas lokalt, samtidigt skickas den till en central server. Miss-lyckas ¨overf¨oringen g¨ors inte n˚agot nytt f¨ors¨ok. Detta leder till att de beh¨over g˚a till m¨atenheten f¨or att h¨amta ut den f¨orlorade m¨atdatan.
3
Teori
Detta avsnitt beskriver bakgrundsteori kring v¨asentliga delar av systemet.
3.1
M¨
atning av vattenkvalitet
Principen ¨ar en enkel elektrokemisk metod med elektrisk stimulering av reaktiva komponenter i vattnet. Reaktionerna ger upphov till en elektrisk str¨om som registreras. Detektorn best˚ar i
hu-vudsak av en liten yta av en katalytisk ¨adelmetall placerad i vattenfl¨odet. De datam¨angder som de uppm¨atta reaktionsstr¨ommarna genererar m˚aste utv¨arderas f¨or att avvikelser i vattenkvalitet ska kunna uppt¨ackas.
3.2
Databaser
N¨ar man pratar om databaser s˚a finns det ett par olika typer som fungerar p˚a olika s¨att, i den-na del kommer tv˚a olika typer tas upp. Den f¨orsta ¨ar en Structured Query Language-databas, som h¨adanefter kommer ben¨amnas SQL. Denna typ ¨ar relationsbaserad. Den andra typen ¨ar en dokument-orienterad databas som ocks˚a kallas f¨or NoSQL-databas, denna ¨ar inte relationsbaserad. Det finns ett par skillnader mellan SQL och NoSQL-databaser. Den st¨orsta skillnaden ¨ar att SQL-databaser ¨ar strukturerade med rader och kolumner och beh¨over ett f¨ordefinierat schema ¨over hur datan ska se ut innan den sparas. NoSQL-databaser anv¨ander sig av collections. MongoDBs col-lections har ett format som liknar formatet JSON(JSON , u. ˚a.). NoSQL kr¨aver inte att schemat ska definieras i f¨orv¨ag och ¨ar helt dynamisk, man kan till och med ha olika schema typer i samma collection. Databaserna skalar dessutom p˚a olika s¨att. En NoSQL-databas skalas genom att l¨agga till en till databas nod. En SQL-databas skalas genom att uppgradera komponenterna, till exempel med en snabbare CPU, mer RAM och fler h˚arddiskar.
3.3
N¨
atverkskommunikation
Kommunikation via n¨atverk bygger olika sorter av sockets. TCP(TRANSMISSION CONTROL PROTOCOL, 1981) ¨ar en typ av socket som ¨ar anv¨andbar n¨ar man beh¨over en eller fler kvaliteter nedan:
• Paket i sekvensiell ordning • Garantera att paket kommer fram • Point-to-point
• Synkroniserad anslutning • S¨aker avslutning
3.4
Packet-Framing
TCP garanterar att paket kommer fram och i r¨att ordning. Det kan dock vara intressant f¨or den som ska behandla datan att veta n¨ar en f¨orv¨antad datam¨angd har kommit in innan denne b¨orjar bearbeta datan. Ett s¨att att g¨ora detta kallas Packet-Framing”. Packet-framing kan g¨oras p˚a flera s¨att, nedan beskrivs tv˚a av dessa(David Andersen, u. ˚a.).
Teckenavslut Denna metoden bygger p˚a att protokollet specifierar ett speciellt tecken som avs¨atts (eller en sekvens av tecken) f¨or att avsluta en datasekvens. Detta betyder att tecknet inte f˚ar f¨orekomma inuti sekvensen. Vid bin¨ar fil¨overf¨oring blir det ofta problem d˚a bin¨ara filer mycket v¨al kan inneh˚alla detta specialtecken.
Sekvensl¨angd Metoden bygger p˚a att du i b¨orjan av varje sekvens skickar ett nummer som motsvarar l¨angden p˚a den inkommande sekvensen. Fler bytes f¨or att representera nummer till˚ater l¨angre sekvenser.
3.5
Node.js
Node.js beskrivs i avsnitt B.2.0.4.
3.6
Websocket
Webbsocket anv¨ands f¨or att skapa en full duplexl¨ank mellan en klient och server ¨over http proto-kollet. Webbsocket ¨ar standardiserat av W3C(“w3c”, u. ˚a.) och finns i de st¨orre webbl¨asarna som Chrome, Firefox och Opera.
3.7
D3
Data-Driven Document, f¨orkortat D3, ¨ar ett ramverk som anv¨ands f¨or att designa interaktiva komponenter till webbsidor som representerar n˚agon form utav data. Man kan s¨aga att D3 ger liv till din data genom att anv¨anda sig utav HTML, SVG och CSS. D3 grundar sig p˚a att man f¨orst l¨aser in den data som man vill jobba med i ett s˚a kallat Document-Object-Model-element (ofta f¨orkortat DOM). N¨ar datan ¨ar bunden till DOM-elementet finns det ett stort utbud av transfor-mationer och anitransfor-mationer f¨or att kunna designa figurer och grafer av olika typer.
3.8
BeagleBone
BeagleBone ¨ar en l˚agenergi-enkortsdator anpassad f¨or att utvecklare ska kunna bygga en rad olika applikationer. BeagleBone var fr˚an b¨orjan byggt som en pedagogisk utvecklingsmilj¨o i syfte att utbilda anv¨andare i b˚ade h˚ardvara och mjukvara.
3.8.1 BeagleBone Black
BeagleBone Black ¨ar en vidareutveckling av BeagleBonen med mer RAM-minne och en snabbare processorklocka. BeagleBone Black inneh˚aller bland annat f¨oljande I/O anslutningar:
• USB-port • Ethernet-port • HDMI
• 46-pins-anslutningar
BeagleBone black inneh˚aller ¨aven en AD-omvandlare med en precision av 12 bitar med 125 nano-sekunders sampeltid(“BeagleBoard System”, u. ˚a.).
Figur 1 – Bild ¨over BeagleBone Black
3.8.2 ARM Cortex-A8
BeagleBone Black inneh˚aller ¨aven tv˚a stycken realtidsprocessorer av typen ARM Cortex-A8, dessa ben¨amns h¨adanefter som PRU. ARM Cortex-A8 ¨ar en 32-bitars processor med en klockfrekvens mellan 600 MHz och 1 GHz(Cortex-A8 processors, u. ˚a.).
4
Metod
I det h¨ar avsnittet beskriver vi hur vi har g˚att till v¨aga f¨or att samla in relevant data f¨or att besvara v˚ara fr˚agest¨allningar.
4.1
Utveckling av system
F¨or att unders¨oka m¨ojligheten att designa det nya systemet och f¨or att se om det gick att genomf¨ora det inom den givna tidsramen s˚a gjorde vi ett f¨ors¨ok att bygga det fr˚an grunden. Hur vi gjorde detta beskrivs i det h¨ar avsnittet.
4.1.1 Kravs¨attning
Kraven som kommer st¨allas p˚a systemet har arbetats fram tillsammans med kunden. Eftersom det redan fanns ett befintligt system s˚a visste kunden vilken funktionalitet som beh¨ovde finnas. Kunden hade d¨arf¨or tagit fram en kravspecifikation redan innan projektet som vi utgick ifr˚an. Efter lite korrigeringar kom vi fram till en kravspecifikation som b˚ada parter var n¨ojda med. F¨or att s¨akerst¨alla att vi byggde systemet enligt kundens ¨onskem˚al och informera kunden om v˚ar status s˚a tr¨affade vi v˚ar kund minst en g˚ang i m˚anaden. Vid dessa m¨oten f¨orevisade vi vad vi hade byggt och kunden fick chansen att ge feedback tidigt och tycka till om det var n˚agot vi missade eller dylikt.
4.1.2 Organisation
Nedan beskrivs hur vi organiserade projektarbetet. Figur 2 visar strukturen ¨over de inblandade parterna.
Figur 2 – Schema ¨over organisationen.
4.1.2.1 Projektgrupp F¨or att projektet ska lyckas har projektgruppen kommit ¨overens om ett antal ansvarsomr˚aden. Dessa ansvarsomr˚aden har f¨ordelats p˚a olika roller, d¨ar varje grupp-medlem har ˚atagit sig ansvar f¨or en specifik roll. Dessa roller ¨ar listade i tabell 1.
Titel Ansvarsomr˚ade Gruppledare Leder arbetet.
Ansvarar f¨or milj¨o, att processer f¨oljs och m˚aluppfyllnad. Har sista ordet och representerar gruppen ut˚at.
Leder, planerar och bokar lokal f¨or m¨oten. Analysansvarig Ansvarar f¨or kundens behov.
F¨orhandlingspart och orakel in mot ¨ovriga gruppen. Dokumenterar krav.
Kommunikation med kund skall i f¨orsta hand ske genom analysansvarig. Ansvarar f¨or kravuppfyllnads-status, f¨orhandling och uppfyllnad. Arkitekt Ser till att en stabil arkitektur tas fram.
Identifierar komponenter och gr¨anssnitt. Har sista ordet i teknikfr˚agor efter gruppledare. Dokumenterar arkitektur.
Utvecklingsledare Ansvarar f¨or detaljerad design.
Leder utvecklingsarbetet och beslutar om utvecklingsmilj¨o. Organiserar utvecklarens tester.
Beslutar om kodstandard och dokumentering. Testledare Beslutar om systemets status.
Sk¨oter den dynamiska verifieringen och valideringen av systemet. Ser till att systemet testas och p˚a r¨att s¨att.
Skriver testplan och testrapport.
Kvalitetssamordnare Initierar och f¨oljer upp kvaliteten f¨or systemet.
Planerar och budgeterar med gruppen f¨or kvalitetsarbetet. Skriver kvalitetsplan.
Dokumentansvarig Ansvarar f¨or fillagret och konfigurationshanteringen. Ansvarar f¨or att det finns mallar och logotyp.
Ansvarar f¨or ¨andringshantering och leveranser till deadlines. Tabell 1 – F¨ordelning av ansvarsomr˚aden.
4.1.2.2 Handledare Projektgruppen har haft tillg˚ang till en handledare. Handledaren har fungerat som ett st¨od och en resurs som kan svara p˚a och diskutera fr˚agor r¨orande projektarbetet, arbetss¨att, tekniska l¨osningar och kandidatrapporten. Handledaren har ocks˚a givit feedback p˚a den dokumentation vi skrivit.
4.1.2.3 Kund I projektgruppen ¨ar analysansvarige ansvarig f¨or att h˚alla kontakten med pro-jektets uppdragsgivare tillika kund och h˚alla denne informerad om v˚art arbete. Analysansvarig har tillsammans med kund tagit fram kravspecifikationen och s¨akerst¨allt att alla krav uppfyllts. Vi hade m¨oten med kund f¨or att presentera och demonstrera det system vi hade byggt f¨or att s¨akerst¨alla att det i s˚a h¨og grad som m¨ojligt uppfyller kundens ¨onskem˚al.
4.1.2.4 Projektets faser Projektet delades in i fyra faser, med olika m˚al f¨or varje fas. Faserna syftar till att tydligg¨ora projektets status f¨or examinator och kund. De syftar ocks˚a till att g¨ora det enklare f¨or projektgruppen att planera och organisera sitt arbete. En ¨oversiktlig planering av de olika faserna ges i figur 3
Figur 3 – Ursprunglig tidsplan
Den f¨orsta fasen, f¨orstudien, hade som m˚al att identifiera kundens behov, ta fram en kravspe-cifikation i samarbete med kund, planera projektet och p˚ab¨orja den dokumentation som kr¨avs. F¨orstudien var tre veckor l˚ang.
Under iteration 1 fokuserade projektgruppen p˚a att ta fram enkla prototyper f¨or att f˚a en tydligare bild av vad kunden verkligen ville ha. Denna prototyp utvecklades sedan vidare i iteration 2, d˚a den st¨orsta delen av systemets funktionalitet implementeras. I iteration 3 skulle slutprodukten kravvalideras inf¨or leverans. I slutet av varje fas omv¨arderade vi dessa m˚al och satte nya f¨or n¨astkommande fas.
4.1.2.5 Dokumentation Under projektet skrevs ett antal dokument. Syftet med dessa var att dokumentera projektet. De dokument som skulle skrivas presenteras i tabell 2.
Dokument Inneh˚all
Projektplan Dokumenterar hur projektet skall genomf¨oras.
Kravspecifikation Dokumenterar de krav som st¨alls p˚a systemet. Tas fram i samarbete mellan kund och projektgrupp.
Arkitekturplan Beskriver hur systemet ¨ar designat.
Kvalitetsplan Hj¨alpmedel f¨or att bedriva kvalitetsarbete p˚a systemet.
Testplan Beskriver hur systemet skall testas f¨or att verifiera systemets funktionalitet och kvalitet.
Testrapport Sammanst¨allning av de test som genomf¨orts p˚a systemet och systemets status.
M¨otesprotokoll Protokoll fr˚an gruppm¨oten, handledarm¨oten och kundm¨oten under projek-tets g˚ang.
Tabell 2 – De dokument som skrivs f¨or att dokumentera systemet och projektet.
LATEX Vi valde att skriva all dokumentation i typs¨attningsspr˚aket Latex eftersom det b˚ade ger
snyggare dokument och m¨ojlighet att versionshantera alla dokument med git.
Vi har anv¨ant en gemensam mall f¨or samtliga dokument, vilket inneb¨ar att v˚ara dokument har ett enhetligt utseende.
4.1.3 Arbets¨att
Vi valde att arbeta efter en agil-liknande metod d¨ar projektet delades in i flera faser som beskrivet i 4.1.2.4. Detta innebar att det f¨or varje fas sattes krav p˚a m˚al och funktionalitet som skulle utf¨oras.
Under f¨orstudien best¨amdes systemets ¨overgripande struktur. Vi gjorde olika gruppmedlemmar ansvariga f¨or olika delar av systemet. Detta har betytt att det alltid funnits n˚agon att fr˚aga g¨allande en specifik modul samtidigt som delegering av arbetsuppgifter fungerat relativt smidigt. Dessa identifieras till:
• Frontend • Backend • BeagleBone • PRU
Under f¨orstudien best¨amdes vilka gruppmedlemmar som skulle fokusera p˚a vilken modul och p˚a s˚a s¨att ha det yttersta ansvaret f¨or den modulen.
4.1.3.1 M¨oten Under projektets g˚ang har projektgruppen kontinuerligt haft ett flertal olika m¨oten. F¨orutom interna m¨oten med gruppen har vi ocks˚a haft ett m¨ote varje vecka med v˚ar handledare samt flera m¨oten med kund. Dessa m¨oten har haft olika syften, s˚a som att klarg¨ora projektets status och f˚a feedback p˚a det vi gjort. Vid m¨oten agerade normalt dokumentansvarige sekreterare med uppgift att skriva protokoll ¨over vad som sagts. Dessa protokoll lades sedan upp s˚a att alla i gruppen kunde komma ˚at dem.
Internm¨otena f¨oljde en tydlig struktur d¨ar f¨oljande fr˚agor ofta togs upp: • Hur arbetet har g˚att f¨or varje medlem
• Vilka m˚al som ska s¨attas till n¨asta iteration • Vilka m˚al som ska uppn˚as inom kommande tid
• Vilka m˚al som varje gruppmedlem siktar mot att n˚a den kommande tiden
4.1.3.2 Gitlab Vi har versionshanterat v˚ar kodbas. Vi valde systemet Git eftersom att vi alla har tidigare erfarenheter av det, kan det och tycker att det fungerar bra. Vi anv¨ande tj¨ansten Gitlab som tillhandah˚alls av IDA vid Link¨opings universitet. Vi anv¨ande tv˚a Git-repositories, ett f¨or dokumentation och ett inneh˚allandes v˚ar kod.
4.1.3.3 Redmine Redmine ¨ar en issue-tracker. Redmine ger tillg˚ang till att skapa aktiviteter. Varje aktivitet kan vara av olika typer som funktionalitet, organisation eller bugg. Via aktiviteter kan man logga antalet timmar som l¨aggs p˚a den aktiviteten, se vem som ¨ar ansvarig f¨or aktiviteten och om aktiviteten ¨ar gjord eller l¨ost. Vi valde att anv¨anda Redmine f¨or att skapa aktiviteter som ska g¨oras, buggar som ska l¨osas och logga antalet timmar vi jobbar och p˚a vad vi jobbar.
4.1.4 Uppsamling av erfarenheter
I slutet av iteration 3 genomf¨orde hade vi ett erfarenhetsm¨ote. Under detta m¨ote fick alla chansen att ta upp och diskutera sina erfarenheter vilket sedan antecknades.
4.1.5 J¨amf¨orelse med f¨org˚aende system
Vi hade tyv¨arr inte tillg˚ang till det f¨oreg˚aende systemet under utvecklingen. F¨or att ta reda p˚a hur v˚art system stod sig mot det f¨oreg˚aende fick vi ist¨allet g˚a mestadels p˚a vad kund ber¨attat om systemet. Vi kunde ocks˚a se i hur h¨og grad vi uppfyllde kravspecifikationen, vilken till stora delar var baserad p˚a det f¨oreg˚aende systemet. Uppfyller vi kravspecifikationen har vi all funktionalitet det f¨oreg˚aende systemet hade och lite till.
4.2
Designbeslutsprocess
I det h¨ar avsnittet definieras den metod vi anv¨ande f¨or att f¨ors¨oka f¨orb¨attra v˚ar designbeslutspro-cess.
4.2.1 Identifiera problem med designbeslutsprocess
F¨or att f¨orb¨attra designbeslutsprocess har vi valt att identifiera problem med den designbesluts-process som anv¨ants. Dessa problem har sedan analyserats f¨or att utr¨ona om det ¨ar brister i v˚ar designbeslutsprocess som har orsakat dem.
4.2.2 Analys av designbeslutsprocess
F¨or att f¨orb¨attra processen analyserades problemen som vi st¨otte p˚a under projektets g˚ang, samtidigt gjordes antaganden om vart i designbeslutsprocessen problemet uppstod. V˚ar process j¨amf¨ordes med andra beslutsmetoder. En slutsats drogs sedan om hur vi kunde f¨or¨andra v˚ar designbeslutsprocess f¨or att f¨orhindra att liknande problem uppst˚ar.
5
Resultat
I detta avsnitt redog¨or vi f¨or de resultat vi uppn˚adde, hur vi uppn˚adde dem och vilka erfarenheter vi som grupp tar med oss fr˚an det h¨ar arbetet.
5.1
Kravh¨
amtning
De krav som vi arbetade efter finns dokumenterade i kravspecifikationen som vi tog fram tillsam-mans med kunden i projektets f¨orstudiefas. Kravspecifikationen ¨ar uppbyggd av ett antal bin¨ara krav (dvs de kan endast uppfyllas helt eller inte alls). Eftersom systemet ¨ar uppdelat i mindre moduler ¨ar kraven relevanta f¨or en specifik modul. Kraven har ¨aven olika prioriteringsgrad d¨ar de listade med en etta motsvarar krav som skall vara uppfyllda efter projektets slut. De med l¨agre prioritering (tv˚a eller tre) ses ¨over i m˚an av tid.
5.2
Overgripande l¨
¨
osning
Enligt kraven fanns det ett antal f¨oruts¨attningar f¨or systemet. M¨atstationer ska kunna placeras ute i f¨alt och med hj¨alp av en prob utf¨ora m¨atningar p˚a vatten. M¨atstationer ska vara implemen-terade p˚a en BeagleBone Black. Ett webbgr¨anssnitt som kan k¨oras i Google Chrome ska finnas f¨or att komma ˚at data, se status f¨or m¨atklienter och ¨andra m¨atklienternas konfiguration.
Med denna information k¨andes det sj¨alvklart att en centraliserad server kr¨avs. Den ska tillhan-dah˚alla webbgr¨anssnittet och kommunicera med m¨atklienterna. En ¨overblick kan ses i figur 4.
Webbklient Server
M¨atenhet
Figur 4 – ¨Oversikt av systemet
En centraliserad server ¨ar b¨asta l¨osningen d˚a m¨atklienter och anv¨andare kan sitta bakom olika sorters brandv¨aggar som skulle om¨ojligg¨ora direktkommunikation. Det ¨ar ocks˚a smidigt att samla all data p˚a ett och samma st¨alle.
5.3
H˚
ardvara
Ett krav fr˚an kunden var att en m¨atstation skall best˚a av en BeagleBone Black, se kapitel 3.8. BeagleBone Black skulle kopplas ihop med en prob och f¨or att integrera den analoga proben med BeagleBone Black beh¨ovdes en D/A- och A/D-omvandlare.
Eftersom BeagleBone Black endast hade 12 bitars precision kunde denna inte anv¨andas f¨or att omvandla den analoga signalen, d˚a kunden kr¨avde en uppl¨osning p˚a 16 bitar. Ist¨allet anv¨andes en extern D/A- och A/D-omvandlare beskriver i kapitlet nedan.
5.3.1 D/A- och A/D-omvandlare
F¨or att stimulera och l¨asa av m¨atproben s˚a fick vi ett analogt gr¨anssnitt ifr˚an kunden best˚aende av en Analog Shield ifr˚an Digilent. Detta kort inneh˚aller en D/A- och en A/D-omvandlare som kon-trolleras via en gemensam SPI-buss. D˚a SPI inte ¨ar en strikt standard s˚a f¨oljer inte D/A- och A/D-omvandlaren samma standarder f¨or kommunikation, utan de vill ha olika polaritet f¨or klockpulser och data under ¨overf¨oringar. P˚a m¨atenheten s˚a ¨ar det PRU:n som styr SPI-kommunikationen, eftersom PRU:n inte har n˚agon SPI-h˚ardvara s˚a ¨ar protokollet implementerat i mjukvara. 5.3.2 Realtidsdator
D˚a ett vanligt Linuxprogram inte uppfyller kraven p˚a stabil sampling i 1 kHz s˚a beh¨ovde vi n˚agot att l¨agga denna tidskritiska funktionalitet p˚a. D˚a BeagleBone Black inneh˚aller ett s˚a kallat ”Programmable Realtime Unit SubSystem” med tv˚a PRU-k¨arnor specifikt designade f¨or att kunna avlasta s˚adan tidskritisk funktionalitet s˚a var de l¨ampliga att implementera samplingen p˚a. Mer om denna l¨osning beskrivs i kapitel E. Sebastian - Implementation av realtidsfunktionalitet.
5.4
M¨
atenhet
I detta avsnitt beskriver vi hur vi valt att konstruera m¨atenheten. 5.4.1 Programstruktur
Vi valde att anv¨anda programmeringsspr˚aket Python p˚a m¨atenheten dels d˚a det var ett ¨onskem˚al ifr˚an kunden, dels d˚a det fungerar bra b˚ade f¨or att kommunicera med servern och f¨or att kommuni-cera med PRU:n via en C-wrapper. Python fungerar ¨aven bra i den Linux-milj¨o vi var begr¨ansade
till och det ¨ar ett spr˚ak vi hade tidigare erfarenhet av och k¨ande oss bekv¨ama med.
Figur 5 ger en snabb ¨overblick av hur vi valde att strukturera programvaran p˚a m¨atenheten. PRU:n hanterar det analoga gr¨anssnittet och utf¨or sj¨alva m¨atningarna, PruHandler hanterar PRU:n, h¨amtar m¨atningar fr˚an denna och presenterar f¨or Main som kommunicerar med servern fr˚an vilken den h¨amtar parametrar och skickar m¨atningar.
Main PRU interface
PRU
Figur 5 – ¨Oversikt av M¨atenhetens struktur
5.4.2 Programvara PRU
PRU:ns program best˚ar av en mainloop som med hj¨alp av en h˚ardvarutimer k¨ors med en periodtid p˚a 0,1 ms. I varje iteration av loopen s˚a kontrolleras f¨orst vilket tillst˚and som ¨ar satt. Det finns tv˚a olika tillst˚and, run och idle. I idle s˚a g¨ors ingenting f¨orutom att s¨atta utsignalen p˚a D/A-omvandlaren till 0 V och i run s˚a ¨okas tre tidsr¨aknare med periodtiden. R¨aknarna styr om en ny m¨atsampel ska tas och l¨aggas i den delade bufferten, om en ny puls i pulst˚aget ska skickas ut, eller om det ¨ar dags att p˚ab¨orja ett nytt pulst˚ag och en ny sampling. I slutet av varje iteration, oavsett l¨age, s˚a l¨ases temperatursensorn av och temperaturen skrivs till det delade minnet.
5.4.3 Delat minne
F¨or att ¨overf¨ora m¨atdata fr˚an PRU:n till Linux-sidan hade vi tv˚a alternativ. Antingen kunde vi l¨agga in m¨atdata direkt i RAM fr˚an PRU:n eller s˚a kunde vi anv¨anda ett s¨arskilt minne som delas mellan de b˚ada PRU:erna och ARM-processorn. PRU:n kan l¨asa och skriva till det delade minnet p˚a en klockcykel. Det ¨ar dock bara 12 kB stort.
En typisk m¨atning, dvs alla sampel, ¨ar i storleksordningen 80 kB. F¨ordelen med att skriva till RAM skulle vara att vi kan spara hela m¨atningar utan att dela upp dem. Nackdelen med att anv¨anda RAM ¨ar att det tar mycket l¨angre tid f¨or PRU:n att skriva till detta och implementationen hade varit kr˚angligare d˚a vi m˚aste allokera en m¨angd RAM som PRU:n f˚ar skriva till och kommunice-ra dessa minnesadresser till PRU:n. Med det delade minnet ¨ar det precis tv¨artom. Nackdelen ¨ar att vi m˚aste dela upp en m¨atning i flera delar eftersom hela m¨atningen inte f˚ar plats i minnet. F¨ordelarna ¨ar att det g˚ar snabbt f¨or PRU:n att l¨asa och skriva till minnet och implementationen blir enklare d˚a adressen till det delade minnet ¨ar alltid tillg¨anglig.
Vi gjorde bed¨omningen att eftersom en m¨atning sker ¨over flera sekunder s˚a kan programmet p˚a Linuxsidan l¨asa data snabbare ¨an PRU:n hinner skriva. Vi har d¨arf¨or bra m¨ojligheter att skicka m¨atningar i delar. Vi valde att anv¨anda det delade minnet och implementera en cirkul¨arbuffer i detta f¨or att f¨ora ¨over data till Linuxsidan.
Eftersom m¨angden parametrar som ska skickas till PRU:n ¨ar begr¨ansade, 5 parametrar och upp till 100 olika step levels, valde vi att helt enkelt dedikera minnesplatser till varje parameter i det delade minnet. Alternativet hade varit att ha en buffer ocks˚a till PRU:n, alternativt implementera buffer-ten som en tv˚av¨agsbuffer, och ha kontinuerlig tv˚av¨agskommunikation. F¨ordelarna med detta hade varit att vi kan anv¨anda hela det delade minnet som buffer och om det i framtiden finns behov av att ut¨oka funktionaliteten hos PRU:n s˚a finns ett generellt protokoll f¨or kommunikation till denna. De fem parametrarna ¨ar implementerade som 32-bitars heltal och varje step level ¨ar ett 32-bitars flyttal, det blir sammanlagt 420 byte. Vi gjorde bed¨omningen att dessa bytes inte skulle begr¨ansa prestandan i systemet n¨amnv¨art. Om inte de resterande 11,5 kB r¨acker har vi st¨orre problem n˚agon annanstans. Dessutom kunde vi specificera de dedikerade minnesadresserna i en header-fil, vilket skulle g¨ora implementationen av nya parametrar trivial vad g¨aller plats i det delade minnet.
Adress Inneh˚all Skrivs av
0x0000 STEP TIME PruHandler
0x0004 NUMBER OF STEPS PruHandler 0x0008 STEP LEVELS PruHandler ..
. Step levels PruHandler
0x0194 Slut Step levels PruHandler 0x0198 SAMPLE RATE PruHandler 0x019C REPEAT RATE PruHandler
0x0200 MODE PruHandler
0x0204 TEMP PRU
.. .
0x0300 LOST DATA PRU
0x0304 BUF HEAD PRU
0x0308 BUF TAIL PruHandler
0x030C BUF START PruHandler
0x0310 BUF END PruHandler
.. .
BUF START Bufferns b¨orjan PRU ..
. Bufferdata PRU
BUF END Bufferns slut PRU
Tabell 3 – Vad det delade minnet inneh˚aller, och vem som skriver vad.
Tabell 3 visar inneh˚allet i det delade minnet enligt tidigare n¨amnda header-fil. Denna delas mellan pru_interface och PRU:ns programvara f¨or att undvika situationer d¨ar olika delar av systemet letar p˚a olika st¨allen efter samma sak samt f¨or att g¨ora det trivialt att ¨andra f¨ordelningen av inneh˚allet i detta minne. Notera dessutom att BUF START och BUF END ¨ar dynamiska och styrs fr˚an PruHandler och skulle kunna ¨andras under k¨orning (befintlig data i bufferten g˚ar dock f¨orlorad).
Buffern fungerar i ¨ovrigt som s˚a att PRU skriver och Linux l¨aser. BUF HEAD pekar p˚a det se-naste v¨arde PRU:n skrev, och BUF TAIL p˚a n¨asta v¨arde programmet p˚a Linux-sidan ska l¨asa. Normalt skriver PRU:n fyra v¨arden till bufferten per sampel. F¨orst kommer ett 32 bitars hel-tal med sampleid, vilket hel-talar om f¨or oss vilket sampel i m¨atningen vi ¨ar p˚a. Detta anv¨ands i PruHandler f¨or att kontrollera att h¨amtad data inte ¨ar korrupt (att datapunkter tappats). Sedan skrivs tre 32 bitars flyttal med uppm¨att probdata. Skulle bufferten vara full, ¨okar PRU:n storleken p˚a LOST DATA med ett. Detta v¨arde anv¨ands dock f¨or n¨arvarande inte till n˚agot annat ¨an att testa och debugga systemet.
5.4.4 Gr¨anssnitt mot PRU
Figur 6 visar hur vi valt att strukturera det interface genom vilket vi anv¨ander PRU:n.
PruHandler pru interface libpru prussdrv mio Delat minne PRU
Figur 6 – ¨Oversikt av interfacet mot PRU
5.4.4.1 prussdrv D˚a PRU:n ¨ar integrerad i BeagleBone kretsen beh¨ovde vi ett interface f¨or att hantera denna. Texas Instruments som tillverkar processorn tillhandah˚aller ett bibliotek f¨or att hantera PRU:en, prussdrv, vilket inneh˚aller funktionalitet f¨or att initiera, ladda in och starta program p˚a PRU:n.
5.4.4.2 mio Vi skrev sj¨alva koden vi anv¨ander f¨or att l¨asa och skriva till det delade minnet, mio, det inspirerades av kod fr˚an biblioteket pru_sdk. Vi anv¨ande ursprungligen pru_sdk men det uppfyllde inte riktigt v˚ara ¨onskem˚al. Detta ledde till att vi skrev ett nytt interface. Vi anv¨ander prussdrv som¨ar skrivet i spr˚aket C. Vi valde d˚a att forts¨atta anv¨anda C ¨aven f¨or interfacet mot det delade minnet eftersom det ¨ar naturligare att arbeta med minnespekare i C ¨an i Python. 5.4.4.3 libpru Vi valde att skriva ett gemensamt C-interface f¨or dessa tv˚a moduler, libpru. I interfacet implementerade vi funktioner f¨or att hantera den delade bufferten och setters f¨or alla parametrar med undantag f¨or step_levels, d˚a dessa var enklare att implementera i Python. Det var smidigt att implementera denna funktionalitet i C delvis p˚a grund av den header-fil med dedikerade minnesadresser som delas med PRU:n. Hade vi implementerat det i Python hade vi beh¨ovt ha en kopia p˚a dessa konstanter i ett format som Python kan f¨orst˚a.
5.4.4.4 pru interface Vi valde att b¨adda in C-koden med Python-biblioteket Ctypes. Vi ans˚ag att det vi skulle g¨ora varken var s˚a omfattande att vi hade tj¨anat p˚a att anv¨anda ett autogenererat interface som SWIG eller s˚a prestandakritiskt att vi hade tj¨anat p˚a att anv¨anda Cython. Ctypes ¨ar enkelt att anv¨anda, man pekar p˚a en kompilerad objektfil och specificerar vad
inparametrar och returv¨arden har f¨or datatyper. Cython sk¨oter sedan konverteringen mellan Pyt-hons datatyper och motsvarande datatyper i C.
Vi implementerade den funktionalitet som saknades i pru_interface, som setters f¨or step_levels och skapade ett paket, pru_interface, f¨or att h˚alla arbetsmappen ren.
5.4.4.5 PruHandler Det st¨orsta problemet med att anv¨anda en buffer i det delade minnet ¨ar att den har en begr¨ansad storlek vilket inneb¨ar att vi m˚aste l¨asa den data PRU:n skriver konti-nuerligt. Vi m˚aste dessutom l¨asa minst lika fort som den skriver f¨or att inte f¨orlora m¨atdata. F¨or att vi inte ska hamna i en situation d¨ar vi endast t¨ommer bufferten i slutet av en l˚ang mainloop och d¨arf¨or m˚aste anpassa mainklienten efter denna tidskritiska del av systemet s˚a valde vi att im-plementera en helt separat tr˚ad, PruHandler, vars uppgift det blir att hela tiden t¨omma bufferten och presentera hela m¨atningar mot m¨atklienten. F¨or att vi inte ska hamna ur synk med oss sj¨alva s˚a hanteras all kommunikation med PRU genom denna tr˚ad.
PruHandler ¨ar uppdelad i tv˚a delar, PruHandlerThread som ¨ar den tr˚ad som hanterar PRU:n, och PruHandlerInterface som ger oss verktyg att hantera tr˚aden. PruHandlerThread styrs av tv˚a dictionaries, ett inneh˚allandes flaggor som talar om f¨or tr˚aden vilket tillst˚and den be-finner sig i och ett som inneh˚aller de parametrar som ska k¨oras p˚a PRU:n. De resulterande m¨atningarna l¨aggs i en k¨o fr˚an vilken PruHandlerInterface kan h¨amta dem. Dessa tre objekt skapas i PruHandlerInterface och delas sedan med PruHandlerThread. I PruHandlerInterface ˚aterfinns sedan funktioner f¨or att ¨andra flaggor, parametrar och returnera m¨atningar. Dessa ab-straktionslager, visualiserade i figur 7 resulterar i att m¨atklienten ¨ar helt skild fr˚an driften av PRU:n. Vi skulle kunna byta ut PRU:n mot n˚agot annat utan att beh¨ova ¨andra n˚agot annat ¨an PruHandler. PruHandlerInterface PruHandlerThread flags parameters measurement queue Main m¨atpunkt temperatur set parameters(parameters) get queue size()
set mode(mode) get measurement() get temp()
Figur 7 – Kommunikationsv¨agar i PruHandler
D˚a m¨atenheten ¨ar i RUN, t¨ommer PruHandlerThread bufferten med j¨amna mellanrum. D˚a m¨atenhetens parametrar eller tillst˚and f¨or¨andras, vilket alltid ska ske i d˚a enheten ¨ar i IDLE, skriver tr˚aden dessa till det delade minnet d¨ar PRU:n kan anv¨anda dem. PruHandlerThread g¨or ocks˚a en enkel kon-troll av inl¨asta v¨arden genom att kontrollera sampleid och se till att det inte tog f¨or l˚ang tid att l¨asa in m¨atningen. Om n˚agot fel uppt¨acks, markeras m¨atningen som korrupt och sedan f¨ors¨oker tr˚aden r¨atta till problemet genom att kassera resten av m¨atningen och f¨ors¨oka hitta starten p˚a n¨asta m¨atning. Ser m¨atningen korrekt ut, filtrerar vi bort sampleid och l¨agger m¨atningen i k¨on.
5.4.5 M¨atklient
M¨atklienten har tv˚a uppgifter den ska klara av f¨or att uppfylla kraven. Varje del av dessa tv˚a kan hanteras individuellt och det ¨ar s˚a koden ¨ar uppbyggd. De kan hanteras individuellt p˚a grund av att n¨atverksdelen ¨ar en funktionalitet i sig sj¨alv och att hantera m¨atningar ¨ar en annan. Att n¨atverket g˚ar ner f˚ar inte p˚averka m¨atningsdelen s˚a det ¨ar naturligt att dela upp dem. Dessa tv˚a uppgifter ¨ar allt m¨atklienten beh¨over g¨ora, s˚a den ligger i en o¨andlig loop och utf¨or dem. Varje uppgift best˚ar av underuppgifter. Bild 8 illustrerar dess underuppgifter.
Figur 8 – Illustration av m¨atenhetens loop.
5.4.5.1 N¨atverkshantering N¨atverkshanteraren har som uppgift att koppla upp sig mot servern och sk¨ota kommunikationen mellan dem. Detta inneb¨ar att den ska se till att kopp-la upp sig n¨ar det ¨ar m¨ojligt och skicka lokalt sparade m¨atningar som servern ¨annu inte f˚att. F¨or att utf¨ora sin uppgift anv¨ands ett antal klasser som SocketHandler, PacketBuilder och Measurehandler. Sockethandler sk¨oter den interna datastrukturen f¨or sockets och ger funktio-nalitet f¨or att skicka paket enligt protokollet. PacketBuilder anv¨ands f¨or att skapa paketen som skickas och Measurehandler har som uppgift att se till att h˚alla reda p˚a m¨atningar. Logiken ¨ar strukturerad p˚a f¨oljande s¨att:
• Om ej uppkopplad → koppla upp
• Om uppkopplad och ej autentiserad → autentisera • Om uppkopplad och b¨or skicka status → skicka status • Om uppkopplad och kan skicka m¨atning → skicka m¨atning • Om uppkopplad → hantera l¨asning fr˚an servern
• Om n¨atverksfel → koppla ned
5.4.5.2 M¨atningshanteraren M¨atningshanteraren har som uppgift att se till att ta m¨atningar och spara dem. Detta g¨or det med hj¨alp av PruHandler. PruHandlerInterface ger tillg˚ang till nya m¨atningar. M¨atningshanteraren kontrollerar om det finns n˚agon ny m¨atning och sparar den lokalt i filsystemet.
5.4.5.3 Filsystemet F¨or filsystemet diskuterades ett antal l¨osningar. De som diskuterades var en lokal databas, samtliga m¨atningar i en fil eller varje m¨atning i varsin fil. Att anv¨anda en databas utesl¨ots snabbt d˚a den skulle kr¨ava on¨odigt mycket prestanda. Vi valde att spara varje m¨atning i varsin fil d˚a det var enklare att implementera. Vid str¨omavbrott ¨ar det bara den m¨atning som skrivs vid str¨omavbrottstillf¨allet som har risken att bli korrupt.
N¨ar det var beslutat att varje fil skulle sparas individuellt ville vi ¨and˚a strukturera det s˚a varje m¨atsession h¨oll ihop och slutimplementationen blev enligt nedan.
En fil inneh˚aller en JSON-lista ¨over m¨atsessioner som inte ¨ar skickade. Sedan sparas alla m¨atsessioner i egna mappar. Dessa mappar har sessionid:t som namn. I varje mapp finns en fil som inneh˚aller en JSON-dictionary med nycklar till sessionid, antalet m¨atningar och skickade m¨atningar. M¨atningar sparas p˚a fil med m¨atningsnummret som namn i m¨atsessionsmappen. Bild 9 illustrerar filsystemet.
I filsystemet kan fem saker intr¨affa. Nedan beskrivs hur dessa p˚averkar systemet. • En ny m¨atsession startas.
– M¨atsessionid:t l¨aggs till i JSON-listan ¨over m¨atsessioner. – M¨atsessionsmappen skapas.
– Filen med JSON-dictionaryn ¨over m¨atningar skapas i m¨atsessionsmappen. • En m¨atning sparas.
– En fil inneh˚allande m¨atningen sparas i m¨atsessionsmappen med m¨atningens id som namn.
– JSON-dictionaryn uppdateras med nya antalet m¨atningar f¨or sessionen. • En m¨atning skickas.
– Filen inneh˚allande m¨atningen l¨ases men filsystemet f¨orblir of¨or¨andrat. • En m¨atning har skickats.
– JSON-dictionaryn uppdateras med antalet skickade m¨atningar f¨or den sessionen. • En m¨atsession har skickats.
– M¨atsessionid:t tas bort ur JSON-listan med m¨atsessioner.
Ingen av dessa h¨andelser jobbar p˚a m˚anga filer samtidigt och vid str¨omavbrott ¨ar det bara filer som skrivs som kan bli korrupta. Eftersom de viktiga filerna ¨ar sm˚a, och skrivs v¨aldigt s¨allan minimerar vi risken f¨or detta. Och det ¨ar oftast bara en m¨atning eller en m¨atsession som kan bli korrupt. Det ¨ar bara n¨ar JSON-listan med alla m¨atsessioner skrivs vi kan f¨orlora all lokal data.
5.5
Server
Vid valet av serverutvecklingsverktyg fanns det en uppsj¨o av alternativ: PHP, Node.js, Python-Web, Java och .Net. Det finns f¨or- och nackdelar med alla utvecklingsspr˚ak, beroende p˚a vilka uppgifter som ska l¨osas. Eftersom enheterna laddar upp data till servern kontinuerligt s˚a kr¨avs det en server som kan hantera IO-operationer i stor skala. Detta var en av anledningarna till att vi valde Node.js som ¨ar ett eventdrivet ramverktyg som bygger p˚a Chrome V8 javascript-motor. En unders¨okning (Kai Lei, Yining Ma & Zhi Tan3, 2014) visar att Node.js presterar b¨attre ¨an m˚anga av sina konkurrenter vid tunga IO-operationer och ¨aven n¨ar antalet anslutna klienter ¨okar blir responstiden n¨astintill densamma. De flesta gruppmedlemmar har ¨aven erfarenhet av Java-script vilket g¨or utvecklandet och f¨orst˚aelsen av serverkod enklare. Node.js har st¨od f¨or MongoDB och med hj¨alp av modulen mongoose blir det enkelt att bygga ODM-modeller.
5.6
Serverarkitektur
Servern ¨ar uppdelade i tv˚a st¨orre komponenter:
• En TCP-del som hanterar anslutningar och IO-operationer mot m¨atenheter • En webbdel som hanterar anslutningar mot webben
5.6.1 TCP
Vi valde att kommunicera med m¨atenheterna ¨over TCP d˚a det garanterar att paketen kommer fram s˚a l¨ange en anslutning mellan parterna ¨ar tillg¨anglig. TCP segmenterar paketen vilket in-neb¨ar att det inte ¨ar garanterat att hela meddelandet inkommer direkt.
Enligt 3.4 beskrivs tv˚a l¨osningar f¨or att paketera data. Vi valde att anv¨anda oss av sekvensl¨angdsmetoden, d¨ar de fyra f¨orsta byten beskriver l¨angden p˚a meddelandet. Problemet med att anv¨anda sig av tec-kenavslut ¨ar att identifieraren m˚aste vara unik, vilket blir ett problem d˚a vi s¨ander icke ¨overvakad bin¨ardata. I v¨arsta fall leder detta till att symbolen finns i bin¨ardatan och kommunikationslogiken blir ur synk.
Kommunikationsl¨anken mellan m¨atenheten och server var strikt specifierat i ett protokoll, d¨ar varje meddelande inleddes med en tag som identifierade vilket typ av meddelande som var p˚av¨ag:
Length Tag Payload 4 bytes 2 bytes Data
5.6.2 Webb
Webbservern ¨ar uppdelad i tre delar:
• Statisk filserver som levererar CSS-, Javascript- och HTML-filer
• Datadriven server som levererar ett REST-API mot en godtycklig klient som kan hantera HTTP-protkollet
• En ¨oppen WebSocket som i realtid s¨ander information till webbklienten
N¨ar en anv¨andare anslutar mot servern genom en webbl¨asare sker kommunikation mellan server och klient enligt figur 10.
Figur 10 – Sekvensdiagram ¨over kommunikation mellan server och webbklient
5.6.2.1 API Vi valde att anv¨anda oss av ett REST-API f¨or att bygga en godtycklig data-driven server. Anledningen ¨ar att det blir enkelt att utveckla godtyckliga grafiska gr¨anssnitt mot exempelvis en applikation i Android eller Iphone.
API:t ¨ar byggt med hj¨alp av express som ¨ar ett ramverktyg till Node.js, gjort f¨or webbapplika-tioner. Den generella strukturen f¨or konstruktionen av API:erna f¨oljde ofta samma metodik:
• CheckInput - Verifiera att det ¨ar korrekta parameterar som skickas in, det vill s¨aga filtrera bort parametrar som kan anv¨andas f¨or att komma ˚at k¨anslig data
• ValidateInput - Verifiera att parametrarna ¨ar i korrekt format
• BuildQuery - Bygg en s¨okstr¨ang f¨or att exempelvis l¨agga till eller hitta i databasen • ReturnMessage - Skicka tillbaka ett svar till anv¨andaren i form av en JSON-str¨ang 5.6.2.2 WebSocket Fr˚an kundens sida fanns det krav p˚a att information om temperatur, minne och diskutrymme skulle visas p˚a webbsidan i realtid. Det finns tv˚a vanliga l¨osningar till pro-blemet, d¨ar klienten kontinuerligt ska vara uppdaterad om vad som sker p˚a de olika m¨atenheterna. Antingen fr˚agar klienten om ny information har kommit in, i form av polling. Detta inneb¨ar att mycket utav kommunikationen mellan server och klienten blir on¨odig, vilket var n˚agonting vi ville undvika.
Genom att ¨oppna upp en WebSocket-l¨ank f¨or klienterna mot servern kunde kommunikation i full-duplex uppr¨atth˚allas och klienten slipper polla om ny information.
5.6.3 MongoDB vs MySQL
I detta projekt har vi en m¨atenhet som skickar en stor m¨angd data till servern som sedan sparar undan all data. En anv¨andare kan sedan h¨amta data genom att g˚a in p˚a hemsidan och ladda ner den. En viktig po¨ang ¨ar att databasen kommer anv¨andas f¨or att skriva v¨aldigt mycket mer ¨an vad den kommer anv¨andas f¨or att l¨asa och skicka iv¨ag data till anv¨andaren.
Eftersom vi inte har haft tid att testa tv˚a olika databaser sj¨alva s˚a har vi utg˚att fr˚an andra personer som har genomf¨ort samma typer av tester som vi skulle ha skapat. I ett test mellan MongoDB, MySQL och Cassandra (som ¨ar en annan databas) f¨or att se vilken databas som ¨ar b¨ast f¨or ett loggsystem vann MongoDB ¨overl¨agset. Vid ins¨attning av 375 000 element var MongoDB mer ¨an tio g˚anger s˚a snabbt som MySQL, ¨aven svarstiden var mindre f¨or MongoDB. Figur 11 och figur 12 visar hur ¨overl¨agset MongoDB ¨ar n¨ar det kommer till logsystem. Det enda testet d¨ar MySQL var b¨attre ¨an MongoDB p˚a var vid m¨atning av CPU-anv¨andningen. (Marcus Olsson, 2014)
Figur 12 – Tids˚atg˚ang f¨or loggsystem.
I slut¨andan beslutade vi att anv¨anda ett filsystem f¨or att spara m¨atdatan ist¨allet f¨or att spara den i databasen. Detta har gjort att valet av databas inte blev lika viktigt, d˚a det sannolikt inte blir n˚agon n¨amnv¨ard skillnad n¨ar det bara ¨ar v¨aldigt lite data som beh¨over h¨amtas. Hade vi inte gjort detta och sparat all m¨atdata i databasen hade MongoDB varit ett b¨attre val.
5.6.4 Databasmodeller
F¨or att m¨atningar skall kunnas sparas korrekt till servern kr¨avs det databasmodeller som specifi-erar serverns funktionalitet mot webbklienter och m¨atenheter.
Databasmodellerna kan delas upp i tv˚a st¨orre delmodeller: • Unit collection
• User collection
5.6.4.1 Unit collection Unit collection inneh˚aller f¨oljande ODM-modeller: • Unit
• MeasureSession • Measure
Unit inneh˚aller information om m¨atenheten samt attribut f¨or att autentisera en m¨atenhet, se nedan.
Attribut namn Datatyp Syfte
mac addr Str¨ang Spara datorn unika mac address last ip Str¨ang Spara datorn senaste anv¨anda ip
name Str¨ang Datorn unika namn
session token Str¨ang En unik token som anv¨ands av m¨atenheten f¨or att autentisera sig file desc Str¨ang Var i filsystemet den har sin unika mapp
status running Boolean Vilket tillst˚and enheten ¨ar i latest sent Datum N¨ar det senaste paketet skickades latest measure session Str¨ang Refererar till senaste m¨atparametrarna MeasureSession inneh˚aller information om hur de olika m¨atparametrarna lagras f¨or, se nedan.
Attribut namn Datatyp Syfte
unit Str¨ang Refererar till vilken enhet den ¨ar kopplade till
createdBy Str¨ang Refererar till vilken anv¨andare som skapade m¨atparametrarna file desc Str¨ang Var i filsystemet alla m¨atningarna kopplade till dessa step time Heltal Definierar hur l˚ang tid i millisekunder ett sample ska tas nr of steps Lista Definierar hur m˚anga pulser det finns i pulst˚aget
step lvls Lista Beskriver vilken sp¨anning [mV] varje puls i pulst˚aget har sample rate Heltal Definierar hur l˚ang tid i millisekunder det ¨ar mellan varje puls
repeat rate Heltal Definierar hur ofta man g¨or en m¨atning
Repeat rate ¨ar hur ofta man g¨or en m¨atning. Measure inneh˚aller information om hur de olika m¨atningarna lagras, se nedan.
Attribut namn Datatyp Syfte
measure session Str¨ang Refererar till den kopplade m¨atparametern file desc Str¨ang Var i filsystem denna m¨atning ¨ar temperature Heltal Temperaturen f¨or m¨atningen
timestamp Heltal N¨ar m¨atningen gjorde i m¨atenheten, m¨att i NTP-standardtid sedan UNIX epoc.
5.6.4.2 User collection User inneh˚aller information om hur anv¨andaren lagras.
Attribut namn Datatyp Syfte
username Str¨ang Anv¨andarnamn f¨or inloggning
password Str¨ang L¨osenord f¨or inloggning, detta ¨ar hashat och saltat med ett unikt salt
email Str¨ang Anv¨andarens email
salt Str¨ang Unikt salt f¨or varje anv¨andare admin Boolean Om anv¨andaren ¨ar admin eller inte
5.7
Webbgr¨
anssnitt
M˚anga av de kraven v˚ar kund hade p˚a v˚art system kretsade kring hur webbgr¨anssnittet skulle se ut och vad det skulle inneh˚alla. Det befintliga systemet som vi skulle ers¨atta hade enligt kunden ett tr˚akigt utseende och “icke-responsivt” beteende. Kunden var tydlig med att v˚ar version skulle vara mer anv¨andarv¨anlig, vilket p˚averkade flertalet designbeslut vi tog.
5.7.1 Bootstrap
Bootstrap ¨ar ett ramverk som ¨ar popul¨art n¨ar man ska bygga responsiva hemsidor. Bootstrap inneh˚aller HTML- och CSS-baserade modeller f¨or typsnitt, indataformul¨ar, knappar och dylikt. Det positiva med Bootstrap ¨ar att alla dessa komponenter blir responsiva. Ett exempel kan vara att om man har musmark¨oren ¨over en knapp ¨andrar knappen f¨arg.
Det finns ¨aven ett Javascript-bibliotek som m¨ojligg¨or att man ger komponenter liv. Vi anv¨ander oss till exempel av “dropdown-menyer”, vilket ¨ar en meny som dyker upp under en knapp n¨ar den klickas p˚a.
5.7.2 DataTables
DataTables ¨ar ett plugin som anv¨ands f¨or att g¨ora vanliga HTML-tabeller mer interaktiva och ge dem ut¨okad funktionalitet. Man f˚ar till exempel m¨ojligheten att sortera p˚a samtliga attribut fr˚an tabellelementen. Man kan ¨aven s¨oka efter n˚agot i tabellen via en s¨okruta. Tabellerna f˚ar ¨aven en snygg design.
5.7.3 Interaktiv graf
Vi beh¨ovde representera m¨atdatan fr˚an den senaste m¨atningen grafiskt. Efter en tid av letande best¨amde sig en medlem sig f¨or att anv¨anda ett plugin vid namn Plotly. Plotly skapade en v¨aldigt snygg och beh¨andig graf, som visas i figur 13.
Figur 13 – Graf genererad av Plotly
F¨ordelarna med Plotly, f¨orutom att den ¨ar snygg, ¨ar att det g˚ar att zooma in genom att markera en ruta i grafen. Dessutom var det v¨aldigt enkelt att implementera grafen p˚a hemsidan.
Plotly har ett flertal nackdelar. Enbart en anv¨andare kan anv¨anda grafen i taget. Om Plotly skulle vara otillg¨angligt skulle vi heller inte kunna visa n˚agra grafer. V˚ara m¨atningar genererar stora datam¨angder som m˚aste skickas till Plotlys servrar. Har man d˚a en taskig n¨atverksansluting al-ternativt om Plotlys servrar skulle strula n˚agon g˚ang s˚a skulle det bli problem att ladda grafen. Dessutom hade en av gruppmedlemmarna problem med att ladda in grafen p˚a sin dator. Ett annat problem var att Plotly inte ¨ar helt gratis. Det ¨ar gratis till viss del, man kunde ha tio stycken grafer men ville man ha fler s˚a beh¨ovde man betala. Det st¨orsta problemet var d¨aremot att Plotly inte renderas lokalt.
Detta ledde till att vi beslutade att byta ut Plotly. Nackdelarna var fler ¨an f¨ordelarna. D˚a vi d¨omt ut Plotly beh¨ovde vi hitta ett nytt s¨att att implementera v˚ar graf. Valet f¨oll p˚a D3 eftersom det ¨ar ett kraftfullt ramverk som liksom Plotly hade st¨od f¨or diverse zoom-funktioner. Nackdelen gentemot Plotly (som f¨or ¨ovrigt delvis ¨ar byggt p˚a D3) ¨ar att det blir betydligt mer kodande. En illustration ¨over hur grafen ser ut kan sk˚adas i figur 14.
Figur 14 – Graf kodad i D3
V˚art system anv¨ander D3 f¨or att m˚ala upp en interaktiv diskret graf som representerar den senaste gjorda m¨atningen d¨ar de tre probernas uppm¨atta str¨om visas. Eftersom det ¨ar ett mycket stort antal punkter som m˚aste finnas i grafen kr¨avdes det att man kunde implementera ”zoom and dragfunktionalitet. D3 blev valet eftersom det finns goda m¨ojligheter f¨or det.
5.7.4 Jade
N¨ar man skall designa hemsidor kr¨avs det att man har HTML-dokument eftersom det ¨ar dessa som webbl¨asarna kan tyda. I Node.js finns det dock st¨od f¨or andra typer av m¨arkspr˚ak som Node.js sedan konverterar till HTML-kod. Ett av dessa spr˚ak ¨ar Jade som vi valde att anv¨anda. F¨ordelar med Jade ¨ar att det finns st¨od f¨or s˚a kallat template inheritance vilket m¨ojligg¨or att man inte beh¨over inkludera Javascript och stylesheets i varje fil (som skulle vara fallet om man kodade i HTML). Det ¨ar ¨aven snabbare och trevligare att programmera i Jade gentemot HTML ans˚ag projektgruppen.
5.8
Designbeslutsprocess
Under projektets g˚ang identifierade vi tre problem som uppstod p˚a grund av brister i designbe-slutsprocessen. Nedan beskrivs dessa i mer detalj.
5.8.1 Plotly
Som beskrivet i avsnitt 5.7.3 implementerade vi till en b¨orjan den interaktiva grafen i Plotly. Problemet var att det tog 40 arbetstimmar innan beslutet att byta till D3 togs.
5.8.2 TCP-protokoll
Tidigt i projektet beslutades det att ett TCP-protokoll skulle skapas. De tv˚a gruppmedlemmarna vars moduler detta ber¨orde beslutade att den ena gruppmedlemmen skulle implementera det. Gruppmedlemmen vars ansvar det var att implementera protokollet best¨amde sig f¨or att skapa protokollet fr˚an grunden. Innan denne hade hunnit implementera protokollet hade den andre redan gjort det med ett externt bibliotek. Eftersom biblioteket fungerade bra avbr¨ots arbetet p˚a det egengjorda protokollet.
5.8.3 Measurehandler
Under projektet skulle en klass i Python implementeras f¨or att spara m¨atningar p˚a m¨atklienten. Gruppmedlemmen som ansvarade f¨or m¨atklienten gjorde ett felaktigt antagande om hur systemet skulle fungera. Detta ledde till ett on¨odigt komplext system. Det ledde ocks˚a till att ¨aven testning blev sv˚arare ¨an n¨odv¨andigt.
5.8.4 V˚ar designbelutsprocess
I slutet av projektet gick vi igenom hur varje gruppmedlem fattat designbeslut. Vi kunde enkelt komma fram till en process vi alla anv¨ant, eftersom att v¨aldigt f˚a saker skilde sig mellan de olika gruppmedlemmarnas processer.
Samtliga h¨amtade information om olika m¨ojliga l¨osningar. Vi v¨agde f¨or- mot nackdelar med olika l¨osningar. Hur andra moduler och utvecklare p˚averkas av din l¨osning v¨agdes in i f¨or- och nackde-lar. H¨ansyn har tagits till om beslutet p˚averkar n˚agon annan modul. H¨ansyn har ocks˚a tagits till kund i de fall kunden p˚averkas direkt. Om n˚agon annan modul eller utvecklare p˚averkas mycket av beslutet har detta diskuterats denne.
Protokoll har diskuterats d¨ar det har varit n¨odv¨andigt. Vissa gruppmedlemmar har fr˚agat tredje-part i s¨arskilda fr˚agor (framf¨orallt om Node.js och hur tidskritiskt Linux ¨ar). D¨arefter tas design-beslut.
I allm¨anhet har inga designbeslut diskuterats med gruppen. Undantag ¨ar st¨orre beslut som var intressanta redan i det f¨orsta planeringsstadiet (t.ex PRU, Node.js, ¨overgripande struktur med server). N¨astan inga beslut som har tagits i projektet har heller presenterats f¨or gruppen, varken i f¨orhand eller i efterhand.
5.9
Tidsf¨
orbrukning
I kursen TDDD77 skulle 300 timmar spenderas per gruppmedlem. I dessa 300 timmar skulle projektet genomf¨oras, kandidatrapport skrivas och ett antal seminarier genomf¨oras.
5.9.1 Medlem hoppar av
Efter cirka halva projekttiden meddelande en gruppmedlem att denne skulle hoppa av. Detta innebar en f¨orlust p˚a ungef¨ar 200 arbetstimmar. Att medlemmen hoppade av medf¨orde ¨aven viss omorganisation, s¨arskilt eftersom avhopparen var gruppledare. Detta gjorde att en ny gruppledare beh¨ovde v¨aljas och beh¨ovde l¨aras upp i arbetsuppgifterna gruppledaren ansvarar f¨or. Fredrik Larsson valdes till ny gruppledare. Detta ledde att vi tappade tid.
5.9.2 F¨orbrukad tid
Systemet konstruerades p˚a utsatt antal timmar. F¨orlusten av en gruppmedlem innebar att viss funktionalitet vi planerat att implementera ut¨over den kravsatta fick bortprioriteras. Av de krav som satts p˚a systemet var det ett som inte uppfylldes. Gruppen diskuterade det ej uppfyllda kravet med kund och kom fram till att den funktionalitet som saknades var ¨onskv¨ard snarare ¨an n¨odv¨andig.
5.10
Gemensamma erfarenheter
Ingen i gruppen har tidigare arbetat med ett projekt i samma omfattning. Det har gett oss nya erfarenheter och insikter i vad som kan vara viktigt f¨or att f˚a arbetet att fortskrida.
En av de viktigaste erfarenheter vi tar med oss, ¨ar vikten av att komma ¨overens tidigt om hur man ska arbeta och kommunicera p˚a ett strukturerat s¨att. Vi har haft problem med kommunikation in-om gruppen vilket har m¨arkts d˚a vi periodvis inte informerade och pratade med varandra s¨arskilt mycket. Under projektets g˚ang bytte vi fr˚an SMSgrupp och mail till Skype till Facebook. Ett bra gemensamt kommunikationsmedel fr˚an b¨orjan, d¨ar man kan vara s¨aker p˚a att alla andra l¨aser det man skriver hade varit bra. Tydligare struktur p˚a m¨oten, med en tydlig dagordning och en plan f¨or vad som ska ˚astadkommas, hade kunnat g¨ora saker mer strukturerade. Ett symptom av v˚ar bristande kommunikation ¨ar till exempel att m˚anga av de dokument vi skrivit inte har anv¨ants som st¨od f¨or oss sj¨alva. Ist¨allet har de skrivits mycket f¨or att de ska skrivas utan att resten av gruppen ¨ar inf¨orst˚add i dess inneh˚all.
Gruppen har ocks˚a haft problem med att det inte funnits n˚agot uttalat arbetss¨att. Vi hade n˚agra id´eer och planer i b¨orjan, men i slut¨andan lyckades inte gruppen best¨amma. Ist¨allet blev gruppen uppdelad i mindre grupper d¨ar varje grupp fick l¨osa sina egna problem b¨ast de ville. Detta ledde till att det har varit sv˚art att f˚a en ¨overblick av hur vi ligger till, hur l˚angt vi kommit i projektet och hur andra har l¨ost problem. Vi upplever att v˚art arbetss¨att har hindrat oss och att b¨attre organisation och mer struktur p˚a v˚art arbete hade hj¨alpt oss att ˚astadkomma ett b¨attre resultat. Vi har m¨arkt att det ¨ar bra, nyttigt och viktigt att testa den mjukvara vi skriver p˚a ett strukturerat s¨att och att b¨orja g¨ora det s˚a tidigt som m¨ojligt. Vi har ocks˚a f˚att erfara hur mycket tid som kan g˚a f¨orlorad om inte designbeslut tas p˚a ett bra s¨att. Somliga har f˚att erfara att n˚agot man l¨agger mycket tid p˚a att konstruera inte n¨odv¨andigtvis kommer med i slutprodukten. Vi har m¨arkt att det kan vara till hj¨alp att arbeta mot tydligt uppsatta m˚al. Om vi hade haft b¨attre m˚al f¨or varje iteration kanske vi hade kunnat f¨ordela arbetsm¨angden b¨attre ¨over hela projekttiden. Slutligen tar vi med oss viss insikt i vad det inneb¨ar att arbeta p˚a en vetenskaplig rapport.
6
Diskussion
6.1
Nya systemet
H¨ar diskuteras fr˚agest¨allningen om vi lyckades byta ut systemet och uppfylla de krav som kunden hade.
6.1.1 Resultat
Resultatet visar att det befinitliga systemet som anv¨andes innan kan bytas ut mot ett enklare, billigare och mer modul¨art system. Genom att byta ut realtidsdatorn som anv¨andes f¨or m¨atningar med en BeagleBone Black och dess realtidsproccessor sparas h˚ardvara och utrymme utan att m¨atningar f¨ors¨amras.
Kundens krav om ett mindre b¨okigt webbgr¨anssnitt uppfylldes, d¨ar en nytt gr¨anssnitt utvecklades f¨or att passa till webl¨asaren i mobilen och datorn. Eftersom kunden var involverad under utveck-lingens g˚ang ledde detta till ett gr¨anssnitt som alla parter blev n¨ojda med, vilket inte var fallet i det gamla systemet.
6.1.2 Metod
Om vi inte hade lyckats konstruera det nya systemet, hade det kr¨avts att vi hade kunnat bevisa att det inte g˚ar att konstruera systemet p˚a en BeagleBone Black f¨or att besvara fr˚agan huruvida det g˚ar eller inte. Vi har inte haft n˚agon metodik f¨or att f¨ors¨oka bevisa att det inte g˚ar.
P˚a motsvarande s¨att g¨aller tidsaspekten. F¨or att visa att det g˚ar att konstruera systemet p˚a given tid beh¨over vi konstruera det p˚a given tid, men f¨or att visa att det inte g˚ar m˚aste vi p˚a n˚agot
s¨att bevisa att det inte g˚ar. Vi samlade inte tillr¨ackligt detaljerad data om hur mycket tid som spenderades p˚a vad f¨or att kunna g¨ora rimliga antaganden i det fall att vi hade misslyckats.
6.2
Designbeslutsprocess
6.2.1 Resultat
Tv˚a av de problem vi presenterade i avsnitt 5.8 resulterade i att arbetstimmar, som kunde lagts p˚a annat, sl¨osades bort. Det tredje problemet orsakade mjukvara som tog h¨ansyn till faktorer som i verkligheten inte finns, och d¨arf¨or b˚ade fungerar s¨amre ¨an det kunde och tog l¨angre tid att testa ¨
an det borde ha tagit.
I det f¨orsta fallet, g¨allande Plotly, s˚a var problemet att den gruppmedlem som tog beslutet inte diskuterade det med n˚agon annan f¨orr¨an Plotly var implementerat och 40 timmar f¨orbrukats. Hade detta beslut p˚a n˚agot s¨att redovisats f¨or resten av gruppen ¨ar det h¨ogst troligt att vi hade bytt graf mycket tidigare.
I det andra fallet, g¨allande TCP-protokoll, var problemet tudelat. Till att b¨orja med var det inte solklart fr˚an b¨orjan vad detta protokoll skulle hantera, om det skulle hantera specifikt JSON-objekt eller kunna skicka vad som helst, vilket innebar att den som utvecklade protokollet fick b¨orja om tv˚a g˚anger. Sedan var det ocks˚a ett problem att beslutet inte omv¨arderades n¨ar det m¨arktes att det skulle ta l˚ang tid att implementera. I slut¨andan valde den andra utvecklaren att anv¨anda ett f¨ardigt paket, vilket innebar att det arbete som lagts p˚a att utveckla ett eget protokoll gjorts f¨org¨aves. Hade det varit klart fr˚an b¨orjan vad protokollet skulle klara av hade mycket arbete sparas. Om utvecklarna hade varit medvetna fr˚an b¨orjan om risken att f¨oruts¨attningarna skulle komma att f¨or¨andras, hade man kanske kunnat v¨alja ett f¨ardigt paket och sedan bygga ett eget n¨ar man var s¨akra p˚a vad man ville ha. D˚a det m¨arktes att det skulle ta mer tid ¨an t¨ankt att konstruera ett eget protokoll ¨an planerat, hade det varit m¨ojligt att omv¨ardera det designbeslutet och p˚a s˚a s¨att spara tid.
I det tredje fallet, g¨allade measurehandler, var problemet att en utvecklare antog att systemet beh¨ovde kunna lagra data fr˚an flera m¨atsessioner parallellt. I verkligheten kommer detta aldrig att ske. Den modul utvecklaren arbetade p˚a blev d¨arf¨or mer komplex ¨an den beh¨ovde vara. Det-ta f¨ors¨amrade prestandan marginellt, i vissa fall specialfall kasseras m¨atv¨arden i on¨odan, men framf¨orallt tog det on¨odigt mycket tid att implementera, testa och fels¨oka.
Hade vi anv¨ant en mer strukturerad designbeslutsprocess hade dessa problem troligtvis inte upp-st˚att. Tanken med att ha en riktig process att f¨olja ¨ar just att uppt¨acka problem med olika alternativ. I de flesta k¨anda designbeslutsprocesser ing˚ar det en fas d¨ar man diskuterar beslutet med hela gruppen och eftersom n˚agon sannolikt hade tagit upp till exempel att Plotly inte riktigt var det vi letade efter s˚a hade en annan l¨osning unders¨okts ist¨allet.
Det ¨ar inte enbart denna diskussionsfas som ¨ar n¨odv¨andig f¨or att f¨orb¨attra processen. Bara id´en med att faktiskt f¨olja en given process g¨or att beslutet sannolikt kommer vara b¨attre.
6.2.2 Metod
Vi baserar v˚ara resultat framf¨orallt p˚a erfarenheter uppsamlade i efterhand. Vi hade kunnat ha f¨orb¨attrat designbeslutsprocessen under projektets g˚ang f¨or att utv¨ardera v˚ara slutsatser.
