Sluttrapport

Internet of Things

Hovedprosjekt i Informasjonsteknologi

Høgskolen i Oslo og Akershus

Våren 2016

Gruppe 24

Jon Gillingsrud Christoffer André Belgen Fredriksen

� av �1 70

� av �2 70

BACHELORPROSJEKT

HOVEDPROSJEKTETS TITTEL

Internet of Things

DATO

23.05.2016

ANTALL SIDER / BILAG

70

PROSJEKTDELTAKERE

Jon Gillingsrud, s198618

Christoffer André Belgen Fredriksen, s198583

INTERN VEILEDER

Thor E. Hasle

OPPDRAGSGIVER Skye Solutions AS

KONTAKTPERSON

Lars Martinsen Alexander Wehlin

SAMMENDRAG

Gruppe 24 har laget en prototype for å hente ut, behandle, lagre og vise frem data som er

hentet fra en Texas Instruments SimpleLink SensorTag.

I tillegg har gruppen kartlagt forskjellige IoT teknologier.

3 STIKKORD Internet of Things REST API AngularJS

Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

PROSJEKT NR. Gruppe 24

TILGJENGELIGHET Åpen

Telefon: 22 45 32 00 Telefaks: 22 45 32 05

ForordDette er prosjektrapporten for gruppe 24 som består av Jon Gillingsrud og Christoffer André Belgen Fredriksen. Produktet er en internet of things prototyp og en kartlegging av eksisterende løsninger innen for denne teknologien. Løsningen er laget etter oppdragsgivers krav og ønsker.

Vi ønsker å takke Lars Martinsen og Alexander Wehlin hos Skye for muligheten til å jobbe med dette prosjektet og hjelpen og støtten de har gitt oss.Vi vil også takke rådgiver Thor Hasle og alle foreleserne vi har hatt for alt de har lært oss gjennom studietiden.

� av �3 70

Innhold1 Innledning 7

1.1 Prosjektgruppe 71.2 Oppdragsgiver 71.3 Problemstilling 81.5 Kravspesifikasjon 8

1.5.1 Funksjonelle krav 81.5.2 Ikke-funksjonelle krav 91.5.3 Tekniske krav 9

2 Prosessdokumentasjon 102.1 Bakgrunn for prosjekt 102.2 Arbeidsmetode 102.3 Prosjektstyring 10

2.3.1 Fremdriftsplan 112.3.1.1 Milepæl 12.3.1.2 Milepæl 22.3.1.3 Milepæl 3

2.3.4 Kommunikasjon 132.3.4.1 Internt2.3.4.2 Oppdragsgiver2.3.4.3 Veileder

2.3.5 Risikoplan 142.3.6 Dagbok 16

2.4 Verktøy 172.4.1 Teksteditor 172.4.2 Wunderlist 172.4.3 Skype 172.4.4 Slack 182.4.5 GitHub 182.4.6 Dropbox 182.4.7 IntelliJ IDEA 19

2.5 Møter 192.5.1 Første møte med oppdragsgiver 192.5.2 Kick-off møte 192.5.3 Møte med rådgiver 202.5.4 Fremvisning av prosjekt til oppdragsgiver 20

� av �4 70

2.6 Utfordringer og avgjørelser 202.7 Kodestandard 21

2.7.1 Kodestruktur 21

3 Produktdokumentasjon 223.1 Målgruppe 223.2 Designvalg 223.3 Teknologivalg 22

3.3.1 Raspberry Pi 223.3.2 Texas Instruments SensorTag 233.3.3 AngularJS 243.3.4 Java 253.3.5 Python 253.3.6 REST API 263.3.7 ZingChart 263.3.8 Bootstrap 263.3.9 Apache Maven 273.3.10 Oracle GlassFish Server 273.3.11 Node.js, npm, og Bower 273.3.12 JSON 283.3.13 IBM Bluemix 283.3.14 Apache Hadoop og dashDB 28

3.4 Prosjekt del 1 : Kartlegging 293.4.1 Introduksjon 293.4.2 AllJoyn 293.4.3 IoTivity 303.4.4 Brillo 303.4.5 Open Connectivity Foundation/Open Interconnect Consortium 313.4.6 Wi-Fi 313.4.7 Bluetooth 323.4.8 NFC 333.4.9 HTTP 343.4.10 FTP 343.4.11 MQTT 343.4.12 Konklusjon 35

3.5 Prosjekt del 2 363.5.1 Introduksjon 363.5.2 Hub 36

� av �5 70

3.5.3 Backend/REST API 393.5.4 Portal 403.5.5 Database 433.5.6 Sikkerhet 443.5.7 Maskin- og programvarekrav 44

3.5.7.1 Hardware3.5.7.2 Software

4 Testdokumentasjon 464.1 Enhetstesting 464.2 Brukertesting 464.3 Ad-hoc testing 464.4 Testresultater 464.5 Konklusjon 48

5 Brukerveiledning og installasjon 495.1 Installasjon 49

5.1.1 Hub 495.1.2 Portal 495.1.3 Backend/REST API 505.1.4 Database 53

5.2 Brukerveiledning 535.2.1 Hub 535.2.2 Backend/REST API 545.2.3 Portal 54

6 Avslutning 57

6.1 Videreutvikling 576.2 Oppnåelse av mål og krav 576.3 Attest fra oppdragsgiver 586.4 Ting vi ville gjort annerledes 586.5 Vurdering av prosjektperioden og konklusjon 58

7 Ordliste 59

8 Vedlegg 608.1 Dagbok 608.2 Attest fra oppdragsgiver 648.3 Oppgavetekst 66

9 Kilder 67

� av �6 70

1 Innledning1.1 ProsjektgruppeGruppe 24 består av Jon Gillingsrud og Christoffer André Belgen Fredriksen, som begge studerer Informasjonsteknologi ved Høgskolen i Oslo og Akershus.

Medlemmene har jobbet sammen i flere sammenhenger igjennom studieperioden med gode resultater, og ønsket derfor å fortsette samarbeidet i dette prosjektet.

Medlemmene møttes i første semester gjennom felles bekjente, og startet å arbeide sammen i andre semester, og har gjort det siden.

Tidligere har gruppen jobbet med blant annet Java, C/C++, PHP, HTML, CSS, .NET, JavaScript, databaser, algoritmer og datastrukturer, menneske-maskin interaksjon, prosjektstyring, programvarearkitektur og rammeverk.

Gruppens leder er offisielt Jon, og han har derfor styrt det meste av kommunikasjonen med oppdragsgiver.I selve prosjektet har begge hatt like mye ansvar, og vi føler at dette har vært et riktig valg.

1.2 OppdragsgiverOppdragsgiver er Skye Solutions AS som holder til på Kolbotn.

Skye ble etablert i 2010, og er et nordisk SAP og IBM-selskap.Selskapet er lokalisert i Stockholm, Gøteborg og Oslo, og har mer enn 85 ansatte og 70 kunder.

De tilbyr tjenester innen:

Mobilitet og brukeropplevelseIntegrasjonUtviklingLedelsesrådgivning / prosjektledelseAnalyser/Business Intelligence serviceSkanning og arbeidsflyts-integrasjonLøsninger og kompetanse for Asset- og Facility ManagementPrediktive vedlikeholds- og analyse løsningerKlassisk SAP konsultasjon

Oppdragsgiver er SAP VAR Partner, SAP Service Partner og IBM Premier Business Partner. Kåret til Gaselle of the year 2014 av Dagens Næringsliv.

Kontaktperson i bedriften er Lars Martinsen, Project and Consultant Manager – Mobile solutions.Gruppen fikk også tildelt en teknisk kontaktperson, Alexander Wehlin, System Developer – Mobile solutions. Begge to har vært til stor hjelp for gruppen både ved tekniske avgjørelser og generell rådgivning gjennom prosjektperioden.

� av �7 70

1.3 ProblemstillingOppgaven vår er basert på begrepet Internet of things. Internet of things er en fellesbetegnelse på sensorer og maskiner som kan koble seg til internett og overføre informasjon. Denne oppgaven er todelt. Den første delen er basert på kartlegging for å se nærmere på standarder som benyttes i frittstående sensorer, så vel som innebygde sensorer i roboter og maskiner, plattformer for å håndtere administrasjon, datakommunikasjon og lagring til databaser eller andre lagringsmedier. Den andre delen er å sette opp en testlab hvor man benytter informasjon man har samlet i del 1, for å implementere sensorer, HUB funksjonalitet, styringsalgoritmer, brukergrensesnitt og datalagring.

Arbeidsoppgaver:

Del 1 (Kartlegging):

• Kartlegge hvilke åpne standarder som benyttes for sensorer i dag.

• Kartlegge hvilke kommunikasjonsprotokoller som benyttes i ulike sensortyper, og fordeler/ulemper ved disse. Eksempler (WiFi, Bluetooth, osv.)

• Kartlegge hvilke IoT plattformer som finnes hos kommersielle aktører, fordeler/ulemper ved et utvalg av disse, og hvilken grad disse benytter seg av de åpne standardene funnet over.

Del 2 (Implementere/Prototype):

• Sammenkobling og oppsett av ulike type sensorer

• HUB for å samle data for videre lagring i en database. (Data må kunne konsumeres fra ulike plattformer. HUB-ene kan for eksempel sende XML eller på annen måte http post etc. Det bør også være mulig å konfigurere HUB-ene via http kall inn. Eks: hvor ofte en sensor skal hente data og hvilke data etc.)

• Brukergrensesnitt for å koble til nye sensorer og oppsett av eksisterende.

• Analyse av datasett.

1.5 Kravspesifikasjon Kravspesifikasjonen er utviklet av gruppen ut ifra oppdragsgivers oppgavetekst og deres ønsker og innspill underveis i prosjektet. Denne har stort sett vært lik igjennom hele perioden, men noen endringer har blitt gjort for å tilpasses prioriteringene i løsningen.

1.5.1 Funksjonelle krav

Oppdragsgiver ville at vi skulle fokusere på funksjonalitet fremfor design. Dette medfører at de fleste kravene er tekniske eller funksjonelle.

• Lagre innhentet data fra sensor i en database.

� av �8 70

• Fremvisning av lagrede data.

• Data må kunne tolkes av flere plattformer.

• Analysere innsamlet data

• Konfigurere huben og velge hvor ofte og hvilke data som skal samles inn.

• Koble til nye sensorer og sette opp eksisterende

1.5.2 Ikke-funksjonelle krav

Da denne løsningen er en prototype er det ikke stilt mange ikke-funksjonelle krav. Oppdragsgivers ønsker var at funksjonalitet var hovedprioritet, samt at dette skulle være en prototype for å vise frem mulighetene i temaet. De hadde derfor ingen konkrete krav til design eller ytelse. Kravene fra kartleggingsdelen av prosjektet er satt som ikke-funksjonelle. Vi har allikevel valgt ut noen krav som vi føler var nødvendige for å få til en tilfredsstillende løsning.

• Kartlegge hvilke åpne standarder som benyttes for sensorer i dag

• Kartlegge hvilke kommunikasjonsprotokoller som benyttes i ulike sensortyper, og fordeler ulemper ved disse

• Kartlegge hvilke IoT plattformer som finnes hos kommersielle aktører, fordeler og ulemper ved et utvalg av disse, og i hvilken grad disse benytter seg av de åpne standardene funnet over

• Portal skal være brukervennlig og data skal være lette å lese og sortere. Vi ønsker også noen grafiske løsninger for visning av data.

1.5.3 Tekniske krav

Da en del av oppgaven var at vi skulle kartlegge eksisterende løsninger og bruke det vi hadde lært som inspirasjon til vår løsning hadde heller ikke oppdragsgiver mange tekniske krav, men det var noen punkter som var viktig for de.

• Bruk av open-source teknologier

• Sensorene som skal brukes er Texas Instruments SensorTag

• Raspberry Pi skal brukes som hub for innsamling av sensordataene

• Bruk av Apache Hadoop via IBMs Bluemix tjeneste.

• Bruk av GitHub for versjonskontroll

Oppdragsgiver ønsket også at AngularJS skulle brukes på portalen som viser sensordataene. Dette var ikke noe krav, og de var åpne for alternative løsninger på dette. Vi så på flere løsninger, men kom til slutt frem til at AngularJS var det vi ønsket å bruke.

� av �9 70

2 Prosessdokumentasjon2.1 Bakgrunn for prosjektLetingen etter et bachelorprosjekt begynte i månedsskiftet september-oktober ved at vi sendte ut forespørsler til bedrifter og rekrutteringsbyråer. Vi kontaktet også venner og kjente som kunne ha kjennskap til noen som ønsket å samarbeide om et prosjekt. Etterhvert fikk vi kontakt med noen bedrifter, men av forskjellige årsaker ble vi ikke enige om noe prosjekt. I julen ble gruppen tipset av et familiemedlem om Skye som kanskje kunne være interesserte i å samarbeide om et prosjekt. Vi tok kontakt, og fikk tilbakemelding på at de kunne tenke seg å hjelpe til, og at vi kunne møtes tidlig i januar for å diskutere muligheter.På dette møtet diskuterte vi om interessepunkter og kunnskaper, og Skye fortalte at de hadde sett litt på internet of things som et mulig prosjekt. Vi ble enige om at dette virket som et godt tema, og at de skulle lage et oppgaveforslag.

Gruppen godtok Skyes oppgaveforslag da medlemmene så på internet of things som et spennende tema, selv om kunnskapen og erfaringen om feltet ikke var så stor fra tidligere.

Skye har ønsker om å begynne arbeidet om temaet, og så på prosjektet vårt som en start på dette der begge parter kunne samle informasjon. Hvis prosjektet er vellykket ønsker Skye å benytte seg av dette som en basis for fremtidige prosjekter.

2.2 ArbeidsmetodeOppdragsgiver ga oss tilgang til å arbeide fra deres lokaler på Kolbotn, noe gruppen benyttet seg av når vi følte dette var nødvendig. Vi har også valgt å møtes hjemme hos hverandre når vi følte vi hadde god kontroll på oppgaven. Ellers har gruppen benyttet seg av Skype som kommunikasjonsmiddel for møter man ikke trengte å være fysisk på samme sted. En påvirkende faktor til dette er avstanden mellom bostedene til medlemmene.

Alexander Wehlin hos Skye fikk rollen som teknisk veileder for gruppen, og har vært til stor hjelp når det har oppstått problemer, og har alltid vært villig til å sette av tid til oss.

2.3 Prosjektstyring I starten av prosjektet bestemte gruppen seg for å benytte seg av Scrum som utviklingsmetodikk. Dette er egentlig ideelt for 3-9 personer, men med noen små endriger ville dette fungere fint for vårt prosjekt. Vi valgte en Scrum lignende løsning av forskjellige grunner. En av tingene som vi valgte bort var Scrum-master delen. Grunnen til dette var at leder rollen blir ikke like synlig når man kun er 2 personer. Gruppen bestemte seg også for at de var bedre at vi jobbet med samme problem og heller hadde små ansvarsområder. Den største grunnen for denne avgjørelsen var mangel på erfaring rundt teknologiene i oppgaven, og at begge derfor ønsket å lære så mye som mulig om alt vi jobbet med.

� av �10 70

Scrum er en utviklingsmetodikk som blir brukt til komplekse prosjekter. Prosjektet blir delt 1

opp i oppgaver som skal gjennomføres i sprinter. Sprinter er en fastsatt tidsperiode på maksimum en måned. Et Scrum-team blir delt opp i tre grupper: Produkteier, Scrum-master og utviklingsteam.Vi har valgt å bruke GitHub som et lagringssted. Dette ble valgt fordi vi har brukt GitHub før og synes at dette er en god løsning. Vi diskuterte også å bruke Dropbox, men valgte GitHub fordi det har en god og enkel versjonskontroll.

2.3.1 Fremdriftsplan

2.3.1.1 Milepæl 1

Første milepæl var første del av prosjektet, kartleggingsdelen.

Oppgaver som ble utført:

• Kartlegge åpne standarder som benyttes for sensorer

• Kartlegge hvilke kommunikasjonsprotokoller som blir brukt i sammenheng med sensorer

• Kartlegge hvilke IoT plattformer som finnes hos komersielle aktører

Påbegynt 03.02.16, utført 18.02.16

2.3.1.2 Milepæl 2

Etter at kartleggingsdelen var ferdig begynte gruppen på del 2 av prosjektet. Første milepæl i denne delen var å hente ut og lagre data fra sensorer i database.

Oppgaver som ble utført:

• Koble til SensorTag

• Hente datamålinger fra sensor

• Laste opp data til database

Påbegynt 22.02.16, utført 05.04.16

2.3.1.3 Milepæl 3

Milepæl 3 i prosjektet var å hente ut data fra database og vise dataene i portalen.

Oppgaver som ble utført:

• Hente ut data fra database

https://www.scrumalliance.org/why-scrum1

� av �11 70

• Lage REST API

• Hente data fra REST og vise det i portal

Påbegynt 15.03.16, utført 02.05.16

2.3.1.4 Milepæl 4

Siste milepæl i prosjektet var å fullføre sluttdokumentasjonen og levere prosjektet.

Oppgaver som ble utført:

• Fullføre sluttdokumentasjon

• Levere prosjektet

Påbegynt 02.05.16, utført 23.05.16

Det ble laget et forslag til fremdriftsplan i forprosjektet, der vi fastslo at fristene og oppsettet av fremdriftsplanen trolig ikke kom til å bli fulgt til den minste detalj, og at muligheten for endringer underveis var ganske stor.Planen ble satt opp mere som en grunnleggende inndeling av prosjektarbeidet.

Vi valgte å dele den inn i følgende faser:

Oppstart og forprosjekt, kartlegging, implentering, testing og rapport.

Tabellen under viser fremdriftsplanen slik vi laget den i forprosjektet:

Tabell 1: Fremdriftsplan forslagFase Detaljer Tidsperiode

Oppstart og forprosjekt 13.01 - 29.01 Oppstartsfasen av prosjektet med møter og samtale med bedrift og veileder for å diskutere prosjektets innhold. Skriving av prosjektskisse og forprosjektrapport vil skje i denne perioden. Avsluttes med kick-off møte hos Skye for å bestemme detaljer og starte selve prosjektarbeidet.

Kartlegging 01.02 - 18.03 Jobbe med kartleggingsdelen av prosjektet.

� av �12 70

Under prosjektperioden holdt vi denne planen ganske godt. Vi valgte å starte implementeringsfasen av prosjektet litt tidligere, mest fordi vi syntes dette var den mest interresante delen av prosjektet. Hovedfokuset på denne fasen begynte også noe tidligere, da vi hadde satt av litt lengre tid til kartleggingen en vi hadde behov for.

Som en følge av dette ble også implementeringsfasen ferdig litt tidligere, noe som gjorde at vi kunne starte testingen tidligere.

Vi fant også fort ut at tiden vi hadde satt av til rapportskrivingen ble litt for kort, og perioden der denne skulle være hovedfokus ble startet 02.05. Dette tok litt ifra tiden satt av konkret til testing.Selv om tiden satt av til testing ble litt kortere enn først planlagt følte gruppen at testing hadde blitt fokusert godt nok på under implementeringsfasen at dette ikke hadde noen stor påvirkning.

2.3.4 KommunikasjonKommunikasjon med tanke på en slik oppgave er utrolig viktig. For at ting skal bli gjort trenger man god kommunikasjon i mellom gruppemedlemmene. Kommunikasjon med oppdragsgiver er viktig for at oppdragsgiver skal få det produktet de vil ha. Kommunikasjon med veileder er viktig for å få tilbakemeldinger med en akademisk synsvinkel. I dette prosjektet føler vi at kommunikasjonen generelt har vært god med alle parter.

Implementering 26.02 - 24.05 Benytte funnene i forrige fase til å lage løsninger for innsamling av sensordata, samt lagring og visning av denne.Denne fasen overlapper den forrige da vi antar at deler av arbeidet her kan påbegynnes selv om ikke kartleggingen er komplett.

Testing 02.05 - 14.05 Omfattende testing av løsninger for å sikre god kvalitet og fjerne bugs og feil. Testing vil også gjøres fortløpende gjennom prosjektperioden.

Rapport 15.05 - 24.05 Tid satt av til ferdigstilling av rapport og avslutning av prosjektet. Rapportskrivingen vil pågå sammen med øvrig arbeid gjennom hele prosjektperioden.

Fase Detaljer Tidsperiode

� av �13 70

2.3.4.1 Internt

Gruppen har jevnlig hatt møter, enten på høgskolen eller hjemme hos hverandre. Dette ble gjort da gruppen følte at vi jobbet best sammen, og der en kanskje hadde problemer kunne den andre ha en løsning. Når deltakerne ikke har hatt mulighet til å møtes har det blitt holdt kontakten via Facebook Messenger og telefon. Møter har også blitt holdt via Skype, og funksjonen for skjermdeling har blitt brukt flittig.

2.3.4.2 Oppdragsgiver

Hovedkommunikasjon med oppdragsgiver har skjedd med epost, og dette har fungert fint. Slik holdt vi oppdragsgiver oppdatert på status, og fikk også svar på eventuelle spørsmål vi hadde. Gruppen fikk også tilbud om en arbeidsplass hos oppdragsgiver, og når vi var igang med selve prosjektet avtalte vi å møtes en dag i uken her når det passet for begge parter. Vi hadde stort utbytte av dagene hos oppdragsgiver da vi fikk god tilbakemelding og rådgivning.

2.3.4.3 Veileder

Kommunikasjon med veilederen på HiOA foregikk stort sett via epost. Når gruppen hadde spørsmål fungerte dette fint, og vi fikk raskt tilbakemelding.

2.3.5 Risikoplan

Risikoplanen vist under ble laget i starten av prosjektfasen. Målet med denne er å kartlegge de potensielle risikoene under prosjektet og konsekvensene disse har. Gruppen følte også at denne planen var viktig for å vise hva som kreves av den enkelte slik at prosjektet skal kunne gjennomføres på en god måte.

I større prosjekter vil det være punkter som omhandler økonomien i prosjektet, men da vi ikke har betaling er ikke dette noen problem i vårt tilfelle. Vi har også sett på risikoen for flere problemer, men da sannsynligheten for disse var meget lav har vi ikke tatt de med i planen.

Tabell 2: RisikoplanRisiko Sannsynlighet Konsekvens Tiltak

Korttids sykdom Høy Lav God kommunikasjon, tilgang til den andres arbeid

Langtids sykdom(Over 1 uke)

Lav Høy Omprioritere og omstrukturere oppgaver. Se hvor mye, hvis noe, sykt medlem kan gjøre.

� av �14 70

Gruppen definerte kort tids sykdom som sykdom som varer under 1 uke. Selv om gruppen kun har 2 medlemmer så vi på dette som meget sannsynlig at en av oss ville bli syke i løpet av prosjektperioden. Konsekvensene av dette er også små, og hvis man har tilgang til hverandres arbeid har det ikke mye påvirkning. Vi så på det som trolig at man også kunne jobbe litt selv om man var syk.

Langtids sykdom ble karakterisert som sykdom over 1 uke. Da begge medlemmene av gruppen ikke har noen historie for sykdom så vi på dette som lite sannsynlig. Konsekvensene av dette er også høy, da tap ett gruppemedlem gjør at gruppen i teorien bare får utført halvparten av planlagt arbeid. Hvis dette skulle inntreffe så er det viktig å få omstrukturert og omprioritert oppgaver, samt at gruppemedlemmene må ha tilgang til den andres arbeid. Det er også viktig å kartlegge hvor mye sykt medlem får jobbet, hvis noe.

Tap av data Lav Meget høy Commite til GitHub eller lagre til Dropbox jevnlig. Utføre backup av pc jevnlig.

Tap av gruppemedlem

Meget lav Katastrofal Motivere og hjelpe hverandre hvis det oppstår problemer.

Tidsmangel Moderat til høy Høy Planlegge godt og gjøre fastsatte ting til fastsatt tid. Omprioritere oppgaver.

Dårlig kommunikasjon

Lav Lav Holde kontakten jevnt og holde hverandre oppdatert. Ikke veldig stort problem når det er kun 2 gruppemedlemmer.

Faglige problemer eller problemer med verktøy

Moderat Lav til moderat Søke hjelp, tilegne seg egenskapene som mangler eller finne alternativ løsning på problemet.

Uklare krav Lav Moderat til høy God kommunikasjon med oppdragsgiver, spørre hvis vi støter på problemer eller uklarheter.

Risiko Sannsynlighet Konsekvens Tiltak

� av �15 70

Tap av data er potensielt katastrofalt for gruppen, avhengig av omfang. Det er derfor veldig viktig at vi benytter oss av GitHub og Dropbox for opplasting og synkronisering av data, samt at gruppemedlemmene tar backup av maskiner med jevne mellomrom.

Sjansen for at en av medlemmene ønsker å forlate gruppa ser vi på som meget liten, da vi har et godt forhold og god erfaring med å jobbe sammen tidligere med gode resultater. Hvis dette allikevel skulle skje er konsekvensen at gruppen prosjektet trolig må avbrytes, avhengig av når i prosjektperioden dette skjer, og om nytt medlem kan anskaffes eller om prosjektet kan fullføres alene. For å unngå dette er det viktig at vi har god kommunikasjon, og snakker sammen hvis det oppstår problemer eller uenigheter.

Tidsmangel er et problem vi ser på som ganske sannsynlig at vi kommer til å måtte håndtere i løpet av prosjektet. Konsekvensene kan også bli ganske store, hvis det for eksempel fører til at vi ikke får levert før fristen. Det er derfor viktig å planlegge oppgaver godt og holde tidsfrister, og om nødvendig sette av mere tid hvis dette er en mulighet.

Kommunikasjonen innad i gruppen kommer ikke til å bli noe stort problem, men det er allikevel viktig å snakke med hverandre og holde den andre oppdatert på status på forskjellige oppgaver.

At vi støter på faglige problemer ser vi på som garantert, og det er en viktig del av prosjektet at vi utfordrer kunnskapene våre. Hvis det oppstår problemer vi ikke klarer å løse selv må vi søke hjelp hos hverandre, medstudenter, oppdragsgiver eller rådgiver. Konsekvensene av dette ser gruppen på som små hvis man søker hjelp når utfordringene oppstår.

Uklare krav ser gruppen også på som lite sannsynlig da det har vært god kommunikasjon med oppdragsgiver fra starten. Konsekvensene kan bli store, og viktigheten av kommunikasjon mellom partene er derfor stor for å unngå at noe blir tolket feil.

2.3.6 Dagbok

Vi har ført dagbok igjennom hele prosjektperioden.

Et innlegg i dagboken ser slik ut:

Dagboken ligger under vedlegg, kapittel 8.1.

Tabell 3: Eksempel dagbokDato Innlegg

13.01 Har møte med Skye. På dette møtet diskuterte vi om interessepunkter og kunnskaper, og Skye fortalte at de hadde sett litt på internet of things som et mulig prosjekt. Vi ble enige om at dette virket som et godt tema, og at de skulle lage et oppgaveforslag.

� av �16 70

2.4 Verktøy

2.4.1 Teksteditor

I kartleggingsfasen begynte vi med å bruke Google Docs for å kunne skrive på et felles dokument samtidig i nettleseren. For å finne informasjonen vi trengte om de forskjellige utviklingsverktøyene og rammeverkene så brukte vi flere forskjellige søkemotorer. Formateringen av dokumentet vi skrev i ble ikke bra nok etter vår smak så vi byttet til iCloud Pages som vi følte var bedre, samtidig som muligheten for å samarbeide på samme dokument var tilstede. Pages er kun tilgjengelig på Mac OS X, men har også som Google Docs gjort editoren tilgjengelig for samarbeid i nettleseren.

2.4.2 Wunderlist

FIGUR 1. WUNDERLIST LOGO

For å holde kontroll på hvilke oppgaver som måtte gjøres benyttet vi oss av huskeliste-applikasjonen Wunderlist . Med Wunderlist kan man sette gjøremål med frister og 2

påminnelser og deretter tilegne gjøremålet til en av gruppemedlemmene.

2.4.3 Skype

FIGUR 2. SKYPE LOGO

Skype har blitt brukt som et kommunikasjonsmiddel. Skype tilbyr både tale og videosamtaler kostnadsfritt over internett. Hovedgrunnen til at vi valgte denne tjenesten fremfor en annen er funksjonen for skjermdeling, slik at man kan se hva den andre personen i gruppen gjør. Dette gjorde det lett for gruppen å kode sammen, og var et godt alternativ til å møtes.

https://www.wunderlist.com/2

� av �17 70

2.4.4 Slack

FIGUR 3. SLACK LOGO

Slack er et sky-basert kommunikasjons og samarbeidsverktøy. Det ble laget en egen 3

gruppe i Slack for å oppnå kommunikasjon mellom gruppemedlemmene, samt å dele lenker og filer på et mer egnet sted enn Facebook Messenger.

2.4.5 GitHub

FIGUR 4. GITHUB LOGO

GitHub ble valgt som lagringsplass av filer som ble brukt i prototypen. Det ble diskutert 4

om vi skulle bruke Dropbox, men på grunn av mangel på versjonskontroll ble GitHub valgt som et bedre alternativ. Vi valgte å bruke et privat GitHub-repo slik at det kun var gruppemedlemmene som hadde tilgang til filene.

2.4.6 Dropbox

FIGUR 5. DROPBOX LOGO

For deling av dokumenter og andre mindre viktige filer brukte gruppen skylagringstjenesten Dropbox. Denne tjenesten tilbyr skylagring samt deling av filer, slik at endringer gjort av ett medlem vil bli synkronisert hos den andre. Dropbox ble også brukt for å overføre filer til huben, da de blir gjort tilgjengelige i nettleseren og kan lastes ned selv om huben manglet en klient for synkronisering.

https://slack.com/is3

https://github.com/4

� av �18 70

2.4.7 IntelliJ IDEA

FIGUR 6. INTELLIJ IDEA LOGO

IntelliJ IDEA endte opp som vår foretrukne IDE for dette prosjektet. Vi startet med å bruke 5

NetBeans da dette har vært det foretrukne valget gjennom flere kurs i studieperioden. Gruppen ble introdusert for IntelliJ IDEA i kurset Programvarearkitektur og rammeverk, og likte det godt. Vi hadde også erfaring med Android Studio som er basert på IntelliJ, og overgangen gikk derfor veldig smertefritt.

IDEen har støtte for alle programmeringsspråkene vi har valgt å bruke i vårt prosjektet, tillegg til en rekke andre.

Community versjonen er gratis for alle, men som studenter har vi tilgang til Ultimate versjonen med utvidet funksjonalitet kostnadsfritt i 1 år. Denne versjonen var nødvendig for oss da det kun er denne som støtter JavaScript og HTML/CSS.

2.5 Møter

Under er det referater av de viktigste møtene under prosjektperioden.Se dagboken for en større oversikt.

2.5.1 Første møte med oppdragsgiver

Den 13.01 hadde vi første hos oppdragsgiver. På dette møtet ble det diskutert hvilke kunnskaper og interesser gruppen hadde, samt hva oppdragsgiver kunne tenke seg et prosjekt å handle om.Vi ble her enige om tema for prosjektet, og fikk i etterkant tilsendt et oppgaveforslag.

Dette oppgaveforslaget ble vurdert, og når gruppen hadde godkjent det ble det videresendt til rådgiver og bachelorprosjekt-ansvarlig ved skolen for tilbakemelding og godkjenning.

2.5.2 Kick-off møte

Etter at forprosjektet var fullført møtte vi den 02.02 hos oppdragsgiver for å ha et "kick-off" møte. Hensikten med dette møtet var å ble enige om detaljer rundt prosjektet og kravspesifikasjon.Gruppen fikk også utdelt Raspberry Pi og TI SensorTag sensorer for å starte prosjektet.

Etter dette møtet ble Pien satt opp slik at utvikling med denne kunne starte når den tid kom, og del 1 av prosjektet ble startet opp.

https://www.jetbrains.com/idea/5

� av �19 70

2.5.3 Møte med rådgiver

Gruppen valgte å kontakte rådgiver for å få tips til rapporten og for å vise frem det vi har gjort hittil. Dette møtet fant sted 12.05, og var et konstruktivt og positivt møte. Vi viste frem oppgaven til rådgiver og fikk noen tips om hva som burde være med i rapporten. Selve produktet vi har laget virket han positiv til og han sa at prosjektet virket veldig spennende.

2.5.4 Fremvisning av prosjekt til oppdragsgiver

19.05 hadde vi fremvisning av prosjektet for oppdragsgiver. Vi viste frem kode, forklarte tankegangen i programmet og teknologivalgene som vi har tatt. De var veldig fornøyde med løsningen vi hadde kommet med, og de påpekte at det var imponerende at vi hadde greid å sette oss inn i så mange teknologier som var helt ukjente for oss når prosjektet startet. Attester for utført oppdrag skulle ettersendes.

2.6 Utfordringer og avgjørelserEn av utfordringene gruppen hadde i portalen var at vi hadde ønske om at siden skulle oppdateres slik at nye sensormålinger automatisk ble vist. Veileder hos oppdragsgiver hadde erfaring med dette og anbefalte $timeout funksjonen for dette. 6

Dette krever ikke mye kode og etter at vi hadde fått til dette i en tutorial for funksjonen begynte implementasjonen i vår løsning. Problemet som oppsto når vi la til dette var at prosessene som ble startet av $timeout økte eksponensielt, noe som førte til at nettleseren til slutt krasjet. Gruppen i samarbeid med veileder brukte mye tid på feilsøking på dette problemet, og forsøkte en rekke løsninger både hvor/hvordan prosessene ble startet og måter å avslutte dem. Etter mye feilsøking bestemte gruppen seg for å droppe denne funksjonen fra løsningen fordi den tok tid fra andre viktigere funksjoner. Denne funksjonen ble i etterkant implementert suksessfullt i Zingchart-grafen.I løsningen vår prøvde vi å finne teknologier som kunne gjøre løsningen så god som mulig og la stor vekt på dette. Som et resultat av dette satt vi oss inn i flere teknologier og rammeverk som vi ikke hadde brukt før. Noen eksempler på dette er REST, Python og AngularJS. Den største utfordringen vi kom ovenfor med tanke på teknologier var å finne de riktige teknologiene for å hente ut dataene fra sensoren og sende dataene til databasen vår. Selv om det i noen tilfeller tok litt tid klarte vi å tilegne oss nødvendige kunnskaper om det meste, og fikk også god assistanse fra veileder hos oppdragsgiver når det var nødvendig.

Vi startet med Apache Hadoop som databaseverktøy. Etter at IBM bestemte seg for å fjerne støtte til Hadoop i Bluemix måtte vi finne et nytt databaseverktøy. Det nye verktøyet ble valgt ved hjelp av veileder på Skye med rådgivning fra IBM. Vi endte opp med dashDB. I dashDB har vi hatt noen utfordringer med å navngi tabellen i databasen. Når vi skulle skrive inn navnet på tabellen ble navnet som ble sendt med gjort om fra stor forbokstav og resten i små bokstaver til alle at alle ble store bokstaver. Vi prøvde oss frem med

https://docs.angularjs.org/api/ngResource/service/$resource6

� av �20 70

forskjellige løsninger, men fant ut at vi ikke ville bruke mer tid på det og gjorde om navnet på tabellen i databasen til kun store bokstaver. Dette løste hele problemet på lettest mulig måte, uten at det påvirker resultatet.

2.7 KodestandardEttersom oppgaven er å lage en prototype har vi hatt stort fokus på at koden skal være skalerbar. Dette vil gjøre at man kan utvide systemet vårt på en lett og effektiv måte når man for eksempel vil legge til flere sensorer eller koble opp løsningen til et større system. Navngiving på filer er valgt slik at det skal være lett forståelig for de som eventuelt skal videreutvikle løsningen. Variabelnavn i koden er navngitt på en måte som gjør at koden er lett leselig for folk som skal videreutvikle og andre som leser koden. Kommentering av koden er brukt for å forklare hva de forskjellige metodene gjør. Kommentering er også brukt på steder hvor koden ikke er selvforklarende på hva den utfører. Kommenteringen i filene er på norsk i denne versjonen.

2.7.1 Kodestruktur

Selv om gruppen kun har 2 medlemmer har det allikevel vært viktig for oss å ha god struktur i koden slik at det er lett forståelig for begge hvilke filer og funksjoner som gjør hva. Vi har gjort dette med å bruke gode navn og kommentering, samt ha oversiktlig kode.

� av �21 70

3 Produktdokumentasjon3.1 MålgruppeMålgruppen i prosjektet er oppdragsgiver Skye. De ønsker å bruke resultatet av prosjektet som et startpunkt for utvikling av ideer som de kan bygge videre på som egne prosjekter i fremtiden. De valgte å gjøre oppgaven 2-delt slik at de fikk et innblikk på hva som var gjeldende standarder innenfor internet of things, samt hvordan dette kunne implementeres i praksis.

Et scenario som er tenkt er Smarthus. Sensorene kan brukes for å måle blant annet temperatur og luftfuktighet. Disse dataene kan brukes for å regulere disse faktorene. Et annet scenario som har blitt nevnt er sensorer for samlebånd i produksjon. Man kan da bruke dataene som blir samlet inn for å bytte ut slitte deler før de blir ødelagt.

3.2 DesignvalgSom nevnt i kravspesifikasjon var det ikke noe krav fra oppdragsgivers side for design, da produktet skulle være en prototype for å vise frem mulighetene. Deres ønske var at utseendet på portalen ikke skulle være noe hovedfokus, men at det skulle være lettvint å bruke.

Gruppen valgte derfor å gjøre designet så enkelt som mulig, slik at det skulle være enkelt å forstå og navigere. Vi har benyttet oss av Bootstrap (Se 3.3 Teknologivalg) for enkelte designelementer, samt ZingChart (Se 3.3 Teknologivalg) for å vise frem dataene grafisk i tillegg til i tabellform. Vi har valgt noen få sorteringsmuligheter slik at man kan finne data man leter etter lettere.

3.3 Teknologivalg

3.3.1 Raspberry Pi

Raspberry Pi 2 Model B ble benyttet som hub i dette prosjektet etter ønske fra 7

oppdragsgiver. Oppdragsgiver har stilt til disposisjon en Raspberry Pi med alt nødvendig tilbehør. Tilbehøret man har behov for er strømforsyning via Micro-USB, MicroSD minnekort og kabinett for maskinen. Mus/tastatur og skjerm hadde begge gruppemedlemene tilgjengelig. Da Raspberry Pi 2 ikke har innebygd Wi-Fi og Bluetooth ble det også kjøpt inn adaptere for støtte av dette. Bluetooth var påkrevd for kommunikasjon med sensorene. Wi-Fi var ikke påkrevd da Pien har innebygd ethernet-port, men det gjorde den nødvendige nettverkstilkoblingen lettere.

https://www.raspberrypi.org/products/raspberry-pi-2-model-b/7

� av �22 70

FIGUR 7. RASPBERRY PI 2 MODEL B

Raspberry Pi er en en-korts datamaskin på størrelse med et kredittkort. Versjon 2 Model B som gruppen fikk tildelt ble lansert i februar 2015. Den har ikke innebygd lagring, og all lagring skjer via et MicroSD kort. Strømtilførsel skjer via en micro-USB kontakt.Maskinen har en ethernet-port, 4 USB 2.0 porter, HDMI-port for tilkobling til en skjerm/TV og en 3,5mm lydutgang. Prisen er på ca. 220kr.

Den kan kjøre en rekke operativsystemer. Produsenten anbefaler en versjon av Debian/Linux kalt Raspbian. Raspbian er kostnadsfri, og vi valgte denne da den inneholdt alle funksjonene som var nødvendig for vårt prosjekt. Pien kan i tillegg kjøre flere andre versjoner av Linux, Android og en versjon av Windows 10 kalt IoT Core.

Versjon 3 ble lansert i februar 2016, og tilbyr i tillegg til raskere prosessor innebygd Wi-Fi og Bluetooth tilkobling.

3.3.2 Texas Instruments SensorTag

Texas Instruments Simplelink SensorTag er en sensor som måler blant annet luftfuktighet, 8

trykk, temperatur og bevegelse via akselerometer. Sensoren er et utviklingsverktøy brukt i sammenheng med utvikling av Internet of Things systemer. For øyeblikket er det kun Bluetooth som er støttet for disse, men det utvikles en versjon med støtte for Wi-Fi også. Det finnes en app til smarttelefoner som viser alle målingene til sensoren i sanntid. Denne appen finnes til Android og iOS. 9

Oppdragsgiver stilte to ulike versjoner av SensorTag til disposisjon for gruppen. I vår prototype har vi brukt den nyeste av de to versjonene, CC2605.

http://processors.wiki.ti.com/index.php/CC2650_SensorTag_User's_Guide8

Android: https://play.google.com/store/apps/details?id=com.ti.ble.sensortag 9

iOS: https://itunes.apple.com/us/app/ti-sensortag/id552918064?mt=8� av �23 70

FIGUR 8. TEXAS INSTRUMENTS SIMPLELINK SENSORTAG

3.3.3 AngularJS

FIGUR 9. ANGULARJS LOGO

AngularJS, Angular.js eller bare Angular er et open-source webapplikasjonsrammeverk i hovedsak vedlikeholdt av Google. Det er laget for å gjøre utvikling av single-page webapplikasjoner enklere å utvikle og teste. Den inneholder rammeverk for model-view-controller, MVC, og model-view-viewmodel, MVVM.

Angular fungerer ved å først leste HTML dokumentet for siden som inneholder egne tag-atributter, og tolker disse og viser siden som standard JavaScript variabler. Målet er å bygge på HTML for å lage dynamiske nettsteder. Som nevnt tidligere er AngularJS basert på MVC. Måten dette er bygget opp på er at i model er det samlede variabler eller objekter. I controller har man $scope som henter dataene fra model utifra hva viewet vil ha. Viewet viser frem dataene. $scope objektet inneholder funksjonene som er tilgjengelig i viewet.

Nettsteder som Wolfram Alpha, NBC og Intel benytter seg av Angular.

Meteor er et open-source JavaScript rammeverk som bruker Node.js som ble sett på som et alternativ, foreslått av oppdragsgiver. Det brukes ofte til prototyping og kryss-platform kode. Den integreres med MongoDB og bruker blant annet Distributed Data Protocol for å automatisk hente ut data uten at man trenger å skrive kode for å synkronisere kode. Meteor er avhengig av å ha jQuery.

Etter å ha prøvd begge to falt valget på AngularJS.

� av �24 70

3.3.4 Java

FIGUR 10. JAVA LOGO

Java er et klassebasert og objektorientert programmeringsspråk. Firmaet som utvikler 10

Java heter Sun Microsystems som er under Oracle Corporation. Java ble først utgitt i 1995, men ble ikke open source før 2006. I 2016 er Java et av de mest populære programmeringsspråkene.

Java er laget så utviklere ikke trenger å lage flere versjoner til forskjellige plattformer programmet skal kjøres på. Det eneste kravet til plattformen er at den har støtte for Javas virtuelle (JVM). Java har store likheter med C og C++ i sin syntaks.

Valget falt på Java i vår løsning fordi dashDB ble valgt som databaseløsning, og kommunikasjon med denne fungerer mest med Java og JDBC, og drivere finnes som .jar-filer.

Det er også dette språket gruppen har mest erfaring med fra tidligere kurs i studiet, noe som hjalp mye i utviklingsprosessen.

3.3.5 Python

FIGUR 11. PYTHON LOGO

Python ble først sluppet 20 Februar 1991. De som utvikler Python er Python Software 11

Foundation. Tanken bak Python er å lage kode som er lett lesbar og å lage et program på så få linjer med kode som mulig. Python er laget for å utvikle både store og små løsninger. Man kan programmere både objekt orientert og funksjonelt. I Januar 2016 ligger Python på femte plass på TIOBE Programing Community Index som rangerer de mest populære programmeringsspråkene.

https://en.wikipedia.org/wiki/Java_(programming_language)10

https://en.wikipedia.org/wiki/Python_(programming_language)11

� av �25 70

I vår løsning har vi brukt Python til å hente informasjon fra sensoren vår og skrive disse til en tekstfil. Dette gjør vi ved å koble oss opp til sensoren via Bluetooth, hente ut informasjonen sensoren måler, og deretter skriver disse til tekstfilen som Javaprogrammet vårt skal bruke. Pythonscriptet blir kjørt av Javaprogrammet.

3.3.6 REST API

REST (Representational State Transfer) er en arkitektur som blir brukt i web sammenheng. Det brukes for å kommunisere mellom klient og server på komplekse måter. Klienten trenger ikke vite noe om hverken serveren eller dens innhold, men klienten og serveren må være enige om hvilket medium som blir brukt. I et REST API blir informasjonen APIet trenger gitt av serveren den kommuniserer med.

Hensikten med et REST API er å kunne fremstille data i mange formater basert på URL og HTTP-metodene POST (Sette inn), GET (Hente) og DELETE (Slette). Metodene forteller hva brukeren ønsker å gjøre ut ifra samme URL.I vår løsning vil vi benytte oss av GET for å hente sensordata.

3.3.7 ZingChart

FIGUR 12. ZINGCHART LOGO

ZingChart er et graf-bibliotek for JavaScript bibliotek, inkluder AngularJS og jQuery. 12

De tilbyr en enkel måte å legge til forskjellige typer interaktive grafer med en gode instruksjoner for hvordan man legger til grafene og hvordan data skal struktureres for å vises. ZingChart har også store muligheter for tilpasning av grafene slik at man får de funksjonene og det utseendet man selv ønsker.

Gruppen prøvde flere biblioteker før vi endte opp med ZingChart, og det ble valgt fordi vi det hadde de tilpasningsmulighetene vi ønsket og var samtidig mye enklere i bruk enn en rekke av alternativene.

3.3.8 Bootstrap

Bootstrap er et front-end bibliotek for å lage og designe nettsider. Det inneholder en 13

rekke maler innenfor HTML og CSS for å enkelt lage dynamiske nettsider med et pent design.Vi brukte dette til å legge til en finpuss på designet på portalen, og brukte kun noen få av de store mulighetene dette biblioteket tilbyr.

http://www.zingchart.com12

http://getbootstrap.com13

� av �26 70

3.3.9 Apache Maven

Maven er et byggesystem for Java applikasjoner. Det beskriver hvordan prosjektet skal 14

bygges og hvilke avhengigheter det har, blant annet eksterne moduler, plugins og byggingsrekkefølge.Beskrivelsen av dette skjer via en XML-fil med navnet pom.xml, forkortelse for Project Object Model.

3.3.10 Oracle GlassFish Server

GlassFish er en applikasjonsserver for Java prosjekter. Denne serveren ble brukt for å 15

kjøre backend-delen av prosjektet lokalt på våre maskiner via IntelliJ. Bakgrunnen for at gruppen valgte denne applikasjonsserveren er fordi JetBrains/IntelliJ anbefaler denne teknologien for REST APIer laget i Java.

3.3.11 Node.js, npm, og Bower

FIGUR 13. NODE.JS LOGO

Node.js er et runtime system for å kjøre nettverksapplikasjoner. npm er 16 17

pakkebehandleren som benyttes av Node.js. Bower er en klient-side pakkebehandler 18

som er avhengig av npm og Node.js.I vårt prosjekt benytter vi disse 3 for å bygge og kjøre vår AngularJS portal lokalt gjennom IntelliJ. De er disse som benyttes standard av IntelliJ for kjøring av AngularJS applikasjoner.

Representational state transfer er en programvare arkitektur som brukes i sammenheng med internett. REST bruker de samme verbene som HTTP bruker når nettlesere bruker for å hente nettsider. REST bruker disse mot eksterne systemer som nett ressurser som identifiseres av Uniform resource identifiers.

https://maven.apache.org14

https://glassfish.java.net15

https://nodejs.org/en/16

https://www.npmjs.com17

http://bower.io18

� av �27 70

3.3.12 JSON

JSON (JavaScript Object Notation) er en standard for å utveksle data mellom en server 19

og en webapplikasjon. I vårt prosjekt brukes dette av REST APIet i backend som sender JSON objekter med sensordata til portalen. Et alternativ til dette er XML, og en løsning med dette som alternativ ble utprøvd, men vi følte at JSON ga et bedre resultat i vårt tilfelle. Det finnes egne funksjoner i Java for å gjøre om objekter til JSON objekter, og AngularJS har funksjoner for å lettvint hente ut data.

3.3.13 IBM Bluemix

FIGUR 14. IBM BLUEMIX LOGO

Bluemix er en skyplatform-tjeneste levert av IBM. Den har støtte for en rekke 20

programmeringsspråk, og har tjenester for å utvikle, distribuere og administrere applikasjoner i skyen. Siden oppdragsgiver er IBM-partner og benytter seg av flere tjenester i Bluemix ønsket de at vi brukte noen av de relevante tjenestene for vårt produkt. Mange av tjenestene er gratis med mulighet for å utvide kapasiteten mot betaling. Gruppen fikk om nødvendig disposisjon til å benytte seg av noen av betalingstjenestene mot godkjenning fra oppdragsgiver.

3.3.14 Apache Hadoop og dashDB

Apache Hadoop og dashDB er begge databasetjenester. Vi valgte Apache Hadoop ved 21 22

oppstart av prosjektet på oppfordring av oppdragsgiver. IBM Bluemix var de som leverte tjenesten. Etter at gruppen hadde begynt med utviklingen av prototypen avsluttet IBM støtten til Hadoop og vi måtte derfor velge et annet databaseverktøy. Oppdragsgiver med råd fra IBM anbefalte derfor dashDB som et godt alternativ. dashDB takler ikke store mengder data like godt som Hadoop, men fungerer mer enn godt nok for vårt prosjekt. Oppsett av databasetabell gjøres med SQL-spørringer på Bluemix nettsiden, og det er også godt forklart hvordan man kan koble seg til databasen gjennom blant annet JDBC 23

som vi valgte.

http://www.json.org19

http://www.ibm.com/cloud-computing/bluemix/20

http://hadoop.apache.org/21

http://www-01.ibm.com/software/data/dashdb/22

Java Database Connectivity, http://www.oracle.com/technetwork/java/javase/jdbc/index.html23

� av �28 70

Hadoop er ikke regnet som en database. Det er et datalagringsverktøy, men bruker ikke queries for å hente ut data. For å bruke Hadoop som en database må man bruke tilleggsverktøy. Planen var å bruke Spark som et mellomledd til vår prototype, men etter at Hadoop ble fjernet fra Bluemix gikk vi bort i fra både Hadoop og spark. dashDB er et databaseverktøy som vanligehovedsakelig bruker DDL istedenfor SQL. Denne løsningen fungerer på tilnærmet lik måte som vanlige databaseløsninger. Det eneste vi måtte gjøre var å legge til en driver slik at vi fikk koblet oss til.

3.4 Prosjekt del 1 : Kartlegging

3.4.1 Introduksjon

Første del av prosjektet besto av å kartlegge hvilke åpne standarder, kommunikasjonsprotokoller som finnes, samt hvilke IoT plattformer som benyttes av kommersielle aktører.

Internet of Things (IoT), er et nettverk av fysiske objekter, som elektroniske enheter, kjøretøy og bygninger som inneholder elektronikk, sensorer, trådløs tilkobling og annen teknologi. Dette nettverket gjør det mulig for disse enhetene å samle og dele data.IoT gjør det mulig å hente inn data og fjernstyre enheter gjennom eksisterende nettverk.

Konseptet ved å koble smartenheter til et nettverk ble diskutert allerede i 1982. Den første enheten som ble koblet til internet var en Cola maskin på Carnegie Mallon University. Da kunne man hente ut informasjon om sortiment og om de nye flaskene som ble satt inn hadde blitt kalde.

Under er funnene våre beskrevet, og fordeler og ulemper ved disse er trukket frem.

3.4.2 AllJoyn

AllJoyn er et open-source prosjekt startet av Qualcomm, som også har ledet utviklingen. Prosjektet er overført til Linux Foundation, og under navnet AllSeen Alliance har en rekke store produsenter blitt med på prosjektet, kjente aktører som Sony, Philips, Electrolux, Canon, Microsoft er en del av de over 200 medlemmene.Dette gir store muligheter for teknologi som fungerer på en rekke forskjellige måter på et stort utvalg produkter.

Systemet benytter seg av klient-server modellen. Hver "produsent" i nettverket, en server eller annet aksesspunkt, benytter seg av en XML fil som kalles introspection som forteller hvilke enheter som er tilkoblet og hva den har mulighet til å gjøre. Det finnes også teknologi for strømming av lyd/musikk til en eller flere enheter.Kommunikasjon er for øyeblikket kun tilgjengelig via Wi-Fi.

Fordelen med AllJoyn er fleksibilitet. Det er designet for å fungere på flere plattformer og rammeverket er open-source slik at implementasjon av flere plattformer skal bli så lettvint som mulig i fremtiden. Det er fullt implementert for Linux, Windows, OS X, iOS og Android med flere.AllJoyn er også fleksibelt når det gjelder programmeringsspråk, og fungerer i C, C++, Objektiv-C og Java.

� av �29 70

Sikkerhet har vært viktig fra starten av, og tilbyr peer-to-peer kryptering med AES128 og autentisering med PSK og ECDSA.

Den største ulempen med AllJoyn er at det kun fungerer via Wi-Fi, da en rekke konkurrenter i tillegg benytter kommunkasjonsprotokoller som Bluetooth, IR og Wi-Fi Direct som åpner for større muligheter for å koble til flere forskjellige enheter og sensorer.

AllJoyn og AllSeen Alliance har store muligheter for å lage et bra produkt/en bra standard innen IoT da de fokuserer på open-source teknologi og samarbeider med en rekke store produsenter for å implementere en rekke forskjellige produkter og teknologier. Det eneste som holder de litt tilbake, spesielt med tanke på vår løsning, er mangelen på tilkoblingsmuligheter, men dette er noe som fint kan implementeres i fremtiden.

3.4.3 IoTivity

FIGUR 15. IOTIVITY LOGO

IoTIvity er et open-source prosjekt som er en del av Linux Foundation. Gruppen OIC (Open Interconnect Consortium) sponser prosjektet. OIC er en gruppe firmaer som samarbeider med å lage standarder og sertifiseringer for enheter som brukes i IoT. Gruppen består av mer enn 80 firmaer, blant annet Intel og Samsung. Dette gjør at det blir en stor variasjon av enheter som kan brukes. Koden er tilgjengelig i Apache 2.0 og skrevet i C/C++. IoTIvity er et prosjekt som ligner på AllJoyn. Det er også støtte for Android, og støtte for JavaScript er under utvikling.

Fordeler: • Kan koble til via Wi-Fi og Bluetooth i tillegg til kablede nettverk.• Støtte for mange ulike enheter fra en rekke ulike leverandører.• Støtter et bredt utvalg av forskjellige teknologier og operativsystemer.

Ulemper:

• Støtter ikke HTTP

3.4.4 Brillo

Project Brillo er Googles Android-baserte IoT løsning. Det er tilsiktet lav-energi enheter med begrenset lagring.

Siden Brillo er basert på Android er det open-source, og skrevet i C, C++ og Java.Kommunikasjonsprotokollene som blir benyttet er Bluetooth low energy og Wi-Fi.

� av �30 70

Da Android-økosystemet er såpass stort og utbredt har Brillo store ressurser som drivere og utviklerverktøy tilgjengelig, og det er derfor godt tilrettelagt for utviklere.

Som med vanlig Android utvikling er fragmentering et stort problem, da kun et fåtall har tilgang til seneste versjon. Dette gjør det vanskeligere for utviklere å nå ut til brukerne med produktene sine.

Som en del av Project Brillo har også Google utviklet Weave, som er er trådløs kommunikasjonsplattform for IoT. Som med resten av Project Brillo er Weave open-source og Google ønsker å få flere IoT-aktører til å omfavne teknologien.

Apple har laget en konkurrent til Brillo kalt HomeKit. Denne er innebygd i iOS, og er derfor ikke open-source, og vil kun fungere med Apples enheter og sensorer og produkter godkjent av Apple. Selv om dette vil begrense mulighetene vil det øke kvaliteten og sikkerheten.

3.4.5 Open Connectivity Foundation/Open Interconnect Consortium

Open Interconnect Consortium, eller OIC er en industrigruppe grunnlagt i 2014 av Intel, Broadcom og Samsung. OIC ble grunnlagt med målet å gjøre IoT en realitet, og jobber med å utvikle standarder og sertifiseringer for enheter.I februar 2016 byttet OIC navn til Open Connectivity Foundation, og Microsoft, Qualcomm og Electrolux ble medlemmer. De har til sammen mer enn 80 medlemmer.

3.4.6 Wi-Fi

FIGUR 16. WIFI LOGO

Wi-Fi er et trådløst nettverk for kommunikasjon mellom enheter basert på IEEE 802.11 24

standarden.Det gjør det mulig for enheter å kobles til et trådløs nettverk gjennom et aksesspunkt. Dette kalles et WLAN (Wireless Local Area Network).

Rekkevidden på et vanlig hjemmenettverk er på ca. 100 meter uten hindringer, avhengig av ruteren/aksesspunktet som blir brukt. Med en ekstern forsterket antenne kan rekkevidden forbedres opp til mange kilometer. Rekkevidden kan også forbedres med flere aksesspunkt på samme nettverk.

Sikkerheten ved Wi-Fi er ikke like god som ved kablede nettverk, og i teorien kan hvem som helst med en antenne få tilgang til nettverket. Det er en rekke sikkerhetstiltak som er mulige å benytte seg av, blant annet kryptering via WEP (Wired Equivalent Privacy), WPA

http://www.wi-fi.org24

� av �31 70

(Wi-Fi Protected Access) og WPA2. WPA2 er den sikreste, og derfor mest anbefalte av disse.

Wi-Fi Direct er en egen Wi-Fi standard for tilkobling av enheter uten aksesspunkt (ruter). 25

Det som skiller ut dette fra for eksempel Bluetooth er at det kun kreves at 1 av enhetene som skal tilkobles har støtte for Wi-Fi Direct, siden denne enheten da vil fungere som aksesspunkt for de andre. Dette gjør tilkobling og oppsett meget lettvint. Eksperter sier at dette vil kunne erstatte Bluetooth i flere situasjoner grunnet enkeltheten i bruk.Bruksområder i tillegg til internet of things er blant annet deling av internett-tilkobling. Dette fungerer ved at en enhet som er koblet til internett oppretter en tilkobling med en enhet via Wi-Fi Direct, og den tilkoblede enheten får tilgang til den andres internettilkobling. De fleste nyere smarttelefoner og datamaskiner har denne teknologien innebygd.

Fordeler:

• Raskt og lettvint• Billig. Oppsett av et Wi-Fi nettverk er relativt rimelig, og finnes etterhvert i de fleste hjem.• Stor utbredelse. De fleste hjem og bedrifter benytter seg av denne standarden

Ulemper:

• Sikkerheten er ikke så stor som på et kablet nettverk• Rekkevidden og hastigheten blir fort påvirket ved forstyrrelser/hindringer.

3.4.7 Bluetooth

FIGUR 17. BLUETOOTH LOGO

Bluetooth 4.0 , også kalt Bluetooth smart, er en versjon av Bluetooth som er fokusert på 26

energibesparelse. Tiltenkt bruk av denne versjonen er helse, signaler, sikkerhet og underholding for hjemmet.

Bluetooth er en trådløs teknologi som bruker radiobølger for å føre over data fra en maskin til en annen. Bluetooth blir brukt fra alt til å føre over bilder fra en mobil til en laptop, oppkobling fra mobil til en bil, eller føre over sanger fra laptop til trådløs høyttaler. Smartklokker er også koblet til mobilen med Bluetooth. Bluetooth kobles opp ved hjelp av at en sender ut signaler som en annen Bluetooth enhet kan bruke for å koble seg til. Etter oppkobling kan man sende data fra en maskin til en annen. Kommunikasjonen går over en frekvens som er i mellom 2,4 og 2,285 GHz, og har normalt en rekkevidde på ca 10 meter. Rekkevidden kan være opp til 100 meter med en veldig god antenne.

http://www.wi-fi.org/discover-wi-fi/wi-fi-direct25

https://www.bluetooth.com26

� av �32 70

Fordelene med Bluetooth er at tilkoblede enheter ikke er avhengig av å være i siktlinje med hverandre, og kan være i forskjellige rom hvis ikke avstanden er for stor. Tilkobling er lagt opp for å være veldig enkelt, og krever veldig få steg. Signalforstyrrelser er heller ikke noe problem, blant annet på grunn av signaler som bruker lav frekvens og liten energi, i tillegg til frekvenshopping.

En av de største ulempene er rekkevidden, spesielt i forhold til Wi-Fi. Maksimal rekkevidde med kraftige nok radioer er ca. 100 meter. Det samme gjelder overføringshastigheten på ca. 25 Mbps som ikke kan måle seg med Wi-Fi på ca. 250 Mbps. Sikkerheten er god, men ikke like god som andre konkurrenter.

3.4.8 NFC

FIGUR 18. NFC LOGO

NFC (Near Field Communication) er kommunikasjonsstandard som bruker radiobølger 27

for å sende små mengder data. Enheter som oftest blir brukt til dette er mobiltelefoner. Det har også blitt vanlig og ha dette på bankkortet. Når man bruker NFC med bankkort slipper man å bruke kode ved små summer som skal betales. Denne løsningen med bankkort har blitt utnyttet av kriminelle. NFC krever at enheter som skal kommunisere er veldig nære hverandre (maksimum 10 cm fra hverandre).

NFC er basert på RFID (Radio-Frequency identifications Technology). RFID har lengre rekkevidde og blir brukt til blant annet AutoPass til bilen. NFC sender på frekvensen 13,56 MHz. Overføringshastigheten varierer fra 106kbit/s til 424 kbit/s. NFC bruker radio frekvenser som kan drive en NFC tag som ikke har strømforsyning. Dette medfører at man kan bruke NFC i blant annet bankkort, mobildeksler og klistremerker. I NFC sammenheng blir dette kalt passive mode. NFC kan også brukes til peer-to-peer kommunikasjon, men da må begge NFC objekter ha egen strømforsyning. Dette kalles active mode. NFC tagger er som regel bare lesbare, men man kan få tak i tagger som kan skrives til også.

Fordeler:

• Lite energikrevende• Tilgjengelighet. Bruken er på vei oppover, men er ikke veldig utbredt enda.• Sikkerhet. NFC benytter seg av god kryptering, og grunnet begrenset rekkevidde er

hacking vanskelig• Begrenset rekkevidde

https://en.wikipedia.org/wiki/Near_field_communication27

� av �33 70

Ulemper:

• Begrenset rekkevidde• Sikkerhet. På grunn av bruk i blant annet betaling blir store mengder personlig data

lagret på brukerens enheter, og disse dataene kan stjeles hvis enheten kommer i gale hender.

3.4.9 HTTP

Hypertext Transfer Protocol er det som primært blir brukt på internett for å utveksle 28

informasjon. HTTP er en forespørsel/respons protokoll mellom klienter og tjener. En sikrere, kryptert versjon kalles HTTPS, der S-en er en forkortelse for Secure.Denne er anbefalt brukt ved blant annet overføring av personlig informasjon, og benyttes i blant annet banktjenester.

Ulempene med HTTP er at hastigheten kan fort bli påvirket ved mange forespørsler.HTTP "antar" også at alle pakker kommer frem som de skal, og har ikke noe system for å kontrollere dette.

3.4.10 FTP

FTP (File Transfer Protocol) er en protokoll standard som brukes til filoverføringer. Denne 29

protokolstandarden ligger i applikasjonslaget. FTP ble først brukt i NCP baserte nettverk på 1980 tallet med brukes nå i sammenheng med TCP/IP baserte nettverk. FTP bruker en server og en klient. Maskinen som er serveren ligger å lytter på nettverket, imens klienten kobler seg opp til server. Protokollen definerer at kommunikasjonen imellom klient og tjener skal skje igjennom port 20 og 21. Port 21 er en kontrollport. Denne blir brukt for å sende kommandoer fra klient til tjener som tjeneren svarer på. Port 20 er porten som blir brukt til selve filoverføringen.

En fordel med FTP er at det er open source. Det at FTP er open source gjør at løsningen er billig. FTP følger som regel med i programmer, eller man kan finne gratis FTP programmer på nett.

Alt av kommunikasjon som skjer imellom partene er ukryptert. Dette gjør det lett for en utenforstående til å lese dataene som blir sendt. Med FTP kan man sende en fil fra server til en tredje maskin. Dette er både en positiv og negativ egenskap. Det gjør det lettere å dele filer med andre, men dette har også blitt et problem med tanke på ulovlig virksomhet.

3.4.11 MQTT

MQTT (Message Queue Telemetry Transport), ISO standard 20922, er en "lettvekts" 30

meldingsprotokoll for bruk over TCP/IP protokollen. Den er publish-subscripe basert og designet for tilkoblinger der det skal overføres små mengder data eller nettverkshastigheten er begrenset.

https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol28

https://no.wikipedia.org/wiki/FTP29

http://mqtt.org30

� av �34 70

MQTT ble originalt utviklet av IBM, men er nå en åpen standard.

Fordeler:

• Da de er publish-subscribe basert vil alle som abbonerer ("subscribe") på en tjeneste automatisk motta dataene.

Ulemper:

• TCP gjør at tilkoblingen alltid er på, noe som påvirker energibruken på tilkoblede enheter.

• Mangler kryptering da dette ville påvirke målet om at tjenesten skulle være "lettvekt".For å unngå dette problemet kan MQTT-S som kommuniserer med UDP benyttes.

3.4.12 Konklusjon

Etter å ha forsket på hvilke eksisterende løsninger som finnes i dag har gruppen inntrykk av at internet of things er en teknologi som er under vekst. Det finnes ingen klar markedsleder, og man ser store bedrifter satse på flere løsninger som er sammenlignbare. Det er også mange, for eksempel Apple og Google, som utvikler sine helt egne løsninger.

De fleste løsningene vi har sett på gjør veldig mye riktig, men siden alle har forskjellige svakheter er det vanskelig å trekke noen konklusjon om hvem som er best.AllJoyn var et alternativ som kunne vært aktuelt hvis den hadde hatt Bluetooth støtte. Ettersom sensorene som vi skulle bruke kun har Bluetooth ble ikke AllJoyn valgt i denne prototypen.IoTivity er den av tjenestene vi har funnet som vi likte best. Den har støtte fra mange forskjellige selskaper som gjør at utvalget som enheter er stor. Den har også rikelig med kommunikasjonteknologier, spesielt Bluetooth som AllJoyn mangler. Det er denne mangelen som gjør at AllJoyn ikke går helt til topps.

Det er også mange forskjellige kommunikasjonsteknologier, og det er de 2 største som vi ønsker å trekke fram som de "beste", Wi-Fi og bluetooth. Dette er på grunn av stor utbredelse, god rekkevidde og lettvint tilkobling av enheter.Bluetooth er en teknologi vi kommer til å bruke ettersom sensorene vi bruker kommuniserer ved hjelp av Bluetooth. NFC er derfor ikke så aktuelt å bruke i prototypen vi skal lage. NFC har kort rekkevidde også noe som ikke er gunstig i vår prototype. I andre løsninger kan NFC være aktuelt å bruke til f.eks. tilkobling til andre teknologier med lengre rekkevidde. Denne teknologien er allerede i bruk i blant annet trådløse høyttalere og headset.Wi-Fi blir heller ikke aktuelt prototypen ettersom sensoren kun har Bluetooth. Wi-Fi adapter er benyttet på huben for å laste opp til database og koble seg til nettet for fjerntilkobling, men dette er ikke noe krav, og kablet nettverk hadde utført de samme tjenestene.

MQTT blir vurdert, og også trukket frem av oppdragsgiver som noe de kunne tenkte seg å se i bruk.

� av �35 70

3.5 Prosjekt del 2

3.5.1 Introduksjon

Del 2 av prosjektet besto av å implementere en internet of things prototype.Denne prototypen skulle bestå av en hub som skulle hente sensordata og lagre det i en database.Dataene skulle hentes ut og vises i en portal. Kravene for prototypen er beskrevet i detalj i kravspesifikasjonen.Vi valgte å dele prototypen opp i 3 deler, hub, backend og portal, disse er beskrevet i detalj under.

Huben er en Raspberry Pi 2 Model B, se nærmere beskrivelse i 3.3 Valg av teknologi.Oppgaven til denne delen av prototypen er kommunikasjon med sensorene for innsamling av data, samt opplasting til database.

Backend-delen består av et REST API som henter ut ønsket data fra databasen og overfører den som JSON til portalen. Vi prøvde en rekke teknologier for å finne det beste alternativet, og endte opp med Java. Dette grunnet kommunikasjon med dashDB som fungerte best med Java og JDBC.

Portalen er laget i AngularJS (Se 3.3 Valg av teknologi), og kommuniserer med backend for å hente ut ønsket data og viser det i nettleseren, enten i tabellform eller grafisk.

3.5.2 Hub

Hubens jobb er å samle inn data fra sensoren og lagre disse i en database. Dette gjør den ved hjelp av et javaprogram som kjører et Python script og håndterer databaselagring. Javaprogrammet starter med å koble seg opp mot en database. Etter tilkoblingen til databasen er opprettet starter den pythonscriptet. Python scriptet kobler seg opp til sensoren ved hjelp av en Bluetooth tilkobling. Når tilkoblingen er utført henter scriptet ut data fra sensoren og skriver dataene til en tekstfil. Etter at pythonscriptet er kjørt fortsetter javaprogrammet med å lese fra tekstfilen og sender disse til en database. Javaprogrammet kjører 5 målinger etter hverandre slik programmet er kodet nå.Antall sensorer og målinger kan lett endres etter ønske.

Pythonscriptet krever grensesnittet bluepy som legger til støtte for Bluetooth Low Energy 31

og funksjoner for kommunikasjon med TI SensorTag. Oppsett av dette er beskrevet i brukerveiledningen.

Python ble brukt for å kommunisere med sensorene da det var dette Texas Instruments hadde mest støtte og informasjon rundt, samt at alternativene vi så på var mye vanskeligere i bruk.

Tidligere i prosjektet har vi prøvd ut flere løsninger på å samle inn data. Vi har blant annet prøvd å både samle inn dataene og å lagre dataene i enten javaprogrammet eller pythonscriptet. Når vi prøvde dette med javaprogrammet fant vi ut at

https://github.com/IanHarvey/bluepy31

� av �36 70

det ble ekstremt mye kode for å gjøre samme jobben som noen få linjer med Python gjorde. Når vi prøvde å gjøre alt med pythonscriptet var det databasehåndtering som var utfordringen. Databasen vi benyttet oss av, dashDB, fungerer best med Java og JDBC tilkobling, og tilhørende drivere er også lagt opp for bruk med Java. Det eneste vi måtte gjøre for å få databasetilkoblingen til å virke med java var å legge til en driver i form av en jar fil i Java Classpath.

MQTT ble nevnt som et alternativ av oppdragsgiver, og de informerte om at dette var noe de var interessert i mulighetene rundt. Implementering av dette hadde vært relativt enkelt å få til via IBMs Internet Of Things Platform i Bluemix. Gruppen så på dette, men valgte å gå bort ifra det da det ikke føltes riktig å bruke denne tjenesten i et prosjekt som denne. I denne tjenesten kan enheter enkelt legges til og målinger startes. Å lage en løsning med MQTT fra bunnen av som hadde passet bedre inn i prosjektet hadde blitt for tidkrevende ut ifra tidsplanen.

FIGUR 19. ET UTDRAG FRA JAVAPROGRAMMET I HUBEN. VISER HVORDAN TILKOBLINGEN TIL DATABASEN ER KODET.

Javaprogrammet kan bli kjørt ved hjelp av SSH. Dette gjør at man kan kjøre hele løsningen fra en maskin.

� av �37 70

FIGUR 20. UTDRAG FRA PYTHONSCRIPTET. VISER TILKOBLINGEN TIL SENSOREN OG UTHENTINGEN AV DATA

FIGUR 21. KJØRING AV SENSORMÅLING VIA SSH.

� av �38 70

3.5.3 Backend/REST API

Backend løsningen i prosjektet består av et REST API kodet i Java.Som med koden for opplastning ble Java valgt her på grunn av kommunikasjonen med dashDB databasen via JDBC.

Tidlig i prosessen hadde gruppen utfordringer med å lage et API som fungerte slik vi ønsket det, og en rekke løsninger ble forsøkt laget i PHP, Python og .NET. Ingen av disse var tilfredsstillende nok til at vi valgte å gå videre med de.

Jobben til backend er å håndtere databasekallene for å hente ut dataene fra databasen og gjør om dataene til JSON objekter. Frontend bruker disse objektene for å vise frem data.På figuren under ser man et utdrag fra controlleren i backend. @Path variabelen brukes for å kontrollere hva kontrolleren skal gjøre basert på hva som blir tastet inn i URLen. Et eksempel på en URL som vil føre til at man kommer inn i kodeutraget under er http://localhost:8080/Backend/REST/sensordata/all. Som man kan se ut i fra denne URLen ender den med /all. @Produces variabelen forteller hvilken type returdata som skal forventes. På figuren under vil dette være et eller flere JSON objekter.

FIGUR 22. UTDRAG FRA BACKEND CONTROLLER. KODE SOM VISER HVORDAN URL-EN PÅVIRKER HVA SOM BLIR VIST

APIet består av en Application klasse som starter opp APIet, en controller, SensordataController, som håndterer HTTP-forespørslene og en egen klasse for kommunikasjon med databasen, DBConnection. Det er i tillegg en modell for dataene kalt SensorTagDataKoden fungerer slik at controlleren får en forespørsel, og kjører riktig metode ut ifra denne. Metodene er satt opp slik at de kjører en forespørsel i DBConnection ut ifra ønsket data. I DBConnection kjøres en spørring til databasen og dataobjektene blir lagt inn i en ArrayList som returneres til controlleren. Tilbake i controlleren gjøres disse objektene om til JSON-objekter og sendes videre av APIet slik at portalen kan bruke dataene.

� av �39 70

Det er laget funksjoner for å hente ut alle data, datamålinger utført i dag, siste måling, målinger der romtemperaturen er høyere enn en ønsket verdi samt et oppsett for ZingChart som inneholder romtemperatur og tilhørende DateTime-verdier.

3.5.4 Portal

Portalen viser frem innsamlet data i en nettleser. Oppdragsgiver hadde som ønske at vi brukte AngularJS eller Meteor som løsning her, da begge er gode alternativer for å skape dynamiske webapplikasjoner.

FIGUR 23. SKJERMDUMP FRA PORTAL SOM VISER TABELL OG GRAF

Da hovedfokuset ikke var på design for denne delen begynte utviklingen med å se på muligheter for kommunikasjon med databasen. Vi så først på muligheter for å koble til databasen direkte i portalen, men fant fort ut at dette ikke var noen god løsning, og at REST var veien å gå (Se 3.5.3 Backend).

� av �40 70

Da ingen i gruppen hadde noe erfaring med AngularJS brukte vi den første tiden til å sette oss inn i hvordan dette fungerte. Vi benyttet oss av instruksjonene på AngularJS sin 32

hjemmeside og tutorialen til W3Schools .33

Portalen består av et view, index.html, 1 module, definert i Portal.js, og 1 controller, PortalController.

Modulen er definert slik:

var app = angular.module("Portal", ['ngRoute', 'zingchart-angularjs']);

For henting av data brukes Angulars $http GET metode:

FIGUR 24. $HTTP GET EKSEMPEL

Variabelen url er URL-en fra REST APIet. Denne varierer fra hvilke data man ønsker å hente ut. I vår løsning vil for eksempel URL-en http://localhost:8080/Backend/REST/sensordata/all returnere alle sensormålingene som er utført som et JSON-objekt. For at dette skal fungere må $http også legges ved som variabel ved definisjon av controlleren:

app.controller("PortalController", ["$scope", "$http", function ($scope, $http) {

Løsningen vår inneholder funksjoner for å hente ut alle dataene, siste måling, målinger utført i dag og målinger der romtemperaturer er høyere enn ønsket verdi. APIet returnerer i tillegg en JSON streng som er formulert for å lage en graf med ZingChart.

Viewet er relativt enkelt, og inneholder i tillegg til menyen kun en tabell for å vise dataene og en div-tag der ZingChart-grafen lastes inn. Disse vises/skjules etter hva man velger å vise ved hjelp at en if (ng-if) som kjøres på HTML-taggene ved hjelp av variabler satt i controlleren.

Dataene vises i tabellen ved hjelp av en for-each løkke, kalt ng-repeat i AngularJS, som kjøres på data-objektet hentet fra backend. Utdraget av koden under viser div-tagen for grafen og tabellen. Class variablene som vises for noen av taggene er for Bootstrap (Se 3.3.8).

https://docs.angularjs.org/tutorial32

http://www.w3schools.com/angular/33

� av �41 70

FIGUR 25. UTDRAG FRA INDEX SOM VISER KODE FOR VISNING AV DATA

ZingChart kan defineres og tilpasses på en rekke måter. Da vi henter ut dataene som skal vises fra backend har vi valgt å opprette dataobjektet som ZingChart bruker også her.Det er i dette objektet vi bestemmer hvilke funksjoner vi ønsker og utseendet på grafen.

FIGUR 26. OPPRETTING AV ZINGCHART-GRAF

I figuren over ser man koden for å opprette ("rendre") grafen i controlleren i portalen. Her defineres navnet og størrelsen, og URL-en fra REST APIet vises også her. Objektet som returneres av APIet ser slik ut:

� av �42 70

{"type": "line",refresh: 10000, "plotarea": { "adjust-layout": true},"scroll-x":{

},"scale-x": { "zooming":true, "labels": ["2016-04-28 09:53:53.0", "2016-04-28 09:53:59.0", "2016-04-28 09:54:05.0", "2016-04-28 09:54:11.0", "2016-04-28 09:54:21.0"]},"crosshair-x":{ "plot-label":{ "text":"%v" }, "scale-label":{ "text":"%l"}},"crosshair-y":{ "type": "multiple", "scale-label":{ "visible":false}},"series": [{ "values": [23.9687, 23.9687, 23.9687, 23.9687, 23.9687]}]}

Her ser man dataene som skal vises ("labels" og "values"), hvilken type graf det er snakk om ("type": "line"), hva vi ønsker skal vises når musen dras over grafen ("scale-label") og at vi ønsker at det vises et trådkors for å lettere følge dataene ("crosshair-x" og "crosshair-y"). Vi har også valgt at grafen skal oppdateres hvert 10. sekund ("refresh: 10000", der tiden er i ms) og at man skal kunne zoome på x-aksen ("scale-x": { "zooming":true,"). Dette er bare noen få av veldig mange muligheter og type grafer ZingChart tilbyr.

3.5.5 Database

Planen var å bruke Apache Hadoop i kombinasjon med Spark. Vi startet med å lese oss opp til dette men så ble Apache Hadoop fjernet fra Bluemix litt ut i prosjektperioden. Dette førte til at vi måtte finne en ny løsning for vår prototype. Skye snakket med IBM og de kom frem til at dashDB var en god erstatning. Spark ble da ikke nødvendig lengre.Når vi gikk over til dashDB satt vi oss inn i denne løsningen ganske raskt og prøvde oss frem med å legge inn forskjellige data fra sensoren. Vi startet med å legge inn kun datoen og temperaturen. Etter dette la vi til flere datafelter slik at vi kunne legge til blant annet trykk og lysmålinger. Vi fant ut at dato ikke ble presist nok så vi la til klokkeslett også.

� av �43 70

Vi prøvde oss på forskjellige måter å legge til primærnøkkel på, men endte opp med å bruke tiden som primærnøkkel i databasen. SQL setningen som vi brukte for å lage tabellen:CREATE TABLE "SENSORTAGDATA" ("DateTime" VARCHAR(50) not null PRIMARY KEY, "IRTemp_Amb" DECIMAL(6,4), "IRTemp_Obj" DECIMAL(6,4), "Hum_Temp" DECIMAL(6,4), "Hum_Rel" DECIMAL(6,4), "Optical_Light" DECIMAL(10,4),"Baro_Temp" DECIMAL(6,4), "Baro_Press" DECIMAL(8,4));Forklaring på hva de forskjellige forkortelsene og målingen betyr:IRTemp_Amb: Romtemperatur, måles i °C.IRTemp_Obj: Objekttemperatur, måles i °C.Hum_Temp: Temperatur beregnet utifra luftfuktighet, måles i °C.Hum_Rel: Luftfuktighet, måles i %RH.Optical_Light: Lysstyrke, måles i lux.Baro_Temp: Temperatur beregnet ut i fra barometrisk trykk, måles i °C.Baro_Press: Barometrisk trykk, måles i hPa.Når vi valgte typen dataene skulle være i databasen prøvde vi litt forskjellige ting, men kom frem til at Decimal var det som funket best i denne sammenhengen med tanke på sortering og søking ved fremvisning.

3.5.6 SikkerhetdashDB databasen er kryptert med AES som standard med en 256-bits nøkkel.Den har også innebygget avansert aksesskontroll og brannmur for å hindre lytting på porter ved tilkobling.I prototypen så bruker vi Texas Instruments SimpleLink SensorTag som er et utviklingsverktøy. Sikkerhet er derfor ikke høyt prioritert.Det samme gjelder for hele prosjektet. Da bakgrunnen for løsningen er å vise frem muligheter med teknologien rundt internet of things, og ikke er en løsning som skal settes i produksjon har ikke implementering av sikkerhetsløsninger vært noen prioritet. Det er heller ingen ømfiendtlige data som lagres.

3.5.7 Maskin- og programvarekrav

3.5.7.1 Hardware

Løsningen vår krever at man har en hub som står i nærheten av en sensor. I vårt tilfelle er huben en Raspberry pi. Sensoren som vi bruker er en Texas Instruments SimpleLink SensorTag. Prototypen krever at man har en Bluetooth tilkobling på huben. Grunnen til dette er at sensoren som den snakker med kun støtter Bluetooth som tilkobling. Huben må også ha internett tilkobling slik at huben kan laste opp dataene til databasen.

� av �44 70

For å kjøre backend løsningen og portalen trenger man en relativt moderne pc som kan kjøre en virtuell server.

3.5.7.2 SoftwarePå huben må det være installert Java og den må ha en driver for å kunne kommunisere med databasen. Driveren kan lastes ned fra IBM og legges inn i pathen hvor Java er installert. Denne driveren er en jar fil som heter "db2jcc4.jar". Python må også være installert på huben. For at pythonscriptet på huben skal kunne snakke med sensoren må bluepy importeres. Bluepy er et bibliotek med funksjoner som gjør at man blant annet kan hente ut informasjon fra sensoren. Bluepy kan lastes ned ifra https://github.com/IanHarvey/bluepy. Dette biblioteket må ligge sammen med pythonscriptet.Denne løsningen krever at man har Glassfish eller annet server simulator verktøy installert på maskinen for å få kjørt backend. Man kan også ha en server som man kjører løsningen på. For å få kontakt med databasen i javaprogrammet og i backend må man ha en driver. Denne driveren er en jarfil som man legger inn i Java pathen på maskinen programmene skal kjøre på. Denne jarfilen heter db2jcc4.jar. Denne filen er en driver til IBMs dashDB, og kan lastes ned fra dashDB på Bluemix.

Node.js, npm og Bower kreves for å kjøre portalen. For å installere dette må man laste ned og installere Node.js (npm er inkludert). Bower installerer man ved hjelp av terminalen i IntelliJ med npm. Installasjon av dette varierer avhengig av hvilket system og programvare/IDE man bruker.

� av �45 70

4 TestdokumentasjonI denne delen vil vi gå igjennom hvordan og hvilke tester som ble utført i dette prosjektet. Det finnes flere typer tester som kan utføres for å kontrollere at løsningen fungerer som tiltenkt.

I programvareutvikling vil det kunne oppstå potensielle feil over alt, og det er derfor veldig viktig å ha et fokus på testing og kontrollere at funksjoner fungerer som tiltenkt. Det er flere typer feil som kan oppstå, alt fra syntaksfeil der man får opp feilen med en gang (programvaren vil ikke kjøre), ned til mindre feil, kalt bugs, som kan være vanskelig å finne. Konsekvensene av feil kan også være potensielt høye, og kan for eksempel føre til sikkerhetshull slik at man blir utsatt for angrep.

4.1 EnhetstestingI enhetstesting går man igjennom alle funksjonene i løsningen ved at man lager testvariabler for å se om man får de sluttverdiene man er ute etter. Vi har kjørt tester opp mot backend, som består av et REST API, og frontend. Vi har også testet diverse databasekall opp mot dashDB databasen.

4.2 Brukertesting

Brukertesting er testing der en person prøver å bruke alle funksjonene i programvaren.Dette er ikke så viktig i en prototype-løsning slik som vår, spesielt der vi ikke har noen tiltenkte brukere annet enn oppdragsgiver. Gruppen har allikevel utført noen enkle brukertester. Gruppemedlemmene har selv testet, og venner og familie med forskjellige datakunnskaper har også utført tester.I tillegg til dette har gruppen fått forskjellige tilbakemeldinger fra oppdragsgiver og veileder der underveis. En av feilene som kom fram under testingen var at dagens data viste frem feil data. Det viste seg at det var noe feil i datosammenligningen. Dette ble rettet opp fort. Det var få feil som kom frem under brukertestingen. Gruppen antar at dette er grunnet stor fokus på ad-hoc testingen underveis. Vi føler at dette trolig gikk en del utover testingsdokumentasjonen også.

4.3 Ad-hoc testing

Ad-hoc testing er testing som utføres uten en detaljert plan og konkrete krav. Dette er også improvisert testing som ofte kjøres bare en gang. Testene blir kjørt "der og da" for å se om noen feil oppstår.Vi brukte denne testingen en del tidlig i prosjektfasen når forskjellige teknologier ble utprøvd, og det viktigste var å se om teknologien eller funksjonen vi testet var noe som kunne brukes videre.

4.4 TestresultaterVi kjørte noen funksjonstester. I tabellen under ser man hvilke tester som ble kjørt, hva vi forventet som resultat og hva resultatet ble. Vi testet også om dataene som ble hentet inn med huben ble lagret på riktig måte. Alle testene som blir gjort på portalen er avhengig av at funksjonene i backend/REST APIet funker som de skal. Grunnen til dette er at databasekallene blir utført i backend/REST APIet.

� av �46 70

Tabell 4: Testresultater Test Utførelse Forventet resultat Resultat

Hub/Sensor: Sjekk om vi får kontakt med sensor og at vi får lesbare data fra sensoren

Kjøre Python-scriptet som kontakter sensoren og skriver resultatet til tekstfil.

Data fra sensoren blir hentet ut og skrevet til tekstfil. Dataene er også leselige

I første test er noen data uforståelige. Vi gjør endringer med formateringen av utskriften i scriptet og kjører testen igjen. Denne gangen blir alt leselig og korrekt.

Hub/Database: Sjekk om vi får kontakt med databasen og om vi kan legge til data i databasen.

Lager en test SQL setning i javaprogrammet som setter inn data i databasen.

Dataene som ligger i test SQL setningen blir lagret i databasen.

Dataene ble lagret i databasen.

Hub: Sjekk om lagring av innsamlet data ble lagret på riktig måte.

Samler inn data fra sensor ved hjelp av huben og lagret dataene i databasen.

Dataene skal bli lagret i riktig format og på riktig plass.

Dataene ble lagret i riktig format, men ikke på riktig plass første gang vi kjørte testen. Vi endret koden for innsetting av data og kjørte testen igjen. Da stemte også plasseringen av dataene.

Portal/Backend: Vise alle dataene som ligger i databasen.

Kjøre backend/REST API og portalen. Deretter gå inn på "Alle" valget på menylinjen og sammenligne resultater med dataene i databasen.

Alle dataene i databasen skal bli vist frem i en tabell i portalen.

Alle dataene ble vist frem i en tabell i portalen.

Portal/Backend: Vise frem siste måling som er utført.

Kjøre backend/REST API og portalen. Deretter gå inn på "Siste" valget på menylinjen og sammenligne målingen med den siste målingen som ble lagt inn i databasen.

Målingen som blir vist i portalen er den samme som målingen som er lagt til sist i databasen.

Første gang vi kjørte testen viste portalen frem den første målingen som hadde blitt gjort. Litt endringer i koden ble gjort og vi kjørte testen igjen. Da viste den rikitig måling.

� av �47 70

4.5 KonklusjonTesting er meget viktig for at løsningen skal fungere som ønsket, og uten systematisk testing fra starten av prosjektperioden vil det fort kunne oppstå feil som er for store til å rette opp som kunne ha vært fikset tidligere. Siden vi jobber med en streng tidsplan er det også viktig å gjøre testingen en del av denne.

Selv om vi i vårt tilfelle kun lager en prototype er det allikevel viktig at en ferdig løsning ikke inneholder feil, dette vil kunne gå utover brukeropplevelsen til kunden, og også kredibiliteten til utvikler.

Portal/Backend: Vise frem målinger som har blitt utført i dag.

Kjøre backend/REST API og portalen. Deretter gå inn på "I dag" valget på menylinjen og sammenligne målingene som blir vist med målingene som har blitt lagt inn i databasen i dag.

Målingene som blir vist i portalen skal være de samme som målingene som har blitt lagt til i tabellen i dag.

Målingene som ble vist frem var de samme som var lagt inn i databasen denne dagen.

Portal/Backend: Vise frem målinger som er høyere enn gitt som søkestreng i søkefunksjonen

Kjøre backend/REST API og portalen. Skriv inn 22 i søkefeltet i portalen og trykk på "Vis" ved siden av søkefeltet. Sammenlign målingene som blir vist med målingene som har høyere romtemperatur enn 22 °C.

Målingene som blir vist skal være alle målinger med romtemperatur på over 22 °C.

Målingene som ble vist frem er de samme som har romtemperatur på over 22 °C i databasen.

Portal/Backend: Kontrollere at data vises korrekt i ZingChart-graf

Sammenligne data som vises i grafen med data i tabellen i portalen.

Dataene er identiske.

Data som vises i grafen er identiske med data i tabellen. Data kommer ut i riktig rekkefølge, og dato/tid har samme verdier.

Test Utførelse Forventet resultat Resultat

� av �48 70

5 Brukerveiledning og installasjon5.1 InstallasjonDette er en detaljert brukerveiledning av hvordan man skal sette opp prototypen og hvordan man skal kjøre den.

For kommunikasjon med databasen kreves driveren db2jcc4.jar. Denne er vedlagt leveringen i Hub mappen, men må også legges til i Java-Classpath. Lokasjonen av denne varierer fra system til system.Man kan finne en guide til hvordan dette gjøres på Windows på forskjellige fra javapapers her:http://javapapers.com/java/java-classpath/

Figurene i brukerveiledningen blir vist for kjøring av prototypen med IntelliJ IDEA 16 på Mac OS X El Capitan. Oppsett på Windows er tilnærmet identisk. Kjøring på andre IDE-er enn IntelliJ kan være noe forskjellig.

5.1.1 HubMappen Hub i innleveringen inneholder alle filer som trengs for å kjøre programmet. Det eneste som må gjøres er å legge til db2jcc4.jar filen i Java-classpath på huben. Får å kjøre programmet for å hente data fra sensoren må man kjøre javaprogrammet via terminalen på huben eller kjøre det fra en annen maskin via SSH.

Man trenger IP-adressen til huben for å kunne koble til via SSH. For å finne denne kan man taste inn kommandoen hostname -I.

5.1.2 Portal

Det forventes at npm, Bower og Node.js er installert før portalen kan kjøres, da dette varierer en del avhengig av hvilket system man bruker. En guide for oppsett av npm, Node.js og Bower med IntelliJ IDEA 2016 skrevet av JetBrains finnes her:https://www.jetbrains.com/help/idea/2016.1/using-angularjs.htmlDenne brukerveiledningen viser hvordan man legge til riktig konfigurasjoner og kjøre portalen fra IntelliJ IDEA. Start med å åpne Portal prosjektet i IntelliJ IDEA og velg Edit Configurations. Trykk på det grønne plusstegnet øverst i venstre hjørne og velg npm. Ligger ikke npm i listen er ikke npm installert og da må man legge til dette først. Etter man har valgt npm kommer man til vinduet som vises på figuren under. Husk å sett "Script" til valget start. Trykk "Apply" og "OK". Backend må kjøre for at portalen skal kunne vise data. Etter at man har kjørt backend kan man kjøre portalen. Man starter denne ved å trykke på det grønne "play"-tegnet øverst i menylinjen, til høyre for navnet man gav npm konfigurasjonen.

� av �49 70

FIGUR 27. KONFIGURASJON FOR KJØRING AV PORTAL

5.1.3 Backend/REST API

Denne brukerveiledningen går utifra at man bruker IntelliJ IDEA for å kjøre løsningen og at man har installert Glassfish. Først åpner man prosjektet ved å velge pom.xml filen og velge åpne.

� av �50 70

FIGUR 28. ÅPNING AV PROSJEKTET BACKEND.

Deretter velger man "Edit Configurations". Velg det grønne plusstegnet, og finn Glassfish server og velg "local". Hvis Glassfish ikke ligger her er ikke Glassfish installert på maskinen. Dette må gjøres først.

FIGUR 29. VALG AV GLASSFISH.

Etter man har valgt Glassfish, velg "Deployment" fanen. Trykk på det grønne plusstegnet på høyre side og velg "Backend:war exploded».

� av �51 70

FIGUR 30. VALG AV ARTIFACTVelg "Server" fanen og sørg for at de forskjellige innstillingene er likt det som vises på bildet under.

FIGUR 31. KONFIGURASJON AV BACKEND.

� av �52 70

Trykk "Apply" og "OK". Nå er backend klar til å kjøres. Trykk på den grønne pilen ved siden av "Edit Configurations" for å kjøre backend. Hvis man får problemer med å kjøre prosjektet, prøv å restart IntelliJ IDEA som administrator.

5.1.4 Database

Databasen som blir brukt i denne løsningen er dashDB. For å sette opp databasen må man ha en Bluemix bruker og legge til dashDB fra produkter. Start opp dashDB i Bluemix. Velg "Tables" i menylinjen på venstre side og velg "Add Table". Fyll ut DDL koden for å lage tabellen(Se koden i 3.5.5 Database), og velg "Run DDL". Tabellen er nå laget og klar til bruk. Husk å legge til driveren på huben og på maskinen som kjører backend(db2jcc4.jar).

5.2 Brukerveiledning

5.2.1 Hub

For å kjøre en måling må man først kompilere prosjektet. Dette gjør man med kommandoen sudo javac DBOpplasting.java. Man kjører deretter en måling med kommandoen java DBOpplasting.

For å kjøre via SSH må man åpne et terminal/shell vindu på en enhet som er på samme nettverk som huben. På Mac OS X skriver man inn kommandoen ssh pi@<IP> der <IP> byttes ut med IP-adressen til Raspberry Pi, for eksempel ssh pi@192.168.0.108. Man får da spørsmål om å taste inn passordet på huben. Gruppen benytter seg av standardpassordet som er raspberry. Hvis man bruker Windows må man ha installert PuTTY eller lignende SSH klient. Hvis man bruker PuTTY taster man inn hubens IP-adresse inn i feltet Host Name. Etter dette må man taste inn brukernavn og passord, brukernavn og passord er standardoppsettet pi og raspberry.Når innlogging er utført vil man få opp et terminalvindu.

Når man har koblet seg til navigerer man seg frem til mappen der filene for sensormåling ligger med kommandoen cd Bachelor/Hub og kjører deretter de samme kommandoene som om man skulle ha brukt direkte på huben.

� av �53 70

FIGUR 32. PUTTY SSH-KLIENT PÅ WINDOWS

5.2.2 Backend/REST API

FIGUR 33. MENYLINJE FOR Å KJØRE REST API

For å starte REST APIet trykker man på den grønne "play"-knappen til høyre for navnet på Glassfish-serveren ("Kjør REST API") som vist på figuren. For å stoppe APIet trykker man på den røde "stopp"-knappen (rød firkant) som erstatter knappen for å kjøre i menylinjen.

Man kan også bruke hurtigtastene Shift + F10 på Windows eller Ctrl + R på Mac OS X for å kjøre og hurtigtastene Ctrl + F2 på Windows og cmd + F2 på Mac OS X for å stoppe.

5.2.3 Portal

Portalen er der dataene blir vist frem. I denne deler av brukerveiledningen skal vi gå nærmere inn på hvordan man kommer inn i portalen og hva de forskjellige menyvalgene viser. For å komme inn på portalen må man ha backend kjørende. Når backend kjører så kan man starte opp Portalen. Dette har vi gjort i IntelliJ IDEA(For oppsett, se installasjonsguiden i kapittel 5.1.2 Portal). Trykk kjør eller bruk hurtigtastene (Shift + F10 på Windows eller Ctrl + R på Mac OS X)

� av �54 70

FIGUR 34. MENYLINJE FOR Å KJØRE PORTALEN

Etter Portalen har startet, gå inn på http://localhost:8000/app/ i nettleseren din. Her skal nå portalen dukke opp. På bildet under ser man hvordan menylinjen på Portalen ser ut. Valgene på menylinjen er selvforklarende, men vi skal gå igjennom de forskjellige menyvalgene.

FIGUR 35. MENYLINJEN I PORTALENIoT Portal: Link til forsiden som viser alle målingene som er samlet inn og lagret i databasen.Alle: Viser alle målingene som er samlet inn og lagret i databasen.

FIGUR 36. UTDRAG FRA PORTALEN, VISER ALLE MÅLINGERSiste: Viser den siste målingen som er utført.I dag: Viser målingene som er gjort i dag.Graf: Viser målingene grafisk i et linjediagram. Når man holder datamusen over et punkt på grafen vil den vise romtemperaturen og tidspunktet målingen ble tatt(Se bildet nedenfor). Man kan også zoome. Dette gjør man ved klikke og dra datamusen fra startpunktet til slutt punktet.

� av �55 70

FIGUR 37. UTDRAG FRA PORTALEN, VISER TEMPERATUR OG TIDSPUNKT I LINJEDIAGRAM.

Helt til høyre på menylinjen er det et søkefelt. Søkefeltet brukes til å søke etter målinger som har høyere romtemperaturer en søkestrengen. Et eksempel på dette er hvis man skriver inn 22 grader så vil man få en tabell som kun viser målinger av romtemperatur som er over 22 grader.

FIGUR 38. UTDRAG FRA PORTAL, SØK ETTER ROMTEMPERATUR PÅ OVER 22 GRADER.

� av �56 70

6 Avslutning6.1 Videreutvikling

Da prosjektet er ment som en løsning for å vise frem mulighetene rundt teknologien ser vi på mulighetene for videreutvikling som ganske stor.Man kan utvide systemet slik at man kan hente ut data fra flere sensorer samtidig. I databasen må man legge til sensor ID slik at man kan skille data som kommer fra de forskjellige sensorene. Det eneste som må endres i koden på huben er i Python scriptet. Her må man legge til Bluetooth adressen til hver enkelt enhet og tilhørende kode.

Sensoren som blir brukt i løsningen vår kan måle flere ting enn det vi har valgt å hente ut. Den kan måle blant annet magnetisme og bevegelse. Måling av magnetisme kan for eksempel brukes til innbruddsalarmer. Man kan utvide systemet ved å koble opp vår løsning til en ovn eller lignende for å regulere temperaturen i for eksempel et rom.

Muligheten for å utvide løsningen vår er meget stor. Funksjonene i både REST APIet og portalen kan utvides etter ønske, og koden er meget skalerbar. Funksjoner for å hente ut og sortere data og hvordan de vises er enkelt å legge til. Som nevnt i kapittel 3.3.7 er det også store muligheter med ZingChart.

6.2 Oppnåelse av mål og krav

De fleste funksjonelle kravene er oppfylt. Tolkning av data fra flere plattformer er oppfylt i den forstand at man kan se dataene vist på flere forskjellige typer enheter. Vi har brukt Bootstrap for at løsningen skal skalere utifra blandt annet skjermstørrelse. Dette gjør at dataene kan vises på alt fra en 65 tommers flatskjerm til en mobiltelefon. Analysering av data er oppfylt ved å fremvise dataene på forskjellige måter for å fremheve forskjellige verdier, både sortering i tabell og visning i graf. Utvidelsesmulighetene for dette er også meget stor, og funksjoner kan legges til uten mye jobb etter ønske.

Det var satt et krav for å konfigurere huben, og velge hvilke data som hentes ut, og hvor ofte. Det er mulig å konfigurere dette ved å endre på Python-scriptet som kjøres. Dette krever litt programmeringskunnskaper, og i ettertid kunne dette ha blitt gjort på en lettere og bedre måte. Hadde gruppen hatt mere tid, er dette trolig det første som hadde blitt implementert.

Det samme som over gjelder også kravet om å koble til nye sensorer.

Gruppen føler at alle ikke-funksjonelle krav har blitt oppfylt.

Tekniske krav:

Alle teknologiene gruppen har benyttet seg av er open-source.

� av �57 70

Det ble satt et krav om at Apache Hadoop skulle brukes som database. Som nevnt i propduktdokumentasjonen, ble støtten til denne fjernet, og dashDB ble valgt som erstatter. Vi føler ikke dette hadde noen effekt på sluttresultatet.

6.3 Attest fra oppdragsgiver

Etter at prototypen ble vist frem til oppdragsgiver ønsket gruppen å få tilsendt en attest for arbeidet vi hadde utført. Attesten ligger under Vedlegg, kapittel 8.2.

6.4 Ting vi ville gjort annerledesGruppen skulle ønske at flere ting kunne implementeres i løsningen, blant annet IBMs Internet of things platform på Bluemix. Denne ble valgt bort da det ikke føltes hensiktsmessig i et slikt prosjekt.

Vi ville hatt mer kommunikasjon med rådgiveren for å få en jevn tilbakemelding på hva vil kan gjøre bedre og hva vi burde legge mere fokus på fra et akademisk synspunkt.

6.5 Vurdering av prosjektperioden og konklusjonProsjektperioden har vært utfordrende og krevende, men har også vært morsom og lærerik. Vi har lært om flere nye teknologier som vil være nyttige i arbeidslivet. Det har vært en god opplevelse å få en smakebit på hvordan det kan være i arbeidslivet.

� av �58 70

7 Ordliste%RH - % Relative Humidity, Måleenhet for relativ fuktighet

.Net - Et rammeverk laget av Microsoft for programvareutvikling.

AES - En krypteringsstandard

API - Application Programming Interface, betegner et grensesnitt i en programvare slik spesifikke deler av denne kan aktiveres fra en annen programvare.

CSS - Cascading Style Sheets, et språk for å definere utseendet og stilen til en nettside.

DDL - Data Definition Language, en syntaks for å definere databasetabeller.

HTML - Hypertext Markup Language, et språk for formatering av nettsider.

hPa - Hektopascal, måleenhet for barometrisk trykk.

Hub - En hub er en enhet som brukes til å koble sammen flere enheter i et nettverk, slik at de kan kommunisere med hverandre.

IBM - Forkortelse for International Business Machines, et amerikansk teknologiselskap.

IDE - Integrated Development Environment, programvare som tilbyr verktøy for programvareutvikling.

Lux - Måleenhet for lysstyrke

NCP - Network Control Program, en nettverksprotokoll, forløper til TCP.

SAP - SAP AG. er en tysk programvareleverandør.

SQL - Structured Query Language, et programmeringsspråk for å formulere og kjøre operasjoner mot databaser.

TCP/IP - Transmission Control Protocol/Internet Protocol, en gruppe nettverksprotokoller for å sammenkoble datamaskiner.

UDP - User Datagram Protocol, en meldingsorientert nettverksprotokoll for overføring av informasjon.

XML - Extensible Markup Language, er et markeringsspråk laget for å dele data mellom systemer.

� av �59 70

8 Vedlegg8.1 Dagbok

Dagbok blir kun skrevet for de dagene vi har møte.Gruppen vil jobbe og kommunisere andre dager mellom innleggene.

Tabell 5: DagbokDato Innlegg

13.01 Har møte med Skye. På dette møtet diskuterte vi om interessepunkter og kunnskaper, og Skye fortalte at de hadde sett litt på internet of things som et mulig prosjekt. Vi ble enige om at dette virket som et godt tema, og at de skulle lage et oppgaveforslag.

15.01og

16.01

Vi får tilsendt oppgaveforslag. Sender dette til rådgiver og bacheloransvarlig for tilbakemelding.Gruppen har møte på Skype, og lager prosjektskisse.Gruppen vil begynne med forprosjektrapport til neste gang

19.01 og

21.01

Møtes på Skype og skriver på forprosjektrapport.

27.1. Fullfører og leverer forprosjekt. Informerer oppdragsgiver om dette for å avtale ønsket kick-off møte.

02.02 Kick off møte hos Skye. Møtet handler om å avtale detaljer rundt prosjektet og bli enige om krav.Skrevet under avtale mellom bedrift og HiOA.Mottatt utstyr for å starte opp hovedprosjekt. Møtes etter møtet, setter opp Raspberry Pi og sensorer.Diskuterer og planlegger for videre arbeid.

03.02 Begynner på del 1 av prosjektet.Søker etter eksisterende løsninger innenfor internet of things.Vi vil fortsette med dette til neste gang.

08.02 Gruppen møtes hos Christoffer og fortsetter å kartlegge eksisterende løsninger og begynner å se på kommunikasjonsprotokoller.

16.02 og

18.02

Jobber med kartlegging via Skype.

Planen er å begynne med del 2 til neste gang.

Dato

� av �60 70

22.02 Møtes hos Jon.Begynner på del 2 av prosjektetStarter med å se på muligheter for å kommunisere mellom Raspberry Pi og SensorTag, og ser på hvordan vi kan hente ut data.Får koblet SensorTag til huben.Planen til neste gang er å se på hvordan sensormålinger kan hentes ut.

25.02 Møte på Skype.Fortsetter med kommunikasjon mellom sensor og hub.Begynner å se på hvordan vi skal løse kommunikasjon mellom backend og portal.

03.03 Jobber hos Skye.Holder et kort foredrag om funn gjort i prosjektets første del.Får en liten innføring i IBM Bluemix slik at vi kan sette igang med oppsett av database.Vi vil fortsette med dette fremover og sette oss inn i hvordan Hadoop fungerer.

15.03 Vi møttes i dag for å jobbe med databasen vår. Når vi skulle begynne å jobbe med databasen så vi at Hadoop var fjernet fra IBM Bluemix. Vi kontaktet Skye for å høre hva som har skjedd. Vi begynner isteden med å se på AngularJS og Meteor som er alternativene vi så langt har for bruk i portalen.Mens vi venter på avklaring rundt database vil vi jobbe med portalen og se på løsninger for REST API.

22.03 Møte på Skype. Jobber med AngularJS og prøver oss litt frem med REST.Vi forventer å få avklaring rundt database over påske, og har samtidig avtalt at vi skal møtes hos Skye.

29.03 I dag fikk vi et alternativ til Hadoop av Skye. De hadde snakket med IBM for å få tips om et godt databaseverktøy som kunne passe inn i vår løsning. Skye og IBM hadde da blitt enige om at dashDB var et godt alternativ. Vi begynte å sette oss inn i dashDB. Vi ser mer på dette frem til planlagt møte hos Skye 31.03.

31.03 Kun Jon hos Skye grunnet sykdom.Jobbet med dashDB og REST API sammen med Angular.I dag har vi jobbet med dashDB og REST API sammen med Angular. dashDB bruker en syntaks som er ganske lik SQL men har noen få forskjeller noe som byr på litt utfordringer. Data Definition Language eller DDL som det også kalles er syntaksen som blir brukt i dashDB.Viser frem hva vi har så langt til oppdragsgiver. Får noen tilbakemeldinger.

05.04 Hos Christoffer.Komponentene fungerer nå hver for seg. Begynner å sette disse sammen til en løsning.Dette vil være hovedfokus til neste møte hos Skye.

InnleggDato

� av �61 70

14.04 Møte på Skype.Fortsetter med å få komponentene til å fungere med hverandre. Største utfordring er REST API backend og portal der vi har noen problemer.Planlegger å spørre om hjelp hos Skye.

15.04 Jobbet hos Skye.Dagens fokus har vært å se på muligheter for å kommunisere mellom hub og database med MQTT. Vi har også jobbet med portalen/backend.Vi vil se på MQTT til neste møte også for å se om vi kan finne en god løsning for vårt prosjekt.

19.04 I dag var vi hos Skye for å jobbe med løsningen vår og få litt tilbakemeldinger/hjelp. Hovedfokuset for dagen var å få vist frem dataene på flere forskjellige måter. La til en søke funksjon som viser data som er høyere enn angitt temperatur.

21.04 I dag dro vi inn til Skye igjen for å fortsette med fremvisningsfunksjoner. Fikk lagt til blandt annet en funksjon for å vise frem kun dagens innsamlede data.

26.04 I dag jobbet vi hjemme hos Jon for å gjøre ferdig del 2 av oppgaven.

02.05 og

03.05

Vi har byttet hovedfokuset til rapport. Vi skriver i iCloud Pages slik at vi kan skrive samtidig. Vi snakker sammen over Skype samtidig som vi skriver i rapporten. Avtaler fysisk møte senere hvis vi føler dette blir nødvendig.

06.05 I dag jobbet vi videre med rapporten.

09.05 og

10.05

Disse to dagene har fortsatt å jobbe med rapporten over Skype. Det ble også gjort små endringer og finpuss på designet i frontend på løsningen vår.

12.05 I dag dro vi til Oslo for å vise frem hva som er gjort til rådgiver. Vi viste frem oppgaven til rådgiver og fikk noen tips om hva som burde være med i rapporten. Selve produktet vi har laget virket han positiv til og han sa at prosjektet virket veldig spennende.

14.05, 15.05, 16.05, 17.05,

og 18.05

Disse dagene har vi jobbet med rapporten samtidig som vi har snakket sammen over Skype. Det har vist seg gang på gang at dette er en arbeidsmetode som fungerer veldig godt for oss og vil derfor fortsette med dette.

19.05 Vi dro til Kolbotn for å vise frem produktet vi har laget til Skye. Her viste vi frem kode, forklarte tankegangen i programmet og teknologivalgene som vi har tatt. De var veldig fornøyde med løsningen vi hadde kommet med, og de påpekte at det var imponerende at vi hadde greid å sette oss inn i så mange teknologier som var helt ukjente for oss når prosjektet startet. Oppdragsgiver skulle ettersende attest for vedlegg til rapport før leveringsfristen.

20.05 Vi fortsetter med rapporten og legger til innhold som ble anbefalt av Skye i går.

InnleggDato

� av �62 70

21.05 Rapportarbeidet fortsetter.

22.05 Arbeidet med rapporten fortsetter. Begynner å nærme seg ferdig nå

23.05 I dag har vi gjort siste finpuss på rapporten og levert oppgaven.

InnleggDato

� av �63 70

8.2 Attest fra oppdragsgiver

� av �64 70

OPPDRAGSATTEST

Hovedprosjekt i Informasjonsteknologi

**************************************************************************************************************** Oppdrag: Kartlegge og implementere løsning for samling av sensordata Oppdragsperiode: 13.01.2016 - 24.05.2016 Oppdragsgiver: Skye Solutions AS Utført av: Christoffer André Belgen Fredriksen Jon Gillingsrud **************************************************************************************************************** Oppgaven bestod av:

• Kartlegge: o Kartlegge hvilke åpne standarder som benyttes for sensorer i dag o Kartlegge hvilke kommunikasjonsprotokoller som benyttes i ulike sensortyper, og

fordeler ulemper ved disse § Eksempelvis: WiFi, blåtann, etc.

o Kartlegge hvilke IoT plattformer som finnes hos kommersielle aktører, fordeler og ulemper ved et utvalg av disse, og i hvilken grad disse benytter seg av de åpne standardene funnet over

• Implementere, prototype o Sammenkobling og oppsett av ulike type sensorer o HUB for å samle datafangst for videre lagring i en database

§ Data må kunne konsumeres fra ulike plattformer. HUB-ene kan for eksempel sende XML eller på annen måte http post etc.

§ Det bør være mulig å konfigurere HUB-ene via http kall inn. Eks: hvor ofte en sensor skal hente data og hvilke data etc

o Brukergrensesnitt for å koble til nye sensorer og oppsett av eksisterende o Analyse av datasett

� av �65 70

Skye mener oppgaven er utført på en god måte, og studentene har vist en god evne til å tilegne seg ny informasjon og kunnskap effektivt gjennom både praktiske oppgaver og teori. Det som har blivit lagat är en internet of things lösning med en sensor ifrån Texas Instrument som samlar in temperatur, ljus och fuktighet. Datan skickas vidare till en raspberry Pi 2 som agerar bro-ker, den som samlar in data från sensor och skickar detta till en DashDB database som hostas i IBM Bluemix. Som backend användes ett Java rest api, REST är lätt att utvidga och vidareutveckla på vid senare tillfälle. Som portal blev HTML5/Javascript använd ihop med Angular. I portalen finns det olika funktioner för att sortera och visualisera data från databasen.

Kolbotn, 23.05.2016

______________________________

Lars Martinsen Project and Consultant Manager – Mobile solutions

8.3 Oppgavetekst

� av �66 70

Internet of Things

Bacheloroppgave – Internet of Things

En av de største hypene de siste årene har vært «Internet of things, IoT». Dette er en fellesbetegnelse for sensorer og maskiner som kan koble seg til Internett og overføre informasjon.

Sensorer som er koblet til nettet åpner nye muligheter, men må organiseres og styres gjennom standarder og plattformer for å kunne gi en verdi for brukerne.

Denne oppgaven er todelt, og baseres på en kartleggingsdel for å se nærmere på standarder som benyttes i frittstående sensorer så vel som innebygde sensorer i roboter og maskiner, samt plattformer for å håndtere administrasjon, datakommunikasjon og lagring til databaser eller andre lagringsmedia for videre analyse og bruk.

Del to av oppgaven består i å sette opp en test lab hvor man benytter funnene i kartleggingsfasen, for å implementere sensorer, HUB funksjonalitet, styringsalgoritmer, brukergrensesnitt og datalagring.

Oppgaven består av:

x Kartlegge: o Kartlegge hvilke åpne standarder som benyttes for sensorer i dag o Kartlegge hvilke kommunikasjonsprotokoller som benyttes i ulike

sensortyper, og fordeler ulemper ved disse � Eksempelvis: WiFi, blåtann, etc.

o Kartlegge hvilke IoT plattformer som finnes hos kommersielle aktører, fordeler og ulemper ved et utvalg av disse, og i hvilken grad disse benytter seg av de åpne standardene funnet over

x Implementere, prototype o Sammenkobling og oppsett av ulike type sensorer o HUB for å samle datafangst for videre lagring i en database

� Data må kunne konsumeres fra ulike plattformer. HUB-ene kan for eksempel sende XML eller på annen måte http post etc.

� Det bør være mulig å konfigurere HUB-ene via http kall inn. Eks: hvor ofte en sensor skal hente data og hvilke data etc

o Brukergrensesnitt for å koble til nye sensorer og oppsett av eksisterende o Analyse av datasett

Skye har diverse utstyr for denne oppgaven som flere sensorer og utviklingskitt som Raspberry PI. Annet utstyr skaffes ved behov.

Studentene må i utgangspunktet benytte egne PCer

Studentoppgave

9 KilderAllseen Alliance. (Udatert).An Open Source Framework for Creating New Experiences. Hentet 16.02.16 fra https://allseenalliance.org AngularJS. (udatert). FAQ. Hentet 15.03.16 frahttps://docs.angularjs.org/misc/faq

AngularJS. (udatert). Tutorial. Hentet 15.03.16 frahttps://docs.angularjs.org/tutorialAngularJS. (Udatert). $resource. Hentet 15.03.16 fra https://docs.angularjs.org/api/ngResource/service/$resource

Apache Hadoop. (2016). What Is Apache Hadoop?. Hentet 03.03.16 frahttp://hadoop.apache.org/#What+Is+Apache+Hadoop%3F

Apple. (Udatert)."HomeKit Et trygt og sikkert hjem. I din hule hånd.". Hentet 16.02.16 fra http://www.apple.com/no/ios/homekit/

Apple Developer. (Udatert).Homekit. Hentet 16.02.16 fra https://developer.apple.com/homekit/Bluetooth.org. (2016). The Story Behind Bluetooth Technology. Hentet 08.02.16 frahttps://www.bluetooth.com/what-is-bluetooth-technology/bluetooth

Bower. (udatert). Getting started. Hentet 22.03.16 frahttp://bower.io/#getting-startedAdrian Bridgwater. (2015). The Internet Of Things Race -- Platforms Vs. Products. Forbes. Hentet 08.02.16 fra http://www.forbes.com/sites/adrianbridgwater/2015/09/07/the-internet-of-things-race-platforms-vs-products/#6fbd1c311097

Jamie Carter. (2015). Which is the best Internet of Things platform?. TechRadar. Hentet 08.02.16 frahttp://www.techradar.com/news/world-of-tech/which-is-the-best-internet-of-things-platform--1302416

GitHub. (udatert). Hello, world. Hentet 15.01.16 frahttps://github.com/GitHub. (Udatert). Zingchart -AngularJS. Hentet 21.04.16 fra http://zingchart.github.io/ZingChart-AngularJS/

Google Play. (2015). Simplelink SensorTag. Hentet 02.02.16 frahttps://play.google.com/store/apps/details?id=com.ti.ble.sensortag

GlassFish Server. (2015). Get Started Quickly. Hentet 15.03.16 frahttps://glassfish.java.net/getstarted.html

� av �67 70

Ian Harvey. (2014). Python interface to Bluetooth LE on Linux. IanHarvey/bluepy - GitHub. Hentet 25.02.16 fra https://github.com/IanHarvey/bluepy

IBM. (udatert). What Is dashDB?. Hentet 29.03.16 frahttp://www-01.ibm.com/software/data/dashdb/what-is.htmlIBM Bluemix. (Udatert). IBM Bluemix. Hentet 03.03.16 fra http://www.ibm.com/cloud-computing/bluemix/

IBM developerWorks Recipes. (Udatert).TI Sensor Tag and Raspberry Pi. Hentet 02.02.16 fra https://developer.ibm.com/recipes/tutorials/ti-sensor-tag-and-raspberry-pi/

iTunes. (2016). TI SensorTag. Hentet 02.02.16 frahttps://itunes.apple.com/us/app/ti-sensortag/id552918064?mt=8JetBrains. (Udatert). IntelliJ IDEA. Hentet 22.02.16 fra https://www.jetbrains.com/idea/JSON. (udatert). Introducing JSON. Hentet 31.03.16 fra http://www.json.org Joseph Kulandai. (2013). Java Classpath.javapapers. Hentet 22.05.16 fra http://javapapers.com/java/java-classpath/Maven. (udatert). What is Maven?. Hentet 22.03.16 frahttps://maven.apache.org/what-is-maven.htmlMQTT.org. (Udatert). MQTT. Hentet 03.03.16 fra http://mqtt.org

Node.js. (udatert). About Node.js®. Hentet 22.03.16 frahttps://nodejs.org/en/about/npm. (2016). Installing Node.js and updating npm. Hentet 22.03.16 frahttps://docs.npmjs.com/getting-started/installing-nodenpm. (2016). What is npm?. Hentet 22.03.16 frahttps://docs.npmjs.com/getting-started/what-is-npm

Oracle. (udatert). Java SE Technologies - Database. Hentet 29.03.16 frahttp://www.oracle.com/technetwork/java/javase/jdbc/index.htmlPostscapes. (udatert). Internet of Things Platforms. Hentet 08.02.16 frahttp://postscapes.com/internet-of-things-platformsRaspberry Pi. (udatert). Raspberry Pi 2 Model B. Hentet 02.02.16 frahttps://www.raspberrypi.org/products/raspberry-pi-2-model-b/Scrum Alliance. (udatert). Learn About Scrum. Hentet 03.02.16 fra

� av �68 70

https://www.scrumalliance.org/why-scrumSlack. (udatert). Team communication for the 21st century. Hentet 03.03.16 frahttps://slack.com/is

Texas Instruments Wiki. (Udatert). CC2650 SensorTag User's Guide. Hentet 02.02.16 fra http://processors.wiki.ti.com/index.php/CC2650_SensorTag_User's_GuideTexas Instruments Wiki. (Udatert). SensorTag2015. Hentet 02.02.16 fra http://processors.wiki.ti.com/index.php/SensorTag2015

Texas Instruments. (udatert). The SensorTag Story. Hentet 02.02.16 frahttp://www.ti.com/ww/en/wireless_connectivity/sensortag2015/index.html#mainthe internet of things. (2016). Hentet 03.02.16 fra http://www.theinternetofthings.eu/

Tizen. (2015).IoTivity – Connecting Things in IoT. Hentet 18.02.16 fra https://www.tizen.org/sites/default/files/event/ballroom1_31st_1100-1200_iotivity_-_connecting_things_in_iot.pdf

W3Schools. (Udatert). AngularJS Tutorial. Hentet 15.03.16 fra http://www.w3schools.com/angular/

W3Schools. (Udatert). Bootstrap Get Started. Hentet 25.04.16 fra http://www.w3schools.com/bootstrap/bootstrap_get_started.asp

Wi-Fi Alliance. (Udatert). Wi-Fi. Hentet 08.02.16 fra http://www.wi-fi.org

Wi-Fi Alliance. (Udatert). Wi-Fi Direct. Hentet 08.02.16 fra http://www.wi-fi.org/discover-wi-fi/wi-fi-direct

Wikipedia. (2016).AllJoyn. Hentet 16.02.16 fra https://en.wikipedia.org/wiki/AllJoynWikipedia. (2016). AngularJS. Hentet 15.03.16 frahttps://en.wikipedia.org/wiki/AngularJSWikipedia. (2016). Apache Hadoop. Hentet 03.03.16 frahttps://en.wikipedia.org/wiki/Apache_HadoopWikipedia. (2016). Bluetooth low energy. Hentet 08.02.16 frahttps://en.wikipedia.org/wiki/Bluetooth_low_energy

Wikipedia. (2016). FTP. Hentet 08.02.16 fra https://no.wikipedia.org/wiki/FTPWikipedia. (2016). Hypertext Transfer Protocol. Hentet 08.02.16 fra https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

Wikipedia. (Udatert). Internet of Things. Hentet 03.02.16 fra https://en.wikipedia.org/wiki/Internet_of_Things

� av �69 70

Wikipedia. (2016). IoTivity. Hentet 18.02.16 fra https://en.wikipedia.org/wiki/IoTivityWikipedia. (2016). Java (programming language). Hentet 03.03.16 fra https://en.wikipedia.org/wiki/Java_(programming_language)Wikipedia. (2016). Meteor (web framework). Hentet 15.03.16 frahttps://en.wikipedia.org/wiki/Meteor_(web_framework)Wikipedia. (2016). Near Field Communication. Hentet 08.02.16 fra https://en.wikipedia.org/wiki/Near_field_communication

Wikipedia. (2016). Open Interconnect Consortium. Hentet 16.02.16 fra https://en.wikipedia.org/wiki/Open_Interconnect_Consortium

Wikipedia. (2016). Python (programming language) Hentet 03.03.16 fra https://en.wikipedia.org/wiki/Python_(programming_language)

Wikipedia. (2016). Representational state transfer. Hentet 22.03.16 fra https://en.wikipedia.org/wiki/Representational_state_transfer

Wunderlist. (udatert). Wunderlist. Hentet 15.01.16 frahttps://www.wunderlist.com/

� av �70 70