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 smidigt 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”, ”Chirpstack Network Server” samt ”Chirpstack 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 programme-
5.3. Server
ringsgränssnitt (API:er) för att vidarebefordra data varvid projektgruppen använder HTTP- integrationen för att vidarebefordra datapaketen i en JSON-struktur till REST API:et, se 5.3.2. Varje enskild hårdvaruenhet måste registreras på Chirpstack Application Server för att Chirp- stack ska veta vilka enheter och data som ska skickas till REST API:et. Figur 5.9 ger en över- blick över Chirpstackens olika delar och hur de är kopplade till varandra.
Figur 5.9: De olika delarna av Chirpstack, där LoRa GateWay är förmedlingsnoderna och HTTP i ”Integrations” kopplas till REST API [33].
5.3.2
REST API
REST API komponenten använder ramverket FastAPI och utvecklades utifrån det sekvens- diagram som kan ses i figur 5.10. REST API komponenten tar emot en JSON-struktur från Chirpstack där fältet data innehåller den kodade sensordatan, se figur 5.8. Sensordatan av- kodas först genom att konverteras från talbas 64 till en sekvens av bytes. Sekvensen av bytes avkodas sedan genom att läsa de två första bytesen som representerar en kanal. Utifrån ka- nalens värde kan REST API komponenten läsa av vilken sensor datan tillhör, antal bytes som ska läsas och hur datan är paketerad i en fördefinerad tabell. Mer information om hur data paketeras finns i kapitel 5.2.3 och 5.2.4.
Den avkodade datan lagras i en Python dictionary, se figur 5.11, och skickas till ett da- tabasgränssnitt som gruppen utvecklat. I detta gränssnitt ansluter REST API:et till de två databaserna. Vid godkänd anslutning plockas datan ut ur den JSON-struktur som skickas från REST API:et och insättningsförfrågningar (eng. insert querys) för respektive databas (In- fluxDB och PostGIS) konstrueras. Därefter används insättningsförfrångningarna för att via anslutningar till databaserna föra in given data. Mer information om vilken data som lagras i databaserna finns i kapitel 5.3.3.
5.3. Server
Figur 5.10: Sekvensdiagram för REST API komponenten.
Figur 5.11: Datastruktur efter avkodning.
5.3.3
Databaser
För lagring av data används de två databaserna PostGIS och InfluxDB. I PostGIS finns tre tabeller: en för personer, en för sensorenheter där den kopplas till personer och en tabell med enhetsdata som innehåller några av kolumnerna som presenteras i tabell 5.3.3, vilka står
5.3. Server
i tabellen. Sensordatan som presenteras i tabell 5.3.3 lagras i InfluxDB. PostGIS-databasens struktur visas i ett ER-diagram i figur 5.13 och ett relationsdiagram i figur 5.12. I figur 5.14 presenteras InfluxDBs strukturdiagram. I tabell 5.3.3 följer en kort beskrivning av de kolum- ner i PostGIS och InfluxDB som innehåller sensordata.
Tabell 5.1: Tabell med fältförklaring för datan i databaserna Fält Förklaring
ts en tidsstämpel på datapaketet, lagras också i PostGIS
id sensorenhetens unika id som också är en etikett (eng. tag) på datan in InfluxDB, lagras också i PostGIS
tick datapaketets ordningstal som återställs vid varje uppstart av en senso- renhet, lagras också i PostGIS
lat sensorenhetens latitudkoordinat, lagras också i PostGIS long sensorenhetens longitudkoordinat, lagras också i PostGIS x accelerometervärde x-axel y accelerometervärde y-axel z accelerometervärde z-axel mq2 sensorvärde för sensor mq2 mq8 sensorvärde för sensor mq8 mq135 sensorvärde för sensor mq135
5.3. Server
Figur 5.13: ER-diagram som beskriver PostGIS struktur och relationen mellan entiteter.
5.4. Användargränssnitt
5.4
Användargränssnitt
Användargränssnittet skapades med hjälp av Grafana och visualiserar den data som senso- renheterna samlar in. Grafana tillät gruppen att snabbt utveckla ett användargränssnitt där insamlade mätvärden över tid kunde visualiseras. Användargränssnittet visar även plats- information och en färgkarta som illustrerar de farliga luftburna ämnenas spridning. Den slutgiltiga versionen av användargränssnittet består av ett översiktsbräde och enhetsbräden, se figur 5.15 respektive figur 5.16. Översiktsbräde presenterar samtliga aktiva sensorenheter på en karta, en heatmap för varje sensor samt en lista över alla aktiva sensorenheter. Genom att klicka på en sensorenhet i lisan visas brädet för den specifika sensorenheten. För varje aktiv sensorenhet skapas dynamiskt ett enhetsbräde. Enhetsbrädet innehåller en karta där sensorenheten visas. Brädet visar även samtliga sensorvärden tillsammans med accelerome- tervärderna och en översiktspanel bestående av alla sensorvärden över tid.
I projektet användes Grafanas inbygga funktionalitet för att hämta data från databaser där en anslutning konfigureras och sparas för kontinuerliga hämtningar. Systemet leverera- des inställt på en uppdateringsperiod om fem sekunder, där gränssnittet alltså får in ny data var femte sekund från databaserna. Efter upprepade försök visade sig fem sekunder vara en bra grundperiod för sensorenheten. Dessutom har Grafana en inbyggd standarduppdate- ringsperiod på fem sekunder.
5.5. Processbeskrivning
Figur 5.16: Exempelbild på hur ett enhetsbräde ser ut i Grafana.
5.5
Processbeskrivning
I följande avsnitt beskrivs centrala processer för projektet.
5.5.1
Process i fokus
Den process som låg i fokus för projektet var Kanbanbrädet som användes under projektets gång. Den slutgiltiga versionen av detta beskrivs i 4.2.5. Till en början fanns en kategori i Kanbanbrädet som hette ”to review” som skulle användas till processen att granska kod och dokument, men som valdes att tas bort och ersättas då den upplevdes otillräcklig. Gransk- ning av kod gjordes istället med hjälp av GitLabs inbyggda funktionalitet för sammanslag- ning (eng. merge request). Processen för dokumentgranskning gjordes istället inuti Overleaf med hjälp av deras egna granskningssystem som tillåter användaren att markera text och skriva kommentarer. Tanken bakom processförändringen var att göra Kanbanbrädet enklare att använda och att flytta granskningen till mer specialiserade verktyg.
5.5.2
Utvärdering
Vid utvärderingarna fyllde varje projektmedlem i en enkät om sprinten och arbetsproces- sen. Enkäten var anonym och innehöll följande frågor gällande processen i fokus respektive sprinten:
• Upplever du att ärendespårning (eng. issue tracking)) har hjälpt dig veta vad du ska göra denna sprint? Svar i skala 1-5: Inte alls - fullständigt
• Upplever du att strukturen för vår ärendespårning är tydlig? Svar i skala 1-5: Mycket otydlig - mycket tydlig
• Har du känt dig hjälpt av projektets ärendespårning i ditt arbete? Svar i skala 1-5: Inte alls - mycket stor hjälp
5.6. Gemensamma erfarenheter
• Vad har fungerat bra under sprinten? Svar i fritext
• Vad har fungerat mindre bra under sprinten? Svar i fritext • Vad kan vi ta med oss ifrån denna sprint? Svar i fritext
• Några övriga tankar om hur sprinten har fungerat eller sett ut? Svar i fritext
Enkäten togs fram av gruppen. Vid varje utvärderingstillfälle gicks svaren på enkäten igenom för att jämföras med tidigare iterationer för att hitta mönster och se hur eventuella förändring- ar påverkat svaren. Brädet låg i projektets GitLab och versionshanterades vilket underlättade vid utvärdering då det gick att jämföra iterationer av processen. Till en början innehöll en- käten bara frågor om processen i fokus men kompletterades senare med allmänna frågor om sprinten för att få ett bredare underlag till utvärderingsmötena.
5.5.3
Mätningar
Under projektets gång genomfördes ett antal mätningar kontinuerligt i syfte att utvärdera projektets effektivitet och framsteg över tid. För varje sprint jämfördes antalet aktiviteter som satts upp med antalet avklarade aktiviteter för den sprinten. Syftet med detta var till stor del att se om gruppen planerat in en lämplig arbetsbörda för sprinten eller om den behövde ökas alternativt minskas till efterkommande sprintar. För att spåra hur produkten utveckla- des över tid gicks kraven igenom varje sprint. Antalet uppnådda krav jämfördes med antalet krav som satts upp för produkten för att ge en siffra på hur långt produkten var kommen. Den primära resursen som disponerats inom projektet var projektmedlemmarnas arbetstid. Antal timmar arbetade spårades för varje medlem och jämfördes med slutmålet om 400 tim- mar arbetade per medlem. På utvärderingsmöten lyftes insamlad data kring varje mätning och jämfördes med data från tidigare sprintar för att sedan analyseras. Kring de slutsatser som drogs gjordes förändringar av processer i syfte att effektivisera och underlätta framtida arbete. En förbättring som kunde mätas var förändringen av granskningsprocessen och Kan- banbrädet som beskrivs i avsnitt 5.5.1. Den tillkom efter att det vid utvärdering visade sig vara otillräckligt att endast ha en Kanbankategori för att hantera granskning. Under utvärde- ringsmötena diskuterades vad som upplevts bra och vad som upplevts dåligt under sprinten utifrån enkätsvaren. Läget jämfördes med målen som sattes upp i början på sprinten:
• Nåddes målen med sprinten?
• Var befinner sig projektet jämfört med slutmålet? • Vilka nya krav uppfyller produkten?
I samband med utvärderingsmötet skickades också en uppdatering till kund för ökad trans- parens. Denna uppdatering utformades av gruppen och innehöll en sammanfattning av de framsteg som gjorts gentemot kundens krav och hur produkten såg ut i dagsläget.
5.6
Gemensamma erfarenheter
Detta avsnitt beskriver de gemensamma erfarenheter projektgruppen erhållit från detta pro- jekt.
5.6.1
Projektorganisation
En viktig erfarenhet som projektgruppen tar med sig är hur ett projekt kan struktureras på ett bra sätt. I början av projektet hölls ett möte där projektmedlemmarna kom överens om mål, arbetssätt och projektroller. Rollerna och hur projektgruppen skulle arbeta skrevs ner i
5.6. Gemensamma erfarenheter
ett gruppkontrakt som gjorde att oklarheter under projektet suddades ut. För varje roll de- finierades olika ansvarsområden där respektive roll var ansvarig för beslutsfattandet. Detta gav alla gruppmedlemmar erfarenhet av ansvar och beslut gentemot en grupp. En annan er- farenhet som projektgruppen erhållit är hur det är att arbeta i projekt mot en kund. I tidigare projekt under studietiden har det funnits en trygghet i att ha en handledare eller assistent till hands när en uppgift ska lösas. I detta projekt gavs istället ett större ansvar att ta egna beslut och lära sig på vägen.
Tidigt i projektet skrevs värdefull dokumentation som bland annat en kravspecifikation och då insågs vikten av kommunikation vid arbete mot en kund. Det fanns från projektets start inte en uppsättning färdiga krav utan det var något som gruppen fick definiera själva för att sedan stämma av med kund. I tidigare projekt har det ofta varit tydligt vad som ska göras och funnits ett tydligt mål.
Projektgruppen delades in i tre arbetsgrupper med olika ansvar och det var något som fungerade bra. Varje arbetsgrupp innehöll två till tre personer vilket gjorde att parprogram- mering kunde användas, att det alltid fanns någon att diskutera med och att projektgruppen inte blev beroende av en enskild person. Projektgruppen ansåg att indelningen i arbetsgrup- per gjorde det tydligare vad varje person fick ansvar för och vad som skulle göras. Personerna som ingick i arbetsgrupperna hoppade inte runt mellan olika arbetsgrupper. Detta uppskat- tades av projektgruppen då det gjorde det lättare att veta vem de kan kontakta vid hjälp inom ett särskilt område.
Kommunikationen i gruppen tycker de flesta gruppmedlemmar varit bättre än i tidigare projekt vilket gav insikten av hur viktigt samarbete är i ett större projekt. Den goda stämning- en i gruppen gjorde också det enklare för gruppmedlemmar att dyka upp på varje schemalagt tillfälle och planera in distansträffar utanför arbetstid. Att arbeta helt på distans är en erfa- renhet som projektgruppen tar med sig och något som gruppen anser är en viktig erfarenhet då flera företag arbetar på distans.
5.6.2
Arbetsmetod
En annan erfarenhet som projektgruppen tar med sig är erfarenheten att arbeta med den agila utvecklingsmetoden Scrum. De flesta i projektgruppen hade teoretisk kunskap om ar- betsmetoden men ingen praktisk erfarenhet. Projektgruppen ansåg att metoden var bra och att det är en metod de kan tänka sig att arbeta med framöver. Något som uppskattades med arbetsmetoden var de dagliga Scrummötena som sammanförde arbetsgrupperna. Tack vare de dagliga mötena kunde projektmedlemmarna få en större insikt i vad övriga arbetsgrup- per arbetat med och om problem uppstod kunde de snabbt lösas eller följas upp. Med Scrum har gruppen fått erfarenheten av att planera ett större projekt genom sprintplaneringsmöten och utvärdera med hjälp av utvärderingsmöten. Utvärderingsmötena var något som gruppen uppskattade och de medförde att arbetsmetoden kontinuerligt kunde revideras.
5.6.3
Tekniska erfarenheter
Trots att projektgruppen sedan innan hade en bred teknisk erfarenhet har flera nya områden introducerats. Med anledning av att projektgruppen delades upp har olika gruppmedlemmar fått olika mycket kunskap inom vissa områden. Tekniska erfarenheter som projektgruppen tar med sig är att arbeta hårdvarunära med MicroPython, att använda virtuella containers genom Docker, att avkoda data med REST API, att designa ett användargränssnitt i Grafana och att lagra information i InfluxDB och PostgreSQL.
För dokumentskrivande användes typsättningssystemet LaTeX vilket är en viktig erfa- renhet som tas med. Flera av projektgruppens medlemmar hade aldrig tidigare arbetat med LaTeX men kunde snabbt inse hur kraftfullt systemet är. En annan erfarenhet som tas med är hur inlärningen av tekniska färdigheter gått till. Tidigare har inlärning av tekniker och program nästan alltid introducerats med föreläsningar eller laborationer, men i projektet la-