Bachelorprosjekt 2017

Transkript

1 Bachelorprosjekt 2017 Høgskolen i Oslo og Akershus Gruppe 8 Studieprogram Anvendt Datateknologi og Ingeniør- Data Sina Haji Hassani s Nattaphong Klinjan s Edvarda Regine Winlund Eriksen s Marius Nilsen Kluften s236307

2 PROSJEKT NR. 8 Telefon: Telefaks: Studieprogram: Anvendt datateknologi og Ingeniørfag - Data Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo BACHELORPROSJEKT TILGJENGELIGHET Offentlig HOVEDPROSJEKTETS TITTEL Coolify DATO ANTALL SIDER / MED BILAG 172 / 199 PROSJEKTDELTAKERE Sina Haji Hassani Nattaphong Klinjan Edvarda Regine Winlund Eriksen Marius Nilsen Kluften s187472@stud.hioa.no s236747@stud.hioa.no s236304@stud.hioa.no s236307@stud.hioa.no INTERN VEILEDER George Anthony Giannoumis gagian@hioa.no OPPDRAGSGIVER ServiceNow Norway AS KONTAKTPERSON Odd Mareno Leonhardsen odd.leonhardsen@servicenow.com Dette er et prosjekt for oppdragsgiver ServiceNow Norway AS utført av studenter fra Anvendt Datateknologi og Dataingeniør ved Høgskolen i Oslo og Akershus, i samarbeid med Coop Norge. Målet har vært å lage et helautomatisk system for måling av temperatur i ulike kjølere, ved hjelp av en applikasjon vi utvikler i ServiceNow-plattformen, og prototyper av IoT-enheter. 3 STIKKORD NodeMCU / Arduino ServiceNow Platform Internet of Things (IoT)

3 Innholdsfortegnelse 1.0 Forord Leserveiledning Innledning Kravspesifikasjon Prosessdokumentasjon Produktdokumentasjon Testdokumentasjon Fremtidig arbeid Oppsummering Kildeliste Dataordbok Vedlegg

4 1.0 Forord Denne rapporten dokumenterer arbeidet og løsningen som er blitt utviklet i forbindelse med bachelorprosjekt 2017 ved Høgskolen i Oslo og Akershus, og er av typen Rapport med program. Rapporten er i stor grad rettet mot oppdragsgiver og bruker (kunde) da løsningen kun kan tas i bruk av personer med tilgang til ServiceNow-plattformen. Videre inneholder den bilder, illustrasjoner og vedlegg som best vises i printet A4-format, men kan også leses digitalt. Gruppen gjorde oppgaven på bestilling fra ServiceNow ved Odd Mareno Leonhardsen, da et av gruppemedlemmene har bekjentskap med han. ServiceNow var på utkikk etter utviklere som kunne utvikle og teste en ny type løsning for plattformen deres og se om dette kunne implementeres hos en reell kunde. Vi vil benytte anledningen til å takke alle som har vært med på å gjøre dette prosjektet mulig, ikke minst de som tok seg tid fra egne arbeidstimer, prosjekter og travle hverdager for å bistå med hjelp og veiledning. Spesielt vil vi takke vår veileder fra Høgskolen, George Anthony Giannoumis, som har vært en motivator og lært oss mer enn vi trodde var mulig om samarbeid, og Odd Mareno Leonhardsen som ga oss tillit og muligheten til å utvikle prosjektet på en så stor og omfattende plattform. Vi ønsker dessuten å vise stor takknemlighet til tre Symfoni konsulenter som har gått utover enhver forventning for å veilede og hjelpe gruppen i sitt arbeid; Vegard Porsedal, Alexander Ljungström og Oleg Andrushko. Prosjektet ville ikke ha vært like bra uten deres engasjement, hjelp og innsats. Til sist vil vi takke ServiceNow for oppgaven og prosjektet, Symfoni for kontorplass og uvurderlig bistand og tilbakemeldinger, og Coop for tilliten og interessen for prosjektet. 1

5 Innholdsfortegnelse: Leserveiledning / Innledning 2.0 Leserveiledning Omtalte personer i rapporten Innledning Presentasjon av gruppesammensetning Oppdragsgiver: ServiceNow ITSM og ITOM Everything as a Service (XaaS)

6 2.0 Leserveiledning Denne rapporten er strukturert delvis etter Høgskolen i Oslo og Akershus sin egen dokumentasjonsstandard (Høgskolen i Oslo og Akershus, udatert), men i enkelte deler av oppgaven har vi valgt å ha egendefinert struktur da dette gir en større innsikt, lesbarhet og forståelse for prosessen eller produktet. Dokumentet er delt opp i større kapitler som således kan leses som individuelle dokumenter, men gruppen anbefaler å lese dokumentet i sin helhet, for en grundig forståelse. For økt lesbarhet har gruppen besluttet å gjenta ulike temaer på tvers av de ulike delene i dokumentet, slik at rapporten kan leses delvis, og at leseren også skal kunne legge fra seg dokumentet og komme tilbake til den. Rapporten forutsetter en grunnleggende forståelse for informasjonsteknologi, datasystemer og koding. Vi er likevel klar over at flere deler av rapporten som er særegent spesifikke, og i disse tilfellene har vi satt av plass i dokumentet for en enkel innføring i temaet. Skulle leseren komme over terminologi eller teknologier som ikke blir forklart referer vi til dataordboken som finnes i slutten av dokumentet før vedlegg. Se gjerne innholdsfortegnelsen for sidetall. 2.1 Omtalte personer i rapporten I denne rapporten har vi bestemt å bruke egne begreper for alle omtalte personer istedenfor navn, slik at det til enhver tid er tydelig hvem de omtalte personene er og hvilken funksjon de har i prosjektet, og hva de er ansvarlig for. Dette er for å unngå forvirringer og unødvendig mange navn å forholde seg til. Gruppe 8 består av Edvarda Eriksen, Sina Hassani, Marius Kluften og Nattaphong Klinjan, og blir omtalt som gruppen, vi eller oss. Det er vi som er forfattere av rapporten og har hatt det primære ansvaret for utvikling av produktet og implementasjon. Gruppen er så heldig at vi har fått velge vår interne veileder fra Høgskolen i Oslo og Akershus selv, George Anthony Giannoumis. Anthony er førsteamanuensis og foreleser på Høgskolen, og omtales som veileder. Odd Mareno Leonhardsen er vår veileder fra ServiceNow, og omtales som oppdragsgiver. I de tilfeller der det har vært nødvendig å prate om ServiceNow som selskap, bruker vi bare ServiceNow. Coop har fungert som interessent og kunde, og omtales som Coop eller kunden. 3

7 3.0 Innledning I denne bacheloroppgaven var det ønsket at vi skulle automatisere prosessen av å hente og lagre informasjon fra Coop sine kjøleskap og frysere. Med ServiceNow som oppdragsgiver og veileder for prosjektet, skulle vi utvikle et verktøy som kunne hente, sende, lagre og tolke data. Dette skulle vi kombinere med Coop sine rutiner for kjøleskap og frysere, og i tillegg lage et brukergrensesnitt som er lett å tolke og forstå for sluttbrukere. På denne måten effektiviseres og reduseres arbeid hos Coop. Dagens rutiner med manuelle stikkprøver av kjøleskap og frysere daglig, blir erstattet med automatisk tilbakemelding med et gitt tidsintervall og varslingssystem dersom en temperatur faller utenfor gitte grenseverdier. I tillegg til å effektivisere og redusere arbeid kan løsningen også være med på å redusere mengden svinn av kjølevarer, og i tillegg synliggjøre feil på utstyr før de slutter å fungere. 3.1 Presentasjon av gruppesammensetning Prosjektgruppen er satt opp av to studieretninger. Dataingeniør, som er representert ved Edvarda Eriksen og Marius Kluften, og anvendt datateknologi, representert ved Nattaphong Klinjan og Sina H. Hassani. Vi har fra tidligere ingen erfaring med å jobbe sammen i prosjekter, men kjenner hverandre fra før gjennom sosiale nettverk på høgskolen. Ettersom vi alle hadde et høyt ambisjonsnivå, bestemte vi oss for å danne en gruppe på tvers av linjer for å spille på den tverrfaglige fordelen dette gir. Dette kommer av at linjene i stor grad utfyller hverandre. Anvendt datateknologi har et bredt fokus på brukervennlighet og testing, som medfører at Nattaphong og Sina har erfaring med blant annet prototyping, menneske-maskin interaksjon, informasjonsarkitektur og visualisering. Denne erfaringen gir kunnskaper innen brukersentrert utvikling, analyse, design og kommunikasjon. Dataingeniør fokuserer mer på det matematiske, tekniske og logiske i utvikling, som gir Edvarda og Marius god erfaring med matematikk, fysikk og kjemi, datanettverk og skytjenester, programmering og algoritmer og datastruktur. Erfaringen deres gir en solid forståelse og logikk innen programmeringsspråk, utvikling og innøvde arbeidsmetoder. Dermed ligger gruppens styrke i det faglige mangfoldet som øker både kunnskapsnivået og de ulike ferdighetene innad i gruppen. Til sammen danner denne styrken et grunnlag for et mer gjennomført prosjekt. Det har gjort oss trygge på å gjennomføre en bachelor med fokus på Internet of Things (IoT) utvikling i samspill med plattformen til ServiceNow, for å bygge egne erfaringer på å koble programvare og fysiske gjenstander, og å utforske feltet IoT, som er veldig relevant i IT bransjen. 4

8 3.2 Oppdragsgiver: ServiceNow Glidesoft Inc. ble grunnlagt i 2003 av Fred Luddy. De spesialiserte seg innen applikasjoner for ITSM (IT Service Management) og lagde den første skybaserte plattformen som var skreddersydd for bedriftsmarkedet. The IT industry deserves a tool that just works. We re going to give it to them (ServiceNow, udatert-d) var ordene Luddy satte som grunnmur for konsernet. I 2006 endret de navnet til ServiceNow i det de begynte å bli virkelig store innen dette ferske markedet og fikk store kunder som blant annet Intel og Staples. I 2015 ble selskapet det andre SaaS (Software-as-a-Service) som nådde én milliard dollar i årlig inntekter (ServiceNow, udatert-d) og i Norge har selskapet mange samarbeidspartnere som utvikler og drifter løsninger for kunder i landet. Blant disse har vi Symfoni ESM, Syscom AS, Accenture, IBM og Fujitsu (ServiceNow, udatert-ab) som leverer løsninger til blant annet Coop Norge ITSM og ITOM ServiceNow så at bedriftsmarkedet ikke hadde et ordentlig verktøy for å knytte sammen og løse alle slags mulige problemer som oppstår på den tekniske siden i en bedrift. Disse problemene må løses av noen som står ansvarlig, dette alt fra store hendelser som forårsaker at hele bedriftens nettverk er nede, til mindre hendelser som at ansatte ikke klarer å resette passordet sitt. Før ServiceNow (og lignende systemer) måtte brukere oppsøke riktig avdeling ved å enten sende epost, ringe eller møte opp fysisk for å få løst problemer. De første verktøyene ServiceNow lagde var rettet mot ITSM 1, men de fant fort ut at de kunne dra stor nytte av å blande inn driftoperasjoner (ITOM 2 ) under samme plattform, for å knytte sammen disse to grenene og treffe et mye større marked Everything as a Service (XaaS) ServiceNow har hele tiden fokusert på å treffe et så bredt spektrum av avdelinger som mulig, så nå, i stedet for å bare tilby SaaS (Software-as-a-Service), dekker de nå også blant annet Platform-as-a-Service (PaaS) og Infrastructure-as-a-Service (IaaS) og har samlet alle disse tjenestene under et eget navn; Everything-as-a- Service (XaaS). Flere aktører skjønner etterhvert nytten av å kunne tilby et bredt spekter av løsninger under samme tjeneste, og dette kommer trolig til å bli bedriftsstandarden fremover. 1 IT Service Management 2 IT Operation Management 5

9 En plattform som tilbyr så mange muligheter gjør at andre avdelinger også får stor nytte av en slik løsning: HR, sikkerhet, kundebehandling og markedsføring knyttes sammen og kan lettere overgi beskjeder. Det er en veldig stor fordel å kunne knyte mange områder til én plattform som alle i selskapet kan ta del i. I det private markedet er dette allerede utbredt, det finnes en løsning for så og si alt, men bedriftene henger fortsatt etter. Det at ServiceNow tilbyr et så stort mangfold av tjenester under samme plattform har gjort de til en av, om ikke den, største aktøren innen as-a-service i verden. 6

10 Innholdsfortegnelse: Kravspesifikasjon 4.0 Kravspesifikasjon Om bakgrunnen To kravspesifikasjoner Oppdragsgivers krav til løsningen: ServiceNow Kundens krav til løsning: Coop Funksjonelle og ikke-funksjonelle krav Brukerhistorier Systembeskrivelse Rammekrav i systemet Kapasitet Sikkerhet Bruk og brukervennlighet Fremtidig utvidelse av systemet Krav til dokumentasjon Verktøy tatt i bruk Dokumentbehandling Illustrasjon Kommunikasjon Versjonskontroll Utvikling

11 4.0 Kravspesifikasjon I denne delen av oppgaven vil vi ta for oss motivasjonen for prosjektet og alle krav til produktet. Hensikten med en kravspesifikasjon er å gjøre klar for alle interessenter hvilke egenskaper et produkt skal ha, slik at det dannes et grunnlag for kostnader og fremdrift. Den skal også sikre at alle parter er inneforstått med rammekravene til systemet, forsikre at det ikke blir uenighet underveis i prosjektet og har fungert som et styringsdokument og referansepunkt for gruppen, slik at utviklingen av produktet stemte overens med dets tiltenkte retning. Kravspesifikasjonen kan brukes for å få en rask innføring i produktet, og er organisert med den hensikt at leseren skal stå igjen med en oversiktlig innsikt om systemets funksjonalitet, struktur og rammebetingelser, samt hvilke krav som er satt til det ferdige produktet. Skulle det være terminologi og begreper som er ukjent for leseren, henviser vi til 11.0 Dataordboken der vi har dekket alle uttrykk etter beste evne. 4.1 Om bakgrunnen ServiceNow er et av verdens raskest voksende Customer Relationship Management-selskap (CRM), og deres hovedfokus er som nevnt å effektivisere og automatisere arbeidsprosesser og kommunikasjonsflyt for sine kunder. Verdiskapingen og kundenes tilfreds står og faller på om kunden føler at ting ble lettere etter oppgraderinger. Dette er et essensielt faktum vi tar med oss inn i utviklingen av prosjektet. Vår prosjektoppgave går ut på å lage en IoT-prototype og tilhørende ServiceNow applikasjon for Coop som er ServiceNow kunde. Denne applikasjonen skal automatisere overvåkingen av temperatur i kjølere plassert i Coop-butikker. Dette skal løses ved at vi har en programmerbar enhet, NodeMCU 3 (NodeMCU, udatert), som måler og rapporterer temperaturer inn til applikasjonen. Planlegging og utvikling skjedde i slutten av januar helt frem til begynnelsen av mai, og gruppen valgte den smidige utviklingsmetoden Kanban. I prosjektet vårt har dermed Internet of Things (IoT) blitt et svært sentral del av utviklingen. IoT refererer til unike gjenstander som på digitalt vis samler data, kommuniserer i samme nettverk med hverandre og med oss som brukere. Hensikten er å gjøre hverdagen enklere for mennesker ved å automatisere daglige gjøremål, slik at vi kan fokusere på viktigere oppgaver. I 2016 var det omtrent 16 milliarder enheter tilkoblet internett og innen 2020 er det estimert at dette tallet kommer til å øke til 29 milliarder, hvorav 1,5 milliard av disse vil være nye IoT-enheter (Ericsson, 3 Et utviklingskort. Les mer om utviklingskort og NodeMCU i detalj under Coolity 0.2: NodeMCU Lampe og Løsning. 8

12 2015). ServiceNow jobber dessuten med å innovere innen IoT for å gjøre brukeropplevelsen for kundene enda bedre. Et av mottoene til ServiceNow er tross alt changing the way people work. 4.2 To kravspesifikasjoner Vi startet samtaler med ServiceNow i siste kvartal av 2016 og fikk en enkel kravspesifikasjon fra dem. På samme tidspunkt ble vi informert om at produktet var tiltenkt Coop, men at samtaler mellom ServiceNow og Coop enda ikke var startet. For oss betydde det at vi måtte være forberedt på en endring i kravspesifikasjonen om Coop kunne tenke seg å ta løsningen i bruk. I starten av første kvartal 2017 begynte møtene med Coop, vi måtte forholde oss til ServiceNow som vår oppdragsgiver og Coop som mottaker av produktet og kunde. Som antatt kom Coop med sin egne ønsker til det ferdige produktet, og vi hadde nå to kravspesfikasjoner vi måtte forhold oss til Oppdragsgivers krav til løsningen: ServiceNow Til å begynne med stilte ServiceNow som oppdragsgiver krav til at vi skulle gå gjennom utviklingskursene de har på nettsiden sin (ServiceNow, udatert-b) slik at vi ble kjent med ServiceNow-plattformen og dennes grunnleggende muligheter, verktøy og metodikk. Kursene tok oss igjennom det mest grunnleggende som å navigere på plattformen, kode scripts og til å lage en applikasjon for bestilling av eventer på forskjellige lokasjoner, pris for leie av utstyr i valuta, hvilke deltakere som er påmeldt og hvor mange som forventes å komme. Hvert kurs hadde tilhørende moduler som gikk igjennom et emne tilhørende kurset. 4 Vi brukte ingen av løsningene i applikasjonen vi lagde underveis i utviklingskursene til vår egen applikasjon, men selve metodikken for bruk ble nyttig for oss da det skapte grunnlaget for utvikling på plattformen. Gjennomføring av kursene skjedde i januar, men vi hadde allerede fått en pekepinn i november på hva som kunne være deler av en kravspesifikasjon i en mail fra ServiceNow 5. Samtidig som vi jobbet med kursene i januar jobbet vi også med å få en generell kravspesifikasjon fra ServiceNow, med forbehold om at vi kanskje måtte endre deler av den om Coop ønsket å ta i bruk løsningen. Odd Mareno var svært tilgjengelig over telefon og etterhvert som vi hadde spørsmål underveis kunne vi ringe eller sende mail for å få oppklarende svar. Vi la mailen fra november til grunn og kom så frem til følgende veiledende kravspesifikasjon for IoT-enheten og applikasjonen: 4 Oversikt over kurs ligger under Kompetansetilegning: ServiceNow Developer Kurs. 5 Se mail-vedlegg 12.2 Kuul Case til deres oppgave. 9

13 KRAVSPESIFIKASJON SERVICENOW IOT-ENHET Arduino UNO utviklingskort / kretskort skal benyttes. WiFi-chip av typen ESP8266 (Kjell & Company, udatert-h) skal benyttes. Temperaturmåler skal benyttes. APPLIKASJON WiFi-chipen skal sende data til en applikasjon vi lager i ServiceNow. Applikasjonen skal inneholde terskler for temperatur og varsle dersom temperaturen faller utenfor terskelverdiene Kundens krav til løsning: Coop ServiceNow kontaktet Coop mens vi jobbet med kurs i løpet av januar, og avtalte et møte med Coop den 2. februar. Vi hadde allerede begynt å eksperimentere med prototyper 6 med temperaturmåler i slutten av januar, så vi hadde noe å vise fram på møtet. Under møtet kom det frem at Coop var mer interessert i applikasjonen vi skulle lage i ServiceNow enn selve IoT-enheten. På tross av det var et av kravene de kom med kritiske for resultatet, de ønsket at enheten skulle bruke batteri som sin strømforsyning. De resterende kravene gikk på størrelse, muligheter i applikasjonen og spilte ellers generelt på kravene fra ServiceNow: KRAVSPESIFIKASJON COOP IOT-ENHET IoT-enheten skal være så liten som vi får til med en prototype. Må fungere med batteri. Temperaturmålere må tilpasses fryser og kjøleskap. APPLIKASJON Terskelverdier skal variere ut ifra hvilke kjølere de står i. 6 Se Prosessdokumentasjon og Utviklings av IoT-enhet: Coolity 10

14 Det skal være ulike nivå for brukere. Det skal være et grafisk brukergrensesnitt. Det må faktisk testes i en Coop-butikk og bekrefte at temperatur registreres i applikasjon. 4.3 Funksjonelle og ikke-funksjonelle krav Brukerhistorier Med kravene fra Coop innså vi at vi trengte å sette opp noen funksjonelle og ikkefunksjonelle krav for applikasjonen, slik at vi hadde en oversikt over hvilke muligheter og tilganger de ulike rollene i applikasjonen skulle ha. SOM... ØNSKER JEG Å... SLIK AT... Akseptanse kriterie Admin: - Coop Styre - ServiceNow Konsulent Få oversikt over alle kjølere i alle butikker Jeg kan se hvilke kjølere som er koblet opp og ikke koblet opp mot en IoT-enhet Tabeller for - Butikk - Kjøler - Arduino Må være laget. Ha kontaktinfo til butikksjefer Jeg kan kontakte ved behov, for eksempel om en kjøler er varm over lengre tid. I tabellen Butikk må tlfnr ligge inne til blant annet - Tlf butikk - Tlf butikksjef Legge inn nye - butikker - kjøler Jeg har totaloversikt og enkelt kan beregne kostnader Tabeller må være satt opp. Generere en token til hver chip Jeg kan gi den videre til arbeideren som skal laste opp sketch i chippen. At chippen sin sketch er kodet riktig. Butikkeier Legge inn kontaktinformasjon til butikk og eier (seg selv) Slik at jeg kan bli varslet ved feil fra system og/eller Admin Må være mulighet for butikkeier å endre tabellen Butikk slik at kontaktinformasjon 11

15 er lagt til. Ha oversikt over kjøler i min butikk og kunne legge til eller fjerne dem etter behov. Jeg har kontroll på hva slags kjøle(re) jeg har og hvor de er plassert. Butikkeier må ha mulighet til å kunne administrere sin egen butikk, slik at tabellen Butikk også oppdateres automatisk for Admin. Se oversikt over hvilke Arduino som er i hvilke kjøler Jeg kan forsikre meg om at de fungerer og eventuelt etterspørre reparasjon eller bytte Felt for reparasjon og bytte av Arduino i tabellen Arduino eller Kjøler slik at butikkeier kan oppdatere og Admin kan se. Se oversikt over temperaturer i kjøler Jeg vet det er forsvarlige forhold i hver kjøler og at produkter ikke tar skade Arduino i kjøler rapporterer følgende temperaturer til ServiceNow: Kjølevarer: 4 Frysevarer: -18 Bruker se temperaturen i kjølediskene i min butikk jeg vet om alt er i orden At Arduinoen er identifisert riktig og sender korrekte temperaturer til applikasjonen få en varsel når frysere/kjølere blir for varme jeg kan justere fryserens temperatur etter butikkens retningslinjer At varsel sendens fra applikasjonen når fryserene blir for varme. 4.4 Systembeskrivelse Vi skal utvikle en automatisert, digital løsning der vi benytter oss av en NodeMCU som skal kobles til Coops trådløse nettverk og kommunisere med en applikasjon vi 12

16 lager i ServiceNow. NodeMCU en overvåker og rapporterer utviklingen av temperatur til applikasjonen, som igjen rapporterer og varsler sluttbrukerne dersom den går over eller under et predefinert nivå. Applikasjonen vil også kunne lagre informasjonen om temperaturutvikling over tid, slik at man kan finne perioder der fryserne er spesielt utsatt. Applikasjonen skal ha to deler, frontend og backend. I backend lagres all informasjon om enhetene og hvor de befinner seg, samt lagring av temperaturen. I frontend presenteres informasjonen i et brukervennlig grensesnitt (graphical user interface (GUI)) som brukes av de ansatte i Coop. Slik får Coop en skreddersydd løsning for lagring, varsling og rapportering av temperatur i sine kjøler, uten at deres ansatte må bruke tid på og manuelt måle temperaturene i hver fryser, hver dag. Det skal også være mulig å bestille en tekniker til å inspisere kjøleren i det tilfelle temperaturen varierer for mye. Gruppen har dermed en løsning basert på to bestanddeler: En NodeMCU chip som settes ut i fryserene hos butikken. Denne måler en temperatur etter et bestemt tidsintervall og sender denne informasjonen sammen med dens unike ID inn til ServiceNow sitt REST API. En applikasjon i ServiceNow som mottar all informasjon fra chippen og prosesserer den. Applikasjonen binder sammen enheten med dens tilhørende record 7 i en tabell som inneholder informasjon om plassering av chip. Dersom temperaturen stiger over ønsket verdi skal applikasjonen generere et varsel som avhengig av alvorlighetsgrad varsler en person som er ansvarlig på et gitt tidspunkt. 4.5 Rammekrav i systemet Kapasitet Gruppen ønsker å lage et robust produkt som skal håndtere mye informasjon på en og samme tid. Vi har lagt mye tid inn i å tenke på hvordan vi etter best praksis skal håndtere de store mengdene informasjon applikasjonen mottar fra de utallige butikkene hos Coop Skalerbarhet For å ruste systemet for fremtidig utvidelse er det viktig at plattformen er skalerbar. Ettersom ServiceNow ligger i skyen er mulighetene for skalering nærmest grenseløs. Det eneste som kan bremse ekspansjonen er fysisk tildeling av datakraft (Ramlochun, 2017) og hvor mange transaksjoner applikasjonen kan kjøre samtidig (ServiceNow, udatert-g). ServiceNow setter noen standard kvoter for hvor mange transaksjoner hver applikasjon kan foreta seg, men disse verdiene er det mulig å 7 En oppføring i en tabell i en database. En enkelt rad. 13

17 endre ved behov. Den største utfordringen ligger ved innkjøp, oppsett og installasjon av store mengder Coolity-enheter og registrere disse manuelt i applikasjonen. Dette er heldigvis en enkel prosess, men det ideelle hadde vært å automatisere alt, der det lar seg gjøre Sikkerhet Gruppen har brukt mye tid på å kartlegge gode sikkerhetstiltak for å etter beste evne sikre informasjonen som sendes mellom Coop og ServiceNow. Når vi blander IoT med denne skyplattformen er det veldig viktig at man ikke kan manipulere eller på andre måter bruke denne dataen. Sikkerhetsproblematikken rundt IoT er noe av det viktigste man må løse før vi etterhvert kan stole trygt på at dingser tilkoblet internett skal hjelpe oss i hverdagen. Det er viktig å sikre enhetene mot endring av funksjonalitet og tap/endring av data NodeMCU Sikringen av dataen i NodeMCU går blant annet på sikkerheten til REST kall, som krever autentisering for hvert request (ServiceNow, 2016c), samt OAuth autentisering (ServiceNow, 2016b), hvor man generer en token istedenfor å oppgi brukernavn og passord hver gang. Hvert request går gjennom Secure Socket layer (SSL) hvor kommunikasjon mellom NodeMCU og Servicenow er kryptert. Tap av data kontrolleres av interne script i ServiceNow som kontrollerer at tabellene faktisk mottar informasjon, og dersom de ikke gjør det på tre intervaller vil brukeren varsles ServiceNow APIet ServiceNow har grundig gjennomgang av den integrerte sikkerheten til APIet i sin Wiki side (ServiceNow, udatert-af), men har også mange sikkerhetsfunksjoner man kan implementere selv Rollebasert tilgang i ServiceNow Dashboardene i applikasjonen endres ut ifra hvilken rolle brukeren har i ServiceNow sitt system. Slik opprettholder vi en Practice of Least Privilege (POLP) slik at brukere til enhver tid bare har tilgang til akkurat de dataene de trenger, og ikke mer. Dette er oppdelt som følger: Coop Styre og ServiceNow administratorer Har tilgang til all temperaturdata og alle varsler i alle butikker over hele Norge. Har samtlige butikksjefers kontaktinformasjon dersom det oppstår et problem. Har også rettigheter til å opprette Incidents, Problems og Change Requests ved behov. Coop Butikksjef Har tilgang til temperaturdata og varsler for alle frysere i butikken. Har kontaktinformasjon til alle som jobber i butikken, og dessuten har hen 14

18 rettigheter til å opprette Incidents og Problems dersom det skulle være behov for dette. Coop arbeider Har tilgang til temperaturdata og varsler for alle frysere i butikken brukeren jobber i. Har også kontaktinformasjon til butikkeier dersom problemer skulle oppstå Bruk og brukervennlighet Gruppen både ønsker og streber etter å ha en universelt utformet applikasjon som i tråd med Web Content Accessibility Guidelines (WCAG) (International Organization for Standardization, 2012) inkluderer så mange brukere som mulig. WCAG er retningslinjer for hvordan webinnhold skal gjøres mer tilgjengelig, slik at brukere med nedsatt funksjonsevne også kan bruke tjenestene (W3C, 2011). I tillegg til å tilfredsstille forskrift om universell utforming av IKT-løsninger 4 (Kommunal- og moderniseringsdepartementet, 2013), så er APIet til ServiceNow utviklet for å tilfredsstille WCAG 2.0 Level AA, samt 508 fra Amendment of the Rehabilitation Act of 1973 i USA (ServiceNow, udatert-a). WCAG er en ISO 8 /IEC :2012 standard (International Organization for Standardization, 2012) som under norsk lovgivning er et absolutt krav for å få lov til å lansere norske webtjenester. Enn så lenge finnes det dessverre ikke en standard for brukervennlighet og universell utforming rundt IoT. Dette fører til at alle aktører lager noe på sin egen måte, uten å måtte svare til en internasjonal standard vedrørende sikkerhet og god brukervennlighet. Siden APIet allerede tilfredsstiller WCAG 2.0 hadde vi et solid grunnlag for brukervennlighet. Videre har vårt fokus hovedsakelig vært den mobile applikasjonen som Coop arbeiderne skal håndtere daglig, men også administrasjonspanelene (ServiceNow Dashbordet) til de forskjellige rollene. Underveis i prosjektet og utviklingen av løsningen har vi hatt en kontinuerlig dialog med Coop for å sikre at løsningen vi lager, spesielt da applikasjonen, er noe de hadde ønsket å ta i bruk. Det har vært essensielt for oss å ha denne dialogen da den har fungert som en type kvalitetssikring av applikasjonen. Selve IoT-enheten vil ikke interagere noe særlig med brukere, med unntak av når det de settes i kjøler eller bytte batteri. Vi har ikke hatt nok tid eller ressurser til å utvikle enheten med et deksel og plassering av batteri. Når det kommer til å utvikle selve enheten har fokuset kun 8 International Organization for Standardization er en internasjonal standardiseringsorganisasjon som utgir internasjonale standarder innenfor en rekke områder. «ISO» kommer fra det greske ordet for «lik» og er ikke et akronym for organisasjonens navn. 9 International Electrotechnical Commission er en ideell, ikke-statlig internasjonal standardiseringsorganisasjon som utformer og publiserer internasjonale standarder for alle typer elektrisk, elektronisk og relatert teknologi under samlebetegnelsen «elektroteknologi». 15

19 vært å oppfylle kravet om liten størrelse og funksjonalitet. At den faktisk registrerer og sender riktig temperaturer. Les mer om utviklingen av de ulike versjonene av prototypen under 5.3 Utvikling av IoT-enheten, Coolity Fremtidig utvidelse av systemet Ettersom Coop har vist stor interesse i prosjektet, har vi etter beste evne laget applikasjonen med hensyn på videreutvikling av systemet. NodeMCUene er eksterne og sender kun REST kall så de kan enkelt byttes ut ved behov. Samtidig kom det frem under møte med Coop at det var et ønske om integrering av varsler i kasseapparatene fra flere ansatte hos Coop, noe vi grunnet tidsnød ikke fikk implementert, men definitivt er noe å se på i fremtiden. Videre var det et ønske om å få vaktlister digitalt i ServiceNow, slik at varsler ikke blir sendt til alle som jobber på butikken, men bare de som er på jobb. 4.6 Krav til dokumentasjon Vi har ikke fått noen håndfaste krav fra oppdragsgiver eller kunde om dokumentasjon av applikasjonen eller Coolity-enheten. Vi har til tross for dette vært i kontakt med flere konsulenter og selskaper som jobber med å utvikle løsninger på ServiceNow-plattformen, og vi fikk tilbakemelding om følgende hovedpunkter som er sentrale i dokumentasjon av ServiceNow applikasjoner: Designdokumentasjon: Mellom kunde og leverandør - korte beskrivelser av hvordan systemet fungerer Inneholder forretningsbeskrivelsen og en high-level teknisk beskrivelse av implementasjonen. Detaljer tas kun med der de er nødvendige for å forklare. Den vil med andre ord beskrive hva vi er enige med kunden om at skal implementeres. Teknisk dokumentasjon: Mellom kunde og leverandør, og også internt for å kunne overlevere til en ny konsulent Inngående, detaljert dokumentasjon. Kan t.o.m inneholde utdrag fra scripts. Strukturen på den er egentlig irrelevant. Formålet er bare å beskrive hvordan ting henger sammen og hva som er laget. Det er anbefalt å skrive denne delen noenlunde prosedyrisk, slik at man ser gangen i det som er laget. Brukerdokumentasjon: Mellom kunde (sluttbrukere) og leverandør. Dette er ofte noe vi utarbeider i samarbeid med kunden. Skifter fokus og beskriver hvordan en person bruker det som er implementert, type «trykk her, fyll inn dette, trykk her, naviger hit» etc. Videre har vi også hentet inspirasjon fra Documenting a ServiceNow application Best Practices (Ljungström, 2017), en artikkel skrevet og publisert av Alexander Ljungström, som også som nevnt har vært en stor bidragsyter til prosjektet. 16

20 4.7 Verktøy tatt i bruk Dokumentbehandling Google Drive Vi tok i bruk skytjenesten Google Drive (Google, udatert) for håndtering av filene våre. Årsaken til at valget falt på Drive og ingen andre tjenester som leverer det samme var at alle på gruppen har erfaring fra Google Drive, er komfortable med det og at et av medlemmene abonnerer på 100GB lagring, slik at vi hadde god plass til å lagre prosjektet uten bekymring for at lagringsplassen skulle være for liten. Alternativet til Google Drive var DropBox. Men grunnet Drive sin enkle funksjon for samarbeid i filer samtidig og vår kjennskap til det fra før av, så falt valget på Drive. Ulempen med Drive var at filene som ble opprettet måttes eksportere til andre filformat når vi var ferdig med å forme filen (Mitroff, 2016). Det betyr da at noen stiler og valg i dokumentet kunne se annerledes ut. For eksempel kan det være at noen plassering av elementer og formatering av tekst kan være annerledes når det eksporteres til Microsoft Office Word Google Drive: Docs Docs er et innebygd verktøy i Google Drive vi brukte til å håndtere dokumenter som vi ønsket å jobbe på sammen. Docs tillater redigering online på samme dokument og var en løsning vi fikk bruk for på flere måter. Blant annet kunne vi skrive deler av sluttrapporten og dagbøkene sammen, lese de og redigere de etter ønske. Det gjorde kommunikasjonen bedre og synliggjorde arbeid når flere kunne jobbe i samme tekstdokument Microsoft Office: Word Word tilhører Microsoft Office sin pakke (Microsoft, udatert-d) og er blitt brukt i dette prosjektet til å formulere og produsere denne sluttrapporten, samt mindre tekstdokumenter. I likhet med Google Drive, brukte vi også Word til eksportering av filer til andre filformat, hovedsakelig PDF Illustrasjon Adobe Illustrator CC Forklarende illustrasjoner vi har tenkt kan være nyttig å ha med har vi designet i det vektorbaserte designprogrammet Adobe Illustrator CC (Adobe, udatert). 17

21 Microsoft Office: Project Microsoft Project (Microsoft, udatert-b) ble tatt i bruk som et prosjektstyringsverktøy, og til å lage GANTT-diagram i starten av prosjektperioden, tidlig januar. Dette var kun for å få en overordnet oversikt over prosjektet og sette noen enkle milepæler Microsoft Office: Visio Underveis i prosjektet har det vært behov for å lage illustrasjoner og skisser for enklere å forstå hvordan kommunikasjon mellom temperaturmåler, butikk og ServiceNow skal være. Til det har vi tatt i bruk Visio (Microsoft, udatert-c) for å lage noen av våre skisser som illustrerer hvordan de ulike Coop-butikkene må kommunisere med ServiceNow. Figur 1 Om alle Coop butikker deler felles nettverk 18

22 Figur 2 Om hver Coop butikk har hvert sitt nettverk Draw.io Visio er et svært tungt program som må lastes ned på våre personlige maskiner for å fungere, og det er i tillegg et krav at vi laster inn eller søker etter egne former. Draw.io (Draw.io, udatert) er svært likt Visio, men med hovedforskjellen i at den finnes på nett. Fordelen er derfor at ingenting trengs å lastes ned. Skisser vi lagde i nettleseren var våre egne og kan brukes til hva vi ønsket, samt eksporteres og lagres lokalt på maskinen vår. Ved å bruke Draw har vi klart å lage UML-diagram som skal hjelpe med å visualisere oppsettet av applikasjonen i ServiceNow Kommunikasjon WebEx Kommunikasjonsverktøyet brukt mellom gruppen og oppdragsgiver, ServiceNow, har vært WebEx (CISCO, udatert). Dette tilbyr både lyd, bilde/videosamtale samt fildeling. Krever egen innlogging og det er gratis registrering Skype Kommunikasjonsverktøy brukt mellom gruppen og veileder ved Høgskolen i Oslo og Akershus, de gangene det ikke var mulig å møtes ansikt til ansikt. Skype tilbyr kommunikasjon med både lyd, bilde/videosamtale samt fildeling (Microsof, udatert). Et gratis verktøy å bruke som krever egen innlogging. 19

23 Slack Kommunikasjon brukt internt i gruppen. Slack (Slack, udatert) er et gratis program som tilbyr flere type plugins som igjen gjør det mulig å bruke programmet på flere måter. Gruppen tok hovedsakelig i bruk Slack til å lage ulike chatterom/kanaler for deler av prosjektet. Dette gjorde at vi til enhver tid var klar over hvilke planer vi har satt, tanker vi har gjort oss og konklusjoner vi har kommet frem til om de ulike delene av prosjektet. Figur 3 Alle slack-chatene våre til venstre med en tom (sensurert) #general chat Trello Et av de viktigste verktøyene for oss har vært Trello (Trello, udatert). Det har vært der vi har strukturert prosjektet vårt ved hjelp av Kanban, delt det inn i oppgaver, trukket oppgavene gjennom en prosess og til slutt markert de som ferdig. Fordelen med Trello er at hver oppgave blir et eget kort, en slags forum, der vi kan laste opp filer, kommentere, sette frister og annet som skal til for å definere oppgaven og fullføre den. Mens vi har hatt Slack for overordnet kommunikasjon om ulike tema i forskjellige chatter, har vi brukt Trello for å diskutere hver enkelt oppgave Outlook Til formell kommunikasjon ut mot oppdragsgiver ServiceNow og Coop, har vi brukt e- post. Til dette har vi tatt i bruk Outlook (Microsoft, udatert-a) da dette er et godt verktøy for sortering av e-post, men også har en godt integrert kalenderfunksjon vi har tatt i bruk hyppig for å sette inn avtaler og møter. 20

24 4.7.4 Versjonskontroll GitHub Koden vi har skrevet og skriptene vi har laget, er blitt lagret på GitHub (GitHub, udatert) slik at vi enkelt kan dele det med hverandre, endre, forbedre og oppdatere i sanntid. GitHub har gitt oss muligheten til å drive med versjonskontroll av prosjektet. Det vil si at vi til enhver tid kan gå tilbake til et tidligere punkt, tidligere versjoner, av koden og skriptene våre. På den måten har vi integrert backup av kode og skript på GitHub, som vil si at om vi skulle gjøre en fatal feil langt frem i prosjektet er det mulig å gå tilbake til en tidligere versjon og forhindre feilen Utvikling ServiceNow Customer Retail Management -systemet, CRM-systemet for kort, er systemet vi brukte for å lagre scriptene våre og kommunisere med chippen. Her utvikles applikasjonen som skal tas i bruk og rammeverket for lagring av data og informasjonsvarsling. Oppdragsgiver er ServiceNow og prosjektet er for Coop Norge. Coop benytter seg av ServiceNow sin plattform, og vi måtte derfor utvikle applikasjonen i ServiceNow (ServiceNow, udatert-h) Arduino IDE Til å programmere NodeMCU vår har vi tatt i bruk Arduino IDE (Arduino, udatert-c) til å skrive kode som kompileres på riktig måte for enheten å tolke. Programmet leser C/C++ (Arduino, udatert-b) som den så kompilerer for NodeMCU slik at den forstår hva det er som skal utføres. Arduino IDE er et open source program som vil si at utviklere selv kan komme med alternativer som gjør IDE en bedre kontinuerlig. Vi valgte derfor å gå for Arduino IDE som har et stort og bredt miljø for hjelp og støtte Postman Til å jobbe med REST API har vi tatt i brukt Postman. Postman er en Google Chrome extension som gjør det lett å jobbe med API. Vi har brukt Postman for bli bedre kjent med hvordan REST API fungerer, slik at det blir lettere å jobbe med ServiceNow sitt REST API senere i prosessen. Vi begynte altså først med REST kall til ServiceNow via Postman, denne dannet grunnlaget vårt til å lære om hvordan vi faktisk skulle kode det i C++. Fordelen med Postman er at man enkelt kan utføre rest kall uten behov for koding. 21

25 Atom Til bruk av CSS og HTML koding har gruppen brukt tekst editoren Atom (Atom, udatert). Fordelen med Atom er at det er en enkel, moderne og svært fleksibel editor som fungerer over flere plattformer (Windows, OS X, Linux). Den har gitt oss muligheten til å sette opp utviklingsmiljøet vårt nøyaktig slik vi ønsker som individer, og har smart autofylling for kode når vi skriver, som gjør det raskere å programmere Viscosity En gratis VPN-tjeneste som Høgskolen i Oslo og Akershus tar i bruk for at studenter skal kunne koble seg på skolens servere. Vi tok i bruk Viscosity (SparkLabs, 2017) for å koble til skolen og lage bachelorgruppens hjemmeside (HiOA, 2016). 22

26 Innholdsfortegnelse: Prosessdokumentasjon 5.0 Prosessdokumentasjon Prosjektstart og plan Valg av oppgave Arbeidsmåter Prosjektstyring Utvikling av IoT-enhet: Coolity Coolity 0.1: Arduino UNO Temp Coolity 0.1.1: Arduino UNO Trådløs Coolity 0.2: NodeMCU Lampe Coolity 1.0: Funksjonell Prototype Koding av Coolity Sikkerhet Maskinvare (Coolity) Programvare Coolify-applikasjon Nettverkskommunikasjon Utviklingsprosess av applikasjonen Coolify Oppstart Utviklingsfase Utfordringer i utviklingen Dokumentasjonsfasen Dagbøker Gruppedagbok Møtereferat

27 5.0 Prosessdokumentasjon I denne delen av oppgaven vil vi gå igjennom oppstart, strukturering og tilegning av kunnskap i løpet av prosjektperioden. Denne delen er ment for alle og gir en innsikt i hvordan vi gjorde undersøkelser om tidligere oppgaver og krav vi ønsket å stille til vår egen. Vi går igjennom planlegging av prosjektet, hvilke arbeidsmetoder og verktøy vi benyttet oss av, og hvordan vi strukturerte arbeidet. Leseren vil bli introdusert til både planlegging, utvikling, tanker og refleksjoner rundt både prototypen Coolity og applikasjonen Coolify. Det forventes at leser har noe forståelse for fagbegrep og tekniske begrep innen IT, men de mest sentrale ord, begreper og uttrykk er å finne i punkt 12.0 Dataordbok. 5.1 Prosjektstart og plan Valg av oppgave Prosessen ved å finne bacheloroppgave startet allerede høsten Under JavaZone (JavaBin, 2016) i september brukte vi anledningen til å høre hvilke selskap som hadde bachelorprogrammer, hva slags oppgaver som var gjort tidligere, hvilke programmeringsspråk de favoriserte og hvilke utviklingsmetoder de tok i bruk. Ut ifra det visste vi hva som var mest populært i markedet, fikk en pekepinne på hva slags oppgaver vi kunne forvente oss og hvordan det var ønskelig at de skulle løses. På bakgrunn av det satte vi noen krav til oppgaven vi ønsket å ha: 1. Det skulle være noe som faktisk kunne bli tatt i bruk. Gruppen ønsket ikke å lage noe bare for oppdragsgiver å se at vi innehar visse ferdigheter til å bli ansatt. 2. Prosjektet skulle følge en smidig utviklingsmetode. Mest fordi de fleste vi snakket med anbefalte dette og sa at deres team jobbet smidig, men også fordi vi tenkte at vi visste at når vi skriver bachelor vil vi ikke alltid være sikre på hva vi gjør, og må derfor kunne tilpasse oss ulike resultater, situasjoner og interesserte parter. 3. Tilgjengelig veileder fra oppdragsgiver. Hvis vi mot formodning skulle ende opp med å stå helt fast på noe punkt, skulle det være mulig å få veiledning og hjelp. 4. Det skulle være noe nytt innen IT-verden. Viktigst for oss var at vi kunne gjøre noe ikke alle store IT-selskaper har gjort og som er spennende. Så i tillegg til at vi ønsket å lage noe som kunne tas i bruk, ønsket vi at det også skulle være nytt eller unikt. 24

28 I løpet av oktober og november hadde vi allerede vært i kontakt med potensielle oppdragsgivere, deriblant ServiceNow. Han presenterte en internet of things oppgave for oss som virket svært interessant, og som det var mulighet for at en reell kunde ønsket å ta i bruk. Samtidig lovet han veiledning og hjelp ved behov 10. Odd ville ikke være med oss fysisk fra dag til dag men var tilgjengelig over mail i tillegg til at han satte opp en møteplan på annenhver uke. For oss ville det si at vi hadde muligheten til å sette opp strukturen på prosjektet selv og at kravet til struktur internt i gruppen måtte være svært god med tanke på at vi ikke hadde en veileder som fulgte oss fra dag til dag. Forslaget fra ServiceNow fylte altså alle våre ønsker til oppgave. Det var en oppgave som hadde potensiale til å kunne bli tatt i bruk, vi kunne selv velge en smidig utviklingsmetode, vi hadde tilgjengelig veileder som kunne hjelpe hvis vi satt helt fast, eller henvise oss til det internasjonale nettverket sitt for hjelp, og kanskje det viktigste; Produktet var nytt og spennende! 5.2 Arbeidsmåter Prosjektstyring Smidig Gruppen valgte en smidig (agile på engelsk) utviklingsmetode i prosjektet. Det kom hovedsakelig av at de fleste selskap nå bruker ulike former for smidig utvikling når de skal lage noe, men også for at det er den mest tilpasningsdyktige utviklingsmetoden. I tillegg var oppgaven kun på idéstadiet da vi begynte, uten en ordentlig definert kravspesifikasjon, som krevde at vi tilpasset oss endringer og krav raskt. Hadde vi valgt en tradisjonell utvikling som hadde fulgt en plandrevet utviklingsmetode, ville det ha krevd mye planlegging og formell dokumentasjon. Det ville gjort at jo lenger ut i prosjektet vi kom, desto vanskeligere hadde det vært å endre eller legge til funksjonalitet. I et lønnet prosjekt ville dette ha kostet arbeidsgiver mye, vi måtte ha brukt tid på å opprette ny dokumentasjon, oppdatere eller kaste gammel dokumentasjon og utviklet arbeid måtte kanskje ha blitt skrapet eller gjort på nytt. Det var derfor enighet i gruppen om at vi skulle gå for en smidig utviklingsmetode. Vi delte opp prosjektets ulike hoveddeler slik vi oppfattet prosjektet inn i hver måned frem til mai og satte det opp på følgende måte: MÅNED OVERORDNET OPPGAVER Januar ServiceNow kurs. 10 Se 12.2 Vedlegg 2 Epost fra veileder ved ServiceNow. 25

29 Februar Mars April Mai Utvikling og testing av enhet. ServiceNow applikasjonsutvikling. Grundig test av enhet og applikasjon. Rapportskriving. Ferdigstilling av rapport og presentasjonsøving. Gruppen var nødt til å sette noen overordnede planer slik at vi for eksempel ikke endte opp med å gjøre endringer på IoT-enheten i april, når vi skulle være ferdig med den i februar. Dette kommuniserte vi til ServiceNow og Coop. Det var spesielt viktig at Coop var klar over det, da de var åpne for å ta i bruk IoT-enheten i butikker og dermed kunne finne på å stille nye krav underveis i prosjektet. Det viste seg og ikke være noe problem da både ServiceNow og Coop var klar over at det kun ville være en prototype som skal teste mulighetene i systemet og teknologien Kanban For å styre prosjektet tok vi i bruk den smidige metodikken Kanban. Gruppen valgte da å bruke Kanban til å styre hele prosjektet, ikke bare utviklingen av kode og IoTenheten. Vi baserte oss på kunnskapen vi har lært fra fag på skolen og fra Jim Benson og Tonianne DeMaria Barry sin bok: Personal Kanban, Mapping Work Navigating Life (Benson & Barry, 2011), som viser hvordan Kanban kan bli tatt i bruk for alt og for små team. Fordelen med Kanban i motsetning til scrum for eksempel, var at vi kunne definere og sette det opp på en måte vi var komfortable med, som igjen førte til at kanbanboardet ble tatt i bruk. Scrum krever faste kolonner og legger arbeid i tidsbaserte sprinter. Kanban gjorde det mulig for oss og heller fokusere på arbeidet ved å begrense hvor mye arbeid som kunne være i hver kolonne, uten å måtte tenke på at noe måtte leveres til en fastsatt frist. Årsaken til det var at vi ville unngå følelsen av å ha mislyktes om et arbeid ikke var ferdig til dagen vi ønsket, slik det kan oppleves i en Scrum-sprint om noe ikke leveres Prosjektstyringsverktøy Gjennom prosjektets løp er det nyttig å kunne få et overblikk over progresjon. Siden vi ikke hadde et fysisk kontor tilegnet oss, ville det gitt lite mening å sette opp et Kanbanboard med post-it lapper. Løsningen ble å finne et digitalt verktøy som gjorde det lett for oss å få ønsket oversikt over prosjektet. Vi var innom Microsoft Project, Jira og ServiceNow sitt eget Visual Task Board, men vi bestemte oss for å ta i bruk Trello (Trello, udatert). Trello er et svært enkelt og brukervennlig online verktøy som lar oss sette opp kolonner og lage oppgaver (cards) enkelt både i begynnelsen av prosjektet, og etterhvert som prosjektet utviklet seg. I motsetning til konkurrentene er 26

30 Trello gratis og enklere å lære seg. Til hver oppgave kunne vi klikke inn på hver oppgave og legge til: Description (Beskrivelse) Member (Medlem med tilgang til boardet) Label (Merkelapp vi selv lagde og kunne sortere med navn og farge) Checklist (Flere sjekklister med navn og oppgaver) Due Date (Frist for når vi skulle snakke om oppgavens situasjon, eventuelt huke av med tid og dato oppgaven ble ferdig) Attachment (Vedlegg, enten det var linker til nettsider eller filer) Comment (Kommentar til oppgaven) Det fantest både power-ups og actions vi kunne benytte oss av på oppgavene, men det var ikke av interesse for oss og lite nyttig da vi hovedsakelig kun opprettet en oppgave, fylte den med nødvendig informasjon og flyttet den gjennom Kanbanboardet. 27

31 28

32 Figur 4 Eksempel på en oppgave med beskrivelse, som hele gruppen jobbet med, hadde label, tid og dato for når den ble ferdig, fil fra drive og link til UML-diagram, og kommentarer Som vi nevnte innledningsvis under Prosjektstyring og Smidig, hadde gruppen et overordnet mål for hver måned og ved å visualisere arbeidet vi hadde i Kanbanboardet, visste vi om vi lå godt an eller om det var for mye arbeid som gjenstod i backloggen. Vi satte følgende kolonner og begrensninger i Kanbanboardet: KOLONNE BESKRIVELSE BEGRENSNING BACKLOG READY DOING THE PEN Alle oppgaver vi måtte gjøre i prosjektet ble satt opp her, sammen med brukerhistoriene for IoT-enheten. De ble brutt ned i mindre, håndterbare oppgaver, slik at alle oppgaver i prinsippet kunne utføres av en person. Oppgaver som var ferdigdefinerte ble dratt fra BACKLOG til READY. Det vil si at oppgavene var definert godt nok til at vi visste hva som måtte gjøres for å ferdigstille de. Oppgavene vi jobbet med ble dratt fra READY til DOING. Her var målet å fullføre oppgaven så godt det lot seg gjøre, og på tidspunktet vi befant oss i. Det var for eksempel noen kurs som var relevante for oss, men som var utdaterte. Det førte til at vi bare fikk gjort deler av det mest essensielle, men ikke fullført hele kurset. Andre ganger fikk vi gjort en oppgave ferdig på et tidspunkt, men det var sannsynlig at de ville måtte jobbe med oppgaven igjen senere i form av optimalisering for eksempel, og disse ble plassert i Midlertidig DONE. Selv om vi fullførte oppgaver, oppstod det situasjoner der vi var avhengig av en ekstern part for å kunne si oss ferdig med oppgaven helt. Da vi skrev kontrakter og trengte signeringer fra Høgskolen og arbeidsgiver for eksempel, hadde vi gjort oppgaven av å skrive kontraktene, men var fortsatt avhengig av eksterne for å signere den. Benson og Barry (Benson & Barry, 2011) kaller det derfor THE PEN, for vi er Ingen begrensning. Alt arbeid skulle føres inn i backloggen. Ingen begrensning. 3 oppgaver per person i gruppen. Totalt betyr det 12 oppgaver samtidig, men ofte jobbet vi flere på samme oppgave, som førte til at det aldri skjedde. 3 oppgaver totalt. Alt som ble satt i THE PEN skulle begrunnes med hvorfor det var der, hva vi ventet på og når det skulle følges opp om det ikke var noe svar. 29

33 TESTING DONE Dokumenter & Planer Midlertdig DONE avhengig av signatur. Vi har til tider også bare kalt det PENDING, da vi kunne vente eksterne sine godkjenninger, enten det var signatur, mail eller generell hjelp. Denne delen ble inkludert i Kanbanboardet i slutten av februar, da vi begynte å teste IoT-enheten koblet til batteri (tidligere kun micro-usb) og lagde tilhørende kode og script. Da vi hadde gjort det som kunne gjøres i DOING og ville bekrefte funksjonalitet eller visste hva slags kode eller scripts som måtte lages, satte vi det i TESTING. Oppgaven måtte først testes og fungere slik vi ønsket, før vi satte det i DONE. Det kom av at vi for eksempel hadde funnet flere alternativer til hvordan å bruke REST API, men vi brukte tid på å faktisk klare å sende GET- og POST-kall til ServiceNow instancen fra IoT-enheten vår. Alle koder og script ble testet i forhold til IoT-enheten, kommunikasjonen mellom IoT-enhet og applikasjon i ServiceNow, og i forhold til applikasjonen i seg selv. De fleste oppgaver som var ferdig definert, løst og eventuelt testet, ble plassert i DONE. Disse oppgave var oppgaver som vi ikke kom til å jobbe med igjen, og som vi var helt ferdig med. Etterhvert som prosjektet begynte å vokse og vi fant nyttig artikler, skrev viktige dokumenter for prosjektet, lagde skisser for IoT-enheten og kode, og generelt andre ting vi tenkte var viktig å ha tilgjengelig, oppdaget vi at vi ikke bare kunne ha denne informasjonen i Drive (Google, udatert), men at vi også kunne dra filene fra drive inn i Kanbanboardet vårt slik at vi både hadde prosjektarbeid og filer i bruk lett tilgjengelig på ett sted. Halvveis i prosjektet oppdaget vi at noen oppgaver vi gjorde på et tidspunkt, ville vi måtte komme tilbake til senere. Typisk eksempel var sluttrapporten som vi skrev flere utkast av, og som vi senere la inn 3 tester har vært maksimalt antall tillatt samtidig. Til å begynne med var dette 2, da vi i begynnelsen sto overfor kritiske tester for å sikre oss om at alt fungerte. Det inkluderte testing av enhet, kode og script. Ingen begrensning. Ingen begrensning. 5 oppgaver satte vi som maksgrense, da det hovedsakelig var elementer i sluttrapporten og 30

34 kommentarer på om hvordan vi kunne forbedre. Da ble det opprettet en ny oppgave med kommentarene fra den før og versjonsnummer ble satt på. Så snart oppgaven gikk fra BACKLOG, til READY og inn i DOING, ble den tidligere satt inn i DONE. Når den nye versjonen ble ferdig satte vi den i DONE, eventuelt i Midlertidig DONE for så å repetere prosessen til vi var helt fornøyde. samling av koder og skisser som oftest ble satt i Midlertidig DONE. Her ville ingen overraskelser komme og vi håndterte trafikken bra. Figur 5 Vårt egendefinerte Kanbanboard laget med Trello viser kolonner og oppgaver Målet er å visualisere arbeidsflyten og skape en konstant strøm gjennom hele prosjektet. Gruppen brukte to ukers iterasjoner der vi vurderte omfang av det som skulle gjøres og hva vi mente vi kunne få til på de to ukene. Deretter dro vi arbeidet fra BACKLOG til READY. Dette ble en fast rutine: Planlegger Designer Lager/Programmerer Tester (Utplassere) Hver oppgave ble utført på denne måten i plenum i gruppen, slik at vi alle hadde forståelse for hva som skulle gjøres, diskuterte hvem som ville og kunne gjøre det, for så å starte arbeidet. 31

35 5.3 Utvikling av IoT-enhet: Coolity Til å begynne med hadde ServiceNow satt en midlertidig kravspesifikasjon 11 som vi måtte basere prototypen vår på frem til vi hadde hatt et møte med Coop: KRAVSPESIFIKASJON SERVICENOW IOT-ENHET Arduino UNO utviklingskort / kretskort skal benyttes. WiFi-chip av typen ESP8266 (Kjell & Company, udatert-h) skal benyttes. Temperaturmåler skal benyttes. APPLIKASJON WiFi-chipen skal sende data til en applikasjon vi lager i ServiceNow. Applikasjonen skal inneholde terskler for temperatur og varsle dersom temperaturen faller utenfor terskelverdiene. Ingen av gruppemedlemmene hadde noen tidligere erfaring med bruk av Arduino utviklingskort, og vi ble derfor nødt til å tenke på hvordan vi enklest kunne tilegne oss denne kunnskapen. Med unntak av et gruppemedlem som hadde fullført et nytt og teoretisk fag kalt ADSE1310 Internet of Things ved Høgskolen i Oslo og Akershus, hadde ingen av medlemmene noen erfaring med internet of things (IoT) fra før av. Som IT-studenter hadde vi alle hørt om utviklingskort på størrelse med bankkort, men ingen hadde noen erfaring med å utvikle på slike utviklingskort tidligere. Ved Høgskolen i Oslo og Akershus har studentene som går linjene Dataingeniør, Informatikk og Anvendt Datateknologi fokus på ren programvare og kommer såvidt innom maskinvare gjennom fag som Operativsystemer. Skolen har en egen linje for elektronikk utviklet for informasjonsteknologi kalt Elektronikkingeniør. Der lærer man om bruk og programmering av utviklingskort/kretskort. Blant slike utviklingskort er Arduino tatt i bruk i den utdanningen. I denne oppgaven havnet vi i en situasjon der vi fikk muligheten til å bruke våre kunnskaper innen brukersentrert utvikling og ferdigheter innen programmering, samt lære oss å utvikle på fysiske utviklingskort. IoT er noe av det heteste innen IT 11 Dette er også omtalt under Kravspesifikasjon og Oppdragsgivers og Kundes kravspesifikasjon 32

36 akkurat nå, og vi hadde derfor en stor vilje og et stort engasjement til å tilegne oss kunnskaper for å utvikle en IoT-enhet som også samarbeider med en såpass stor sky-aktør som ServiceNow. Kjell & Company (Kjell & Company, udatert-c) hadde en startpakke (Kjell & Company, udatert-b) vi kunne ta i bruk som inkluderte det vi trengte for å komme i gang; både for å lære oss hvordan å programmere på utviklingskortet og å komme i gang med en prototype. I startpakken fulgte det blant annet med en Arduino prosjektbok og en Arduino UNO i tillegg til ekstra utstyr for å kunne eksperimentere med ulike prosjekter. Dette var nok til å lage vår første prototype som fikk navnet Coolity. Endelsen -ity er ekvivalent til endelsen -het på norsk, som i kulhet, kaldhet. På engelsk gir navnet konnotasjon til quality og andre kjente -ityer, som usability, readability, unity, som alle står i stil med XaaS. Merk at Coolity er navnet på enheten og prototypen, mens Coolify er navnet på applikasjonen vi lager i ServiceNow. Vi anser navnet som et slags engelsk verb der applikasjonen coolifyer coolityen. En Coolity-enhet må Coolifyes om den skal være en Coolity, dette gjør applikasjonen. Figur 6 Arduino startpakke 12 Figur 7 Utstyr i Arduino startpakken

37 Vi vil i denne delen av oppgaven gå igjennom de fire forskjellige versjonene av prototypene vi laget. Arbeidsprosessen med hver prototype hadde en start, utfordring, løsning og vurdering til slutt, og denne prosessen ble repetert tre ganger før vi hadde en funksjonell prototype som oppfylte kravene fra ServiceNow og Coop. Figur 8 Prototypens "circle of life" Vi lagde altså fire prototyper der de to første fylte kravene fra ServiceNow i januar, og de to siste bygger videre på kravene for å tilfredsstille Coop sine krav som kom i februar. KRAVSPESIFIKASJON ServiceNow PROTOTYPE-VERSJON Coolity 0.1: Arduino UNO Temp Coolity 0.1.1: Arduino UNO Trådløs Coop Coolity 0.2: NodeMCU Lampe Coolity 1.0: Funksjonell Prototype Coolity 0.1 og hadde som formål å vise at tingene kan fungere sammen. Coolity 0.2 og 1.0 optimaliserer løsningene ved å gjøre den mindre og gi den mulighet til å koble til batteri. 34

38 5.3.1 Coolity 0.1: Arduino UNO Temp Vi oppdaget at vi i startpakken hadde utstyret vi trengte for å lage en temperaturmåler. I første omgang ville vi bare øve på å programmere Arduino UNO en og å få den til å måle temperatur. Til å begynne med trengte vi å lære oss å ta i bruk Arduino IDE, som igjen betydde at vi trengte å lære oss C og C++ 14 (Heretter kun referert til som C++ (Kumar, udatert)). Dette var ikke noe stort problem da det er liten forskjell annet enn syntaks 15 fra Java til C++. Java var noe vi alle hadde kjennskap til i gruppen og det var derfor ikke vanskelig å tilpasse seg C Prototypen Allerede etter å ha kjøpt startpakken den første dagen fikk vi til å lage en versjon som målte temperaturen i rommet vi var i. De røde lampene ga tilbakemelding på temperaturen og vi kunne sette grenseverdier for hver om når de skulle lyse. Code 58. float temperature = (voltage -.5) * 100; 59. Serial.println(temperature); // if the current temperature is lower than the baseline 62. // turn off all LEDs 63. if (temperature < baselinetemp + 2) { 64. digitalwrite(2, LOW); 65. digitalwrite(3, LOW); 66. digitalwrite(4, LOW); 67. } // if the temperature rises 2-4 degrees, turn an LED on 68. else if (temperature >= baselinetemp + 2 && temperature < baselinetemp + 4) { 69. digitalwrite(2, HIGH); 70. digitalwrite(3, LOW); 71. digitalwrite(4, LOW); 72. } // if the temperature rises 4-6 degrees, turn a second LED on 73. else if (temperature >= baselinetemp + 4 && temperature < baselinetemp + 6) { 74. digitalwrite(2, HIGH); 75. digitalwrite(3, HIGH); 76. digitalwrite(4, LOW); 77. } // if the temperature rises more than 6 degrees, turn all LEDs on 78. else if (temperature >= baselinetemp + 6) { 79. digitalwrite(2, HIGH); 80. digitalwrite(3, HIGH); 81. digitalwrite(4, HIGH); 82. } 14 C og C++ er to type programmeringsspråk. I motsetning til C, så støtter C++ klasser og objekter. 15 Hvordan en sorterer kode. 35

39 Dette var noe vi tok i bruk i den første prototypen kun for å se at den ga en form for tilbakemelding. Figur 9 Coolity Utstyr og dimensjon Coolity 0.1 bestod av: UTSTYR ANTALL Arduino UNO utviklingskort 1 USB-kabel 1 Koblingsbrett 1 Plasseringsbrett (Stand for utstyr) 1 Ledninger 8 Lamper 3 Resistorer 3 Temperaturmåler 1 36

40 Totalt 19 Figur 10 Coolity 0.1 dimensjoner Coolity 0.1 dimensjoner: DIMENSJON cm Bredde 11.5 Dybde 9.3 Høyde Vurdering Vi hadde nå klart å registrere målinger fra temperaturmåleren og få det vist på en maskin, det neste vi trengte å gjøre var å få den til å sende temperaturmålingene trådløst til en annen enhet Coolity 0.1.1: Arduino UNO Trådløs For å kunne sende temperaturmålingene ønsket ServiceNow at vi skulle ta i bruk en ESP WiFi-chip (Kjell & Company, udatert-h) (Heretter referert til som WiFi- 37

41 chip). I versjon av Coolity anskaffet vi oss derfor en WiFi-chip og tilhørende ledninger (Kjell & Company, udatert-d) for å kunne koble det til koblingsbrettet vårt. Dette oppsettet gjorde det mulig å programmere WiFi-chipen gjennom Arduino UNO en. Det var ikke lenger behov for lampene da vi visste at temperaturmåleren registrerte riktig og at lampene bare tok ekstra plass. Men å koble opp WiFi-chipen var ikke like lett som det hadde vært å sette opp første versjon av Coolity; Coolity Utfordring Det tok oss litt tid til å finne ut av hvordan vi skulle koble til og programmere WiFichipen. Vi visste hverken hvordan koblingen fra den fysiske WiFi-chipen skulle være til koblingsbrettet eller hvordan forholdet og kommunikasjonen må settes opp for å kommunisere med Arduino UNO utviklingskortet. Spørsmålene vi stilte oss var: - Får WiFi-chipen nok strøm / Får den for mye? - Hvordan begrenser vi strømmen? - Hvordan skal vi forsikre oss om at den fungerer? Løsning Til å begynne med måtte vi finne ut hvor mye strøm ESP8266 WiFi-chipen tålte. Vi fant brukermanualen på nett (Arduino, 2015) og oppdaget at WiFi-chipen kun tålte 3.3V strøm. Siden WiFi-chipen selv ikke hadde en regulator som regulerte mengden strøm den mottok, om det var for mye - eller at strømkilden til Arduino UNO-brikken ikke var nok alene, anskaffet vi en strømforsyning til koblingsbrettet som også kunne regulere strømmen mot WiFi-chippen (Kjell & Company, udatert-g). 38

42 Figur 11 Strømforsyning fra Kjell & Company Denne kunne bytte mellom å gi 3.3V og 5V spenning fra adapter eller USB. Dette ble gjort enkelt ved å ta av en liten koblingsbrikke og bytte mellom å sette den på to pins som enten indikerte 5V, OFF (Av) eller 3.3V. Disse vises nede til høyre og venstre på strømforsyningen over. Da bildet ble tatt var begge kildene satt til 3.3V. Nedenfor er et bilde av koblingsbrikken tatt av fra venstre som styrer spenningen på adapter. Avhengig av hvilke to pins en setter koblingsbrikken på, så begrenses spenningen til WiFi-chipen. 39

43 Figur 12 Strømforsyning og demonstrasjon av spenningsbrikken som kan plasseres på 5V eller 3.3V Til nå hadde vi altså funnet ut hvor mye spenning WiFi-chipen tålte, og hvordan vi kunne styre den. Det som gjensto var hvordan vi kunne teste om den fungerte. Code / AT command 1. //Test if AT system works correctly 2. AT 3. //Commands ESP8266 to connect a SSID with supplied password. 4. AT+CWJAP="my-test-wifi","1234test" For å teste at WiFi-chipen fungerte som vi ønsket, programmerte vi chipen og koblet den fra laptopen. Deretter koblet vi adapteret til strøm i en annen stikkkontakt innenfor rekkevidden til ruteren og skrudde den på. Deretter måtte vi koble Coolity til samme nettverk som en av laptopene våre og bekrefte at laptopen mottok målinger. Vi brukte en mobiltelefon som hotspot for å koble Coolity og PC til det samme trådløse nettverket og oppdaget at vi fikk målingene inn på PC en. 40

44 Prototypen Figur 13 Coolity For å kunne lage Coolity trengte vi å finne ut av hvordan å kunne programmere WiFi-chipen. Dette løste vi ved å programmere Arduino UNO en til å kommunisere med WiFi-chipen. Det betydde at vi både måtte koble til strøm til WiFi-chipen gjennom strømforsyningen, og til Arduino UNO-utviklingskortet for å kunne programmere WiFi-chipen gjennom den. Figur 14 Coolity med strømforsyning og ESP8266 WiFi-chip 41

45 Utstyr og dimensjon Ved å fjerne lampene ble Coolity flatere og bestod nå av: UTSTYR ANTALL Arduino UNO 1 USB-Kabel 1 Adapter 1 Koblingsbrett 1 Strømforsyning koblingsbrett 1 Plasseringsbrett (Stand for utstyr) 1 Ledninger 13 Resistor 1 Temperaturmåler 1 WiFi-Chip 1 Total 22 Coolity sin dimensjoner: DIMENSJON cm Bredde 11.5 Dybde 9.3 Høyde Vurdering Coolity var den første prototypen vi lagde som hadde det grunnleggende vi trengte og som fylte de første kravene fra ServiceNow: Et Arduino utviklingskort og måling av temperatur. I siste uken av januar begynte vi med utvikling av prototypene og var klar med Coolity til et møte med veileder fra ServiceNow mandag 30 januar. Vi var nå på riktig spor ved at vi hadde en fungerende WiFi-chip og PC som kunne motta målinger, men det kom også frem av tilbakemeldinger at de forventet mindre utstyr. 42

46 Dette passet godt i våre planer da utvikling og testing av enhet var satt til februar, så vi hadde fortsatt tid til å endre og tilpasse Coolity versjoner. I tillegg til det hadde vi avtalt et møte med Coop for å få klarhet i deres ønsker, og en form for kravspesifikasjon, torsdagen 2. februar Coolity 0.2: NodeMCU Lampe Til Coolity 0.2 måtte vi finne alternativer til Coolity Vi var noe i tvil om hvor store endring vi skulle gjøre før møtet med Coop. Vi hadde en enkel kravspesifikasjon fra ServiceNow om en Arduino som sender signaler via WiFi, og vi hadde fått tilbakemeldinger om at Coolity var for stor og at vi selv kunne finne alternativer. På bakgrunn av det bestemte vi oss for å finne forbedringer vi visste ville spare kostnader og som ville gjøre produktet bedre, samtidig som enheten skulle være mindre. Vi var sikre på at Coop ikke ville gi en tilbakemelding om at de ønsket en større enhet, dyrere og med flere komponenter som kunne forårsake feil Utfordring I all hovedsak trengte vi en enhet som hadde integrert WiFi-chip, mindre ledninger og egen regulator som kunne styre strømmen fordelt på utviklingskortet. De to hele dagene vi hadde fra møtet med ServiceNow mandag 30. januar til møtet med Coop torsdag 2. februar, brukte vi til å finne alternativer. Vi så blant annet på Raspberry Pi 3 (Raspberry Pi, udatert) som både hadde integrert WiFi-chip og ingen ledninger. Den ville vært litt større enn Arduino UNO utviklingskortet, men uten noe koblingsbrett, egen strømforsyning til WiFi-chipen eller ledninger. Problemet var at prisen var merkbart større enn hva Arduino UNO kostet og at den hadde flere funksjoner og komponenter på utviklingskortet som vi ikke trengte. I tillegg til det måtte vi ha tilpasset oss et eget operativsystem og funnet løsning eller guide 16 på hvordan å koble opp en temperaturmåler til Raspberry Pi 3. Dette var ting vi hadde funnet lett tilgjengelig i utviklingsheftet for Arduino UNO en. Vi var på utkikk etter en enhet som hadde minst mulig unødvendig komponenter, krevde lite endring fra hva vi hadde lært så langt og som var mindre enn både Raspberry Pi 3 og Arduino UNO Løsning 31. januar kom et av gruppemedlemmene på at vi hadde sett en demonstrasjon av en NodeMCU (NodeMCU, udatert) på JavaZone i 2016 (JavaBin, 2016), og vunnet en slik en i en konkurranse. NodeMCU en var under halvparten av størrelsen til Arduino UNO og trengte hverken ledninger eller eksterne strømkilder, hadde integrert ESP8266 WiFi-chip, kunne programmeres i samme språk og i Arduino 16 Forklaring på hvordan et program eller handling skal utføres. 43

47 IDE en som vi allerede var blitt kjent med, og vi kunne kjøpe den på dagen da Kjell og Company hadde varen inne (Kjell & Company, udatert-f). Figur 15 NodeMCU utviklingskort 17 Alternativt kunne vi ha gått for en Adafruit Feather HUZZAH (Kjell & Company, udatert-a) med omtrent samme spesifikasjoner og samme pris, men vi valgte heller NodeMCU da den ikke trengte noen form for lodding slik det viste seg at Adafruit Feather HUZZAH gjorde. Den krevde nemlig at vi loddet på pins 18 for tilkobling til koblingsbrett og det var ikke noe vi følte oss trygge på. Nedenfor er det inkludert en tabell som viser størrelsesforskjellen på de ulike utviklingskortene vi vurderte i forhold til Arduino UNO. DIMENSJON Arduino UNO (Arduino, udatert-a) Raspberry Pi 3 (SocialCompar e, udatert) Adafruit Feather HUZZAH (Adafruit, 2015) NodeMCU (CNXSoft, 2015) Bredde (mm) Dybde (mm) Eller pin header er en form for elektronikktilkobling og er vanligvis hankjønn. 44

48 Høyde (mm) (krever lodding av pins) 13 Figur 16 Sammenlikning av størrelser for ulike utviklingskort Prototypen Med tanke på at vi hadde gjort oss litt kjent med programmering av Arduino UNO en og Arduino IDE, brukte vi dagen før møte med Coop 2. februar til å programmere og teste at NodeMCU fungerte slik vi ønsket. Til å begynne med ville vi prøve å få en lampe til å lyse på den ved hjelp av et REST-kall fra en nettleser til enheten. På denne måten forsikret vi oss om at NodeMCU en var noe vi kunne håndtere, forstod og var villig til å bruke. 45

49 Figur 17 Coolity 0.2 REST-kall for å lyse lampe På bilde over tester vi å bruke NodeMCU fra JavaZone på koblingsbrettet vi fikk i startpakken til Arduino UNO en. Vi programmerte den ved hjelp av Arduino IDE en og ga strøm ved hjelp av en microusb-kabel koblet til en av våre maskiner. Ved å taste inn en nettadresse på mobilen får vi opp grensesnittet som består av, av og på knapper. Når på-knappen trykkes sender vi et REST-kall som skrur på lampen. Code 1. #include <ESP8266WiFi.h> 2. const char* ssid = "wifi-ssid"; 3. const char* password = "wifi-password"; int ledpin = LED_BUILTIN; // GPIO13 6. WiFiServer server(80); // Read the first line of the request 57. String request = client.readstringuntil('\r'); 58. Serial.println(request); 59. client.flush(); 60. // Match the request 61. int value = LOW; 62. if (request.indexof("/led=on")!= -1) { 63. digitalwrite(ledpin, HIGH); 64. value = HIGH; 65. } 66. if (request.indexof("/led=off")!= -1) { 67. digitalwrite(ledpin, LOW); 68. value = LOW; 46

50 69. } if(value == HIGH) { 86. client.print("on"); 87. } else { 88. client.print("off"); 89. } 90. client.println("<br><br>"); 91. client.println("<a href=\"/led=on\"\"><button>turn On </button></a>"); 92. client.println("<a href=\"/led=off\"\"><button>turn Off </button></a><br />"); 93. client.println("</html>"); På dette tidspunktet hadde vi funnet en enhet vi følte oss komfortable med å bruke og som var mindre, billigere og enklere å koble sammen enn tidligere Coolity versjoner Utstyr og dimensjon Coolity 0.2 var kun en prototype for å teste at vi forsto NodeMCU og at vi fikk ting til å fungere slik vi ønsket. Det var en rask fiks og test og ble derfor satt sammen av plasseringsbrettet som Arduino UNO en allerede var skrudd fast i og som vi hadde et koblingsbrett teipet på. Det resulterte i følgende utstyr for Coolity 0.2: UTSTYR ANTALL NodeMCU 1 Arduino UNO 1 USB-Kabel 1 Koblingsbrett 1 Plasseringsbrett (Stand for utstyr) 1 Lampe 1 Total 6 Og samme dimensjoner som Coolity 0.1: Dimensjon cm 47

51 Bredde 11.5 Dybde 9.3 Høyde Vurdering Den 2. februar hadde vi møte med Coop der målet var å få en kravspesifikasjon fra dem. Det kom frem at Coop var mer interessert i applikasjonen i ServiceNow enn hva de var for selve utviklingen av enheten. De var fornøyde med størrelsen på NodeMCU og ønsket at vi bygget videre på hva vi hadde, og at vi ellers hadde frie tøyler til å utvikle som vi ville for å få det til å fungere. Ønsket deres var en funksjonell prototype som kunne testes i en av deres Coop-butikker for å måle nøyaktighet 19 og inkludere det i rapporten. Det eneste kravet Coop stilte til selve enheten var at den skulle fungere ved hjelp av batteri. Dette var nytt og en kritisk del av utviklingen vi ikke hadde tenkt på tidligere. Frem til da hadde vi enten brukt en form for USB-tilkobling til PC ene våre eller adapter i strømkontakt for å gi Coolity versjonene strøm. Ikke alle kjølerne ville ha egne strømkontakter vi kunne koble adapter til eller noen USB, det var derfor viktig for Coop at prototypen fungerte med batteri. Sammen med Coop kom vi frem til følgende kravspesifikasjon: KRAVSPESIFIKASJON COOP IOT-ENHET IoT-enheten skal være så liten som vi får til med en prototype. Må fungere med batteri. Temperaturmålere må tilpasses fryser og kjøleskap. APPLIKASJON Terskelverdier skal variere ut ifra hvilke kjølere de står i. Det skal være ulike nivå for brukere. Det skal være et grafisk brukergrensesnitt. Det må faktisk testes i en Coop-butikk og bekrefte at temperatur registreres i applikasjon. 19 Les mer under 7.0 Testdokumentasjon og 7.1 Testing av prototypene. 48

52 5.3.4 Coolity 1.0: Funksjonell Prototype Batteri var ikke noe vi hadde tenkt på tidligere og lagt inn i våre planer, heller ei noe ServiceNow hadde nevnt til oss eller fått vite noe om da de hadde vært i kontakt med Coop tidligere. Dette gjorde at vi måtte tenke på en ny måte og ta inn enda en faktor til vurdering, nemlig holdbarhet Utfordring Med Coolity 0.2 hadde vi klart å finne en enhet som reduserte utgifter, hadde integrert de komponentene vi trengte, hadde totalt mindre antall komponenter enn tidligere, og viktigst av alt, så var enheten mindre enn Arduino UNO løsningen vår. Disse fordelene var både Coop og ServiceNow fornøyde med. Men det var kun NodeMCU alene. Til Coolity 1.0 trengte vi å koble til temperaturmåler, batteri, sjekke at alt fungerte sammen. Dette krevde at vi leste oss opp på en god del før vi kunne begynne å utvikle Coolity Løsning Til å begynne med måtte vi finne ut av hva de forskjellige tilkoblingspunktene til NodeMCU en var. Figur 18 NodeMCU med illustrasjon av hva tilkoblingspunkter, eller bare koblingspunkter, er På denne måten ville vi kunne vite hvilke muligheter og begrensninger den hadde og vi trengte å finne ut av hvordan vi skulle kunne koble til en temperaturmåler og et batteri, samtidig som vi skulle få batteriet til å vare lengst mulig Varighet på batteriet kan det leses mer om under 8.3 Teknologi og WiFi - ESP

53 Figur 19 Tilkoblingspunktenes ulike navn Vi oppdaget at det ikke var noen utfordring å koble et batteri til NodeMCU. I Arduino UNO-startpakken vår hadde vi fått en battericap 21 som passet til et 9V batteri - alt vi trengte å gjøre var å koble capen til et 9V batteri og ledningene til koblingsbrettet med tilsvarende kobling til NodeMCU sine innganger: GND 22 og Vin 23. Da gjenstod det å koble til en temperaturmåler og sende målingene trådløst ved hjelp av den integrerte WiFi-chipen NodeMCU en. Vi tok i bruk to varianter av Dallas 18B20 temperaturmålere med tre pins (Maxim Integrated, udatert). Den ene var raskere til å registrere romtemperatur, mens den andre brukte lenger tid men var vanntett. Begge passet vårt bruk da vi skulle måle temperatur i både kjøleskap og frysere. Dette er noe vi kommer tilbake til under Prototypen lenger ned. Temperaturmåleren ble koblet til koblingsbrettet for å skape tilkobling til NodeMCU og å kunne registrere målinger. 21 Cap, eller hatt, brukes som begrep for noe som settes på/kobles på. 22 GND står for Ground (Joring). 23 Vin står for Voltage in. 50

54 Figur 20 To forskjellige modeller av Dallas DS18B20 For at temperaturmåleren skulle registrere riktig temperaturer måtte vi sørge for at den fikk riktig mengde spenning. Om den trakk for mye ville den bli varm og gi oss feil temperaturmålinger. Vi koblet derfor en resistor mellom NodeMCU og temperaturmåleren slik at vi ikke overbelastet temperaturmåleren. 51

55 Figur 21 Coolity 1.0 tilkoblingspunkter og enheter Resistoren er lagt flat mellom NodeMCU og koblingsbrettet som vist på illustrasjonen under. 52

56 Figur 22 NodeMCU med resistor og koblingsbrett Totalt trengte vi kun 13 tilkoblingspunkter for at Coolity skulle fungere med batteri og temperaturmåler. Det gjorde at vi kunne bruke et merkbart mindre koblingsbrett 24 enn hva vi hadde operert med tidligere og vi gikk til innkjøp av et koblingsbrett med 170 koblingspunkter Prototypen Coolity 1.0 har samme komponenter koblet sammen men med forskjellig varianter av temperaturmåleren Dallas 18B20. Vi tar i bruk to varianter der en har silikontupp og er ment til å plasseres i kjøleskap, og en som er vanntett med lengre kabel og metalltupp som er ment til å plasseres i frysere. 24 Illustrasjoner henviser til koblingsbrett som breadboard. 53

57 Figur 23 Utstyret som utgjør Coolity 1.0 Det var nødvendig med to typer temperaturmålere da vi hadde to typer kjøler som skulle måles. Vi hadde derfor tre ulike modeller av Coolity 1.0 slik at vi kunne måle temperaturen på forsvarlig vis i de ulike kjølene; Coolity 1.0A, 1.0B og 1.0C Coolity 1.0A Coop ønsket at vi kunne måle temperaturen i deres åpne kjøleskapløsninger og frysere. Åpne kjøleskapløsninger vil si de kjøleskapene som ikke har noen dører som kan lukkes og holde på temperaturen, men som er åpne til enhver tid og utsettes for varme luftstrømmer som endrer på temperaturen. Dette er typisk for ostedisker, ferskvaredisker og skap med pålegg, og det er dette Coolity 1.0A ble laget for. Til denne oppgaven trengte temperaturmåleren å være en variant som raskt tilpasset seg temperaturen i omgivelsene da kjøleskapene hadde varmere temperatur enn hva frysere hadde, og ved en stor temperaturendring ville matvarene måtte kastes. Coolity 1.0A består derfor av en silikontupp som hverken holder på varme eller kulde, og enkelt kan tilpasse seg omgivelsenes temperaturer og gi en nøyaktig sanntidsmåling. 54

58 Figur 24 Coolity 1.0A med silikontupp Figur 25 Coolity 1.0A Coolity 1.0B I motsetning til kjøleskap har frysere fryste varer, og dette gir oss noen andre prioriteringer og faktorer å tenke på. Isen i fryseren kan smelte og skade temperaturmåleren. I Coolity 1.0A er det utsatte 25 ledninger fra temperaturmåleren som kan skades. I Coolity 1.0B tok vi derfor i bruk en vanntett temperaturmåler 25 Ledninger som ikke er skjermet. 55

59 variant som skjermer sensoren ved hjelp av en metalltupp og gummi rundt ledningene. Fordelen med en metalltupp er at den holder på temperaturen en stund før den tilpasser seg temperaturen i omgivelsene. Dette passer til måten temperaturen på kjølevarer skal måles. Det er ikke temperaturen i fryseren i seg selv som er viktig, men temperaturen mellom varene for å illustrere en omtrentlig temperatur på varen i seg selv. Om en skulle åpne en fryser og slippe inn varm luft for så å lukke fryseren igjen, så vil ikke det påvirke temperaturen på kjølevarene men bare luften i fryseren. Kort tid etter at fryseren er lukket vil luften i fryseren være tilbake til temperaturen den hadde. I de tilfellene der fryseren forblir åpen eller fryseren opplever feil og ikke kjøler varene, så vil temperaturen på varene falle etterhvert. Metalltuppen fungerer omtrent som varen ved at den holder på temperaturen en stund, før den etterhvert begynner å kjenne en fast og kontinuerlig temperaturendring og endrer seg i tråd med den. På denne måten registrerer metalltuppen tiningsprosessen og varsler før det har nådd et punkt der maten må kastes. Figur 26 Coolity 1.0B metalltupp 56

60 Figur 27 Coolity 1.0B Coolity 1.0C Forskjellen mellom Coolity 1.0B og Coolity 1.0C er kun lengden på temperaturmåleren. Vi tenkte det ville være lurt med to forskjellige lengder da det ville gi oss flere muligheter til å plassere enheten på forskjellige steder, eventuelt på forskjellig måter. Merk at det kun er temperaturmåleren i Coolity 1.0B og C som er vanntette, men selve enheten og batteriet har vi ikke laget noen vanntett løsning til. Tanken er å ha et deksel til alle modellene, som beskytter mot væske og kondens. 57

61 Figur 28 Coolity 1.0C med lang metalltupp Figur 29 Coolity 1.0C Utstyr og dimensjon Med Coolity 1.0 hadde vi klart å redusere mengden utstyr koblet til og størrelsen på enheten fra tidligere Coolity 0.1 versjoner! 58

62 Utstyr Ettersom NodeMCU har integrert WiFi-chip og ikke noe behov for ekstra strømkilde som de tidligere versjonene hadde så ble også mengden utstyr sterkt redusert. UTSTYR ANTALL NodeMCU 1 Batteri 1 Battericap Temperaturmåler 1 (2 ledninger) 1 (3 ledninger) Ledninger 3 Resistor 1 Total 8 Den første Arduino versjonen som fungerte trådløst og sendte signaler, Coolity 0.1.1, hadde 22 utstyr koblet sammen for å fungere. Vår første funksjonelle versjon med NodeMCU, Coolity 1.0, hadde bare 8 utstyr koblet til. Figur 30 Coolity 1.0 kompakt løsning Utstyr sammenliknet PROTOTYPE TOTALT ANTALL UTSTYR 59

63 Coolity 0.1: Arduino UNO Temp 19 Coolity 0.1.1: Arduino UNO Trådløs 22 Coolity 0.2: NodeMCU Lampe 6 Coolity 1.0: Funksjonell Prototype 8 Det er viktig å merke seg at hverken Coolity 0.1 eller Coolity 0.2 var funksjonelle prototyper, den mest interessante sammenligningen er derfor mellom Coolity og Coolity Dimensjoner I tillegg til en reduksjon i utstyr, hadde vi også klart å redusere størrelsen på Coolity 1.0 sammenlignet med tidligere 0.1 versjoner, og det inkludert med et 9V batteri. Vi har valgt å ikke inkludere selve temperaturmåleren i dimensjonene da vi har tenkt at de kan variere ut ifra behov hos kunde. Kunde kan ønske seg ulike modeller og lengder på temperaturmåleren, det kan resultere i Coolity 1.0A, B, C eller X en gang i fremtiden. I tillegg kan kunde bøye og plassere temperaturmåleren etter ønske og behov selv, noe som gjør det unøyaktig og unødvendig og inkludere temperaturmåleren i dimensjonene. DIMENSJON cm Bredde 5.8 Dybde 5.1 (Uten temperaturmåler) Høyde

64 Figur 31 Coolity 1.0 dimensjoner Dimensjoner sammenliknet PROTOTYPE BREDDE (cm) DYBDE (cm) HØYDE (cm) Coolity 0.1: Arduino UNO Temp Coolity 0.1.1: Aruino UNO Trådløs Coolity 1.0: Funksjonell Prototype Vurdering Før vi fikk en funksjonell prototype versjon av Coolity 1.0, hadde vi et tilfelle der den første prototypen for versjon 1.0 ble defekt. Da vi koblet den til et batteri hørte vi et lite smell og en komponent (Tantalum Capacitator) på NodeMCU ble så varm at den ble rød og startet å ryke. NodeMCU vi brukte var den første vi hadde fått fra JavaZone. Samme dagen hadde vi kjøpt tre nye NodeMCU, som senere ble til Coolity 1.0. Men før det skjedde ønsket vi å finne ut av hva som hadde skjedd. Problemet var at vi ikke visste årsaken til feilen. Vi hadde noen teorier om at det kunne være fordi vi hadde tatt for mye på chipen, at chipen trakk for mye spenning, at batteriet var defekt eller at NodeMCU 61

65 var defekt. For å få hjelp til dette kontaktet vi derfor en elektroingeniør ved navn Aryan Naqid som skrev bachelor samtidig som oss, og spurte om han kunne ta en titt på løsningen vår og om alt var riktig. Det tok en uke før Aryan hadde tid til å møtes, men han hadde på forhånd lest brukermanualen til NodeMCU og gjort seg kjent med løsningen vår. Under møte med han avdekket han at det ikke var noen problemer med batteriet, at det er svært usannsynlig at årsaken til feil er fordi vi har tatt på enhet eller at den trakk for mye strøm da den har en regulator. Da gjenstod det kun et alternativ om at selve NodeMCU var defekt. Frem til da hadde vi ikke turt å koble til et batteri til noen av de nye NodeMCU vi hadde kjøpt. Mens Aryan var tilstede for å observere om samme feil skulle oppstå igjen, koblet vi til et batteri og enheten fungerte feilfritt. Figur 32 Første tilkobling til batteri hvor vi oppdaget at WiFi-chip utgir varme nok til å påvirke temperatur Bilde over viser første tilkobling uten cap da vi ikke hadde den tilgjengelig da den skulle kobles opp første gang. Den startet å registrere temperaturer slik vi ønsket og 62

66 lagret dette i en tabell vi hadde satt opp i ServiceNow for å teste. Vi oppdaget da at selve WiFi-chipen utgir varme, nok til å påvirke temperaturmålingene til sensoren som på det tidspunktet var plassert rett under chipen. Vi bøyde derfor temperaturmåleren ut og problemet var løst. Dette illustrerte sensitiviteten til temperaturmåleren og er noe vi måtte tenke på til senere; Temperaturmåler bør ikke være nær selve enheten. Et deksel ville ha løst dette problemet sannsynligvis, i det minste kunne det ha skjermet temperaturmåleren. Vi hadde klart å øke varigheten på batteriet fra tre timer til fire dager, men dette var fortsatt ikke noe vi som gruppe var fornøyd med, og heller ikke noe vi vil tro ServiceNow eller Coop er. Før enheten kunne tas i bruk måtte varigheten forbedres betraktelig. Måten vi gikk fra tre timer til fire dager, og hvordan det eventuelt kan forbedres ytterligere diskuteres under 6.3 Teknisk dokmentasjon: Coolity, Fremtidig arbeid og Teknologi. Nå gjenstod det kun å teste at Coolity 1.0 faktisk fungerte og registrerte målinger til ServiceNow. Vi avtalte med Coop Mega Skøyen om å få teste enhet og applikasjonen hos dem, noe de stilte seg svært positive til. Om enheten fungerte ville det bety at selve løsningen med enhet og applikasjon i prinsippet kunne tas i bruk Koding av Coolity 1.0 Vi har nå skrevet en del om selve utviklingen av IoT-enheten Coolity, men ikke noe om hvordan vi kom frem til valgene vi måtte ta for komponentene. I denne delen introduserer vi ulike løsninger og ting vi gjorde, før vi kom frem til den endelige løsningen for Coolity 1.0. Det går på hvordan vi startet å måle temperatur, koble til WiFi, forstå sending av data og hvordan å spare strøm. Under Produktdokumentasjon og Teknisk dokumentasjon: Coolity vil vi gå litt nærmere inn på løsningene vi fant for hvert av punktene Temperaturmåling For å måle temperaturen har vi benyttet oss av en Dallas DS18B20 temperaturmåler. For å programmere temperaturmåleren brukte vi en utregning for måling av temperatur, men denne viste seg å være noe unøyaktig. Code / Arduino LoveOMeter 38. // read the value on AnalogIn pin // and store it in a variable 40. int sensorval = analogread(sensorpin); // send the 10-bit sensor value out the serial port 43. Serial.print("sensor Value: "); 44. Serial.print(sensorVal); 63

67 // convert the ADC reading to voltage 47. float voltage = (sensorval / ) * 5.0; // Send the voltage level out the Serial port 50. Serial.print(", Volts: "); 51. Serial.print(voltage); // convert the voltage to temperature in degrees C 54. // the sensor changes 10 mv per degree 55. // the datasheet says there's a 500 mv offset 56. // ((volatge - 500mV) times 100) 57. Serial.print(", degrees C: "); 58. float temperature = (voltage -.5) * 100; 59. Serial.println(temperature); For å gjøre det mer nøyaktig fant vi ut at C++ har egne bibliotek som håndterer temperatur nøyaktig og vi inkluderte disse for en bedre og mer nøyaktig måling WiFi-tilkobling For at vi skulle få ESP8266 og WiFi til å fungere tidlig i prosessen, tok vi i bruk et verktøy som kalles AT Command Set (Pridopia, udatert). AT Command Set åpner et kommando-vindu i Arduino IDE hvor vi gir kommandoer direkte til ESP8266, som fore eksempel brukernavn og passord til et WiFi-nettverk. Men så snart kommandovinduet er lukket eller Coolity-enheten slås av / restartes, så vil all informasjonen være borte. Det vil si at AT Command Set ikke lagrer noen informasjon, men er kun ment til å teste funksjonalitet. Code / AT command 1. //Test if AT system works correctly 2. AT 3. //Commands ESP8266 to connect a SSID with supplied password. 4. AT+CWJAP="my-test-wifi","1234test" For at kode med WiFi SSID og passord skulle lagres på ESP8266 WiFi-chipen, tok vi i bruk biblioteker som håndterer dette REST API: Sende temperaturmålinger til ServiceNow For å sende temperaturmålingene til ServiceNow, måtte vi først lære oss å bruke REST API. Vi tok i bruk Google Chrome utvidelsen Postman (Postdot, udatert) for å eksperimentere med REST GET, POST, PUT, PATCH og DELETE. På denne måten fikk vi et grunnlag og ble kjent med hva som skal inn i C++ koden som sendes til ServiceNow. 64

68 Hvilemodus: Deep Sleep NodeMCU-utviklingskortet har flere koblingspunkter og komponenter på seg enn bare ESP8266 WiFi-chipen. Når NodeMCU er koblet til strøm vil alle komponentene trekke spenning og strømmen brukes raskere opp. Dette er hva vi opplevde første gangen vi koblet opp Coolity 1.0 til batteri og lot den gå. Det var hovedsakelig to ting som skjedde: Komponentene begynte å trekke spenning. Målingene skjedde kontinuerlig uten stopp. Kombinasjonen av dette gjorde at et 9V s batteri gikk tom for strøm på tre timer og vi var nødt til å se etter alternativer for å bruke mindre strøm. Vi fant frem til Deep Sleep som er en måte å programmere NodeMCU til å sove i et gitt tidsintervall etter at den har utført en handling, for så å repetere prosessen. 5.4 Sikkerhet Sikkerhet generelt handler om at viktige verdier skal beskyttes mot uønskede hendelser. Når verdien vi beskytter er informasjon og data, omtales dette som informasjonssikkerhet og datasikkerhet. Fremover omtaler vi data som fellesbetegnelse for informasjon og data. For at data skal være sikret må følgende deler i løsningen være godt beskyttet: Maskinvare : Viktig å beskytte maskinvare og IoT enhet. Det er vanskelig å beskytte IoT enhetene når de er ute i drift. Programvare : ServiceNow er allerede sikret. Programmet som skal lastes opp på IoT enheten bør oppdateres dersom feil blir oppdaget. Data: Temperaturer som ligger i ServiceNow databasen trenger ikke å være kryptert. Andre data, som lister over event, incidents trenger heller ikke å være kryptert. Nettverkskommunikasjon. Det er viktig at nettverkskommunikasjon er kryptert. Kommunikasjon mellom IoT enhetene og ServiceNow går gjennom SSL hvor dataene er kryptert før det sendes Maskinvare (Coolity) Vi programmerer Arduino utviklingskort med Arduino IDE i C eller C++. Når vi laster programmet opp til utviklingskort blir programmet kompilert med Avr-gcc kompilator. Kompilatoren Avr-gcc kompilerer C eller C++ til maskinkode og binder sammen data 65

69 med Arduino biblioteker til én intel HEX fil. En intel HEX fil er et filformat som formidler binær informasjon i ASCII 26 format. Figur 33 Illustrasjon av hvordan C++ kode blir til maskinkode før det leses av NodeMCU NodeMCU lagringsplasser Flash memory: er lagringsplass for programmet (Sketch). SRAM (Static random access memory) : er hvor variabler lagres når programmet kjører. EEPROM: minne som kan brukes til å lagre langsiktig informasjon. Det er mulig å hente programmet fra Flash memory og data EEPROM dersom man klare å aksessere Bootloader. En Bootloader er en mikrokontroller som muliggjør å installere programmet uten behov for andre eksterne mikrokontroller. 26 ASCII står for American Standard Code for Information Interchange og er et tegnset. Det er en standard for utveksling av tekst mellom datamaskiner (AsciTable, udatert). 66

70 Figur 34 Illustrasjon av hvordan maskinkoden i form av HEX går igjennom Bootloader og plasseres på de ulike plassene på NodeMCU: Flash SRAM og EEPROM Uansett om man har klart å hente HEX-filen (programmet) er det fortsatt umulig å forstå hva som står i den. Et alternativ til å gjøre om HEX-filen som ble kompilert tilbake til originale kildekode er, er ved bruk av Reverse engineering. Reverse engineering krever at man forstår hvordan en kompilator fungerer, hva den gjør og hvordan den er bygd opp for å kunne reverse engineere HEX filen. Figur 35 Ved hjelp av reverse engineering kan HEX filer gjøres om til C/C++ kode igjen Coolity program, passord og tokenlagring Det er vanlig at programmet legges ut i github når det er flere som skal jobbe sammen. For at hardware skal kunne koble seg til WiFi og ServiceNow kreves det at vi skrive WiFi- SSID, passord og ServiceNow token. Det er ikke lurt å publisere programmet på en offentlig og åpen github om det inneholder brukernavn og passord. Som studenter har vi mulighet til å bruke private repository (lagring) og har benyttet oss av det. 67

71 Selv om WiFi SSID, passord og token er lagret i en privat repository på github, er et alltid en sjangse for at github-kontoen våres kan bli hacket, noe som kan resultere i komplikasjoner i ServiceNow-applikasjonen som at data vi ikke ønsker lagres i tabellene våre. Det lureste er derfor å lagre WiFi SSID, passord og token i en separat fil. Når vi legge ut programmet på github legge vi kun ut den funksjonelle delen og setter git-ignore på filen som inneholder WiFi SSID, passord og ServiceNow token slik at denne ikke tas med. Alternativet er å kryptere filen. Kryptering kan enten være symmetrisk eller asymmetrisk kryptering Misbruk av Coolity I tilfellet der en uvedkommende (hacker) stjeler prototypen og får tilgang til WiFI SSID og passord, er det svært lett å misbruke prototypen. Misbruk av prototypen fører til at systemet får falske alarmer. Måten uvedkommende kan aktivere prototypen og bruke den til å sende data på er å sette opp WiFi SSID og passord identisk med WiFi SSID og passord slik det var satt opp i Coop butikken hvor prototypen ble stjålet fra. Prototypen vil da koble seg til internett og begynne å sende data. Andre alternativ er å kopiere HEX-filen og laste den opp til flere chipper, sette opp WiFi SSID og passord identisk med Coop butikkens konfigurering, og la chippen sende en stor mengde falske alarmer Programvare Coolify-applikasjon ServiceNow ServiceNow er allerede et sikkert system. Dashboardene i applikasjonen endres ut ifra hvilken rolle brukeren har i ServiceNow sitt system. Slik opprettholder vi en Practice of Least Privilege (POLP), så brukere til enhver tid kun har tilgang til akkurat de dataene de trenger, og ikke mer. Dette er oppdelt som følger: Rolle Coop Styre Coop Butikksjef Rettighet Har tilgang til all temperaturdata og alle varsler i alle butikker over hele Norge. Har samtlige butikksjefers kontaktinformasjon dersom det oppstår et problem. Har også rettigheter til å opprette Incidents, Problems og Change Requests ved behov. Har tilgang til temperaturdata og varsler for alle frysere i butikken. Har kontaktinformasjon til alle som jobber i butikken, og dessuten har hen rettigheter til å opprette Incidents og Problems dersom det skulle være behov for dette. 68

72 5.4.3 Nettverkskommunikasjon REST API Vi bruker REST API for å få tilgang til dataene i ServiceNow. REST (REpresentational State Transfer) er en handling mellom klient og server gjennom en webtjeneste. REST er en enkelt stateless architecture som vanligvis går/ kjører over HTTPS / TLS. Med REST gjennom webtjeneste har vi muligheten til å få tilgang til og manipulere web ressurser. Hver REST operasjon har unike URI (Uniform Resource Identifier) for å unngå uklarhet (ServiceNow, 2016c) HTTPS HTTPS eller Hypertext Transfer protocal Secure er en sikrere utgave av HTTP, som er kommunikasjonsprotokollen til www (World Wide web). En HTTPS-sesjon blir kryptert enten ved bruk av SSL-protokollen (Secure Socket Layer) eller TLSprotokollen (Transport Layer Security). SSL er kryptografiske (Encryption) protokoller som tilbyr sikker kommunikasjon på internett. Det er små forskjeller mellom SSL og TLS og de gjør hovedsakelig den samme jobben (Instans SSL, udatert) Autentiseringsmetoder Autentisering er måten å verifisere seg mot systemet. For å kunne gjøre et REST kall mot ServiceNow kreves det at brukeren er autentisert. Autentiseringen ligger i HEAD på et HTTP kall. Det finnes forskjellige autentiseringsmetoder som basic, digest og Oauth. Autentiseringsmetoder. Basic: Autentiseringsmetode som sender inn brukernavn og passord i ren tekst mot server. Men dersom basic autentiseringsmetoder brukes gjennom HTTPS (TLS) blir brukernavn og passord kryptert med base64. Hvert bokstav i brukernavn og passord erstattet med en annen bokstav i base64 indextabellen. Brukernavn og passord med base64 er fortsatt ikke sikret nok. Det er enkelt å knekke base64 (Zaikin, 2005). Digest: Autentiseringsmetoden hasher først brukernavn og passord før det sendes, i motsetning til Basic som sender brukernavn og passord som rent tekst (Zaikin, 2005). Oauth 2.0: Token basert autentiseringsmetode. Ved bruk av Oauth 2.0 trenger bruker å oppgi passord og brukernavn én gang og deretter brukes samme token ved senere REST kall i steden for å oppgi brukernavn og passord til hvert enkelt kall. Ved bruk av OAuth 2.0 kreves det et mindre antall system-autentiseringer (ServiceNow, udatert-x). 69

73 5.5 Utviklingsprosess av applikasjonen Coolify Utviklingen av ServiceNow applikasjonen, Coolify, har både vært spennende og utfordrende, samtidig som den tidvis har vært noe frustrerende. Ettersom vi er den første gruppen som har fått den unike muligheten til å skrive en bacheloroppgave for ServiceNow, har vi også, på godt og vondt, vært forsøkskaniner. Dette førte til at spesielt oppstarten var preget av mye prøving og feiling. Vi har i ettertid funnet ut alle som starter sin karriere hos ServiceNow får en seks måneders periode hvor de utelukkende skal tilegne seg plattformen og dens muligheter, hvor de deretter ofte blir sendt på kurs for å kvalitetssikre kunnskapen før de settes inn i utviklingsprosjekter. Vi måtte forholde oss til tidsrammene på prosjektet og var ikke kvalifiserte til å sendes på kurs, så vår egenskap til å raskt tilegne oss nye teknologier og systemer ble uvurderlig for hele gruppen. Videre påvirket også dette hele utviklingsfasen. Vi har hatt en uortodoks struktur på utviklingsfasen, ettersom vi kontinuerlig måtte tilegne oss nye ferdigheter inne i plattformen og forholde oss til kravene satt av kunden om implementering av plugins. Videre måtte vi ved flere anledninger revurdere fremgangsmåten på grunn av begrensninger i plattformen eller ved misforståelser mellom arbeidsgiver og kunde. Mer om dette under Utfordringer i utviklingen. Figur 36 Fremgangsmåte og tankesett for utvikling av Coolify-applikasjonen Oppstart Kompetansetilegning: ServiceNow Developer Kurs For å lære plattformen å kjenne ble vi satt til å fullføre de forskjellige kursene på utvikler-siden til ServiceNow for å lære det mest grunnleggende ved utvikling på plattformen. Vi fant frem til en rekke kurs som virket nyttige for prosjektet og som ga oss en innføring i både grunnleggende og spesialiserte områder på plattformen: 70

74 Developer Site Walkthrough Enkel og kjapp gjennomgang av hvordan utvikler-siden til ServiceNow er bygd opp, hvor man finner ting og hvem man skal rådføre seg med hvis man står fast. Kurset ga en veldig enkel gjennomgang av siden som ga en god oversikt over nyttige ting Scripting in ServiceNow Innføring i hvilke typer skript det finnes i ServiceNow, og hvordan man kan bruke hver enkelt, for å endre på funksjonaliteten i plattformen. Det skilles mellom klientside og server-side. Førstnevnte omfavner skript som brukes for å endre utseende til applikasjonen for brukers øyne, mens server-side brukes til å manipulere data i bakgrunnen. Gjennom dette kurset lærte vi hvordan skriptredigeringsverktøyet til ServiceNow fungerer i forhold til bl.a. kontroll av syntaks i sanntid og fargekode for forskjellig type kode Developer platform introduction Gjennomgang av hvordan plattformen fungerer for en utvikler som ønsker å opprette egne applikasjoner, bygge opp en logikk bedriften kan dra nytte av eller som ønsker å endre utseendet på en tabell. I dette kurset lagde vi applikasjonen Marketing Events Coding on ServiceNow Mer grundig gjennomgang av hvordan man koder på plattformen. I dette kurset bygger vi videre på applikasjonen Marketing Events; vi legger til mer avansert funksjonalitet og bygger på både klient-side og server-side. Etter dette kurset var vi litt tryggere på å utvide funksjonaliteten til applikasjonen vi skulle lage ved hjelp av kode Integrating with ServiceNow Gjennomgang av hvordan vi bruker ServiceNow sitt REST API til å integrere eksterne løsninger med plattformen. Dette ble veldig interessant for vår oppgave, da det var nettopp modulen Inbound web services (ServiceNow, udatert-p) som gikk gjennom hvordan man bruker REST APIet til å laste opp data Building the Marketing Event application Etter å ha gått igjennom de forskjellige kursene i Servicenow ble vi mer komfortabel med å lage en enkel applikasjon og tok til slutt kurset Building the Marketing Event application for å praksisere det vi tidligere hadde lært. Kurset går gjennom å lage en applikasjon for håndtering av markedsføringsarrangementer. Denne applikasjonen er et eksempel på hvordan man kan effektivisere arrangementskoordinatorer til å håndtere arrangementer og kunne holde styr over flere arrangementer samt kostnader vedrørende utstyr mm. 71

75 Marketing Event applikasjonen består av ulike moduler som til sammen utgjør applikasjonen. Disse modulene og sammensetting av de, lærte oss blant annet hvordan å bygge opp databasetabeller, hvordan lage brukergrensesnitt, registrere arrangementer, importere data fra eksterne kilder, utvide data fra andre tabeller for å arve funksjonalitet og hvordan tilegne brukere av applikasjonen Least Privilege. Det fine med disse kursene er at alle som har litt grunnleggende JavaScript erfaring kan sette seg ned og lære plattformen. Utvikler-instancen man får er kun ment for å leke med nye ideer, men man kan også sende de til produksjon og lansere de på ServiceNow sin ServiceNow Store, så fremt man har registrert seg som en teknisk partner Oppsett av utviklingsmiljø Etter å ha brukt omtrent en måned i hver vår Personal Development Instance (ServiceNow, udatert-i) hvor vi gjennomførte alle kursene, ble vi tildelt vår første reelle instance, coopstudentdemo.service-now.com. Grunnen til at vi ikke ble tildelt en ordentlig instance før var et sikkerhetsnett for oss som nye utviklere, da Personal Development Instancer kan slettes og genereres på nytt svært enkelt, i motsetning til ordinære ServiceNow instancer. Allikevel ser de helt like ut, så overgangen mellom dem var mindre krevende enn vi hadde trodd. Når instancen var satt opp, var det eneste vi trengte en fast strøm data fra Coolity-enhetene, slik at tabellene ble fylt og vi kunne bruke test dataen videre Utviklingsfase Fremdriftsplan i forhold til kravspesifikasjonen Den 20. januar var innleveringsfristen for et forprosjekt der hensikten var å legge en plan for utviklingen av prosjektet. Frem til da hadde vi kun fått kravspesifikasjon fra ServiceNow og ventet fortsatt på et møte med Coop 2. februar. Vi tok derfor utgangspunkt i den eksisterende kravspesifikasjonen fra ServiceNow og opprettet et Gantt-diagram vi satte arbeidsoppgavene i. 72

76 Figur 37 Første GANTT-diagram for januar. Se 12.4 Vedlegg 4 GANTT diagram for februar og mars Fordelen med et Gantt-diagram er at det visualiserer arbeidsmengden for de ulike periodene ved å estimere tidsbruken per oppgave. Er det noen oppgaver som strekker seg over lengre tid og mange mindre oppgaver som begynner senere, vil det plutselig ende opp med å kunne bli for mye arbeid i en periode og gruppen vil falle etter. To ting ble derfor viktig for oss ved opprettelse av Gantt-diagrammet Vi måtte være åpne for endring da vi ikke hadde alle kravspesifikasjoner enda. Gantt-diagrammet skulle fungere som en forgjenger til utviklingsmetoden vår med de overordnede oppgavene. Vi oppdaterte Gantt-diagrammet over tre iterasjoner for å tilpasse tidene satt til diverse oppgaver og for å inkludere kravspesifikasjonen vi fikk fra Coop. Etterhvert som vi fikk bedre oversikt over omfanget av de store oppgavene og kunne bryte de ned i mindre oppgaver, gikk vi vekk ifra Gantt-diagrammet og forholdt oss kun til Kanbanboardet vi hadde satt opp i Trello 27. Fra midten av mars gikk vi helt vekk fra Gantt-diagrammet og forholdt oss kun til Kanbanboardet som visualiserte arbeidet enda mer, gjorde det håndterbart og skapte en kontinuerlig arbeidsflyt. Det var den beste løsningen for oss ettersom at estimering av store oppgaver var vanskelig, og at det å legge til flere små oppgaver tok lenger tid i et Gantt-diagram, noe som gjorde det upraktisk og igjen førte til at vi ikke brukte det. Det var også logisk at estimeringene av arbeidsoppgavene fra januar ikke traff helt med arbeidet vi drev med i mars og utover. Dette kommer vi tilbake til under Utfordringer i utviklingen Backend Til å begynne med hadde vi få kunnskaper om hvordan applikasjonen ville fungere i samspill med Event Management, så vi prøvde å sette opp logiske datamodeller på 27 Les mer under Verktøy tatt i bruk og Trello 73

77 standard vis med penn og papir. Her prøvde vi i å få med alle sider av applikasjonen, fra Eventer til varsler osv Databasen Fra emnet DATS1500 Databaser som vi gikk gjennom i løpet av studiet, var vi allerede kjent med oppbygging av databaser, SQL-kode og UML-diagram. Dette ble tatt godt i bruk gjennom prosjektet når vi først lagde skissene for hvordan vi kunne tenke oss at applikasjonen skulle se ut. Vi fant tidlig ut at vi ikke hadde behov for å hardkode SQL siden plattformen gjør dette i bakgrunnen mens vi lager, leser, endrer, og sletter enkelt i grensesnittet. Dette gjorde det enklere for oss å gjøre mindre til store endringer når vi fant tabeller som manglet/var feil. For å lagre all temperaturdata, trengte vi et sted å kunne sende de til og lagre de for å ta vare på, og kunne bearbeide statistikk. Dette resulterte i tabellen Measurement som har en relasjon med tabellen Device. Device-tabellen inneholder informasjon om selve Coolityen og peker videre til hvilken Cooler den er plassert i. Vi brukte denne strukturen som utgangspunkt og satte i gang utviklingen. Figur 38 Databasestruktur I utgangspunktet tenkte vi at vi skulle lagre all data i egne tabeller og generere egne Eventer som skulle bli til Incident og Problems. Et stykke inn i utviklingen innså vi at dette kunne bli litt for stort, spesielt når den vanlige praksisen ute i bedrifter er å ha egne overvåkningsverktøy som sender egendefinerte eventer til ServiceNow. Dette i 74

78 motsetning til vår løsning med en chip som laster opp data med to parametre - ChipID og temperatur. Etter et møte med veileder der vi tok frem denne problemstillingen, anbefalte han oss å se på Event Management som kunne hjelpe oss med å oppnå dette. Han nevnte at det var mulig å sende data direkte fra Coolityen vår inn til Event Management, i stedet for vår løsning med egendefinerte tabeller. Problemet med å skifte helt til dette fra vår egen applikasjon ville være at vi mistet muligheten til å lagre all temperaturdata på en oversiktlig måte og ta vare på historikk, samt at vi måtte ha gjort drastiske endringer i koden på Coolityene våre Event Management Coop ønsket, som nevnt, at vi skulle generere events, incidents og problems basert på temperaturvariasjonene. Dette viste seg å være en løsning som ble både tungvint og vanskelig å utvikle på den korte tiden vi hadde. Å gjøre det på denne måten hadde ikke vært et problem, hvis vi hadde et eksternt eventsystem som snakket med ServiceNow, men vi brukte Coolity som kun sender temperaturdata. Løsningen på dette kom frem under et møte med veileder fra ServiceNow, der han nevnte at Event Management var en applikasjon på plattformen som utviklet for akkurat dette. I Norge er ikke dette verktøyet særlig utbredt enda, fordi de fleste bedrifter allerede sitter på egne programmer som håndterer events og er koblet opp mot ServiceNow. Oppdragsgiver ønsket at vi skulle benytte oss av Event Management for å vise nytten av plugin. Det var også svært interessant og lærerikt å være blant de første i Norge som satte fingrene skikkelig i Event Management. Problemet lå i at det var svært få gratis ressurser tilgjengelig for å lære seg Event Management, utover å lese generelle Wiki sider eller usedvanlig spesifikke spørsmål på ServiceNow Community. Dessuten var det svært få konsulenter hos Symfoni (vår arbeidsplass under prosjektet) som hadde drevet med akkurat Event Management før, så vi sto på bar bakke. Dermed ble det veldig mye learning by doing Opprette Events: Business Rules Vi fant fort ut av at vi måtte bruke Business regler i ServiceNow for å genere Events knyttet til vår Measurement database. Dermed måtte vi friske opp JavaScript kunnskapene og sette oss inn i kliten-side koding i ServiceNow. Også her skulle det vise seg å være få ressurser tilgjengelig for å få en god oversikt over god kodepraksis, tutorials hvor man dannet seg et grunnlag osv. Blant annet kursene som innebar scripting gav oss ferdigdefinerte script som vi skulle sette inn i Script feltene i en form, istedenfor at vi skulle lage scriptene selv. Første gangen vi genererte eventer i ServiceNow, hadde vi ikke forstått forskjellen på tabellene Event [sysevent] og Event [em_event]. Selv om dette kan virke elementært, minner vi om at det meste vi gjorde var prøving og feiling. Dermed lagde 75

79 vi den første eventen i Event [sysevent], noe som var feil tabell, og dette innså vi når vi skulle eskalere Eventen til en Alert og rett og slett ikke fant Alert tabellene som skulle ligge inne i instancen. Det var først nå vi lærte at Event Management var en plug-in og ikke noe som allerede eksisterte i alle instancer. Vi sendte en epost til veilederen vår og fikk raskt installert plug-innen. Problemet lå i at scriptingen vi hadde gjort så langt var av ingen nytte og vi måtte begynne fra starten av, da scripting og generering av records gjøres helt forskjellig i Event [sysevent] og Event [em_event]. Frustrasjonen var stor i gruppen og vi forhørte oss med veileder fra ServiceNow om vi kunne få noe hjelp til å få satt opp det mest grunnleggende. Vi ble da satt i kontakt med en Senior Technical Consultant hos Symfoni som hadde vært borte i dette før. Han hjalp oss å sette opp et utkast til en Business regel som genererte Events, samt viktigheten rundt å ha en CMDB og CIer i applikasjonen for å koble Coolityene til Eventer, Alerts og Incidents Implementering av Configuration Items (CI) I Business reglene våre har vi med feltene Node og CI Type som brukes av Event Management til å binde opp en event mot en Coolity i vår database. En Coolity i vår tabell er en extension av en Configuration Item (cmdb_ci), som vil si at den arver alle felter som ligger i en standard CI. I vår applikasjon ønsket vi å registrere nyeste temperatur i sanntid, samt laste opp ChipID fra enheten for å binde målinger mot enheter. Dette var funksjonaliteter som ikke kom out-of-the-box i CI, så vi måtte derfor lage vår egen tabell Device CI som erstattet den eksisterende Device-tabellen. Dette kunne vi også gjort med Cooler tabellen, men vårt fokus lå hovedsakelig på selve enheten, så det ble nedprioritert siden vi ikke ville gjøre alt for store endringer på databasen. Når CIene var på plass var det betydelig mye lettere å spore hvor Eventene og Alertene kom fra, samt om ting fungerte som de skulle. Videre måtte vi sette opp de resterende delene, Event Rules som genereres Alerts, og Alert Rules som genererer Incidents Opprette Event Regler Innledningsvis var tanken som følger: Event Rule 1: Threshold regel som teller to eventer, og når disse er registrert varsles ansatte i butikken og butikksjef med en Alert. Event Rule 2: Threshold regel som teller fire eventer samtidig som den forrige. Dersom det blir fire sendes incidents, butikkansatte og butikksjef varsles på nytt, men denne gangen varsles også Coop administratorene og Incidents genereres. Med dette oppsettet kan de ansatte varsles før de høyere opp i systemet, slik at de får omtrent 30 minutter på å løse problemet før det eskaleres. Implementering tok 76

80 relativt kort tid, men vi merket raskt at Event Rulene ikke gjorde det vi forventet. Event Rulene knyttet opp til Coolityen 19438E snakket i munnen på hverandre, og det var bare den med minst Order (felt som setter prioritering i ServiceNow) som kjørte. Vi kom raskt i gang med å spørre om hjelp, men det skulle vise seg at kompetansen tok sin tid å finne. Vi prater mer om hele prosessen om å finne kompetansen i Utfordringer i utviklingen, men til slutt måtte vi komme opp med en alternativ løsning. Av de mange mulighetene vurderte vi følgende muligheter: Ha et skjult teller-felt i tabellen som teller og resettes av scripts, og når denne telleren var to eller fire skulle alerter sendes. Å bare ha en Event Rule, på bekostning av varsling. Modifisere Business reglene slik at de spesifiserer Severity på Eventen, og ha en Event Rule til hver Severity. Til sist valgte vi å gå for å sette Event severity ut ifra de verdiene Coop bruker i dag på å regulere om mat skal kastes eller ikke. Se trafikklyssystemet under 7.1 Testing av prototypene og Resultater. Altså lagde vi Event reglene som følger: 1. Business reglene (Verify Fridge/Freezer Temperature) fikk funksjonaliteten at de sjekker temperatur, og setter Event Serverity basert på temperatur (Minor/Major/Critical). 2. Så lagde vi Event regler til hver Severity: 1. Minor events: Tell til fire, deretter generer Alert. 2. Major events: Tell til to, deretter generer Alert. 3. Critical events: Genererer Alert med en gang. 3. Deretter vil alle Alertene bli fanget opp av en Alert Rule og lage en Incident. Dermed vil disse Event reglene generere Alerts dersom alle kravene er oppfylt, og Alertene vil da arve samme Severity som Eventene som trigget Event Regelen hadde Utfordringer med Event Regler Den største utfordringen ved denne løsningen var at vi potensielt kunne miste data dersom temperaturen konstant faller og stiger mellom grensene som følger: 77

81 Figur 39 Eksempel på mulig temperaturutvikling I et slikt tilfelle ville reglene vi har satt opp potensielt tape mye data før vi faktisk får et treff på enten to eller fire eventer. Dermed måtte vi legge til ekstra funksjonalitet, for å fange opp eventuelle slingringsmonn. Denne slingringen var hovedsakelig et problem mellom Minor og Major, ettersom slingring mellom Major og Critical vil konstant generere varsler, og slingring mellom godkjente temperaturer og Minor vil regnes som så trivielle at maten ikke står i fare for å bli ødelagt. Sistnevnte ble bekreftet med kunde. Etter å ha sett nærmere på de ulike utfallene, kom vi frem til følgende tillegg i reglene: Hvis fire Minor Events genereres i tidsrommet hvor seks mulige Events kommer inn, lages en Alert. Hvis to Major Events genereres i tidsrommet hvor tre mulige Events kommer inn, lages en Alert. Dette dekker alle variasjoner av stigninger og fall innenfor en tidsperiode på maks en og en halv time, slik at Coop varsles før maten må kastes Alert Regler Når Alerter sendes fra Event Reglene, er det Alert reglene sin jobb å fange opp hvilke av disse som skal opprette Incidents. I vår første implementering av Event Regler som beskrevet i Opprette Event Regler, med to forskjellige Event regler, genererte vi bare en Alert regel for å generere incidents fra Event reglene som teller fire Eventer. Hensikten var at Alerten som kom etter to Eventer skulle være varsling for systemet, mens den som kom etter fire skulle være en trigger for Incidents ved hjelp av en Alert regel. 78

82 Alert reglene fungerte som de skulle, men som vi nevnte over i Utfordringer med Event Regler måtte vi endre Event reglene som genererte Alerts. Etter at denne endringen ble implementert, har vi Alert regler som følger: Coolify Minor Incident: Fanger opp Alertene som blir generert av Event regelen Coolify Minor Alert. Coolify Major Incident: Fanger opp Alertene som blir generert av Event regelen Coolify Major Alert. Coolify Critical Incident: Fanger opp Alertene som blir generert av Event regelen Coolify Critical Alert. Problemet med denne løsningen er at vi ikke rakk å implementere en måte å få varslet brukerne av systemet, før vi er nødt til å sende Incidents. Mye av hensikten med den stegvise tellingen og to Event Rules per Coolity, var at vi den første genererte en Alert, og så med den andre eskalerte Alerten og sendte en Incident. I vår ferdig løsning genereres Alerten og Incidenten samtidig, så varslingen skjer via Incidenten. Vi diskuterer dette videre i 8.0 Fremtidig utvikling Task Templates og Incident ServiceNow definerer selv at hensikten med Incident Management er å gjenopprette vanlig drift så fort som mulig, samtidig som man minimerer innvirkningen på virksomheten og verdiskapingen, etter at en Incident har truffet inn (ServiceNow, udatert-q). Altså er det essensielt at incidenten får meg seg nøkkelinformasjon slik at man så raskt som mulig får kommet seg til roten av problemet, og får løst hva det er. Når vi satte opp Incidenten for første gang lagde vi identiske incidents uavhengig av temperaturen og hvor stort avviket på temperatur var. Dette er fordi vi bare hadde en generisk Alert regel som fanget opp alle kritiske Alerts generert av Event reglene som telte til fire. Dermed trengte vi også bare en Task Template. Tanken var at en administrator eller butikksjef skulle gå manuelt inn i Incidenten å oppdatere den fortløpende om hva som var feil, men underveis i prosjektet da vi måtte justere business logikken, innså vi at det å lage Incidents basert på temperatur var en forbedring av utgangspunktet. Task Templatene og generering av Incidents ble dermed endret da vi gikk over til flere Alert regler. Som nevnt over lagde vi Task Templates som basert på hvor kritisk temperatur avviket har vært, representert i Severityen til Alertene, bestemte de ulike feltene for Incidentene. Helt konkret endte vi opp med tre Task Templates, som generer Incidents til Minor -, Major - og Critical Alerts. På denne måten klarte vi å inkludere nøkkelinformasjon slik at kunden i større grad får utbytte av Incident Management sine fordeler. 79

83 Performance Analytics og Dashboard Coop ønsket et dashboard som viste en oversikt over alle eventer, alerter og incidenter som blir generert av applikasjonen vår. Vi har opprettet to forskjellige dashboards til to forskjellige brukergrupper. En for Coop administrator og en for Coop butikksjef som vises avhengig av hvilken rolle brukeren av applikasjonen har. For å bygge opp et dashboard tar vi i bruk forskjellige widgeter 28 som hver kan vise forskjellige type data vi har valgt i applikasjonen. For en butikksjef vil grensesnittet inneholde widgeter som viser antall eventer og incidenter i sin butikk, grafer som viser antall av hver som har blitt opprettet over tid og en oversikt over alle kjølere som er plassert i butikken. En administrator vil få en liste med butikker som viser hvor mange incident butikken har, navnet til butikken og butikksjef sammen med tellere som viser antall Problem, Incident og Change Request som er opprettet av applikasjonen Hva er Performance Analytics Performance Analytics er en applikasjon som brukes til å samle data og analysere ytelsen til en bedrift og deres komponenter. Dette kan brukes til å analysere temperaturmålingene, hvor mange avvik en Coolity/kjøler registrerer over tid mm. Performance Analytics gjør det lettere å få oversikt over data man får inn under daglig drift Hvorfor Performance Analytics Performance Analytics er et veldig bra verktøy for å kunne måle data og se ytelsen av tjenester en bedrift yter. Man kan bruke applikasjonen til å få overblikk over kjøleres tilstand i hver enkelt butikk, sammenligne modellene og se hvilken som yter bedre enn andre for å få en oversikt over butikkens tilstand. Dashboard Dashbordet er et alternativ til Homepage, som følger med Performance Analytics. Dette brukes for å kunne fremstille data fra Performance Analytics grafisk i et ryddig og oversiktlig grensesnitt. For å kunne se et dashboard må brukeren ha rollen pa_viewer, mens for å kunne sette opp og endre et dashboard kreves enten pa_admin eller pa_power_user som vi inkluderer i brukergruppene hver bruker er del av. Det er også mulig å lage flere faner for hvert dashboard som hver kan vise forskjellig data. Denne dataen fremstilles visuelt i form av diagrammer, tellere eller lister. Homepage er også en form for dashboard, men er ment som startside for en bruker ved innlogging av instancen. Avhengig av rolle består Homepage av forskjellige 28 En widget er en del av et grafisk brukergrensesnitt (GUI) som viser informasjon eller tilbyr en spesifikk måte å påvirke et operativsystem eller en applikasjon. 80

84 navigasjonselementer, funksjonelle kontrollere og systeminformasjon. I en instance der Performance Analytics er aktivert, kan man velge å sette sitt dashboard som homepage ved innlogging i stedet Kommunikasjonsflyt og varsling Det første steget i denne prosessen var å tilegne seg informasjon om hvordan varsling foregår i dagens drift. Etter å ha forhørt oss med kunden ble vi fortalt at det er forskjellig praksis i butikkene. Det var generelt de eldste butikkene som hadde et behov for applikasjonen vår, ettersom et av de største problemene i dagens prosess er at alle stegene i målingen av temperatur gjøres manuelt. De ansatte må gå rundt med en måler, føre temperaturene opp på et ark og så skrive det inn i et system. På grunn av dette har gruppen helt siden starten av prosjektet hatt et stort fokus på varsling. Det å automatisere især kommunikasjonsflyten og eliminere så mange manuelle steg som mulig har vært et stort mål. I starten hadde vi sett for oss at vi skulle varsle de tre brukergruppene som fantes i prosessen, nemlig ansatte som jobbet i butikken, butikksjefene og administratorer. Dette skulle skje stegvis med gradvis opptrapping, slik at de ansatte skulle få tid til å rette opp feilen, om dette tok for lang tid skulle butikksjef varsles for å kunne følge opp problemet, og om dette igjen tok for lang tid skulle administratorer varsles. Basert på de ulike brukergruppene vurderte vi derav mange forskjellige varslingsmetoder, deriblant: Notifications: Notifications er enten s eller SMSer som sendes av eventer (ServiceNow, udatert-v). Live Feed Alerts: Live Feed Alerts lytter på tabeller og generer en alert i en brukergruppe- eller selskaps feed (ServiceNow, udatert-ad). Alerts i Event Management: Alerts i Event Management blir kalt av eventer og kan settes opp i kategorier og sorteres etter omfang/alvorlighetsgrad. Den har også fire tilstander, basert på hvor langt i prosessen den har kommet (ServiceNow, udatert-s). Etter litt eksperimentering kom vi frem til at en sammenslått løsning mellom Notifications og Alerts i Event Management var best for butikksjefer og coop administratorer. Hvordan disse fungerer i praksis kan du lese mer om i 6.0 Produktdokumentasjon. Imidlertid rakk vi dessverre ikke å implementere varsling for ansatte i butikken. Dette kommer av tidsnød, ettersom Coop ønsket seg varsling på mobil for de ansatte i butikken, og vi ikke hadde tid til å sette oss inn i mobilapplikasjoner i ServiceNow. Vi tok dette opp med både arbeidsgiver og kunden, hvor vi allikevel fant ut at det allerede er et prosjekt som jobber med å lage en mobilapplikasjon i ServiceNow hvor de ansatte manuelt kan føre opp temperatur, istedenfor å ha det på papir. Vi foreslo 81

85 at oppdragsgiver og kunde kunne slå sammen vår løsning med deres, slik at kunden sitter igjen med et så godt produkt som mulig. Vi kommer tilbake til videre utvikling og tanker til løsningen under 8.0 Fremtidig arbeid Utfordringer i utviklingen Bytte av instance Et godt stykke inn i utviklingen fant vi ut at ved vår Instance sin opprettelse, ble det registrert feil selskap som eier av Instancen, dvs det selskapet som har eierskap av applikasjonen vi lager. I vår Instance var det Rema som var oppført som selskap, som førte til at alle våre tabeller fikk scopet x_rema_coolify, som vi i utgangspunktet trodde var tilfeldig generert, men som ville fulgt oss helt til utgivelse. Dette er en såpass integral del av Instancen, at å bare bytte navn på selskapet ikke ville løse scopeproblemet vårt. Vi endte opp med å få veileder til å spinne opp en ny Instance til oss, med riktig navn. Heldigvis var vi i et stadie i utviklingen der eksport og import av eksisterende konfigurasjoner ikke ville ta for lang tid, så vi var relativt raskt tilbake til full utvikling. Navnet på vår instance endret seg fra coopstudentdemo.service-now.com til coopbachelordemo.service-now.com Treffe taket i ServiceNow: Event regler Som vi nevnte tidligere i denne delen, kom vi til et punkt i utviklingen hvor vi satt oss helt fast. Dette var da vi innså at to Event regler ikke kan implementeres til å lytte på en og samme Event. Gruppen kom raskt opp med alternative løsninger, men vi klarte ikke å finne en løsning med likeverdig verdiskaping. Første skritt etter dette var å spørre om hjelp i kontorene hos Symfoni, der vi jobbet. Vi tok kontakt og rådførte oss med flere konsulenter med forskjellig nivåer erfaring. Det kom raskt frem at ingen på Symfoni hadde jobbet med dette før, så kompetansen var ikke tilstede, men noen av konsulentene bidro med forslag til løsninger som kunne fungere. Forøvrig ble vi tipset om at det var et team med konsulenter lokalisert i Symfoni sine kontorer i Stavanger som nylig hadde begynt å jobbe med Event Management. Vi arrangerte et Skype møte med dem, men også her fant vi ut at de ikke satt på kunnskapen til akkurat vårt problem. De introduserte oss dog til konseptet med CI og CMDB, noe som ble en stor bidragsyter til den ferdige applikasjonen. En av konsulentene viste også en stor grad av interesse for hele prosjektet, og vi har mailet tett med han siden møtet. Etter dette tok vi igjen kontakt med en av kontaktpersonene våre hos Symfoni, og vi fikk mailen til en konsulent i Symfoni Sverige som hadde drevet med dette i lengre tid. Vi nådde ut til han, men han hadde dessverre ikke disponibel tid til å bistå til prosjektet, men han ga oss mailen til en av sine kollegaer som hadde en over 82

86 middels interesse for sitt eget arbeidsfelt. Vi hadde et møte med han, men igjen kunne ikke denne konsulenten hjelpe oss. Han kunne dog meddele at de jobbet på et liknende prosjekt, hvor de løste problemene vi hadde med tredjepartsprogrammer. På dette punktet hadde det gått nesten to og en halv uke uten progresjon i applikasjonsutviklingen. Gruppen begynte å bli svært frustrert og vi begynte å nærme oss fristene vi hadde satt for oss selv. Vi gikk dermed til vår veileder og hadde et møte med han hvor vi forklarte at dersom vi ikke fikk løst problemet, ville vi måtte lage en løsning med mindre funksjonalitet. Veilederen vår trakk i noen tråder og vi ble satt opp på et nettmøte med Jason Smith, en Senior Solution Consultant i ServiceNow som er ansvarlig for Event Management i hele Norden. Vi hadde et lengre møtet med Jason hvor det kom fram at ServiceNow sin plattform faktisk ikke støtter funksjonaliteten å ha to Event regler på en Event. Etter noen samtaler med Jason om hvordan vi kunne komme opp med en god løsning som mulig, som lignet mest på den vi hadde, konkluderte Jason med at han skulle ta problemet vårt videre til Product Management avdelingen innad i ServiceNow, for å fronte at det skulle implementeres funksjonalitet for å støtte flere Event regler mot en Event. Til sist pratet vi om potensiale til applikasjon etter bachelorgruppen var ferdig med den. Dermed kan vi med sikkerhet si at veien videre etter dette går utenfor omfanget en bachelor rekker å dekke. Vi fant en alternativ løsning og venter spent på utvikling hos ServiceNow, og gruppen synes det er spesielt begeistrende at vi har potensielt påvirket den totale verdiskapingen til ServiceNow plattformen. Videre er det også motiverende å vite at vi er helt i front av feltet vi har prosjekt i, da flere av konsulentene påpekte at de driver med svært like prosjekter. 5.6 Dokumentasjonsfasen Underveis i bachelorperioden har det vært kritisk for oss å dokumentere hva vi har gjort. Et prosjekt på størrelse med bachelor er ikke mulig for noen å huske alle detaljer, aspekter og avgjørelse fra. Denne delen tar derfor for seg måten vi dokumenterte arbeidet vårt, kontakten og avgjørelsene fra dag til dag helt til vi startet å skrive og ferdigstille sluttrapporten i mai. Vi benyttet oss av dagbøker og møtereferat for å ferdigstille sluttrapporten vår. Det var en stor fordel å kunne se tilbake på dagene vi brukte på arbeidet og vite nøyaktig hva vi gjorde Dagbøker Gruppen startet 10. januar med prosjektdagbøker. Hvert gruppemedlem hadde hver sin dagbok der de dokumenterte hva de jobbet med fra dag til dag og eventuelle 83

87 problemstillinger som dukket opp. Målet var å ha en oversikt over hva vi jobbet med, hvilke problemstillinger vi hadde møtt på og hvilke tanker vi hadde gjort oss rundt de. På denne måten var det lett å starte dagen fra der vi slapp dagen før Gruppedagbok I tillegg til at hvert gruppemedlem hadde hver sin dagbok, hadde vi også en felles dagbok vi kalte gruppedagbok. Denne hadde som funksjon å dokumentere det overordnede arbeidet vi jobbet med og hvordan vi lå an der, eventuelle problemer vi møtte på og hvordan vi løste det. Vi noterte også flere av møtene vi hadde med de ulike interessentene for prosjektet; Høgskolen i Oslo og Akershus, ServiceNow og Coop Møtereferat Til møter vi selv hadde bedt om å få eller møter der vi visste vi hadde mange spørsmål skrev vi egne referat med en slags mal til møtet på forhånd slik at vi var klare. 84

88 Innholdsfortegnelse: Produktdokumentasjon 6.0 Produktdokumentasjon ServiceNow plattformen Nettverksstruktur Glide Stack Database ServiceNow instancer, applikasjoner og moduler Underprogrammer/Plug-ins Komponenter tatt i bruk Teknisk dokumentasjon: Coolity Temperaturmåling WiFi-tilkobling REST API: Sende temperaturmålinger til ServiceNow Hvilemodus: Deep Sleep Teknisk dokumentasjon: Coolify Beskrivelse av programmet Systemarkitektur Logisk datamodell Backend Integrering av Event Management Frontend Installasjon og vedlikehold Systemkrav Installasjon Vedlikehold Brukermanual Oppsett av Coolity Oppsett av Coolify Dashboardet Kontroll av temperaturovervåking Event Management

89 6.0 Produktdokumentasjon Figur 40 viser hvilke deler som bør ha vært lest frem til nå I denne delen av oppgaven vil vi gå igjennom oppbygging, installasjon, drift og vedlikehold av programmet. Denne delen er hovedsakelig beregnet for ServiceNow konsulenter som skal drifte og videreutvikle applikasjonen, men er også nyttig for alle interessenter som har et ønske om å få en dypere forståelse av de ulike delene av applikasjonen og Coolity-enheten, samt hvordan systemet er bygget opp. Mye av produktdokumentasjonen vil forutsette at leseren har forkunnskaper om ServiceNow sin plattform og de ulike komponentene det innebærer, samt drevet med utvikling i ServiceNow sitt system. Det er også en fordel å ha drevet med Event Management og Performance Analytics før, men ikke et krav. Gruppen har etter beste evne prøvd å inkludere så mye bakgrunnsinformasjon som mulig slik at flest mulig lesere skal ha utbytte av dokumentasjonen. Utover dette henviser vi til ordlisten. 86

90 6.1 ServiceNow plattformen I vårt prosjekt har vi tatt i bruk ServiceNow sin Application Platform-as-a-Service (apaas) (ServiceNow, udatert-w). På denne plattformen er det nærmere 200 forhåndslagde plugins som kan skrus på ved behov. Når en kunde først tar i bruk denne plattformen er det et bestemt utvalg plugins som skrur seg på out of the box, slik at alle kunder får samme produktet til å begynne med. Videre kan man enten skru på flere plugins eller utvikle egne applikasjoner for å oppnå ønskelig funksjonalitet på plattformen. Dette ga oss muligheten til å anvende våre kunnskaper fra studiet på en ny måte og bygge applikasjonen raskere enn vi kunne gjort med andre verktøy, slik at vi kunne fokusere mer på funksjonalitet og innhold Nettverksstruktur For å gjøre plattformen tilgjengelig for alle på en trygg og effektiv måte er hele plattformen lansert på skyen 29. Det at plattformen ligger på skyen, gjør at alle som har tilgang til en moderne nettleser kan få tilgang til plattformen og ta den i bruk med en gang. Når en kunde tar i bruk ServiceNow får de en eller flere instancer som er avgrenset fra andre kunder sine instancer. Denne instance fungerer som et eget domene og er stedet en bruker går inn for å aksessere plattformen gjennom nettsiden/url en: I forhold til andre konkurrenter opererer ServiceNow med et høyt antall datasentre over hele verden. Til forskjell med andre leverandører av skytjenester har satt opp infrastrukturen med 8 datasenterpar (til sammen 16 datasentre) rundt omkring i verden. Instancer blir splittet over to fysiske datasentre som former et high availability 30 -par og sikrer brukeren ved at det alltid finnes en ressurs som kan aksesseres. Når man skal koble til sin instance blir man henvist fra DNS til det datasenteret som på det øyeblikket kjører instancen. Hvis dette datasenteret mot formodning går ned, flyttes man over til det tilhørende datasenteret. Denne funksjonaliteten gjør at alle brukere kan forvente at deres instance alltid er oppe. ServiceNow skilter med gjennomsnittlig % uptime med 6 timer planlagt vedlikehold hvert kvartal. Se vedlegget 12.1 Introduction to ServiceNow for mer informasjon. 29 Skytjenester (cloud computing) er en samlebetegnelse på alt fra dataprosessering og datalagring til programvare på servere som er tilgjengelig fra eksterne serverparker tilknyttet internett. (Datatilsynet, udatert) 30 High Availability (HA) vil si at et system eller en komponent som strever for å være oppe oftere enn vanlig. Uptime skal være så høyt som mulig og man skal skjerme systemet mot uforutsette downtimes. 87

91 Figur 41 viser tilgjengelige datasenter og forholdet mellom dem Glide Stack På denne apaas en har ServiceNow sin egendefinerte Web 2.0 utviklingsplattform, Glide Stack. Glide er skrevet hovedsakelig i Java og JavaScript, og gjør det mulig å effektivt lage form-baserte workflow applikasjoner (ServiceNow, udatert-n). Glide Stack er bygd opp på følgende måte: 88

92 Figur 42 Glide Stack diagram 31 GlideSystem - Mozilla Rhino (JavaScript) GlideSystem i ServiceNow tar i bruk Mozilla Rhino. Mozilla definerer Mozilla Rhino som en open source implementasjon av JavaScript (Mozilla Developer Network, 2016) skrevet i Java, også omtalt som en JavaScript-motor av Wikipedia (Wikipedia, 2017). Rhino brukes for å konvertere JavaScript skript til klasser, og blir som oftest brukt i Java applikasjoner for å tilby skripting til sluttbrukere. I ServiceNow bruker man metodene til GlideSystem for å utvide funksjonaliteten i instancer, blant annet med å lage Business Rules. GlideRecord - MySQL/Oracle/DB2 GlideRecords er Java klasser som kan bli brukt i JavaScript som om de var JavaScript klasser. De brukes til Database Interface (DBI), for å sette opp databaseoperasjoner uten å kjøre SQL spørringer, og hvert GlideRecord objekt inneholder null eller flere databaserader (ServiceNow, udatert-o). GlideForm - Apache Jelly GlideForm er en JavaScript klasse man bruker til å tilpasse forms 32. Teknologien baserer seg på Apache s Jelly sin syntaks som brukes til rendering av blant annet forms, lister og UI-sider i ServiceNow (ServiceNow, udatert-m) Forms er uttrykket som brukes i JavaScript-klassen som oversettes til skjema på norsk. 89

93 Alle disse kjøres gjennom GlideServlet, hvorav GlideSystem og GlideRecord kjører på serverside, mens GlideForm kjøres på klientsiden Database I ServiceNow blir nesten alt i plattformen lagret som en entry i en database. Almost everything in ServiceNow is an entry in a database. When you look at the user interface, virtually everything you see-from the data typed in by a user to log files and how the views are structured-is stored in the instance's relational database. The scripts you write are kept in a string field, and the files you attach to records are stored in chunks, all in the database. (Wood, 2016, Kapt. 1-3) All denne dataen blir lagret i tabeller, og siden hele plattformen er bygd opp på denne strukturen trenger man ikke å restarte serveren for å legge til ny funksjonalitet - man trenger bare å oppdatere records. Denne funksjonaliteten tillater brukere av plattformen å kunne skreddersy plattformen til sine behov uten å måtte tenke på det tekniske som ligger bak Relasjonsdatabase ServiceNow er bygget opp av relasjonsdatabaser (ServiceNow, udatert-f). Det vil si at de bygger på den såkalte relasjonsmodellen der databasen består av tabeller som er forbundet med henvisninger. Disse henvisningene er i praksis satt opp som nøkler der man har en primærnøkkel i hver tabell samt en fremmednøkkel i hver relaterte tabell som peker til denne primærnøkkelen (Oracle, udatert). Dette oppretter det vi kjenner som relasjoner i en database. Vi kan lage spørringer som henter informasjon fra relaterte tabeller når vi skal vise frem data Global unique identifier (GUID) I ServiceNow opprettes disse relasjonene i praksis ved bruk av datafeltet Reference (ServiceNow, udatert-aa). Dette er et eget felt som peker til records i en annen tabell. Hver enkelt record i ServiceNow har feltet Sys_id - et GUID 33 (ServiceNow, udatert-ag) på 32 karakterer som genereres ved å samle forskjellige data om applikasjon/scope/dato/tid/sted o.l. Dette fører til at alle records på ServiceNow-plattformen er unike fra hverandre og det er dette unike feltet som 33 Globally Unique Identifier 90

94 Reference peker til for å opprette relasjoner mellom tabeller. Eksempel på GUID: cc611227c000bbd1bd8cd Dot-walking Når man legger til Reference feltet i en tabell og peker til en annen tabell, åpner dette for et konsept som er veldig viktig for ServiceNow: Dot-walking (ServiceNow, udatert-j). Dot-walking er funksjonen der man kan få tilgang til data i tabellen som det blir referert til ved å dot-walke - dvs å kalle på felter ved hjelp av punktum (. ). Eksempel: soda.manufacturer.name vil inneholde navnet på fabrikanten av en bestemt brus. Denne funksjonaliteten har vi brukt mye i diverse script som vi kommer til senere. 6.2 ServiceNow instancer, applikasjoner og moduler I denne delen vil vi gå kjapt igjennom hva en ServiceNow applikasjon og en ServiceNow instance er, samt hvilke globale applikasjoner vi har tatt i bruk som supplement til vår egen oppgave. Vil vil først forklare forskjellen på en ServiceNow applikasjon kontra en ServiceNow instance, for å så videre prate om underprogrammene Event Management og Performance Analytics. Til sist vil vi gå igjennom de generelle definisjonene av de forskjellige komponentene innenfor applikasjonsutvikling i ServiceNow vi har tatt i bruk. Først og fremst må vi definere hva en ServiceNow instance er. Dette er fordi det er gjennom en ServiceNow instance man enten kan laste ned eksterne, globale applikasjoner, hente applikasjoner som tilhører ditt firma eller lage dine egne applikasjoner. Det er også her man får tilgang til modulene som er tilgjengelige. Vi vil komme tilbake til definisjonene av de to sistnevnte senere, men først definerer ServiceNow en instance slik: A instance is an individual implementation of the ServiceNow platform. Each instance has a unique address (usually and many customers have multiple instances (such as sandbox, development, and production instances) (ServiceNow, 2015a). Altså kan man på en svært forenklet måte si at plattformen til ServiceNow er som et operativsystem, hvorav instancen er ditt operativsystem på din PC, som du kan gjøre endringer på innenfor gitte rammer. Videre kan man også laste ned applikasjoner i instancen. Verdt å nevne her er at ettersom ServiceNow er et cloud selskap, så lagres alle instancer på et dedikert sett av virtuelle Linux maskiner. Dette gir instancene muligheten til å skalere, slik at ekstreme mengder brukere og applikasjoner kan betjenes i en instance uten at det går utover ytelsen. 91

95 Videre er det også i disse instancene man har tilgang til alle modulene i applikasjonsnavigatoren, hvor en modul defineres slik A module is any link in the application navigator that opens a page in the content frame or in a separate tab or window. (ServiceNow, 2015a) I vår applikasjon, har vi opprettet modul-menyen Coolify som inneholder alle tabellene våre som egne moduler. Når vi åpner en modul, vises datafelter som vi har forhåndsbestemt skal vises ved hjelp av List Layout 34 som tillater oss å definere hver enkel grafisk fremstilling av våre tabeller. Figur 43 viser eksempel på moduler Dette bringer oss til hva en ServiceNow applikasjon er. En ServiceNow applikasjon er ikke helt som alle andre, da den må lastes ned på en ServiceNow instance for å fungere. ServiceNow definerer det selv som følger, i en av sine Wikibøker: An application is a group of modules, or pages, that provide related information and functionality in a ServiceNow instance. For example, the Incident application contains modules for creating and viewing incidents; the Configuration Management application contains modules for configuring servers, databases, and networks. The application navigator, or left-navigation bar, provides links to all applications and the modules they contain, enabling users to quickly find information and services. (ServiceNow, 2015b) 34 En konfigurasjon av hvilke kolonner som skal vises når en bruker ser på en tabell fra applikasjonsnavigatøren. 92

96 Det er altså i applikasjonen du lagrer alt av databaser, scripts, forms, egendefinerte regler og så videre. Utifra dette ser man viktigheten av å forstå forskjellen og kunne skille mellom en ServiceNow Instance, en ServiceNow applikasjon, samt modulene og sidene applikasjonen inneholder Underprogrammer/Plug-ins ServiceNow tilbyr en rekke produkter for å forbedre business modellen og hverdagen til flere bedrifter innenfor flere bransjer, deriblant IT Service Management (ITSM) og IT Operations Management (ITOM) (ServiceNow, udatert-ac). Disse kan også brukes for å forbedre utviklingen av egne applikasjoner ved at ServiceNow har en rekke konfigurerbare applikasjoner som kan abonneres på som en plug-in for å forbedre verdiskapingen til en applikasjon. Ut av disse har vi i stor grad drevet med IT Service Management (ITSM), som tar for seg blant annet Incident Management og Problem Management (ServiceNow, udatert-r). Allikevel er det nok IT Operations Management (ITOM) som preger oppgaven vår mest, i form av produktet Event Management (ServiceNow, 2016a). Event Management har vært helt avgjørende for at vi kunne ta dette prosjektet så langt som vi faktisk gjorde. Til sist brukte vi også Performance Analytics, et mer selvstendig produkt som fokuserer på å analysere og sette mål for hele bedriftens fremgang ServiceNow Event Management Event Management er en ServiceNow applikasjon som hjelper deg å identifisere feil i datasystemet på en enkeltstående management konsoll (ServiceNow, udatert-k). ServiceNow sin visjon med Event Management er å automatisere prosessflyten ved å lage automatiserte rammer som identifiserer og varsler alle uønskede endringer i tjenester hos bedrifter. Dermed har de laget verktøyet ServiceNow som i sanntid overvåker tilstanden til tjenestene og infrastrukturen hos selskapet, og varsler om alle problemer som oppstår. Rent teknisk defineres det på følgende måte av ServiceNow: ServiceNow Event Management automatically creates actionable alerts from infrastructure events captured by third-party monitoring tools. When used with ServiceNow Service Mapping and ServiceNow Configuration Management Database (CMDB), the application maps alerts to configuration items (CIs) and services. You get a service health dashboard that shows a consolidated view of all service-impacting events. Now you can take action from alerts by automatically creating Incidents, setting rules to trigger workflows, or providing 93

97 automated remediation options through ServiceNow Orchestration. You can even identify and proactively act upon potential infrastructure problems before they cause service outages. (ServiceNow, udatert-l) Det er nettopp denne tankegangen vi har basert store deler av vår oppgave på, med den hensikt å kunne forhindre store verditap hos kunden samt å varsle de så snart et problem oppstår ServiceNow Performance Analytics Performance Analytics er, som navnet tilsier, et produkt som hjelper alle utviklere og daglig ledere å få et overblikk på hvordan bedriften gjør det. Performance Analytics prøver å gjøre jobber der funksjonsverdien ligger i å holde oversikt over dataen man får inn i daglig drift, ved at den overvåker key performance indicators (KPIs) og metadata i et visuelt dashboard. Dette dashboardet har dessuten interaktiv funksjonalitet slik at man raskt kan komme seg til der problemet oppstod (ServiceNow, udatert-y). Ved å gjøre dette, kan bedrifter overalt lettere måle sine egne Service Level Agreements (SLAs), altså at eierne av instancen som kjører Performance Analytics kan opprettholde verdiskapingen og forpliktelsene overfor sine egne brukere og kunder. Kort oppsummert kan hensikten med Performance Analytics defineres som å visualisere data fra din instance for å bedre forstå dine prosesser og derav drive kontinuerlig forbedring (ServiceNow, udatert-z). I vår oppgave ble dette essensielt for å se på utviklingen av temperatur over tid, for å kunne isolere problematiske frysere eller tidspunkt på dagen hvor fryserne er spesielt utsatt, slik at man proaktivt kan redusere tapene hos kunden Komponenter tatt i bruk I denne siste delen vil vi kort forklare de forskjellige komponentene til ServiceNow vi tar i bruk: Komponent Kjører på Beskrivelse Ofte brukt til Business rules Server Utføre operasjoner på tabelldata når den fremstilles, blir satt inn, oppdatert, slettet eller spørres etter. Script Includes Server Lagre JavaScript funksjoner og klasser for senere bruk av server-side script-objekter. Hvert script include definerer enten en funksjon eller en Validere data og sette i gang events Tillater forskjellige komponenter til å gjenbruke server kode og gjør server kode tilgjengelig for 94

98 implementasjon av en ServiceNow klasse. Kjører bare når kalt på av server script. Events Server Kjører når spesifikke betingelser oppfylles. Script actions Server Kjører når et bestemt event blir avfyrt for å avgjøre hvordan systemet skal bearbeide eventet. klientside kall. Identifisere og nedskrive når bestemte betingelser oppfylles, som for eksempel når en temperatur er 5C. Automatisere en respons når et bestemt event oppstår. For eksempel sende en melding til butikkansvarlig om at en kjøler er for varm. UI Actions Server eller Klient Legge til UI elementer, knapper, linker, menyer og lister som tillater en bruker å gjøre operasjoner. Tillater en bruker å gjøre en bestemt handling. F.eks. endre status på et event til at den er løst. Client scripts Klient Kjører JavaScript i nettleser for å utføre operasjoner på tabeller. UI policies Klient Utføre operasjoner på tabelldata eller datafelt - synlig, read-only, -unik osv. Sette regler for validering av input fra brukere. F.eks. sjekke at Sluttdato ikke er før startdato. Håndheve datapolitikk fra UI, som å gjøre slik at ChipID må være unikt for hele tabellen. 6.3 Teknisk dokumentasjon: Coolity I denne delen av oppgaven vil vi presentere og gå igjennom de viktigste delene av koden som utgjør prototypen vår Coolity 1.0. Fra tidligere i prosessdokumentasjonen har vi forklart hvilken kode vi trengte og hvorfor, og vi skal nå gå igjennom og forklare punktene. 95

99 6.3.1 Temperaturmåling Vi har brukt to biblioteker i forbindelse med Dallas DS18B20 temperaturmåler. Vi brukte DallasTemperature bibliotek for utregningen av temperaturer og OneWire for å koble temperaturmåler og NodeMCU sammen. OneWire bibliotek er ment for komponenter med kun én strøminngang som Dallas temperaturmåleren. Fordelen med OneWire biblioteket er at det kun trenger noen få ledninger og en 4.7k Ohm resistor for at temperaturmåler fungerer riktig. Det er mulig å få en fungerende temperaturmåler uten noen form for bibliotek, men da vil temperaturmåleren gi upresise målinger WiFi-tilkobling For at Coolity skal kunne koble til WiFi har vi tatt i brukt ESP8266WiFiMulti biblioteket. ESP8266 WiFi modulen har tre moduser: Access Point (AP), Station (STA) og Access point and Station (AP & STA). Access Point modus: WiFi modulen vil sette seg til et Access point, hvor andre enheter kan kobler til. Station modus: Wi-Fi modulen vil kobler til et bestemt WiFi SSID. Access Point and Station modus: er en kombinasjon mellom Access point og Station. WiFi modulen vil både koble seg til en gitt WiFi SSID og sette seg som en slags WiFi hotspot. For Coolity er vi kun interessert i at WiFi modulen skal koble til et annet Acces Point, som vil si at selve WiFi modulen er i Station modus. Så snart en Coolity-enhet slås på, vil den da prøve å koble til et nettverk med WiFi SSID og passord som er gitt. Code 58. // Connect ESP8266 with to an Access point (WPA) 59. WiFiMulti.addAP("wifi-ssid","wifi-password"); REST API: Sende temperaturmålinger til ServiceNow For at Coolity skal kunne sende data til Coolify har vi tatt i brukt et bibliotek som heter ESP8266HTTPClient. Biblioteket hjelper til og muliggjøre utførelse REST kallene til ServiceNow og Coolify-applikasjonen. REST kallene består av tre hoveddeler; end-point, head og body. HTTP end-point: er endepunktet, det vil si hvor dataene er plassert eller skal bli plassert. HTTP head: består av hvilken autentiseringsmetode som skal brukes, og hvilken type innhold det skal være. 96

100 HTTP body: er hvilken HTTP request vi ønsker å utføre, hvor det kan være GET, POST, PUT, PATCH eller DELETE. Til Coolity bruker vi POST metoden som betyr at vi sender og skriver data til end-pointet vi har satt i Coolifyapplikasjonen. For at Coolity skal kunne sender data til ServiceNow kreves det en internetttilkobling. I ESP8266HTTPClient bibliotek har vi også brukt httpcode metoden som verifisere om kallene Coolity utfører er vellykket eller mislykket. Dette vises ved en tilbakemelding i Arduino IDE der tallet 200 indikerer suksess og 400 indikerer feil i REST kall Hvilemodus: Deep Sleep For å spare batteriet til Coolity, tar vi i bruk en funksjonalitet kalt Deep Sleep. Når Coolity-enheten har sendt data til Coolify-applikasjonen, stopper alle komponenter å kjøre bortsett fra den innebygde sanntidsklokken på ESP8266 WiFi-chipen. Sanntidsklokken fungerer som en alarm med et gitt tidsintervall den skal vekke alle komponenter på. ESP8266 regner tiden i mikrosekunder, og i eksempelet nedenfor har vi satt et regnestykke 15*60* som utgjør 15 minutter søvn for Coolity: Code 125. //Deep sleep with a 15 minutes interval ESP.deepSleep 15*60* , WAKE_RF_DEFAULT); Etter 15 minutter vekkes Coolity-enheten for å utføre målinger og sende data, før den repeterer prosessen med søvn igjen. Dette gjøres kontinuerlig. 6.4 Teknisk dokumentasjon: Coolify I denne delen av oppgaven vil vi gå igjennom hva som ble vår endelige applikasjon. Altså vil vi steg for steg gå igjennom hva som ble implementert i applikasjonen, hvilke tillegg som ble brukt og hvorfor vi brukte dem. Etter å ha rådført oss med diverse konsulenter hos ServiceNow har vi kommet frem til at det er mest hensiktsmessig å skrive denne delen prosedyrisk. Dette medfører at vi får en egendefinert struktur på denne delen av rapporten, hvor enkelte deler vil flyte litt inn i hverandre til fordel for å vise sammenhengen av prosesser og komponenter, eller gangen i systemet. For oss gjelder det især Backend og Underprogrammer. Merk at denne delen av oppgaven vil ikke ta for seg hvordan man bruker programmet; dette finner du i 6.6 brukermanualen. 97

101 6.4.1 Beskrivelse av programmet I denne delen vil vi gi en kort beskrivelse av hensikten med applikasjonen, hva applikasjonen gjør og forretningslogikken, samt en kort gjennomgang av de mest sentrale business reglene og scriptene. Som nevnt innledningsvis i rapporten, er hensikten med programmet å automatisere temperaturmålinger i kjølere hos kunden. Coolify, vår ServiceNow applikasjon, er knutepunktet for denne prosessen, da det er den som lagrer all informasjon mottatt av Coolityen, fellesnavnet for våre NodeMCUer, og som videre varsler de ansatte hos kunden. Programmet skal hovedsakelig brukes av ansatte hos Coop for å administrere alle kjølere, og slik fungerer det: Coolityene plasseres ut i frysere i butikker hos Coop, der de kobler seg opp mot internett via WiFi og så Coolify. Deretter begynner de å sende inn temperaturmålingene sine med REST kall til Coolify sin Measurement tabell. All data som sendes inn hit kontrolleres av business regler som sjekker type kjøler og temperaturen opp mot grenseverdier. Dersom temperaturen er over grenseverdien vil reglene genere Eventer i em_event tabellen. Disse blir igjen lyttet på av Event regler, som teller antall forekomster innenfor forhåndssatte tidsperioder. Dersom for mange oppstår, genereres en Alert i alert tabellen. Dette blir igjen fanget opp av en Alert regel, som generer en Incident og varsler alle relevante User Groups, og herfra må ansatte hos Coop manuelt ta over arbeidet Sentrale Business regler Business Regler Verify Fridge Temperature Verify Freezer Temperature Set Current Temperature in Tables Assign store manager to Incident Set Coop Administrator Group Lager en Event [em_event] til CI dersom temperaturen i kjøleskapet er over 4.5 grader Lager en Even [em_event] til CI dersom temperaturen i fryseren er over -18 grader Når en temperatur kommer inn fra kjøler/fryser, settes dataen som Current Temperature i respektiv tabell Når en Incident genereres, finner koden hvem som er Store Manager i butikken temperaturen kommer fra, og setter han/hun i Assignment feltet. Gir alle som blir lagt inn i Coop 98

102 Administrator tabellen rollen Coop Admin fra User Roles. Set Store Manager Group Remove Administrator from Group Remove Store Manager from Group Gir alle som blir lagt inn i Store Manager tabellen rollen Store Manager fra User Roles. Dersom en bruker fjernes fra Coop Administrator tabellen, mister de også rollen sin. Dersom en bruker fjernes fra Store Manager tabellen, mister de også rollen sin Systemarkitektur Figur 44 ServiceNow systemarkitektur Systemarkitektur forklarer hvordan delene i systemet kommuniserer med hverandre, hvor dataene kommet fra, hvordan systemet håndterer data og hvordan brukere får tilgang til disse dataene. 99

103 6.4.3 Logisk datamodell Figur 45 logisk datamodell for Coolify Den logiske datamodellen forklarer databasemodellen vi kom frem til, til slutt. Vi har våre tabeller, deres relasjoner og hvordan de samkjører med Event Management sine tabeller. De tabellene som er uthevet med en rød firkant er allerede eksisterende tabeller vi har tatt i bruk, og de blå pilene representerer de forskjellige reglene som kjøres for å generere en ny record i hver tabell Backend Databasen Vi bruker Studio for å opprette databasetabeller, som i bakgrunnen er MySQLtabeller. I vår applikasjon har vi benyttet oss av følgende tabeller som allerede finnes i plattformen: Tabell Configuration Item (CI) Beskrivelse Inneholder all relevant informasjon om alle komponenter i et IT-system. Laptoper, mobiler, lisenser osv. 100

104 User Event Alert Incident Alle brukere på instancen. Alle eventer som registreres i systemet. Bruker her CI for å binde fast hendelser med de forskjellige objektene. Når event regler fyres av oppretter vi alerter som fylles ut med informasjon om eventen som lagde den. Alle saker som lages i plattformen som må bli håndtert. Incidentene kan komme fra mange kilder - f.eks. event management. I vårt eget scope har vi opprettet følgende tabeller for å strukturere databasen: Navn Coop Administrator Store Manager Store Model Cooler Device CI Measurement Beskrivelse Alle administratorer. Tabellen består av en referanse til User-tabellen. Rettigheter tildeles disse brukerne automatisk når de legges til i denne tabellen via business regler. Alle butikkeiere. Tabellen består av en referanse til User-tabellen slik at vi lettere får oversikt over butikkeiere i vår løsning. Alle butikker i Coop. Har en referanse til Store Manager tabellen for å vise hvem som står ansvarlig for butikken. Fryser- og kjølemodeller som Coop innehar. Viser hvilken type kjøler hver maskin er - Kjøleskap/Fryser. Alle kjølere og frysere som er plassert ute i en butikk. Viser nåværende temperatur samt modell/butikkeier. Forlengelse av Configuration Itemtabellen som arver alle felter og funksjonalitet CI har. Viser hvilken kjøler den ligger i, samt ChipID og antall incidents den har generert. Målingene vi sender inn til REST API et ender opp her. Business regler fyres av 101

105 hvis temperaturen er for høy og lager en event som legges i event-tabellen. ServiceNow bruker Sys_ID som egne primærnøkler, men vi bestemte oss for å lage egne datafelter i Device CI og Cooler for å skille mellom records på en hensiktsmessig måte for vårt prosjekt. Ved at et datafelt skal være display value og Unique får vi i praksis samme funksjonalitet. Sys_id på 32 karakterer gjorde det litt vanskelig for oss å identifisere hver enkelt enhet, så løsningen for Device CI var å bruke hver enkelt enhets unike ChipID. Dette gjorde det lettere for oss å binde målingene i Measurement til riktig enhet i Device CI mens vi, i Cooler lagde feltet CoolerID - et egendefinert ID som vi genererer ut ifra butikktype, butikknavn og nummer i rekken Configuration Items og Configuration Management Database Som nevnt i prosessdokumentasjonen, er CMDB en database som inneholder informasjon om en bedrifts infrastruktur. Med hjelp av denne databasen kan man se status på hver enkelt avdeling til enhver tid. En Configuration Item inneholder veldig mange datafelter som kan brukes for å spesifisere mange deler av komponenten. I all hovedsak måtte vi benytte oss av Configuration Item for å kunne oppnå bindingen mellom Eventer, Alerter og Incident og våre fysiske enheter. Når en CI blir bundet til en hendelse i Event Management, bygges det opp en historikk med referanser til hvilke Coolityen er kilden til. Dette oppnåes med at vi har spesifisert en CI Type, som sier at alle Eventer vi registrerer i Event-tabellen skal lete etter en CI av type Device CI. Event Management leter gjennom hele Device CI tabellen etter en Coolity som matcher feltet Name i både Device CI og Eventen Business regler: Håndtering av temperatur Definisjonen av en business regel er: A business rule is a server-side script that runs when a record is displayed, inserted, updated, or deleted, or when a table is queried. Use business rules to accomplish tasks like automatically changing values in form fields when certain conditions are met, or to create events for notifications and script actions. (ServiceNow, udatert-c) I Coolify har vi tatt i bruk åtte forskjellige business regler, hvorav fire av disse er til håndtering av data som sendes inn til tabellene. De to mest sentrale er Verify Fridge Temperature og Verify Freezer Temperature. Som navnene tilsier er det disse som kontrollerer og overvåker dataen som kommer inn og generer Events i Event 102

106 [em_event] tabellen i ServiceNow instancen hvis den målte temperaturen overstiger en viss grense. Under Advanced taben i business regelen finner man følgende felter: Figur 46 Utklipp fra ServiceNow Studio, hvor vi viser "Advanced" fanen Her setter man altså et krav eller en condition, som må være oppfylt før skriptet kjører. At skript ikke kjører før disse kravene er oppfylt bidrar til å øke den helhetlige ytelsen til systemet ved å motvirke unødvendige skript fra å kjøre. Vi har følgende conditions på hver av reglene: Code / Condition: Verify Fridge Temperature (Business Rule) 1. current.device.cooler.model.type == "fridge" && current.getvalue('temperature') >= 4.5 Code / Condition: Verify Freezer Temperature (Business Rule) 1. current.device.cooler.model.type == "freezer" && current.getvalue('temperature')>=-17.5 Disse grenseverdiene er gitt i kravspesifikasjonen til kunden, men forøvrig så sjekker også business regelen hva slags type kjøler Coolityen får målinger fra, og om det overstiger de forhåndsgitte verdiene. Siden temperaturmåleren vår har en toleranse på grader legger vi inn toleranse for dette i vårt krav. Ved overstigning vil våre businessregler kjøre koden. 103

107 Skriptet består av en såkalt self-invoking eller self-executing JavaScript funksjon. Fordelen med disse er at de kjøres uten å måtte kalles fra et annet sted, samt at variablene som deklareres inne i funksjonen er bare tilgjengelig for funksjon, og ikke utenfra. Dette gir høyere sikkerhet og integritet, og er dessuten god kodepraksis (Ahmed, 2012). Hensikten med koden er å lage et nytt Event objekt i em_event tabellen, som inneholder all den nødvendige informasjonen. I følgende forkortede kodebit lager vi et nytt GlideRecord objekt av tabellen em_event, hvorav et GlideRecord objekt består av en eller flere database records. Videre fyller vi ut feltene i den tomme database recorden ved å bruke funksjonen setvalue(feltnavn, verdi) for å sette verdier i de tomme datafeltene. Code 1. (function executerule(current, previous) { 2. var temperature = current.getvalue('temperature'); 3. var severity = getseverity(temperature); var gr = new GlideRecord("em_event"); 6. gr.initialize(); 7. gr.setvalue("node", current.device.getdisplayvalue()); 8. gr.setvalue("source", "Coolify"); })(current, previous); Første steg er å finne ut hvor kritisk temperaturavviket er utifra forhåndssatte grenseverdier. Dette er for å få satt Severity på eventen - et felt i Event objektet som representerer alvorlighetsgraden av dette avviket og ved videre eskalering. Dette beregnes ved hjelp av getseverity(temperature)-funksjonen som returnerer en array med Severity-verdien i både integer-form og String. Grunnen til at vi ikke bare returnerer selve tallet, er at ServiceNow har en liten feil (sist sjekket ) der Severity = 1 ikke vil sette Critical, men heller 1.0. Code 1. (function executerule(current, previous) { 2. var temperature = current.getvalue('temperature'); 3. var severity = getseverity(temperature); // This function allows dynamic population of the // severity field based on how bad the deviation is. 8. // We re returning an array with numerical value and string 104

108 9. // because setvalue( severity, 1) sets the severity to 1.0, 10. // instead of Critical 11. function getseverity(temperature) { 12. var majordeviation = 7.5; 13. var criticaldeviation = 12.5; //Test the temperature and return severity based on 16. //placement 17. if(temperature > criticaldeviation) 18. return ['1', "Critical"]; // Critical value 19. else if(temperature > majordeviation) return [2, "Major"]; // Major value //If neither major nor minor, we'll return warning } return [3, "Minor"]; // Warning 24. })(current, previous); Vi definerer, i linje 10 og 11, hva som er av stor alvorlighetsgrad og kritisk alvorlighetsgrad. Utifra hvem av if-setningene som oppfylles får Eventen som lages en tilsvarende alvorlighetsgrad, og vil eskalere henholdsvis til denne. Mer om dette under Eventer og Event Regler Business regel: Oppdatering av temperatur på Kjøler og Device CI Vi ønsket å kunne vise hvilken temperatur hver Coolity og tilhørende kjøler lå på til enhver tid. For å få til dette, opprettet vi et veldig enkelt skript som ga god trening i serverside-koding og gjorde det vi ønsket: Code: Set Current Temperature in Tables 1. (function executerule(current, previous) { 2. // Fetch the device and cooler record from the Device CIs and 3. // Cooler table, respectively, through the referenced field 4. var dev = current.device.getrefrecord(); 5. var cooler = dev.cooler.getrefrecord(); 6. // Set Current Temperature data field in both records to be the 7. // reported temperature. 8. dev.current_temperature = current.temperature; 9. cooler.current_temperature = current.temperature; 10. // Update the record to show desired value. 11. dev.update(); 12. cooler.update(); 13. })(current, previous); Integrering av Event Management Event Management er, som nevnt innledningsvis, en plug-in applikasjon som defineres som følger: 105

109 ServiceNow s Event Management application enables the consolidation and management of the Enterprise s IT events. Typically, this means creating actionable alerts from performance and operational health events coming from various IT monitoring tools. (ServiceNow, 2017c) I vårt tilfelle bruker vi Event Management til å overvåke og varsle avvik i temperaturen som er rapportert fra kjølere hos kunden. I denne delen av rapporten forklarer vi hvordan Eventer og Event regler Når business reglene våre generer Eventer, fyller de ut feltene en Event er bygd opp av som følger: Felt Type Hva settes Source String Coolify Node String Referanse til CI (Coolity ChipID) Type String Severity regnes ut basert på temperatur og feltet settes til <Severity> Measurement Resource String ID til kjøleren Coolityen står i Source instance String Feltet er blankt med hensikt Message key String Feltet er blankt med hensikt Severity Choice Regnes ut basert på temperatur, blir enten Minor, Major eller Critical Resolution state Choice Ready (default value) Time of event Date/Time Tiden når eventen ble opprettet State Choice Settes til Processed Alert Reference Dersom er Alert blir generert, vil dette feltet inneholde Alerten sitt ID nummer Description String Feltet er blankt med hensikt Additional Information String Her legges current temperature og navnet på Store Manager til den tilhørende butikken. Processing Notes String ServiceNow plattformen fyller ut dette feltet 106

110 dersom Event regler blir brukt på eventen samt om hvilken CI den binder seg til. CI Type String Device CI (Navnet på vår CMDB) De blå cellene settes og/eller oppdateres av systemet. Grunnen til at enkelte felt settes blankt ved hensikt er at Event Management vanligvis brukes til IT support, så ikke alle feltene er aktuelle for vårt bruksområde. Alle eventene legges inn i Event tabellen [em_event]. For å unngå overbelastning av systemet og uhåndterbare databaser vil hele denne tabellen nullstilles (alle records slettes) hver uke ved hjelp av Table Rotations in ServiceNow. Dette tidsperspektivet kan endres i Application Navigator, under System Definition > Table Rotations. Når Eventene legges inn i Event tabellen [em_event] settes først State til Ready, så sjekker Eventen systemet opp mot en rekke regler som vist i følgende tabell: 107

111 I vår applikasjon er alle Eventer bundet opp mot en Event rule, så sjekken vil alltid være sann. Vi har tre event regler: Coolify Minor Alert Coolify Major Alert Coolify Critical Alert Event reglene er bygd opp på følgende måte: Felt Verdi 108

112 Name Source Coolify <Severity> Alert Coolify Order 100 Active Description Checked (True) Passende forklaring av event regelen Videre fanger vi opp Eventene basert på severity. Dette gjøres ved hjelp av innebygde filter i Event Rules hvor man kan teste Severity is Minor/Major/Critical på følgende måte: Figur 47 viserer hvordan å sette Severity i ServiceNow sin Coolify applikasjon Når riktig Event er fanget opp av regelen, har vi forskjellige utløser betingelser for de ulike reglene basert på alvorlighetsgrad og tid, basert på en terskel. Figur 48 viser utklipp fra ServiceNow applikasjonen Coolify sin Minor Alert regel Eksemplet over er hentet fra Coolify Minor Alert regelen. Som den informative teksten i det blå feltet tilsier, overvåker denne delen av event regelen alle eventer 109

113 som inneholder teksten temperature, og venter på om fire eventer oppstår i en tidsperiode på sekunder. Kort oppsummert sjekker Event Rulene følgende ting: 1. Coolify Minor Alert 1.1. Source feltet til eventen begynner med Coolify 1.2. Eventen som er generert har Severity Minor 1.3. Threshold: Dersom fire eventer av denne typen genereres innenfor tidsperioden av seks mulige, skal en Alert genereres. 2. Coolify Major Alert 2.1. Source feltet til eventen begynner med Coolify 2.2. Eventen som er generert har Severity Major 2.3. Threshold: Dersom to eventer av denne typen genereres innenfor tidsperioden av tre mulige, skal en Alert genereres. 3. Coolify Critical Alert 3.1. Source feltet til eventen begynner med Coolify 3.2. Eventen som er generert har Severity Critical 3.3. Har ingen threshold for denne regelen, ettersom hvis temperaturen er kritisk skal en Alert genereres med en gang. Hvis disse kravene til Event reglene møtes vil Alerter generes og behandles av Alert regler Alert og Alert Rules Definisjon av alert: An alert is a notification generated by Event Management for selected events that are considered to be important and require attention. The generation of alerts is based on event rules. After alerts generate, the manner in which you can monitor and resolve alerts is based on alert configuration settings and properties, and alert impact calculation. (ServiceNow, 2017a) Hvis event reglene våre generer alert, fyller de ut feltene en alert er bygd opp som følger: Felt Type Hva settes Source String Coolify Node String Referanse til CI (Coolity ID) 110

114 Type String <severity> measurement Resource String ID til butikken Coolityen står i Configuration Item Reference Bindes til CI fra Device CI tabellen. Systemet finner CI vha Node-feltet som samsvarer med ChipID. Task Reference Dersom en Incident blir generert, vil dette feltet inneholde Incident-nummeret. Message key String <Source_Node_Type_Resource> brukes for å skille mellom alerter fra samme kilde. Severity Choice Viktighet av alerten. State Choice Open (default value) Category String Default (default value) Acknowledged Checkbox Checked settes av event rule. Maintenance Checkbox Unchecked (default value) Updated Date/Time Tid når event sist ble oppdatert. Knowledge Article Choice Feltet er blankt med hensikt. Brukes dersom man har en kunnskapsdatabase med en artikkel som kan brukes til å løse problemet. Description String Feltet er blankt med hensikt Additional Information String Her legges current temperature og navnet på Store Manager til den tilhørende butikken. De blå feltene er felter som systemet setter automatisk basert på data i eventene som genererte alerten. De grønne feltene er data som enten arves fra, eller tilegnes fra event reglene. Et eksempel på en Alert med ferdig utfylte felter: 111

115 Figur 49 viser eksempel på Alert med ferdig utfylte felter Alle alerter legges inn i alert tabellen [alert] og på nesten samme måte som med event tabellen, vil en alert som er satt til Closed bli slettet etter å ha vært urørt i 90 dager av renseverktøyet table cleaner 35 (ServiceNow, udatert-s). Alertene er ment til å brukes som varslinger innad i Event Management, men fordi vi bestemte oss for å gi direkte beskjed til butikkeier, opphøyer vi hver enkelt alert til en Incident med en gang. For å gjøre dette, genererer vi en Task 36. For å oppnå dette, har vi tre Alert regler: Coolify Minor Incident Coolify Major Incident Coolify Critical Incident 35 Verktøy under Data Management som automatisk sletter records fra tabeller for å motvirke ukontrollerbar mengde data. 36 En oppgave som må håndteres av enten en bruker, eller systemet. Incident og Change er to tabeller som arver fra Task tabellen og 112

116 Hensikten med disse å fange opp alertene og eskalere de til Incidents basert på Task templates. Dette gjøres ved følgende filtrering: Figur 50 viserer filtrering i ServiceNow Altså brukes samme prinsipp som på Event reglene, Alertene filtreres basert på at de kommer fra Coolify og hvilken Severity Alertene har. Dersom disse kravene blir møtt generes Incidents med en gang basert på forhåndsdefinerte Task templates 37. Merk at alle alerts sendt fra Coolify med disse Severity verdiene vil generere Incidents Incidents For generering av Incidents har vi opprettet tre task templates som spesifiserer de feltene som vil være like for alle incidentene som følger: Felt Verdi Urgency Impact Short description Assignment Group Category Minor: Medium Major: Medium Critical: High Minor: Medium Major: High Critical: High Passende beskrivelse av incidenten Coop Admin Coolify Ved å sette Urgency og Impact setter vi graden av alvorlighet til Incidenten etter følgende mønster: Impact Urgency Priority 37 En forhåndsdefinert mal for hvordan Incident skal se ut. 113

117 1 - High 1 - High 1 - Critical 1 - High 2 - Medium 2 - High 1 - High 3 - Low 3 - Moderate 2 - Medium 1 - High 2 - High 2 - Medium 2 - Medium 3 - Moderate 2 - Medium 3 - Low 4 - Low 3 - Low 1 - High 3 - Moderate 3 - Low 2 - Medium 4 - Low 3 - Low 3 - Low 5 - Planning Utover disse feltene vil også alerten og CI en bli bundet til incidenten av systemet, slik at man ser hva som forårsaket incidenten. Store Manager som er eier av butikken vil bli tildelt Incidenten, i tillegg til at alle Coop Administratorer får tilgang. Mer om dette under Saksbehandling. En ferdig incident i systemet vil til slutt se ut som følger: Figur 51 viser en ferdig utfylt incident Tilgangsrettigheter: User Roles og User Groups For å forsikre at ingen uautoriserte personer behandler Incidents, og at alle som bør få informasjonen får den, har vi definert User Roles og User Groups for forbedret 114

118 varsling og saksbehandling. Merk at disse ikke er en del av Event Management, men heller en out-of-the-box funksjonalitet på ServiceNow plattformen. Helt konkret har vi definert følgende roller: Coop Administrator Coop Store Manager User Og følgende User Groups: Coop Administrator Coop Store Manager For å tildele butikkeiere og administratorer riktig tilgangsrettigheter og roller automatisk, legger vi de til i riktig User Group når de registreres som enten Store Manager eller Coop Administrator. Vi har allerede definert de respektive rollene og rettighetene hver brukergruppe får tildelt, så vi trenger bare å legge brukeren til i en gruppe. Dette gjøres med følgende skript: Code / Business Rule: Set Store Manager Group 1. (function executerule(current, previous) { 2. var rec1 = new GlideRecord('sys_user_grmember'); 3. rec1.initialize(); 4. rec1.user = current.store_manager; 5. rec1.group.setdisplayvalue('coop Store Manager'); 6. rec1.insert(); 7. })(current, previous); Vi oppretter et GlideRecord objekt av tabellen Group Member og oppretter en record i denne tabellen der vi setter butikkeier sin gruppe til å være Coop Store Manager. Roller blir automatisk tildelt ettersom alle som legges inn i denne gruppen får denne rollen av systemet, og brukeren er klar til å begynne med en gang. Vi har også en nærmest identisk business regel for Coop Administratorer, hvor brukeren legges inn i Coop Administrator gruppen. Videre har vi to tilsvarende business regler i det tilfelle en bruker blir fjernet fra databasen, som fjerner rollen til brukeren, og fjerne de fra gruppen hen var i Kommunikasjon: Varsling Når en incident blir generert vil det sendes ut eposter til alle personer som ble tildelt incidenten, gitt at det er oppgitt en epost på brukeren i ServiceNow. Dette skjer via et allerede eksisterende script i ServiceNow, som lytter på alle incidents og sender s med varsler. 115

119 Saksbehandling Vi nevnte kort i delen om Incident at vi tildeler incidents til både én person og en gruppe, respektivt en Store Manager og Coop Administrator gruppen. I hovedsak vil det være Store Manageren som ble tildelt incidenten sitt ansvar å oppdatere og lukke incidenten, men Coop Administratorer kan også håndtere de ved behov Business regel: Tildeling av Incident til Store Manager For å tildele alle Incidents til Store Manager lagde vi følgende business regel: Code / Business Rule: Assign store manager to Incident 1. (function executerule(current, previous) { 2. var device = new GlideRecord('x_opn_coolify_device_ci'); 3. device.addquery('sys_id', current.cmdb_ci); 4. device.query(); 5. if(device.next()) { 6. current.setvalue('assigned_to', device.cooler.store. store_manager.store_manager.sys_id); 7. current.update(); 8. } 9. })(current, previous); Her lytter man på Incident tabellen og venter på at records enten legges inn, eller blir oppdatert. Når dette skjer tilegnes riktig Store Manager til Incident ved hjelp av dotwalking fra Incidenten sin cmdb_ci-objekt (Device CI). Til slutt vil det være riktig butikkeier og administrator som kan behandle butikkens Incidenter, ettersom vi også har tilpasset tilgangsrettigheter. Når incidentene er generert i systemet, og alle brukere er varslet, må incidentene manuelt behandles videre. Dette er fordi det er dårlig praksis at incidents behandles automatisk, da de ofte tar for seg alvorlige problemer. I vårt tilfelle kan det gå utover holdbarheten på maten, da den i verste fall må kastes av de ansatte. I det en incident er kartlagt, og er klar til lukking, kan de enten lukkes med Closure Information feltene fylt ut, eller så kan de videreføres til enten et Problem, som vil stå i systemet som et kjent problem man ikke får gjort noe med (ServiceNow, 2013), eller til et Change Request, dersom for eksempel en fryser er ødelagt og trenger service (ServiceNow, 2017b). Dette har ikke vi fått implementert ordentlig, men vi drøfter videre potensiale under 8.0 Fremtidig arbeid Frontend I frontend delen vil vi først ta for oss det generelle ServiceNow instance utseende, hvordan man manøvrerer rundt i denne, samt hvordan man får tilgang til de forskjellige delene av applikasjonen fra fra instancen. 116

120 Brukergrensesnitt: UI16 ServiceNow plattformen sitt grensesnitt omtales bare som User Interface (UI), og får versionsnavn basert på hvilket år UI en ble oppdatert (UI16, UI15, UI11 osv.) (ServiceNow, udatert-u). Vi ble pålagt av arbeidsgiver å ta i bruk UI16, da dette er den mest oppdaterte og brukervennlige versjonen. En stor fordel vi merket med dette underveis er at nesten hvilken som helst ServiceNow konsulent kan lett se over vår applikasjon og gi oss råd på veien da de er kjent med utviklingsmiljøet. UI16 er i skrivende stund den siste versjonen av grensesnittet til ServiceNow. Ny funksjonalitet som ble introdusert i denne versjonen var blant annet at forms blir oppdatert i sanntid, man kan se hvilke andre brukere som er på samme sted som deg og applikasjons navigatoren ble renovert (ServiceNow, udatert-u). UI16 består av følgende tre hoveddeler: Banner frame Ligger på toppen av alle sidene i instancen. Har funksjonaliteter som blant annet søking etter tekst i flere applikasjoner, muligheten til å imitere andre brukere (som har like eller færre rettigheter som din egen bruker) etc. Application navigator Content Frame Viser informasjon som lister, formas, dashboards og widgets. Hva som vises velges i application navigator. (ServiceNow, udatert-u) (ServiceNow, 2015c) Figur 52 viser ServiceNow sitt brukergrensesnitt og navnet på de ulike delene 117

121 Vi referer mye til Application Navigator da det er her man får tilgang til all informasjon og alle applikasjoner, som nevnt tidligere. Altså er det denne vi bruker når vi skal hente fram både informasjonen til Coolify og dashboardet Performance Analytics: Dashboard Dashboardets hensikt er å visuelt fremstille relevant data basert på de ulike brukergruppene; Coop administrator og butikksjef. Ettersom de ulike brukerne har forskjellige behov og ønsker når det kommer til hva som er relevant, brukte vi mye tid på å sette opp et eget dashboard for hver brukergruppe Lage en skisse Vi startet først med å lage en skisse på hvordan dashboard kommer til å se ut, en for administrator og en for butikksjef. Vi diskuterte grundig hva som er viktig for brukere, og hvor widgetene skal plasseres i dashboardet. Coop ønsker å ha et dashboard for Coop administrator og et for butikksjefer. For administrator er det viktig å få oversikt over alle butikker for å se om noen har alvorlige problemer. For butikksjefer er det viktigste å se status på inventar i egen butikk samt utvikling over tid og om noen av modellene butikken har kjøpt inn presterer bedre enn andre. Figur 53 viser en skisse av hvordan vi tenkte grensesnittet skulle se ut for en Coop administrator 118

122 Figur 54 viser en skisse av hvordan vi tenkte grensesnittet skulle se ut for en Coop administrator Opprett dashboard og sett opp widgeter Dashbordet ble satt sammen etter ønsker fra Coop. Widgetene vi har tatt i bruk har vi valgt ut fra vurderinger om hva som skal visualiseres og presenteres. 119

123 Figur 55 viserer utklipp av grensesnittet for en Coop butikksjef I figur 55 viser vi en butikksjef sitt dashboard. Her vises antall incidenter i butikken og den presenteres med Single Score. Rett ved siden av incident har vi valgt å bruke et linjediagram som viser incidenter opprettet over tid. Under denne raden vises samme data for Eventer tilhørende butikken. Nederst på dashbordet er en liste med oversikt over kjølere i butikken som viser navn på kjøler, siste rapporterte temperatur, modell, hvilken type kjøler maskinen er og antall incident som har kommet fra den. Single Score: Grafisk fremstilling av en teller Line graph: En graf som kan presentere data over tid i en graf List: Presentasjon av data fra en tabell i en liste Deling av dashboard For å oppnå egendefinerte dashboard implementerte vi de to forskjellige brukergruppene: Coop Admin = Videreutvikler og oversikt over alle butikker med tilhørende Incidents. Store Manager = Får alle Incident tilhørende sin butikk. 120

124 SEVERITY KJØLESKAP FRYSER Minor Sjekk rutiner Major Sjekk rutiner Critical Sjekk rutiner +4 til til til til -7 over +12 under -7 Coop administrator og butikksjef krever i tillegg roller for å kunne lese, opprette, redigere, slette eller dele dashbord i Performance Analytics. Administrator skal ha alle rettigheter i Performance Analytics, men butikksjef skal kun se på dashbordet. Administrator fikk pa_admin, og butikksjef fikk pa_viewer som tillegg til deres roller. Tabellen nedenfor viser hvilken rettigheter brukere har i Performance Analytics. ROLLE LESE OPPRETT REDIGER SLETT DELE Coop Admin (pa_admin) Coop Butikksjef (pa_viewer) Ja Ja Ja Ja Ja Ja Nei Nei Nei Nei 6.5 Installasjon og vedlikehold I denne delen av rapporten vil vi gå gjennom hvordan man laster ned Coolify på en ServiceNow instance og hvordan man klargjør Coolity-enheten for første gang. Vi vil også gå igjennom systemkrav, samt hvordan man vedlikeholder både Coolity og Coolify Systemkrav Coolify (Applikasjon) For å kunne bruke Coolify applikasjonen må man ha tilgang til en ServiceNow instance med tilhørighet til Coop Norge SA. Dette er fordi man må ha tilgang til Coop sitt Application Repositoriet i ServiceNow. Coolify er utviklet på release Istanbul, så instancen må være oppdatert til versjon Istanbul eller nyere. Videre må pluginene Event Management og Performance Analytics være lagt til i instancen. Dersom disse ikke er tilstede vil applikasjonen ikke fungere som den skal, da den ikke har tilgang til databasene og funksjonaliteten tilhørende disse. 121

125 Utover dette kreves kun en nettleser installert på PCen og tilkobling til internett. ServiceNow er en skyplattform og kan kjøre på blant annet Internet Explorer, Microsoft Edge, Google Chrome, Opera, Safari eller Firefox Coolity (Prototypen, IoT-enhet) For at Coolity-enheten skal kunne sende temperaturer til Coolify må den ha tilgang til strøm (batteri) og være tilkoblet WiFi med internett. Coolity-enheten krever at Coop butikkene sitt WiFi er kryptert med en av følgende metoder: WEB, WPA eller WPA2. WPA2 er anbefalt. Avstanden mellom Coolity-enhetene og ruteren bør være maksimalt 150 meter Installasjon Installering av programvare til Coolity Installasjon i denne sammenhengen er å laste opp programmet (sketch) på en NodeMCU. For å kunne å gjøre det krever at datamaskinen har Arduino IDE installert. 1. Last ned en kopi av koden til maskinvaren og legg det på et passende sted. 2. Åpne kildekoden i arduino IDE. For at man skal kunne laste programmet opp på NodeMCU må programmet være riktig konfigurert. a. Trykk på Tools på hovedmenyen. b. Velg Board og velg Boards Manager c. Skriv inn i søkefeltet ESP8266 og installer denne pakken. Figur 56 viserer Arduino IDE som installerer ESP8266 sin WiFi-bibliotek 3. Sette korrekte miljøvariabler a. Board: NodeMCU 1.0 (ESP-12E Module) b. CPU Frequency: 80 MHz (Default) c. Flash size: 4M (3M SPIFFS) (Default) d. Upload speed: e. Port: usb porten Coolity er koblet til 122

126 Figur 57 viserer Arduino IDE og installasjonsmiljø med satte variabler 4. Etter punkt 3. sørg for at Coolity er koblet til pc og trykk på pil (høyre pil) for å laste opp programmet til Coolity. 5. Følger med på installasjonsprosessen siden installasjonen kan være vellykket eller mislykkes. a. I tilfelle vi får feilmelding ved opplasting av programmet vil feilmelding skrives ut. i. Dersom Coolity nekter å laste opp programmet. Trykk og hold på Flash knappen i det man kobler enheten til USB. ii. Dersom Arduino IDE ikke finner porten må man sørge for at miljøvariabler er satt riktig (punkt 3.) 6. Trykk på serial monitor for å følge med på statusen om alt er riktig uten feil og om Coolity har koblet til internett og ServiceNow sitt REST API. a. Dersom Coolity ikke er koblet til internett, dobbeltsjekk at SSID og passord er riktig. b. Dersom Coolity er koblet til internett, men har ikke klart å sende data ServiceNow plattformen kan det være mange mulige grunner. Det kan være at endpoint er ugyldig, ugyldig fingerprint eller ugyldig token. Sjekk HTTP response status code. (ServiceNow, 2016c) Status Code Message Details 200 Success Success with response body. 123

127 201 Created Success with response body. 204 Success Success with no response body. 400 Bad Request The request URI does not match the APIs in the system, or the operation failed for unknown reasons. Invalid headers can also cause this error. 401 Unauthoriz ed The user is not authorized to use the API. 403 Forbidden The requested operation is not permitted for the user. This error can also be caused by ACL failures, or business rule or data policy constraints. 404 Not found The requested resource was not found. This can be caused by an ACL constraint or if the resource does not exist. 405 Method not allowed The HTTP action is not allowed for the requested REST API, or it is not supported by any API Generere ny Access Token for Coolity Brukeren må ha admin rollen for å kunne generere Oauth 2.0 access token for Coolity. Fremgangsmåten for å opprette ny acces token består av to deler. Første delen er å sette opp Oauth 2.0 access token i Servicenow og andre delen er å få access med Postman. 124

128 Steg i ServiceNow: 1. Logg inn på ServiceNow instancen (Administrator) 2. Naviger til System OAuth og velg Application Registry 3. Ved Application Registry trykk New 4. Velg Create an OAuth endpoint for external clients 5. Fyll inn feltene (La Client Secret være blank) 6. Trykk Submit Figur 58 viserer Application Registry og skjema for å fylle ut felter til OAuth Steg i Postman REST Client: 1. Opprett ny request 2. Velg POST som HTTP-metode og sett inn end-point (url til data tabellen). 3. Trykk Body og velg x-www-form-urlencoded 4. Fyll inn informasjonen fra Servicenow OAuth. a. grant_type b. client_id c. client_secret d. username e. password 5. Trykk Send a. Dersom alt er vel lykkes Status 200 OK skal man få token, token levetid og en refresh token. 125

129 b. Dersom vi får en annen status code enn 200, vil det si at vi mislyktes med å hente token. Da må det dobbeltsjekkes om grant_type, client_id, client_secret, username og password stemmer. Figur 59 viser utsnitt av Postman og bruk Installering av ServiceNow applikasjonen: Coolify Når man skal installere ServiceNow applikasjoner innenfor sitt eget selskap bruker man noe som heter Application Repository. Application Repository referer til området innenfor ServiceNow hvor man som administrator kan dele applikasjoner med andre innenfor samme selskap, slik at de kan installere, eller deploy, applikasjonen på sin egen produksjonsinstance. Det vil si at alle applikasjoner som deles vil være tilgjengelige for alle instancer som er tildelt samme selskap (ServiceNow, udatertae). Prosedyre: 1. Logg inn i ServiceNow instancen hvor applikasjonen skal lastes ned. Brukeren må ha rolle som Administrator. 2. Forsikre deg om at alle systemkravene (6.5.1 Systemkrav) er oppfylt. 3. Naviger til System Applications > Applications i navigasjonsbaren. 4. Klikk på Downloads. 5. Finn Coolify i listen, og trykk på Install knappen. a. Dersom Install knappen er grået ut, vil det trolig bety at en annen installasjon allerede pågår. Husk at systemet bare tillater en installasjon omgangen. 126

130 6.5.3 Vedlikehold Oppdatering av programmet til Coolity (WiFi SSID, passord og token) Programmet som er lastet opp i Coolity-enheten krever oppdatering dersom Coops WiFi SSID, passord eller Access Token i ServiceNow endres Endre WiFi SSID og Passord Oppdatering av WiFi SSID og passord gjøres ved å endre på følgende kode-linje (velg easter) Code 58. // Connect ESP8266 with to an Access point 59. WiFiMulti.addAP("Nattaphong-iPhone","nknn1924"); Endre intervall på temperaturmåling Endring av intervall på temperaturmåling kan gjøres på følgende kode-linje. Tallet 15 i begynnelsen av regnestykket indikerer antall minutter. Code 124. //Deep sleep with a 15 minute interval 125. ESP.deepSleep(15*60* , WAKE_RF_DEFAULT); Endre Access token Oppdatering av ny Access Token gjøres ved å endre på følgende kode-linje Code 76. http.addheader("authorization","bearer 2nIjIGX7ml3ruXfyvzkS7erMXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX3M_CsHmN8tIZdFp VxHHsiziUw"); Endre REST API endpoint og Domain Fingerprint REST API endpoint er hvor dataene skal lagres og Domain Fingerprint er unik id for hvert domainet navn. Oppdatering av en REST API endpoint og Domain fingerprint kan gjøres ved å endre på følgende kode-linje Code 74. http.begin(" :0A:AE:XX:XX:XX:XX:XX:XX:XX:XX:XX:EC:17:FB:9E:BB"); 127

131 Sørger for at Domain fingerprint stemmer over REST API endpoint. Dette kan gjøre vet å gå inn på Kopier og lim inn REST API endpoint i søkefeltet og trykk Fingerprint Site. Figur 60 viser Arduino IDE som viser hvor REST API endpoint, domain fingerprint og access token ligger i koden 6.6 Brukermanual Hensikten med denne manualen er å gi alle brukere og interessenter en innføring i alle bruksområder av applikasjonen i sin helhet. Manualen bør spesielt anvendes dersom brukeren opplever at applikasjonen er vanskelig å bruke. Den kan også brukes til opplæring av brukere eller nye konsulenter, om de så skal prøve ut, teste eller videreutvikle applikasjonen. Vi vil først gi veiledning av prosessen av å sette opp Coolity-enheten, for å så forklare alle bruksområder til Coolify-applikasjonen Oppsett av Coolity Installasjon/flashing Installasjon i denne sammenhengen er å laste opp programmet opp på Colity. For å kunne å gjøre det krever at datamaskinen har Arduino IDE installert. 1. Laste ned eller kopiere kildekoden til hardware delen og legge den på et passende sted. Vi anbefaler å laste ned til /Document/Arduino (på mac). 128

132 2. Åpne kildekoden på arduino IDE. For at man skal kunne laste programmet til NodeMCU krever at arduino IDEén riktig konfigurert. a. Trykk på tools på hovedmenyen. b. Velg board og velg Boards Manager c. I søkefeltet skriv inn ESP8266 og installere pakken 3. Sette korrekte miljøvariabler a. Board: NodeMCU 1.0 (ESP-12E Module) b. CPU Frequency: 80 MHz (Default) c. Flash size: 4M (3M SPIFFS) (Default) d. Upload speed: e. Port: usb porten Coolity er koblet til 4. Etter punkt 3. sørg for at Coolity er koblet til pc og trykk på pil (høyre pil) for å laste opp programmet til Coolity. 5. Følger med på installasjonsprosessen hvor installasjonen kan være vellykket eller mislykkes. a. I tilfelle vi får feilmelding ved opplasting av programmet, les hva feilmelding inneholder. i. Dersom chippen nekter å laste opp programmet. Trykk og hold på Flash knappen før å koble usb til enheten. ii. Dersom Arduino IDE finner ikke porten. Sørge for at miljøvariabler er satt riktig (punkt 3.) 6. Trykk på serial monitor for å følge med på statusen om alt er riktig uten feil og om Coolity har koblet til internett og servicenow plattformen. a. Dersom IoT enheten er ikke koblet til internett, dobbelt sjekke om internett ssid og passord er riktig. b. Dersom Coolity er koblet til internett, men har ikke klart å sende data servicenow plattformen kan det være mange mulige grunner. Det kan være at endpoint er ugyldig, ugyldig fingerprint eller ugyldig token. Sjekk HTTP response status code Hente ChipID For å finne ut den unike ChipID til hver enkelt Coolity ved å følge på Serial monitor til Arduino IDE. Etter programmet er lastet opp, så vil Coolity begynne å kjøre. På serial monitor kan vi følge med på hva Coolity gjør. Først Coolity gjør er å koble seg til internett. Etter at den har klart å koble seg til internett vil den begynne å sende temperaturer til Servicenow. 129

133 Men her er vi mest interessert i å finne chip ID til Coolity. På venstre siden er koden som finner chip id og skrive på skjermen. På høyre delen av skjermdumpen kan vi se hvilken id chippen har. Figur 61 viser Arduino IDE og hvor man kan hente Chip ID Lage Access Token Det består av to hoveddeler når det gjelder å lage Access Token. Først er å sette opp Oauth 2.0 til applikasjonen i ServiceNow og den andre delen er å generere access token. Å sette opp Oauth 2.0 gjøres i ServiceNow, men å generere access token gjøres med Postman ServiceNow 1. Logg inn på Servicenow instancen (Administrator) 2. Naviger til System OAuth og velg Application Registry og trykk New 3. Velg Create an OAuth endpoint for external clients 4. Fyll inn feltene (La Client Secret være blank) 5. Trykk Submit Postman 1. Opprett ny request 2. Velg POST som HTTP-metode og sett inn end-point (url til data tabellen). 3. Trykk Body og velg x-www-form-urlencoded 4. Fyll inn informasjonen fra Servicenow OAuth. a. grant_type b. client_id c. client_secret d. username e. password 130

134 5. Trykk Send a. Dersom alt er vel lykkes Status 200 OK skal man få token, levetid og en refresh token. b. Dersom vi får andre statuskoder enn 200 betyr det at vi mislykkes å hente token, kontroller at grant_type, client_id, client_secret, username og password stemmer Oppsett av Coolify Etter installasjon av applikasjonen vil applikasjonen Coolify ligge i instancen og være klar til bruk. Vi minner om at applikasjonen krever at pluginene Event Management og Performance Analytics må være aktivert for å få full funksjonalitet. Coolify vil fungere uten Performance Analytics, men da må man opprette egne widgets eller rapporter for å fremstille data som blir samlet Brukerregistrering Som tidligere nevnt har vi satt opp to brukerroller for løsningen vår: Store Manager Coop Administrator En Store Manager skal kunne se og gjøre endringer på ting som som tilhører vedkommendes egen butikk. Registrere nye enheter, kjølere og få et overblikk over hendelser som foregår i butikken. I applikasjonen vår har vi satt opp disse to rollene under Access Control og gitt de tilhørende rettigheter som tillater de å utføre enkelte konfigurasjoner, basert på rolle. Alle brukere av en ServiceNow Instance må først registreres i ServiceNow sin egne User-tabellen. Dette gjøres ved å gå inn på User under User Administration - modulen i Instancen. Her fyller man ut en form med all personalia. Det er anbefalt å krysse av Password needs reset, fordi da må brukeren lage et eget passord ved første innlogging. Dette for å fremme sikkerheten til brukeren ved vanlig bruk. 131

135 Figur 62 viser utklipp av brukerregistrering i ServiceNow Når en bruker er registrert, må vedkommende legges inn i enten Store Manager eller Coop Administrator tabellen i vår applikasjon. Dette gjøres ved å gå inn i applikasjonsnavigatøren å søke etter den respektive brukerrollen. Figur 63 viser skjermutklipp av Applikasjonsnavigatør og oversikt over butikkeiere Her er en oversikt over alle brukere som er registrert som Store Manager. Det fulle navnet på butikkeieren, epost og mobilnummer er relevant informasjon som vises i denne visningen. For å legge til en bruker her, trykker man på knappen New og går 132

136 videre til visning under. Fyll inn navnet til brukeren du har registrert, så vil ServiceNow søke gjennom alle brukere og finne riktig person utifra navnet. Hvis personen ikke eksisterer må man registreres først. Figur 64 viser utklipp av søk etter person som skal registreres som butikkeier Grunnen til denne tabellen, er at vi ønsket et lett sted å samle alle butikkeiere/coop administratorer i en pen og oversiktlig tabell, der vi kan legge til egne business regler for å utvide funksjonaliteten ved registrering av en butikkeier/admin. Vi har lagd to business regler for hver tabell; en som automatisk tilegner personen riktig brukerrettigheter, basert på rolle og en som fjerner rettighetene, hvis de blir fjernet fra tabellen Registrere ny Store Når en Store Manager er registrert, kan vi gå videre til å registrere en butikk. For å finne butikkoversikten, går man inn på modulen Stores under Coolify fra applikasjonsnavigatøren. Her står butikknavn, hvilken butikkeier som står ansvarlig for butikken og antall Incident som tilhører butikken. Figur 65 viser utklipp av Stores med Tabell 133

137 Inne på den nye visningen må vi fylle ut navn på butikken, finne butikkeier Ola Nordmann og fylle ut Location - som er en referanse til Location tabellen der man kan fylle ut informasjon om lokasjonen. Til slutt trykker man på Submit og lagrer butikken. Figur 66 viser utklipp av skjema for registrering av butikk Registrere ny Cooler Når butikkeier og butikk er registrert, må vi legge til kjøleskap og frysere som det skal måles temperatur av. Dette er en operasjon både en Store Manager og Coop Administrator kan utføre. Før man registrerer en Cooler, er det nyttig å sjekke modulen Models og se om kjølerens modell er registrert i databasen. Riktig modell er nødvendig for at applikasjonen skal fungere ordentlig, og er nyttig for å kunne se hvilke modeller som presterer best over tid. Figur 67 viser utklipp av Model med tabell Hvis modellen ikke ligger i denne tabellen, må den registreres med all informasjon som det spørres om i skjemaet. Etter dette går man videre til Cooler som inneholder informasjon om hvilken butikk den er plassert i, modell, type kjøler, hvor mange Incidents den har forårsaket og temperatur. 134

138 Figur 68 viser utklipp av Cooler med tabell For å registrere en ny kjøler, trykker man på New og fyller ut CoolerID (En ID som bygges opp av butikknavn og et nummer), modell og hvilken butikk den er plassert i. Figur 69 viser utklipp av Cooler registrering Registere ny Coolity Nå har vi registrert en Cooler, som ligger i en Store som styres av en Store Manager. Det som gjenstår nå er å registrere selve Coolityen. Coolityene er oppført i Device CI tabellen og man registrerer en enhet ved å trykke New. Her står informasjon om ChipID, nåværende temperatur, hvilken kjøler og butikk Coolityen er plassert i, beskrivelse av plassering, status, antall Incidents og når siste temperaturmåling ble foretatt. 135

139 Figur 70 viser utklipp av tabellen Device CI Ved registrering av en ny Coolity, må feltene Name og ChipID være identiske og tilsvare ChipID som må per dags dato må hentes manuelt fra hver enkelt enhet som registreres. Velger Cooler som enheten er plassert i, sett Category til Coolify, installasjonsdato for når kjøleren ble installert og til slutt en kort beskrivelse om lokasjonen til enheten. Figur 71 viser utklipp av skjema for registrering av Device CI Når enheten er registrert, vil man nå kunne koble enheten til strøm og laste opp data til Measurement tabellen. Plattformen vil automatisk finne riktig Coolity utifra Device CI-tabellen og opprettholde logikken. Dessverre er det litt tungvint å registrere enheter ut ifra ChipID som lastes opp til REST API et. Det optimale hadde det vært å gjøre dette automatisk, noe vi snakker mer om under fremtidig arbeid Dashboardet Dashboard består av flere widgeter, og en widget kan brukes til å presentere data på forskjellige måter. Dashboard gir brukere oversikt over dataene, og widgetene kan trykkes for å komme direkte til datakilden. 136

140 Dashboard for butikksjef Dashboard for butikksjefen er et nyttig verktøy. Det er ikke bare for å få ha oversikt over temperaturer til kjølere, men det kan også brukes til å finne feilen og fikse. Når butikksjef trykke på en Store incident widgeten vil brukeren videreføre til incident tabellen. Figur 72 oversikt over incident Nå er butikksjefen i incident tabellen og her ligger lister med incidentene som har blitt opprettet. Nå kan butikksjefen se incidenten har blitt opprettet og se hvor krise incidenten er. Butikksjefen kan få mer detaljert informasjon om en incident, ved å trykke på incident number. Figur 73 tabell for incident Når butikksjef trykke inn på en incident, vil butikksjefen videreføre inn i detaljert nivå til en incident. Butikksjefen kan se hvor krise incidenten er og hva som må gjøres for å løse opp problemet. Dersom problemet har blitt løst, kan butikksjefen trykke på Resolve for å registrere at problemet har blitt løst. 137

141 Figur 74 viser en valgt incident Dashboard for Coop administrator Det er enkelt for administrator å holde oversikt over butikkene med dashboard. Administrator kan følge med på hvor mange incident finnes totalt, og hvilken butikk som har flest. Administrator kan trykke på incident widgeten for å komme direkte til incident tabellen. Administrator har også muligheten til å filtre incidenter etter en bestemt butikk eller person. Dette gjøres med filtering funksjonen i ServiceNow Filtrering av incident Eksempel på filtrering: Administrator ønsker å finne incidenter som til høre Edvarda Eriksen. 1. I navigasjonsbaren, gå til Performance Analytics > dashboard. 2. Velg admin dashboard. 3. Trykk på incident widgeten. 4. Trykk på filtrering knappen som ligger oppe på venstre siden av skjermbildet. 5. Velg Assigned to.first.name -> start with -> og skrive inn Edvarda 6. Trykk Run. 138

142 Figur 75 viser sorteringsmuligheter og resultat av sortering Deling av dashboard Administrator har også oppgaven til å opprette dashboard og administrere tilgang for butikksjefer. Deling av dashboard til butikksjef kan gjøres som følger: 1. I navigasjonsbaren, gå til Performance Analytics > dashboard. 2. Velg dashboard som skal deles til butikksjef, den ligger oppe på venstre siden av dashboard. 3. Trykk sharing knappen oppe på høyre siden. 4. Trykk add groups, users and roles. 5. Skrive inn x_opn_coolify.store_manager 6. Velg Can view som access 7. Trykk Invite Figur 76 delingsmuligheter Kontroll av temperaturovervåking Prate om temperaturer registreres i Measurements, Eventer genereres, Alerts og Incidents etc. 139

143 6.6.5 Event Management Endre grenseverdier for oppretting av events (Business Rule) I systemet i dag vil alle temperaturmålinger som overstiger grenseverdiene i kjøleskap og frysere, respektivt 4.5 og grader, generere events i Event [em_event] tabellen. Dette kan endres i Business reglene som følger: 1. I navigasjonsbaren, gå til System Applications > Studio. 2. I Load Application pop-up vinduet, trykk på Coolify. 3. I Application Explorer, gå til Server Development > Business Rules. 4. Trykk på enten Verify Freezer Temperature eller Verify Fridge Temperature, basert på om du skal endre grenseverdien for kjøleskap eller frysere. 5. Trykk på Advanced taben. Figur 77 viser hvordan man endrer grenseverdier i studio 6. I Condition-feltet, endre verdien som kontrolleres til den ønskede verdien. Figur 78 advanced-fanen til figur Endre terskel for opprettelse av Alerts (Event Rule) Som nevnt i produktdokumentasjonen vil eventer opprette alerter etter fire tilfeller av Severity minor, to av major eller en critical, innenfor en forhåndsdefinert tidsperiode. Disse tersklene kan endres i Event Rulene som følger: 1. I navigasjonsbaren, naviger til Event Management > Rules > Event Rules. 140

144 2. Finn Event Rulen du ønsker å endre: Coolify Minor Alert Threshold: Dersom fire eventer av denne typen genereres innenfor tidsperioden av seks mulige, skal en Alert genereres. Coolify Major Alert Threshold: Dersom to eventer av denne typen genereres innenfor tidsperioden av tre mulige, skal en Alert genereres. Coolify Critical Alert Har ingen threshold for denne regelen, ettersom hvis temperaturen er kritisk skal en Alert genereres med en gang. 3. Dersom Event Rulen ikke er i Advanced Mode, huk av Advanced. 4. Trykk på Threshold Figur 79 Threshold for Events 5. Endre enten Count (hvor mange tilfeller som skal telles) eller Over(seconds) (tidsperiode i sekunder). Merk at tidsperioden bør stemme overens med intervallene satt på Coolity-enheten. Dette må desverre regnes ut manuelt. Inkluder et par sekunder ekstra per intervall da temperaturmålingene ikke alltid kommer nøyaktig på sekundet. Eksempel: Temperaturmålinger hvert 15. minutt (900 sekunder). Tell fire på tiden seks kommer inn blir da 900*6 = 5400 sekunder, der vi legger til 100 ekstra sekunder (5500 sekunder) Endre feltene automatisk fylt ut i incidents (Task Template) 1. I navigasjonsbaren, naviger til Event Management > Settings > Task Templates. 2. Velg en av Task Templatene, basert på hvem du vil endre: a. Coolify Minor Incident b. Coolify Major Incident 141

145 c. Coolify Critical Incident 3. Under Template, endre alle felter etter ønske. 142

146 Innholdsfortegnelse: Testdokumentasjon 7.0 Testdokumentasjon Testing av prototypene Hypoteser Testing i butikk Måleinstrumenter Resultater Testing av applikasjon Systemoversikt Fremgangsmåten Testresultater Testobjekter Testnivåer

147 7.0 Testdokumentasjon Nedenfor presenteres tester og resultater av både prototypen vår, Coolity, og applikasjonen vår i ServiceNow, Coolify. 7.1 Testing av prototypene I denne delen av rapporten vil vi gå igjennom hypoteser og testing av Coolity 1.0. Vi vil presentere måleinstrumenter som brukes av Coop og mattilsynet for måling av kjølestatistikk, slik at vi på den måten kan vite hvor nøyaktig vår egen Coolity 1.0 måler er. I denne delen av oppgaven vil vi henvise til de ulike Coolity 1.0 modellen A, B og C etter sine respektive ChipID-navn i ServiceNow-applikasjonen: NAVN PROTOTYPE SERVICENOW CHIP-ID Coolity 1.0A Coolity 1.0B Coolity 1.0C 19438E 13E1D2 801B8D Hypoteser Hypotesene våre er antagelser av løsningen. Det vil si at vi hadde på forhånd gjort noen antagelser om hvordan vi ønsket at prototypen skulle være. Den måtte blant annet være like sensitiv til måling av temperatur som en industriell temperaturmåler og den måtte tåle flere kuldegrader. Nedenfor er den komplette listen over hypoteser, der h1 er ønsket hypotese, mens h0 vil være det motsatte. Hypotese ServiceNow ID: 19438E ServiceNow ID: 13E1D2 ServiceNow ID: 801B8D h1 Vil vise like temperaturmåling som Comark C26. Vil vise like temperaturmåling som Comark C26. Vil vise like temperaturmåling som Comark C26. h0 Vil differensierer fra Comark C26 sine temperaturmålinger. Vil differensierer fra Comark C26 sine temperaturmålinger. Vil differensierer fra Comark C26 sine temperaturmålinger. h1 Tåler temperaturer under -20 C. Tåler temperaturer under -20 C. Tåler temperaturer under -20 C. 144

148 h0 Gir avvik eller slutter å fungere ved temperaturer lavere enn -20 C. Gir avvik eller slutter å fungere ved temperaturer lavere enn -20 C. Gir avvik eller slutter å fungere ved temperaturer lavere enn -20 C. h1 Mister ikke nettilkobling. Mister ikke nettilkobling. Mister ikke nettilkobling. h0 Mister nettilkobling. Mister nettilkobling. Mister nettilkobling Testing i butikk Mellom 27. mars og 7. april startet vi testingen av Coolity i butikk. Vi hadde fått tillatelse fra Coop sentralt til å benytte oss av Coop Mega Sjølyst for å teste prototypene i forskjellige kjøler. Til å begynne med måtte vi vite hvilke kjølere vi ønsket å teste og hvorfor. Samtidig måtte vi vite hvordan temperaturene måles i diverse kjølere når Coop måler temperaturen selv eller når mattilsynet er innom og gjør det. For å finne ut av disse rutinene spurte vi de ansatte som til vanlig benytter seg av temperaturmåleren Comark C26 med trådføler om hvordan de måler temperaturene. Vi oppdaget at de til frysevarer plasserte måleren mellom varene for å finne riktig temperatur på varen og at de til varer i åpne kjøledisker (uten dør) plasserte måleren på det høyeste / ytterste punktet der varen er mest utsatt for varm luft. En av hypotesene våre var at Coolity ville tåle kuldegrader, og det var derfor en selvfølge at Coolity temperaturmålerne ble testet i frysere. En annen hypotese omhandlet hvor tilpasningsdyktig og responsiv Coolity var i forhold til å registrere variasjon av temperatur i åpne omgivelser, som et kjøleskap med åpen løsning (uten dør). Vi testet de i butikk og sjekket målingene opp mot Coops egen temperaturmåler Comark C26. Hver Coolity-enhet var tilkoblet et batteri og ettersom vi ikke hadde laget et deksel til prototypene, måtte vi finne en alternativ og midlertidig løsning for hvordan å ha batteri og Coolity-enhet sammen slik at batteriet ikke hang løst. Ved å klippe opp tre pappbiter (en til hver modell) kunne vi ved hjelp av dobbelsidet teip klistre Coolity-enheten og batteriet til pappbiten. 145

149 Figur 80 Comark C26 med våre Coolity 1.0 modeller Fryser I perioden vi befant oss hos Coop Mega Sjølyst var det tilbud på et merke av pizzaer og det var stor aktivitet i de fryserne. Vi ønsket derfor å se hvor stor påvirkning det har for varene når fryseren stadig ble åpnet og lukket. På bakgrunn av det plasserte vi to målere i fryseren: 801B8D ble plassert i en Grandiosa (Grandiosa, udatert) pizzaeske som vi la mellom varene for å få en eksakt måling av temperaturen mellom varen: Figur 81 Coolity 80D1B8D måtte i en pizzaeske for å illustrere en frysevare 146

150 Figur 82 Coolity 80D1B8D i en pizzaeske plassert mellom varer for å måle temperatur som om det var en fryst vare selv og 13E1D2 plasserte vi ved luftstrømmen på glasset, i midten av fryseren helt for seg. 13E1D2 hadde som funksjon å måle lufttemperaturen i kjøleboksen for å sjekke at det stadig var kald luft i fryseren og at temperaturen ikke startet å øke (Bli varmere). Om den kalde luftstrømmen sluttet å fungere ville vi først se en temperaturøkning på 13E1D2, da den ikke holder like lenge på kulden som 801B8D gjør som ligger mellom varer, og avvik og feil ved frysere ville være enkle å fange opp. 147

151 Figur 83 Coolity 13E13D plassert ved luftstrøm Kjøledisk Coop Mega Sjølyst hadde en stor kjøledisk de hadde plassert all ost i. Dette var et godt sted å teste enheten med tanke på at disken var plassert i nærheten av andre ferskvarer og at det da alltid var en ansatt som kunde holde øye med den. Men viktigst av alt var at det var den største og mest åpne kjøledisken i butikken. Om det skulle være noen avvik ville det være logisk at de oppstod der og vi plasserte Coolity 19438E der for å holde oversikt. 148

152 Figur 84 Coop Mega Sjølyst sin ostedisk Teori Som beskrevet i 5.3 Utvikling av IoT-enhet, Coolity under Coolity 1.0: Funksjonell prototype så bruker vi to forskjellige målere da de registrerer temperaturer på forskjellig måter: 19438E sin silikontupp hverken holder på varme eller kulde og kan enkelt tilpasse seg omgivelsenes temperaturer og gi en nøyaktig sanntidsmåling. Derfor passer denne godt i åpne kjøleskap. Metalltuppen på 801B8D holder på temperaturen en stund før den tilpasser seg temperaturen i omgivelsene. Dette passer til måten temperaturen på kjølevarer skal måles. Det er ikke temperaturen i fryseren i seg selv som er viktig, men temperaturen mellom varene for å illustrere en omtrentlig temperatur på varen i seg selv. Vi bekreftet teorien ved å sammenlikne målingene fra 801B0D sin metalltupp og 19438E sin silikontupp og merket at 801B8D hadde oftere lik måling enn hva 19438E hadde. Blåste vi på metalltuppen ble det heller ikke registrert noe særlig temperaturforskjell med mindre vi blåste over en lengre periode. Med silikontuppen på 19438E merket sensoren tydelig forskjeller i temperaturen da de oppsto, og så snart vi blåste på sensoren merket den temperaturfoskjellen. Vår teori om at Coolity med silikontupp er mer egnet for kjøleskap og at andre med metalltupp passer i frysere, stemte altså Måleinstrumenter Som vi nevnte innledningsvis sammenligner vi de ulike måleinstrumentene fra både Coop og Mattilsynet for å se hvilke som er mest nøyaktig, og som vi igjen kan bruke til sammenligning for Coolity 1.0. Coop tar i bruk en Comark C26 (Comark, udatert) 149

153 mens Mattilsynets benytter seg av en Testo 926 (Max Sievert, udatert-a). Begge benyttet seg i tillegg av den samme trådføleren med nøyaktighetsklasse 1 (Max Sievert, udatert-b). Vi fant brukermanualer og informasjon som dokumenterte nøyaktigheten til både Comark C26, Testo 926 og trådføleren. Til å begynne med så vi på nøyaktigheten av trådføleren begge måleinstrumentene tok i bruk: MODELL AVVIK AVVIK MÅLEOMRÅDE TOTALE MÅLEOMRÅDE Trådføler Type T +/- 0.5 C -40 C til 125 C -75 C til 350 C (Max Sievert, udatert-b) +/- 0.5 C *(t) 125 C til 350 C Instrumentene selv, Comark C26 og Testo 926, hadde følgende nøyaktighet: MODELL AVVIK AVVIK MÅLEOMRÅDE TOTALE MÅLEOMRÅDE Comark C26 +/- 0.2 C + 0.1% -200 C til 400 C -200 C til +400 C Testo 926 +/- 0.3 C -20 C til 70 C -50 C til +400 C +/- 0.7 C + 0.5% Resterende (Comark, udatert) (Max Sievert, udatert-a) Temperaturene vi skulle måle lå hovedsakelig mellom -25 C og 25 C og instrumentene med trådføler ville som oftest befinne seg innenfor deres mest nøyaktige måleområde. Vi regnet ut avviket til Coops temperaturmåler Comark C26, Mattilsynets temperaturmåler Testo 926 og trådføleren fra måleområdet vi kom til å benytte enheten vår i: -25 C til 25 C. MODELL TEMPERATUR ( C) REGNESTYKKE Comark C26 +/- 25 C 25 * = = AVVIK (Toleranse) +/- 0.2 C (25.2 C til 24.8 C) Testo C 0.3 C +/- 0.3 C (25.3 C til 24.7 C) 150

154 -25 C 25 * = = /- 0.8 C (-25.8 C til C) Trådføler Type T +/- 25 C 0.5 C +/- 0.5 C (25.5 C til 24.5 C) Fra utregningene merket vi oss at temperaturmåleren Testo 926 hadde større avvik både da det var minus- og plussgrader, og vi kunne derfor med sikkerhet velge Comark C26 til sammenlikning for Coolity 1.0. Tar vi utgangspunkt i minusgradene der skillet var størst mellom de to instrumentene, -25 C, hadde Comark C26 et totalavvik på +/- 0.7 C (0.2 instrument trådmåler) og Testo 926 et totalavvik på +/- 1.3 C (0.8 instrument trådmåler). Coolity 1.0 hadde et avvik på +/- 0.5 C mellom -55 til 125 C som er måleområdet dens (Electronics, udatert; Kjell & Company, udatert-e). Det gjald både temperaturmåleren med silikontupp og metalltupp da begge er av samme type Dallas DS18B20 (Maxim Integrated, udatert), men med forskjellig skjerming. Tilsammen utgjorde da Coolity 1.0 og Comark C26 et avvik på 1.2 C som vi da var innstilt på å godta under testing Resultater Coop benytter seg av et trafikklyssystem som inneholder regler, rutiner og grenseverdier for temperaturer og de forskjellige kjøle- og frysevarene deres. For oss var grenseverdiene det viktigste, og under testingen i butikk fokuserte vi på å besvare hypotesene, teste selve Coolity 1.0 som enhet og dens nøyaktighet i forhold til målinger. Under 7.2 Testing av applikasjonen lenger ned i rapporten tester vi hva som skjer når noe er utenfor grenseverdiene. 151

155 Figur 85 Coop sitt trafikklyssystem for kjøle- og frysevarer i butikk Under testing i butikk oppdaget vi ingen tilfeller hvor temperaturen gikk utenfor den grønne grenseverdien, som vil si at alle målingene viste temperatur som forholdt seg innenfor ønskede parametere. I applikasjonen baserte vi oss på trafikklysene og satte grenseverdier for varsling, kalt Severity i ServiceNow. Disse kan du lese mer om i 7.2 Testing av applikasjonen Resultat: Fryser Fryseren hadde stabile temperaturmålinger tross åpning og lukking av dør. Hverken varene eller luftstrømmen ble påvirket under testing, og temperaturen forholdt seg innen de grønne grenseverdiene på under -18 C. Vi merket en temperaturforskjell mellom 801B8D, som lå plassert i pizzaesken mellom varene, og 13E1D2, som lå plassert ved luftstrømmen til fryseren. Her var det en differanse på C. Dette kommer av at den kalde luftstrømmen som går inn i fryseren er konstant på samme punkt og varm luft når aldri det punktet. Ellers i fryseren vil det være varm luft som kommer inn gjennom sprekker og når dører åpnes og lukkes. Med mindre fryseren hadde vært helt lufttett og dørene aldri ble åpnet, vil varene alltid være litt varmere enn hva luftstrømmen inn i fryseren er. Derfor registrerte 801B8D i pizzaesken C mens 13E1D2 registrerte C Resultat: Kjøledisk Også 19438E plassert i kjøledisken målte stabile målinger på mellom 3 og 4 C. Her merket vi tilpasningen en silikontupp har til omgivelsene versus en metalltupp. For å få rask tilbakemelding satte vi registreringsintervallet på fem sekunder. Da så vi at så snart vi blåste på silikontuppen eller flyttet den et punkt der den var mer utsatt for varme luftstrømmer, justerte temperaturen seg på neste måling. Det var ikke tilfellet med en metalltupp som holdt på temperaturen lenger. 152

156 Resultat: Hypoteser Alle hypotesene våre viste seg å stemme. I ettertid ser vi at det også hadde vært interessant å se om batteri eller ulike signaler som WiFi, Bluetooth, Infrarødt eller annet vil bli påvirket av å være i frysere og i kald temperatur. Hypotese ServiceNow ID: 19438E ServiceNow ID: 13E1D2 ServiceNow ID: 801B8D h1 Vil vise like temperaturmåling som Comark C26. Vil vise like temperaturmåling som Comark C26. Vil vise like temperaturmåling som Comark C26. h0 Vil differensierer fra Comark C26 sine temperaturmålinger. Vil differensierer fra Comark C26 sine temperaturmålinger. Vil differensierer fra Comark C26 sine temperaturmålinger. RESULTAT Vi forventet en forskjell på 1.2 C eller mer da dette var avviket Coolity og Comark hadde tilsammen, men det var svært sjeldent at de viste mer enn 0.3 C forskjell. Hypotese h1 stemte. h1 Tåler temperaturer under -20 C. Tåler temperaturer under -20 C. Tåler temperaturer under -20 C. h0 Gir avvik eller slutter å fungere ved temperaturer lavere enn -20 C. Gir avvik eller slutter å fungere ved temperaturer lavere enn -20 C. Gir avvik eller slutter å fungere ved temperaturer lavere enn -20 C. RESULTAT Vi plasserte de ulike Coolity modellene i en fryser som hadde temperatur på under 20 C for å se hvordan enhetene reagerte. Alle fungerte uten noen problemer eller avvik i registrering. h1 stemte. h1 Mister ikke nettilkobling. Mister ikke nettilkobling. Mister ikke nettilkobling. h0 Mister nettilkobling. Mister nettilkobling. Mister nettilkobling. RESULTAT Under testing mistet ingen av Coolity modellene internettilgangen. Hypotese h1 stemte. 7.2 Testing av applikasjon 153

157 I løpet av denne testperioden, har vi testet Coolify applikasjonen. Perioden med applikasjons-testing har vart fra til Vi har brukt to ulike testnivåer for å gjennomføre testingen og grundig sjekk av applikasjonen. Vi gjennomførte integrasjons- og systemtester for å teste Coolify-applikasjonen. Enhetstester ble ikke tatt i bruk for å teste Coolify-applikasjonen, da det krevde tilgang til ServiceNow sin kildekoden som var noe vi ikke hadde Systemoversikt Løsningen vår er et overvåkings- og varslingssystem for temperaturmålinger foretatt i Coops ulike kjølere. Vi sender temperaturdata gjennom hver Coolity-enhet som innehar en unik ChipID til Measurement-tabellen ved hjelp av ServiceNow sitt REST API. I applikasjonen har vi to Business regler som sjekker om temperaturen på disse målingene overstiger en viss grense avhengig av om Coolity-enheten er plassert i en fryser eller i et kjøleskap. Hvis temperaturen er for høy, genererer Business reglene et Event der alvorlighetsgraden settes avhengig av hvor stort avviket er. Denne Eventen legges i Event [em_event] tabellen som tilhører Event Management. Vi baserte oss på trafikklysene og satte alvorlighetsgrad for varsling, kalt Severity i ServiceNow: SEVERITY GRENSEVERDI KJØLER GRENSEVERDI FRYSER Minor 4.5 C til 7.4 C C til C Major 7.5 C til 12.4 C -15 C til -6.9 C Critical 12.5 C og varmere -7 C og varmere Når Event objektet blir satt inn i Event [em_event] tabellen, har vi satt opp Event regler som sjekker om Category-feltet er satt til Coolify, altså om Eventen kommer fra vår applikasjon, og hvis Severity er Minor, Major eller Critical. Avhengig av Severity, skjer følgende: SEVERITY HANDLING 154

158 Minor Major Critical Systemet teller antall Eventer av denne graden til den har enten fått inn 4 på rad, eller 4 på tiden det tar for 6 å komme inn. Når antallet overstiger denne grensen innenfor tidsrommet, vil en Alert med alvorlighetsgrad Minor genereres. Systemet teller antall Eventer av denne graden til den har enten fått inn to på rad, eller to på tiden det tar for tre å komme inn. Når antallet overstiger denne grensen innenfor tidsrommet, vil en Alert med alvorlighetsgrad Major genereres. Systemet lager en Alert med Critical alvorlighetsgrad med en gang. Grunnen til at vi for Minor og Major har et slingringsmonn på +50% er for å minimere de tilfellene der temperaturen svinger mellom to alvorlighetsgrader slik at det tilsynelatende ikke er noe problem, selv om det i realiteten er det. Når vi har generert en Alert har vi satt opp Alert regler som lager en Incident basert på alvorlighetsgraden som er satt på Alerten. Dette gjøres ved at vi har en Alert regel som gjelder for hver alvorlighetsgrad som bruker et Task Template som statisk setter feltene Urgency og Impact i Incidenten til å gjenspeile alvorligheten av avviket. Systemet har et tilpasset dashboard til ulike brukere som viser oversikt over hendelser. Administrator har oversikt over alle butikker og hvor mange incidents hver enkelt har åpen til enhver tid. Coop store manager har oversikt over incidents, events og Coolity-enheter i sin egen butikk Fremgangsmåten I integrasjonstest tester vi business reglene for å finne ut om reglene som er satt opp produserer riktig event, alert og incident. Integrasjonstest utføres ved å sette temperaturer manuelt inn i measurement-tabellen slik at Business reglene fanger opp overskytende temperatur og genererer event, alert og incident. I systemtest testet vi brukerhistorier som er hoved funksjonalitetene i Coolify. Vi gjennomførte testen ved å teste alle brukerhistoriene og notere testen i ServiceNow Test Management. Systemtesten er delt i to forskjellige testplaner. Coop Administrator- og Coop Store Manager test plan. Hver test plan inneholdt test suiter og testen. Testplan: En test plan er en samling av brukerhistorier til en bestemt rolle i systemet. Test case: En test case er samling av flere tester tilknyttet en brukerhistorie. 155

159 Test: Trinn som brukes til å avgjøre om en funksjon (brukerhistorie) fungerer som den skal. En test inneholder også et forventet resultat, som brukes til å avgjøre om testen passerer eller feiler Testresultater TEST NIVÅ PASSED FAILED Systemtest (Test case) 39 0 Integrasjonstest Testobjekter Applikasjonenes hovedfunksjonaliteter ligger i blant annet å kunne registrere og endre på nye Coolity-enheter, kjølere og butikker samt business-, event- og alertregler som i tur genererer eventer, alerter og incidenter. Vi testet disse og flere funksjoner for å finne ut om de fungerer. Noen funksjoner ble nedprioritert i testprosessen. Eksempel: Innlogging og utlogging av ServiceNow. Årsaken til det er at ServiceNow innlogging og utlogging allerede er grundig testet av ServiceNow. Noen funksjoner ble ikke testet i det hele tatt, eksempelvis å opprette Oauth 2.0 Access token og administrering av ressursrettigheter. Dette fordi vi visste tidlig i utviklingsprosessen at kun system-administrator og bruker med administrator-rollen hadde rettigheten opprette og utføre dette. Tabellen nedenfor viser oversikt over hva som skal testes, hvilke som er nedprioritert og hvilke som ikke skal testes. TESTEDE FUNKSJONALITETER - Opprett Event - Opprett Alert - Opprett Incident - Opprett Minor Event - Opprett Major Event - Opprett Critical Event - Opprett Alert og Incident etter 4 Minor Events på rad - Opprett alert og Incident etter 2 Major Events på NEDPRIORITERTE FUNKSJONALITETER - Innlogging - Utlogging IKKE TESTEDE FUNKSJONALITETER - System administrator gir Access Control til andre bruker - Opprett Oauth 2.0 Access token 156

160 rad - Opprett Incident etter 1 Critical Events - Legg til ny Cooler - Oppdatere Cooler - Slett Cooler - Legg til ny Coop Admin - Oppdatere Coop admin - Slett Coop admin - Legg til ny Device CI - Oppdatere Device CI - Legg til ny Store - Oppdatere Store - Slett Store - Legg til bruker til Store manager - Oppdatere Store manager - Fjern bruker fra Store manager - Legg til ny Dashboard - Oppdater Dashboard - Deler Dashboard - Slett dashboard - Opprett Problem - Opprett Change request Testnivåer Testobjektene tilhører forskjellige testnivåer. I integrasjonstest tester vi business reglene for å finne ut om reglene som er satt opp produserer riktig event, alert og incident. I systemtest tester vi brukerhistorier som er hovedfunksjonalitet i applikasjonen. INTEGRASJONSTEST - Opprett Event - Opprett Alert - Opprett Incident - Opprett Minor Event - Opprett Major Event - Opprett Critical Event - Opprett Incident og Alert når 4 Minor Eventer forekommer på rad - Opprett Incident når 2 Major Events forekommer på rad SYSTEMTEST - Legg til ny Cooler - Oppdatere Cooler - Slett Cooler - Legg til ny Coop Admin - Oppdatere Coop admin - Slett Coop admin - Legg til ny Device CI - Oppdatere Device CI - Legg til ny Store - Oppdatere Store 157

161 - Opprett Incident når 1 Critical Eventer forekommer - Slett Store - Legg til bruker til Store manager - Oppdatere Store manager - Fjern bruker fra Store manager - Legg til ny Dashboard - Oppdater Dashboard - Deler Dashboard - Slett Dashboard - Opprett Problem - Opprett Change request 158

162 Innholdsfortegnelse: Fremtidig arbeid 8.0 Fremtidig arbeid Applikasjon (Coolify) Automatisk generering av Coolity Varsling når enhet ikke varsler Varsle ansatte i butikken Dashboard map report IoT-enhet (Coolity) OTA (Over The Air) WiFiManager bibliotek Teknologi WiFi - ESP Alternativer til teknologi Infrarødt - Pricer Bluetooth - Bluetooth Low Energy (BLE) Til vurdering Dataoverføring: Viktig faktor

163 8.0 Fremtidig arbeid I denne delen av oppgaven vil vi snakke om videreutvikling og det fremtidige arbeidet som kan vurderes i forhold til løsningen. Vi vil komme med noen refleksjoner vi har gjort oss underveis og tanker om hva som bør vurderes i fremtiden i forhold til teknologier og løsninger for både applikasjonen, Coolify, og IoT-enheten, Coolity. 8.1 Applikasjon (Coolify) Automatisk generering av Coolity Vi får generert CI manuelt med all nødvendig informasjon, men det kan være nyttig å gjøre dette automatisk, hvis vi kobler til en enhet som ikke er forhåndsregistrert. Blir litt vanskelig å gjøre dette automatisk, da det eneste av informasjon vi sender med til REST API er ChipID. For å sikkert kunne registrere en enhet automatisk uten å måtte gjøre inngrep på plattformen, må plassering/butikk hardkodes sammen med REST kallet. Dette må gjøres manuelt på hver enkelt enhet, med mindre man klarer å lage en enklere registrering for hver enhet gjennom et GUI fremfor flashing av chip Varsling når enhet ikke varsler I tilfelle noe uforutsett skulle skje med Coolityen vår, enten at Wifi går ned, den blir stjålet, vannskade, går tom for strøm o.l vil den mest sannsynligvis slutte å sende temperaturdata. Hvis dette skjer kommer det ikke noe data inn i systemet, som vil si at vi ikke får sett noen oversikt over denne enheten. Det er ikke satt inn et system for å håndtere slike hendelser, siden vi har satt opp applikasjonen med enheter som sender POST-requests til et REST API uten å måtte varsle i tilfelle den ikke får sendt data. Scheduled Jobs er en metode for å kunne løse dette fra plattformen sin side. Her kan man automatisere kjøringen av et skript som gjør en spørring mot Device CI tabellen som sjekker samtlige Coolityer som varsler (ServiceNow, udatert-e). For å finne en enhet som ikke rapporterer, burde søket avgrenses til enheter som ikke har varslet de siste 15 minuttene. Er tidsavviket for høyt, må det opprettes en Incident som varsler butikkeier/tekniker om at en Coolity har sluttet å fungere Varsle ansatte i butikken En av de mest sentrale delene av kravspesifikasjonen vi ikke ble ferdige med var å varsle de ansatte i butikken. Dette regner vi derfor som et av de første punktene som bør videreutvikles. Kunden ønsker at de ansatte skal varsles per mobil, som vil si at man vil måtte lage en utvidelse av programmet som sender varsler per mobil til de ansatte, på lik linje med eposter til butikksjefer og administratorer. 160

164 Videre har vi pratet med ansatte hos Coop som fremmet ideen å ha noen form for varsling i kasseapparatene, om det så skulle være noe man fester til kassaapparatet eller integrert i kassaapparatet sitt system. Dette er også noe man kan vurdere for videreutvikling, ettersom noen av de ansatte mener dette er et bedre alternativ Dashboard map report Istedenfor for å bare vise hvor mange incident og eventer som oppstår eller finnes i en butikk, kan vi ha en widget som kalles Map report i dashbordet. Map report kan brukes til å presentere data i kart form. Vi har to muligheter å benytte en map report på, det er geografisk varmekart og bestemte datapunkter. Varmekart kan brukes til å vise hvilken butikk som har flest incidenter. Med bestemte datapunkter kan varmekartet brukes til å definere hvilken kjøler som har temperaturer over grensen og hvor den er plassert i butikken. Ved bruk av map report kan dette være svært nyttig for både Coop administrator og butikksjef. Det vil være mye enklere å identifisere hvilken kjøler som har for høy temperatur (ServiceNow, udatert-t). 8.2 IoT-enhet (Coolity) OTA (Over The Air) OTA (Over The Air) oppdatering prosessen foregår ved å laste opp fireware til ESP modulen ved hjelp av WiFi tilkobling heller å bruke serial port. Denne funksjonaliteten ble ekstremt nyttig i tilfelle av begrenset eller ingen fysisk tilgang til modulen (GitHub Project, udatert). OTA kan gjøres med Arduino IDE Nettleser HTTP Server OTA - prosessen har ingen sikkerhetsmekanisme integrert. Utvikler må selv sørge for at OTA-prosessen gjennomføres på en sikker måte. Dette kan gjøres ved å benytte et bibliotek som heter ArduinoOTA. Ved å benytte dette biblioteket reduseres risikoen for å bli hacket. For å kunne laste opp programmet til ESP8266 modulen må brukernavn og passord være oppgitt (GitHub Project, udatert) WiFiManager bibliotek. Ved oppstart er Coolity satt til STA modus (Station mode), som vil si at den prøver å koble til WiFi med SSID og passord som er hardkodet på Coolity-enheten (tzapu, 161

165 udatert). Ulempen med dette er at dersom Coop gjør endringer på sitt WiFi, vil Coolityen slutte å sende data til ServiceNow. En mulig løsning for å slippe å måtte programmere enheten på nytt hver gang WiFi endrer seg er å inkludere biblioteket WiFi-manager i koden vår. WiFi-manager er et bibliotek som gjør det mulig å få en NodeMCU/ESP8266 til å fungere som et AP (Access point) dersom den ikke finner et WiFi den kjenner fra før. Dette tillater en bruker å koble til Coolityen via en smarttelefon eller PC som vil åpne en nettside som kjøres av enheten der man kan fylle ut ønsket SSID og passord Coolity-enheten skal prøve å koble seg til med. Ved bruk av dette biblioteket, vil enheten blir mer fleksibel med tanke på plassering og nettverk ute i butikk. Dette er en bedre løsning enn å måtte legge SSID og passord i koden, men den er dessverre ikke helt optimal, fordi noen blir nødt til å fysisk koble seg til hver enkel Coolity-enhet for og manuelt legge til SSID og passord. 8.3 Teknologi I begynnelsen av prosjektet hadde ServiceNow introdusert ideen om å bruke Arduino utviklingskort til å lage en trådløs temperaturmåler som sender statistikk til ServiceNow-plattformen 38. I tillegg til å gi en veldig generell kravspesifikasjon, tipset ServiceNow oss om ESP8266 (Kjell & Company, udatert-h) WiFi-chipen vi kunne bruke i prosjektet. Dette tipset låste oss til WiFi-teknologi for sending av data, og denne avgjørelsen viste seg å påvirke prosjektresultatet. Under møtet med Coop 2. februar introduserte Coop ønske om at enheten skulle fungere med batteri. I startpakken vi hadde kjøpt (Kjell & Company, udatert-b) fulgte det med en 9V battericap så vi tok derfor utgangspunkt i 9V s batterier da vi skulle teste hvor lenge et slikt batteri varte med løsningen vår WiFi - ESP8266 Som tidligere nevnt 39 i oppgaven har NodeMCU en integrert ESP8266. Da vi testet Coolity 1.0 med et 9V batteri, oppdaget vi at det kun holdt i tre timer før batteriet var tomt for strøm og enheten sluttet å virke. Vi måtte prøve å finne måter å forlenge batterilevetiden på. Problemet var at Coolity 1.0 alltid sto på og at alle komponenter på NodeMCU-kortet trakk strøm. Vi trengte enten å redusere mengden strøm NodeMCU tok eller å gi den pauser. Det første alternativet ville vært at vi måtte ha loddet av diverse komponenter på NodeMCU. Det var vi ikke komfortable med da vi ikke har lært noe om lodding under 38 Vedlagt mail fra Odd Mareno Leonhardsen fra ServiceNow 39 Se Coolity 0.2: NodeMCU Lampe avsnitt Løsning 162

166 studietiden og sjansen for å ødelegge enheten vurderte vi som høy. Det ville vært svært problematisk da vi kun hadde tre funksjonelle NodeMCU utviklingskort og at Kjell & Company ikke hadde flere på lager på det tidspunktet. Vi måtte derfor gå for det andre alternativet vi tenkte oss, som var å gi enheten pauser. Vi fant frem til at det finnes noe som kalles Deep sleep (Falafel Posts, 2016). Ved å implementere deep sleep i løsningen vår ba vi Coolity 1.0 om å sove etter at den hadde gjort jobben sin med å registrere og sende temperaturmålingene. Måten dette fungerer på er at alle komponenter på NodeMCU ikke tar noe strøm etter at den har utført oppgaven; de slukner. Det eneste funksjonelle på NodeMCU-brikken er den integrerte ESP8266 sin interne klokke. Den vil fungere som en alarm eller stoppeklokke, og vi kan definere hvor lenge komponentene skal sove før den integrerte klokken i ESP8266 skal vekke dem. Code 124. //Deep sleep with a 15 minute interval ESP.deepSleep(1*60* , WAKE_RF_DEFAULT); I koden over ser vi at den integrerte klokken i ESP8266 får et tidsintervall den skal vekke alle komponentene. Når tiden er oppfylt vil den sende et signal til resetfunksjonen på NodeMCU, som istedenfor å faktisk resette og slette informasjon, kun vekker alle komponentene for at de skal sende signaler igjen før de repeterer prosessen med å sove og venter på at den interne klokken skal vekke dem. Ved hjelp av deep sleep klarte vi å få Coolity 1.0 til å sende signaler i omtrent fire dager før 9V-batteriet gikk tomt. Dette var en stor forbedring, men det var fortsatt langt ifra hva vi ønsket oss Alternativer til teknologi Utover et ønske om en mindre enhet enn hva Coolity 0.1 versjonen var og at den skal fungere med batteri, hadde hverken ServiceNow eller Coop gjort seg opp noen mening om varighet på batteriet eller type batteri. Alle parter var klar over at dette ville være en prototype for å vise mulighetene med IoT og ServiceNow-plattformen. Vi har ikke hatt tid til å utforske grundig eller implementere andre alternativer til Coolity-løsningene våre. Det er mulig vi hadde fått et annet resultat om oppgaven hadde blitt gitt på en måte der vi selv måtte utforske alternativer til teknologi. Vi har likevel gjort en innsats for å komme i kontakt med leverandører av relevant teknologi og også fått noen treff på forskningsartikler som sammenlikner og tester ulike teknologier. 163

167 Nedenfor har vi derfor presentert to teknologier som kan vurderes; infrarødt og bluetooth Infrarødt - Pricer Underveis i prosjektet oppdaget vi at Meny og Kiwi har digitale prislapper som vi tenkte måtte være av en type IoT-enhet da de oppdaterte seg trådløst. For å ha noe å sammenlikne Coolity og dens varighet med, undret vi derfor på hva slags teknologi disse baserte seg på og hvor lenge de varte. Vi kontaktet Pricer (Pricer, udatert-a), leverandøren av prislappene til butikker, for å høre om de kunne fortelle litt om teknologien. Pricer tar i bruk infrarødt (IR) til sine løsninger. De leverer en komplett løsning der en server har all informasjon om pris og varer. Dette sendes til hver butikk for at de skal ha informasjon lokalt i programvaren Pricer har gitt kundene sine. Den lokale maskinen kommuniserer med transceivere som sender oppdatert pris og vareinformasjon til prislappene som henger ute i butikken. Figur 86 kommunikasjon fra Pricer server til elektronisk prislapp i butikk IR-teknologien har utviklet seg til det punktet hvor det ikke lenger er behov for at transceiveren trenger å se prislappene (mottakere). Det infrarøde signalet transceiveren sender kan hoppe på ulike flater til prislappene mottar signalet 164

168 (Pricer, udatert-b). Pricer informerte oss om at det på det meste tar 0.5 sekunder å få sendt et signal til prislappene. Ettersom Pricer ikke ønsket å gå ut med nøyaktig informasjon kan vi ikke være helt sikre, men prislappene benytter seg av batterier på størrelse og omtrentlig lik kapasitet som CR2032 modellen. Basert på 30 minutters aktivitet om dagen har leverandøren av prislappene informert Pricer om at holdbarheten kan regnes med til et minimum av 5 år. Pricer selv informerte oss om at butikkene og deres prislapper aldri når en aktivitet på 30 minutter om dagen, da de kun trenger å sjekke og oppdatere priser en gang om dagen. De har derfor hatt prislapper som har vart i over 10 år Bluetooth - Bluetooth Low Energy (BLE) I en studie om smartbygg fra januar 2017 (Putra, Pratama, Lazovik & Aiello, 2017) sammenliknes energiforbruket på mobiler som benytter seg av WiFi- og Bluetooth Low Enery-signaler (BLE). BLE er versjonen laget for Internet of Things med fordeler som lavere energiforbruk, 128-bits kryptering, interoperabilitet, i tillegg til lik rekkevidde som vanlig Bluetooth (Bluetooth, udatert). Tidligere har den mest utbredte, sikre og effektive overføringen av data vært ved hjelp av WiFi over HTTP kall. Nå har Bluetooth sin Low Energy kommet på banen, spesielt for IoT, med høyt krypteringsnivå og med packets som tillater sending av data. I forskningsartikkelen kommer det frem at gruppen gjorde et eksperiment på 20 bytes dataoverføring over det tradisjonelle WiFi med HTTP, og sammenliknet med Bluetooth Low Energy sine packets. De tok i bruk beacons plassert i en smartleilighet og sjekket hvor raskt data ble overført til brukeres telefoner og hvor mye batteri som ble brukt. Resultatet viste en 30% raskere dataoverføring med BLE packets enn med WiFi HTTP, og 12.6% lenger varighet med BLE enn med WiFi på batteriet (Putra et al., 2017) Til vurdering Det kan virke som at både infrarødt (IR) og bluetooth (BT) er bedre alternativer enn WiFi, spesielt når det kommer til energibruk. Til vår løsning i butikk ville begge vært gode alternativer. Den største forskjellen på IR og BT mot WiFi, er rekkevidden på signalene og tilkoblingsmuligheten. WiFi har den lengste rekkevidden og kan enkelt koble seg trådløst til butikkers trådløse nettverk og sende statistikk til Coops ServiceNow-instance. I en stor Coop butikk ville det med en IR- eller BT-løsning måtte settes opp mottakere for IR eller beacons for BT. Disse videresender signaler til en lokal maskin i butikk som er koblet på nett og sender statistikken til ServiceNow-instancen. 165

169 Vår løsning er den enkleste løsningen med tanke på oppsett i butikk, den krever kun et trådløst nettverk. For IR og BT trengs det tilleggsutstyr som receiver og beacon i tillegg til enhetene vi eventuelt lager, dette kan påvirke produktprisen Dataoverføring: Viktig faktor Coolity varer kun i 4 dager, selv med deep sleep mode. Dette kommer blant annet av energiforbruket til WiFi når den kobler opp og sender data. Coolity overfører rundt 400 bytes til ServiceNow over WiFi. Ifølge en forskningsartikkel fra 2014 (Shahzad & Oelmann, 2014) vil WiFi ikke være lønnsomt med tanke på forholdet mellom datamengden som overføres og energiforbruket. Dette støttes også opp i forskningsartikkelen fra 2017 som vi nevnt tidligere, med 20 bytes overføring (Putra et al., 2017). Figur 87 "Energy consumption of the ZigBee, BLE and Wi-Fi for different data loads" 40 Figuren over fra Shahzad og Oelmann sin forskningsartikkel (Shahzad & Oelmann, 2014), viser at jo større datamengde som overføres, desto lenger tid vil overføringen ta, som igjen resulterer i større energibruk og rask tømming av batteriet. Det er altså to ting som må tas i betraktning når en analyserer figuren: 40 Copyright 2017 IEEE - All rights reserved. (Shahzad & Oelmann, 2014) 166

170 1. Hvor mye energi det krever å koble opp og registrere informasjon/statistikk. 2. Hvor lang tid det tar å overføre datamengden. Til sammen resulterer det altså i energibruk for enheten. Overføringen vi gjør over WiFi når vi registrerer kjølestatistikken ligger som sagt på rundt 400 bytes. Shahzad og Oelmann konkluderer med at ZigBee har lavest energibruk ved tilkobling og overføring av data med størrelse opptil 500 bytes. Ved 800 kb eller mer har WiFi minst energiforbruk da den bruker kortest tid på overføringen. Om en overfører data som varierer i størrelse, vil bluetooth low energy være mest lønnsomt hvis det er mellom 500 bytes og 800 kb. Til videre arbeid med Coolity, vil det derfor være viktig å vurdere bruksområdet, hva som skal registreres av enheten, hvor stor pakke det er og hvordan det ønskes å bli sendt. Vi har ikke funnet noen forskningsartikkel eller hatt mulighet til å teste infrarødt nærmere og måle det opp mot de andre teknologiene. 167

171 Innholdsfortegnelse: Oppsummering 9.0 Oppsummering Konklusjon: ServiceNow plattform Konklusjon: Applikasjon Konklusjon: Prototype

172 9.0 Oppsummering I denne delen vil vi prøve å runde av oppgaven og konkludere de ulike delene. Vi har hatt et omfattende prosjekt der oppgavene og fokuset er delt i tre hoveddeler; ServiceNow plattformen, prototype og applikasjon. 9.1 Konklusjon: ServiceNow plattform ServiceNow er et verktøy vi absolutt ser nytten av for bedriftsmarkedet. Ved hjelp av egendefinerte tabeller, regler og visualiseringsverktøy har de laget en full pakke som inneholder det mest nødvendige for hvilken som helst kunder, og det som ikke finnes allerede kan utvikles. Likevel fant vi ut at enkelte problemer enklere kunne løses ved å kode noen linjer fremfor å lete gjennom hele ServiceNow etter ønsket funksjonalitet. Dette har vært en av de største utfordringene i løpet av utviklingen; å prøve å finne frem til riktig informasjon. Vi hadde en klar idé om hva vi ønsket at applikasjonen vår skulle gjøre og hvordan den skulle gjøre det, men vi opplevde til tider at ServiceNow-plattformen ikke hadde mulighet til å gjøre det. For eksempel ønsket vi å ha én enkelt eventregel som kunne bearbeide alle eventene våre ved hjelp av en tellefunksjon, men etter mye lesing og etter et møte med en ServiceNow utvikler, viste det seg at det ikke var mulig. Overraskende nok var ikke utvikleren klar over det heller, så da lærte begge parter noe nytt. Da vi til å begynne med skulle forstå og bekrefte oppsettet av applikasjonen vår, spurte vi diverse konsulenter om hjelp og innspill for å verifisere at vi gjorde ting riktig. Etterhvert som applikasjonen vår tok mer form og vi møtte på feil, merket vi oss at det ikke var særlig mange som hadde spisskompetanse innen Event Management, og det ble derfor vanskelig å få tak i informasjonen vi trengte. Årsaken til at det ikke finnes særlig spisskompetanse innen Event Management er at det ikke er noen kunder av ServiceNow i Norge som benytter seg av det. I Coop sitt tilfelle og sannsynligvis andre, er nok årsaken at de fleste selskaper allerede har etablerte verktøy som tar seg av nøyaktig det samme som Event Management gjør. Likevel fant vi i mange tilfeller noen som kunne gi noen tips til å hjelpe om vi sto fast, eller så var det noen som besvarte oss i community 41. Men det var også noen ganger vi måtte konkludere med at ServiceNow ikke kan gjøre det vi ville, og at vi måtte løse et gitt problem på en annen måte. Eksempelvis måtte vi løse problemet nevnt tidligere om eventregler ved å opprette en egen regel for hver enkelt type event basert på alvorlighetsgrad i stedet for én enkelt regel. Til konklusjon kan vi si at ServiceNow er en god plattform med mange muligheter, men at det er en klar høyde under taket som gjør at utvikling av ny funksjonalitet kan 41 Forum der man kan snakke om ServiceNow plattformen. 169

173 bli begrenset. I tillegg er det slik at ikke alt oppfattes som intuitivt i plattformen og en må bruke lang tid på å gjøre seg kjent med måten ting skal gjøres på. Det har vært svært interessant for oss å benytte oss av ServiceNow; vi ser verdien av plattformen og vi merker også at det er et stort behov for flere konsulenter. Utviklerne og de som jobber med ServiceNow-plattformen er svært opptatte av tilbakemeldinger for å gjøre plattformen bedre, så det er mulig å tenke seg at de begrensningene som er nå, kun er midlertidige og at noen allerede jobber med å finne løsninger. 9.2 Konklusjon: Applikasjon Applikasjonsutvikling for plattformen har vært en veldig spennende og givende opplevelse gjennom prosjektets løp. Etter 2,5 år med studier på datalinjen ved Høgskolen i Oslo og Akershus føler vi at vi var godt rustet til å begi oss ut på å utvikle en applikasjon for en skyplattform. Vi fikk god bruk for kunnskap vi tilegnet oss gjennom studiet i emner som databaser, nettverk og skytjenester, webprogrammering og systemutvikling. Vi har brukt smidig utviklingsmetodikk, skrevet kode i C++ og JavaScript, brukt teknologier som baserer seg på Java, MySQL og lært oss store deler av en massiv plattform. I utgangspunktet var vi skeptiske til at oppgaven skulle bli for enkel, fordi en stor del av det som gjør ServiceNow så populært er hvor enkelt man kan sette sammen forskjellige biter for å få til ønsket funksjonalitet på kort tid. Riktignok krever dette at man på forhånd allerede har gode kjennskaper til ITSM- og ITOM-systemer, noe vi ikke hadde. Dette kombinert med at vi ikke fant noen andre som har gjort noe lignende på denne plattformen før, gjorde at det ble en veldig bratt læringskurve gjennom hele prosjekt-perioden. Til å begynne med ønsket vi å lage en enkel applikasjon som kunne motta temperaturdata og koble hver enkelt måling opp mot riktig Coolity-enhet i vår tabell. Videre ønsket vi å kunne gi varslinger når temperaturen oversteg en grenseverdi og lage en event som skulle eskaleres til en incident og tilslutt et problem som måtte håndteres. Etter en del testing og feiling fant vi ut, etter samtaler med ServiceNow, at det allerede fantes en plugin som kunne hjelpe oss med å oppnå dette. Vi ble rådet til å ta i bruk Event Management i løsningen vår, men halvveis ut i utviklingsprosessen fant vi ut at dette er en plugin som er lite utbredt blant ServiceNow-konsulenter i Norge. Vi trengte hjelp og gikk internasjonalt for å finne noen med ekspertise innen denne pluginen, kun for å oppdage at vi ikke kunne behandle flere eventer med samme eventregel. Overraskende nok var heller ikke denne utvikleren klar over dette, men skulle ta det videre i systemet for å finne en løsning på det. Avslutningsvis vil vi si at til tross for at applikasjonen ikke nådde det potensiale vi først hadde sett for oss, er den et steg i riktig retning. Å være med å utvikle en 170

174 løsning som bidrar til dagens digitalisering og automatisering er veldig givende, spesielt med tanke på at vi har fått den unike muligheten til å bruke plattformen til et av de fremste CRM-systemene i verden, samt å se potensiale og sammenheng mellom internet of things og store IT systemer. Til tross for at arbeidsmengden til slutt beveget seg forbi omfanget til en bachelor, har gruppen fått testet sine evner til å ta til seg kunnskap vi aldri ellers hadde hatt mulighet til å tilegne oss i løpet av studieløpet. Vi kan med stolthet si at både kunden og arbeidsgiver har gitt oss positive tilbakemeldinger på prosjektet, og at interessen for feltet er stor. Dette er deriblant da vi har fått vite at det allerede pågår andre prosjekter som takler samme problemstilling på en annerledes måte, hvor potensiale for samarbeid i fremtiden er stor. I et større perspektiv er det definitivt behov for prosjektet, og det er en uunngåelig bevegelse i samfunnet at alle arbeidsprosesser moderniseres og digitaliseres. Især internet of things har fått eksponensiell interesse i IT bransjen, både for sitt enorme potensiale og de store usikkerhetene rundt uoppdagede sikkerhetsbrudd og mulighet for misbruk. Gruppen er spent på å følge utviklingen, spesielt nå som vi har fått konkret erfaring innenfor feltet. 9.3 Konklusjon: Prototype Det har vært utrolig givende å jobbe med prototypen. Det er annerledes å jobbe med noe på skolen som er til en innlevering, enn hva det er å jobbe med noe som er fra en arbeidsgiver og som en reell kunde kan ta i bruk. Det har likevel vært svært interessant å merke oss hvor mye av kunnskapen, rutinene og disiplinen vi har fra skoleprosjekter som har spilt inn i prosjektet og prototypen. Det å jobbe i et tverrfaglig team, hvor du har dataingeniører og anvendt datastudenter, alle med forskjellig bakgrunn og interesseområder, har hatt enormt mye å si når vi jobber med et prosjekt som er nytt og som vi ikke har direkte erfaring med fra tidligere. Som vi nevner i teknologi-delen 42, oppdaget vi underveis i prosjektet at WiFi bruker mye strøm i vår løsning og at det kan finnes bedre alternativer til løsningen enn WiFi, eksempelvis bluetooth low energy eller infrarødt, alt etter hvilke vurderinger en tar for enheten og hva slags data som skal overføres. For at denne prototypen skal kunne tas i bruk, trenger den et deksel som er vanntett, skiller batteriet fra resten av utviklingskortet og at temperaturmåleren ikke er i nærheten av WiFi-chipen, da vi merket at WiFi-chipen blir varm og kan utgjøre en forskjell på målingene. Likevel kan vi konkludere med at vi leverte en funksjonell prototype ut i fra kravspesifikasjonene vi fikk, og til vår glede fylte den også hypotesene våre. Den 42 Se Fremtidig arbeid og Teknologi 171

175 eneste forskjellen vi hadde ønsket oss for Coolity og utvikling av prototypen er at kravspesifikasjonene kom samtidig og at vi selv kunne reflektert rundt teknologi tatt i bruk for løsningen. Dette er ikke ment som kritikk til hverken ServiceNow eller Coop; Alle parter inkludert oss selv var inneforstått med at dette kun var tenkt som en prototype og at vi sannsynligvis må ta nye runder med utvikling og grundig testing før vi har et produkt som kan brukes som vi ønsker både med hensyn til registrering av data, sending av data, batterivarighet og ikke minst størrelse da også det kan bli enda mindre ved videre arbeid eller bytte av teknologi. 172

176 Innholdsfortegnelse: Kildeliste / Dataordbok / Vedlegg 10.0 Kildeliste Dataordbok ServiceNow og Coolify NodeMCU og Coolity Generelt Vedlegg Vedlegg 1 - Introduction to ServiceNow Vedlegg 2 - Epost fra veileder ved ServiceNow Vedlegg 3 - Epost fra Jason Smith Vedlegg 4 - Gantt-diagram

177 10.0 Kildeliste Adafruit. (2015). Adafruit Feather HUZZAH ESP8266: WiFi with built-in battery charging for IoT on-the-go! Hentet 10. april fra Adobe. (udatert). Adobe Illustrator CC: Create beautiful vector art. Hentet 27. februar fra Ahmed, Sarfraz. (2012). Javascript Self Invoking Functions. Hentet 3. mai fra Arduino. (2015). ESP8266EX Datasheet. Hentet 21. mar fra Arduino. (udatert-a). Arduino: Arduino/Genuino UNO. Hentet 14. mars fra Arduino. (udatert-b). Frequently Asked Questions: Can I program the Arduino board in C? Hentet 27. februar fra Arduino. (udatert-c). Software: Download the Arduino IDE. Hentet 27. februar fra AsciTable. (udatert). ASCII Table and Description. Hentet 20. mai fra Atom. (udatert). Atom: A hackable text editor for the 21st Century. Hentet 27. februar fra Benson, Jim & Barry, Tonianne DeMaria. (2011). Personal Kanban: Mapping Work Navigating Life (Bind 1). USA: Modus Cooperandi Press. Bluetooth. (udatert). Bluetooth Low Energy. Hentet 2. mai fra CISCO. (udatert). WebEx: Work where you are. Hentet 28. februar fra CNXSoft. (2015). NodeMCU is both a Breadboard-Friendly ESP8266 Wi-Fi Board and a LUA based Firmware. Hentet 10. april fra software.com/2015/04/18/nodemcu-is-both-a-breadboard-friendly-esp8266- wi-fi-board-and-a-lua-based-firmware/ Comark. (udatert). C26 Industrial Thermometer (Type T). Hentet 27. mars fra 174

178 Datatilsynet. (udatert). Skytjenester - en veiledning. Hentet 5. april fra Draw.io. (udatert). Hentet 14. februar fra Electronics, SparkFun. (udatert). One Wire Digital Temperature Sensor - DS18B20. Hentet 5. april fra Ericsson. (2015). Ericsson Mobility Report: On the pulse of the networked society. Hentet 20. mai fra Falafel Posts. (2016). ESP8266/NodeMCU Deep Sleep. Hentet 2 mai fra GitHub. (udatert). How people build software. Hentet 28. februar fra GitHub Project. (udatert). ESP8266 Arduino Core. Hentet 24. april fra html Google. (udatert). Google Dive: All your files, ready when you are. Hentet 21. februar fra Grandiosa. (udatert). Grandiosa Original. Hentet 27. mars fra HiOA. (2016). Bachelorgruppe 8. Hentet 2. desember fra Høgskolen i Oslo og Akershus. (udatert). Dokumentasjonsstandard. Hentet 22. mai fra 2.pdf Instans SSL. (udatert). What is HTTPS? HTTP VS HTTPS. Hentet 20. februar fra International Organization for Standardization. (2012). ISO/IEC 40500:2012: Information technology -- W3C Web Content Accessibility Guidelines (WCAG) 2.0. Hentet 8. mai fra JavaBin. (2016). JavaZone: 15 years of JavaZone. Hentet 8. mars fra Kjell & Company. (udatert-a). Adafruit Feather HUZZAH utviklingskort: ESP8266 WiFi-utviklingskort. Hentet 10. april fra 175

179 verktoy/elektronikk/arduino/shields/adafruit-feather-huzzah-utviklingskortp88221 Kjell & Company. (udatert-b). Arduino Startpakke. Hentet 14. mars fra Kjell & Company. (udatert-c). Kjell & Company. Hentet 14. mars fra Kjell & Company. (udatert-d). Luxorparts Koblingskabler Hann-hunn. Hentet 11. jan fra Kjell & Company. (udatert-e). Luxorparts Temperatursensor med kabel - DS18B20, vannavvisende. Hentet 5. april fra Kjell & Company. (udatert-f). NodeMCU Utviklingskort: Utviklingskort med wifi-støtte. Hentet 10. april fra Kjell & Company. (udatert-g). Strømforsyning til koblingsbrett. Hentet 21. mar fra Kjell & Company. (udatert-h). WiFi-modul for Arduino ESP8266. Hentet 11. januar fra Kommunal- og moderniseringsdepartementet. (2013). Forskrift om universell utforming av informasjons- og kommunikasjonsteknologiske (IKT)-løsninger. FOR Hentet fra Kumar, Krishan. (udatert). What is the difference between C and C++? Hentet 14. mars fra Ljungström, Alexander. (2017). Documenting a ServiceNow application Best Practices. Hentet 22. mai fra Max Sievert. (udatert-a). Bærbar Temperaturmåler - Testo 926. Hentet 27. mars fra Max Sievert. (udatert-b). TRÅDFØLER, TYNN M/STREKKAVLASTER. Hentet 27. mars fra 176

180 Maxim Integrated. (udatert). DS18B20: Programmable Resolution 1-Wire Digital Thermometer (Rev 4), 20. Hentet fra Microsof. (udatert). Skype: Celebrate the season together, wherever you are. Hentet 28. februar fra Microsoft. (udatert-a). Outlook: Organize your world. Hentet 23. februar fra Microsoft. (udatert-b). Project: Deliver winning projects. Hentet 21. februar fra Microsoft. (udatert-c). Visio: Work visually. Hentet 20. januar fra Microsoft. (udatert-d). Word 2016: get it now with an Office 365 subscription. Hentet 20. februar 2017 fra Mitroff, Sarah. (2016). OneDrive, Dropbox, Google Drive and Box: Which cloud storage service is right for you? Hentet 14. februar fra Mozilla Developer Network. (2016). Rhino. Hentet 18. april fra NodeMCU. (udatert). NodeMCU: Connect Things EASY. Hentet 10. april fra Oracle. (udatert). A Relational Database Overview. Hentet 18. april fra Postdot. (udatert). Developing APIs is hard. Postman makes it easy. Hentet 21. mai fra Pricer. (udatert-a). Infrastructure. Hentet 02. mai fra Label-System/Infrastructure/ Pricer. (udatert-b). Technology. Hentet 2. mai fra Label-System/Technology/ Pridopia. (udatert). ESP8266 AT Command Set. Hentet 21. mai fra 177

181 Putra, G. D., Pratama, A. R., Lazovik, A. & Aiello, M. (2017, 9-11 Jan. 2017). Comparison of energy consumption in Wi-Fi and bluetooth communication in a Smart Building. Paper presentert på 2017 IEEE 7th Annual Computing and Communication Workshop and Conference (CCWC) Ramlochun, Dravvy. (2017). ServiceNow instance scalability. Hentet 19. mai fra Raspberry Pi. (udatert). RASPBERRY PI 3 MODEL B. Hentet 10. april fra ServiceNow. (2013). Problem Management. Hentet 9. mai fra ServiceNow. (2015a). Glossary of Terms. Hentet 1. mai fra ServiceNow. (2015b). Navigating Applications. Hentet 24. april fra ServiceNow. (2015c). Navigation and the User Interface. Hentet 2. mai fra e#gsc.tab=0 ServiceNow. (2016a). Event Management. Hentet 1. mai fra ServiceNow. (2016b). OAuth Applications. Hentet 28. februar fra ServiceNow. (2016c). REST API. Hentet 28. februar fra ServiceNow. (2017a). Alerts. Hentet 9. mai fra ServiceNow. (2017b). ITIL Change Management. Hentet 9. mai fra b=0 ServiceNow. (2017c). ITOM Event Management - Custom Event Integration. Hentet 19. mai fra ServiceNow. (udatert-a). Accessibility 508 Compliance. Hentet 27. februar fra 178

182 ServiceNow. (udatert-b). Build Apps Faster: All of the resources you need to build applications more rapidly than ever before. Hentet 8. mai fra ServiceNow. (udatert-c). Business rules. Hentet 2. mai fra ServiceNow. (udatert-d). Changing the Way People Work Since I infographicservicenow-history-and-milestones.pdf (Red.). servicenow.com: ServiceNow. ServiceNow. (udatert-e). Creating a Scheduled Job. Hentet 19. mai fra b=0 ServiceNow. (udatert-f). Database structure. Hentet 18. april fra ServiceNow. (udatert-g). Default transaction quota rule. Hentet 19. mai fra e.html ServiceNow. (udatert-h). Developer program. Hentet 28. februar fra ServiceNow. (udatert-i). Developer Program quick start. Hentet 16. mai fra _getting_started_helsinki_topic_lyf_bf2_3r?v=helsinki ServiceNow. (udatert-j). Dot-walking. Hentet 3. mai fra ServiceNow. (udatert-k). Event Management. Hentet 27. april fra ServiceNow. (udatert-l). Event Management. Hentet 1. mai fra ServiceNow. (udatert-m). Extension to Jelly Syntaz. Hentet 19. april fra b=0 ServiceNow. (udatert-n). Glide Stack. Hentet 18. april fra 179

183 ServiceNow. (udatert-o). GlideRecord. Hentet 19. april fra ServiceNow. (udatert-p). Inbound web services. Hentet 20. mai fra ServiceNow. (udatert-q). Incident Management. Hentet 15. mai fra ServiceNow. (udatert-r). IT Service Management. Hentet 1. mai fra ServiceNow. (udatert-s). Managing Alerts. Hentet 15. mars fra ServiceNow. (udatert-t). Map reports. Hentet 15. mai fra ServiceNow. (udatert-u). Navigation and the user interface. Hentet 2. mai fra rinterface.html ServiceNow. (udatert-v). Notifications. Hentet 15. mars fra ServiceNow. (udatert-w). Now Platform. Hentet 18. april fra ServiceNow. (udatert-x). OAuth 2.0. Hentet 20. februar fra ServiceNow. (udatert-y). Performance Analytics. Hentet 1. mai fra ServiceNow. (udatert-z). Performance Analytics and Reporting. Hentet 1. mai fra ServiceNow. (udatert-aa). Reference Fields. Hentet 3. mai fra ServiceNow. (udatert-ab). ServiceNow Partners. Hentet 16. mai fra 180

184 ServiceNow. (udatert-ac). ServiceNow Products. Hentet 1. mai fra ServiceNow. (udatert-ad). Setting Up Live Feed Table Notifications. Hentet 15. mars fra fications#gsc.tab=0 ServiceNow. (udatert-ae). Sharing Applications. Hentet 21. mars fra ServiceNow. (udatert-af). Table API. Hentet 27. februar fra ServiceNow. (udatert-ag). Unique Record Identifier. Hentet 3. mai fra Shahzad, K. & Oelmann, B. (2014, Aug. 2014). A comparative study of insensor processing vs. raw data transmission using ZigBee, BLE and Wi-Fi for data intensive monitoring applications. Paper presentert på th International Symposium on Wireless Communications Systems (ISWCS) Slack. (udatert). Slack: Where work happens. Hentet 28. februar fra SocialCompare. (udatert). Raspberry Pi 3. Hentet 10. april fra SparkLabs. (2017). Viscosity: The ultimate OpenVPN client. Hentet 28. februar fra Trello. (udatert). Hentet 23. januar fra tzapu. (udatert). WiFiManager. Hentet 24. april fra W3C. (2011). Web Content Accessibility Guidelines (WCAG) 2.0. Hentet 14. mars fra Wikipedia. (2017). Rhino (JavaScript engine). Hentet 18. april fra Wood, Martin. (2016, Kapt. 1-3). Mastering ServiceNow. Hentet 3. mai fra 5/1 Zaikin, Mikalai. (2005). SCWCD 1.4 Study Guide. Hentet 20. februar fra 181

185 11.0 Dataordbok I dataordboken har vi fokusert på og enkelt forklare terminologi, begrep og uttrykk som dukker opp underveis i rapporten ServiceNow og Coolify UTTRYKK Customer Relationship Management (CRM) Everything as a Service (XaaS) Graphical user interface (GUI) Instance IT Operation Management (ITOM) IT Service Management (ITSM) Open Authorization (OAuth) REpresentational state transfer (REST) Severity Update Sets BETYDNING Svært enkelt forklart er dette et kommunikasjonsprogram mellom selskaper og deres kunder. Everything as a Service handler om at ServiceNow nå ønsker å tilby alle tjenester for å treffe alle målgrupper og type kunder. En fremstilling av data som er designet på noe vis for at bruker enklere skal kunne tolke data. Instancene i ServiceNow er en indiviudell implementering av ServiceNow plattformen, som man bruker for å utvikle og teste applikasjoner. I større produksjonsteam skiller man mellom sandboxer, utviklingsinstancer og produksjonsinstancer. Behandling av driftsoperasjoner for selskap. Behandling av service for selskaper. En åpen protokoll som tillater kommunikasjon med sikret data. En web arkitektur som tillater kommunikasjon mellom klienter og servere, gjennom HTTP-protokoller. Alvorlighetsgrad sett i sammenheng av Coop sitt trafikklys for temperatur, der det er grenseverdier for grønn, gul og rød og i ServiceNow opereres med minor, major og critical. I ServiceNow opererer man med Update Sets istedenfor versjonskontroll. Update Sets brukes til å lage, teste og implementere endringer mellom instancer i ServiceNow sitt API. Det brukes også for å lagre tidligere versjoner av applikasjonen. De kan sammenlignes med brancher i Git. 182

186 Merk at Update Sets ikke brukes til å installere applikasjoner i en ServiceNow instance. Widget Et grafisk brukergrensesnitt (GUI) som viser informasjon eller tilbyr en spesifikk måte å påvirke et operativsystem eller en applikasjon på NodeMCU og Coolity UTTRYKK Access Point (AP) Access Token Domain fingerprint Prototype REST API endpoint Service Set identifier (SSID) Station (STA) BETYDNING WiFi modulen ESP8266 vil sette seg til et Access point, hvor andre enheter kan kobler til. Som en type hotspot. Legitimasjon som brukes til å få tilgang til ressursene i ServiceNow. Den har et bestemt omfang og levetid. Legitimasjon som tilhøre et domene. Et utkast av noe som skal illustrere en funksjonalitet eller løsning. Endepunktet hvor dataene lagres, i vårt tilfellet lagres dataene i Measurement tabellen. Navn på WiFi-nettverk. WiFi modulen ESP8266 kobler til et bestemt WiFi Generelt UTTRYKK Integrated development environment (IDE) Internet of Things (IoT) BETYDNING Utviklingsprogrampakke for utviklere som har integrerte verktøy som gjør programmering mer oversiktlig. Eller Tingenes internett på norsk, er en samlet betegnelse på alle ting som kan kobles på nett med det formål om å gjøres menneskes hverdag enklere. 183

187 Wiki En nettside eller database utviklet av flere brukere som inneholder informasjon. Informasjon kan endres på eller legges til av brukere. 184

188 12.0 Vedlegg 12.1 Vedlegg 1 - Introduction to ServiceNow 185

189 186

190 187

191 188

192 189

193 190

194 191

195 192

196 193

197 12.2 Vedlegg 2 - Epost fra veileder ved ServiceNow Kuul Case til deres oppgave. 194

198 195

199 12.3 Vedlegg 3 - Epost fra Jason Smith ServiceNow + IoT = 196

200 197

201 12.4 Vedlegg 4 - Gantt-diagram 198