Sluttrapport. Internet of Things. Hovedprosjekt i Informasjonsteknologi. Høgskolen i Oslo og Akershus. Våren Gruppe 24

Transkript

1 Sluttrapport Internet of Things Hovedprosjekt i Informasjonsteknologi Høgskolen i Oslo og Akershus Våren 2016 Gruppe 24 Jon Gillingsrud Christoffer André Belgen Fredriksen 1 av 70

2 PROSJEKT NR. Gruppe 24 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL Internet of Things DATO ANTALL SIDER / BILAG 70 PROSJEKTDELTAKERE INTERN VEILEDER Jon Gillingsrud, s Thor E. Hasle Christoffer André Belgen Fredriksen, s 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 2 av 70

3 Forord Dette 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. 3 av 70

4 Innhold 1 Innledning Prosjektgruppe Oppdragsgiver Problemstilling Kravspesifikasjon Funksjonelle krav Ikke-funksjonelle krav Tekniske krav 9 2 Prosessdokumentasjon Bakgrunn for prosjekt Arbeidsmetode Prosjektstyring Fremdriftsplan Milepæl Milepæl Milepæl Kommunikasjon Internt Oppdragsgiver Veileder Risikoplan Dagbok Verktøy Teksteditor Wunderlist Skype Slack GitHub Dropbox IntelliJ IDEA Møter Første møte med oppdragsgiver Kick-off møte Møte med rådgiver Fremvisning av prosjekt til oppdragsgiver 20 4 av 70

5 2.6 Utfordringer og avgjørelser Kodestandard Kodestruktur 21 3 Produktdokumentasjon Målgruppe Designvalg Teknologivalg Raspberry Pi Texas Instruments SensorTag AngularJS Java Python REST API ZingChart Bootstrap Apache Maven Oracle GlassFish Server Node.js, npm, og Bower JSON IBM Bluemix Apache Hadoop og dashdb Prosjekt del 1 : Kartlegging Introduksjon AllJoyn IoTivity Brillo Open Connectivity Foundation/Open Interconnect Consortium Wi-Fi Bluetooth NFC HTTP FTP MQTT Konklusjon Prosjekt del Introduksjon Hub 36 5 av 70

6 3.5.3 Backend/REST API Portal Database Sikkerhet Maskin- og programvarekrav Hardware Software 4 Testdokumentasjon Enhetstesting Brukertesting Ad-hoc testing Testresultater Konklusjon 48 5 Brukerveiledning og installasjon Installasjon Hub Portal Backend/REST API Database Brukerveiledning Hub Backend/REST API Portal 54 6 Avslutning Videreutvikling Oppnåelse av mål og krav Attest fra oppdragsgiver Ting vi ville gjort annerledes Vurdering av prosjektperioden og konklusjon 58 7 Ordliste 59 8 Vedlegg Dagbok Attest fra oppdragsgiver Oppgavetekst 66 9 Kilder 67 6 av 70

7 1 Innledning 1.1 Prosjektgruppe Gruppe 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 Oppdragsgiver Oppdragsgiver 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 brukeropplevelse Integrasjon Utvikling Ledelsesrådgivning / prosjektledelse Analyser/Business Intelligence service Skanning og arbeidsflyts-integrasjon Løsninger og kompetanse for Asset- og Facility Management Prediktive vedlikeholds- og analyse løsninger Klassisk 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. 7 av 70

8 1.3 Problemstilling Oppgaven 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 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. 8 av 70

9 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 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 ikkefunksjonelle. 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 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. 9 av 70

10 2 Prosessdokumentasjon 2.1 Bakgrunn for prosjekt Letingen 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 Arbeidsmetode Oppdragsgiver 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. 10 av 70

11 Scrum 1 er en utviklingsmetodikk som blir brukt til komplekse prosjekter. Prosjektet blir delt 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, Scrummaster 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 Fremdriftsplan 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 , utført 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 , utført 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 av 70

12 Lage REST API Hente data fra REST og vise det i portal Påbegynt , utført 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 , utført 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 forslag Fase Detaljer Tidsperiode Oppstart og forprosjekt 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 Jobbe med kartleggingsdelen av prosjektet. 12 av 70

13 Fase Detaljer Tidsperiode Implementering 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 Omfattende testing av løsninger for å sikre god kvalitet og fjerne bugs og feil. Testing vil også gjøres fortløpende gjennom prosjektperioden. Rapport Tid satt av til ferdigstilling av rapport og avslutning av prosjektet. Rapportskrivingen vil pågå sammen med øvrig arbeid gjennom hele prosjektperioden. 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 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 Kommunikasjon Kommunikasjon 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. 13 av 70

14 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 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 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 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: Risikoplan Risiko 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. 14 av 70

15 Risiko Sannsynlighet Konsekvens Tiltak 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 Faglige problemer eller problemer med verktøy Lav Lav Holde kontakten jevnt og holde hverandre oppdatert. Ikke veldig stort problem når det er kun 2 gruppemedlemmer. 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. 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. 15 av 70

16 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 Dagbok Vi har ført dagbok igjennom hele prosjektperioden. Et innlegg i dagboken ser slik ut: Tabell 3: Eksempel dagbok Dato Innlegg 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. Dagboken ligger under vedlegg, kapittel av 70

17 2.4 Verktøy 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 Wunderlist FIGUR 1. WUNDERLIST LOGO For å holde kontroll på hvilke oppgaver som måtte gjøres benyttet vi oss av huskelisteapplikasjonen Wunderlist 2. Med Wunderlist kan man sette gjøremål med frister og påminnelser og deretter tilegne gjøremålet til en av gruppemedlemmene 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 av 70

18 2.4.4 Slack FIGUR 3. SLACK LOGO Slack 3 er et sky-basert kommunikasjons og samarbeidsverktøy. Det ble laget en egen gruppe i Slack for å oppnå kommunikasjon mellom gruppemedlemmene, samt å dele lenker og filer på et mer egnet sted enn Facebook Messenger GitHub FIGUR 4. GITHUB LOGO GitHub 4 ble valgt som lagringsplass av filer som ble brukt i prototypen. Det ble diskutert 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 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 av 70

19 2.4.7 IntelliJ IDEA FIGUR 6. INTELLIJ IDEA LOGO IntelliJ IDEA 5 endte opp som vår foretrukne IDE for dette prosjektet. Vi startet med å bruke 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 Første møte med oppdragsgiver Den 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 Kick-off møte Etter at forprosjektet var fullført møtte vi den 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 av 70

20 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 Fremvisning av prosjekt til oppdragsgiver 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ørelser En 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 6 funksjonen for dette. 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 av 70

21 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 Kodestandard Ettersom 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 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. 21 av 70

22 3 Produktdokumentasjon 3.1 Målgruppe Må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 Designvalg Som 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 Raspberry Pi Raspberry Pi 2 Model B 7 ble benyttet som hub i dette prosjektet etter ønske fra 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 av 70

23 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 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 Texas Instruments SensorTag Texas Instruments Simplelink SensorTag 8 er en sensor som måler blant annet luftfuktighet, 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 9 finnes til Android og ios. Oppdragsgiver stilte to ulike versjoner av SensorTag til disposisjon for gruppen. I vår prototype har vi brukt den nyeste av de to versjonene, CC Android: ios: 23 av 70

24 FIGUR 8. TEXAS INSTRUMENTS SIMPLELINK SENSORTAG 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-viewcontroller, MVC, og model-view-viewmodel, MVVM. Angular fungerer ved å først leste HTML dokumentet for siden som inneholder egne tagatributter, 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. 24 av 70

25 3.3.4 Java FIGUR 10. JAVA LOGO Java 10 er et klassebasert og objektorientert programmeringsspråk. Firmaet som utvikler Java heter Sun Microsystems som er under Oracle Corporation. Java ble først utgitt i 1995, men ble ikke open source før 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.jarfiler. Det er også dette språket gruppen har mest erfaring med fra tidligere kurs i studiet, noe som hjalp mye i utviklingsprosessen Python FIGUR 11. PYTHON LOGO Python 11 ble først sluppet 20 Februar De som utvikler Python er Python Software 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 av 70

26 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 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 ZingChart FIGUR 12. ZINGCHART LOGO ZingChart 12 er et graf-bibliotek for JavaScript bibliotek, inkluder AngularJS og jquery. 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 Bootstrap Bootstrap 13 er et front-end bibliotek for å lage og designe nettsider. Det inneholder en 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 av 70

27 3.3.9 Apache Maven Maven 14 er et byggesystem for Java applikasjoner. Det beskriver hvordan prosjektet skal 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 Oracle GlassFish Server GlassFish 15 er en applikasjonsserver for Java prosjekter. Denne serveren ble brukt for å 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 Node.js, npm, og Bower FIGUR 13. NODE.JS LOGO Node.js 16 er et runtime system for å kjøre nettverksapplikasjoner. npm 17 er pakkebehandleren som benyttes av Node.js. Bower 18 er en klient-side pakkebehandler 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 av 70

28 JSON JSON 19 (JavaScript Object Notation) er en standard for å utveksle data mellom en server 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 IBM Bluemix FIGUR 14. IBM BLUEMIX LOGO Bluemix 20 er en skyplatform-tjeneste levert av IBM. Den har støtte for en rekke 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 Apache Hadoop og dashdb Apache Hadoop 21 og dashdb 22 er begge databasetjenester. Vi valgte Apache Hadoop ved 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 Java Database Connectivity, 28 av 70

29 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 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 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 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. 29 av 70

30 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 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 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. 30 av 70

31 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 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 Wi-Fi FIGUR 16. WIFI LOGO Wi-Fi 24 er et trådløst nettverk for kommunikasjon mellom enheter basert på IEEE 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 av 70