Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 15hp | Datateknik
2017 | LIU-IDA/LITH-EX-G--17/037--SE
Övervakning och bedömning
av flygledares prestanda
Monitoring and Performance Assessment of
Air Traffic Controllers
Markus Alvila, Jonathan Johansson, Philip Johansson,
Silas Lenz, Sebastian Lindmark, Emil Norberg, Viktor Regard
Handledare : August Fundin Bengtsson 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 admi-nistrativ 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 sam-manhang som är kränkande för upphovsmannenslitterä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 circumstan-ces. 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 unchang-ed for non-commercial research and unchang-educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent 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 Uni-versity 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/.
© Markus Alvila, Jonathan Johansson, Philip Johansson, Silas Lenz, Sebastian Lindmark, Emil Norberg, Viktor Regard
Sammanfattning
Möjligheten att fjärrstyra flygledartorn kommer att ställa högre krav på flygledares koncentrations- och simultanförmåga runt om i Sverige. Det är viktigt att åtgärder tas för att förhindra att en trött flygledare begår ett misstag och det är just detta som det framtagna systemet försöker att förhindra.
Med hjälp av sensorer och modeller kan systemet bestämma flygledarens trötthet, stressnivå, uppmärksamhet och nuvarande arbetsuppgift. Alla värden presenteras i ett enkelt grafiskt gränssnitt. Tillsammans med resultaten för flygledarens hälsa presenteras även all sensordata i gränssnittet.
Systemet är främst uppbyggt av två olika ramverk: Apache NiFi och Apache Spark. Vad de båda ramverken har gemensamt är att de har funktionalitet för att bygga kluster, vilket betyder att endast antalet noder sätter gränsen för hur många flygledare som kan vara uppkopplade samtidigt.
Denna prototyp har inte all funktionalitet på plats för att behandla flera flygledare. Grunden är däremot lagd för att enkelt kunna implementera ytterligare funktionalitet och i slutändan ha flera flygledare uppkopplade samtidigt.
Systemet öppnar upp möjligheter till att fördela arbetet på de flygledare som är mest fokuserade och kan därför bidra till att öka flygsäkerheten.
Tillkännagivanden
Vi vill tacka vår examinator Kristian Sandahl och handledare August Fundin Bengtsson för det stöd vi fick under projektets gång. Vi vill också tacka kunden för ett gynnsamt samarbete.
Innehåll
Sammanfattning i Tillkännagivanden ii Figurer ix Tabeller xi Ordlista xiiI
Gemensam del
1
1 Inledning 2 1.1 Motivering . . . 2 1.2 Syfte . . . 2 1.3 Frågeställningar . . . 2 1.4 Avgränsningar . . . 3 2 Bakgrund 4 2.1 Projektbeskrivning . . . 4 2.2 Tidigare erfarenheter . . . 5 2.3 Kursen . . . 5 3 Teori 6 3.1 Flygledning . . . 6 3.2 Skalbarhet . . . 6 3.3 Systemanatomi . . . 73.4 Skapa värde för kunden . . . 7
3.5 Vitalparametrar . . . 7 3.5.1 Hjärtslagsvarians . . . 7 3.5.2 Poängbaserad hälsomodell . . . 7 3.6 Elektroencefalografi (EEG) . . . 8 3.7 Eyetracking . . . 8 3.8 Kognitiva tillstånd . . . 8 3.9 Ramverk . . . 8 3.9.1 Apache NiFi . . . 8 3.9.2 Apache Kafka . . . 9 3.9.3 Apache Spark . . . 10 3.9.4 Zookeeper . . . 10 3.9.5 Bokeh . . . 10 3.10 Scrum . . . 10
3.10.2 Roller . . . 10 4 Metod 12 4.1 Projektorganisation . . . 12 4.1.1 Roller . . . 12 4.1.2 Specialiseringar . . . 13 4.1.3 Möten . . . 14 4.1.4 Dokumentation . . . 15 4.1.5 Arbetsverktyg . . . 16 4.1.6 Utbildning . . . 17 4.2 Projektfaser . . . 17 4.2.1 Förstudie . . . 18 4.2.2 Specificering . . . 18 4.2.3 Konstruktion . . . 18 4.2.4 Överlämning . . . 18 4.3 Utvecklingsmetod . . . 19
4.4 Metod för att besvara frågeställningar . . . 19
4.4.1 Hur kan ett system för övervakning och bedömning av flygledares pre-standa realiseras så att ett värde skapas för kunden? . . . 19
4.4.2 Vilka erfarenheter och lärdomar har gruppens medlemmar fått från programvaruprojektet? . . . 19
4.4.3 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 19 4.4.4 Hur har de valda ramverken påverkat systemets skalbarhet? . . . 19
4.5 Metod för att fånga erfarenheter . . . 19
5 Resultat 21 5.1 Systembeskrivning . . . 21 5.1.1 Mjukvaruarkitektur . . . 22 5.1.2 Hårdvara . . . 23 5.1.3 Sensordatabehandling . . . 26 5.1.4 Bedömningsmodeller . . . 26 5.1.5 Grafiskt gränssnitt . . . 29 5.2 Gemensamma erfarenheter . . . 29 5.2.1 Processrelaterade erfarenheter . . . 29 5.2.2 Tekniska erfarenheter . . . 30
5.2.3 Resultatet i relation till kravspecifikationen . . . 30
5.3 Översikt över individuella bidrag . . . 30
6 Diskussion 32 6.1 Resultat . . . 32
6.1.1 Alternativa implementationssätt . . . 32
6.1.2 Åtgärder tills prototypen är en färdig produkt . . . 32
6.1.3 Hur skapar projektet ett värde för kunden? . . . 33
6.1.4 Skalbart system . . . 33
6.2 Metod . . . 33
6.2.1 Roller och Specialiseringar . . . 34
6.2.2 Möten . . . 34 6.2.3 Dokumentation . . . 34 6.2.4 Arbetsverktyg . . . 34 6.2.5 Utbildning . . . 35 6.2.6 Projektfaser . . . 35 6.2.7 Arbetsmetod . . . 35 6.2.8 Programmeringsspråk . . . 35
6.2.9 Fånga erfarenheter . . . 35
6.3 Arbetet i ett vidare sammanhang . . . 35
6.3.1 Samhälleliga aspekter . . . 35
6.3.2 Miljöaspekter . . . 36
6.3.3 Etiska aspekter . . . 36
7 Slutsatser 37 7.1 Hur kan ett system för övervakning och bedömning av flygledares prestanda realiseras så att ett värde skapas för kunden? . . . 37
7.2 Vilka erfarenheter och lärdomar har gruppens medlemmar fått från program-varuprojektet? . . . 37
7.3 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? . . . 38
7.4 Hur har de valda ramverken påverkat systemets skalbarhet? . . . 38
II Individuella delar
39
A Markus Alvila: Sårbarhetstestning av ett distribuerat system 40 A.1 Inledning . . . 40 A.1.1 Syfte . . . 40 A.1.2 Frågeställning . . . 40 A.1.3 Definitioner . . . 40 A.1.4 Avgränsningar . . . 41 A.2 Bakgrund . . . 41 A.3 Teori . . . 41A.3.1 Adress Resolution Protocol . . . 41
A.3.2 Man-in-the-middle (MITM) . . . 41
A.3.3 Kali Linux . . . 41
A.3.4 Ettercap . . . 41
A.3.5 Wireshark . . . 42
A.3.6 Secure Shell (SSH) . . . 42
A.3.7 Transport Layer Security (TLS) . . . 42
A.4 Metod . . . 42
A.4.1 Datornätverk . . . 42
A.4.2 Attackdator . . . 43
A.4.3 Nätverksskanning . . . 43
A.4.4 ARP spoofing attack . . . 43
A.4.5 Analysera nätverkstrafik . . . 44
A.4.6 Modifiera dataflöden . . . 45
A.5 Resultat . . . 46
A.6 Diskussion . . . 47
A.6.1 Omedelbara åtgärder . . . 47
A.6.2 Åtgärdsförslag inför skarp drift . . . 48
A.7 Slutsatser . . . 49
B Jonathan Johansson: Analys av metoder för retrospektiv och feedback 50 B.1 Inledning . . . 50 B.1.1 Syfte . . . 50 B.1.2 Frågeställning . . . 50 B.1.3 Avgränsningar . . . 50 B.2 Bakgrund . . . 51 B.3 Teori . . . 51
B.3.2 Sprintutvärdering . . . 51 B.3.3 Grupper i undersökningen . . . 52 B.4 Metod . . . 52 B.4.1 Övning för retrospektiv . . . 52 B.4.2 Övningstillfället . . . 52 B.4.3 Sammanställning . . . 53 B.5 Resultat . . . 53 B.5.1 Grupp A . . . 53 B.5.2 Grupp B . . . 53 B.5.3 Grupp C . . . 53 B.6 Diskussion . . . 54 B.7 Slutsatser . . . 54
C Philip Johansson: En analys om testdriven utveckling 55 C.1 Inledning . . . 55 C.1.1 Syfte . . . 55 C.1.2 Frågeställning . . . 55 C.2 Bakgrund . . . 55 C.3 Teori . . . 56 C.3.1 Testdriven utveckling . . . 56 C.3.2 White-box testning . . . 56 C.3.3 Black-box testning . . . 57 C.3.4 Gränsvärdestestning . . . 57 C.3.5 Fullväg-täckning . . . 57
C.3.6 TDUs påverkan på kodkvalitet och tidsåtgång . . . 57
C.4 Metod . . . 58 C.5 Resultat . . . 59 C.6 Diskussion . . . 59 C.6.1 Tidsförbrukning . . . 59 C.6.2 Kodkvalitet . . . 59 C.6.3 Påverkan av TDU . . . 60 C.7 Slutsatser . . . 60
D Silas Lenz: Prestanda vid parallellprogrammering i olika språk och ramverk 61 D.1 Inledning . . . 61 D.1.1 Syfte . . . 61 D.1.2 Frågeställning . . . 61 D.2 Avgränsningar . . . 61 D.3 Bakgrund . . . 61 D.4 Teori . . . 62 D.4.1 Apache Spark . . . 62 D.4.2 Multiprocessing i Python . . . 62 D.4.3 Gorutiner i Go . . . 62
D.4.4 Beräkna pi med Monte Carlos metod . . . 62
D.5 Metod . . . 63
D.5.1 ”Layout” på beräkningsuppsättningen . . . 63
D.5.2 Spark-konfiguration . . . 63
D.5.3 Beräkna pi med Monte Carlos metod . . . 64
D.6 Resultat . . . 64
D.6.1 Go . . . 64
D.6.2 Python . . . 65
D.6.3 Spark . . . 67
D.8 Slutsatser . . . 68
E Sebastian Lindmark: Valet av utvecklingsmetodik inom ett studentprojekt 70 E.1 Inledning . . . 70 E.1.1 Syfte . . . 70 E.1.2 Frågeställning . . . 70 E.2 Bakgrund . . . 70 E.3 Teori . . . 70 E.3.1 Scrum . . . 71
E.3.2 Dagligt scrummöte . . . 71
E.3.3 Sprintstart . . . 71
E.3.4 Tidsestimering . . . 71
E.3.5 Planeringspoker . . . 71
E.3.6 Sprint backlog . . . 72
E.3.7 Burn-down chart . . . 72
E.3.8 Sprintutvärdering . . . 72
E.3.9 Scrumban . . . 72
E.3.10 Trello . . . 72
E.3.11 Forskning . . . 72
E.4 Metod . . . 72
E.4.1 Utvärdering av frågeställningar . . . 73
E.5 Resultat . . . 73
E.6 Diskussion . . . 74
E.7 Slutsatser . . . 75
F Emil Norberg: Jämförelse av NiFi och Spark som beräkningskluster 76 F.1 Inledning . . . 76 F.1.1 Syfte . . . 76 F.1.2 Frågeställning . . . 76 F.2 Bakgrund . . . 76 F.3 Teori . . . 77 F.3.1 Generellt om beräkningskluster . . . 77 F.3.2 NiFi kluster . . . 77 F.3.3 Spark kluster . . . 78 F.4 Metod . . . 79 F.4.1 Spark-inställningar . . . 79 F.4.2 NiFi-inställningar . . . 80 F.4.3 Hårdvara . . . 82 F.4.4 Versioner . . . 83 F.4.5 För- och nackdelar . . . 83 F.5 Resultat . . . 83 F.6 Diskussion . . . 83 F.7 Slutsatser . . . 84
F.7.1 Hur ser exekveringstiderna ut i förhållande till varandra? . . . 84
F.7.2 Vad är för- och nackdelar med respektive kluster? . . . 84
F.A Appendix: nifi.properties filen från Nod 2 . . . 85
F.B Appendix: Inställningar för ExecuteProcess . . . 89
G Viktor Regard: Varför parprogrammering? 92 G.1 Inledning . . . 92
G.1.1 Syfte . . . 92
G.3 Teori . . . 93 G.3.1 Parprogrammering . . . 93 G.3.2 Kombinationer av partners . . . 93 G.4 Metod . . . 93 G.5 Resultat . . . 94 G.6 Diskussion . . . 97 G.7 Slutsats . . . 97
G.A Appendix: Enkät för att utvärdera parprogrammering . . . 99
Figurer
3.1 Exempel på hur ett NiFi-flöde kan se ut i NiFis grafiska gränssnitt. . . 9
5.1 Övergripande beskrivning av systemet. . . 21
5.2 Övergripande systemanatomi. . . 22
5.3 Bild på en Polar H7 Bluetooth Smart som mäter puls och RR-intervall . . . 24
5.4 Bild på en Emotiv Epoc+ som mäter hjärnaktivitet . . . 24
5.5 Översiktsbild av datornätverket. . . 26
5.6 Resultatet från en inlärd SVR. Rött motsvarar trött och blått motsvarar pigg. . . 27
5.7 Plottad figur för formel 5.2. . . 28
5.8 Det grafiska gränssnittet. . . 29
A.1 Man-in-the-middle-position mellan NUC 1 och NUC 2. . . 42
A.2 IP- och MAC-adresser till alla nätverksenheter förutom attackdatorn. . . 43
A.3 Terminalkommando för ARP spoofing med Ettercap. . . 43
A.4 ARP-tabell för NUC 1 innan attacken påbörjades. . . 43
A.5 ARP-tabell för NUC 2 innan attacken påbörjades. . . 44
A.6 ARP-tabell för NUC 1 under attacken. . . 44
A.7 ARP-tabell för NUC 2 under attacken. . . 44
A.8 Wireshark filter för HTTP-trafik till och från IP-adressen 192.168.1.101. . . 44
A.9 Eyetrackingdata i nätverkstrafiken från NUC 1 till NUC 2. . . 45
A.10 Inspektion av användargränssnittets källkod under körning. . . 45
A.11 Inspektion av användargränssnittets källkod under körning. . . 45
A.12 Ettercap filter för injicering av JavaScript via eyetrackingdata. . . 46
A.13 Terminalkommando för kompilering av Ettercap filtret. . . 46
A.14 Terminalkommando för ARP spoofing med Ettercap filtret. . . 46
A.15 Injicerad JavaScript i eyetrackingdata påväg till användargränssnittet. . . 46
A.16 Exekvering av injicerad JavaScript i användargränssnittet. . . 47
A.17 Sårbar kod med ofiltrerad input från mottagen eyetrackingdata. . . 48
A.18 Patchad kod med standardsträng för okänd eyetrackingdata. . . 48
D.1 Ritning över piltavlan. . . 62
D.2 Pseudokod av Monte Carlos metod för beräkning av π med n antal ”pilkast”. . . . 63
D.3 Körtid för algoritmen i Go, med olika antal gorutiner. I logskala. . . 64
D.4 Körtid för algoritmen i Python, med olika antal processer. I logskala. . . 66
D.5 Körtid för algoritmen i Apache Spark, på en respektive två maskiner. I logskala. . . 67
F.1 Kod som gör en approximation av pi. . . 77
F.2 Sparkklustrets arkitektur. . . 78
F.3 Exempel på hur utdata från ExecuteScript kan se ut. . . 79
F.4 Tillagda inställningar i spark-env.sh. Koden är hämtad från nod 1. . . 79
F.7 Vy över NiFi-flödet. . . 82
F.B.1 Inställningar i Settings. . . 89
F.B.2 Inställningar i Scheduling. . . 90
F.B.3 Inställningar i Properties. . . 91
F.B.4 Inställningar för kön innan ExecuteProcess. . . 91
G.1 Tabell över hur skicklig varje person ansåg sig vara med antalet personer i Y-led utifrån enkäten. . . 95
G.2 Diagram över hur projektmedlemmarna tyckte att effektiviteten påverkades av parprogrammering utifrån enkäten . . . 95
G.3 Diagram över hur projektmedlemmarna tyckte att kvalitén av arbetet påverkades av parprogrammering utifrån enkäten . . . 96
G.A.1Första halvan av enkäten som användes i utredningen. . . 99
Tabeller
3.1 En översikt över den poängbaserade hälsomodellen. . . 7
3.2 Frekvensband för hjärnvågor. . . 8
5.1 Översikt av systemets hårdvara. . . 24
C.1 Frågorna som ställdes till medlemmarna. . . 58
C.2 Resultatet till frågorna som ställdes till medlemmarna. . . 59
D.1 Körtid för beräkning av π med Monte Carlos metod i Go med en respektive tolv gorutiner. . . 65
D.2 Körtid för beräkning av π med Monte Carlos metod i Go med en gorutin respek-tive en gorutin per pilkast. . . 65
D.3 Körtid för beräkning av π med Monte Carlos metod i Python med en respektive tolv processer. . . 66
D.4 Körtid för beräkning av π med Monte Carlos metod i Python med en process respektive en process per pilkast. . . 67
D.5 Körtid för beräkning av π med Monte Carlos metod i Apache Spark. . . . 68
F.1 Tabell med info om de datorer som användes i klustret. . . 83
F.2 Exekveringstider för NiFi kluster. . . 83
Ordlista
Apache Apache Software Foundation. En stiftelse för programvara med öppen källkod.
Apache Kafka Ramverk för strömmande distribuering av data.
Apache NiFi Ramverk för hantering och övervakning av dataflöden.
Apache Spark Ramverk för behandling av data över noder.
API Application Programming Interface. Ett gränssnitt för att kommunicera mellan applikatio-ner.
ARP Address Resolution Protocol. Adresseringsprotokoll som används av nätverksenheter för att associera MAC-adresser med IP-adresser.
Branch En förgrening av katalogen som innehåller källkoden. Används då ny funktionalitet ska implementeras.
Burn-down chart En graf över antalet timmar som återstår.
Burn-up chart En graf över antalet timmar som har lagts ner.
Commit Tillägg av de senaste ändringarna till ett repository.
CSV Comma-Separated Values. Ett format för representation av tabell-data.
EEG Electroencephalography. Metod för att registrera hjärnbarkens elektriska aktivitet.
Eyetracker Sensor för kartläggning av ögonrörelser.
Eyetracking Kartläggning av ögonrörelser med hjälp av en eyetracker.
Git Versionshanteringsprogram.
GitHub Webbplattform för versionshantering med Git.
Google Drive Molnlagringstjänst för filer.
GUI Graphical User InterfaceGrafiskt användargränssnitt.
HRV Heart Rate VariabillityVariationer i hjärtslagens tempo och karakteristik.
IDA Institutionen för datavetenskap vid Linköpings universitet.
IP-adress Mjukvaruadress som används för adressering i nätverk.
IP Internet Protocol. Kommunikationsprotokoll som används för överföring av information över Internet.
JSON JavaScript Object Notation. Ett textbaserat format för representation av data.
CSV Comma-Separated ValuesEtt filformat för att samla till exempel flera värden av JSON-format.
Kognitiva tillstånd Syftar i detta projekt på uppmärksamhet, trötthet och stress.
LaTeX Typsättningssystem för dokument.
MAC-adress Media Access Control-adress. Statisk hårdvaruadress som används av nätverk-senheter för adressering.
MITM Man-in-the-middle. En attack där angriparen avlyssnar och möjligtvis modifierar kom-munikationen mellan två parter.
Modell Implementering av samband mellan in- och utdata.
NUC Next Unit of Computing. En dator med liten formfaktor av Intel.
PEP 8 Python Enhancement Proposal 8. Kodstandard i Python.
Pull Request Förfrågan om att slå ihop ny källkod med befintlig. Bjuder in till kodgransk-ning.
PyCharm En utvecklingsmiljö för Python.
Repository Datakatalog för lagring och versionshantering av källkod.
Scrum Metodik anpassad för programutveckling.
ShareLaTeX Webbaserad LaTeX-editor med stöd för samtidig redigering av flera användare.
Slack Onlinetjänst för kommunikation i chattrum.
SVM Support Vector Machine En kategori modeller för klassificering av data med hjälp av maskininlärning.
SVR Support Vector RegressionEn version av SVM (Support Vector Machine) för regression. Här avses implementationen i scikit-learn1.
Switch Nätverkshårdvara som används för att koppla samman nätverksenheter.
Travis CI Tjänst för automatisering av tester. Integrerbar med GitHub.
Trello Projekthanteringssystem med digital version av kanbanbräda.
Del I
1
Inledning
Den här rapporten beskriver ett projektarbete i kursen TDDD96 - Kandidatprojekt i program-varuutveckling vid Linköpings universitet. Arbetet utfördes under våren 2017 och projekt-gruppen bestod av sju studenter, varav fem läser till civilingenjör i datateknik och två till civilingenjör i mjukvaruteknik.
Rapporten inleds med en bakgrund till projektarbetet samt vilka metoder som använts under utvecklingen av systemet. Därefter presenteras resultat och en diskussion förs kring frågeställningarna. Den sista delen av rapporten består av individuella utredningar om rela-terade ämnen och har utförts av de enskilda projektmedlemmarna vid sidan om det huvud-sakliga projektarbetet.
1.1
Motivering
Projektet gick ut på att utveckla ett system för övervakning och bedömning av flygleda-res pflygleda-restanda åt Institutionen för datavetenskap (IDA) vid Linköpings universitet. Systemet skulle realisera konceptet och utgöra en prototyp inför fortsatt forskning om kognitiv lastba-lansering och utökning till fler applikationsområden än flygledning.
1.2
Syfte
Rapportens syfte är att beskriva projektgruppens tillvägagångssätt och resultat vid framta-gandet av ett system för övervakning och bedömning av flygledares prestanda, samt redovisa projektgruppens erfarenheter och de lärdomar projektgruppen fick under arbetets gång. Syf-tet med projekSyf-tet var att realisera en prototyp för bedömning av flygledares prestanda, och samtidigt undersöka hur de valda ramverken påverkar systemets skalbarhet.
1.3
Frågeställningar
Nedanstående frågeställningar besvaras i rapporten:
1.4. Avgränsningar
2. Vilka erfarenheter och lärdomar har gruppens medlemmar fått från programvarupro-jektet?
3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 4. Hur har de valda ramverken påverkat systemets skalbarhet?
1.4
Avgränsningar
I rapporten är enskilda implementations- och systemdetaljer utelämnade på grund av gällan-de sekretessavtal.
Då projektet var tidsbegränsat till 400 timmar per projektmedlem och slutprodukten skul-le vara en prototyp, lade projektgruppen fokus på att göra modelskul-lerna konfigurerbara snarare än att ge hög träffsäkerhet. Speciellt då projektgruppen ansåg sig ha låg kunskap om aktuell forskning inom medicin och kognitionsvetenskap.
Kunden förmedlade tidigt att det grafiska gränssnittet var av låg prioritet vilket gjorde att projektgruppen avgränsade sig till ett enkelt grafiskt gränssnitt, vilket gav mer tid för utveckling av det underliggande systemet.
Den huvudsakliga målgruppen för rapporten är studenter, handledare och examinatorer i kursen TDDD96 - Kandidatprojekt i programvaruutveckling vid Linköpings universitet.
2
Bakgrund
Modern flygledning karaktäriseras av centralisering, en allt högre grad av automation och optimering av resurser och tid [1]. Det ständiga beslutsfattandet och dynamiska arbetet stäl-ler höga krav på en flygledare [2]. Trenden med allt högre trafikvolymer ser ut att fortsätta, då transportstyrelsen rapporterar en ökning av resenärer på svenska flygplatser på hela 8 procent mellan årets första kvartal år 2015 och 2016[3].
Adaptiv automation är ett forskningsområde där man bland annat försöker stödja ope-ratörer vid perioder av hög kognitiv belastning [4]. Exempelvis kan kognitiv lastbalansering göras automatiserat mellan ett antal flygledare och torn. Vidare kan sådana system bedöma hela gruppers belastning och prestanda i realtid. I forskning på institutionen för dataveten-skap vid Linköpings universitet har det utvecklats en rad tekniska prototyper, sensorer och algoritmer för att övervaka flygledare. Det långsiktiga målet med forskningen är att skapa en avancerad operatörsmiljö med adaptiv automation för utvärdering och utbildning av flygle-dare.
Den här rapporten beskriver utvecklingen av en prototyp som arbetar på en hög nivå där sensordatan till viss del redan är behandlad. Prototypen som togs fram i samband med den här rapporten var nästa naturliga steg för att realisera konceptet med att övervaka och bedöma prestandan hos flygledare.
2.1
Projektbeskrivning
Projektet gick ut på att skapa en prototyp som samlar data från kroppsburna sensorer i realtid för att bedöma flygledares mentala belastning samt avgöra vad flygledaren arbetar med. Sy-stemet skulle behandla redan tolkad högnivådata och skapa modeller över flygledares hälsa, kognitiva tillstånd samt nuvarande arbetsuppgift. Till förfogande fanns eyetracking, EEG-utrustning och andra relevanta trådlösa sensorer. Med projektet skulle det alltså tas fram en lämplig ontologi (modell) för problemet och implementera en regelmotor i en servermiljö för att dra slutsatser av insamlad sensordata. Sammanfattat beskrivs projektets övergripande krav enligt nedan:
• Ta fram och implementera modeller för flygledares hälsa, kognitiva tillstånd och nuva-rande arbetsuppgift.
2.2. Tidigare erfarenheter
• En generell regelmotor som kan dra slutsatser av bearbetad sensordata i realtid ska skapas.
• Ett enkelt gränssnitt för att visualisera flygledarens tillstånd ska skapas.
2.2
Tidigare erfarenheter
Projektgruppen bestod av sju medlemmar som alla hade läst fem terminer inom civilingen-jörsprogrammet, varav fem av medlemmarna studerade på civilingenjörsprogrammet inom datateknik och två av medlemmarna på civilingenjörsprogrammet inom mjukvaruteknik. Samtliga projektmedlemmar hade ingen eller begränsad erfarenhet av flygledning, model-ler och distribuerade system. I inledningen av projektet diskuterade gruppen därför vikten av tid till utbildning, något som gruppen även tog hänsyn till vid planeringen av projektet.
Gruppens tidigare erfarenheter var att kod som skrivits av en enda person var svår att un-derhålla, vilket gjorde att parprogrammering föredrogs. Tidigare projekt som medlemmarna framgångsrikt utfört inkluderade även kodgranskningar i utvecklingsprocessen, något grup-pen därför beslöt att fortsätta med. I praktiken innebar det att all kod skulle läsas av minst två personer.
2.3
Kursen
Projektet utfördes som en del av kursen TDDD96 - Kandidatprojekt i programvaruutveckling för studenter vid Linköpings universitet på programmen civilingenjör i datateknik och civilin-genjör i mjukvaruteknik. Kursens omfattning var 15 högskolepoäng, där 14 högskolepoäng gavs för projektarbetet och 1 högskolepoäng för opponeringarna som genomfördes i kursen.
3
Teori
Detta avsnitt presenterar grundläggande teoretiska begrepp som används i resten av rappor-ten. Nedan beskrivs flygledning i allmänhet, medicinska termer, ramverk, utvecklingsmeto-diken Scrum och andra relevanta teoriavsnitt.
3.1
Flygledning
En flygledare är någon som schemalägger och planerar rutter på en flygplats. I arbetet ingår det även att sköta säkerheten på flygplatsen, där flygledare har ett ansvar att se till att plan på marken håller säkra avstånd till varandra samt bestämmer när de ska starta och landa. Dessa personer måste besitta mycket kunskap och ha kapacitet att ta hänsyn till ett flertalet paramet-rar inför varje beslut. Jobbet beskrivs som ett av det mest tanke- och koncentrationskrävande arbeten som finns, där misstag i bland annat kommunikationen kan få stora konsekvenser. Eftersom det ställs höga krav på flygledare sköts arbetet i kortare skift, mellan 90 och 120 minuter, för att se till att personalen alltid presterar på högsta nivå [5].
3.2
Skalbarhet
Skalbarhet inom mjukvara syftar på ett systems förmåga att hantera en ökande arbetsbörda med en godtagbar prestanda [6]. De metoder som finns för att skala upp eller ned ett system kan delas upp i horisontell och vertikal skalning [7].
• Horisontell skalning betyder att antingen lägga till eller dra ifrån noder till ett system. Ett exempel på horisontell skalning är att lägga till en dator till ett beräkningskluster [7].
• Vertikal skalning syftar på att lägga till resurser till en redan existerande nod i systemet. Ett exempel på detta är att lägga till en CPU-kärna till en redan existerade dator i ett beräkningskluster [7].
3.3. Systemanatomi
3.3
Systemanatomi
En systemanatomi är en graf som beskriver hur de olika beroenden mellan resurser och funk-tionalitet ser ut i ett system. Högst upp i systemanatomin befinner sig användarfunktionerna. Användarfunktionerna bryts ner till mindre funktioner tills de mest fundamentala funktio-nerna och resurser till systemet är bestämda. För att markera att en funktion A är beroende av en funktion B dras en pil från B till A [8].
3.4
Skapa värde för kunden
Värde är ett begrepp som är svårt att definiera och används oförsiktigt i vardagen. En stor del av det värde som finns för kunden förmedlas via produkten. Det är däremot ett faktum att kundrelationen spelar en stor roll för att skapa värde till kunden [9]. Följande citat förklarar kundrelationens betydelse på ett bra sätt:
”Relationens förmåga som värdeskapande resurs påverkar därmed om kunden upplever det vara värt att engagera sig i dess fortsatta existens.”[9]
Samma författare presenterar kunden och företagets överlappning av värdeskapande pro-cesser som ett gränssnitt. Det är i detta gränssnitt som företagets erbjudande och intresse kan bli en värdeskapande resurs till kunden. På samma sätt blir kundens betalningsförmåga och vilja att bygga en relation en resurs för företaget [9].
3.5
Vitalparametrar
Hälsotillståndet hos en person kan bedömas med hjälp av vitalparametrarna blodtryck, kroppstemperatur, hjärtfrekvens och andningsfrekvens. I förekommande fall tas det även hänsyn till personens syresättning, urinproduktion och medvetandegrad [10].
3.5.1
Hjärtslagsvarians
Hjärtslagsvariansen beskriver variationen i tidsavståndet mellan hjärtslag. Stressnivån för en person är omvänt proportionellt mot HRV, det vill säga att en stressad person har låg HRV. Anledningen till detta är att när en person har hög puls så är variansen låg vilket resulterar i en lägre standardavvikelse hos hjärtslagen. Ett normaliserat HRV under 60% är en indikator på att individen är stressad. Ett HRV över 85% indikerar att personen är lugn [11].
3.5.2
Poängbaserad hälsomodell
För att bedöma allvarlighetsgraden vid avvikelser från normalvärden och underlätta priori-teringen av patienter används ett bedömningsverktyget baserat på en poängbaserad hälso-modell. En översikt syns i figur 3.1.
Tabell 3.1: En översikt över den poängbaserade hälsomodellen [12].
Poäng 3 2 1 0 1 2 3
Andningsfrekvens ă9 9 ´ 14 15 ´ 20 21 ´ 29 ě30
Hjärtfrekvens ă40 41 ´ 50 51 ´ 100 111 ´ 129 ě130
Systoliskt blodtryck ď70 71 ´ 80 81 ´ 100 101 ´ 199 ě200 Kroppstemperatur ď35 35.1 ´ 36 36.1 ´ 38 38.1 ´ 38.5 ą38.5
Enligt den poängbaserade hälsomodellen ska alla vitalparametrar poängsättas från noll till tre med undantag för kroppstemperatur som ska poängsättas från noll till två. Normalvär-den ger alltid noll poäng och avvikelser graderas från ett till tre. Därefter summeras poängen och totalsumman ligger till grund för bedömning om personens hälsostatus[12].
3.6. Elektroencefalografi (EEG)
3.6
Elektroencefalografi (EEG)
EEG mäts med hjälp av elektroder som fästs på specifika områden på skalpen. Dessa elektro-der mäter i sin tur elektrisk potential som skapas av hjärnaktivitet och kan avläsas i form av spänning som kommer i en vågliknande form. Dessa oscillationer, även kallade hjärnvågor, är i sin tur indelade i olika frekvensband. Det finns ingen accepterad standard för indelning av frekvensband, men tabell 3.2 visar den definition som använts i detta projekt [13].
Tabell 3.2: Frekvensband för hjärnvågor [14]. Frekvensband (Hz) Namn 4 – 8 Thetavågor 8 – 12 Alfavågor 12 – 16 Lägre betavågor 16 – 25 Övre betavågor 25 – 45 Gammavågor
Dessa hjärnvågor korrelerar med kroppsliga tillstånd som avkoppling, koncentration och trötthet [15]. Med hjälp av olika spänningsvärden i de definierade frekvensbanden kan slut-satser dras angående de kognitiva tillstånd en person befinner sig i [13]. Exempelvis ger upp-märksamhet och koncentration en större variation på EEG-värdena än vila [16].
3.7
Eyetracking
Eyetracking syftar till någon form av mjukvara som med hjälp av en videoström på en per-sons ansikte kan bestämma i vilken riktning individen tittar. Detta verktyg kan användas för att få en inblick i var en människas fokus ligger just nu [17].
3.8
Kognitiva tillstånd
Kognition kan kort beskrivas som förmågan att bearbeta intryck, känslor och tankar [18]. Begreppet kognitivt tillstånd är dock mer abstrakt och svårt att mäta och definiera. Hit hör en mängd olika tillstånd som medvetenhet, nyfikenhet, trötthet, distraktion och stress.
3.9
Ramverk
Ramverk tillhandahåller en programvarumiljö med återanvändbar funktionalitet som un-derlättar utvecklingen av programvaror. Ramverken som används i projektet beskrivs i detta kapitel.
3.9.1
Apache NiFi
Apache NiFi kan beskrivas som ett ramverk för att administrera dataflöden. En av de många fördelarna med att använda NiFi är att dataflödet administreras via ett grafiskt gränssnitt. Om inte beräkningskraften hos en enskild dator skulle räcka till så finns det funktionalitet i NiFi för att fördela ut arbetet på ett kluster av datorer. Det finns även inställningar för att bestämma hur många trådar som arbetet hos en process ska fördelas ut på [19].
3.9. Ramverk
Figur 3.1: Exempel på hur ett NiFi-flöde kan se ut i NiFis grafiska gränssnitt.
I figur 3.1 visas ett exempel på hur ett flöde i NiFi kan se ut. I detta exempel läser Ni-Fi kontinuerligt data från ListenHTTP. Den inkommande dataströmmen manipuleras sedan med ett godtyckligt script i ExecuteScript. Utdata från ExecuteScript skrivs sedan till en fil med PutFile. ListenHTTP, ExecuteScript och PutFile är alla exempel på ”processorer” i NiFi. ”Pro-cessorer” används i NiFi för att göra förändringar i datatrömmen. För att få dataströmmen att gå mellan till exempel ListenHTTP och ExecuteScript som i figur 3.1 så räcker det att endast dra en pil mellan dem.
3.9.2
Apache Kafka
Apache Kafka används för distribution av dataströmmar. Kafka följer en så kallad publicera/prenumerera-modell där avsändaren av datapaket inte känner till eventuella mot-tagare utan kategoriserar bara paketen i ämnen. Likaså känner inte motmot-tagaren till avsända-ren utan pavsända-renumererar bara på ett eller flera ämnen. Kafka klarar av att göra det här snabbt, skalbart till flera servrar och med möjlighet till redundans i form av att säkerhetskopior ska-pas på flera servrar [20].
3.10. Scrum
3.9.3
Apache Spark
Apache Spark är ett ramverk för storskaliga beräkningar i datorkluster. Det sköter distribu-erad uppgiftsutdelning, schemaläggning av processer samt grundläggande dataflöden och tillgängliggör detta genom ett API i flera språk, bland annat Python och Java. Spark innehål-ler även bibliotek för behandling av strömmande data i små batcher, samt för distribuerad maskininlärning [21].
Antalet CPU-kärnor som Spark ska allokera på varje dator i klustret går att bestämma specifikt för varje enskild dator och för varje enskild process [22].
3.9.4
Zookeeper
Zookeeper är ett ramverk utvecklat av Apache. Syftet med ramverket är att underlätta koor-dinationen mellan enheter i distribuerade applikationer [23].
3.9.5
Bokeh
Bokeh är ett ramverk för interaktiva grafer i webbläsare. Det stödjer bland annat realtidsupp-dateringar och konstruktion av grafiska gränssnitt i Python [24].
3.10
Scrum
Scrum är en agil utvecklingsmetodik som används för produktutveckling. Metodiken foku-serar på att genom hela utvecklingsprocessen flexibelt ha möjlighet att ändra fokus utefter kundens behov. Detta görs möjligt med så kallade sprintar, vilka är tidsbestämda perioder be-stående av flertalet aktiviteter att utföra. Under en sprintplanering planeras vilka aktiviteter som ska utföras under perioden. Dessa är krav från kunden som har brutits ner, tidsuppskat-tats och sedan prioriterats utifrån hur viktiga de är. Eftersom alla aktiviteter är tidestimerade med hur många timmar dessa beräknas ta, kan sprinten fyllas på med så många tidupp-skattade timmar som gruppen kommer att lägga under perioden. Tidsuppskattningen kan utföras med hjälp av planeringspoker [25].
Under sprinten, som vanligtvis är mellan 3 och 30 dagar, hålls korta dagliga möten i ut-vecklingsgruppen. Syftet med dessa möten är att hela gruppen ska få reda på vad varje indi-vid gjorde under gårdagen, kommer att göra under dagen och om några problem eller hinder existerar. När sprinten är slut hålls en sprintutvärdering. Här gås den tidigare perioden ige-nom, bland annat vad som har fungerat bra eller dåligt och om gruppens tidsuppskattning var någorlunda korrekt. Den nya sprinten påbörjas snart därefter och nya funktioner planeras för implementation [25].
3.10.1
Planeringspoker
Planeringspoker är en metod för att tidsuppskatta aktiviteter i ett projekt. Tidsuppskattning-en planeringspoker utförs gTidsuppskattning-enom att alla medlemmar i utvecklingsteamet samlas i grupper om 10 och röstar på hur lång tid som kommer krävas för att slutföra aktiviteten. Varje röst är lika mycket värd och den slutgiltiga tiden är den tid som har flest röster. De tider som går att rösta på är tal från fibonacciserien (0, 1, 2, 3, 5, ...) [26].
3.10.2
Roller
I Scrum-grupper finns följande roller definierade:
• Produktägare - Har kontakt med kund och förmedlar information kring kundens krav till gruppen.
3.10. Scrum
• Scrum-master - Är ansvarig för att strukturen för Scrum hålls genom hela projektet. Scrum-mastern har även ansvaret för att bryta ner krav från kund till klara och tydliga uppgifter för utvecklingsteamet.
• Utvecklare - En utvecklare är en del av en utvecklingsgrupp som har ansvaret för att funktioner blir implementerade.
4
Metod
Detta kapitel beskriver vilka metoder som användes för att genomföra projektarbetet. Först presenteras vald metod för att fördela ansvaret i projektet med hjälp av rolltilldelningar och specialiseringar. Sedan presenteras den mötesstruktur och de arbetsverktyg som användes i projektet, samt den dokumentation och utbildning som genomfördes. Därefter behandlas de fyra olika projektfaserna och vald utvecklingsmetod med tillhörande utvärderingar.
4.1
Projektorganisation
För att organisera projektarbetet tog gruppen fram en projektstruktur med väldefinierade an-svarsområden och förutsättningar. Alla projektmedlemmar undertecknade sedan ett grupp-kontrakt.
4.1.1
Roller
Under den första veckan tillsattes teamledaren efter en intern urvalsprocess, och därefter identifierade och tilldelade gruppen ett antal roller. Alla projektmedlemmar tilldelades ock-så uppgifter relaterade till rollen. Projektrollerna var på deltid och alla arbetade även med utveckling och testning under stora delar av projektet.
4.1.1.1 Teamledare
Teamledarens huvudansvar var att säkerställa att projektgruppen uppfyllde sina mål och att leda arbetet som gruppen gemensamt planerade. Andra ansvarsområden var att coacha övriga projektmedlemmar, se till att uppsatta processer följdes och att representera gruppen utåt. Teamledaren ansvarade även för att ta fram och underhålla projektplanen.
4.1.1.2 Analysansvarig
Analysansvarig såg till att kommunikationen med kunden sköttes på ett bra sätt och att slut-produkten motsvarade kundens verkliga behov. Det låg på analysansvarig att agera förhand-lingspart och att vara den som driver framtagandet av kravspecifikationen framåt. För att
4.1. Projektorganisation
komma fram till genomförbara och rimliga krav upprätthölls en tät kontakt mellan analys-ansvarig och övriga projektmedlemmar. Analysanalys-ansvarig såg till att kraven blev tydliga och väldokumenterade.
4.1.1.3 Arkitekturansvarig
Den arkitekturansvariges ansvar var att ta fram en stabil arkitektur, identifiera komponenter och gränssnitt samt göra övergripande teknikval. En av den arkitekturansvariges viktigaste uppgifter var att beskriva och dokumentera arkitekturen utförligt.
4.1.1.4 Utvecklingsledare
Utvecklingsledarens främsta ansvar var att detaljera designen, leda och vid behov fördela utvecklingsarbetet. Dessutom var det utvecklingsledarens ansvar att fatta beslut om utveck-lingsmiljön under projektets inledande fas.
4.1.1.5 Kvalitetssamordnare
Kvalitetsarbetet i projektet utfördes av alla roller, men en av kvalitetssamordnarens ansvars-uppgifter var att ta initiativ och följa upp arbetet. En av de största ansvars-uppgifterna för kvalitets-samordnaren var att skriva en kvalitetsplan, samt fånga upp erfarenheter och lärdomar under projektets gång.
4.1.1.6 Testledare
Testledaren beslutade om systemets status, skötte den dynamiska verifieringen och valide-ringen av systemet genom exekvering, samt testade kvalitetskrav tillsammans med kvalitets-samordnaren. Testledaren ansvarade även för projektets testplan och testrapporter.
4.1.1.7 Konfigurations- och dokumentansvarig
Konfigurations- och dokumentansvarig bestämde vilka arbetsprodukter som skulle versions-hanteras, valde och underhöll arbetsverktygen, samt följde upp att de användes på rätt sätt. Dessutom innebar rollen ett ansvar över projektets dokumentmallar och leveranser till dead-lines.
4.1.2
Specialiseringar
Under projektet fick varje gruppmedlem varsin specialisering tilldelad. Det innebar att varje medlem utöver sin projektroll även var ansvarig för ett visst kunskapsområde. Korta utbild-ningar hölls vid behov för övriga gruppmedlemmar av ansvarig specialist.
4.1.2.1 Sensorer
Specialiseringen innebar dels att läsa på om sensorers funktionalitet och krav för att bli med-veten om mätstörningar och ideal placering, dels att ansvara för att insamlad data blev klas-sificerad och lagrad korrekt. Se relaterad hårdvara i kapitel 5.1.2.1.
4.1.2.2 Eyetracking
Specialiseringen innebar att läsa på om hur Smart Eye Pro används, besöka visualiserings-centret i Norrköping för att bekanta sig med utrustningen, samt ansvara för att inspelad data höll hög kvalitet med tidsstämplar och klassificering.
4.1. Projektorganisation
4.1.2.3 Modeller
Under projektet skulle tre modeller tas fram för att kunna bestämma flygledarens hälsotill-stånd, kognitiva tillstånd och nuvarande arbetsuppgift. Till detta utsågs tre medlemmar som ansvarade för att läsa in sig på forskning relaterat till respektive område. De tog del av forsk-ningsrapporter och litteratur med målet att hitta korrelationer mellan indata och utdata. För medlemmen som ansvarade för hälsomodellen innebar det exempelvis att hitta korrelationer mellan vitalparametrar och hälsotillstånd.
4.1.2.4 Datornätverk
Specialiseringen innebar ett ansvar för uppsättningen, installationen och konfigurationen av alla datorer och nätverksutrustning. Dessutom innebar specialiseringen ett ansvar för att hål-la en beskrivning över systemets konfiguration aktuell.
4.1.2.5 Inferensmotor/AI
Modellberäkningarna skulle utföras distribuerat och med hjälp av AI. Specialiseringen inne-bar ett ansvar för att en lämplig struktur för modellberäkningar och AI togs fram.
4.1.3
Möten
Projektgruppen strävade efter att hålla få och effektiva möten för att frigöra maximalt med tid till utveckling och testning. Detta uppnåddes genom att följa fasta agendor i största möjliga utsträckning under status-, planerings-, uppföljnings-, och kundmötena.
4.1.3.1 Status
För att synkronisera gruppens medlemmar och handledare hölls ett gemensamt statusmöte varje måndag. Statusmötet följde en fördefinierad agenda där projektmedlemmarna disku-terade projektets nuvarande status, föregående veckas arbete och planer för den kommande veckan.
4.1.3.2 Planering
Innan varje sprint hölls ett planeringsmöte som utvecklingsledaren förberedde. Under plane-ringsmötet gick projektgruppen igenom vad som skulle utföras under nästkommande sprint. Vidare gick gruppen igenom att-göra listan på Trello, lade till nya punkter, tidsuppskattade med planeringspoker och prioriterade punkterna. Prioritering skedde utifrån tidplan och be-roenden. Därefter var det fritt fram för projektmedlemmarna att ta till sig av uppgifter och utvecklingsledaren delade vid behov ut överblivna uppgifter.
4.1.3.3 Ståupp-möte
Gemensamma arbetspass inleddes med ett ståupp-möte på maximalt 15 minuter. Alla pro-jektmedlemmar berättade i tur och ordning om de senaste framstegen, eventuella problem och planerat arbete för dagens arbetspass.
4.1.3.4 Uppföljning
Efter varje sprint hölls ett utvärderingsmöte där projektmedlemmarna reflekterade över vad de hann med, vad som återstod och om något kunde förbättras till nästa sprint. Alla lärdomar dokumenterades av sekreteraren, som utsågs under varje möte. Att lärdomarna sedan blev utnyttjades till nästa sprint var gruppens gemensamma ansvar. Om kravspecifikationen eller
4.1. Projektorganisation
4.1.3.5 Kundmöte
Under förstudien 4.2.1 och specifikationsfasen 4.2.2 hölls formella möten tillsammans med kund. Här diskuterades kontrakt, implementationsverktyg och mål med projektet. Under konstruktionsfasen 4.2.3 besökte kunden ofta projektets arbetsplats som låg beläget i samma hus som kunden jobbar i. Därför kunde diskussioner och frågor tas upp på plats under denna fas och endast demonstrationsmöten behövde bokas in.
4.1.4
Dokumentation
Under projektet dokumenterades ansvarsområden och förhållningssätt i ett gruppkontrakt. Projektgruppens möten protokollfördes. Veckovisa tidsrapporter med statusrapporter skapa-des och skickaskapa-des till handledaren och examinatorn. Mer formell dokumentation som togs fram var projektplan, kvalitetsplan, kravspecifikation, arkitekturbeskrivning, testplan och testrapporter. Även en installations- och driftmanual togs fram. En sammanfattning av all dokumentation och vad den innehöll finns nedan:
• Gruppkontrakt – I gruppkontraktet definierades gruppens målsättning om att levere-ra en slutprodukt av hög kvalitet med fokus på konfigurerbarhet och skalbarhet, se kvalitetsplan nedan. Efter gemensamma diskussioner fastställdes även hantering av frånvaro och konflikter samt gruppens önskemål kring närvaro och beslutsfattande. Dessutom dokumenterades överenskomna tillvägagångssätt för versions- och doku-menthantering, kommunikation och arbetsrapportering.
• Mötesprotokoll – För dokumentation av erfarenheter och uppföljning av arbetet pro-tokollfördes gruppens möten. I protokollen dokumenterades förra veckans händelser, kommande veckans planerade arbete och potentiella problem. Även fattade beslut och kommentarer kring dessa dokumenterades.
• Tid- och statusrapporter – Varje måndag genererades en tidsrapport för alla projekt-medlemmar med den senaste veckans loggade tid och eventuella samarbeten. Den ge-nererade tidsrapporten skickades sedan till examinatorn och handledaren tillsammans med en aktuell statusrapport.
• Projektplan – Projektet strukturerades upp av projektplanen, som innehöll informa-tion om projektets bakgrund, avgränsningar och mål. Dessutom definierade projektpla-nen projektorganisatioprojektpla-nen, utbildning och förhållningssätt. För att bryta ner projektet i mindre hanterbara bitar inkluderade projektplanen även en tid- och resursplan med definierade milstolpar och beslutspunkter. Projektplanen innehöll även en riskanalys. • Kvalitetsplan – För att gruppen skulle arbeta enhetligt med kvalitet definierades
ar-betsrutiner för utvecklingsarbetet och granskning i en kvalitetsplan. Dokumentet defi-nierade även när utbildningsaktiviteter skulle ske och vem som var ansvarig.
• Kravspecifikation – Kundens önskemål och krav definierades i kravspecifikationen. Den inledande projektbeskrivningen från kunden utgjorde en grund och därefter fyll-des kravspecifikationen på allteftersom projektgruppen och kunden nådde överens-kommelser om den slutgiltiga funktionaliteten.
• Arkitekturbeskrivning – Systemets arkitektur dokumenterades i en arkitekturbeskriv-ning, där särskilt gränssnitten mellan systemets olika delar definierades. Även de en-skilda delsystemens funktionalitet och ansvarsområden dokumenterades.
• Testplan och testrapporter – Under utvecklingens gång testades systemets funktionali-tet enligt testplanen och resultaten dokumenterades i testrapporter, som sedan skicka-des till examinatorn och handledaren.
4.1. Projektorganisation
• Installations- och driftmanual – För att kunden efter projektets avslutande ska kun-na installera och driftsätta systemet på egen hand skrevs en utförlig installations- och driftmanual.
4.1.5
Arbetsverktyg
Arbetsverktygen valdes ut för att effektivisera samarbetet i gruppen såväl som det indivi-duella arbetet. Vi strävade efter att hitta lättanvända verktyg med minimal tidsåtgång att använda.
4.1.5.1 Dokumentlagring
I Google Drive lagrades alla projektrelaterade dokument som kontaktlista, mötesprotokoll, gruppkontrakt, rollspecifika dokument och andra mer formella dokument skapade i LaTeX.
4.1.5.2 Dokumentskrivning
Alla formella dokument avsedda för inlämning eller överlämning skrevs i LaTeX med hjälp av samarbetstjänsten ShareLaTeX. Detta för att få en enhetlig formatering på samtliga doku-ment och för att enkelt kunna underhålla alla dokudoku-mentmallar.
4.1.5.3 Intern kommunikation
Digital kommunikation inom gruppen skedde via Slack. Kommunikationen mellan alla par-ter sköttes i specifika kanaler, för att senare lätt kunna hitta nödvändig information. Varje gång ett nytt ämne behandlades skapades en ny kanal med passande namngivning dit alla berörda medlemmar bjöds in. Konfigurations- och dokumentansvarig modererade alla kana-ler.
4.1.5.4 Tidsrapportering
Alla projektmedlemmar ansvarade för sin egen tidsrapportering. För att underlätta rappor-teringen och uppföljningen använde sig gruppen av Toggl. För att generera de veckovisa tidsrapporterna skrev konfigurations- och dokumentansvarig en Slackbot som kombinerade det senaste mötesprotokollet med inrapporterad tid och skapade en PDF-fil1.
4.1.5.5 Arbetsplanering
Projektplanering såväl som sprintplanering skapades och visualiserades med hjälp av sam-arbetsverktyget Trello. Genom att skapa kort för varje aktivitet kunde sedan Burn-down och Burn-up diagram tas fram. Visualiseringarna underlättade den gemensamma planeringen såväl som synkroniseringen mellan projektmedlemmarna och handledaren.
4.1.5.6 Versionshantering
Alla filer som var nödvändiga för att bygga och exekvera projektet versionshanterades med Git i ett privat repository på GitHub. En ny branch skapades för varje större funktionalitets-kliv och commits utfördes regelbundet under arbetspass.
4.2. Projektfaser
4.1.5.7 Testning
Testerna, som är skrivna i Pythons unittest-bibliotek, kördes med verktyget Travis CI för att automatisera testning och uppnå kontinuerlig integration. Travis CI integrerades med Git-Hub och körde alla definierade tester vid nya commits och pull-requests. Slutförda tester pre-senterades sedan visuellt i både Travis CI och GitHub vilket gjorde att projektmedlemmarna enkelt kunde se nuvarande kodstatus.
4.1.5.8 Parprogrammering
Under projektet användes parprogrammering vid utveckling och implementation av nya funktioner. Då gruppen bestod av sju utvecklare växlades programmeringspartner kontinu-erligt för att involvera samtliga personer.
4.1.5.9 Systemanatomi
Systemanatomin togs fram genom att först anteckna alla användarfunktionerna. Sedan ställ-des frågan: ”Vilka funktioner eller resurser måste redan vara implementerade innan denna funktion kan implementeras?”. Detta upprepades tills dess att de mest fundamentala funk-tionerna och resurserna var dokumenterade i systemanatomin.
Arkitekturansvarig och teamledare tog tidigt i projektet fram en systemanatomi för syste-met tillsammans med examinator. Efteråt involverades gruppen för att tillsammans diskutera beroenden mellan komponenter i den framtagna systemanatomin.
4.1.5.10 Kodgranskning och kodstandard
Projektet använde sig av kodgranskningar för att godkänna ny kod i master-branchen. Minst en granskning av en person annan än utvecklaren krävdes för att koden skulle bli godkänd. I samband med kodgranskningen kontrollerades också att den valda kodstandarden PEP 8 följdes.
4.1.5.11 Utvecklingsmiljö
Projektgruppen använde utvecklingsmiljön PyCharm för all programmering i Python. PyCharm har funktioner för att öka produktiviteten, som automatiska kodkontroller mot vald kodstandard, kodkomplettering och en tydlig dokumentation.
4.1.6
Utbildning
Alla projektmedlemmar utbildade kontinuerligt sig själva och gruppen genom litteraturstu-dier, workshops och korta föredrag. Utbildningsaktiviteterna syftade till att gruppen skulle uppnå en tillräckligt hög grundkunskap för att behärska valda verktyg, ramverk och teknik-områden. Det övergripande utbildningsmålet var att kunna utveckla slutprodukten enligt kravspecifikationen. Kunskapsområden som projektmedlemmarna utbildade sig inom åter-finns under kapitlen 4.1.5 arbetsverktyg, 4.1.2 specialiseringar och 3.9 ramverk.
4.2
Projektfaser
Målet med projektfaserna var att bryta ner projektet i mindre beståndsdelar, allokera tid till specifika aktiviteter och sätta upp delmål. Dessa gav tillsammans en vägledning om hur pro-jektet kunde genomföras steg för steg. Propro-jektet hade fyra övergripande faser som i sin tur delades in i ett antal sprintar och detaljplanerades under projektgruppens planeringsmöten.
4.2. Projektfaser
4.2.1
Förstudie
Under förstudien lärde projektmedlemmarna känna varandra, fördelade alla roller och speci-aliseringar, satte upp projektstrukturen och började sätta sig in i alla nya kunskapsområden. En första version av alla projektdokument skrevs och lämnades in. Förstudien pågick under fem veckor.
4.2.2
Specificering
Under specificeringsfasen bekantade sig gruppen ordentligt med valda tekniker och ram-verk. Alla förberedelser inför konstruktionsfasen avslutades och en första prototyp för syste-mets användargränssnitt togs fram. Prototypkod för modellerna och testkod i relevanta ram-verk programmerades. En komplett kravspecifikation och arkitekturbeskrivning togs fram och godkändes av kunden. Dessutom bekantade sig projektgruppen med vald utvecklings-metod, se kapitel 4.3. Specificeringsfasen pågick under två veckor.
4.2.3
Konstruktion
Under konstruktionsfasen skrevs majoriteten av koden. Under konstruktionsfasen spelades också data in för skapandet och testningen av modellerna. Konstruktionen var den längsta fasen och pågick under åtta veckor. För bättre överblick och uppföljning delades den därför in i tre underfaser.
4.2.3.1 Uppstart
I detta stadie implementerades den första riktiga koden i systemet. Därmed kunde också kod-basen vara instabil. Enkla tester kunde genomföras, men majoriteten av den kritiska funk-tionaliteten specificerad i kravspecifikationen återstod att implementera. Under uppstarten detaljerades att-göra listan och grundläggande moduler för datainsamling från sensorer och eyetracker implementerades. Dessutom togs dataflödet i Apache NiFi fram och en slutver-sion av hälsomodellen skrevs.
4.2.3.2 Alfa
Systemet kunde här liknas vid en enkel prototyp med de värsta buggarna åtgärdade, över-ensstämde delvis med arkitekturbeskrivningen och viss kritisk funktionalitet återstod. En första demonstration för kunden hade också genomförts. Under alfafasen implementerades modellen för kognitiva tillstånd och modellen för nuvarande arbetsuppgift påbörjades. An-vändargränssnittet började ta form och den första integrationstestningen utfördes.
4.2.3.3 Beta
Kunden kunde i betafasen använda produkten och dra användbara slutsatser, men det fanns fortfarande förbättringar att göra. Systemet uppfyllde helt arkitekturbeskrivningen och till stor del kravspecifikationen. Mot slutet av betafasen var testplanen avklarad. Under be-tafasen slutfördes implementationen av samtliga modeller. Dessutom utfördes avslutande systemtestning.
4.2.4
Överlämning
Den sista fasen överlämning bestod i att slutföra en komplett verifiering av systemets funk-tionalitet och stabilitet, samt att dokumentation slutfördes och slutprodukten lämnades över till kunden. Ett särskilt planerat tillfälle för en slutdemonstration hos kunden genomfördes.
4.3. Utvecklingsmetod
4.3
Utvecklingsmetod
Projektgruppen utvecklade all mjukvara enligt Scrum, se kapitel 3.10. Alla projektfaser de-lades upp i sprintar. I gruppen tilldede-lades teamledaren rollen som produktägare och lingsledaren rollen som Scrum-master. Förutom dessa roller tilldelades teamledaren, utveck-lingsledaren och övriga i gruppen titeln utvecklare. Under projektets gång användes en mo-difierad variant av Scrum som tog hänsyn till att gruppen inte hade schemalagd tid tillsam-mans varje vardag och att de dagliga mötena, se kapitel 4.1.3.3, endast hölls på schemalagd arbetstid.
4.4
Metod för att besvara frågeställningar
4.4.1
Hur kan ett system för övervakning och bedömning av flygledares
prestanda realiseras så att ett värde skapas för kunden?
Denna frågeställning har besvaras främst genom att hålla en kontinuerlig diskussion med kunden. Detta för att säkerställa att både gruppen och kunden har haft delade tankar kring det system som utvecklats.
4.4.2
Vilka erfarenheter och lärdomar har gruppens medlemmar fått från
programvaruprojektet?
Detta har besvarats genom diskussion utifrån resultat från projektet. Dessa diskussioner har förts och nedtecknats under sprintutvärderingar och statusmöten.
4.4.3
Vilket stöd kan man få genom att skapa och följa upp en systemanatomi?
Den tredje av rapportens frågeställningar har besvaras genom diskussion i gruppen huruvida systemanatomin har hjälpt projektet eller ej.
4.4.4
Hur har de valda ramverken påverkat systemets skalbarhet?
Denna frågeställning besvaras genom reflektion och diskussion med gruppen av de resultat som projektet har gett.
4.5
Metod för att fånga erfarenheter
Projektet har innefattat flertalet olika moment vilket har gjort det svårt för samtliga medlem-mar att vara involverade i alla delar. Därför har interna demonstrationer hållits för att alla ska få en övergripande bild över projektets moduler. Dessa genomgångar har gått till väga på så sätt att den som har haft bäst förståelse för momentet har visat ett lättare exempel för hur till exempel ramverket används. En storbildsskärm fanns till gruppens förfogande och användes flitigt till dessa demonstrationer.
Efter varje sprint har utvecklingsledaren, i egenskap av Scrum-master, hållit utvärderings-möten där gruppen samlats för att diskutera föregående sprint. Fokus har främst legat i att identifiera svårigheter och problem för att på så sätt kunna undvika dem till kommande sprintar.
Utöver utvärderingsmötena relaterade till sprintarna har även gruppen provat på en ut-värderingsövning där fokus har legat i att lyfta fram vardera medlems tankar om vad som har fungerat bra respektive dåligt under projektet. Övningen är uppdelad i två moment. I den första delen får varje deltagare, under tystnad, skriva ned sina tankar om respektive kategori; saker jag aldrig vill se igen, saker vi kan göra bättre, och saker som har varit bra. Till skillnad
4.5. Metod för att fånga erfarenheter
från de regelbundna utvärderingarna har denna övning tagit fram mer generella punkter om projektet samt lyft projektmedlemmars insatser.
5
Resultat
Detta kapitel beskriver resultatet av projektarbetet. Först presenteras systemet och därefter presenteras gemensamma erfarenheter och de individuella bidragen till kandidatrapporten.
5.1
Systembeskrivning
Systemet består av en hårdvaruuppsättning och en mjukvaruarkitektur som presenteras här.
5.1. Systembeskrivning
Som illustrerats i figur 5.1 är systemet uppdelat i fyra lager: Input, Behandling, Inferensmotor och Presentation.
• Input: Samlar in högnivådata från de sensorer som används och kommunicerar vidare med resten av systemet.
• Behandling: Behandlar och filtrerar sensordata från Input innan den når Inferensmotor. Behandling fungerar som mellanhand mellan Presentation och Inferensmotor då Apache Kafka tillhör detta lager. Apache Kafka används för att skicka och ta emot data från Inferensmotor samt för att skicka till Presentation eftersom Behandling till stor del är upp-byggt i ramverket Apache NiFi. Se avsnitt 3.9.1 och 3.9.2 ovan för mer information om Apache NiFi respektive Apache Kafka.
• Inferensmotor: Alla modellerna är implementerade i detta lager. Totalt består lagret av tre NUC:s som alla är noder i Spark-klustret.
• Presentation: Presenterar resultaten från Inferensmotor i ett grafiskt gränssnitt.
Figur 5.2: Övergripande systemanatomi.
Systemanatomin i figur 5.2 ger i översta raden en bra visualisering av vilken funktionalitet som implementerats i systemet, och i de lägre stegen vilka beroenden som behövdes för att denna funktionalitet skulle kunna implementeras.
5.1. Systembeskrivning
ponenten Collector. Collector skickar sedan vidare denna data till Controller som är en kompo-nent uppbyggd med NiFi. Här behandlas och filtreras sensordata så att Inferensmotor endast får den data den behöver för att köra modellerna.
Inferensmotor använder sig av ett distribuerat beräkningskluster i Spark. Det är här som alla modellerna är implementerade. Efter att Inferensmotor har beräknat modellerna så skickas resultaten vidare till GUI via Kafka.
5.1.1.1 Distribuerad datainsamling
Datainsamlingen byggs upp av komponenterna Collector och Controller. Collector kan betrak-tas som den nödvändiga funktionaliteten för att ta emot data från sensorerna och skicka den vidare till NiFi. All data tas emot i NiFi via HTTP servrar.
Sensordata skickas som ett JSON-meddelande på formen: {”timestamp”: unixtimestamp, ”datatyp1”: värde1 ...}. Sensorerna har främst simulerats med läsning från loggfiler i CSV eller JSON-format.
5.1.1.2 Distribuerade beräkningar
De nödvändiga beräkningarna har delats upp i följande delar: • En modell för hälsotillstånd
• En modell för trötthetsuppskattning • En modell för stressuppskattning
• En modell för uppmärksamhetsuppskattning
Alla ovanstående beräkningar går i grunden till på samma sätt: Först läses data som krävs in från en eller flera topics i Kafka, sedan behandlas den, och till sist publiceras resultatet på ett eller flera nya Kafkatopics.
Modellerna distribuerar beräkningarna i Spark-klustret. Detta sker genom att alla datapa-ket som anländer inom en kortare tidsrymd, som bestäms av hur lång tid en enskild beräk-ning tar, delas upp på alla tillgängliga noder och beräknas separat för att sedan samla ihop resultaten. På så sätt kan en snabbare dataström och tyngre modeller hanteras genom en ök-ning av antalet noder. Då hälsotillståndet utgår från flera olika sensorvärden klarar denna modell att spara värden mellan beräkningar. Om modellen tar emot ett datapaket som inte innehåller alla efterfrågade värden så återanvänds övriga värden från tidigare datapaket.
5.1.2
Hårdvara
För att utföra projektet har det behövts en del hårdvara. I tabell 5.1 listas all hårdvara som använts för att bygga systemet och även de sensorer som datainsamlingen sker genom. Det användes alltså 6 stycken Intel NUCs med 16GB RAM-minne, och en SSD vardera. Switch och nätverkskablar kopplar ihop dessa till ett nätverk. Resterande i tabellen är sensorer, som nämndes ovan, är till för att mäta respektive parametrar som står definierat. Bland annat en Polar H7 Bluetooth Smart och en Emotiv Epoc+ visas i figur 5.3 respektive 5.4.
5.1. Systembeskrivning
Tabell 5.1: Översikt av systemets hårdvara.
Antal Typ Beskrivning
6 Mini-PC Intel NUC I5-6260U 2.5” Skylake
6 RAM-minne Crucial VS 16GB DDR4 2133MHz SODIMM
1 SSD Crucial MX300 525GB M.2-SATA
5 SSD Intel 600P Series 128GB M.2-PCI-E SSD
1 Switch ZyXEL GS1900-48 48 Port Gigabit Smart Managed 6 Nätverkskabel Deltaco FTP Cat.6 Shielded RJ45 1M
1 Nätverkskabel Deltaco FTP Cat.6 Shielded RJ45 5M
2 EEG-sensor EMOTIV Epoc+, registrerade hjärnaktiviteten med 14-kanalig EEG. 1 Multisensor Mätte puls, syresättning, andningsfrekvens och kroppstemperatur. 1 Pulssensor Polar H7 Bluetooth Smart mätte puls och RR-intervall.
1 Eyetracker Smart Eye Pro, mätte kontinuerligt huvud- och ögonrörelser.
Figur 5.3: Bild på en Polar H7 Bluetooth Smart som mäter puls och RR-intervall
5.1. Systembeskrivning
5.1.2.1 Kroppsburna sensorer
För att kunna bedöma flygledarens hälsotillstånd användes sensorer som kontinuerligt mät-te puls, syresättning, andningsfrekvens och kroppsmät-temperatur. Olika kognitiva tillstånd be-stämdes utifrån EEG-data i kombination med övrig tidigare nämnd hälsodata.
5.1.2.2 Eyetracking
För att kunna bestämma flygledarens nuvarande arbetsuppgift användes en Smart Eye Pro. Systemet för Smart Eye Pro bestod av åtta kameror och avancerad mjukvara från Smart Eye AB. Eyetrackingutrustningen var inte direkt kopplad till projektets system, istället spelades data in i förväg och sparades till fil. Den inspelade datan lästes sedan från fil och matades in i övriga systemet, se översiktslistan i avsnitt 5.1.2.3 nedan.
5.1.2.3 Datornätverk
Datornätverket var uppbyggt av sex stycken Intel NUC datorer och operativsystemet Fedo-ra Server 25 installeFedo-rades på samtliga. Alla enheter konfigureFedo-rades med statiska IP-adresser. Systemets funktionalitet var utspridd på de sex datorerna och varje enhet hade specifika ar-betsuppgifter, se översikt nedan och figur 5.5:
• NUC 1: Lagrade insamlad data och exekverade användargränssnittet. Använde HTTP för att skicka data till Apache NiFi och även för att ta emot slutsatser. NUC 1 skötte all extern datainsamling från de kroppsburna sensorerna och visualiserade alla slutsatser. • NUC 2: Exekverade Apache NiFi-ramverket och möjliggjorde visuell hantering av
da-taflödena i systemet. Tog emot all rådata från NUC 1 och publicerade den till Apache Kafka.
• NUC 3: Exekverade Apache Kafka och en ZooKeeper-server. Skötte köhantering av sy-stemets dataflöden och möjliggjorde att sysy-stemets olika delar kunde publicera och pre-numerera på alla dataflöden.
• NUC 4: Exekverade Apache Spark. Resurshanterade beräkningsklustrets hårdvara. Pre-numererade på rådata från Apache Kafka och utförde modellberäkningarna distribue-rat på NUC 4-6. Publicerade slutsatserna till Apache Kafka.
• NUC 5-6: Exekverade Apache Spark och var en del av beräkningsklustret som utförde arbete på begäran av NUC 4. Antal enheter i beräkningsklustret kunde enkelt utökas.
5.1. Systembeskrivning
Figur 5.5: Översiktsbild av datornätverket.
5.1.3
Sensordatabehandling
Beräkning av blinklängd och blinkfrekvens Blinklängd beräknas genom att utnyttja pa-rametern blink från Smart Eye Pro som inkrementellt ökas med ett vid varje blinkning och sätts till noll när ingen blinkning pågår, samt datapunktens timestamp. För blinkfrekvensen mäts sedan antalet blinkningar under en minut. Indata läses från en Kafkatopic och publice-ras sedan till nya Kafkatopics för vidare analys och presentation i GUI:t.
Beräkning av hjärtslagsvarians (HRV) Hjärtslagssvariansen beräknas direkt i det Python-script som hämtar indata från Polar H7 pulssensor i Collector (NUC 1). Den beräknas med hjälp av insamlade RR-intevall från de senaste 60 sekunderna som sparas i en lista. Med hjälp av detta jämförs respektive intervall med medelvärdet av alla intervall i listan. Skillnaderna mellan intervallen och det uträknade medelvärdet används sedan genom att ta absolutbe-loppet på alla dessa värden och dela på antalet sampel, som i det här fallet är 60 då vi valt att hämta data från de senaste 60 sekunderna och Polar H7 har en uppdateringsfrekvens på ungefär 1 Hz.
Insamling av EEG-data Vid insamlingen av EEG-data med hjälp av Emotiv EPOC+ an-vänds funktionen IEE_GetAverageBandPowers från Emotivs Community SDK1och snab-ba variationer som misstänks vara störningar filtreras bort.
5.1.4
Bedömningsmodeller
För att dra slutsatser kring flygledarens status och hälsa används nedanstående bedömnings-modeller.
5.1.4.1 Hälsotillstånd
Med hjälp av kroppsburna sensorer mäter systemet vitalparametrarna blodtryck, kroppstem-peratur, hjärtfrekvens, andningsfrekvens och syresättning. Dessa används i en regelmotor som implementerar den poängbaserade hälsomodellen beskriven i kapitel 3.5.
