Sensorsystem för farliga luftburna ämnen inom räddningstjänst

Linköpings universitet SE–581 83 Linköping

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

2021 | LIU-IDA/LITH-EX-G--2021/033--SE

Sensorsystem för farliga luftburna

ämnen inom räddningstjänst

Sensor system for dangerous airborne substances within rescue

service

Aleksi Evansson

Martin Gustafsson

Mathilde Hennings

Alexander Johansson

Elise Lång

Gustav Stål

Ludvig Widén

Frans Öhrström

Handledare : Hugo Cedervall Examinator : Kristian Sandahl

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publice-ringsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopi-or för enskilt bruk och att använda det oförändrat för ickekommersiell fkopi-orskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan använd-ning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedu-res for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. © Aleksi Evansson Martin Gustafsson Mathilde Hennings Alexander Johansson Elise Lång Gustav Stål Ludvig Widén Frans Öhrström

Sammanfattning

Denna rapport beskriver ett kandidatarbete som utfördes av åtta studenter i kursen TDDD96 - Kandidatprojekt i programvaruutveckling vid Linköpings universitet våren 2021. Projektet handlade om att skapa ett system för att spåra och visualisera förekomsten av farliga ämnen som kan förekomma på olycksplatser och på så sätt underlätta tjänstens arbete. Resultatet av projektet bestod av en sensorenhet som fästs på räddnings-personalens hjälm. Sensorenheten detekterar halten butan, vätgas, ammoniak, sulfider och bensen i luften och skickar dessa värden tillsammans med GPS och acceleration till en in-strumentbräda. Där visas all data och kan användas av bakre led.

Rapporten beskriver projektets arbete beställt av forskningsgruppen Ubiquitous Com-puting and Analytics Group vid Institutionen för Datavetenskap på Linköpings universi-tet. Teorin kring systemet lägger grunden till förståelse av rapporten, samt hur arbete kan effektiviseras med hjälp av till exempel Scrum, parprogrammering och ärendespårning (eng. issue tracking). Rapporten redovisar även projektets resultat och hur den slutgiltiga produktens hårdvara, server och användargränssnitt fungerar. Till sist presenteras grupp-medlemmarnas individuella bidrag som innehåller djupdykningar inom olika områden med koppling till projektet.

Författarens tack

Vi vill tacka vår kund Magnus Bång för möjligheten att utföra ett intressant och lärorikt pro-jekt. Vid utvecklingsfrågor har gruppen fått gott bemötande och hjälpsamt stöd från Nils Hedner och Daniel Westberg, som arbetar med Mangus Bång, vilket vi tackar för. Vi vill även tacka Mikael Johansson från räddningstjänsten för att vi fick möjlighet att ställa frågor för att få insikt i räddningstjänstens arbete.

Till sist vill vi tacka vår handledare Hugo Cedervall för allt stöd och all vägledning grup-pen har fått under projektets gång. Hugo har gett tydliga svar på grupgrup-pens alla frågor och givit bra respons på dokument och presentationer vilket har gynnat gruppens arbete.

Innehåll

2.5 Gruppens tidigare erfarenheter . . . 4

3 Teori 5 3.1 Räddningstjänst . . . 5

3.1.1 Räddningsinsatser . . . 5

3.1.2 Flyktiga organiska ämnen . . . 5

3.2 Verktyg och program . . . 6

3.2.1 Processverktyg . . . 6 3.2.2 Versionshantering . . . 6 3.2.3 Testning . . . 6 3.2.4 Mjukvarustack . . . 7 3.3 Programmeringsspråk . . . 8 3.3.1 Python . . . 8 3.3.2 MicroPython . . . 9 3.3.3 SQL . . . 9

3.4 Ramverk och arbetsmetod . . . 9

3.4.1 Parprogrammering . . . 9 3.4.2 Scrum . . . 9 3.4.3 Systemanatomi . . . 9 3.4.4 ER-modellering . . . 9 4 Metod 10 4.1 Roller . . . 10 4.1.1 Teamledare . . . 10 4.1.2 Analysansvarig . . . 11

4.1.3 Utvecklingsledare . . . 11 4.1.4 Arkitekt . . . 11 4.1.5 Testledare . . . 11 4.1.6 Kvalitetssamordnare . . . 11 4.1.7 Dokumentansvarig . . . 11 4.1.8 Konfigurationsansvarig . . . 12 4.2 Utvecklingsmetod . . . 12 4.2.1 Sprintar . . . 12 4.2.2 Dagliga Scrummöten . . . 12 4.2.3 Utveckling . . . 12 4.2.4 Testning . . . 12 4.2.5 Kanbanbrädet . . . 13 4.2.6 Dokument . . . 13 4.2.7 Kodgranskning . . . 14 4.2.8 Dokumentgranskning . . . 14 4.2.9 Versionshantering . . . 14 4.3 Informationssamling . . . 14 4.3.1 Förundersökning . . . 14

4.3.2 Möte med kontaktperson från räddningstjänsten . . . 15

4.4 Metod för att fånga erfarenheter . . . 15

4.4.1 Sprintutvärdering . . . 15

4.4.2 Kommunikation och dokument . . . 15

4.4.3 Dagligt Scrummöte . . . 15 5 Resultat 16 5.1 Systembeskrivning . . . 16 5.1.1 Systemanatomi . . . 16 5.1.2 Översikt . . . 17 5.1.3 Komponenter . . . 18 5.2 Hårdvara . . . 18 5.2.1 Sensorenhet . . . 19 5.2.2 Förmedlingsnod . . . 20

5.2.3 Data från sensorenhet till förmedlingsnod . . . 21

5.2.4 Data från förmedlingsnod till Chirpstack . . . 22

5.3 Server . . . 22 5.3.1 Chirpstack . . . 22 5.3.2 REST API . . . 23 5.3.3 Databaser . . . 24 5.4 Användargränssnitt . . . 27 5.5 Processbeskrivning . . . 28 5.5.1 Process i fokus . . . 28 5.5.2 Utvärdering . . . 28 5.5.3 Mätningar . . . 29 5.6 Gemensamma erfarenheter . . . 29 5.6.1 Projektorganisation . . . 29 5.6.2 Arbetsmetod . . . 30 5.6.3 Tekniska erfarenheter . . . 30

5.7 Översikt över individuella bidrag . . . 31

5.7.1 Databasdesign - En jämförelse mellan relationsdatabaser och tidsserie-databaser av Aleksi Evansson . . . 31

5.7.2 Webbutveckling i Python - En jämförelse av ramverken Django och Flask av Martin Gustafsson . . . 31

5.7.3 Kodgranskning inom ett småskaligt mjukvaruprojekt av Mathilde

Hen-nings . . . 31

5.7.4 MicroPython - Ett nytt sätt att programmera mikrokontrollers av Alex-ander Johansson . . . 31

5.7.5 Hantering av geografisk data i PostGIS av Elise Lång . . . 31

5.7.6 Trådlös dataöverföring med LoRa av Gustav Stål . . . 31

5.7.7 En jämförelse mellan explorativ och skriptad testning av Ludvig Widén 31 5.7.8 En jämförelse mellan containers och virtuella maskiner i servermiljöer av Frans Öhrström . . . 32

6 Diskussion 33 6.1 Resultat . . . 33

6.1.1 Implementationsval . . . 33

6.1.2 Vidareutveckling . . . 34

6.1.3 Förbättringar från tidigare projekt . . . 34

6.1.4 Lärdomar . . . 35

6.2 Metod . . . 35

6.2.1 Roller och gruppdynamik . . . 35

6.2.2 Sprintmetod . . . 35 6.2.3 Utveckling . . . 36 6.2.4 Testning . . . 37 6.2.5 Kodgranskning . . . 37 6.2.6 Dokumentgranskning . . . 37 6.2.7 Versionshantering . . . 37 6.2.8 Kundkontakt . . . 37 6.2.9 Källkritik . . . 38

6.3 Arbetet i ett vidare sammanhang . . . 38

7 Slutsatser 39 7.1 Hur kan systemet implementeras så att man skapar värde för kunden? . . . 39

7.2 Vilka erfarenheter kan dokumenteras från programvaruprojektet som kan vara intressanta för framtida projekt? . . . 39

7.3 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? . . . 40

7.4 Hur kan sensor- och GPS-data presenteras för att tillåta analys och identifiering av risker inom räddningstjänsten? . . . 40

A Databasdesign - En jämförelse mellan relationsdatabaser och tidsseriedatabaser - Aleksi Evansson 41 A.1 Introduktion . . . 41

A.1.1 Syfte . . . 41

A.1.2 Frågeställningar . . . 41

A.1.3 Definitioner och akronymer . . . 42

A.2 Teori . . . 42

A.2.1 Tidsserier . . . 42

A.2.2 NoSQL . . . 42

A.3 Bakgrund . . . 42

A.3.1 Tidigare erfarenhet . . . 42

A.4 Metod . . . 42 A.4.1 Litteraturstudie . . . 43 A.5 Resultat . . . 43 A.5.1 Relationsdatabaser . . . 43 A.5.2 Tidsseriedatabaser . . . 44 A.5.3 PostgreSQL . . . 44

A.5.4 InfluxDB . . . 45

A.6 Diskussion . . . 46

A.6.1 Metod . . . 46

A.6.2 Resultat . . . 46

A.7 Slutsatser . . . 47

A.7.1 Hur fungerar relationsdatabaser respektive tidsseriedatabaser? . . . 47

A.7.2 Vilka fördelar och nackdelar finns med respektive designval? . . . 48

A.7.3 När lämpar det sig att bruka respektive databastyp? . . . 48

B Webbutveckling i Python En jämförelse av ramverken Django och Flask -Martin Gustafsson 49 B.1 Introduktion . . . 49

B.1.1 Syfte . . . 49

B.1.2 Frågeställning . . . 49

B.1.3 Definitioner och akronymer . . . 50

B.2 Teori . . . 50 B.2.1 WSGI . . . 50 B.2.2 Flask . . . 50 B.2.3 Django . . . 51 B.2.4 Model-View-Controller . . . 51 B.2.5 Templates . . . 51 B.2.6 ORM . . . 51 B.3 Metod . . . 51 B.4 Resultat . . . 52 B.4.1 Mål och fokus . . . 52

B.4.2 Arkitektur och filstruktur . . . 52

B.4.3 Templatesystem . . . 52 B.4.4 Databaskoppling . . . 52 B.4.5 Säkerhet . . . 53 B.4.6 Prestanda . . . 53 B.5 Diskussion . . . 53 B.5.1 Resultat . . . 53 B.5.2 Metod . . . 55 B.6 Slutsatser . . . 55

B.6.1 Vad finns det för skillnader mellan Django och Flask gällande utveck-lingsprocessen för en webbapplikation? . . . 55

B.6.2 Vad finns det för skillnader inom prestanda av en webbapplikation ut-vecklad med Django jämfört med Flask? . . . 55

B.6.3 Vilka typer av projekt lämpar sig Django och Flask för? . . . 56

C Kodgranskning inom ett småskaligt mjukvaruprojekt - Mathilde Hennings 57 C.1 Introduktion . . . 57 C.1.1 Syfte . . . 57 C.1.2 Frågeställning . . . 57 C.2 Bakgrund . . . 57 C.3 Teori . . . 58 C.3.1 Kodgranskning . . . 58 C.3.2 Git . . . 58 C.4 Metod . . . 59 C.4.1 Litteraturstudie . . . 59 C.4.2 Fallstudie . . . 59 C.4.3 Avgränsningar . . . 59 C.5 Resultat . . . 60

C.5.1 Litteraturstudie . . . 60 C.5.2 Fallstudie . . . 61 C.6 Diskussion . . . 62 C.6.1 Metod . . . 62 C.6.2 Resultat . . . 62 C.7 Slutsatser . . . 63

C.7.1 Hur kan kodgranskning användas i ett småskaligt mjukvaruprojekt? . . 63

C.7.2 Vilka fördelar och problemområden finns med kodgranskning? . . . 63

C.7.3 Hur hade kodgranskningsprocessen i vårt projekt kunnat förbättras? . . 64

D MicroPython - Ett nytt sätt att programmera mikrokontrollers -Alexander Johansson 65 D.1 Introduktion . . . 65

D.1.1 Syfte . . . 65

D.1.2 Frågeställning . . . 65

D.1.3 Avgränsningar . . . 66

D.1.4 Definitioner och akronymer . . . 66

D.2 Teori . . . 66 D.2.1 Python . . . 66 D.2.2 MicroPython . . . 67 D.2.3 C . . . 67 D.3 Metod . . . 67 D.3.1 Littraturstudie . . . 67 D.4 Resultat . . . 68 D.4.1 Utökning av Python . . . 68

D.4.2 MicroPython och Python . . . 68

D.4.3 MicroPythons hastighet . . . 68

D.4.4 MicroPythons begränsade minne . . . 69

D.4.5 Prestationsskillnad mellan MicroPython och C . . . 70

D.5 Diskussion . . . 70

D.5.1 Metod . . . 70

D.5.2 MicroPythons hastighet . . . 71

D.5.3 MicroPythons användningsområden . . . 71

D.6 Slutsatser . . . 71

D.6.1 Vilka för och nackdelar finns det med att använda sig av MicroPython? 71 D.6.2 På vilket sätt skiljer sig MicroPython mot Python? . . . 72

D.6.3 Varför användes MicroPython i detta Projektet? . . . 72

D.6.4 Hur hanterar MicroPython minnesallokering på mikrokontrollers och hur presterar det i jämförelse med C. . . 72

E Hantering av geografisk data i PostGIS - Elise Lång 73 E.1 Introduktion . . . 73

E.1.1 Syfte . . . 73

E.1.2 Frågeställning . . . 73

E.1.3 Definitioner och akronymer . . . 74

E.2 Teori . . . 74

E.2.1 Geografisk data och GIS . . . 74

E.2.2 Frågefunktioner för geografisk data . . . 74

E.2.3 Hantering av geografisk data i relationsdatabaser . . . 75

E.2.4 Hantering av geografisk data i NoSQL-databaser . . . 75

E.2.5 PostgreSQL . . . 75

E.2.6 PostGIS . . . 75

E.4 Resultat . . . 75

E.4.1 Språk för geografisk data . . . 76

E.4.2 PostGIS funktionalitet . . . 76

E.4.3 Jämförelser mellan PostGIS och NoSQL-databaser . . . 76

E.5 Diskussion . . . 78

E.5.1 Metod . . . 78

E.5.2 Resultat . . . 78

E.6 Slutsatser . . . 78

E.6.1 Hur fungerar PostGIS? . . . 79

E.6.2 Varför behövs databaser såsom PostGIS till geografisk data? . . . 79

E.6.3 Vilka är fördelarna och nackdelarna med PostGIS? . . . 79

F Trådlös dataöverföring med LoRa - Gustav Stål 80 F.1 Introduktion . . . 80

F.1.1 Syfte . . . 80

F.1.2 Frågeställningar . . . 80

F.1.3 Definitioner och akronymer . . . 80

F.2 Metod . . . 81

F.3 Resultat . . . 81

F.3.1 LoRa . . . 81

F.3.2 WiFi . . . 83

F.3.3 Bluetooth . . . 83

F.3.4 Överföringsteknikernas primära egenskaper . . . 84

F.4 Diskussion . . . 84

F.4.1 Överföringsteknikernas skiljaktigheter . . . 84

F.4.2 Överföringsteknikernas främsta användningsområden . . . 85

F.4.3 LoRaWAN och framtiden för IoT . . . 86

F.5 Slutsatser . . . 86

F.5.1 Hur skiljer sig LoRa mot överföringsteknikerna WiFi och Bluetooth? . . 86

F.5.2 Vilken av överföringsteknikerna lämpar sig bäst för vårt projekt? . . . . 87

G En jämförelse mellan explorativ och skriptad testning - Ludvig Widén 88 G.1 Introduktion . . . 88 G.1.1 Syfte . . . 88 G.1.2 Frågeställning . . . 88 G.1.3 Definitioner . . . 89 G.2 Teori . . . 89 G.2.1 Programvarutestning . . . 89 G.2.2 Testnivåer . . . 89 G.2.3 Skriptad testning . . . 90 G.2.4 Explorativ testning . . . 90 G.3 Metod . . . 90 G.3.1 Litteraturstudie . . . 90 G.4 Resultat . . . 90 G.4.1 Skriptad testning . . . 91 G.4.2 Explorativ testning . . . 92 G.5 Diskussion . . . 94 G.5.1 Metod . . . 94 G.5.2 Resultat . . . 94 G.6 Slutsatser . . . 95

G.6.1 Vad är skillnaden mellan explorativ och skriptad testning? . . . 95

G.6.2 Vilka fördelar har skriptad testning över exlorativ? . . . 95

G.6.4 Vilken testningsstil är mest lämpad för projektet? . . . 95

H En jämförelse mellan containers och virtuella maskiner i servermiljöer -Frans Öhrström 97 H.1 Introduktion . . . 97 H.1.1 Syfte . . . 97 H.1.2 Frågeställning . . . 97 H.1.3 Definitioner . . . 98 H.2 Teori . . . 98 H.2.1 Virtualisering på hårdvarunivå . . . 98 H.2.2 Virtualisering på operativsystemsnivå . . . 98 H.3 Metod . . . 99 H.3.1 Litteraturstudie . . . 99 H.4 Resultat . . . 99

H.4.1 Skillnader mellan containers och virtuella maskiner . . . 99

H.5 Diskussion . . . 101

H.5.1 Litteraturstudie . . . 101

H.5.2 Resultat . . . 101

H.6 Slutsatser . . . 101

H.6.1 Vilka är de generella skillnaderna mellan containers och virtuella ma-skiner med avseende på funktionalitet, prestanda, underhåll och säker-het? . . . 101

H.6.2 För vilka användningsområden lämpar sig den ena formen av virtuali-sering mer än den andra? . . . 102

H.6.3 Vilka faktorer låg bakom beslutet att bygga projektets server-delar i containers? . . . 102

I Svar från frågeformulär om kodgranskning 103

Figurer

4.1 Ett exempelbräde . . . 13

5.1 Systemanatomi för projektet. . . 17

5.2 Överblick av systemets delar. . . 18

5.3 Detaljerad bild över systemets komponenter och vilka delar de tillhör. . . 18

5.4 Illustration av sensorenhetens konstruktion. . . 19

5.5 Illustration av kopplingsschemat för gassensorerna. . . 20

5.6 Illustration av förmedlingsnodens konstruktion. . . 21

5.7 Exempel på hur datapaket med GPS-data ser ut och avkodas. . . 21

5.8 Ett exempel på ett datapaket från Chirpstack. . . 22

5.9 De olika delarna av Chirpstack, där LoRa GateWay är förmedlingsnoderna och HTTP i ”Integrations” kopplas till REST API [chirpstack-overview]. . . . 23

5.10 Sekvensdiagram för REST API komponenten. . . 24

5.11 Datastruktur efter avkodning. . . 24

5.12 Relationsdiagram som beskriver PostGIS relationsstruktur. . . 25

5.13 ER-diagram som beskriver PostGIS struktur och relationen mellan entiteter. . . 26

5.14 Diagram som beskriver datastrukturen för InfluxDB databasen. . . 26

5.15 Exempelbild på hur översiktsbräde ser ut i Grafana. . . 27

5.16 Exempelbild på hur ett enhetsbräde ser ut i Grafana. . . 28

A.1 Approximerad exempeldata i PostgreSQL. . . 45

A.2 Exempeldata i InfluxDB. . . 46

A.3 Topp 20 mest populära tidsseriedatabassystemen i och med maj 2021 [toptime]. . . 47

C.1 Grenar och sammanfogningar i Git. . . 58

D.1 Visualiering av fragmentering . . . 70

F.1 Bild som visar ett exempel på en LoRa-topologi . . . 82

F.2 Tabell som jämför olika överföringstekniker. . . 85

F.3 Diagram som visar användningsområden för olika överföringstekniker. Hämtad från [lora_and_lorawan] . . . . 86

I.1 Diagram över svaren på påståendet ”Jag tyckte det var lärorikt att granska någon annans kod”. . . 103

I.2 Diagram över svaren på påståendet ”Jag hade rätt förkunskaper för att kunna göra en grundlig granskning”. . . 103

I.3 Diagram över svaren på påståendet ”Jag hade velat vara mer delaktig i kodgransk-ningen”. . . 104

I.4 Diagram över svaren på påståendet ”Jag tyckte kodgranskningen hjälpte mig skri-va bättre kod”. . . 104

Tabeller

4.1 Gruppmedlemmarnas tilldelade roller. . . 10

5.1 Tabell med fältförklaring för datan i databaserna . . . 25

C.1 Frågor från frågeformuläret, vem de var riktade till samt deras svarstyp. Svarsty-pen skala angavs med 1-5, där 1 var ”instämmer inte alls” och 5 var ”instämmer helt”. . . 60

C.2 Resultet från mätningar av kodgranskning. . . 61

C.3 Genomsnitt av mätningarnas resultat. . . 61

E.1 Distansbaserade frågor i PostGIS. . . 76

E.2 Riktningsbaserade frågor i PostGIS. . . 76

E.3 Topologiska frågor i PostGIS. . . 77

Definitioner

Ord Betydelse

Bakre ledning Refererar till personal som använder en instrumentbräda och övervakar en situation från en räddningsstation eller annan fy-sisk plats.

BLE Akronym för ”Bluetooth Low Energy” som är en trådlös kom-munikationsstandard utvecklat som ett strömsnålt alternativ till Bluetooth.

CayenneLPP Ett kodbibliotek designat för att packa och skicka data dynamiskt och energisnålt över LoRa.

Gunicorn En HTTP server skriven i Python som är kompatibel med en mängd ramverk.

Django Ett ramverk för att bygga programmeringsgränssnitt i Python som följer de öppna standarderna för JSON-schema.

Flask Ett ramverk för att bygga programmeringsgränssnitt i Python som följer de öppna standarderna för JSON-schema.

Instrumentbräda Ett användargränssnitt som ger en översiktlig bild av snabbför-änderlig aktuell data genom flera mätare.

IoT Akronym för ”Internet of Things” vilket motsvarar en enhet som är uppkopplad mot internet varifrån den kan hanteras och admi-nistreras.

JSON Akronym för ”JavaScript Object Notation” som är ett textbaserat format som ofta används vid utbyte av data.

Kanban En agil metod för systemutveckling som går ut på att balansera och fördela arbete.

LaTex Ett typsättningssystem som är utvecklat för produktion av tek-niska och vetenskapliga dokument.

LTE Akronym för ”Long Term Evolution” som är en standard för mo-bilt bredband via 4G.

OpenAPI En specifikation som definierar en standard och språkgränsnitt för REST API:er.

PEP8 Ett dokument som innehåller riktlinjer och kodstandard för Pyt-honkod.

Ord Betydelse

PIK-lista En lista av vanligt förekommande kemikalier vid hantering, transporter eller bränder som vid utsläpp kan få stora konse-kvenser för människor och miljö. PIK är en akronym för ”Prio-riterade Industrikemikalier”.

Pycom Pycom är ett företag som skapar hårdvara och mjukvara för IoT-system.

REST Akronym för ”Representational State Transfer” som är en arki-tekturstil för att tillhandahålla standarder som gör det enklare för kommunikation mellan datorsystem på webben.

REST API Ett programmeringsgränssnitt som följer reglerna för REST. Sensorenhet Den sammansatta hårdvarumodul som slutprodukten består av. Sigfox Ett företag som bygger trådlösa nätverk för anslutning av lågef-fekt produkter som är igång kontinuerligt och skickar en liten mängd data.

Uvicorn En asynkron HTTP-server skriven i Python som är kompatibel med en mängd ramverk.

1

Introduktion

I detta projekt utvecklades ett system som med hjälp av sensorer kan visualisera halten av farliga luftburna ämnen vid olycksplatser. Systemet kan användas för att skydda räddnings-tjänst från att utsätta sig för höga halter av farliga ämnen och därmed göra räddningsräddnings-tjänstens arbete säkrare.

I denna rapport presenteras systemets bakgrund, relevant teori, projektetarbetets resul-tat samt diskussion och slutsatser baserade på rapportens frågeställningar. Därefter följer en individuell del för varje projektmedlem som djupdyker inom ett ämne relaterat till projektet.

1.1

Motivering

Att räddningstjänst ute i fält utsätts för faror är en del av deras vardag. Bland dessa fa-ror finns ohälsosamma gaser som räddningstjänsten kommer i kontakt med under olyckor såsom bränder, trafikolyckor och industriläckage. Dessa gaser kan vara giftiga, frätande el-ler brandfarliga, varför räddningstjänsten använder skyddsutrustning och zonindelning av olycksplatsen för att indikerar hur farligt området är. Beslut om zoners gränser och vilken skyddsutrustning som ska bäras i respektive zon fattas av olycksplatsens räddningsledare utifrån information från bakre ledning och informationen som finnes på olycksplatsen [1].

För att underlätta detta arbete forskar Ubiquitous Computing and Analytics Group kring ett system med sensorer som placeras på personalen ute i fält för att i realtid samla data om omgivningens halter av farliga luftburna ämnen. Den bakre ledningen kan då följa utveck-lingen av farliga ämnen vilket kan användas vid beslutsfattning. Systemet kan även följa varje individs exponering av ämnen och därigenom detektera om någon utsatts för höga halter av ett farligt ämne som kan kräva åtgärder eller behandling.

1.2

Syfte

Syftet med projektet var att skapa ett system för att spåra och visualisera förekomsten av farli-ga ämnen som kan förekomma på olycksplatser och på så sätt underlätta räddningstjänstens arbete. Projektarbetets syfte var att ge gruppen lärdomar kring utveckling av ett större projekt mot en kund. Dessa lärdomar inkluderar implementation av etablerade utvecklingsmetoder och hur de kan användas inom projekt. Rapporten presenterar projektets arbete och ger lä-saren en förståelse kring projektet i sin helhet. Rapporten ämnar även samla de erfarenheter

1.3. Frågeställning

som gruppen fått under projektet samt beskriva utvecklingsprocessen och de verktyg som använts. Rapporten är indelad i en gemensam- och ett antal individuella delar. Den gemen-samma delen består av en introduktion, bakgrund, teori, resultat, diskussion samt en slutsats för att besvara frågorna som ställs i 1.3. I de individuella delarna görs djupdykningar inom olika områden med koppling till projektet.

1.3

Frågeställning

Följande frågeställningar behandlas i rapporten:

1. Hur kan systemet implementeras så att man skapar värde för kunden?

2. Vilka erfarenheter kan dokumenteras från programvaruprojektet som kan vara intres-santa för framtida projekt?

3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi?

4. Hur kan sensor- och GPS-data presenteras för att tillåta analys och identifiering av ris-ker inom räddningstjänsten?

1.4

Avgränsningar

Projektet begränsades till 400 timmar per gruppmedlem, där dessa 400 timmar fördelades mellan utvecklingsarbete och skrivning av rapporter. Då projektgruppen bestod av åtta per-soner resulterade detta i totalt 3 200 timmar. Projektet hade även begränsningar på hårdvaror och programvaror, då utvecklingen utfördes på ett påbörjat system. Dessa hårdvaror och programvaror inkluderade mikrokontroller från Pycom, PostGIS, InfluxDB och Grafana. Rap-porten begränsades till att endast behandla områden relevanta till utvecklingsarbetet och för att besvara frågeställningarna.

1.5

Kontext

Projektet genomfördes inom kursen TDDD96 – Kandidatprojekt i programvaruutveckling på Lin-köpings universitet. Detta medförde vissa krav på arbetet som var utom projektgruppens kontroll. Dessa krav inkluderade kursens deadlines, inlämning av dokument och ett fast an-tal timmar varje gruppmedlem skulle spendera på projektet.

2

Bakgrund

I detta kapitel beskrivs kunden, uppdraget, kundens system samt gruppens tidigare erfaren-heter.

2.1

Kunden

Kunden var forskningsgruppen Ubiquitous Computing and Analytics Group vid Institutio-nen för datavetenskap vid Linköpings universitet. De forskar kring IT-lösningar för att hante-ra och underlätta vid olyckor, bränder och katastrofer. För ändamålet har forskningsgruppen skapat ett IoT-system med sensorer och radionät samt ett avancerat klusterbaserat AI-system, för att i realtid processera och visualisera dataströmmar från en olycksplats.

2.2

Vision

Kundens vision med projektet är att minska halten av farliga ämnen som utryckningsperso-nal drabbas av vid olycksplatser. Kundens lösning är en vidareutveckling av ett IoT-system som i realtid ska kunna spåra och visualisera förekomsten av olika luftburna ämnen. Systemet ska användas på olycksplatser för att med hjälp av insamlad och visualiserad data ge bakre ledning ett bra beslutsunderlag och statusrapport. Besluten ska leda till att utryckningsper-sonalen i större grad undviker områden med för höga halter av farliga luftburna ämnen och att personalen har rätt skyddsutrustning för varje enskild olycka.

2.3

Uppdrag

Gruppen fick som uppdrag av kunden att utefter visionen, se avsnitt 2.2, vidareutveckla de-ras system som sedan tidigare hade vissa delar implementerade, se avsnitt 2.4. En sak som be-hövde vidareutvecklas var att implementera gassensorer för insamling av data. Datan skulle sedan skickas till en server där den avkodades och fördes in i två databaser. Den ena data-basen var en tidsseriedatabas som sorterade datan i kronologisk ordning och den andra var en positionsdatabas som hanterade positionsdata. Kunden efterfrågade även ett användar-gränssnitt för att visa upp positionen för alla anslutna enheter samt mer specifik information om varje enhet och dess insamlade data. Användargränssnittet skulle visualisera

sensorda-2.4. Kundens system

tan grafiskt likt en instrumentbräda som visade den insamlade datan både momentant och historiskt. Kunden önskade även visualisering av farliga ämnens utbredning som värmezo-ner på en karta. Dessa zovärmezo-ner skulle vara anpassningsbara för att ge användaren möjligheten att anpassa systemet till olika halter av farliga ämnen.

2.4

Kundens system

Då Ubiquitous Computing and Analytics Group har forskat kring IT-lösningar för att hantera och underlätta vid olyckor, bränder och katastrofer under en längre tid har de implementerat ett antal komponenter som var relevanta för detta projekt. Vissa av dessa komponenter var till viss del implementerade och andra var helt färdiga. De färdiga komponenterna var en LoRa gateway, en NUC chirpstack samt WiFi-kommunikationen mellan dessa. De komponenter som var till viss del implementerade var en InfluxDB-databas, en PostgreSQL databas, ett användargränssnitt i Grafana och en mobilapplikation med Mapbox-implementationer.

2.5

Gruppens tidigare erfarenheter

Samtliga i gruppen har tidigare arbetat i projektgrupper där syftet har varit att producera nå-got mjukvarusystem eller hårdvarusystem. Dessa projektarbeten har exempelvis genomförts i samband med kurserna TSEA29 - Konstruktion med mikrodatorer och TDDD92 - AI-projekt. Majoriteten av gruppen har även arbetat i projektgrupper med syfte att planera studieso-ciala arrangemang. Gruppen besitter kunskaper inom flera tekniska områden, bland annat mjukvaruprogrammering, hårdvaruprogrammering, databaser och datatyper. Dessa kunska-per har givits i samband med gruppens utbildning på universitet samt annan sysselsättning utanför utbildningen.

3

Teori

I detta kapitel beskrivs relevant teori kopplat till projektet. Det innefattar bland annat hjälp-medel och verktyg som har använts av gruppen under planerings- och utvecklingsfasen.

3.1

Räddningstjänst

Följande avsnitt beskriver hur räddningsinsatser sker i dagsläget samt vilka farliga ämnen som finns i räddningstjänstens arbetsmiljö.

3.1.1

Räddningsinsatser

När bränder, trafikolyckor eller andra olyckor inträffar får SOS-alarm ett samtal. De kontaktar i sin tur räddningstjänsten som åker till olycksplatsen med lämplig skyddsutrustning. Rädd-ningstjänsten består av två led: främre led och bakre led. Båda leden arbetar nära varandra. Vid antingen främre led eller bakre led arbetar en räddningsledare som tar beslut rörande olycksplatsen. Främre led arbetar på olycksplatsen efter de beslut som tagits samt ger infor-mation om olycksplatsen till bakre ledet. Motsvarande arbetar bakre led tillsammans med SOS-alarm där de ger information som är svårtillgänglig på plats till främre led samt rädd-ningsledaren [1].

För att veta vilken skyddsutrustning som behövs använder räddningstjänsten sig av zo-ner som kan ha tre olika klassificeringar: kall zon, varm zon och het zon. Räddningsledaren ansvarar över att dela in olycksområdet i dessa zoner. Idag är zonindelningen ungefärlig och uppdelningen kan variera beroende på räddningsledarens tidigare erfarenheter och tillgäng-lig information [1].

3.1.2

Flyktiga organiska ämnen

Flyktiga organiska ämnen (eng. Volatile organic compounds) är ämnen som förångas vid en re-lativt låg temperatur. Europeiska unionen definierar flyktiga organiska ämnen som ämnen med en kokpunkt på 250 grader celsius eller lägre vid normalt lufttryck [2]. I Sverige finns en PIK-lista som innehåller de vanligaste förekommande industrikemikalierna. Räddningsper-sonal har en stor sannolikhet att komma i kontakt med dessa ämnen vid olyckor [1].

3.2. Verktyg och program

3.2

Verktyg och program

Följande avsnitt beskriver de verktyg och program som använts under projektets gång.

3.2.1

Processverktyg

Följande delavsnitt behandlar relevant teori till projektets processer. Microsoft Teams

Microsoft Teams är en kommunikationsplattform som tillhandahåller kommunikationstjäns-ter såsom chatt, samtal och videomöten för flera personer. Den tillhandahåller även tjänskommunikationstjäns-ter för fillagring, redigering och integration av applikationer [3].

Overleaf

Overleaf är ett webbaserat verktyg som används för att skriva LaTeX-dokument. Verktyget stödjer gemensam redigering av dokument och kompilerar LaTeX-dokumentet automatiskt i bakgrunden vid redigering [4].

3.2.2

Versionshantering

Följande delavsnitt behandlar relevant teori till versionshantering. Feature Branches

Feature Branches är ett Git-arbetsflöde där all utveckling görs i separata grenar (eng. branches) istället för i huvudgrenen. Det gör det enkelt för användaren att utveckla egna funktioner eller funktionalitet utan att störa huvudgrenen. Detta innebär att koden som huvudgrenen kommer innehålla är mer testad och kontrollerad och mängden trasig kod som läggs där minskar [5].

GitLab

GitLab är plattform baserad på öppen källkod vars syfte är att minska avståndet mellan ut-vecklare och IT-drift (eng. DevOps). Applikationen tillhandahåller tjänster för utut-vecklare att samarbeta och versionhantera sin mjukvara med Git. GitLab tillhandahåller även tjänster för automatisk testning av kod, automatiska leveranser och planeringsverktyg [6].

GitLab CI/CD

Akronymen CI/CD står för ”Continuous Integration” och ”Continuous Delivery” eller ”Con-tinuous Deployment”. GitLab CI/CD är GitLabs egna inbyggda CI/CD-verktyg och det an-vänds för kontinuerlig integration, leverans och distribution av mjukvara [7].

3.2.3

Testning

Följande delavsnitt behandlar relevant teori till testning. Coverage.py

Coverage.py är ett verktyg för att mäta kodtäckning för Pythonkod. Det används för att mäta hur stor del av ett programs kodbas som är exekverad. Coverage.py kontrollerar vilka rader som körts och identifierar och returnerar därefter en analys av kodbasen [8].

3.2. Verktyg och program

Flake8

Flake8 är ett omslag (eng. wrapper) med de tre Pythonverktygen PyFlakes, pycodestyle och Ned Batchelder’s McCabe script. Flake8 utför statisk analys av kod och används för att kon-trollera att kod inte bryter mot PEP8 eller innehåller andra typer av fel [9].

3.2.4

Mjukvarustack

Följande delavsnitt behandlar relevant teori till mjukvarustacken. Docker

Docker är en plattform för körning av applikationer i en delvis isolerad miljö, kallad ”con-tainer”. En container skapas med hjälp av en instruktionsfil, en så kallad docker-bild, och innehåller allt som krävs för att köra applikationen och har därmed inget krav på installe-rad mjukvara hos den som kör containern. Detta gör att applikation kan köras på flera olika maskiner men ändå fungera likadant [10].

FastAPI

FastAPI är ett ramverk för att bygga programmeringsgränssnitt i Python som följer de öppna standarderna för OpenAPI och JSON-schema [11].

Grafana

Grafana är en programvara baserad på öppen källkod som kan visualisera data som en in-strumentbräda med strömmar från ett flertal datakällor. Grafana tillhandahåller tjänster för visualisering, framtagning av information ur en större informationsmängd samt varnings-tjänster på mätningar och loggar. Grafana stödjer databaser som hanterar tidsseriedata samt leverantörer till molnövervakning [12].

InfluxDB

InfluxDB är en databashanterare baserad på öppen källkod. Den är specialiserad på lagring och hantering av tidsseriedata och tillhandahåller funktionalitet för visualisering, användar-gränssnitt och framtagning av information ur en större informationsmängd med hjälp av sökvillkor och sökbegränsningar (eng. queries) [13].

Mapbox

Mapbox är en molnplattform som hanterar och kartlägger positionsdata. Plattformen tillhan-dahåller programmeringsgränssnitt, utvecklingsverktyg för tredjepartsutvecklare och real-tidsuppdaterad kartdata [14].

PostgreSQL

PostgreSQL är en relationsdatabas baserad på öppen källkod. Den använder sig av program-meringsspråket SQL och kan hantera olika tillägg vilket gör databasen kraftful. Den tillhan-dahåller funktioner såsom att utvecklaren kan definiera egna datatyper och skapa egna funk-tioner [15].

PostGIS

PostGIS är ett tillägg till relationsdatabasen PostgreSQL baserad på öppen källkod. Det till-handahåller mer avancerade funktioner för att hantera data som är knuten till geografiska platser [16].

3.3. Programmeringsspråk

Hårdvaruverktyg

Följande delavsnitt som behandlar relevant teori till hårdvara. Chirpstack

Chirpstack är en komplett nätverksserver baserad på öppen källkod som tillhandahåller komponenter för LoRa-nätverk. Chirpstack innehåller ett användarvänligt gränssnitt för en-hetshantering och API-integration. Chirpstacken tar emot och behandlar data från förmed-lingsnoder [17].

LoRa

LoRa, akronym för ”Long Range”, är en trådlös överföringsteknik som används för att bygga trådlösa nät på licensfria frekvenser. LoRa har en långsam överföringshastighet och fungerar som ett protokoll avsett för sensordata och IoT [18].

NUC

NUC är en akronym för ”Next Unit of Computing” och är en avskalad datorutrustning (eng. Barebone) från Intel. Det är en minidator som följer standarderna för modulära sändtagare för datakommunikation och telekommunikation [19].

Pycom GPy

Pycom GPy är en mikroprocessor skapad av Pycom som programmeras med MicroPython, se sektion 3.3.2. GPy stödjer trådlös kommunikation via WiFi, Bluetooth och LTE [20]. Pycom LoPy4

Pycom LoPy4 är en mikroprocessor skapad av Pycom som programmeras med MicroPython, se sektion 3.3.2. LoPy4 kan agera både som förmedlingsnod och utvecklingsplatform som stödjer LoRa, Sigfox, WiFi och BLE [21].

Pycom Pygate

Pycom Pygate är ett expansionskort till Pycoms utvecklingskort som utökar LoRa-kapabiliteten och gör den till en 8-vägs förmedlingsnod för ett LoRa-nätverk bestående av andra Pycomkort [22].

Pycom Pytrack

Pycom Pytrack är ett expansionskort för Pycoms mikroprocessorer och tillför ny sensorfunk-tionalitet i form av GPS och accelerometer [23].

3.3

Programmeringsspråk

Följande avsnitt beskriver de programmeringsspråk gruppen har använt under projektets gång.

3.3.1

Python

Python är ett objektorienterat högnivåspråk som har dynamisk typning [24]. Det är ett in-terpreterat språk vilket medför att programmen kan köras utan ändringar på många olika typer av datorer och operativsystem. Som en följd av språkets uppbyggnad och datastruk-turer används det till exempel som skriptspråk och för sammansättning av moduler. Språket

3.4. Ramverk och arbetsmetod

utvecklas av en organisation som främjar öppen källkod [25]. Det har bidragit till dess mo-duläritet då Python stödjer ett flertal paket och bibliotek [26].

3.3.2

MicroPython

MicroPython är en programtolk baserad på öppen källkod som är skriven i programmerings-språket C. Programtolken är till stor del kompatibel med Python 3 och är optimerad för att användas på mikrokontroller. Programtolken innehåller avancerade funktioner som fungerar under kompakta hårdvaruförhållanden [27].

3.3.3

SQL

SQL är en akronym för ”Structured Query Language” och är ett programmeringsspråk för relationsdatabaser. Språket kan användas för att efterfråga (eng. query), uppdatera, omorga-nisera och skapa ny data i databaser [28].

3.4

Ramverk och arbetsmetod

Följande avsnitt beskriver de ramverk och arbetsmetoder som använts i projektet.

3.4.1

Parprogrammering

Parprogrammering är en programutvecklingsteknik som tillhör den agila programutveck-lingsmetoden. I parprogrammering sitter två programmerare vid en gemensam datorskärm på plats alternativt på distans. En utses som förare, vars ansvar är att skriva kod, och den andra utses som navigatören, vars ansvar är att granska den skrivna koden. Några av förde-larna med tekniken är att det kan leda till att antal defekter minskar, högre kodkvalité och att de involverade får en bättre förståelse av koden [29].

3.4.2

Scrum

Scrum är en metod som används främst inom mjukvaruutveckling, som innebär att ett pro-jekt delas in i tidsperioder där varje tidsperiod har satta delmål. Efter varje tidsperiod utvär-deras det tidigare arbetet och nya delmål sätts till den nya tidsperioden. Metoden känneteck-nas därför av att fokus läggs på den produkt som ska utvecklas istället för hur produkten ska utvecklas, vilket generellt leder till mer effektivt arbete [30].

3.4.3

Systemanatomi

En systemanatomi är en riktad, acyklisk graf vars användningsområden är att översiktligt visa ett systems funktionalitet. Den fungerar som ett stöd för utvecklarna av systemet. Syste-manatomin är generellt uppdelad i olika lådor där varje låda innehåller någon funktionalitet. Beroenden mellan de olika lådorna representeras med pilar mellan dem. Lådorna är placera-de i något av placera-de fem lagren: service, användargränssnitt, serverfunktioner, kommunikation eller hårdvara. Diagrammet kan uppdateras under projektets gång vid agil utveckling [31].

3.4.4

ER-modellering

ER-modellering är ett grafiskt tillvägagångsätt att designa en databas där ER är en akronym för Entity Relationship. Objekt ritas upp och kan få attribut, egenskaper samt relationer till andra objekt. Detta kan användas som ett kommunikationsverktyg mellan utvecklare och intressenter av systemet [32].

4

Metod

I detta kapitel beskrivs projektgruppens roller, utvecklingsmetod och metod för att fånga gruppens erfarenheter under projektets gång.

4.1

Roller

För att strukturera arbetet fick varje gruppmedlem vid projektets start en arbetsroll. Des-sa roller fördelades utefter önskemål från gruppmedlemmarna och på demokratiskt vis där konflikter uppstod. Gruppmedlemmarnas respektive roller presenteras i tabell 4.1. Alla roller och deras specifika arbetsuppgifter och ansvarsområden beskrivs nedan.

Tabell 4.1: Gruppmedlemmarnas tilldelade roller.

Roll Gruppmedlem

Teamleadare Gustav Stål

Analysansvarig Elise Lång

Utvecklingsledare Frans Öhrström

Arkitekt Martin Gustafsson

Testledare Ludvig Widén

Kvalitetssamordnare Aleksi Evansson Dokumentansvarig Mathilde Hennings Konfigurationsansvarig Alexander Johansson

4.1.1

Teamledare

Teamledaren var den gruppmedlemmen som ledde arbetet, och därmed såg till att alla arbe-tade samt att det skedde framsteg i projektet. Teamledaren ansvarade även för måluppfyll-nad och såg till att slutmålet uppfylldes. Hen ansvarade också för arbetsmiljö och fungerade som en coach, vilken alla kunde kontakta om det var något att prata om. Om en oenighet skedde i ett projektbeslut hade teamledaren sista ordet för att arbetet inte skulle stanna upp. Dessutom representerade teamledaren gruppen utåt och ansvarade för organisation, mötes-bokning samt att projektplanen skrevs och uppdaterades. Teamledaren ansvarade även för att skriva och skicka in gruppens veckorapporter.

4.1. Roller

4.1.2

Analysansvarig

Analysansvarig agerade som kundens röst till projektgruppen. Den analysansvarige tog reda på kundens verkliga behov och tolkade det kunden vill till krav. Den analysansvarige age-rade dessutom orakel och skulle kunna svara på frågor egentligen riktade till kunden för att underlätta kontaktbehovet. Analysansvarig skulle också se till att kravspecifikation skapas och hölls uppdaterad under arbetet.

4.1.3

Utvecklingsledare

Utvecklingsledaren ansvarade för detaljerad design, och bestämde därför på en mer detalje-rad nivå hur projektet skulle formas och hur de olika delarna skulle se ut. Utvecklingsledaren hade också sista ordet i tekniska frågor. Utvecklingsledaren ledde och fördelade vid behov utvecklingsarbetet, försatte resterande del av gruppen i arbete kring utvecklingen och styrde över vem som gjorde vad och att alla delar arbetades med. Dessutom fattade utvecklingsle-daren beslut om utvecklingsmiljö, kodstandarder och utvecklingspraxis, samt hjälpte till med att organisera sammanslagning och testning av kod tillsammans med konfigurationsansvarig och testledare.

4.1.4

Arkitekt

Arkitekten ansvarade för att en stabil arkitektur för systemet togs fram, samt målade ut helhe-ten och definierade hur de olika delarna skulle kommunicera. Hen identifierade komponen-ter och gränssnitt, och gjorde övergripande teknikval samt valde vilka tekniker som skulle användas för att lösa de olika delarna. Arkitekten dokumenterade arkitektur och ansvarade för att systemets arkitekturdokument skrevs och uppdaterades under projektets gång. Arki-tekten hade även näst sista ordet i tekniska frågor.

4.1.5

Testledare

Testledaren beslutade om systemets status och satte upp tester för mål och delmål av pro-jektet. Testledaren skötte den dynamiska verifieringen och valideringen av systemet genom exekvering av tester, samt testade kvalitetskrav tillsammans med kvalitetssamordnare och testade systemet mot kraven. Testledaren hade en viss distans till koden och skapade test utifrån dokumentation och inte utifrån skriven kod, samt skrev testplan och testrapport.

4.1.6

Kvalitetssamordnare

Kvalitetssamordnaren såg till att kvalitetsarbete utfördes överallt och av alla roller, samt ha-de initiativ- och uppföljningsansvar. Kvalitetssamordnaren såg också till att om erfarenhet saknades så skulle någon eller några i gruppen utbildas för att täcka denna brist. Kvalitets-samordnaren skulle även fånga upp erfarenheter där det fanns och dra nyttja av de personer som redan har kunskap inom ett område. Tillsammans med gruppen skulle även kvalitets-samordnaren planera och budgetera kvalitetssäkring (eng. Quality Assurance) för projektet. Dessutom skrev kvalitetssamordnaren en kvalitetsplan, såg till att denna uppdaterades och ansvarade för kontakt med kvalitetskursen.

4.1.7

Dokumentansvarig

Den dokumentansvarige ansvarade för att designa eller leta upp dokumentmallar till doku-ment som skulle lämnas in och användas under projektets gång. Den dokudoku-mentansvarige hade även ansvar för att det fanns rutiner för hur, när och hur ofta dokument skulle uppda-teras samt hanterade olika versioner av dokument. Dessutom hade den dokumentansvarige ansvar för att se till att dokument och inlämningar blev klara i tid och såg till att de som behövde jobba på dokumenten gjorde det.

4.2. Utvecklingsmetod

4.1.8

Konfigurationsansvarig

Den konfigurationsansvarige ansvarade för vilka delar av projektet som skulle versionshan-teras samt vilka verktyg som skulle användas för detta. Hen såg även till att alla verktyg användes på rätt sätt och utbildade gruppen om nödvändigt. Dessutom beslöt den konfigu-rationsansvarige vilka arbetsprodukter som ingick i en utgåva samt hur gruppens arbetsflöde såg ut och utformades.

4.2

Utvecklingsmetod

Under projektet valde projektgruppen att arbeta enligt den agila arbetsmetoden Scrum. Vid användningen av Scrum arbetade gruppen i iterationer, också kallade sprintar.

4.2.1

Sprintar

Varje sprint inleddes med ett sprintplaneringsmöte. Under detta möte sattes mål upp för vad gruppen skulle åstadkomma och var i projektet gruppen önskade vara när sprinten var genomförd två veckor senare. Dessa mål delades sedan upp i mindre mer konkreta arbets-uppgifter och lades in och spårades i gruppens bräde i GitLab, se 4.2.5.

Vid slutet av varje sprint anordnades en sprintutvärdering där gruppen utvärderade arbe-tet som gjorts under sprinten och om målen som sattes upp vid sprintplaneringsmöarbe-tet nåtts, se 5.5.2. Utvärderingen behandlade även vad som fungerat bra och vad som kan ändras till framtida sprintar för att på så sätt förbättra arbetsprocessen baserat på gruppens erfarenheter.

4.2.2

Dagliga Scrummöten

För att projektgruppen skulle få en överblick över varandras arbete och framsteg hölls dagli-ga Scrummöten. Under dessa möten berättade varje projektmedlem vad de arbetat på under föregående dag, vad de skulle arbeta på idag och om de behövde hjälp med någonting som hindrade deras fortsatta arbete.

4.2.3

Utveckling

Vid utveckling av systemet valde projektgruppen att arbeta i mindre grupper för att föra arbetet framåt på hela produkten istället för att fokusera på en specifik del. Dessa mindre grupper bestod av två till tre personer som hade olika utvecklingsområden under sprintarna, se 4.2.1. De olika utvecklingsområdena var under större delen av projektet hårdvara, data-baser och REST API. Gruppstorleken på två till tre personer tillät grupperna att arbeta med parprogrammering under sprintarna.

4.2.4

Testning

Strategin i projektet för att upprätthålla felfri kod var baserad på både automatisk och ma-nuell testning. Testprocessen började redan i början av en sprint där aktiviteter specificera-des och testfall specificera-designaspecificera-des. Under tiden sprinten pågick skapade projektets utvecklare egna mindre tester för att säkerhetsställa funktionalitet. Större tester planerades och dokumentera-des för att testledaren skulle kunna besluta om systemets status. För att veta vilka tester som planerades och hur de genomfördes skapades en testplan. Utfallet från testerna dokumente-rades i en testrapport. När kod lades till på GitLab utfördes en automatisk kontroll av den nya koden via GitLabs egna CI/CD, se 3.2.2. Kontrollen bestod av kodgranskning med Fla-ke8, se 3.2.3, kodtäckningsanalys med Coverage.py samt exekvering av ett antal tester som skrivits.

4.2. Utvecklingsmetod

Figur 4.1: Ett exempelbräde

4.2.5

Kanbanbrädet

Under projektet användes en variant av Kanban för att strukturera arbetet. På ett bräde dela-des aktiviteter upp i följande kategorier: ”todo”, ”assigned”, ”doing” och ”closed” (se figur 4.1). Aktiviteter som ännu ej påbörjats och som dessutom ännu ej tilldelats till någon i pro-jektgruppen placerades i ”todo”. När en aktivitet blivit tilldelad lades den i ”assigned” av en person den tilldelats. När en aktivitet sedan påbörjades flyttades den som förväntat till ”doing” av densamma. När en samling aktiviteter motsvarande en funktion avslutats skic-kades den för granskning. När arbetet hade granskats kunde det antingen skjutas tillbaka till ”todo” med kommentarer om vad som behövde förändras eller läggas i ”closed” och anses vara klart. Mer om granskningen finns att läsa i avsnitt 4.2.7.

4.2.6

Dokument

Dokument som skrevs för stöd under utvecklingsarbetet var följande:

• Arkitekturdokument: Arkitekturdokumentet användes som ett verktyg och beslutsun-derlag när nya delar av systemet skulle implementeras. Dokumentet gav projektmed-lemmarna en bättre överblick över systemet och de olika delarnas ansvarsområde. • Kravspecifikation: Kravspecifikationen användes som ett formellt protokoll och

verka-de som beslutsunverka-derlag unverka-der utvecklingsfasen. Kraven som sattes upp i kravspecifi-kationen medförde att otydligheter om vad som skulle göras försvann. Kravspecifika-tionen uppdaterades vid behov när ett krav förändrades.

• Kvalitetsplan: Kvalitetsplanen satte en tydlig plan för hur kvalitetsarbetet skulle utfö-ras. Där definierades utvärderingsprocesser och processer för processförbättring. Mät-ningar och uppföljning av krav behandlas också i kvalitetsplanen. Kvalitetsplanen upp-daterades i samband med varje sprintutvärdering.

• Projektplan: Projektplanen användes som ett stöd vid planering av sprintar samt fun-gerade som ett protokoll då den gav en översikt över leveranser och givna deadlines. • Systemanatomi: Systemanatomin gav en enkel beskrivning av hur systemet var tänkt

att vara uppbyggt. Från systemanatomin kunde projektmedlemmar enkelt se relationer och beroenden mellan olika tjänster, funktionalitet och kommunikation.

• Testplan: Testplanen skrevs i syfte att ge en insyn i hur och när tester skulle utföras. • Testrapport: Testrapporten dokumenterade utförda tester och mätningar som utfördes

i samband med testningen. Testrapporten uppdaterades vid varje sprintutvärdering. Dokumenten skrevs i LaTeX med verktyget Overleaf för att möjliggöra samtidig redigering och för att få en bra översikt över alla dokument.

4.3. Informationssamling

4.2.7

Kodgranskning

För att kod under projektet skulle hålla en hög standard användes kodgranskning. En stor del av kodgranskningen utfördes redan under utvecklingens gång då tekniken parprogram-mering användes, se 3.4.1. Tekniken tillät att koden granskades av en navigatör under ti-den ti-den skrevs och vid oklarheter kunde gruppmedlemmar i paren diskutera med varandra. Projektgruppen använde även kodgranskning när ny funktionalitet var färdigutvecklad och skulle sammanfogas med utvecklingsgrenen, se 4.2.9. Initialt granskades koden med hjälp av verktyget Flake8, se 3.2.3 som hittade fel och kontrollerade att koden följde kodstandarden PEP8. Därefter tilldelades gruppmedlemmar som inte arbetat med funktionen att granska den skrivna koden för att försöka finna fel eller oklarheter. Om ett fel upptäcktes nekades koden att få sammanfogas och författarna till koden fick åtgärda problemen för att få koden granskad på nytt.

4.2.8

Dokumentgranskning

Innan dokument skulle lämnas in utfördes en dokumentgranskning. Alla gruppens medlem-mar granskade dokument utifrån språk och innehåll och lämnade kommentarer med hjälp av granskningsfunktionaliteten i Overleaf. När alla medlemmar granskat dokumenten hölls ett möte där synpunkter på dokumenten diskuterades och dokumenten uppdaterades utefter dessa.

4.2.9

Versionshantering

För att hantera den kod som skrevs under projektet och de olika versionerna som gruppen producerade under projektet valde projektgruppen att arbeta med GitLab. Med gruppens utvecklingsmetod i åtanke (se 4.2.3) valde gruppen att arbeta enligt Git-arbetsflödet Feature Branches. För projektgruppen innebar detta att huvudgrenen av projektet alltid skulle ha en fungerande stabil version på sig. Från huvudgrenen klonades en utvecklingsgren. Utveck-lingsgrenen var för gruppen en mellanlandning av olika versioner av produkten. För att ut-veckla en ny funktion klonades utvecklingsgrenen till en funktionsgren. På funktionsgrenen kunde varje mindre grupp, se 4.2.3, arbeta på en ny funktion till produkten. För att sedan få sammanfoga den nyutvecklade funktionen på funktionsgrenen med utvecklingsgrenen be-hövde koden som skrivits granskas enligt 4.2.7. Först efter godkännande från den utomstå-ende gruppmedlemmen kunde funktionsgrenen sammanfogas med utvecklingsgrenen. När gruppen ansåg att alla funktioner var implementerade och sammanfogade med utvecklings-grenen kunde utvecklingsutvecklings-grenen sammanfogas med huvudutvecklings-grenen som en ny stabil version av produkten.

4.3

Informationssamling

För att få en bättre helhetsbild över problemen som uppdraget skulle lösa behövdes en bre-dare förundersökning göras. Förundersökningen utfördes genom både en litteraturstudie om farliga ämnen och genom kontakt med en person som verkar inom området.

4.3.1

Förundersökning

För att få en bättre förståelse av hur räddningstjänsten arbetar och vilka sensorer som var relevanta att fokusera implementation på utfördes en förundersökning. Förundersökningen bestod av en litteraturstudie där gruppen samlade information om vilka ämnen som rädd-ningstjänsten kommer i kontakt med vid hantering av olycksplatser. För att finna litteratur sökte gruppen efter information och publikationer kring ämnet via Linköpings universitets-bibliotek och via sökmotorn Google. Där användes sökfraserna: ”toxic gases and vapours

4.4. Metod för att fånga erfarenheter

produced during fires”, ”giftiga gaser vid brand”, ”VOC’s released during fire” och ”Toxici-ty of Building Materials”. För att komplettera och finna mer information om de ämnen som fanns under litteraturstudien användes MSB:s RIB-databas över farliga ämnen. Under littera-turstudien undersöktes även i vilka situationer och omständigheter som de farliga luftburna ämnena bildas eller frigörs samt på vilket sätt ämnena är farliga för räddningstjänsten. Med information om ämnen som räddningstjänsten riskerar att komma i kontakt med på olycks-platser undersöktes om det fanns sensorer på marknaden som var kompatibla med den givna hårdvaran och kunde detektera någon av de önskade farliga ämnena.

4.3.2

Möte med kontaktperson från räddningstjänsten

Då det gjorts en litteraturstudie kring hur räddningstjänsten arbetar samt deras exponering av farliga ämnen upplevdes att informationen behövde kontrolleras mot hur räddningstjäns-ten arbetar. Projektgruppen hade från kunden fått tillgång till en kontaktperson inom rädd-ningstjänsten som frågor kunde ställas till. Ett möte sattes upp där kontaktpersonen från räddningstjänsten gav en presentation av deras arbete och där frågor kunde ställas. Informa-tionen från mötet sammanställdes i ett dokument för att senare kunna användas i förunder-sökningen.

4.4

Metod för att fånga erfarenheter

I detta avsnitt beskrivs de huvudsakliga metoderna projektgruppen har används sig av för att fånga erfarenheter relevanta till projektet.

4.4.1

Sprintutvärdering

Efter varje sprint genomfördes en utvärdering av gruppens utvecklingsarbete. Under utvär-deringen diskuterades i helgrupp vad som fungerat bra respektive dåligt under sprinten. Dessa erfarenheter antecknades i ett mötesprotokoll och kunde följas upp. Vidare beskriv-ning av utvärderingen finns i avsnitt 5.5.2.

4.4.2

Kommunikation och dokument

Under projektets gång användes Microsoft Teams för både kommunikation och dokumenta-tion. Varje arbetsområde fick en egen kanal vilket möjliggjorde enkel kommunikation mellan de olika arbetsgrupperna. Samtliga kanaler hade egna dokument som uppdaterades vid ut-veckling vilket gjorde det möjligt för alla i projektgruppen att sätta sig in i varandras arbeten.

4.4.3

Dagligt Scrummöte

Genom att vid varje dagligt Scrummöte fråga om det fanns något som hindrade fortsatt arbete kunde problem enklare synliggöras för hela gruppen. Detta gjorde det möjligt att på ett enkelt sätt få hjälp av andra projektmedlemmar som besatt kunskap inom området. Genom att få hjälp av en annan gruppmedlem utnyttjades den kunskap och erfarenheten som redan fanns inom gruppen istället för att på nytt söka information.

5

Resultat

Detta kapitel presenterar projektets resultat. Detta görs genom att presentera systembeskriv-ning, processbeskrivning och gemensamma erfarenheter. Kapitlet presenterar även en över-blick över samtliga individuella bidrag.

5.1

Systembeskrivning

I projektet skapades ett system som visualiserar förekomsten av butan, vätgas, ammoniak, sulfiter och bensen i luften. Detta kapitel presenterar systemet och innehåller en beskrivning av de abstraktioner som gjorts av systemet samt en överblick av dess komponenter.

5.1.1

Systemanatomi

I början av projektet utvecklades en systemanatomi till det system projektgruppen skulle ut-veckla, som vilken syns i figur 5.1. Systemanatomin gav projektgruppen en bra översikt över systemets olika funktioner och hur de berodde av varandra. En pil från en funktion till en annan funktion symboliserar att den första funktionen behöver den andra. Systemanatomin var på så vis även en bra indikator för i vilken ordning funktionalitet skulle implementeras och testas.

Projektgruppen delade in systemets funktioner i fyra kategorier: tjänster, funktionalitet, kommunikation och hårdvara. Med tjänster avsågs de funktioner som användaren av syste-met förväntades interagera med och var baserade på de krav som specificerats av projekt-gruppen. Kategorin funktionalitet tilldelades de funktioner hos systemet som inte används av en användare direkt. Kommunikation var de funktioner som hanterade kommunikation mellan två av systemets komponenter och där möjligheten att testa funktionen inte var be-roende av korrekt data. Hårdvarukategorin beskrev de funktioner som kräver särskild hård-vara för att kunna utföras men där de funktioner rörande gränssnitt mellan två av systemets delar utesluts.

5.1. Systembeskrivning Se nuvarande batteriprocent för en sensorenhet Se graf för historiska mängder av ämnen från en sensorenhet Se mängden av olika ämnen från en sensorenhet Sensorenheternas positioner visas på en karta Användaren kan anpassa vid vilka nivåer av ett ämne

larm går av

Larm går av ifall en sensorenhet visar höga värden av ett

ämne Användargränssnitt kan kommunicera med databaser (Grafana) Data från sensorenheter skickas till Chirpstacken

Rest API kan kommunicera med databaser (SQL) Chirpstacken kan kommunicera med Rest API (HTTP) Strömförsörjning Sensorenheter kan kommunicera med förmedlingsnod (LoRa) Förmedlingnod kan kommunicera med Chirpstacken (WiFi / 4G) Sensorer mäter mängden av olika ämnen Sensorenhet kan läsa

av mängden av olika ämnen Data från sensorenheter sparas i databaser Användargränssnitt kan hämta sensorenheternas data från databaser Tjänster Funktionalitet Kommunikation Hårdvara

Rest API avkodar data från sensorenheter

Figur 5.1: Systemanatomi för projektet.

5.1.2

Översikt

För att ge en översikt över systemet så skapades en abstraktion av det. I abstraktionen, som syns i figur 5.2, delas systemet in i tre delar: hårdvara, server och användargränssnitt. Hård-varan samlar in, paketerar och skickar iväg data till en server. Servern behandlar och lagrar denna data i två databaser. Från dessa databaser hämtar och visar användargränssnittet den behandlade datan för användaren.

5.2. Hårdvara

Figur 5.2: Överblick av systemets delar.

5.1.3

Komponenter

För att öka projektgruppens förståelse av systemet skapades en utökad abstraktion utifrån ab-straktionen i figur 5.2. Den utökade abab-straktionen innehåller mer detaljerade beskrivningar av systemets komponenter och gränssnitten mellan dem, se figur 5.3. I bilden representeras komponenter av blåa boxar och kommunikationsvägar mellan komponenter representeras av pilar med tillhörande gröna boxar. I denna modell syns även vilken del av systemet var-je komponent tillhör. Systemet är riktat till två typer av användare i varsin ände: den som ska bära de uppkopplade sensorenheter på plats, och den som ska interagera med användar-gränssnittet. I sektionerna 5.2, 5.3, och 5.4 beskrivs komponenterna och hur de kommunicerar mer utförligt.

Figur 5.3: Detaljerad bild över systemets komponenter och vilka delar de tillhör.

5.2

Hårdvara

Hårdvara är den del av systemet som ansvarar för att ute i fält samla in, paketera och skicka data från sensorer samt metadata vidare till systemets serverdelar. I detta kapitel presenteras

5.2. Hårdvara

den byggda sensorenheten och förmedlingsnoden samt hur data överförs från sensorenheten hela vägen fram till Chirpstack.

5.2.1

Sensorenhet

En sensorenhet består av en Pycom LoPy4, en Pycom Pytrack, ett portabelt batteri samt tre gassensorer av modell MQ-2, MQ-8 och MQ-135, vilka mäter butan, vätgas respektive am-moniak, sulfiter och bensen. Gassensorerna ger en analog utsignal i form av spänning, där en högre spänning motsvar en högre halt av ett ämne. Mätdata för varje gassensor tolkas och paketeras tillsammans med GPS-position och accelerometerdata i ett datapaket som över LoRa skickas till förmedlingsnoden.

Sensorenheten konstruerades med hjälp av en expansionslist, expansionslisten sitter mel-lan Pycom LoPy4 och Pycom Pytrack för att möjliggöra inkoppling på Pycom LoPy4:s ana-loga portar. Expansionslisten bryter ut och ger tillgång till de anaana-loga portarna på Pycom LoPy4, som annars sitter dolda inne i expansionskortet. Sensorenhetens konstruktion visas i figur 5.4. Gassensorerna kopplades in i Pycom LoPy4 enligt kopplingsschemat i figur 5.5, där Pycom LoPy4 monterades på en Pycom PyTrack via expansionslisten.

5.2. Hårdvara

Figur 5.5: Illustration av kopplingsschemat för gassensorerna.

5.2.2

Förmedlingsnod

Förmedlingsnoden består av en Pycom GPy och en Pycom PyGate. Pycom PyGate möjlggör för förmedlingsnoden att agera som en LoRa-router så att den kan ta emot data från flera sensorenheter samtidigt. Förmedlingsnoden kopplas även upp till ett WiFi för att ha nätverk-såtkomst. Den tar emot data från sensorenheter över LoRa och vidarebefordrar informationen till en Chirpstack-instans via WiFi, se avsnitt 5.3.1. Hur förmedlingsnoden ser ut visas i figur 5.6.

5.2. Hårdvara

Figur 5.6: Illustration av förmedlingsnodens konstruktion.

5.2.3

Data från sensorenhet till förmedlingsnod

För projektet användes en modifierad variant av CayenneLPP för att skicka data från indivi-duella sensorenheter till dess förmedlingsnod. För varje sensor som ska med i datapaketet packas först två bytes som talar om vilken sensor det är och hur många nästkommande bytes som sedan anger mätvärdet för den sensorn. Till exempel har en GPS-sensor värdet 0 i sin första byte vilket innebär att det är 8 bytes mätdata, dess andra byte förblir oanvänd, däref-ter följer 4 osignerade bytes som anger latitud samt 4 osignerade bytes för longitud. I figur 5.7 visas ett exempel på ett datapaket med GPS-data. GPS, accelerometer och varje gassen-sor har på så vis varsin unik första byte (i CayenneLPP kallat kanal-byte) som definierats av projektgruppen, där det är trivialt att utöka formatet med nya sensortyper.

5.3. Server

5.2.4

Data från förmedlingsnod till Chirpstack

Datan som skickas från en förmedlingsnod erhålls i Chirpstacken (Chirpstack förklaras un-der delkapitel 5.3.1). Den innehåller framförallt ett datafält bestående av den kodade mät-data som skickas från en särskild sensorenhets GPS, accelerometer och gassensorer. Utöver datafältet så bifogar förmedlingsnoden diverse metadata, bland annat sitt eget och senso-renhetens unika ID:n samt hur många paket som skickats sedan sensorenheten startade sin nuvarande session. I figur 5.8 visas ett exempel på ett datapaket som skickats från en senso-renhet.

Figur 5.8: Ett exempel på ett datapaket från Chirpstack.

5.3

Server

Server är den del av systemet som tar emot mätdata från hårdvara och lagrar den i två da-tabaser. Med server syftar rapporten på en dedikerad server där samtliga docker-containers kördes för de fyra olika delarna: en Chirpstack-instans, ett REST API, en InfluxDB-databas och en PostGIS-databas. Chirpstack mottar datapaket från förmedlingsnoder och vidarebe-fodrar dem till REST API:et som avkodar dem och placerar resulterande data i de två data-baserna. Mer detaljer om serverns olika delar hittas i avsnitten 5.3.1, 5.3.2 och 5.3.3. Serverns fyra delar är utvecklade i varsin docker-container för att göra systemet modulärt men samti-digt smisamti-digt att installera. Förutom utveckling på egna datorer valdes även att placera dessa fyra delar på en virtuell linuxmaskin som gjordes tillgänglig över internet. Det underlättade hämtning av datapaket från hårdvara på två olika platser samtidigt som det fungerade som ett test för integration av komponenterna.

5.3.1

Chirpstack

I detta projekt används en färdig och fullständig docker-bild innehållande både ”Chirp-stack Gateway Bridge”, ”Chirp”Chirp-stack Network Server” samt ”Chirp”Chirp-stack Application Ser-ver”. Chirpstack Gateway Bridge ansvarar för att ta emot datapaket från förmedlingsno-der. Chirpstack Network Server köar upp och hanterar datapaketen ungefär som en förmed-lingsnod för LoRa-Gateways. Chirpstack Application Server innehåller ett antal