Videoströmningsarkitektur för ett molnbaserat drönarsystem

Linköpings universitet SE–581 83 Linköping

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

2020 | LIU-IDA/LITH-EX-G--20/017--SE

Videoströmningsarkitektur för ett

molnbaserat drönarsystem

Video streaming architecture for a cloud based drone system

Robert Almgren

Hugo Cedervall

Mattias Ljung

Daniel Norström

Helena Orädd

Martin Steen-Holmberg

Caspian Süsskind

Handledare : Erik Matti Examinator : Kristian Sandahl

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publiceringsdatum 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 kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning 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 upphovsmannens 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 download, 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 procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. © Robert Almgren Hugo Cedervall Mattias Ljung Daniel Norström Helena Orädd Martin Steen-Holmberg Caspian Süsskind

Sammanfattning

Denna rapport behandlar det arbete som under våren 2020 utfördes av en grupp på sju civilingenjörsstudenter i data- och mjukvaruteknik vid Linköpings universitet som en del av kursen TDDD96 – Kandidatprojekt i programvaruutveckling. Projektet utfärdades på efterfrågan av företaget Airpelago, och gick ut på att utveckla en stabil grund för ett molnbaserat videoströmningssystem. Denna rapport beskriver den färdiga produkten, förklarar de beslut som togs, beskriver vilka problem som uppstått och hur dessa lösts, samt diskuterar det slutgiltiga arbetet. Rapporten innehåller även sju individuella bidrag skrivna av gruppens enskilda medlemmar.

Författarnas tack

Gruppen vill ägna ett stort tack till Airpelago som gjort det möjligt för gruppen att arbeta med detta projekt och även tillhandahållit det material som krävts. Projektet har varit mycket givande och väldigt lärorikt. Ett särskilt tack riktas till Tobias Fridén som alltid varit lätt att få kontakt med och som bidragit med mycket bra återkoppling. Gruppen skulle även vilja tacka Erik Matti, som varit gruppens handledare, och Kristian Sandahl, kursens examinator, för deras stöd och återkoppling genom gruppens arbete med projektet.

Innehåll

2.5 Drönare Utan Gränser - DUG . . . 6

3 Teori 7 3.1 WebRTC . . . 7

3.2 GStreamer . . . 7

3.3 Janus . . . 7

3.4 Janus Streaming Plugin . . . 8

3.5 Nginx . . . 8 3.6 Docker . . . 8 3.7 Docker Compose . . . 8 3.8 Raspberry Pi . . . 8 3.9 Raspberry Pi Kameramodul . . . 9 3.10 React . . . 9 3.11 Firebase Authentisering . . . 9 3.12 H.264 . . . 9 3.13 SRTP . . . 10 3.14 HTTPS . . . 10 3.15 Google Cloud . . . 10 3.16 Git . . . 10 3.17 Gitlab . . . 10

4 Metod 12

4.1 Arbetsmetod . . . 12

4.2 Roller . . . 12

4.3 Versionshantering . . . 14

4.4 Granskningar . . . 14

4.5 Metod för att fånga erfarenheter . . . 14

5 Resultat 16 5.1 Systembeskrivning . . . 16

5.2 Processbeskrivning . . . 20

5.3 Gemensamma erfarenheter . . . 22

5.4 Översikt över individuella bidrag . . . 23

6 Diskussion 24 6.1 Resultat . . . 24

6.2 Metod . . . 25

6.3 Arbetet i ett vidare sammanhang . . . 28

7 Slutsats 31 7.1 Hur kan videoströmningsarkitektur för molnbaserat drönarsystem implementeras för att skapa värde för kunden? . . . 31

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

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

7.4 Hur kan WebRTC tillsammans med Janus möjliggöra peer-to-peer videoströmning till flera klienter? . . . 32

7.5 Hur kan videoströmningsarkitektur för molnbaserat drönarsystem uppnå låg latens och uppfylla den säkerhet kunden önskar? . . . 32

7.6 Nåddes syftet med projektet? . . . 32

A WebRTC, RTMP och HLS, en jämförelse av Mattias Ljung 33 A.1 Inledning . . . 33 A.2 Bakgrund . . . 33 A.3 Teori . . . 34 A.4 Metod . . . 37 A.5 Resultat . . . 37 A.6 Diskussion . . . 38 A.7 Slutsatser . . . 38

B En jämförelse mellan videokodek H.264 och VP8 av Robert Almgren 40 B.1 Inledning . . . 40 B.2 Bakgrund . . . 40 B.3 Teori . . . 40 B.4 Metod . . . 42 B.5 Resultat . . . 43 B.6 Diskussion . . . 44 B.7 Slutsatser . . . 45

C Agil utvecklingsmetodik för mindre mjukvaruprojekt av Hugo Cedervall 46 C.1 Inledning . . . 46

C.2 Bakgrund . . . 47

C.3 Teori . . . 47

C.4 Metod . . . 49

C.6 Diskussion . . . 51

C.7 Slutsatser . . . 53

D Vikten av en utförlig kravspecifikation i ett mjukvaruprojekt av Daniel Norström 54 D.1 Inledning . . . 54 D.2 Bakgrund . . . 55 D.3 Teori . . . 55 D.4 Metod . . . 57 D.5 Resultat . . . 57 D.6 Diskussion . . . 59 D.7 Slutsats . . . 59

E Jämförelse av arbetsflöden i Git av Helena Orädd 61 E.1 Inledning . . . 61 E.2 Bakgrund . . . 62 E.3 Teori . . . 63 E.4 Metod . . . 65 E.5 Resultat . . . 65 E.6 Diskussion . . . 69 E.7 Slutsatser . . . 72

F Videointegritet av Martin Steen-Holmberg 73 F.1 Inledning . . . 73 F.2 Syfte . . . 73 F.3 Frågeställning . . . 73 F.4 Bakgrund . . . 74 F.5 Teori . . . 74 F.6 Metod . . . 75 F.7 Resultat . . . 76 F.8 Diskussion . . . 76 F.9 Slutsatser . . . 81

G Docker eller virtuella maskiner vid mjukvaruprojekt av Caspian Süsskind 83 G.1 Inledning . . . 83 G.2 Bakgrund . . . 83 G.3 Teori . . . 84 G.4 Metod . . . 86 G.5 Resultat . . . 86 G.6 Diskussion . . . 88 G.7 Slutsatser . . . 89

I. Intervju med kontaktperson inom sjöräddningssällskapet . . . 90

II. Enkätfrågor gällande arbetsflöden inom projektet . . . 92

III. Enkätsvar gällande arbetsflöden inom projektet . . . 94

IV. Systemanatomi . . . 98

Figurer

5.1 Översiktlig bild av systemets arkitektur. . . 16

5.2 Kommando för att starta en pipeline på Raspberry Pi. . . 17

5.3 Översikt av kommunikationen mellan Raspberry Pi och server. . . 17

5.4 Användargränssnittets autentiseringssidor. . . 18

5.5 Användargränssnittets huvudsida. Visar upp en videoström. . . 19

A.1 Simpel visualising av WebRTC . . . 34

A.2 RTMP översikt . . . 35

A.3 Header-struktur . . . 35

A.4 Exempel på AMF-meddelande . . . 36

A.5 Översikt av HLS-arkitekturen . . . 37

C.1 Exempel på hur en översiktlig bild av en Kanban tavla kan se ut . . . 49

C.2 Statistik på hur resultatet av 10 000 mjukvaruprojekt blev med deras arbetsmetod som varierande variabel . . . 52

D.1 Enkätsvar angående nivån av nytta medlemar hade av kravspecifikationen. 1 är lite nytta, 5 är mycket nytta. . . 58

D.2 Enkätsvar angående placering av nytta medlemar hade av kravspecifikationen. 1 är tidigt i projektet, 5 är sent. . . 59

E.1 Ett exempel på struktur då GitFlow används på ett projekt med två funktionsgrenar, en snabbfixgren och en utgivningsgren. . . 67

E.2 Ett exempel på struktur då OneFlow används på ett projekt med två funktionsgrenar, en snabbfixgren och en utgivningsgren. . . 68

G.1 Översikt av strukturen hos Docker . . . 84

G.2 Två typer av hypervisors . . . 86

I Projektets systemanatomi. . . 98

Tabeller

1

Inledning

Rapporten kommer att innefatta en gemensam del och sju individuella delar, en från vardera gruppmedlem. Den gemensamma delen beskriver utvecklingsprocessen och erfarenheter från att skapa ett molnbaserat system för videoströmning. De individuella delarna djupdyker i särskilda ämnen som kan kopplas till projektet.

Projektets ändamål är att ta fram en stabil videoströmningstjänst som kan distribueras på molnet. Videoströmmen ska användas från drönare vid sjöräddningsarbete, vilket ställer höga krav på latens, upplösning och kryptering.

1.1

Motivering

Sjöräddningens arbete baseras i dagsläget på mycket ovisshet, och beslut får tas med bristande informationskällor. Det kan ta lång tid att ta sig ut med en livbåt till olycksplatsen, vilket resulterar i att räddningsarbetet inte är så effektivt som det kan vara. Om räddningstjänsten skulle få en överblick om olycksplatsen innan de var på plats så skulle arbetet kunna justeras efter situationen. Med hjälp av kameror på drönare har projektgruppen i uppdrag av Airpelago utvecklat ett molnbaserat system för videoströmning. Systemet kan användas vid olycksplatser och strömma information till operatörer.

1.2

Syfte

Syftet med projektet var att utveckla en stabil grund till ett molnbaserad system för videoströmning. Systemet ska förhoppningsvis användas i samband med sjöräddningssällskapet för att strömma video från drönare till operatörer under utryckningar. Projektet inkluderar allt från att videoströmmen skickas från enhetsdator till att den visas i webbläsaren. En väldigt viktig del är säkerheten, då videoströmmen kan innehålla mycket känslig data. Målet med projektet var att skapa framtida värde för kunden Airpelago.

Huvudsyftet med rapporten är att presentera arbetet och utvecklingen med projektet, samt reflektera kring erfarenheter. Rapporten innehåller individuella delar som djupdyker i ämnen som relaterar till projektet. Syftet är också att besvara frågeställningen.

1.3. Frågeställning

1.3

Frågeställning

Denna rapport besvarar följande frågeställningar.

1. Hur kan videoströmningsarkitektur för molnbaserat drönarsystem implementeras för att skapa värde för kunden?

2. Vilka erfarenheter kan dokumenteras från projektet som kan vara intressanta för framtida projekt?

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

4. Hur kan WebRTC tillsammans med Janus möjliggöra peer-to-peer videoströmning till flera klienter?

5. Hur kan videoströmningsarkitektur för molnbaserat drönarsystem uppnå låg latens och uppfylla den säkerhet kunden önskar?

1.4

Avgränsningar

Projektgruppen har en tidsbudget på 2660 timmar vilket motsvarar 380 timmar per gruppmedlem. Denna tid omfattar utveckling av systemet samt skrivandet av kandidatrapport och ett flertal andra tillhörande dokument. Rapporten behandlar endast projektarbetet som utförts och tillhörande tekniker för att besvara frågeställningarna. Eventuella säkerhetsbrister med systemet, utöver den säkerhet teknikerna tillåter och den tid projektgruppen har till förfogande, kommer systemet och projektgruppen inte att behandla. För att se om systemet fungerar kommer det testas av kunden på en av kundens drönare.

1.5

Definitioner

Nedan följer en lista med förklaringar av begrepp.

• Airpelago – Företaget som var projektgruppens kund. • Bittakt – Antal bitar som kan behandlas per tidsenhet. • Branch – Uppdelning av arbetet i två parallella versioner. • C – Kompilerat programmeringsspråk.

• Cache – Snabb lagring som lagrar en viss mängd data som kan kommas åt snabbt. • CSS – Språk för att beskriva visuell presentation av dokument skrivna i HTML. • Discord – Kommunikationsverktyg där flera olika kanaler för text- och röstchatter kan

skapas i en server som finns tillgänglig för inbjudna användare.

• Docker – Mjukvara för att paketera program med tillhörande beroenden i behållare. • Docker Compose – Verktyg för att bygga och köra Docker-behållare.

• DOM – Document Object Model är ett gränssnitt för HTML- och XML-dokument så att program kan ändra på dokumentens innehåll.

• Express – Ramverk skrivet i JavaScript, vilket används för webbapplikationer. • Firebase – Webbapplikationsplattform för att sköta autentisering.

1.5. Definitioner

• GitFlow – Arbetsmodell för Git.

• Gitlab – Webbaserad applikation för Git.

• Google Cloud – Molntjänst för beräkningskraft och lagring. • GStreamer – Bibliotek för att hantera mediaströmmar. • H.264 – Videokompressionsstandard.

• HTML – Markup-språk.

• HTTP – Underliggande protokollet som används på World Wide Web. • HTTPS – Utökning av HTTP med kryptering.

• Janus – Server som implementerar WebRTC. • JavaScript – Interpreterat programmeringsspråk.

• Kanban – Agil processramverk med fokus på visualisering.

• Mount point – En katalog i det nuvarande filsystemet där ett ytterligare filsystem är bunden.

• Nginx – Webbserver och omvänd proxy.

• OAuth 2.0 – Industristandard autentiseringsprotokol. • OneFlow – Git versionsarbetsflöde.

• OpenID Connect – Simplare lager ovanpå OAuth 2.0.

• Peer-to-peer – En direktlänk mellan två hierarkimässigt identiska noder i ett nätverk. Exempelvis en direktlänk mellan två klienter, utan en server som mellanhand.

• Raspicam – Kameramodul som kan kopplas till Raspberry Pi.

• Pipeline – Ett antal seriekopplade element där varje elements utmatning är nästa elements inmatning.

• Proxyserver – En proxyserver är som en mellanhand mellan klienten och servern. All trafik går igenom serverproxyn.

• Raspberry Pi – Liten dator.

• React – JavaScript-bibliotek. Fullständiga namnet är ReactJS

• Request – En mängd data som definierar en mängd metoder som en klient önskar ska genomföras på en server i HTTP-sammanhang.

• Response – En mängd data som ger återkoppling till en tidigare mottagen request i HTTP-sammanhang.

• RTP – Real-time Transport Protocol är ett nätverksprotokoll för för ljud och video över IP-nätverk.

• Scrum – Agilt processramverk.

• Signaling Server – En server som agerar mellanhand för att byta information mellan två klienter.

1.5. Definitioner

• SSL & TLS – Secure Sockets Layer och Transport Layer Security är säkerhetsprotokoll för att skapa autentiserade krypterade länkar mellan noder i ett nätverk.

• Streaming plugin – Plugin till Janus som möjliggör för bland annat realtidsströmmning av video.

• TCP – Nätverksprotokoll för att skapa och upprätthålla en förbindelse mellan två noder i ett nätverk.

• UDP – Nätverksprotokoll för att skicka meddelanden mellan två noder i ett nätverk utan nödvändig respons.

• Visual Studio Code – Textredigeringsverktyg för källkod. • VP8 – Videokompressionsformat.

• WebRTC – Kommunikationsstandard för mediaströmning peer-to-peer.

• Zoom – Kommunikationsverktyg som används vid exempelvis distansarbete och distansundervisning.

2

Bakgrund

2.1

Sjöräddning

Enligt statistik från Sjöfartsverket skedde över 900 sjöräddningsinsatser i Sverige år 2015 [1]. Av de hade Sjöräddningssällskapet varit deltagande i cirka 80%. Livräddningen är dock inte perfekt, då det under samma år omkom eller försvann 29 människor, som sjöräddningsinsatser inte lyckades rädda. Detta går inte ens in på hur ineffektiv och farlig proceduren av sjöräddning kan vara. Det här kandidatprojektet är därför relevant i form av hur effektiv digitaliseringen i samhället kan bli och även dess möjligheter och konsekvenser.

2.2

Övervakning

Övervakning har förändrat samhället. Det har ökat säkerheten med hjälp av säkerhetskameror och bebiskameror och därför tas nu steget för att utforska hur effektivt det kan användas i livräddning. Övervakning kan inkräkta på människors integritet, men då projektet enbart innefattade att övervaka människor som är i omedelbar fara har sjöräddningssällskapet gjort en avvägning och bedömt att det inte borde vara ett problem. Denna information fås i en intervju med vår kontaktperson i sjöräddningssällskapet, Fredrik Falkman, i appendix I.

2.3

Airpelago

Airpelago är ett företag som arbetar nära det Svenska Sjöräddningssällskapet. De utvecklar ett system för att få drönare att filma olyckor till havs. Denna video skall sedan strömmas till personalen från sjöräddningsstyrkan, sådant att de får en översikt över olyckan innan de själva anländer till olycksplatsen. Airpelago är ett ungt startup-bolag, som inte har många utvecklare, vilket lett till att de tagit in projektgruppen Drönare Utan Gränser, även kallat DUG, för hjälp.

2.4. Uppdraget

2.4

Uppdraget

Airpelago har arbetat ett tag med utvecklingen av sitt videoströmningssystem, men de har inte lyckats ta fram ett fullt fungerande system själva. De har valt att arbeta med en arkitektur innefattande att skicka videoströmmar från en Raspberry Pi till en central server, och därifrån vidare till mottagare som skall kunna se videoströmmen i ett webbaserat gränssnitt. De ställer höga krav på att denna videoström skall ha låg latens. Därmed har de undersökt lösningar innefattande WebRTC, vilket är ett videoströmmningsprotokoll som nyttjar User Datagram Protocol (UDP) istället för Transmission Control Protocol (TCP). Denna lösning kan beskrivas som att offra pålitlighet för hastighet. Det stora problemet Airpelago stötte på, som fick dem att kalla in DUG, var att de hade svårigheter att skicka WebRTC-videoströmmar från Raspberry Pi:en till servern.

2.5

Drönare Utan Gränser - DUG

Gruppen som utvecklade denna produkt kallas Drönare Utan Gränser och studerar vid Linköpings universitet. Denna produkt är en slutprodukt av deras kandidatarbete som utfördes under vårterminen 2020. Gruppen bestod av sju medlemmar varav fem studerar till civilingenjör i datateknik medan två studerar till civilingenjör i mjukvaruteknik. Varje medlem förväntades lägga 380 timmar på projektet vilket gav en slutgiltig projekttid på 2660 arbetstimmar, både för dokumentation och produktutvecklande. Samtliga medlemmar i gruppen hade från sin utbildning erfarenhet av att arbeta i grupp med liknande mjukvaruprojekt. En del skillnader förekom dock i att detta projekt var i större skala än något någon i gruppen tidigare stött på, att det var högre krav på diverse dokument, samt att gruppen arbetade gentemot en faktisk kund istället för universitetet.

3

Teori

Här beskrivs tekniker och verktyg som använts under projektet. Kapitlet är till grund för den teori som resten av rapporten bygger på.

3.1

WebRTC

WebRTC är en kommunikationsstandard som skapar en peer-to-peer-uppkoppling mellan två noder i ett nätverk [2]. Det fungerar genom att en av noderna skickar sin information till en signaling server, som sedan skickar den vidare till den andra noden. Den andra noden skickar därefter tillbaka sin information, på samma sätt som den första, och då kan en direktlänk mellan dem skapas. WebRTC är baserat på protokollet User Datagram Protocol (UDP), vilket är ett protokoll som inte gör några handskakningsdialoger [3]. Det innebär att det är opålitligt eftersom det inte finns någon garanti att all data som skickats faktiskt kommer fram, men med fördelen att det är snabbare. WebRTC gör det därför möjligt att implementera en videoström med låg latens. Det finns implementerat i de flesta stora webbläsare.

3.2

GStreamer

GStreamer är ett bibliotek skrivet i programmeringsspråket C som används för att hantera mediaströmmar [4]. Det är baserat kring en pipeline som en mediaström kan passera. Den består av ett antal sammankopplade element, där varje element har en inmatningsdel och en utmatningsdel. Däremellan kan de också modifiera datan på något sätt. Ett element kan användas till saker som till exempel kryptering, komprimering, ta in data från en webbkamera eller skicka data till en IP-adress. GStreamer har färdiga element för att hantera många standarder och protokoll som SRTP, H.264-kodning och UDP.

3.3

Janus

Janus är en server som implementerar WebRTC [5]. Janus i sig själv tillhandahåller inte någon funktionalitet utan implementerar endast WebRTC för mediekommunikation till andra WebRTC-implementationer, vilket främst är webbläsare. Janus används alltså som

3.4. Janus Streaming Plugin

en mellanhand för att utbyta JSON-meddelanden och vidarebefordra RTP-media mellan webbläsare och applikationer. Janus är i sig en lättviktig implementation som bygger på att funktionalitet kan utökas med hjälp av insticksprogram.

3.4

Janus Streaming Plugin

Janus Streaming Plugin används för att utöka funktionaliteten av Janus [6]. Pluginet kan användas för tre typer av strömning, strömning på begäran av förinspelad media, realtidsströmning av förinspelad media och realtidsströmning av media som genereras kontinuerligt under strömningen. Vad gäller realtidsströmning av kontinuerligt genererad media så kommer den att mottas med protokollet RTP och distribueras till användare, det vill säga det räcker med en ingående mediaström för att kunna förse flera användare med den. Pluginet kan också användas för att spara den ingående strömmen på servern.

3.5

Nginx

Nginx är en open source-mjukvara som används bland annat som webbserver, omvänd proxy, cache och mediaströmning [7]. Det är en server som designats för att klara av hög prestanda med stabilitet för många användare. Ursprungligen skapades mjukvaran för att klara av ”The C10K”, vilket sammanfattningsvis gick ut på att kunna ha 10 000 anslutningar samtidigt. Nginx används som server på mer än 50% av de sidor med högst trafik på webben [8]. Servern används också ofta mellan klienter och en annan webb-server för att hantera säkerheten med SSL/TSL samt caching.

3.6

Docker

Docker är en teknik för att skapa behållare av applikationer [9]. Docker utvecklades för att förenkla utvecklingsprocessen där program inte uppförde sig lika på olika maskiner. Docker bygger därför på att skapa behållare, som kan liknas med virtuella maskiner som ska uppföra sig lika oberoende av maskinen de körs på. Allt som krävs för att köra applikationen ska specificeras i en Docker-fil, vilket medför att steget mellan utveckling och produktion blir betydligt mindre och smidigare. Skillnaden mellan docker och virtuella maskiner är att Docker fortfarande körs på värdmaskinens operativsystem vilket medför att det är mer flexibelt, lättviktigt, portabelt och skalbart än virtuella maskiner som istället kör ett ”gästoperativsystem”, vilket generellt sett innebär mycket mer overhead.

3.7

Docker Compose

Docker Compose är ett verktyg som används för att definera och köra flera Docker-behållare, som här kallas för tjänster [10]. För att specificera beteendet av tjänsterna så används en YAML fil som beskriver hur de olika tjänsterna ska länkas ihop, byggas och köras. Filen som skapats kan startas med ett kommando, vilket i sin tur förenklar utveckling-, testning- och produktionsarbetet.

3.8

Raspberry Pi

Raspberry Pi är en billig dator som är ungefär lika stor som ett kreditkort [11]. Datorn är utvecklad av en icke vinstdrivande organisation som vill göra programmerbara datorer tillgängliga för så många som möjligt. Ofta används operativsystemet Raspbian, vilket är baserat på linuxdistributionen Debian och specifikt utvecklat för Raspberry Pi:s. Processorn som används i datorn drar endast omkring 1W. Det i samband med att operativsystemet

3.9. Raspberry Pi Kameramodul

klarar av att köra många moderna tekniker har lett till att datorn används för bland annat hemautomation och som webb-server.

3.9

Raspberry Pi Kameramodul

Kameramodulen är en kamera som utvecklats för att kopplas till en Raspberry Pi [12]. Kameran är designad för att kunna användas av nybörjare och ska därför vara lätt att montera. Även fast den ska vara lätt att använda så har den mycket funktionalitet att erbjuda till de mer avancerade användarna. Kameran kan filma i 30 bilder per sekund i 1920x1080 pixlar och 60 bilder per sekund i 1080x720 pixlar.

3.10

React

React är ett open source JavaScript-bibliotek som skapats för enklare utveckling av interaktiva användargränssnitt för bland annat webbsidor [13]. Biblioteket bygger på att utveckla komponenter som kan hantera sina interna tillstånd och funktioner. React skapar en virtuell Document Object Model (DOM) som utnyttjas för att endast uppdatera delar av gränssnittet som ändrats.

3.10.1

JavaScript

JavaScript är ett lättviktigt interpreterat programmeringsspråk som traditionellt har sin historia i webbläsare, då det främst använts för att skapa dynamiska webbsidor [14]. I samband med att Node.js, en miljö som kan köra JavaScript på olika platformar, släppts har det kommit fler användningsområden, exempelvis i utveckling av servrar.

3.10.2

HTML

Hypertext Markup Language (HTML) är den mest essentiella byggstenen av webben [15]. Språket beskriver innehåll och strukturen på hemsidor. HTML använder sig av olika taggar för att definera hur bland annat text, tabeller och media ska visas.

3.10.3

CSS

Cascading Style Sheets (CSS) är ett format som kan användas för att beskriva hur element i ett HTML-dokument ska renderas på skärmen [16]. CSS kan bland annat specificera färger, storlek och placering av element. Formatet är standardiserat i alla moderna webbläsare.

3.11

Firebase Authentisering

För att kunna säkerställa säkerheten på en webbsida är användare en essentiell del. Firebase autentisering erbjuder hantering av bland annat användare för diverse applikationer [17]. Det finns stöd för inloggning med populära tjänster som Google, Facebook och Twitter. Tjänsten implementerar industristandarder som OAuth 2.0 och OpenID Connect.

3.12

H.264

H.264 är en videokompressionsstandard som baseras på rörelsekompensation, vilket är en algoritm som förutser kommande bildruta baserat på rörelser i de tidigare [18]. Det är den vanligaste standarden för videokomprimering.

3.13. SRTP

3.13

SRTP

Secure Real-time Transport Protocol (SRTP) är en förlängning av protokollet Real-time Transport Protocol (RTP) som tillför kryptering, autentisering och dataintegritet [19]. RTP är oftast baserat på UDP 3.1 och har hjälpmedel för att upptäcka förlorade paket och data som levererats i fel ordning. RTP är den vanligaste standarden för att leverera ljud- och videoströmmar.

3.14

HTTPS

Hyptertext Transfer Protocol Secure (HTTPS) är en förlängning av protokollet Hyptertext Transfer Protocol (HTTP) som tillför kryptering, autentisering och dataintegritet [20]. HTTP fungerar genom att en nod i ett nätverk skickar en förfrågan till en annan nod. Om inget gått fel skicar sedan den andra noden ett svar innehållande den önskade datan. Det baseras på protokollet Transmission Control Protocol (TCP) vilket använder en trestegshandskakning och felkorrigering. Detta gör protokollet pålitligt men långsammare än exempelvis UDP-baserade protokoll.

3.14.1

TLS

Transport Layer Security (TLS) är ett kryptografiskt protokoll, och är det som HTTPS använder för att göra kommunikationen säker [21]. Det använder symmetrisk kryptering, vilket innebär att datan som skickas krypteras och avkrypteras med en och samma nyckel. TLS använder också certifikat för att hantera identifiering av de klienter eller servrar som ingår i kommunikationen. Om certifikatet inte är skapat av en certifikatutfärdare kommer klienten bli uppmärksammad om detta, och kan då välja om den vill lita på den som skapat det eller inte.

3.15

Google Cloud

Google Cloud är en mängd molntjänster som används främst för beräkningskraft och lagring. Det består av en mängd fysiska enheter som datorer och hårddiskar, och en mängd virtuella resurser som Virtual Machines där användare kan placera sin mjukvara för exekvering eller lagring [22].

3.16

Git

Git är ett system för versionshantering [23]. Det håller koll på förändringar av filer, vilket innefattar vad som har förändrats, när, och av vem. Git kan skapa kopior av projektet med hjälp av grenar för att användare ska kunna utveckla olika funktioner parallellt med varandra utan komplikationer. Det är designat för att programmerare lättare ska kunna arbeta med samma filer samtidigt. Mer information om Git och arbetsflöden går att läsa om i delrapport E.

3.17

Gitlab

Gitlab är ett webbaserat verktyg som möjliggör lagring av Git-projekt [24]. Det möjliggör åtkomst av dessa Git-projekt på en central server genom ett grafiskt gränssnitt.

3.18. Visual Studio Code

3.18

Visual Studio Code

Visual Studio Code är ett redigeringsverktyg för källkod [25]. Det innehåller stöd för bland annat felsökning och syntaxmarkering.

4

Metod

Under arbetets gång använde sig projektmedlemmarna av ett antal metoder för att underlätta arbetet och möjliggöra besvarandet av projektets frågeställningar. Gruppen skrev bland annat ett flertal dokument och hade kontinuerligt schemalagda möten.

4.1

Arbetsmetod

Under projektet användes en modifierad version av Scrum tillsammans med ett Kanban-bräde. Det främsta gruppen tog från scrum var att använda sig av sprinter och sprintmöten. Några sprinter varade i en vecka, men de flesta sattes till att vara två veckor. Det hölls inte heller några demonstrationer av produkten under sprint-mötena, då produkten sällan nått ett stadie då det fanns något som kunde visas upp. Det hölls inte heller dagliga scrum-möten. Istället har gruppen haft möten två gånger i veckan för att diskutera arbetet. Dessa möten har behandlat samma frågor som dagliga scrum-möten, men har även använts för att diskutera vissa problem och har därmed även blivit längre. Under projektet agerade gruppens projektledare som scrum-master. Det fanns däremot ingen bestämd produktägare som jobbade på det sätt som beskrivs i scrum-modellen. Istället hölls konversationer med kunden av och till under projektets gång för att stämma av att arbetet gick som tänkt. Detta gjordes oftast genom gruppens analysansvarig.

Kanban användes genom att vid planeringen inför varje sprint dela upp alla arbetsuppgifter i kort som sattes på ett kanbanbräde i Gitlab. Det kanbanbräde gruppen använde sig av var inte särskilt komplicerat. Det fanns en kolumn för uppgifter som ska jobbas med, en för uppgifter som jobbas med, en för granskningar och en för uppgifter som är klara. I gruppens kanbanbräde kunde varje gruppmedlem välja att skriva upp sig på en uppgift för att indikera att personen arbetade med denna. Ofta valde alla gruppmedlemmar uppgifter redan vid mötet i början av sprinten för att säkerställa att alla blev tagna. Projektgruppen valde att inte sätta någon gräns för hur många uppgifter som fick ligga arbetskolumnen samtidigt.

4.2

Roller

Gruppen delades i början av projektet in i olika roller med olika ansvarsområden. Denna indelning gjordes genom att samtliga gruppmedlemmar skrev upp sig på den eller de roller

4.2. Roller

de kunde tänkas ta på sig, och rollerna tilldelades sedan så alla fick en roll de kände sig bekväma i. På grund av gruppens storlek fick en gruppmedlem ta på sig två roller och blev dokument- och konfigurationsansvarig. Nedan beskrivs de olika rollerna.

4.2.1

Analysansvarig

Den som är analysansvarig ansvarar för kommunikation med kunden och samlar information från intressenter för att förstå problemet som ska lösas. I det ingår att ta reda på vilka krav som ska finnas och prioritering av dessa.

4.2.2

Arkitekt

Arkitekten ansvarar för den övergripande arkitekturen för systemet och de val som påverkar den. Det innebär bland annat att dokumentera systemets arkitektoniskt viktiga aspekter och motivera eventuella beslut som är relevanta för arkitekturen.

4.2.3

Dokumentansvarig

Dokumentansvarig ansvarar för att samtliga dokument levereras i tid och håller samma standard. Detta innefattar ansvar över att det finns dokumentmallar till alla projektdokument och att samtliga medlemmar i gruppen använder dessa korrekt. Denna roll innefattar även ansvaret över att samtliga dokument levereras i tid, samt ansvar över projektets eventuella logotyper.

4.2.4

Konfigurationsansvarig

Konfigurationsansvarig har ansvar över projektets versionshantering. Detta innefattar att bestämma ett versionshanteringsverktyg att använda i projektet, konfigurera detta, samt se till att samtliga gruppmedlemmar använder sig av verktyget på ett korrekt sätt. Om någon utbildning skulle krävas i versionshanteringsverktyget är det konfigurationsansvariges ansvar att sådan utbildning finns tillgänglig. Konfigurationsansvarig har även ansvar för att bestämma vad som ska versionshanteras samt vilka versioner som ingår i en färdig utgåva.

4.2.5

Kvalitetssamordnare

Kvalitetssamordnaren ansvarar för kvaliteten på produkten som gruppen genererar såväl som kvaliteten på det arbetssätt som gruppen använder sig av. Det innebär att skapa en kvalitetsplan med bestämmelser kring hur gruppen ska arbeta sett ur ett kvalitetsperspektiv och övervaka hur denna plan efterföljs under arbetets gång.

4.2.6

Teamledare

Teamledaren ansvarar för att leda gruppen under projektets gång. Det innebär att se till att målen som finns uppfylls, att processer följs och att det finns en bra arbetsmiljö för projektmedlemmarna. Vidare agerar teamledaren coach, har det sista ordet om det skulle behövas, representerar teamet utåt sett och ansvarar för att en projektplan skrivs.

4.2.7

Testledare

Testledaren ansvarar för att sätta upp aktiviteter för testning av systemet. Dessa aktiviteter innefattar att identifiera, definiera och implementera tester för de olika komponenterna som bygger upp systemet.

4.3. Versionshantering

4.2.8

Utvecklingsledare

Utvecklingsledaren ansvarar för att generera en detaljerad designbeskrivning, leder och delegerar utvecklingsarbetet, fattar beslut om utvecklingsmiljö och organiserar utvecklarnas tester.

4.3

Versionshantering

Projektgruppen valde att använda sig av Git för att versionshantera både dokument och kod. Gruppen valde även att dela upp dokumenten och koden i två olika Git-projekt, och använde sig av taggar för att koppla korrekt dokumentation till olika utgåvor av kod. Dokumenten använde sig av ett förenklad version av arbetsflödet One-flow medan det för koden användes en förenklad version av Git-flow. För vidare detaljar, se avsnitt E.4.2.

4.4

Granskningar

Under utvecklingens gång genomfördes granskningar systematiskt i takt med att nytt material arbetades fram.

4.4.1

Dokumentgranskning

Alla dokument som skrevs gick igenom en process där de, efter att författaren/författarna kände sig klara med dem, lästes igenom och kommenterades av en eller två personer. Dessa personer var, om möjligt, inte inblandade i processen av insamling av information till dokumentet eller skrivandet av det. Därefter diskuterade granskaren/granskarna och författaren/författarna kommentarerna tillsammans, och författaren/författarna åtgärdade kommentarerna på det sätt som de tyckte var mest lämpligt. Alla dokument och delar av större dokument skrevs i enskilda grenar som sedan slogs samman med huvudgrenen när de blivit granskade.

4.4.2

Kodgranskning

Innan någon kod som skrevs lades upp på huvudgrenen i projektgruppens Git-katalog granskades den av en annan projektmedlem som, om möjligt, inte varit involverad i skrivandet av just den koden. Om något med koden var oklart eller inte såg rätt ut fick granskaren och den/de som skrivit koden lösa de problemen tillsammans innan koden fick läggas upp.

4.4.3

Hårdvarugranskning

Då gruppen fick tillgång till hårdvaran genomfördes en snabb och översiktlig kontroll av den för att säkerställa att inget saknades eller var trasigt.

4.5

Metod för att fånga erfarenheter

För att samla information om hur arbetet gått och ta lärdom av erfarenheter använde gruppen sig av ett antal metoder. Varje vecka höll gruppen ett möte tillsammans med handledaren där handledaren kunde kontrollera hur arbetet gick för att se till att inga större problem uppstått. Utöver mötena med handledaren höll även gruppen interna möten varje vecka där det fortsatta arbetet samt eventuella problem diskuterades mer ingående. Vid behov kallade gruppen även in extra möten med berörda medlemmar. Gruppen höll även SCRUM-möten i slutet av varje sprint för att stämma av hur arbetet gått samt sätta upp en plan för kommande sprint.

4.5. Metod för att fånga erfarenheter

Vid alla dessa möten höll gruppen mötesprotokoll så alla medlemmar kunde påminna sig om vad som diskuterats och bestämts under mötet.

Varje vecka sammanfattade varje gruppmedlem sitt arbete under veckan samt planen för kommande vecka i en veckorapport. Gruppledaren sammanställde sedan detta till en veckorapport för hela gruppens arbete, som även skickades in till gruppens handledare. I denna rapport samlades även alla problem som uppstått under veckan, så dessa synliggjordes för alla gruppmedlemmar.

Gruppen skrev även ett antal olika dokument i samband med projektet vilket hjälpte till med att fånga erfarenheter från arbetet. Dokumenten som skrevs var följande: projektplan, kvalitetsplan, kravspecifikation, testplan, testrapport och systemanatomi. Vidare deltog alla medlemmar i gruppen på fem stycken seminarium där de fick lära sig om ämnen som hållbar utveckling, hur man säljer en idé och genomför en presentation. Två av gruppens medlemmar tog även del av ytterligare fyra stycken seminarium där fokus låg på att förbättra kvaliteten hos projektet. Det gjordes i samarbete med två studenter som läste en kurs i programvarukvalitet.

5

Resultat

Projektet resulterade i ett system som uppfyllde kravspecifikationen och gjorde kunden nöjd. Detta uppnåddes genom ett Scrum-baserat arbetssätt med en Kanban-inspirerad arbetstavla.

5.1

Systembeskrivning

Systemet består av tre delar: en Raspberry Pi, en server, och ett gränssnitt vilket syns i figur 5.1. Raspberry Pi:en filmar och strömmar video till servern, som i sin tur vidarebefordrar strömmen till användargränssnittet som visar upp videon för användaren.

5.1. Systembeskrivning

5.1.1

Raspberry Pi

Det slutgiltiga programmet som körs på Raspberry Pi:en körs i en Docker-behållare med Docker-bilden gcc från Docker Hub som basbild. GStreamer används i detta program för att möjliggöra videoströmning från en raspicam till en Janus-server. För att åstadkomma detta skapades en pipeline, som syns i figur 5.2.

Figur 5.2: Kommando för att starta en pipeline på Raspberry Pi.

Som syns i figur 5.3 hämtar pipeline:en video från raspicam:en och sätter parametrar som bittakt, profil, bredd, höjd och videokodek. Sedan strömmas videon till en Janus-server som ligger uppe på Google Cloud. För att kunna strömma video från mer än en Raspberry Pi samtidigt skapas en mount point för varje enhet som kör programmet. Programmet har därför en del som är dedikerad åt att hantera kommunikationen mellan Janus-servern och Raspberry Pi:er. Denna del är, precis som all kod som körs på Raspberry Pi:en, skriven i programmeringsspråket C. För att kommunicera med Janus-servern används JSON och cURL, där JSON-data skickas till Janus rest API som hjälper till med att skapa ett nytt mount point på porten 10001 om den är ledig, och om den inte är det väljs port 10002 och så vidare. Funktionaliteten för att ta bort mount points finns i form av en funktion men används inte i produkten. Att bygga vidare och implementera programmet så att mount points tas bort om de inte används skulle vara möjligt.

Figur 5.3: Översikt av kommunikationen mellan Raspberry Pi och server.

Videoströmningen sker via protokollet SRTP med UDP vilket är en krypterad variant av protokollet RTP. Krypteringen som används i pipeline:en är Advanced Encryption Standard (AES) med 128-bitars kryptering och för autentiseringen används Hash-based Message Authentication Code (HMAC) med hashfunktion SHA1.

5.1. Systembeskrivning

5.1.2

Server

De servrar som används i systemet är en Janus-server, en Express-server för användargränssnittet och en Nginx-server. Google Cloud agerar värd för alla dessa servrar. Nginx-servern körs framför Janus-servern samt användargränssnittet och har till uppgift att omdirigera förfrågningar så att de skickas vidare till rätt del av systemet, antingen Janus-servern eller användargränssnittet. All kommunikation till och från Google-Janus-servern går genom Nginx. Nginx-servern hanterar också SSL-certifikat så att HTTPS fungerar.

Janus-servern är den mest centrala delen av systemet. Den tar emot videoströmmar som skickas med SRTP från flera Raspberry Pi:er. Klienter kan skicka förfrågningar till Janus-servern med hjälp av JSON-meddelanden för att ta emot dessa videoströmmar. I systemet som utvecklades används ett webbaserat användargränssnitt som klient.

Allt på servern ligger i Docker-behållare där användargränssnittet, Janus-servern och Nginx-servern har sina egna Docker-bild. Denna Docker-behållare är placerad på Google Cloud och körs därifrån.

Under utvecklingen användes en utvecklingsserver för användargränssnittet, vilket var smidigt då den till exempel automatiskt uppdaterar hemsidan när koden för användargränssnittet uppdateras, så att servern slipper startas om. Mot slutet av projektet användes istället en Express-server som är mer optimerad, vilket är lämpligt när systemet används i produktion.

5.1.3

Gränssnitt

Användargränssnittet är webbaserat och anpassat för att köras på en modern version av Google Chrome, enligt begäran från kund. Det är skapat i React, kräver autentisering genom Firebase och tar emot videoströmmar med hjälp av Janus. Gränssnittet är inkapslat i en Docker-behållare, för att det smidigt skall kunna köras på olika datorer/servrar.

Att använda React för att skapa gränssnittet var i sig inte problematiskt, och Firebase var ett smidigt verktyg för att hantera autentisering. Att sammanslå de två krävde dock en del arbete, även om det inte orsakade några stora problem. Janus var däremot en annan fråga, då det visade sig svårt att få in mottagardelen av Janus Streaming plugin, ett tillägg till Janus vilket användes för att skicka och motta videoströmmar. Detta problem blev ett hinder för gruppen, men kunde till slut lösas.

Användargränssnittet som syns i figur 5.4 har en enkel, nästan minimalistisk design, sådant att kunden lätt ska kunna redigera sidan och/eller integrera den i sitt tidigare system. Detta reflekteras även i koden bakom gränssnittet, som är väldigt modulär, välkommenterad, och skriven för att vara lättförståelig.

5.1. Systembeskrivning

Firebase gjorde det smidigt att få in mycket funktionalitet som annars hade varit svår att framställa i gränssnittet. Med hjälp av Firebase kan en användare:

• Skapa ett konto • Logga in

• Byta lösenord ifall den är inloggad

• Begära att byta lösenord via E-mail ifall den glömt lösenordet

• Bli omdirigerad ifall den försöker komma åt en låst sida utan autentisering

Dessa funktioner syns i figur 5.4 där pilarna i figuren visar hur en användare kan navigera mellan dem olika funktionerna.

Hemsidans huvudsida som syns i figur 5.5 är tillgänglig då användaren är inloggad. När denna sida laddas skickas en förfrågan till Janus-servern om aktiva videoströmmar. Dessa listas upp på sidan i form av videor med tillhörande “stop”- och “watch”-knappar. När användaren trycker på en “watch”-knapp skickas en förfrågan till Janus-servern om att få ta emot vald videoström och ett utbyte av Session Description Protocols utförs för att möjliggöra videoströmningen med WebRTC. Videoströmningen kan när som helst avbrytas med “stop”-knappen och på samma sätt skickas en förfrågan till Janus-servern, nu istället om att stoppa videoströmningen så att WebRTC anslutningen kan upphöra.

Figur 5.5: Användargränssnittets huvudsida. Visar upp en videoström.

5.1.4

Utvärdering av produkten

I slutet av projektet uppfyllde produkten kravspecifikationens alla prio 1-krav. Kravspecifikationen innehöll även ett flertal prio 2-krav, varav ett har uppfyllts. Kodmässigt har projektets kvalitetsplan följts, både vad gäller kodningsstandard och kommenteringsstandard.

Resultatet av ett antal tester av produkten visade att latensen mellan Raspberry Pi och videon som visades i gränssnittet låg mellan 0,3 och 0,4 sekunder beroende på användare. Kravet på latens från kunden var att den skulle vara mindre än en sekund. Testerna visade även att antalet användare som kunde kolla på en videoström samtidigt var minst 22 stycken. Kravet från kunden på antalet användare som skulle kunna kolla på en ström var tre stycken. Vidare visade testerna att det gick att kolla på minst två stycken videoströmmar i samma gränssnitt vilket även var det krav som kunden hade på produkten.

5.2. Processbeskrivning

Systemet demonstrerades i sin helhet för kunden nära projektets slut, och kunden blev mycket nöjd. Kunden testade systemet med en Raspberry Pi fäst på en drönare, med lyckat resultat.

5.1.5

Värde för kunden

Produkten kan ge en överblick över sjöfartsolyckor, sådant att sjöräddningspersonal får en överblick över olyckan innan de anländer till platsen. Med denna överblick kan de förbereda sig bättre. Detta kan leda till ett smidigare sjöräddningsarbet, vilket skapar värde för kundens kund, och därmed även för kunden.

Produkten är skapad för att vara lätt för kunden att modifiera och att integrera i existerande system, då all kod är modulär och välkommenterad. Dessutom är produkten skapad enligt kundens begäran vad gäller språk, ramverk, etc. vilket innebär att kunden är bekant med kodens utvecklingsmiljö.

5.2

Processbeskrivning

Gruppen använde sig av en arbetsmetod som tog inspiration av Scrum och Kanban (se avsnitt 4.1). Gruppen arbetade i sprinter som var två veckor långa.

5.2.1

Möten och sprinter

Gruppen hade regelbundna internmöten en gång i veckan och vartannat utav dessa blev ett sprintmöte. Gruppen hade även regelbundna handledarmöten en gång i veckan, som mot slutet av projektet smälte samman med gruppens internmöten. Utöver detta samlades gruppen för extra möten när det behövdes.

Under gruppens internmöten behandlades vad som hade hänt den föregående veckan, och vad gruppens plan för nästkommande vecka var. Dessutom diskuterades eventuella nyheter som dykt upp, samt problem som berörde gruppen. Projektgruppen delade ofta in sig i mindre grupper för att arbeta med olika uppgifter, i enlighet med Scrum, och under gruppens internmöten kunde sådana smågrupper skapas eller blandas om.

Gruppens sprintmöten var mycket lika gruppens internmöten, men under sprintmötena uppdaterades även gruppens kanban-bräde med nya uppgifter, som fördelades mellan gruppens medlemmar.

Under gruppens handledarmöten fick samtliga gruppmedlemmar berätta för gruppens handledare om vad de gjort den föregående veckan, samt vad de planerade att göra den nästkommande veckan. Handledaren bekräftade att gruppens planer var rimliga, och gav ut råd där den kunde. Handledaren förklarade sedan kommande planerade händelser inom projektkursen, och gruppmedlemmarna fick chans att ställa frågor om projektet.

5.2.2

Kanban-bräde

Ifall något kort på brädet inte blev avklarat i tid fick det ligga kvar till nästkommande sprint, och uppmärksammades på sprintmötet. Mot slutet av projektet valde gruppen också att tilldela olika aktiviteter till personer eller mindre grupper så fort de skrevs upp i brädet, istället för att personer ‘’plockade” ett kort att arbeta med när ett annat var avklarat, såsom gruppen gjorde i början.

Vad som skulle klassas som ett eget kort i brädet var i början av projektet väldigt oklart. Detsamma gällde även när kort skulle räknas som klara, samt vad som var skillnaden mellan taggarna ‘’open” och ‘’doing”. Efter några sprinter hade gruppen dock kommit fram till vad som fungerade och valde då även att helt ta bort taggen ‘’open” som skapades automatiskt i Git men inte passade in i gruppens arbetssätt. Då gruppen blev mer vana vid vilken omfattning som var lämpligt för ett kort blev det tydligare när kort var avklarade och inte,

5.2. Processbeskrivning

och färre kort behövde i efterhand delas upp i mindre aktiviteter då de var så stora att bara delar av dem blivit avklarade.

Planen med brädet var att ständigt flytta aktiviteter från ett steg till ett annat så fort de blivit redo; detta för att sprida medvetenhet om projektets status. Ett av dessa steg var att flytta de från ‘’doing” till ‘’review”. Detta skedde dock sällan då aktiviteterna blev klara, utan vid nästkommande sprintmöte. Korten låg därför ofta kvar i ‘’todo” tills de lades i ‘’closed”, och helt hoppade över ‘’doing” och ‘’review”. Det kunde därför vara svårt att veta hur långt övriga mindre grupper inom projektet hade kommit på sina områden innan veckans internmöte. Ifall en grupp behövde veta hur läget såg ut hos en annan grupp var det dock aldrig några problem att höra av sig till någon i den gruppen och fråga hur de låg till. Detta eftersom att gruppen som tumregel hade att alltid läsa och svara på nya meddelanden minst en gång om dagen.

5.2.3

Kvalitetscoachning

Under större delen av projektets gång deltog två av projektmedlemmarna i seminarier med studenter som läste en kurs i programvarukvalitet där syftet var att få hjälp med att säkerställa en hög kvalitet på produkten. Totalt var det fyra stycken seminarier där representanterna från projektgruppen fick hjälp med att skriva en kvalitetsplan och att jobba med Scrum. Utöver den hjälp som erhölls på seminarierna fick projektgruppen material från studenterna från programvarukvalitetskursen via mejl som behandlade de ämnena.

5.2.4

Arbetssätt över tid

Arbetssättet ändrades en del över tiden som projektet varade. Eftersom mycket av det gruppen arbetade med var nytt för dess medlemmar så gjorde erfarenheten de samlade på sig genom projektets gång stor skillnad. Gruppens internmöten blev mer strukturerade mot slutet av projektet; likaså dess sprinter, främst i och med att uppgifterna på gruppens kanban-bräde också blev mindre och mer konkreta.

Projektgruppens medlemmar lade även mer tid på projektet under andra halvan av projekttiden. Efter halva tiden hade de flesta medlemmar lagt drygt 100 timmar utav de 380 som krävdes, och de blev därför tvungna att lägga över 30 timmar på projektet varje vecka till projektets slut.

Rollernas uppgifter skiftade mycket under projektets gång då vissa ansvarsområden för rollerna var obalanserade över projekttiden. Detta ledde till att många av rollerna mer eller mindre glömdes bort.

5.2.5

Distansläge

Den största förändringen i gruppens arbetssätt skedde på grund av att Linköping Universitet gick in i distansläge ungefär halvvägs genom projektets gång, med orsak av Covid-19. Innan detta hade större delen av arbetet skett inom universitetets byggnader, men efter att det inträffade var gruppmedlemmarna tvungna att istället göra nästan allt arbete hemifrån. All kommunikation i gruppen sköttes digitalt. Alla gruppens möten skedde genom Zoom, och det mesta av utvecklingsarbetet som involverade flera medlemmar skedde över röstchatt i Discord.

5.2.6

Systemanatomi

Tidigt i projektet skapades en systemanatomi som var tänkt ge en överblick över systemets olika delar och hur de beror på varandra. Systemanatomin användes inte så mycket under projektets gång utan hjälpte mest till i början att sammanställa gruppens idé om vilka funktioner systemet skulle ha. Någon uppdaterad version av systemanatomin togs inte fram. Systemanatomin stämmer någorlunda överens med det utvecklade systemet med några

5.3. Gemensamma erfarenheter

beroenden och funktioner som skiljer sig åt. Systemanatomin som gruppen tog fram kan ses i figur I i appendix IV. I figur II på samma ställe syns en illustration av det färdiga systemet som vid jämförelse med systemanatomin visar på hur nära systemanatomin var den slutgiltiga produkten.

5.3

Gemensamma erfarenheter

Gruppen hade ingen erfarenhet av att jobba med projekt i den här skalan eller att arbeta med en kund. Att hålla möten, organisera arbete, sprida information och dylikt var saker som gruppen fick lära sig under arbetets gång. Gruppen utvecklades och blev märkbart bättre på dessa saker genom projektets gång. Nedan följer en lista av olika reflektioner om de erfarenheter som gruppen utvecklat utifrån sina upplevelser inom projektet.

• Att kommunicera med kunden gick smidigare än vad gruppen förväntade sig, då kundens representant själv hade gått samma projektkurs tidigare och visste väl vad projektgruppen behövde från sin kund. Därmed fungerade kundkommunikationen bra trots att gruppen saknade erfarenhet, men det är möjligt att gruppen hade lärt sig mer ifall de hade stött på fler kundrelaterade utmaningar. Exempelvis fick inte gruppen mycket erfarenhet av att förhandla om krav, eftersom kunden ställde mycket rimliga krav från början.

• Medlemmarna hade blandade erfarenheter av de tekniker som användes i projektet som till exempel Docker och Janus men för de flesta var det mesta nytt. Det krävdes mycket tid för att sätta sig in i dessa tekniker och det var något som medlemmarna i projektgruppen underskattade till en början. Gruppen lärde sig många detaljkunskaper om de tekniker de använde.

• Gruppen hade inte så mycket erfarenhet av att skriva de dokument som kursen krävde. Gruppen lärde sig mycket om att skriva och använda projektplan, kravspecifikation, kvalitetsplan, arkitekturdokument, testplan, och systemanatomi. Gruppen upplevde att det var mycket nyttigt att framställa samtliga dokument, men de fann att de knappt använde dokumenten senare i projektet.

• Gruppen hade begränsad erfarenhet av att arbeta med målet att lägga en mängd tid snarare än målet att framställa en produkt. Det ledde till ett nytt sätt att tänka för många i gruppen som de var tvungna att anpassa sig efter.

• Distansläge var något som var nytt för alla i projektet och det var något som gruppen snabbt anpassade sig efter. Gruppen lärde sig att kommunicera via andra kanaler än fysiska och det fungerade bra sett till helheten. Det innebar dock en omställning för gruppmedlemmarna och flera upplevde att det var lite svårare att arbeta effektivt och enligt en bra rutin i distansläget.

• Varje medlem i projektgruppen hade en eller flera roller som de tilldelades i början av projektet och det var en ny erfarenhet för många i gruppen. Medlemmarna lärde sig inte bara nya erfarenheter av sin roll utan även hur det var att arbeta i en grupp med kamrater som hade roller. Att ha någon att vända sig till när de hade frågor som berörde ett särskilt område var något som medlemmarna i gruppen upplevde som positivt. • Projektet innefattade väldigt mycket självlärande, vilket gruppmedlemmarna inte stött

på mycket av i sina utbildningar tidigare. Utan föreläsningar eller labbar att luta sig mot var medlemmarna tvungna att själva hitta all information och kunskaper de behövde. Detta var en utmaning för gruppen, inte enbart för att dess medlemmar saknade erfarenhet av att självutbilda sig, utan även för att detta ställde ytterligare organisationskrav på gruppen, då olika medlemmar lärde sig olika saker, vilket medförde att gruppen blev tvungen att hålla koll på vilken medlem som kunde vad.

5.4. Översikt över individuella bidrag

• I projektkursen ingick att opponera på andra gruppers arbeten, samt att revidera eget arbete efter opponering från andra, vilket var nytt för många i gruppen. Detta är en värdefull erfarenhet som gruppen utvecklade.

• Att arbeta med GitFlow och OneFlow i en större grupp var en relativt ny erfarenhet för gruppens alla medlemmar och detsamma gällde för att arbeta med Scrum och ett Kanban-bräde. Det var något som krävde en inlärningsperiod, och dessutom var det inte alltid som metoderna följdes till fullo. Det som gruppen upplevde var positivt med sättet att arbeta var att det gav en struktur för arbetet.

Till sina framtida projekt tänker gruppens medlemmar främst ta med sig sina erfarenheter om att arbeta med väldefinierade roller inom gruppen, såväl som sina erfarenheter om att skriva, underhålla, och använda de dokument som kan stötta ett projekt. Utöver det kommer gruppmedlemmarna i framtiden att vara bättre beredda på att behöva helt ändra sina arbetsrutiner ifall omständigheter påtvingar det, då de i projektet fick erfarenhet av det i samband med COVID-19.

5.4

Översikt över individuella bidrag

A. WebRTC, RTMP och HLS en jämförelse av Mattias Ljung

I detta avsnitt jämförs kommunikationsstandarderna WebRTC, RTMP och HLS med avseende på latens och stabilitet. Detta för att avgöra huruvida WebRTC bör användas i större projekt som idag använder en äldre standard.

B. En jämförelse av videokodek H264 och VP8 av Robert Almgren

Detta avsnitt jämför prestanda hos videokodek H.264 och VP8 samt undersöker hur prestanda mellan videokodekar kan mätas och vilka faktorer som påverkar resultatet.

C. Agil utvecklingsmetodik för mindre mjukvaruprojekt av Hugo Cedervall

Avsnittet undersöker hur agila utvecklingsmetoder som Scrum och Kanban lämpar sig för mindre mjukvaruprojekt. Undersökningen tar i hänsyn hur tidigare erfarenhet av mjukvaruutveckling kan påverka resultatet av arbetsmetoden.

D. Vikten av en utförlig kravspecifikation i ett mjukvaruprojekt av Daniel Norström

Detta avsnitt väger fördelar mot nackdelar av att framställa och arbeta med en kravspecifikation i ett mjukvaruprojekt i samma skala som ett kandidatprojekt.

E. Jämförelse av arbetsflöden i Git av Helena Orädd

Här jämförs de två arbetsflödena GitFlow och WorkFlow, som båda använts till viss del under detta projekt, för att avgöra vilket typ av arbetsflöde som passar bäst för ett projekt i liknande omfattning som detta kandidatarbete.

F. Videointegritet av Martin Steen Holmberg

Detta avsnitt undersöker och diskuterar hållbarheten av produkten och dess påverkan på användare, olycksoffer och omgivningen, både i avsedd användning och framtida missanvändning.

G. Docker eller virtuella maskiner vid mjukvaruprojekt av Caspian Süsskind

Detta avsnitt behandlar Docker och virtuella maskiner i mjukvaruprojekt och gör en jämförelse för när och baserat på vilka egenskaper hos projektet det ena är bättre än den andra.

6

Diskussion

I detta avsnitt diskuteras de olika delarna av rapporten.

6.1

Resultat

Här diskuteras resultatet av projektet.

6.1.1

Alternativa implementationssätt

Många val blev begränsade då kunden hade särskilda önskemål angående vilka bibliotek och program som skulle användas. Därför har gruppen inte funnit det relevant att undersöka andra alternativa implementationssätt av dessa delar.

Det hade varit möjligt att använda Pion eller Aiortc istället för GStreamer, men eftersom kunden stött på problem med dessa valdes GStreamer. Alla alternativ undersöktes dock och gruppen kunde inte se några tydliga anledningar att Pion eller Aiortc inte skulle kunna gå att använda till produkten, då båda lyckades skicka videoströmmar korrekt när gruppen provade implementera en snabb prototyp. Eftersom dessa inte användes i den slutgiltiga produkten är det svårt att avgöra om dessa hade påverkat slutresultatet eller arbetssättet märkbart.

Istället för att använda WebRTC från servern till Pi:en används SRTP. Detta var enklare att implementera och fungerar för den produkt som utvecklats. Därför går kommunikationen i nuläget bara från Pi:en till servern. Det skulle förenkla för större och mer komplexa system om WebRTC implementerats då detta förenklar kommunikationen mellan Pi:en och servern så att information även kan skickas från servern till Pi:en. Detta skulle till exempel möjliggöra en del av de prio 2 krav som beror på feedback av anslutningen, som i den nuvarande produkten ej kunde uppfyllas.

De ursprungliga planerna var att skriva vissa delar av produkten i Python men detta ändrades då det visade sig vara enklare än förväntat att skriva de delarna i C istället. Detta kan ha bidragit till längre implementationstid då Python bland annat har en enklare syntax än C och är därmed lite lättare att jobba med. De som arbetade med denna del av produkten var även något mer vana vid att arbeta i Python gentemot C och hade därmed troligtvis jobbat snabbare om de använt sig av Python istället för C. GStreamer och Janus var också skrivna i C vilket förstärkte initiativet att skriva i C då det därmed inte behövdes bibliotek för att

6.2. Metod

få kommunikationen att fungera. C är dessutom ett snabbare och mer hårdvarunära språk jämfört med Python vilket passade bättre för vår produkt.

6.1.2

Värde för kunden

Produkten anses av kunden utge värde för den utsedda uppgiften, men det fanns önskvärda funktionaliteter som ej kunde implementeras under den tid som var given för utveckling av produkten. Dessa skulle troligtvis göra produkten mer behändig och tillföra ett större värde för kunden. De kom i form av prio 2-krav samt övriga funktioner som aldrig sattes i kravspecifikationen men diskuterades som potentiella uppgifter att påbörja ifall tid fanns över. Bland dessa fanns exempelvis att kunna ändra videoströmningsinställningar från användargränssnittet, för att kunna få en slät videoström vid dålig uppkoppling eller en extra bra bild vid bra uppkoppling, lagra video, för att träna upp nya anställda, eller att utveckla AI-bildbehandling för att lättare kunna identifiera fartyg och potentiellt olika skador i fartygen.

Kunden har alltid haft planer på att vidareutveckla den produkt som togs fram. En sådan vidareutveckling skulle vara att implementera AI som känner igen olika typer av objekt i en video. Detta skulle göra produkten väldigt kraftfull genom att snabbare kunna få en överblick av vad som finns på olycksplatsen. Annan vidareutveckling skulle vara att kunna bestämma i användargränssnittet vilken upplösning videor skulle skickas i eller sätta på och stänga av videoströmningen från drönarna. Som nämnt i avsnitt 6.1.1 är det i nuläget komplicerat att få en kommunikation från servern till drönarna. Detta försvårar för kunden att vidareutveckla produkten. Ett sätt att få ut mer värde i produkten hade varit att hålla vidareutveckling i åtanke under fler av de designbeslut som togs under projektets gång.

6.2

Metod

Här diskuteras gruppens metoder under projektet.

6.2.1

Arbetsmetod

Gruppens arbetsmetod (se avsnitt 4.1) var väldigt simpel och enkel att förstå, men gav struktur till gruppen under arbetets gång. De veckovisa mötena gav regelbunden återkoppling till vad alla andra i gruppen åstadkommit och vilka problem som uppstått, även när gruppen var uppdelad och jobbade på helt olika håll. Detta ledde till att gruppen fortfarande kände sig samlad och medveten om allt som hände i projektet. Att alla aktiviteter skrevs upp i ett kanbanbräde i GitLab säkerställde även att inget glömdes bort. I de fall då kort blev kvar efter en sprint hade det kunnat finnas en risk i att aktiviteter sköts upp sprint efter sprint, men det skedde aldrig under arbetet. Om en aktivitet skjutits upp till en senare sprint var det istället oftast den aktiviteten som fick mest fokus vilket gjorde att den blev slutförd. Att gruppen tilldelade aktiviteter till specifika personer hjälpte med att se till att ingen aktivitet blev bortglömd eller bortvald för att den kändes jobbig eller tråkig att arbeta med. Detta hjälpte även gruppens samförstånd om vad uppgiften innebar samt skapade struktur då alla visste vad alla andra jobbade med.

På grund av osäkerhet om vad kanbanbrädets aktiviteter faktiskt innebar fanns en risk att gruppmedlemmar kunde börja jobba på samma saker alternativt anta att andra jobbade på dem. Detta undveks genom att kommunicera men det hade fortfarande kunnat hända att en grupps arbete tvingades stanna av i väntan på svar. Detta kanske skulle ha kunnat undvikas med bättre hantering av kanbankorten, men detta var inget som upplevdes som ett problem under detta projekt då alla svarade snabbt på meddelanden.

Genom att tidigt ta upp vilka kommunikationskanaler som skulle användas, samt regler om hur ofta dessa skulle läsas, fick gruppen tidigt en bra kommunikation. Just kommunikation har i vissa av gruppmedlemmarnas tidigare projekt upplevts som bristande,