
Internet of things för optimerad och
smart prestationsutveckling

Kandidatarbete inom civilingenjörsutbildningen

vid Chalmers tekniska högskola

Einar Ingemarsson

Thomas Trinh

Frida Krohn

Jessica Preiman

Sattar Akbari

Filip Helmroth

CHALMERS TEKNISKA HÖGSKOLA

Göteborg, Sverige 2021

www.chalmers.se

www.chalmers.se


Kandidatarbete 2021

Internet of things för optimerad och
smart prestationsutveckling

TIFX04-21-81

Einar Ingemarsson ieinar@student.chalmers.se
Thomas Trinh ttrinh@student.chalmers.se
Frida Krohn krohnf@student.chalmers.se
Jessica Preiman preiman@student.chalmers.se
Sattar Akbari sattara@student.chalmers.se
Filip Helmroth helmroth@student.chalmers.se

Handledare
Magnus Karlsteen magnus.karlsteen@chalmers.se
Ali Tabrizi ali75tabrizi@gmail.com
Janne Wanhainen janne.wanhainen@ifkgoteborgfriidrott.com
Jeremy Pryce jeremy.pryce@ifkgoteborgfriidrott.com
Darko Sarovic darko@darkosarovic.com

Institutionen för fysik
CHALMERS TEKNISKA HÖGSKOLA

Göteborg, Sverige 2021


Internet of things för optimerad och smart prestationsutveckling
TIFX04-21-81
Einar Ingemarsson, Thomas Trinh, Frida Krohn, Jessica Preiman, Sattar Akbari, Filip Helmroth

© EINAR INGEMARSSON, THOMAS TRINH, FRIDA KROHN, JESSICA PREIMAN, SATTAR
AKBARI, FILIP HELMROTH, 2021.

Handledare: Magnus Karlsteen, Ali Tabriziali, Janne Wanhainen, Jeremy Pryce, Darko Sarovic
Examinator: Lena Falk, Institutionen för Fysik

Kandidatarbete 2021
Institutionen för fysik
Chalmers Tekniska Högskola
SE-412 96 Göteborg

Typsättning i LATEX, template by Magnus Gustaver
Göteborg, Sverige 2021


Internet of things för optimerad och smart prestationsutveckling

Förord

Denna rapport är ett resultat av ett projektförslag av tv̊a tränare fr̊an IFK Göteborg friidrott: Jeremy
Pryce och Janne Wanhainen. Vi vill tacka dem för deras idé och för deras fantastiska stöd och förtroende
under arbetets g̊ang. Vi vill även tacka dem för friheten vi fick att utveckla och styra riktningen p̊a
projektet åt det h̊all vi ans̊ag skulle vara mest till nytta för deras projektförslag.

Vi vill även tacka Ali Tabrizi som gett oss goda r̊ad för utecklandet av applikationen och som sett till att
alla har ett leende p̊a läpparna under handledningsmötena.

Vi vill även tacka Darko Sarovic för värdefulla reflektioner och ideér gällande teorin och studien, han har
varit mycket hjälpsam fr̊an start och genom hela arbetet.

Till slut vill vi tacka Magnus Karlsteen som alltid ställde upp och svarade p̊a v̊ara fr̊agor, b̊ade stora
som sm̊a. Vi vill ocks̊a tacka Magnus för det helhjärtade stödet och den positiva inställningen genom hela
projektet.


Internet of things för optimerad och smart prestationsutveckling

Sammanfattning

Den växande marknaden kring digitala hjälpmedel som smarta klockor och pulsband visar p̊a ett intresse
för individuell träningsoptimering. Denna rapport syftade till att ta fram en grundläggande prototyp av
en mobilapplikation med fokus p̊a att intuitivt presentera analyserad träningsdata för slutanvändaren
och en studie som jämförde prestationen mellan en matematiskt modell och maskininlärningsmodeller.
Projektet avgränsades till att använda existerande h̊ardvara och istället fokusera p̊a analys av data. Stu-
dien avgränsades till att inte ta hänsyn till försökspersonernas näringsintag eller sömn, med undantag för
antal sömntimmar. Applikationen strukturerades som en klientserverlösning där serversidan utvecklades
som ett REST-API i Python med ramverket Flask och applikationssidan utvecklades med hjälp av react
native. Studien genomfördes under 40 dagar med 6 försökspersoner med olika träningsbakgrund med ålder
23,2 ± 1,6 år. Samtliga skulle rapportera värden för rSPE varje dag och hade krav p̊a att träna minst 4
g̊anger i veckan med varierad intensitet. Datan fr̊an studien bearbetades för att sedan användas i tre mo-
deller: Banister-modellen och tv̊a maskininlärningsmodeller, en ANN-modell och en RNN-modell. MSPE
användes för att mäta modellernas förm̊aga att förutsäga HRV. Medelvärdet för MSPE ± standardav-
vikelsen blev för Banister-modellen 0, 066± 0, 052, för ANN och RNN blev det 0, 127± 0, 141 respektive
0, 05±0, 005. RNN p̊avisade ett tillräckligt l̊agt MSPE-värde utan att överanpassa datan och uts̊ags därför
som ett lämpligt alternativ till Banister-modellen som fick det lägsta MSPE men istället överanpassade
datan. Applikationen blev i huvudsak färdigställd men saknar en del önskad funktionalitet. Funktionalitet
som blev implementerad b̊ade i mobilapplikationen, servern och databasen var: användarhantering med
inloggning, inmatning av sRPE och HRV samt skapande av träningspass och uppvisning av förutsagt
HRV. Applikationen funkar som en prototyp som kan vidareutvecklas i kombination med ytterligare stu-
dier med längre tidsintervall och fler försökspersoner för att vidare undersöka möjligheterna med att
använda maskininlärning för träningsoptimering.

Abstract

The growing market for digital aids such as smart watches and heart rate monitors shows an interest in
individual training optimization. This report aimed to develop a basic prototype of a mobile application
with a focus on intuitively presenting analyzed training data to the end user and a study comparing
performance between a mathematical model and machine learning models. The project was limited to
using existing hardware and instead focused on data analysis. The study was limited to not taking into
account the subjects’ nutritional intake or sleep, with the exception of the number of hours of sleep. The
application was structured as a client server solution where the server side was developed as a REST API
in Python with the framework Flask and the application side was developed using react native. The study
was conducted over 40 days with 6 subjects with different training backgrounds aged 23.2 ± 1.6 years.
All were to report values for rSPE every day and were required to exercise at least 4 times a week with
varying intensity. The data from the study were processed and then used in three models: the Banister
model and two machine learning models, an ANN model and an RNN model. MSPE was used to measure
the models’ ability to predict HRV. The mean value of the MSPE ± standard deviation for the Banister
model was 0.066 ± 0.052, for ANN and RNN it was 0.127 ± 0.141 and 0.05 ± 0.005, respectively. RNN
demonstrated a sufficiently low MSPE value without over-adapting the data and was therefore designated
as a suitable alternative to the Banister model, which received the lowest MSPE but instead over-adapted
the data. The application was mainly completed but lacks some desired functionality. Functionality that
was implemented in both the mobile application, the server and the database was: user management with
login, input of sRPE and HRV as well as creation of training sessions and demonstration of predicted HRV.
The application works as a prototype that can be further developed in combination with further studies
with longer time intervals and more subjects to further investigate the possibilities of using machine
learning for training optimization.


Internet of things för optimerad och smart prestationsutveckling

Inneh̊allsförteckning

1 Inledning 1
1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Marknadsanalys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 Metodöversikt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Teori 2
2.1 Hjärtfrekvensvariabilitet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1.1 Faktorer som p̊averkar HRV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Kvantifiera träning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2.1 TRIMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.2 Session rating of perceived exertion . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3 Analys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.1 Banister-modellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.2 Artificiella neuronnät . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.3 Återkommande neuronnät . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.4 Jämföra modeller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Programvara och hjälpmedel 8
3.1 Git & GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Figma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 React Native . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Expo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5 Flask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.7 Elite HRV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.8 Anaconda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.9 Tensorflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Applikation 9
4.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.2.1 Databas och API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.2 Inloggningssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.3 Dataanalys och maskininlärning i applikationen . . . . . . . . . . . . . . . . . . . . 13
4.2.4 Inhämtning av data via externt API . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 Metod för studie 13
5.1 Urval av försökspersoner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2 Mätning av HRV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3 Mätning av träningsbelastning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4 Databearbetning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.4.1 Felinmatning av data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4.2 Sortering av data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4.3 Ofullständig data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4.4 Skalning av data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.5 Regressionsanalys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.5.1 Banister-modellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.5.2 ANN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.5.3 RNN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6 Resultat 20
6.1 Jämförelse av modeller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3 Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

7 Diskussion 25


Internet of things för optimerad och smart prestationsutveckling

7.1 Val av mätmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.2 Val av värde att förutsäga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.3 Tidsspann och datamängd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7.3.1 Urval av variabler i analysen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.3.2 Framtida studier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7.4 Server och databas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.5 Applikationens funktionalitet och vidareutveckling . . . . . . . . . . . . . . . . . . . . . . 27
7.6 Samhälleliga och etiska aspekter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Referenser 29

Appendix 31

A Applikationen 31

B Blankett för GDPR 39

C Enkäter för studien 40

D Resultat 42
D.1 Härledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43


Internet of things för optimerad och smart prestationsutveckling

Ordlista

Bias: Bias är maskininlärningsmodellens tendens att konsekvent lära fel.

Dashboard: En dashboard är en visuell och lättbegriplig sammanställning av viktiga funktioner för att
snabbt kunna f̊a en översikt [1].

Dokumentdatabas: En databas som lagrar data i dokumentformat.

Fitness: Fitness används för att beskriva hur vältränad en individ är.

Hashfunktioner: En matematisk algoritm som genererar ett binärt värde med en given längd för indata
med godtycklig längd. Vanligt förekommande när lösenord skickas över internet.

Homeostas: Homeostas är kroppens förm̊aga att h̊alla sig stabilt runt ett visst tillst̊and trots förändringar
i miljön. När man tränar utsätts kroppen för stress vilket rubbar den interna miljön. För att upprättah̊alla
homeostasen anpassar sig kroppen genom att reglera den interna miljön. Viktiga homestatiska mekanismer
är termoreglering, osmoreglering och reglering av blodsockerniv̊aerna.

Högniv̊aspr̊ak: Ett typ av programspr̊ak som är mer abstrakt och där programmeraren inte behöver
tänka p̊a flyttningsinstruktioner eller minnesaddresser.

Icke-relationsdatabas: En databas som sparar data p̊a ett flexibelt sätt i motsats till en relationsdatabas
där fokus ligger p̊a att lagra relationer mellan data.

Overfitting: En maskininlärningsalgoritm som har uppn̊att för hög precision för träningsdata s̊a att
algoritmens tillförlitlighet p̊a ny data är för l̊ag.

Kodbas: All källkod som utgör grunden för att kompilera och bygga ett program eller en applika-
tion.

Ramverk: Ett ramverk är ett färdigbyggt bibliotek av mjukvarukomponenter som kan användas till
specifika syften.

Rutnätsökning: En teknik som försöker räkna ut det kommande värdet utifr̊an värden som redan blivit
inmatade. När nya värden sedan matas in kontrollerar dessa att modellen gör rätt annars anpassar sig
modellen p̊a nytt [2].

Stressbiomarkör: En biomarkör är en mätbar biologisk parameter [3]. Detta innebär att en stressbio-
markör är en parameter som p̊averkas av stress. Träning usätter till exempel kroppen för en viss typ av
stress.

Träningstimulans: En träningsstimulans är en form av stress som kroppen utsätts för vid fysisk ak-
tivitet. Beroende p̊a intensiteten och varaktigheten av stressen kan kroppen reagera genom till exempel
muskeluppbyggnad eller neuronal anpassning, vilket leder till en förbättrad fysisk form.

VO2max: Maximum takt syre konsumerad medan träningen.


Internet of things för optimerad och smart prestationsutveckling

Akronymer

API: Application programming interface

ANN: Artificial neural network

ANS: Autonoma nervsystemet

AU: Arbitrary units

EMA: Exponential moving average

FPTT: Forward propagartion through time

HRV: Heart rate variability

HTTP: Hypertext transfer protocol

JSON: JavaScript object notation

LSTM: Long short-time memory

MLPRegressor: Multi layer perceptron regressor

MSE: Mean squared error

MSPE: Mean squared prediction error

MVP: Minimum viable product. Avser den minsta möjliga produkten som fortfarande skapar värde för
användaren.

NoSQL: Non structured query language

REST-API: Restful application programming interface.

RMSSD: Root mean square of the successive differences

RNN: Recurrent neural network

SQL: Structured query language

sRPE: Session rating of perceived exertion

TRIMP: Training impulse


sida 1 Internet of things för optimerad och smart prestationsutveckling sida 1

1 Inledning

Historiskt har personlig utveckling inom sport och idrott varit enbart beroende av tränares erfarenheter
och kunskap. P̊a senare tid med den digitala utvecklingens framfart har det dock blivit allt mer vanligt att
använda digitala hjälpmedel som till exempel smarta klockor. Dessa klockor har ofta möjlighet att mäta
b̊ade puls och ge återkoppling kring träningens belastning samt frekvens. Oavsett om m̊alet med träningen
är hälsa eller prestation finns det ett intresse av att försöka optimera resultaten, vilket bekräftas av den
växande marknaden för digitala hjälpmedel. En intressant fr̊ageställning är d̊a om man kan specificera
informationen fr̊an b̊ade tränare och digitala hjälpmedel p̊a ett sätt som är tillräckligt tillförlitligt.

För att ett resultat ska vara tillförlitligt krävs det att den underliggande datan har inhämtats med en
hög noggrannhet och att den har en bevisad p̊averkan p̊a resultatet. Det finns flera omr̊aden, bland annat
v̊ard och forskning, som idag är helt beroende av att arbeta med s̊adan data för att kunna dra tillförlitliga
slutsatser. Metoder som utandningsanalyser, blodprov och hjärtfrekvens används regelbundet och i forsk-
ningens framkant upptäcks allt fler metoder och värden som kan vara till nytta för att göra ytterligare
uttalanden. Med dessa värden som grund kan man med stora sannolikheter uttala sig om kroppens
välm̊aende. Därmed blir det även intressant ur ett träningsperspektiv att ta reda p̊a om samma typer
av värden kan ge betydelsefull information om träningsoptimering och skaderisker. För att kunna uttala
sig om en individs välm̊aende utifr̊an ett antal uppmätta värden krävs det ofta specialiserad utbildning,
vilket kan vara rimligt inom omr̊aden som v̊arden. När det istället gäller träningsoptimering vore det mer
relevant om en vanlig idrottare kunde f̊a ut samma typ av slutsatser med bibeh̊allen korrekthet.

I dagsläget finns det m̊anga olika typer av redskap för att mäta viktiga värden vid träning. Genom
mjukvara presenteras ofta mätvärden i tabeller och grafer, men värdet av dessa minskar utan specifik
kunskap kring hur tabellerna och graferna ska tolkas i relation till ett specifikt m̊al. Idén till detta projekt
uppstod i precis det tomrummet och syftar till att hitta en metod som kan ta dessa värden och presentera
analysering av dessa p̊a ett intuitivt sätt för varje individuell motionär.

1.1 Syfte

Syftet med projektet är att ta fram en grundläggande prototyp, en s̊a kallad minimum viable product
(MVP), i form av en mobilapplikation som kan hjälpa användaren att p̊a ett mer individualiserat sätt
f̊a respons p̊a sin träning. Detta genom att jämföra om modeller skapade med hjälp av maskininlärning
kan förutsäga fysisk form utifr̊an träningsrelaterad indata bättre än konventionella matematiska modeller.
Fr̊an resultatet av jämförelsen är syftet sedan att använda den bäst presterande modellen för att analysera
användarens träningsdata och presentera detta p̊a ett intuitivt sätt i applikationen. Målgruppen för
projektet innefattar alla fr̊an vardagsmotionärer till elitidrottare.

1.2 Avgränsningar

Eftersom det redan finns ett flertal produkter som tillsammans täcker ett brett spektrum av mätvärden,
avgränsas projektet till att använda befintlig h̊ardvara. Detta trots att projektet identifierat ett behov av
ny h̊ardvara i form av ett bärbart system för mätning av utandningsluft som kan bäras bekvämt under ett
träningspass. Beslutet togs med hänsyn till att utvecklandet av en s̊adan produkt med stor sannolikhet
skulle bli tidskrävande. Dessutom fastslogs att ett grundläggande system med fokus p̊a dataanalys och
användargränssnitt är mer värdeskapande för en MVP än en prototyp av ovannämnda h̊ardvara.

Sömn och näringsintag har stor inverkan p̊a en persons energiniv̊a och prestationsförm̊aga. Dock har
avgränsningar gjorts där analysen kommer samla in subjektiv data i form av sömntimmar men bortse
fr̊an all data kring näringsintag. Detta innebär att användaren svarar p̊a fr̊agor kring sin sömn istället
för att genomföra objektiva mätningar. Valet att bortse fr̊an näringsintag grundar sig i att datan kräver
detaljerad manuell inmatning fr̊an användaren, vilket sannolikt är för tidskrävande i förh̊allande till
dess p̊averkan p̊a analysen. Till skillnad fr̊an näringsintaget, kan mängden sömn och dess kvalité lättare
uppskattas samt matas in av användaren.

1.3 Marknadsanalys

Redan idag finns det flera applikationer som uppfyller liknande syfte som detta projekt vill uppn̊a.
Tjänsterna Strava, Runkeeper och Svettig är tre vanliga träningsapplikationer vars främsta syfte är att
skapa en social gemenskap kring träningen där man kan logga och dela sina träningspass med bekanta.


sida 2 Internet of things för optimerad och smart prestationsutveckling sida 2

Tjänsterna Polar Flow, Garmin Connect, EliteHRV och Apple Health är fyra applikationer som fokuserar
mer p̊a analysering av träningsdata och hur träning i kombination med återhämtning kan optimeras för
att producera bättre träningsresultat. Applikationen ämnar att bli en tjänst som b̊ade inkluderar den
sociala gemenskapen och den individuella prestationsutveckling. Därmed skulle den fylla ett identifierat
tomrum p̊a marknaden.

1.4 Metodöversikt

Detta projekt har genomförts i tv̊a huvudsakliga delar: en studie och utveckling av en applikation. Struk-
turen p̊a rapporten kommer därför beskrivas kort för att tydliggöra rapportens kapiteluppdelning. Först
presenteras teorin som ligger till grund för studien. Detta efterföljs av programvara och hjälpmedel som
beskriver verktygsval för utvecklandet av applikationen och analysverktyget. Utvecklingsprocessen för
applikationen beskrivs sedan i sin helhet. Metoden för genomförandet av studien presenteras därefter och
avslutningsvis presenteras resultat för b̊ade studien och utveckling av applikationen samt en diskussion
kring bägge dessa resultat.

2 Teori

En stor utmaning är att hitta balansen mellan träning och vila över längre tidsperioder där prestations-
utvecklingen maximeras och risken för överträning och skador samtidigt minimeras. Ett sätt att angripa
detta problem är att kartlägga en idrottares fitness och analysera hur den förändras över tid. Utifr̊an
dessa förändringar g̊ar det sedan att se om idrottaren f̊ar positiv eller negativ effekt p̊a sin utveckling
utifr̊an sitt aktuella träningsprogram [4]. Genom att undersöka effekterna kan det exempelvis avgöras om
idrottaren kan träna mer intensivt, vilket leder till en förbättrad prestationsutveckling, eller om idrotta-
ren behöver mer vila, d̊a en för hög träningsbelastning kan leda till en försämrad prestationsutveckling
och dessutom en högre risk för skador [5].

Det vanligaste sättet att kartlägga en idrottares fysiska form är att undersöka de olika typer av
träningsbelastning som idrottaren utsätts för under sitt träningsprogram. Träningsbelastning kan ka-
tegoriseras som antingen intern eller extern belastning [4]. Intern träningsbelastning omfattar alla stress-
biomarkörer som uppst̊ar vid fysisk ansträngning hos idrottare, b̊ade fysiologiska och psykologiska.
En stressbiomarkör är en mätbar bioligisk parameter som p̊averkas av stress och n̊agra exempel p̊a
stressbiomarkörer som är vanliga att mäta är puls, hjärtfrekvensvariabilitet och subjektiv upplevd fy-
sisk ansträning. Extern träningsbelastning avser istället objektiva mätningar som utförs p̊a den akti-
vitet idrottaren genomför. Detta inkluderar exempelvis mätning av acceleration, hastighet, kraft och
träningseffekt.

2.1 Hjärtfrekvensvariabilitet

Hjärtfrekvensvariabilitet (HRV) är en av de stressbiomarkörer som g̊ar att mäta för att f̊a en upp-
fattning av den interna träningsbelastningen. Värdet erh̊alls genom att mäta variationen mellan
hjärtslagens tidsintervall [6]. HRV p̊averkas av det autonoma nervsystemet (ANS) som reglerar krop-
pens grundläggande livsprocesser, till exempel puls, andning och matsmältning. ANS är uppdelat i tv̊a
delar: det sympatiska och parasympatiska nervsystemet [7]. Det sympatiska nervsystemet styr ener-
gikrävande uppgifter medan det parasympatiska styr över energisparande uppgifter. Dessa tv̊a system
motarbetar allts̊a varandra där större delen av det sympatiska systemet är ig̊ang när du exempelvis
tränar medan det parasympatiska är ig̊ang när du vilar och återhämtar dig. ANS:s primära funktion
är att alltid försöka beh̊alla homeostas genom reglering av olika kroppsfunktioner. När en idrottare
utsätter sin kropp för träningsstress under upprepade träningspass leder det till fysiologisk anpassning,
vilket innebär att den homeostatiska basniv̊an reduceras som respons. Följaktligen kan ANS:s respons till
ändring i träningsbelastning indikera kroppens förm̊aga att tolerera eller anpassa sig till träningsstimulans
[8].

HRV kan mätas med ett pulsband som är ett kostnadseffektivt, icke-invasivt och praktiskt sätt att upp-
skatta ANS reglering av pulsvariabiliteten. Värdet p̊a mätningen representerar summan av effekterna p̊a
det sympatiska och parasympatiska systemet i respons till b̊ade fysisk och psykologisk stimulans [9]. Detta
innebär att det sympatiska nervsystemet aktiveras när en individ utsätts för fysisk ansträngning, vilket
leder till en förhöjd puls och ett minskat HRV. När kroppen däremot f̊ar vila aktiveras det parasympatiska
systemet, vilket leder till en sänkt puls och ett högre HRV [10]. Trots att det finns tydliga fysiska och


sida 3 Internet of things för optimerad och smart prestationsutveckling sida 3

fysiologiska skillnader mellan idrottsutövare, ökar för närvarande användandet av HRV-mätningar inom
idrottsvetenskap för att bevaka idrottare [11].

2.1.1 Faktorer som p̊averkar HRV

Vid användning av HRV som ett mätvärde är det viktigt att fastställa vilka yttre faktorer som kan
p̊averka mätningen. Detta är framförallt viktigt när man ska analysera och dra vidare slutsatser utifr̊an
dessa värden genom att finna underliggande mönster samt förklara avvikelser i den insamlade datan.
N̊agra kända faktorer som p̊averkar HRV, men som en individ själv inte kan p̊averka är ålder, kön och
dygnsrytm. En individs HRV ökar fram tills cirka 15 års ålder och börjar sedan avta med åldern.

Man har observerat att försökspersoner i medel̊aldern följer HRV en periodisk dygnsrytm [6]. Observatio-
ner har visat att HRV-värdet minskar under förmiddagen och antar sina lägsta värden p̊a eftermiddagen
runt 15:00-18:00 för att sedan öka igen p̊a kvällen och antar sina högsta värden tidigt p̊a morgonen runt
3:00-5:00.

HRV kan ocks̊a p̊averkas av vilken miljö individiden befinner sig i. Detta beror p̊a att miljöfaktorer kan
leda till psykologisk stimulans vilket p̊averkar ANS. Exempelvis kan exponering för ljud leda till att det
sympatiska nervsystemets aktivitet ökar och därmed sjunker HRV-värdet [12]. P̊a samma sätt kan värme
sänka HRV-värdet genom en ökning av det sympatiska systemets aktivitet.

2.2 Kvantifiera träning

För att f̊a ett p̊alitligt värde p̊a idrottarens träningsbelastning är det viktigt att använda sig av flera olika
mätvärden d̊a enskilda värden riskerar att ge en felaktig bild. För att ytterligare addera värde kan sedan
varje värdes p̊averkan p̊a belastningen undersökas. Träningsbelastning p̊averkas huvudsakligen av tre
komponenter: varaktighet, träningsintensitet och träningsfrekvens [13]. Summan av dessa komponenter
kan beskrivas som en träningsstimulans. När det kommer till förbättring av prestationsförm̊aga är det
dock sv̊art att definiera gränsen mellan optimal och destruktiv träningsstimulans.

2.2.1 TRIMP

Ett av de mer populära sätten att kvantifiera träningsbelastning är att mäta hjärtfrekvensen hos
en idrottare under ett träningspass. Utifr̊an dessa värden kan sedan TRIMP-metoden användas
för att räkna ut träningsbelastningen genom att ta varaktigheten multiplicerat med förändringen i
hjärtfrekvens [14]. Förändringar i hjärtfrekvens uppst̊ar d̊a intensiteten förändras under ett träningspass,
där förväntningen är en högre hjärtfrekvens vid hög träningsintensitet och en lägre hjärtfrekvens vid l̊ag
träningsintensitet.

Genom att använda kontinuerlig pulsdata som sträcker sig över ett träningspass kan dessa värden sedan
matas in i ekvationen och producera en kvantifierad träningsbelastning. Detta d̊a hjärtfrekvens kan ses
som ett index p̊a utnyttjandet av sin maximala syrekonsumption.

Träningsbelastningen kan beräknas vid varje tidpunkt, t, genom att ta produkten av ett träningsmoments
varaktighet och förändring i hjärtfrekvens vid tiden t. Träningsbelastningen vid tiden t, kan därmed
representeras av pseudointegralen av ekvation (1).

w(t) = (varaktigheten av träningen) · HRex −HRvila

HRmax −HRvila
, (1)

där HRex är medelpulsen, HRvila är vilopulsen och HRmax är maxpulsen.

2.2.2 Session rating of perceived exertion

Session rating of perceived exertion (sRPE) är en metod för att mäta träningsbelastning där idrottaren
f̊ar ange upplevda värden p̊a träningsansträning. Denna metod, uppfunnen av Carl Foster, l̊ater idrottare
helhetsgradera ansträngingen av träningspasset 30 min efter passets slut [15]. Det ska helst inte graderas
tidigare än 30 min och inte heller l̊angt senare. Om träningsintensiteten graderas direkt efter träningen
finns en risk att graderingen endast reflekterar slutet av passet och inte hela passet. Att graderingen inte
bör ske för sent beror p̊a att en förlängd vila efter passet kan p̊averka graderingen ocks̊a. Därav ses 30
min som en lämplig tid för att graderingen ska reflektera hela passet [16]. Graderingen utförs utifr̊an
en skala mellan 6 och 20 som kan ses i tabell 1. Graderingen av passet, RPE, multipliceras sedan med


sida 4 Internet of things för optimerad och smart prestationsutveckling sida 4

varaktigheten av träningen vilket ger ett värde p̊a träningsbelastningen i en arbiträr enhet, se ekvation
(2).

Träningsbelastning = RPE · (varaktighet i minuter) (2)

Gradering Ansträngning
6 Extremt lätt
7 Extremt lätt
8 Extremt lätt
9 Mycket lätt
10 Mycket lätt
11 Lätt
12 Lätt
13 Ganska ansträngande
14 Ganska ansträngande
15 Ansträngande
16 Ansträngande
17 Mycket ansträngande
18 Mycket ansträngande
19 Extremt ansträngande
20 Maximalt ansträngande

Tabell 1: Tabell av Borgs RPE-skala.

2.3 Analys

Data kan analyseras med hjälp av olika matematiska modeller med förhoppning att finna samband. För
att hitta samband kan man utifr̊an valda parametrar använda sig av färdiga matematiska modeller eller
använda maskininlärning som letar efter matematiska samband som sedan kontinuerligt förbättras i takt
med att datamängden ökar.

2.3.1 Banister-modellen

Vid modellering av prestationsförm̊aga finns endast ett f̊atal färdiga modeller som är användbara. En
av dessa är impuls-responsmodellen som är uppkallad efter skaparen Banister. Denna har visat sig kun-
na förutsäga träningsinducerade träningsresponser p̊a prestationsförm̊aga med hyfsad exakthet i diver-
se uth̊allighetssporter och icke-uth̊allighetssporter [17]. Utifr̊an modellen har sedan förslag p̊a ideala
träningsprogram utarbetats där m̊alet varit att optimera förh̊allandet mellan träning och vila. Banister-
modellen modellerar relationen mellan träning och prestationsförm̊aga som en funktion. Indata represen-
teras av träningsstimulanser och utdata representerar idrottarens uppskattade prestation [17].

Funktionen beskrivs med hjälp av tv̊a faktorer g(t) och h(t), se ekvation (3) respektive ekvation (4).

g(t) = g(t− i)e−i/τ1 + w(t) (3)

h(t) = h(t− i)e−i/τ2 + w(t) (4)

Dessa ekvationer motsvarar fitness och utmattning för dagen t. g(t) representerar mer l̊angvariga och
positiva effekter fr̊an träningsstimulanser medan h(t) representerar kortvariga och negativa effekter av
träningen. w(t) är träningsbelastning, i är antalet vilodagar och τ1 samt τ2 är tidskonstanter som p̊averkar
hur snabbt funktionerna avtar.

Eftersom fitnessfaktorn har en positiv p̊averkan och utmattningsfaktorn har en negativ p̊averkan p̊a
prestation, kan man modellera prestationsutveckling med den linjära differensen i ekvation (5).

p(t) = k1g(t)− k2h(t), (5)


sida 5 Internet of things för optimerad och smart prestationsutveckling sida 5

där p(t) är prestationen vid tiden t och k1 samt k2 är positiva dimensionlösa viktkonstanter som är
relaterade till effekterna av respektive faktor. Idrottare med ett större k2 karaktäriseras av en utmatt-
ningsdominerad prestationutveckling, vilket innebär att det tar längre tid för dem att återhämta sig fr̊an
intensiv träning [17]. Idrottare med ett större k1 värde har däremot en fitnessdominerad prestationsut-
veckling vilket betyder att de återhämtar sig snabbare.

2.3.2 Artificiella neuronnät

Ett artificiellt neuronnät (ANN) är ett koncept som är inspirerat av biologiska neuronnät i hjärnan, där
flera självlärande algoritmer har som uppgift att i en mängd data leta efter mönster och samband [18].
Nätet best̊ar av ett flertal sammankopplade noder som ska representera hjärnans uppbyggnad av neuroner.
Fr̊an ett matematiskt perspektiv är ett neuronnät en matematisk funktion som tar in och klassificerar
information enligt ett specifikt nätverk [19]. Processen i ANN är väldigt lik processen i statistiska metoder
som regressionsanalys och interpolation.

Noderna i ett neuronnät delas in i flera olika lager där varje nod har en anpassningsbar parameter som
kallas för en vikt. Det första lagret tar in obehandlad data som viktas för att skickas vidare till nästa
lager som är dolt. Denna process upprepas sedan lika m̊anga g̊anger som det finns dolda lager för att
till sist resultera i ett eller flera slutvärden som utdata. P̊a detta sätt bildar noderna ett nätverk som
inneh̊aller nodernas relation till varandra, se figur 1.

Figur 1: Ett enkelt neuronnät med tv̊a noder för indata, fyra noder i ett dold lager och en nod för utdata.

Värdet i varje nod kan beräknas genom en linjärkombination där xi representerar individuella värden
fr̊an noder i det tidigare lagret med tillhörande vikt wi [20]. Vanligtvis justeras sedan detta värde med
hjälp av en aktiveringsfunktion f för att bestämma hur mycket information som ska skickas till nästa
nod. Exempel p̊a aktiveringsfunktioner är identitetsfunktionen, stegfunktionen och sigmoidfunktionen.
Dessa tv̊a steg tillsammans kallas ofta för fram̊atpropagering, se ekvation (6).

y(n) = f
( n∑
i=1

(xi · wi)
)

= f
(
(x1 · w1) + (x2 · w2) + ...+ (xn · wn)

)
, (6)

där xi är värdet fr̊an en nod i det tidigare lagret, wi är tillhörande vikt och f st̊ar för aktiveringsfunktionen.
Noderna i det sista lagret utgör resultatet och kan användas för att dra slutsatser om kopplingar i
datamängden, till exempel bildigenkänning eller att förutsäga värden utifr̊an en viss indata.

Nätverket tränas sedan utifr̊an ett dataset där vikterna justeras utifr̊an hur nära slutvärden stämde med
det faktiska värdet fr̊an datasetet [20]. Funktionen för att räkna ut felgraden i slutvärden kan definieras


sida 6 Internet of things för optimerad och smart prestationsutveckling sida 6

som ekvation (7).

E(n) =
1

2

∑
j

e2
j (n) =

1

2

∑
j

(
(dj(n)− yj(n)

)2
(7)

Där j är noderna i det sista lagret i datapunkten n med ej(n) = dj(n)− yj(n), d är m̊alvärdet och y är
nodens värde som beräknas i (6).

För att minska värdet p̊a felgraden används en process som kallas bak̊atpropagering där gradienten
dE/dwi av felgraden E beräknas och uppdateras för varje vikt wi och η är träningstakten för modellen,
se ekvation (8).

wi,new = wi,old − η
dE

dwi
. (8)

När värdet p̊a denna funktion anses vara tillräckligt minimerat kan nätverket ses som tränat.

2.3.3 Återkommande neuronnät

Återkommande neuronnät (RNN) är en typ av ANN som lämpar sig för att hitta mönster i sekventiell
data, som till exempel text och tidsserier [21]. Detta åstadkoms genom att varje nod i RNN-modellen inte
bara f̊ar indata fr̊an tidigare lager, utan även återkoppling fr̊an tidigare iterationer i beräkningsstegen.
S̊aledes kan modellen lära sig hur sekventiella värden samverkar. Detta kan jämföras med ett vanligt
neuralt nätverk där ingen återkoppling sker [21].

Figur 2: En återkommande neuronnät med N tidenheter

Arkitekturen för en RNN-modell visas i figur 2 [22]. Under ett tidssteg, t, tas indatavektorn Xt samt det
tidigare tillst̊andet ht−1 och skapar det nya tillst̊andet ht genom aktiveringsfunktionen (Φ). Detta visas i
ekvation (9) [23]. Vid tillst̊and 0, h0, existerar det inget tillst̊and än och s̊aledes initieras tillst̊andet med en
tom vektor. Utdatan fr̊an RNN-modellen, yN , f̊as genom ekvationen (10) och sker via fram̊atpropagering
[23]. Denna typ av RNN-modell klassificeras som en many-to-one, vilket innebär att indatan best̊ar av
flera tidsobservationer medan utdata endast erh̊alls i den sista tidpunkten [24].

ht = f(xt, ht−1) = Φ(W xhxt +Whhht−1 + bh) (9)

yt = Whyht + by (10)

I ekvationerna 9 och 10 finns även tv̊a biases, nämligen bh och by. Ett bias är ytterligare en parameter
som uppdateras medans neuronnätet kaliberaras. En RNN-modell har tre olika samlingar av vikter: W xh,
Whh och Why, som kan ses i ekvation (9) och (10). Dessa vikter representerar olika tillst̊and och fungerar
som filter för att bestämma hur stor vikt indatan (xt) respektive tillst̊andet (ht−1) ska f̊a. Felet som
genereras justeras genom bak̊atpropagering vid varje iteration. En iteration innebär att algoritmen g̊ar


sida 7 Internet of things för optimerad och smart prestationsutveckling sida 7

igenom och justerar alla vikter en g̊ang, vilket leder till att felmarginalen minskas [24]. Felet beräknas
genom en förlustfunktion, L, enligt ekvation (11) [21].

L =

N∑
i=0

li =

N∑
i=0

f(yi, ŷi) (11)

Förlustfunktionen kan anpassas till RNN-modellens syfte, och är en funktion av y och ŷ. Dessa juste-
ras via bak̊atpropagering där algoritmen stegvis g̊ar tillbaka genom tidsenheterna och justerar vikter-
na. Följaktligen blir RNN-modellen mer och mer kalibrerad och felmarginalen minskar [21]. Ett vanligt
återkommande problem med RNN benämns vanishing gradient och exploding gradient [21]. I detta fallet
syftar gradienten p̊a den term som uppdaterar vikten Whh, vilket kan ses i figur 2 och visas i ekvation
(12) [24].

∇ =
∂L(ŷ, y)

∂W
(12)

Gradienten definieras som kvoten mellan förändringen i felmarginal genom förändring av vikten i
föreg̊aende beräkningssteg . Blir gradienten för stor resulterar det i att vikterna uppdateras för snabbt.
Blir gradienten för liten riskerar vikterna att uppdateras för l̊angsamt [21]. En vedertagen lösning till pro-
blemet är Long Short Time Memory (LSTM), vilket är en typ av RNN [25]. Arkitekturen p̊a en LSTM-
modell är väsentligt mer komplex där man lägger till ytterligare en tredje tillst̊ands-input [21].

2.3.4 Jämföra modeller

För att avgöra hur bra en matematisk modell presterar krävs att en uppsättning av data delas upp
i en träningsuppsättning och en testuppsättning. Träningsdata används för att träna modellen medan
testdata används för att utvärdera modellens prestation. Vanliga delningsförh̊allanden är 80/20, 67/33,
50/50. Där 80/20 betyder att 80% av datan används för uppträning och 20% av datan används för
testning.

Vid utvärdering av modeller kan m̊attet mean squared prediction error (MSPE) användas, vilket mäter
modellernas förm̊aga att förutsäga rätt värde. Idealt ska värdet vara noll vilket innebär att modellen har
lyckats förutsäga de verkliga värdena. MSPE beräknas med ekvation (13).

MSPE =
1

n

n∑
1

(yi − ŷi)2 (13)

En annat m̊att som kan användes för att jämföra modeller är korrelationskoefficient r [26]. Detta m̊attet
kan appliceras p̊a träningsperioden för att kvantifiera hur bra modellen passar träningsdatan. Koeffici-
enten antar ett värde mellan −1.0 och +1.0. Ett r-värde p̊a +1 innebär att datan passar perfekt medan
−1 har en inverterad korrelation.


sida 8 Internet of things för optimerad och smart prestationsutveckling sida 8

3 Programvara och hjälpmedel

Flera olika programvaror och hjälpmedel användes under arbetets g̊ang för att möjliggöra och förenkla
olika processer samt för att underlätta samarbete. Samtliga av dessa beskrivs kort tillsammans med en
förklaring till varför de behövdes.

3.1 Git & GitHub

För att slippa spara kod manuellt och h̊alla reda p̊a vilken version som är rätt används Git som är ett
verktyg för versionshantering. Med hjälp av Git kan man se till att all kodhistorik dokumenteras och
sparas. Detta innefattar även vem som har skrivit eller tagit bort specifika kodrader i kodbasen. När Git
används i kombination med Github, som är en online-plattform för att lagra kod, kan kodbasen lagras i
molnet och därmed förenklas processen att dela kod mellan programmerare.

3.2 Figma

Som prototypverktyg och grafikredigeringsprogram valdes Figma. Bakgrunden till valet var Figma:s
möjligheter att samarbeta med andra personer i realtid, att skapa interaktiva prototyper och att dessa
kan köras i en mobiltelefonsimulator. I prototypen kan man även navigera mellan de olika sidorna som om
den vore en färdig applikation. Detta underlättar nästa projektfas, d̊a applikationen ska programmeras,
eftersom det finns en klar bild över vad som ska åstadkommas.

3.3 React Native

Ramverket som valdes var React Native och använder sig av programmeringsspr̊aket JavaScript. React na-
tive är anpassat för att förenkla processen att utveckla mobilapplikationer. För att skapa en lättillgänglig
applikation bör den finnas tillgänglig för b̊ade iOS- och Androidanvändare, vilket React Native tar hand
om genom att agera som en egen plattform som internt hanterar kodomvandlingen till respektive opera-
tivsystem. Detta innebär att kodbasen därför bara behöver skrivas en g̊ang i ramverkets spr̊ak. Detta blev
extra viktigt d̊a projektet var tidsbegränsat och det därför inte fanns möjligthet att skapa tv̊a separata
applikationer.

3.4 Expo

Expo är ett ramverk som gör det enkelt att testa applikationen via b̊ade webbläsaren och mobiltelefonen,
där det senare möjliggörs via en specifik app: Expo Go. Vidare s̊a möjliggör expo att applikationen upp-
dateras i realtid samtidigt som programmeringskoden ändras utan att applikationen i sig behöver startas
om. Syftet med att använda expo var att underlätta och öka hastigheten p̊a skapandet av applikatio-
nen.

3.5 Flask

Flask är ett ramverk som förenklar programmeringen av servern. Flask är skrivet för programmerings-
spr̊aket Python och underlättar utvecklingen av serverapplikationen och specifikt hur API:t kan struktu-
reras. Programmeringsspr̊aket Python är ett väldokumenterat högniv̊aspr̊ak som har ett stort utbud av
standardiserade funktioner och bibliotek. Ramverket Flask fungerar väl att integrera mot React Native,
vilket beskrivs i avsnitt 3.3.

3.6 MongoDB

MongoDB är en icke-relationsdatabas, s̊a kallad non Structured Query Language (NoSQL), vilken lagrar
data p̊a ett sätt som är optimerat för de specifika kraven som applikationen har. Denna typ av databas
möjliggör skalbarhet, smidig utveckling och hög flexibilitet jämfört med en traditionell relationsdatabas,
Structured Query Language (SQL). Skalbarheten var en av nyckelfaktorerna till valet av denna modell.
Genom att fr̊an start använda en skalbar databas möjliggörs att applikationen i framtiden enkelt kan
addera nya datastrukturer utan att behöva bygga om databasen. P̊a grund av säkerhetsskäl, vilket vi
återkommer till i avsnitt 4.2.2, valde vi att bygga tv̊a separerade databaser för användaruppgifter och
hälsodata.


sida 9 Internet of things för optimerad och smart prestationsutveckling sida 9

Databasen implementeras genom applikationen MongoDB Atlas vilket är en extern molnbaserad doku-
mentdatabas som kan driftsättas p̊a valfri molnplattform. MongoDB har inbyggd funktionalitet för att
strukturera upp data effektivt och optimera arbetsbelastningen. Den skapar även en flexibilitet d̊a den
kan hantera multipla förfr̊agningar parallellt, vilket är fördelaktigt d̊a flera användare ska kunna använda
applikationen samtidigt.

3.7 Elite HRV

Elite HRV är en applikation som mäter och analyserar hjärtvariabiliteten. Applikationen är kompatibel
med flera befintliga pulssensorer, vilket förenkelar mätningar och uppföljning av dagliga HRV-mätningar
till studien. Dessa mätningar är en förutsättning för att kunna göra de analyser som beskrivs i avsnitt
5.2.

3.8 Anaconda

Anaconda är en komplett plattform för dataanalys i programmeringsspr̊aket Python. Anaconda inneh̊aller
flera förinstallerade proagramvarubibliotek som används för dataanalys och statistik. Programvarubiblio-
teken som användes fr̊an Anaconda var främst NumPy, Scikit-Learn, Pandas, SciPy och Matplotlib.

3.9 Tensorflow

Tensorflow är ett heltäckande programvarubibliotek för maskininlärning som är skapad av Google. Tensor-
flow erbjuder ett programvarubibliotek som kan träna och köra neurala nätverk vilket används i projektet.
Keras är en modul som körs ovanp̊a Tensorflow och bidrar med ett användarvänligt gränssnitt för att
kunna arbeta med programvarubiblioteket Tensorflow.

4 Applikation

För att kunna utnyttja studien och dess resultat behövs verktyg för att lagra resultaten fr̊an analysen,
samt ett sätt att redovisa den för användaren. Därför väljer detta projekt att även fokusera p̊a att skapa
en server och en applikation för att kunna kommunicera med användaren.

Applikationens syfte är att ge användaren ett lätt och enkelt sätt att f̊a översikt över sin träning och
prestationsutveckling. För att åstadkomma detta bör applikationen vara intuitiv att hantera och först̊a,
den ska allts̊a kunna visa resultatet fr̊an analysen p̊a ett sätt som är lätt att tyda. I applikationen ska det
finnas möjlighet att starta och logga träningspass för att efter̊at visa lämplig feedback samt en funktion att
kunna se tidigare träningspass. I applikationen kommer även användarens subjektiva data tas in.

4.1 Design

För att skapa en intuitiv design för applikationen krävs att användarflödet är väl genomtänkt. Den
första planeringen gjordes helt i text och fungerade som en utg̊angspunkt för designen. Dess syfte var att
logiskt kunna sortera alla önskade funktioner s̊a att designen kunde utformas därefter, detta b̊ade för att
göra applikationen lättnavigerad samt se till att den uppfyller önskad funktion. I steget efter skapades en
prototyp av applikationen i Figma vilket gav en tydlig bild över designen och underlättade skapandefasen.
Ännu en fördel med att ha en prototyp var att skapa en större medvetenhet kring designen. När först̊aelsen
ökar kring navigation i applikationen kan den skapas p̊a ett sätt där den beter sig s̊a som användaren
förväntar sig.

Applikationen delades in i fem huvudsidor: dashboard, aktivitet, historik, profil samt en sida för grupper
och organisationer. Sidorna kodades separat och kopplades sedan till varandra via en rad ikoner som
fungerar som applikationens huvudmeny.

Applikationens dashboard ses i figur 3. Dashboarden finns till för att användaren ska ha en god översikt
p̊a sin träninghistorik, subjektiva data och m̊al. Utöver detta kan användaren se dagens datum, vad
vädret är just nu och fylla i sin subjektiva data.

Nya träningspass startas p̊a aktivitetssidan som ses i figur 4, där finns möjlighet att välja vilka h̊ardvaror
man vill använda och ansluta dessa via bluetooth. När en aktivitet sedan startas visas ett nytt fönster


sida 10 Internet of things för optimerad och smart prestationsutveckling sida 10

med en knapp där användaren kan pausa respektive fortsätta passet. Utöver detta g̊ar det även att avsluta
passet samt se ett tidtagarur med träningens varaktighet.

Figur 3: Figmaprototypens dash-
board.

Figur 4: Figmaprototypens sida
för p̊ag̊aende aktivitet.

Historiksidan delas upp i tre flikar, ett flöde, en översikt och tidigare värden. Flödet visar en lista med
information över de tidigare passen s̊a som dess givna namn, tid och datum för utförande. Även data
fr̊an eventuell kopplad h̊ardvara kan visas, s̊a som genomsnittligt tempo eller snittpuls. Historikflödet kan
ses i figur 5. Översikten har en m̊anadskalender som markerar de dagar där aktiviteter har genomförts.
Under samma flik finns även statistik för m̊anaden som visar antal loggade pass, loggade timmar och hur
m̊anga dagar användaren uppfyllt respektive m̊al. Under tidigare värden kommer bland annat HRV för
de olika dagarna synas.

Profilsidan, som syns i figur 6, finns d̊a användaren behöver ha en profil för att applikationens server
ska kunna lagra information om användaren. P̊a denna sida kan användaren ställa in sina m̊al, lägga
in en profilbild, redigera kontoinformation samt b̊ade importera och exportera data till respektive fr̊an
applikationen.


sida 11 Internet of things för optimerad och smart prestationsutveckling sida 11

Figur 5: Figmaprototypens his-
torikflöde.

Figur 6: Figmaprototypens pro-
filsida.

P̊a gruppsidan finns möjligheten att skapa en ny grupp och se alla grupper användaren är med i, denna
sida syns i figur 7. Det finns tv̊a olika typer av grupper: kompisgrupp och organisation. En kompisgrupp
är till för att användare ska kunna dela sin träning med varandra och även kunna sätta gemensamma
m̊al, hur en s̊adan kan se ut syns i figur 8. En organisation är till för att tränare för olika idrottslag och
träningsgrupper ska kunna följa sina adepters träning och värden. Skillnadena mellan dessa grupper är
att i en kompisgrupp kan alla se varandras träningspass och värden, samt deras individuella bidrag till
gruppm̊alen. I en organisation däremot är de bara tränaren som ser träningspassen och värdena, samt
kan ändra inställningarna i gruppen. Adepterna i en organisation kan se vilka som är med i gruppen och
se sitt personliga träningsprogram som tränaren skrivit in.

Figur 7: Figmaprototypens gru-
ppsida.

Figur 8: Figmaprototypens sida
d̊a en grupp valts.

4.2 Server

Systemet implementerades med en klientserverlösning enligt figur 9. Klienterna kommunicerar med ser-
vern genom API-anrop. Servern kommunicerar sedan med den externa databasen där all information


sida 12 Internet of things för optimerad och smart prestationsutveckling sida 12

ligger lagrad. Denna arkitektur ans̊ags skapa en bra skalbarhet för applikationen och är en väl beprövad
arkitektur.

Figur 9: Figuren visar den övergripande systemarkitekturen och hur de olika komponenterna kommunicerar.

Utvecklingen av servern skedde parallellt med klientsidans mobilapplikation. Fokus för servern l̊ag p̊a att
implementera de mest systemkritiska funktionerna, vilket innefattade databashantering och utveckling
av standardiserade API-anrop. Därefter fortskred arbetet med att sammankoppla klientsidan med ser-
vern, dataprocessering samt att inhämta träningsdata fr̊an externa tjänster likt Strava. Tjänsten Strava
förklaras mer utförligt i avsnitt 4.2.4.

4.2.1 Databas och API

Servern använder sig av en icke-relationsdatabas där fördelarna har beskrivits utförligt i avsnitt 3.6.
Databasen lagrar dokument i JSON-format vilket är lätthanterligt b̊ade för servern och klienten. Detta
formatet visualiseras i figur 10 och kan förklaras som ett nyckel-till-värde-par. Varje textnyckel refere-
rar till ett specifikt värde. Formatet gör att det är snabbt och enkelt att extrahera specifik data ur
databasen.

Databasen strukturerades i tv̊a övergripande kategorier: hälsodata och användaruppgifter. Hälsodatan
best̊ar av b̊ade individuell träningsdata, HRV och upplevd träningsbelastning. Bakgrunden till den
inhämtade datan beskrivs i avsnitt 5.2 och 5.3. Figur 10 visar hur ett datainsamlingsformulär är lagrat
i databasen. Användaruppgifterna som lagras i databasen har tv̊a syften: Dels att lagra vilka användare
som finns i systemet, men ocks̊a för att ge korrekt behörighet till hälsodatan som finns lagrad. Dessa syf-
ten ledde till att vi valde att implementera ett inloggningssystem, vilket beskrivs mer utförligt i avsnitt
4.2.2.

1 {

2 "stress_level": 3,

3 "muscle_ache": 4,

4 "mood_level": 10,

5 "hrv": 84,

6 "injury_level": 2,

7 "date": "2021-04-01",

8 "energy_level": 5,

9 "sleeping_hours": 8

10 }

Figur 10: Exempel p̊a en JSON-fil som sparat en användares ”mätning av hjärtfrekvensvariablilitet” enkät i
databasen.

För att möjliggöra enkel och flexibel kommunikation mellan servern och flera klienter parallellt beslutades
det att ett API skulle användas. Detta var en förutsättning för att slutprodukten i framtiden ska kunna
fungera över internet och att användarna ska kunna utnyttja applikationen via sina personliga mobila
enheter. Valet föll p̊a att implementera ett s̊a kallat REST-API. I praktiken betyder det att klienten är
separerad fr̊an servern och datalagringen, vilket innebär att servern inte vet vad som sker hos klienten
och vice versa. Ett REST-API till̊ater klienten att hämta och manipulera specifik data i databasen genom
standardiserade API-anrop. Hur ett API-anrop implementeras kan ses i tabell 2. Ramverket Flask, som


sida 13 Internet of things för optimerad och smart prestationsutveckling sida 13

nämndes i avsnitt 3.5, används för att hantera anropen fr̊an klienten. De anrop som kommer fr̊an klienten
kan liknas vid en stig som leder till att ett visst kodstycke p̊a servern exekveras.

URI Metod Beskrivning
Länk till API:t Typ av API-anrop Förklaring av API-anropet

Tabell 2: Exempel p̊a hur API-anrop kommer implementeras p̊a servern.

För att minska belastningen p̊a klientens processorkapacitet strukturerades applikationen genom att all
databearbetning sker p̊a serversidan. P̊a s̊a vis kan arbetsbelastningen och laddningstiden reduceras för
användaren vilket resulterar i en snabb och responsiv applikation.

4.2.2 Inloggningssystem

För att kunna autentisera att ett API-anrop kommer fr̊an en behörig användare krävs det att servern
har kunskapen kring vilken användare som har rätt till vilken data. I databasen lagras information
om användarens inloggningsuppgifter vilket möjliggör att servern kan verifiera varje API-anrop fr̊an
användaren. Följaktligen skickas känslig data endast till behöriga användare.

D̊a lösenordet lagras i databasen krävs det specifika säkerhets̊atgärder utifall n̊agon obehörig skulle f̊a
tillg̊ang till databasen. Modulpaketet hashlib implementerades, vilket inneh̊aller ett flertal hashfunktioner
för Python. Dessa funktioner krypterar användarens lösenord innan de sparas i databasen, vilket gör att
vid ett obehörigt intr̊ang eller vid stöld av databasen skulle lösenorden vara obrukbara, se figur 11. För
detta projektet användes hash-funktionen pbkdf2 sha256 [27].

1 {

2 "name": "John Doe",

3 "email": "john@doe.com",

4 "password": "$pbkdf2-sha256$291120$Wh"

5 }

Figur 11: Exempel p̊a en JSON-fil som sparat inloggningsuppgifter med ett krypterat lösenord i databasen.

4.2.3 Dataanalys och maskininlärning i applikationen

För att presentera förutsägelsen av morgondagens HRV körs dataanlaysen, som beskrivs i avsnitt 5.5,
i servern. Varje g̊ang en ny datapunkt fr̊an användaren registeras i databasen uppdateras den indivi-
duella maskininlärningsmodellen och s̊aledes kan den tränas p̊a ett större dataset och ge mer träffsäkra
förutsägelser. När klienten efterfr̊agar den individuella HRV-förutsägelsen returnerar servern detta via
sitt API.

4.2.4 Inhämtning av data via externt API

Som tidigare beskrivits i avsnitt 4.1 ville applikationen kunna presentera historisk träningsdata p̊a ett
intuitivt sätt till användaren. D̊a databasen innehöll f̊a träningspass behövdes fler importeras externt.
Träningstjänsten Strava har över 73 miljoner användare och används av flera i projektgruppen [28]. Syf-
tet med Strava är att kunna lagra historiska träningspass och dela dessa med andra Strava-användare.
Strava tillhandah̊aller ett öppet API, motsvarande det API som utvecklats i servern, vilket möjliggör att
historisk individuell träningsdata kan hämtas fr̊an Strava och sedan lagras i databasen. Detta API imple-
menterades i servern och en användare kan s̊aledes f̊a sin historiska träningsdata fr̊an Strava presenterad
i mobilapplikationen.

5 Metod för studie

Målet med projektet är att ta reda p̊a om de g̊ar att hitta samband fr̊an olika värden för att kunna opti-
mera individens prestationsutveckling, för att ta reda p̊a detta valde vi att göra en studie. Denna studie
är tänkt att bygga vidare p̊a en tidigare studie som endast använde Banister-modellen för att undersöka


sida 14 Internet of things för optimerad och smart prestationsutveckling sida 14

om HRV-responser, som en representativ markör för träningsadaption, kan förutsägas utifr̊an elite rub-
gy idrottares träningsbelastningar [29]. Syftet med denna studien är att undersöka om neurala nätverk
som ANN och RNN kan förutsäga HRV-responser bättre än Banister-modellen genom att inkludera fler
variabler. Det genomfördes genom att försökspersonerna under 40 dagar rapporterade in olika variabler i
form av dagliga mätvärden. De primära variablerna var träningsintensitet och träningens varaktighet för
att beräkna träningsbelastning. D̊a HRV p̊averkas av andra externa faktorer, se avsnitt 2.1, inkluderades
även variablerna sömntimmar, stressniv̊a, humör, muskelvärk, energiniv̊a och skador i ANN och RNN
modellerna för att förutsäga HRV-responser.

5.1 Urval av försökspersoner

För denna studie rekryterades sex stycken försökspersoner, fem män och en kvinna i ålder 23.2 ± 1.6
år, längd 177.5 ± 3.9 cm samt vikt 71.3 ± 7.0 kg, där värdet efter ± är standardavvikelsen. Fyra
av försökspersonerna är författare till denna rapport och de tv̊a resterande är närst̊aende till en av
författarna. Fem av deltagarna är sedan tidigare aktiva idrottare medan en utav dem tränar sporadiskt.
Deltagarna tränade badminton (n = 1), släggkastning (n = 1), löpning (n = 2), gym (n = 3), bas-
ket (n = 2) och boxning, (n = 2), där vissa även tävlade aktivt. Kravet för att delta i studien var
att försökspersonerna skulle genomföra n̊agon form av fysisk aktivitet under 40 dagar med minst fyra
träningspass i veckan. Inget krav p̊a vilken typ av fysiskt aktivitet sattes s̊a länge aktiviteten gav n̊agon
grad av träningsstimulans. Ett krav som formulerades var dock att försökspersonerna skulle variera inten-
siteten p̊a sina pass minst tv̊a g̊anger i veckan för att träningsstimulansen inte skulle vara likadan vid varje
pass under de 40 dagarna. Huruvida detta uppn̊addes genom att förlänga eller förkorta träningspasset,
höja intensiteten eller sätta in ytterligare ett pass var upp till försökspersonerna själva.

5.2 Mätning av HRV

Försökspersonerna instruerades att utföra en mätning av HRV under 60 sekunder varje morgon direkt
när de hade vaknat. De skulle avst̊a fr̊an att titta p̊a mobilen, äta, dricka eller röra sig hastigt för
att eliminera s̊a m̊anga externa faktorer som eventuellt kunde p̊averka mätningen av HRV. Mätningen
skulle genomföras oavsett om de hade tänkt träna den dagen eller inte. För att utföra mätningarna
användes antingen Polar H7 eller Polar H10 Bluetooth pulsband1 kopplat till den fritt tillgängliga mobi-
lapplikationen2. Försökspersonerna fick själva välja vilken position de utförde mätningen i, där alterna-
tiven var liggande, sittande eller st̊aende. Ett krav var dock att försökspersonerna skulle fortsätta utföra
mätningarna i samma position under hela studiens g̊ang. Mätningen utfördes genom att sätta pulsbandet
runt bröstet och följa instruktionerna i Elite HRV för utföra en HRV-mätning. Under denna mätning
skulle försökspersonerna vara s̊a avslappnade som möjligt och andas naturligt. Efter mätningen skulle
de svara p̊a en enkät, se första enkäten i appendix C, där de fyllde i HRV-värdet, antalet sömntimmar,
stressniv̊a, skador, humörniv̊a, muskeltrötthet och energiniv̊a. Alla parametrar, förutom HRV-värdet och
sömntimmar, graderades mellan 0-10.

Efter att studien p̊ag̊att i en vecka beslutades att ändra mättiden fr̊an en minut till tre minuter. Detta
berodde p̊a att den tidigare mättiden inte gav tillräckligt med tid för HRV-värdet att stabilisera sig och
därmed ibland gav avvikande värden.

Efter att mätningen är klar utför Elite HRV n̊agra uträkningar, exempelvis Root mean square of the
successive differences (RMSSD), se ekvation (14).

RMSSD =

√√√√ 1

N − 1

(
N−1∑
i=1

((R−R)i+1 − (R−R)i)
2

)
(14)

RMSSD ska reflektera variansen i hjärtfrekvensen och användes som en primär mätform för att uppskatta
förändringar i HRV. Det har allts̊a p̊avisats vara den mest p̊alitliga mätformen för HRV [30]. Utöver att
använda RMSSD valdes även att log-transfomera RMSSD data med naturliga logaritmen d̊a det reducerar
variabilitet i data och därmed gör det enklare att tolka värdena [31].

1En produkt av Polar Electro, Kempele, Finland
2En applikation av Elite HRV, Ashville, North Carolina, USA


sida 15 Internet of things för optimerad och smart prestationsutveckling sida 15

En uträkning av det exponentiella glidande medelvärdet (EMA) av ln RMSSD utfördes, se ekvation
(15).

EMA = ln RMSSD(t) · k + EMA(t− 1) · (1− k) (15)

där t är idag, t− 1 är g̊ardagen, N är tidsspannet och k = 2/(N + 1).

Den fyrtionde exponentiella glidande medelvärde användes. För N = 40 ger ln RMSSD40−exp vil-
ket är m̊attet som användes i kommande analyser (se avsnitt 5.5) som en representativ markör för
träningsadaption [29]. Vi kommer använda ln RMSSD istället för ln RMSSD40−exp för att underlätta
läsbarheten.

5.3 Mätning av träningsbelastning

De träningsbelastningar som försökspersonerna genomförde mättes med hjälp av en modifierad sRPE-
metod med en skala p̊a 0-10, se tabell 3, för att underlätta graderingen för försökspersonerna.
Försökspersonerna svarade p̊a en enkät efter varje träningspass där de fyllde i träningsintensiteten som
graderades p̊a en skala 0-10, samt träningstyp, varaktighet och energiniv̊an efter passet. Detta skulle helst
utföras 30 min efter varje pass. Om försökspersonerna tränade flera g̊anger om dagen behövde de skicka
in separata enkäter för varje träningspass. Det krävdes även att de skickade in en enkät p̊a vilodagar där
man endast graderade 0 p̊a träningsintensiten. Försökspersonerna fick även instruktioner att använda sig
av ett tidtagarur för att säkerställa den exakta längden p̊a passet.

Gradering Ansträngning
0 Vila
1 Mycket lätt
2-3 Lätt
4-5 Ganska ansträngande
6-7 Ansträngande
8-9 Mycket ansträngande
10 Maximalt ansträngande

Tabell 3: Tabell av Borgs modifierade RPE-skala.

5.4 Databearbetning

I denna studie studerades insamlad data för att hitta samband mellan olika parametrar och HRV. För
att säkerställa att den insamlade datan är kompatibel för modellerna samt analys s̊a behövde datan bli
bearbetad. Databearbetning är en essentiell del för att kunna se tillförlitliga mönster som inte beror p̊a
exempelvis slumpen. Det kan vara värden som inte är inom det till̊atna intervallet, exempelvis varak-
tigheten i negativt antal minter eller orimliga datakombinationer om värdet är ifyllt i fel spalt, samt
saknade värden. Att analysera data utan att ha proaktivt bearbetat datan kan leda till att man f̊ar
missvisande resultat. Med andra ord är det ytterst viktigt att datakvaliteten är hög, speciellt vid maski-
ninlärningsprojekt där stora mängder data används för att träna modellen. Databearbetning är uppdelat
i fyra steg, se figur 12.


sida 16 Internet of things för optimerad och smart prestationsutveckling sida 16

Figur 12: Systemarkitektur över databearbetning samt regressionsanalys för ANN och RNN.

För att kunna bearbeta den insamlade data användes huvudsakligen biblioteken Pandas och NumPy.
Pandas användes för att enkelt kunna läsa in och hantera datamängder medan NumPy användes för att
hantera arrayer och enkelt kunna utföra beräkningar p̊a de.

Insamlingen av data skedde genom enkäter där data lagrades i tv̊a separata datafiler, en som fylldes i
efter träningspassen och en för uppmätt HRV, se appendix C.

5.4.1 Felinmatning av data

Felinmatning av data kunde endast förekomma i tre utav fr̊agorna. Det berodde p̊a att de flesta fr̊agorna
i formulären använde skalor fr̊an 0-10, se appendix C. Det som försökspersonerna behövde skriva in själva
var sitt namn, typ av träning och varaktigheten av träningspasset. För att hantera felinmatning av namn
genomfördes korrigeringar manuellt.

När det kommer till inmatning av varaktigheten p̊a passen instruerades försökspersonerna att mata in
det i antal minuter. Om de tränade i 100 minuter skulle de fylla in ”100” i formuläret. Däremot förekom
exempelvis att försökspersonerna matade in ”100 min”, ”100 minuter” eller ”1:40”. Initialt korrigerades


sida 17 Internet of things för optimerad och smart prestationsutveckling sida 17

det manuellt men valdes sedan att lösas genom att skriva en funktion som undersökte datamängden och
konverterade datan till den önskade typen.

5.4.2 Sortering av data

Data för alla försökspersoner samlades in i en tabell. För att analysera respektive försöksperson krävdes
det att datan sorterades in i separata tv̊adimensionella datastruksturer. En av dessa innehöll värdena
för HRV, stress, humör med flera samt en för träningsintensitet och varaktighet av träningspass. Det vi
undersökte i studien var om träningsbelastningen, stress, humör med flera p̊averkade morgondagens HRV-
mätning. Datumen som automatiskt registreras när en enkät skickas in användes för att matcha HRV-
värdet till den korresponderade träningsbelastningen. Det förekom att försökspersoner glömde skicka in
antingen enkäten för träningspasset eller för mätning av HRV. Detta hanterades genom att ha med fr̊agan
”Träningsdag” i enkäten ”Hur var din träning”. Därmed kunde försökspersonerna skicka in enkäten för
ett träningspass dagar efter genom att välja vilken dag träningspasset genomfördes. För HRV mätningen
krävdes det däremot att det skickas in samma dag.

5.4.3 Ofullständig data

Om försökspersonerna hade skickat in en enkät utan att svara p̊a alla fr̊agor tilldelades ett null-
värde för den information som saknades. För att hantera de saknade värdena användes metoden
medelvärdesimputering. Det innebär att man ersätter det saknade värdet hos en variabel med me-
delvärdet av de observerade värdena för samma variabel [32]. Ett annat alternativ var att ta bort
raderna med null-värden helt men p̊a grund av de begränsade tidsspannet av studien s̊a användes me-
delvärdesimputering.

5.4.4 Skalning av data

För modellerna ANN och RNN är det viktigt att den data som de tränas och testas p̊a inte har för stor
variation d̊a det kan leda till lärningsprocessen i neuronerna g̊ar l̊angsamt eller har sv̊art att lära sig
[33]. Dessutom ser skalningen till att variabler med olika enheter bidrar med lika mycket till regressions-
analysen. Exempelvis kan träningsbelastningen anta värden upp till 1000 om en försöksperson graderar
träningsintensiteten till 10 och träningen varar i 100 min medan värden för energiniv̊a, stress, humör
etc. antar värden mellan 0-10. I v̊ar analys väger alla variabler lika mycket och därmed valdes det att
skala alla indata variabler med Min-Max skalning [34]. Det valdes specifikt att skala till intervallet [0, 1]
d̊a variablerna endast antar icke-negativa värden. Det gjordes genom att utg̊a fr̊an formeln i ekvation
(16).

x′ =
x−min(x)

max(x)−min(x)
(16)

där x är det originala värdet, x′ är det skalade värdet, min(x) och max(x) är det minsta respektive största
värdet som x kan anta.

5.5 Regressionsanalys

För alla tre modeller valdes delningsförh̊allandet 75% till träningsdata och 25% till testdata. Med 40 data-
punkter per försöksperson blev det 30 datapunkter för att träna upp modellen och sedan 10 datapunkter
för att utföra förutsägelserna. För studien som tidigare hade modellerat träningsbelastning och HRV
användes delningsförh̊allandet 50% där 28 datapunkter användes till träningsdata och 28 datapunkter
användes till testdata [29]. Eftersom vi hade färre datapunkter ans̊ag vi att 20 datapunkter var för lite och
därmed tränades modellen upp p̊a 30 datapunkter. Figur 12 visar i andra boxen hur regressionsanalysen
kommer g̊a till för neuronnäten.

5.5.1 Banister-modellen

Banister-modellen som beskrivs i avsnitt 2.3.2 modellerar relationen mellan träningsbelastning (indata)
fr̊an pulsdata och prestationsutveckling (utdata) vid löpning. Denna studie har istället valt att modellera
relationen mellan idrottarnas subjektiva gradering av träningsbelastning (indata) och HRV (utdata), där
vi använde mätformen ln RMSSD, utifr̊an samma Banister-modell [29]. Detta implementeras i Python
genom att utg̊a fr̊an ekvationerna (3), (4) och (5).


sida 18 Internet of things för optimerad och smart prestationsutveckling sida 18

Fr̊an ekvation (3) och (4) s̊a sattes fitness och trötthetsfaktorn till att vara

g(t) = g(t− i)e−i/τ1 + s(t) (17)

respektive

f(t) = f(t− i)e−i/τ2 + s(t) (18)

där s(t) är den upplevda träningsbelastningen som försökspersonen har genomg̊att vid tiden t, där tiden
mäts i dagar. Trötthetsfaktorn valdes att beskrivas med f(t) istället för h(t) d̊a h(t) är tänkt att beskriva
HRV i nedanst̊aende del.

P̊a samma sätt ändrades ekvation (5) till

h(t) = h0 + k1g(t)− k2f(t) (19)

där h(t) är HRV vid tiden t med ett intialt värde h0 p̊a HRV. En omskrivning (see appendix D.1 för
härledningen) ger att

h(t) = h0 + k1

t−1∑
i=1

s(i)e−(t−i)/τ1 − k2

t−1∑
i=1

s(i)e−(t−i)/τ2 (20)

Modellen karaktäriseras, som tidigare nämnts, av tv̊a förändringstermer (k1 och k2), tv̊a tidskonstanter (τ1
och τ2) och ett initialt HRV-värde h0. Dessa parametrar bestämdes genom att minimera medelkvadratfelet
(MSE) mellan den estimerade och den uppmätta HRV. Det vill säga

MSE =
1

n

n∑
t=1

(ht − ĥt)2 (21)

minimerades där ht är det uppmätta HRV och ĥt är den förutsagda HRV-värdet.

För att minimera ekvation (21) användes optimize fr̊an paketet SciPy som minimera objektiva funk-
tioner genom att lägga in ett initial värde. En rutnätssökning användes p̊a de första 30 dagarna för att
erh̊alla värdena för parametrarna. De intiala värdena togs fr̊an studien som tidigare hade modellerat
träningsbelastning och HRV [29]. Förändringstermerna k1 och k2 sattes till 7.67 · 10−5 AU respektive
8.93 ·10−5 AU där de inte ingick i rutnätssökningen d̊a MSE inte p̊averkades av de. För τ1 och τ2 testades
värden mellan 0-50 dagar för att sedan erh̊alla värdena i tabell 4 vilket gav det lägsta MSE. De estimerade
parametrarna användes sedan för att förutsäga ln RMSSD-värdena de 10 efterföljande dagarna.

Försöksperson # h0 τ1 τ2
1 4.2 4 9
2 3.9 49 32
3 4.0 46 43
4 2.7 45 16
5 4.2 15 2
6 4.8 2 6

Tabell 4: Tabell över parametrarna för varje försöksperson till Banistermodellen

5.5.2 ANN

För ANN-modellen användes maskininlärningsalgoritmen Multi-Layer Perceptron (MLP). MLP är den
mest grundläggande versionen av ett fram̊atpropagerande ANN och best̊ar av åtminstone tre lager av
neuroner: ett inputlager, ett eller flera dolda lager och ett utdatalager. Figur 13 visar det neurala nätverket
som tränades.


sida 19 Internet of things för optimerad och smart prestationsutveckling sida 19

Figur 13: Figuren illustrerar det artificiella neuronnätet som användes för studien.

För att optimera algoritmen sattes parametrarna initialt till solver till ’lbgfs’, activation till ’relu’ och
max iter til 1500. Parametern hidden layer sizes itererades mellan 1 till 50 för varje enskild individ och
värdet som minimerade respektive förlustfunktion valdes, se tabell 5.

Individ # Antal dolda lager
1 44
2 8
3 49
4 47
5 15
6 4

Tabell 5: Tabell över antalet dolda lager som minimerade förlustfunktionen för respektive individ.

5.5.3 RNN

RNN-modellen som implementerades beskrevs i avsnitt 2.3.3. Träningsdatan bearbetades enligt avsnitt
5.4 och delades upp i vektorer om sju dagar var. Anledningen till valet av sju dagar var d̊a det existerande
datasetet hade ett begränsat antal datapunkter fr̊an projektets studie. S̊aledes analyserar RNN-modellen
indatan i en period av sju dagar för att förutsäga dagens HRV-värde. Detta illustreras i figur 14 där data
fr̊an Xmån till Xsön förutsäger HRV-värdet HRVsön. Respektive indata , Xt, bestod av en vektor med
elementen [Träningsbelastning, Sömn, Stress, Muskelvärk, Skador, Energi, Humör ].

Datasetet delades upp i tränings- respektive testdata där RNN-modellen kunde tränas och valideras.
RNN-modellen är ett objekt fr̊an klassen sequential i Keras. Klassen sequential möjliggör att olika lager
kan sammanfogas i en och samma RNN-modell. Den tränade modellen konstruerades med nio lager:

• 4 LSTM -lager med 100, 50, 20 respektive 10 neuroner vardera.

• 4 dropout-lager som slumpmässigt droppar 20% av enheterna i de första 3 LSTM-lagren.

• 1 dense-lager som förutsäger HRV värdet för den sista tidsenheten.


sida 20 Internet of things för optimerad och smart prestationsutveckling sida 20

Figur 14: Diagrammet illustrerar RNN modellen som används för studien

Funktionaliteten som dropout-lagret bidrar med är att minska risken för att modellen överanpassar sig
till träningsdatan, s̊a kallad overfitting. Dense-lagret är ett lager där alla neuroner i lagret är kopplat till
alla neuroner i det föreg̊aende lagret och används för att kunna förutsäga utdatan.

För att kalibrera RNN-modellen s̊a itererade modellen över olika parameterval. Optimeringen av RNN-
modellen utvärderades genom att minimera felmarginalen samt att modellens förutsägelser följer den
verkliga utdatan. Kalibreringen resulterade i att aktiveringsfunktionen sattes till ’huber loss’ och antalet
iterationer var optimalt vid 5-15 stycken.

6 Resultat

Arbetet resulterade i en jämförelse mellan olika modeller för att förutse HRV i kombination med en
mobilapplikation som bland annat kan visa användarens träningspass och förutsp̊adda HRV. De tv̊a
delarna kopplas ihop med en server som hämtar, beräknar och skickar data. Resultatet av projektet är
en plattform som till̊ater forsatt vidareutveckling.

6.1 Jämförelse av modeller

Resultatet fr̊an de tre olika modellerna Banister, ANN och RNN visas i figurerna 15, 16 och 17. I respektive
figur presenteras även den uppmätta ln RMSSD-datan för försöksperson #2, #4 och #5. De resterande
försökspersoners resultat finns att se i Appendix D. Den svarta sträckade linjen i figurerna delar upp
träningsdata fr̊an testdata. Mellan dag 0 och 30 har respektive modell tränats upp för att sedan förutsäga
värden för de 10 resterande dagarna.

Försöksperson #2 är idrottaren som tränade sporadiskt innan studien. För #2 visas ln RMSSD-värden
i figur 15. Uppmätta värden för ln RMSSD, som representeras av de röda cirklarna, stiger de första tre
dagarna för att sedan avta fram till dag 7. Detta mönster ser ut att upprepa sig över de 40 dagarna.
För ANN syns en tydlig överanpassning till träningsdatan medan Banister och RNN följer träningsdata
relativt bra hela 40 dagarsperioden, se r-värden i tabell 7. När modellerna använder testdata för att
förutsäga ln RMSSD ser vi att ANN presterar markant bättre än RNN och Banister-modellen. ANN lyckas
f̊anga mönstret av ln RMSSD mellan dag 30-37 för att sedan underestimera de resterande punkterna. ANN
presterar därmed bäst av de tre modellerna, se tabell 6 för en mer detaljerad jämförelse av MSPE.


sida 21 Internet of things för optimerad och smart prestationsutveckling sida 21

Figur 15: Uppmätt ln RMSSD för försöksperson #2 visas tillsammans de tre modellerna Banister, ANN och
RNN.

Försöksperson # Banister ANN RNN
1 0.00061 0.00173 0.00030
2 0.00810 0.00150 0.00721
3 0.01080 0.06457 0.03569
4 0.00702 0.12867 0.05252
5 0.00478 0.00614 0.00155
6 0.00913 0.00138 0.00036

Tabell 6: Jämförelse av MSPE för Banister-, ANN- och RNN-modellerna för varje försöksperson.

Försöksperson # Banister ANN RNN
1 -1.57 0.98 0.44
2 0.24 0.83 0.58
3 0.68 0.99 0.78
4 0.87 0.99 0.82
5 0.73 0.35 0.82
6 0.41 0.87 0.45

Tabell 7: Jämförelse av r-värde för Banister-, ANN- och RNN-modellerna för varje försöksperson.

Försöksperson #4 är en av idrottarna som tränade regelbundet innan studien. För #4 visas ln RMSSD-
värden i figur 16. De uppmätta ln RMSSD minskar de första 5 dagarna för att sedan öka fram till dag 40.
Jämfört med Figur 15, observerar vi att Banister-modellen för försöksperson #4 f̊angar mönstret i den
uppmätta ln RMSSD relativt bra för träningsdatan. Däremot ser vi att ANN överanpassas i hög grad
till träningsdatan medan RNN-modellen tydligt överestimerar, se tabell 7. För testdata observerar vi att
ANN:s förm̊aga att förutsäga ln RMSSD är underm̊alig. För RNN förutsp̊as att ln RMSSD ska minska
de 10 sista dagarna när de i själva verket stiger. Det trenden lyckas Banister f̊anga relativt bra med en
minimal överestimation efter dag 35, se tabell 6 för en mer detaljerad jämförelse av MSPE.


sida 22 Internet of things för optimerad och smart prestationsutveckling sida 22

Figur 16: Uppmätt ln RMSSD för försöksperson #4 visas tillsammans de tre modellerna Banister, ANN och
RNN.

Försöksperson #5 är ocks̊a en av idrottarna som tränade regelbundet innan studien. För #5 visas
ln RMSSD-värden i figur 17. Den uppmätta ln RMSSD saknar ett tydligt mönster, dock observeras en
tydlig minskning mellan dag 10 och 15 för att sedan ökas fram till dag 30. Endast RNN-modellen lyckas
finna trenden p̊a träningsdata, dock i form av överanpassning, se tabell 7. För testdata förutsäger RNN
relativt bra de första 6 dagarna för att sedan överestimera resterande dagarna. Anpassningsgraden för
ANN-modellen till träningsdata är avsevärt sämre jämfört med försöksperson #2 och #4 vilket f̊ar mo-
dellen att överestimera markant p̊a testdata. Banister-modellen tränas heller inte tillräckligt vilket f̊ar
den att underestimera p̊a testdatan.

Figur 17: Figur över uppmätt ln RMSSD för försöksperson #5 utritad tillsammans de tre modellerna Banister,
ANN och RNN.

En jämförelse av MSPE för alla tre modellerna för varje försöksperson visas i Figur 18. För fyra av
försökspersonrna #1, #3, #4 och #5 observeras att ANN är sämst p̊a att förutsäga ln RMSSD av de
tre modellerna. För försöksperson #1, #5 och #6 observeras att alla modeller har l̊agt MSPE där RNN
presterade bäst för dessa tre försökspersoner, se tabell 6.

Genom att ta medelvärdet av MSPE för alla sex försökspersoner observeras att av de tre modellerna har
Banisters förutsägelser lägst felmarginal, RNN näst lägst och ANN högst, se tabell 8. För träningsdata
uppvisade ANN- och RNN-modellerna höga korrelationer mellan modellerat och uppmätt ln RMSSDexp

medan Banister-modellen hade relativt l̊aga r-värden, se tabell 9.


sida 23 Internet of things för optimerad och smart prestationsutveckling sida 23

Figur 18: Histogram över MSPE för alla tre modellerna Banister, ANN och RNN för varje försöksperson.

Banister ANN RNN
MSPE 0.006± 0.020 0.034± 0.048 0.016± 0.020

Tabell 8: Jämförelse av med hjälp av standardavvikelse µ± σ av MSPE för varje modell.

Banister ANN RNN
r 0.20 0.84 0.64

Tabell 9: Jämförelse mellan medelvärdet av r-värde för varje modell.


sida 24 Internet of things för optimerad och smart prestationsutveckling sida 24

6.2 Server

Kommunikation mellan klient och server sker via API-anrop och de funktioner som implementerades
visas i tabell 10. Datan som lagras i databasen i MongoDB hämtas och modifieras i servern för att
sedan skickas till klienten. Servern byggdes som ett REST-API vilket möjliggör att flera klienter kan
hanteras parallellt. Servern implementerades i Python med hjälp av ramverket Flask. B̊ade API-anrop
och serversvar strukturerades i JSON-format, vilket är ett format som b̊ade servern och klienten enkelt
kan tolka. Validering av data fr̊an klienten sker p̊a serversidan, vilket exempelvis säkerställer att samma
träningsformulär inte kan laddas upp tv̊a g̊anger i databasen.

API för autentisering
URI Metod Beskrivning
/signup POST Registrera en ny användare i databasen.
/login POST Autentiserar användaren via matchning av uppgifter i databasen.

API för formulär
URI Metod Beskrivning
/api/form/stats GET Hämtar individens morgonformulär fr̊an databasen.
/api/form/stats POST Postar individens morgonformulär till databasen.
/api/form/stats DELETE Tar bort ett specifikt morgonformulär fr̊an databasen.
/api/form/stats/hrv GET Hämtar en individs specifika HRV-värde fr̊an databasen.
/api/form/stats/all/hrv GET Hämtar individs alla HRV-värden fr̊an databasen.
/api/form/training GET Hämtar individens träningsformulär fr̊an databasen.
/api/form/training POST Postar individens träningsformulär till databasen.

API för aktiviteter
URI Metod Beskrivning
/api/activities GET Hämtar en individs träningspass fr̊an databasen.
/api/activity POST Postar en individs träningspass till databasen.

API för grupper och organisationer
URI Metod Beskrivning
/api/group GET Hämtar alla medlemmar i en specifik grupp fr̊an databasen.
/api/user/group POST Skapar en ny grupp och adderar en individ till gruppen.
/api/user/group GET Hämtar alla grupper som en individ är medlem i.
/api/organisation GET Hämtar alla medlemmar i en specifik organisation fr̊an databasen.
/api/user/organisation POST Skapar en ny organisation och adderar en individ till organisationen.
/api/user/organisation GET Hämtar alla organisationer som en individ är medlem i.
/get png GET Hämtar logon till gruppen/organisationen fr̊an databasen.

API för att hämta predikterat HRV
URI Metod Beskrivning
/ml/neural GET Hämtar morgondagens predikterade HRV-värde, baserat p̊a ANN.

API för inhämtning av data fr̊an Strava
URI Metod Beskrivning
/strava/authorize GET Autentiserar användaren s̊a att data kan hämtas fr̊an Strava.
/strava/connect POST Sammankopplar existerande träningsdata med data fr̊an Strava.
/strava/athlete GET Hämtar individens användaruppgifter i Strava fr̊an databasen.
/strava/athlete all GET Hämtar alla individer som har lagrat data fr̊an Strava i databasen.

Tabell 10: Tabell över alla API-anrop som implementerades p̊a servern.

6.3 Applikation

Majoriteten av alla planerade sidor blev implementerade i applikationen. En del funktionalitet saknas
men visuellt sett är den huvudsakligen färdig. Servern och applikationen är ihopkopplade vilket bland
annat möjliggör användarhantering och inloggning. Efter inloggning visas dashboarden som kan visa
datum och temperatur i realtid utifr̊an användarens fysiska plats. Dashboarden inneh̊aller information
om morgondagens förväntade HRV och möjlighet att navigera till en ny sida där sRPE och HRV kan
fyllas i. Denna data skickas sedan till servern som analyserar och sparar datan i databasen. Dessa värden
finns sedan tillgängliga under historiksidan. Applikationen kan ocks̊a l̊ata användaren starta ett nytt
träningspass som sparas i servern när det har avslutats och finns sedan tillgängligt under historiksidan.
I dagsläget mäter träningspasset endast tid.

En del önskad funktionalitet blev inte färdigställd. Grupper best̊aende av olika användare kan skapas
och visas men det finns ingen möjlighet att förändra vilka användare som ing̊ar i en grupp. Däremot


sida 25 Internet of things för optimerad och smart prestationsutveckling sida 25

kan ett flöde av medlemmarnas kombinerade aktiviteter visas i datumordning. Profilsidan visar hur olika
personliga m̊al kan se ut och ska inneh̊alla information om användaren, dock finns ingen koppling mellan
denna sida och servern.

7 Diskussion

Det primära syftet med studien var att undersöka om ANN och RNN är bättre än Banister-modellen
p̊a att förutsäga ln RMSSD genom att inkludera parametrar som träningsbelastning, sömn, stress, mus-
kelvärk och humör. Målet med att skapa en applikation var att skapa en plattform med möjlighet till
intuitiv information utifr̊an analysering av användarens träningsdata. D̊a utveckling av applikationen och
genomförandet av studien gjordes parallellt innebar detta att dessa delar inte alltid var kompatibla med
varandra under arbetets g̊ang. I följande underavsnitt kommer först studien diskuteras kring metodval,
resultat och jämförelse med resultat fr̊an andra studier. Sedan diskuteras implementationen av server,
databas och applikation följt av etiska aspekter.

7.1 Val av mätmetod

Som vi beskrev i avsnitt 2.2 finns det en rad olika sätt att mäta träningsbelastning för en idrottare, där
träningsbelastning delas upp i extern och intern belastning.

TRIMP-metoden anses vara tillförlitlig d̊a den använder ”objektiv data” och var en kandidat vid val av
mätmetod, där planen var att mäta puls under olika träningspass. En nackdel med att mäta puls är dock
att detta inte alltid reflekterar träningsbelastning där ett exempel är löpning gentemot styrketräning.
S̊aledes lämpar sig TRIMP främst vid aktiviteter med kontinuerlig puls som till exempel cykling och
löpning. Detta skulle ha resulterat i att antalet tillgängliga försökspersoner skulle ha begränsats fr̊an sex
stycken till tv̊a stycken. sRPE är en annan metod som kan appliceras inom diverse idrottsaktiviteter och
till̊ater en större mängd idrotts- och sportaktiviteter, vilket skulle till̊ata alla tillgängliga försökpersoner
att delta i studien. En nackdel är att mätningar med sRPE har sv̊arare att uppfatta förändringen i
hjärtfrekvens för extremt intensiv träningsbelastning vilket ger en mätning som inte är tillförlitlig. En
avvägning gjordes därför mellan antalet försökspersoner till studien och tillförlitligheten av mätningarna.
Det är däremot n̊agot som är värt att studera vidare p̊a hur olika mätmetoder som TRIMP eller en
mätning av träningsbelastning som hastighet med hjälp av GPS kan användas för att förutsäga HRV-
responser. Det som däremot är värt att nämna att sRPE metoden är b̊ade ett kostnadseffektivt val och
tillräckligt tillförlitligt [15]. Om man har begränsade resurser eller tillg̊angar kan sRPE vara ett utmärkt
val.

7.2 Val av värde att förutsäga

D̊a modellering av träning, träningsprogram och förh̊allandet mellan träning och vila är ett omr̊ade med
stor utvecklingspotential är det litterära underlaget begränsat. Den mest populära modellen att använda
för detta är Banister-modellen, som finns beskriven i 2.3.1. Ett problem med att använda prestationutveck-
ling som värde att förutsäga är att det skulle ha krävt ett flertal träningspass med maximal ansträngning
[17]. D̊a flera av försökspersonerna inte hade möjlighet att göra stora förändringar i sina träningsscheman
var följdaktligen prestationutveckling inte lämpligt som värde att förutsäga. Det slutliga valet blev att
använda HRV, vilket inte krävde n̊agon typ av förändring p̊a befintliga träningsscheman.

7.3 Tidsspann och datamängd

Studien genomfördes med 6 försökspersoner och p̊agick under 40 dagar. En datapunkt per person och dag
samlades in oavsett om de tränade eller inte. De begränsade antalet datapunkter p̊averkade storleken p̊a
träningsdatan, vilket vanligtvis är en hämmande faktor för inlärning av en modell. För att matematiskt
modellera träningsbelastning och prestationsutveckling argumenterar Morton för att 60-90 datapunkter
är att föredra [17].

För Banister-modellen observerades i studien en anpassningsgrad p̊a r = 0.2. För de individuella
försökspersonerna varierade r-värdena mellan −1.57 till 0.8735. Det observerade värdet fr̊an projek-
tets studie var lägre än värdet som Williams et al. (2018) uppmätte till r = 0.66 när elitrugbyspelare
studerades. Banister-modellen antar ett lägre medelvärde p̊a anpassaningsgraden p̊a grund av det l̊aga


sida 26 Internet of things för optimerad och smart prestationsutveckling sida 26

r-värdet (r = −1.57) för försöksperson #1. För de andra försökspersonerna erhölls relativt höga korrela-
tioner mellan den modellerade och uppmätta ln RMSSD i enlighet med studien av Williams et al. (2018).
Fördelen med en maskininlärningsmodell jämfört med Banister-modellen är att den kan ta hänsyn till
fler parametrar.

ANN-modellen och de uppmätta ln RMSSD hade en hög anpassningsgrad p̊a r = 0.84. Detta in-
dikerar att modellen är överanpassad till träningsdatan. Överanpassning kan leda till en försämrad
förutsägelseförm̊aga, vilket kan vara en förklaring till varför Banister f̊ar ett lägre medelvärde för MSE än
ANN trots att ANN använder fler parametrar. Det som däremot är positivt med ANN-modellen jämfört
med Banister är att desto mer data som används desto bättre kan den tränas för att inte överanpassa
och därmed kunna göra bättre förutsägelser p̊a ny indata [35].

Trots en begränsad mängd av träningsdata s̊a presterade RNN-modellen relativt bra jämfört med
Banister- och ANN-modellen. Detta kan förklaras av att RNN-modellen i studien använde flera ob-
servationer i en tidsekvens av 7 dagar för att förutsäga HRV. HRV p̊averkas, vilket nämns i avsnitt
2.1, av b̊ade livsstils- och miljöfaktorer. Till exempel kan den fysiologiska effekten av muskelvärk och
energiniv̊a fr̊an träningspassen ackumuleras över tid där inte bara g̊ardagens muskelvärk, energiniv̊a
och träningsbelastning p̊averkar dagens HRV utan även tidigare dagar kan p̊averka [36]. Därav anses
RNN, som tar hänsyn till tiden, vara ett lämpligt val för att undersöka hur de olika parametrar som
träningsbelastning, muskelvärk, energiniv̊a etcetera kan p̊averka HRV. Med fler datapunkter g̊ar det
ocks̊a att mata in fler tidssekvenser och använda ett längre tidsspann för att eventuellt f̊a ett bättre
resultat.

Även om Banister gav lägst MSPE s̊a är r = 0.2 för l̊agt för att kunna f̊anga komplexiteten i HRV-
responser vilket medför underanpassning till träningsdatan och därmed troligen d̊alig förutsägelseförm̊aga
av nya HRV-responser [37]. Däremot s̊a har RNN ett relativt l̊agt MSPE med tillräckligt högt r-värde
för att med tillräckligt noggranhet förutsäga HRV-responser. Det vill säga för försökspersonerna med
positiva r-värden och l̊aga MSE kan en upptränad RNN-modell förslagsvis användas som alternativ för
att förutsäga framtida HRV-värden.

7.3.1 Urval av variabler i analysen

Att välja vilka variabler man vill inkludera i analysen är kritiskt för resultatet. Det kan förekomma att
vissa variabler i modellen resulterar i bias eller s̊a kan värdena bidra till att modellen presterar bättre
men detta kan vara av slump. P̊a grund av tidsbrist samt att tv̊a undersökningar p̊agick samtidigt i denna
studien s̊a valdes att inkludera alla variabler som undersöktes i studien för nerronnät modellerna. I fram-
tida arbeten kan en välja att analysera vilka variabler som bidrar till en försämrad förutsägelseförm̊aga
av modellerna för att exkludera de fr̊an analysen.

7.3.2 Framtida studier

Syftet med detta projekt fr̊an början var att analysera den insamlade datan och hitta ett sätt att optimera
idrottarens träning baserad p̊a n̊agra parametrar. Datainsamlingsprocessen tog l̊ang tid och det ledde till
att en del undersökningar som var planerade inte blev av. En tanke var att se om man kan p̊averka en
individs HRV genom att justera parametrar s̊asom sömn och träningsbelastning. Nästa dags HRV skulle
kunna förutsägas genom att mata in olika värden för sömn och träningsbelastning i modellen och sedan
välja ut de värden som leder till högst HRV. Vi kunde inte genomföra en s̊adan studie p̊a grund av
tidsbrist samt att den mängd data som samlades inte var tillräcklig för att göra tillförlitliga förutsägelser.
Detta kan vara värt att studera i en framtida studie där man har mer data samt tid för att validera
resultatet.

Ett annat intressant omr̊ade att undersöka vidare kring hur modellerna kan simulera effekterna av olika
träningsprogram p̊a HRV för att objektivt kunna planera hur en atlet som rehabiliterar fr̊an en skada
bör sätta upp sin träning [38].

7.4 Server och databas

Målet med servern och databasen uppfylldes under projektets g̊ang. Även om slutresultatet blev önskvärt
hade en tydligare planering av databasens struktur effektiviserat arbetet. Nya krav och funktioner
upptäcktes under utvecklingens g̊ang vilket medförde att databasen behövdes struktureras om. Exem-


sida 27 Internet of things för optimerad och smart prestationsutveckling sida 27

pelvis krävde inhämtningen av data fr̊an Strava, som beskrivs i avsnitt 4.2.4, att aktivitetsdatan i den
befintliga databasen strukturerades om för att matcha formatet.

Istället för ramverket Flask kunde ramverket Django ha använts för att bygga serverarkitekturen. B̊ada
ramverken bygger p̊a programmeringspr̊aket Python. Fördelen med Django är att ramverket är mer
komplett för större applikationer, dock kräver det mer kunskap och initial konfiguration. Om målet med
projektet varit en storskalig plattform med hög kapacitet skulle Django s̊aledes varit ett bättre alternativ.
Valet föll dock p̊a Flask som kunde driftsättas snabbare. Det faktum att serverarkitekturen inte behövde
ändras under utvecklingens g̊ang visar p̊a att den valda arkitekturen var korrekt fr̊an start.

Implementationen av servern tog längre tid än planerat som en följd av gruppens begränsade erfarenheter
inom API-utveckling samt programmering med Flask. Följaktligen gick en stor andel av utvecklingstiden
åt till att inhämta kunskap. Gruppen är enig kring att implementationsfasen inte kunde utförts snabbare
d̊a kunskap kring andra serverlösningar saknades vid start. Förbättringspotentialen ligger i planeringsfa-
sen, där projektplanen borde tagit hänsyn till inhämtningen av kunskap.

Testningen av serverns funktionaliteten var en process som borde planerats redan vid starten av projek-
tet. En mer genomtänkt och automatiserad testningsprocess hade minskat antalet timmar som lades p̊a
felsökning. Exempelvis kunde testfunktioner som testar flera olika typer av indata direkt ha implemen-
terats för att säkerställa att servern alltid fungerar som planerat.

D̊a känslig data hanteras i servern hade ytterligare säkerhetslager kunnat implementeras. I nuvarande
version autentiseras användaren genom ett API-anrop till inloggningsssystemet, se avsnitt 4.2.2. Genom
att implementera ett ramverk som genererar slumpmässiga nycklar vid varje API-anrop, skulle servern
ha möjlighet att kontrollera exakt vilka användare som har till̊atelse att använda olika API-funktioner.
Detta har dock inte implementerats i nuvarande version, d̊a en bred lansering av applikationen inte är
inplanerad.

7.5 Applikationens funktionalitet och vidareutveckling

I appendix A finns bilder p̊a applikationens alla sidor, där projektet lyckats f̊a med de önskade funktioner-
na designmässigt. Däremot p̊a grund av tidsbrist och att projektets alla delar inte varit helt synkroniserade
s̊a har inte alla önskade delar av applikationen implementeras än. Detta eftersom det fanns en ovisshet om
vad v̊ar studie skulle ge för resultat och om det skulle vara möjligt att förutsp̊a morgondagens HRV. Ifall
detta hade varit möjligt och en enkel, samt lättförst̊aelig förklaring till HRV-värden hade getts s̊a hade
projektet uppn̊att sitt syfte att skapa en MVP. Ett annat sätt som applikationen hade kunnat n̊a, enligt
projektets mening, en MVP skulle varit om till exempel ett pulsband hade kunnat kopplas till applika-
tionen och användaren hade kunnat mäta sin puls under ett träningspass. Anledningen till att en MVP
inte uppn̊addes berode p̊a tidsbrist och att vissa delar av projektet var sv̊arare och mer tidskrävande än
förväntat.

Utöver att skapa en MVP s̊a var projektets syfte att ge applikationens användare lättförst̊aelig information
som skulle ge användaren återkoppling kring hur denne ska strukturera träningens frekvens och intensitet
för optimal utveckling. Detta delm̊al har f̊att en bra start, om vi skulle göra fler och längre studier om
olika värden som kan p̊averka träningen skulle vi kunna presentera dessa i appen och ge användaren
verktyg för att planera sin träning p̊a bästa sätt. Ytterligare en funktion som uppkom under projektet
g̊ang var att kunna lägga in egna m̊al, till exempel 10 km per vecka eller 10 000 steg varje dag. Dessa m̊al
skulle användare kunna ha, samt gemensamma m̊al tillsammans med användarens vänner i en grupp.
Detta var ett av flera exempel p̊a funktioner som uppkom under projektet g̊ang som inte var med i första
planeringsfasen.

Att skapa just en mobilapplikation istället för ett datorprogram eller webbsida har sin grund i mobil-
telefonens portabilitet och att stora delar av befolkningen redan använder den som hjälpmedel i andra
vardagliga syften.

GDPR-processen för att f̊a till̊atelse att lagra persondata i applikationen sker i den nuvarande versio-
nen manuellt. I en framtida version skulle en sekretesspolicy kunna implementeras direkt i appen, där
nya användare kan ge sin till̊atelse att persondata lagras i applikationen. Denna sekretesspolicyn skulle
d̊a inneh̊alla vad för slags information som samlas in, hur denna information samlas in och hur denna
information lagras och skyddas. Fördelarna med att implementera en sekretesspolicy som kan accepte-
ras direkt i applikationerna blir främst att friktionen för nya användare minskas och att det manuella
pappersarbetet försvinner.


sida 28 Internet of things för optimerad och smart prestationsutveckling sida 28

7.6 Samhälleliga och etiska aspekter

Att bevaka värden, exempelvis laktat och VO2max, kan avslöja en hel del om formen p̊a en idrottare
och kan därmed bli en fr̊aga om integritet. Detta gäller särskilt inom organiserad idrottsverksamhet
där m̊alet ofta är att producera elitidrottare. En risk med