Utveckling av en adapter till en öppen energiplattform

Teknik och samhälle

Datavetenskap

Examensarbete

15 högskolepoäng, grundnivå

Utveckling av en adapter till en öppen

energiplattform

Adaptordevelopment for an open source energyplatform

Per Johansson

Joakim Lithell

Examen: Kandidatexamen i dataveten-skap 180 hp

Program: Systemutvecklare

Datum för slutseminarium: 28/8 2014

Handledare: Carl Magnus Olsson Andrabedömare: Mia Persson

Förord

Examensarbetet, Utveckling av adapter till en öppen energiplattform, har pågått under våren samt sommaren 2014 och avslutar Systemtutvecklingsprogrammet på Malmö Högskola - Teknik & Samhälle. Arbetet motsvarar 15hp och har gjorts i samarbete med Elis-projektets utvecklingsteam på Medea.

Vi vill börja med ett stort tack till vår handledare Carl Magnus Olsson som har väglett oss genom arbetet på ett outtröttligt och motiverande sätt above and beyond. Vi vill även tacka Johan Holmberg, Axel Olsson, Magnus Ljungblad för att ni har välkomnat oss in i gänget och låtit oss störa er när vi fastnat. Utan er medverkan hade det inte blivit något examensarbete. Även ett stort tack till Ulrik Eklund för att vi ck interjua dig.

September 2014 - Malmö Per och Joakim

Sammanfattning

Målet med denna studie är att utveckla en adapterprototyp mot en öppen ener-giplattform och dokumentera utvecklingsprocessen. Fokus ligger på att integrera Philips Hue, ett system för styra trådlösa lampor mot plattformen Elis (Mobile ser-vices for energy eciency in existing buildings). Inom en begränsad tidsram så ska vi sätta oss in i två främmande system till en sådan grad att vi kan skapa kommuni-kationen mellan dem. Inledningsvis krävs det att vi läser dokumentation och att vi jobbar fram en arbetsplan. Vidare kommer vi lösa den adaption som krävs för att värden mellan det två systemen överensstämmer och fungerar. Vi kommer använda oss av intervjuer för att få klarhet i hur plattformen är uppbyggd och grunden till deras designval. Metoden design research används för att på ett iterativt sätt skapa delmål och successivt utveckla och utvärdera arbete. Målet med design research är att skapa en artefakt, en adapterprototyp i vårt fall. Vi gjorde totalt fyra iterationer där vi delade upp arbetet. Steg ett var att lära oss om plattformen, steg två lära oss Philips Hue. Först i steg tre började vi utveckla vår adapterprototyp med kunskapen från det första iterationerna Slutligen intervjuade vi utvecklare i Elis och prata med dom om vad vi har kommit fram till och diskuterade fördelarna och nackdelarna vi stött på vid utveckling mot deras plattform. Vi kommer med synpunkter och saker vi anser kan förbättras och hur adaptern bidrar till ett Elis ur ett software ecosystem perspektiv.. . .

Abstract

The purpose of this essay is to develop an adapter prototype for an open energy platform and document the development process. We focus on integrating Philips Hue personal wireless lighting unto the platform Elis (Mobile services for energy eciency in existing buildings). Within the short timeframe of this study we intend to reach a level of understanding enough to make the systems communicate using our adapter prototype. Initially we study documentation and prepares a work plan. Further more we try to solve the adaptation needed for the two system to commu-nicate, this involves converting and matching up values. We will do some interviews with the developers of Elis to get the big picture of how and why they designed the platform they way it is. The research paradigm design research is a iterative met-hodology that creates milestones, develop prototypes and evaluate the work. The goal of design research is to create an artifact, in our case an adapterprototype. We made a total of four iterations where the work was divided. Step one was to learn how the platform works and step two was to study Philips Hue. At step three the implementation of our prototype with the preparatory work from the rst iterations could begin. The nal step was to interview members of Elis development team to nd out the impact of our work and to discuss the pros and cons of working with their platform. We present opinions and ndings of things we have found that can be improved. We also dene how our adapter benets Elis in a software ecosystem perspective.. . .

Innehåll

1 Inledning 1 2 Metod 3 2.1 Design research . . . 3 2.2 Forskningsansats . . . 6 2.3 Metodavgränsning . . . 7 2.4 Avgränsningar . . . 7 2.5 Metodkritik . . . 8 3 Utvecklingsprocess 8 3.1 Iteration 1 - Plattformen . . . 8

3.2 Iteration 2 - Philips Hue . . . 13

3.3 Iteration 3 - Integrera Philips Hue . . . 14

3.4 Iteration 4 - Intervjuer . . . 20

4 Diskussion 22 4.1 RQ1 - Vilka praktiska problem innebär integrationen av den trådlösa belysningen(Philips Hue) till den existerande plattformen(Elis)? . . . 22

4.2 RQ2 - Vilka praktiska möjligheter medger integrationen? . . . 24

4.3 RQ3 - Vilken problematik introducerar behovet av generalisering när man integrerar enheter mot existerande system? . . . 24

4.4 Reektion av metodansats . . . 25 4.5 Sammanfattning . . . 26 5 Slutsats 28 Referenser 29 6 Bilagor 32 6.1 DSRM-modellen . . . 32 6.2 Elis skalarkitektur . . . 33 6.3 Intervjuer . . . 34

6.3.1 Intervju med Johan Holmberg . . . 34

1 Inledning

Inom energieektivisering nns i dagens läge inga etablerade öppna plattformar. Istället erbjuder enskilda företag lösningar, t.ex. Struxware [1], som i vissa fall tillå-ter tredejpartsutvecklare att skapa applikationer via deras öppna API. Med andra ord är dagens lösningar mer att beskriva som 'stuprörslösningar' än de software eco-systems (SECO) [2] som forskning och praktik i övrigt trycker på som vägen fram. Detta kommer att successivt förändras när skiftet mot det så kallade 'sakernas in-ternet' (Internet of Things, cf. [3], också kallat 'study of cyber-physical systems', cf. [4] sker. Relaterat till software ecosystems [2], sakernas Internet har ett fo-kus på integration av enskilda enheter likväl som hela system (inklusive existerande stuprörslösningar). Det nns idag inga tecken på utvecklingen, eektiviseringen och framstegen inom mikroelektronik, nätverkskommunikation samt informationstekno-logi som pågått under de senaste trettio åren ska avstanna. Dagens processorer, nätverksenheter och andra elektroniska komponenter blir mindre, mer energieek-tiva och därmed lättare att integrera i vardagsobjekt. När dessa inbäddade system görs tillgängliga över internet kommer behovet för gemene man att ansluta sig till en mängd olika typer av enheter att uppstå( [3] s.243). Med andra ord är hetero-geniteten i den uppkopplade och starkt integrerade framtid som eftersträvas en av de rotproblem som detta område brottas med. För att överbrygga heterogeniteten i denna miljö kan öppna plattformar med ett relevant urval av tjänster inom en domän vara en lösning. Enligt Bosch [2] är en plattform en uppsättning mjukvarutjänster, produkter som baseras på samma verktyg, metoder och tekniker för sin utveckling. Problem som plattformar brottas med är att det är svårt för en plattform att vara konkurrenskraftig och hänga med i utvecklingen. Exempelvis mobila enheter är ett område där hårdvarukongurationernas komplexitet blir en källa till att kompabili-tetsproblem uppstår. Ny funktionalitet utvecklas här snabbt och möjligheterna att uttnyttja dessa kontra kompabilitet med äldre enheter skapar svårigheter och under-håll. En annan källa till utmaningar är skräddarsydda plattformar där användaren bestämmer innehållet, s.k mashups. Här måste man kunna bidra med ett relevant utbud som kan vara svårt att uppnå utan externt engagemang. Att öppna upp platt-formen kan därmed bli en attraktiv lösning. Enligt Jan Bosch övergår en plattform över till att vara ett SECO när den blir tillgänglig utanför företagets gränser [2]. Externa utvecklares bidrag till SECO:t expanderar gränserna för vad som tidigare

varit möjligt med varje enstaka tjänst för sig. För att kunna realisera detta så måste utvecklarstödet vara attraktivt för utvecklare (Guerin [5], 3.2 Platform Utility s.38). Uppnås detta kommer ekosystemet av applikationer gagna såväl användare som fö-retaget bakom plattformen får adderat värde av SECOs. I denna studie fokuserar vi på problematik som uppstår vid integration av ny hårdvara i en öppen plattform för energieektivisering. Denna plattform är en del av ett 2-årigt forskningsprojekt [6] med 15-talet industriparter, icke-kommersiella samhällsaktörer, samt tre högre lärosäten. Specikt innebär integration av extern hårdvara i denna plattform ut-veckling av en 'adapter', dvs en mjukvarukomponent som läser in data från från ett system och anpassar det till ett annat [7]. Denna studie är ett praktiskt bidrag till det existerande forskningsprojektet genom de praktiska erfarenheter av integration som studien innebär. En aspekt som forskningprojektet inte utvärderar på annat sätt än genom vår studie. Ur ett akademiskt perspektiv bidrar denna studie genom att omsätta principer för SECOs med det teoretiska ramverk vi valt. Vi angriper dessa problem ur ett externt perspektiv där vi som utvecklare kommer att jobba med plattformen som externa aktörer. Vårt mål är att integrera en produkt som erbjuder personlig trådlös belysning i hemmet. Produkten kan även skifta färg på lampenheterna, dimma och schemalägga nyttjandet. Trådlös belysning har i era fall visat sig kunna minska stress [8], öka produktivitet [9] och informera användare i ett smart hem om externa angelägenheter [10] samt energiförbrukning. De specika forskningsfrågor vi vill besvara med denna studie är:

1. RQ1: Vilka praktiska problem innebär integration av den trådlösa belysningen i den existerande öppna plattformen?

2. RQ2: Vilka praktiska möjligheter medger integrationen?

3. RQ3: Vilken typ av problematik introducerar behovet av generalisering när man integrerar externa enheter mot existerande system?

För att svara på dessa frågor samt utveckla vår prototyp kommer vår forsknings-metod att vara design research (cf. Hevner et al. 2010, Peers et al. 2007). Valen som görs under den iterativa designprocessen kommer grundas på etablerad forskning. Inom design research väger de praktiska och teoretiska bidragen lika tungt och anses båda som lika viktiga forskningsbidrag [11].

2 Metod

I det här kapitlet presenteras den metod som har valts för arbetet. Som en del av detta motiveras valet av denna metod, samt presenteras forskningsprocessen som metoden bygger på. Avslutningsvis reekterar vi på avgränsningar som gjorts i denna studie.

2.1 Design research

Som metod har vi valt design research som är den praktiska tillämpningen av de-sign science. Det nns ett samband inom den informationsteknologiska domänen mellan design-science och beteendevetenskap. Båda är avgörande för bearbeta den sammanströmmning som sker mellan organisation, beteende och informationstek-nologi. Genom Peers design research process modell(se g.1) [11] och Hevners sju riktlinjer(se g.2) [12] kan man skapa artefakter som utökar gränsen för mänsklig problemlösning och organisatoriska begränsningar. En artefakt är produkten av pro-cessen och kan vara ett koncept, metod, modell eller prototyp. Målet för denna är att uppnå ett godtagbart stadie för den denierade målbilden för processen [11]. De-sign science är utformad för att vara en problemlösande paradigm och har som mål att skapa och innovera idéer, tillämpningar, tekniska förutsättningar och produkter inom den informationssystematiska disciplinen. Metoden söker efter en lösning på ett avgränsat problem via en iterativ process istället för traditionell forskning som söker svaret på en fråga. Processmodellen vi använder oss av kallas DSRM(Design Science Research Model) [11]. DSRM-modellen(se g.1) beskriver den iterativa pro-cessen som är design research. Den har fyra insteg som visar var i propro-cessen man börjar beroende på vilket huvudmål man har med arbetet. Sedan följes denna mo-dell och itereras tills man uppnått ett godtagbart resultat i relation med projektets ursprungliga måldenition. Hevner et al. presenterar en uppsättning av sju riktlinjer som man bör följa när man utför forskning inom informations system. Dessa stödjer en i att genomföra, utvärdera och redovisa design science research resultat. Nedan följer en kort tabell om vad alla riktlinjerna från Hevner.et.al innebär. Denna tabell återkommer vi till senare för att presentera hur vi adresserat respektive riktlinje. För att analysera datan kommer vi att använda oss av Hevners tredje riktlinje om utvär-dering. Eftersom metoden är en iterativ och inkrementell så måste utvecklingsfasen

Figur 1: Peers DSRM-modell.

kunna bestämma om iterationens delmål är uppfyllda. Om de är uppfyllda så går man vidare med utvecklingen i nästa iteration. Utvärderingen i vårt fall består av enhetstester där krav ställs på funktionalitet och överensstämmelse med existerande dokumentation och implementation.

Tabell 1: Tabell över Hevners riktlinjer. Riktlinje Beskrivning

Design som en artefakt Resultatet av en design research process ska vara en artefakt som löser

ett identierat problem. Artefakten måste dokumenteras och planeras noga så den kan tillämpas och implementeras så eektivt som möjligt.

Problemrelevans Målet med design research metoden är att utveckla lösningar

för viktiga och relevanta verksamhetspro-blem. Här tittar man på värdet av att lösa problemet i förhållande till lönsamheten och eektiviteten.

Utvärdering Användbarheten, kvalitén och eektiviteten av artefakten måste kunna utvärderas. Re-sultatet måste även utvärderas i ett helhets-perspektiv i den miljö som artefakten ska le-va i. Artefakter utvärderas i termer av funk-tionalitét, fullständighet, överensstämmelse, precision, prestanda, tillförlitlighet, använd-barhet och acceptans.

Forskningsbidrag Design research kan resultera i tre olika typer av forskningsbidrag:

Forskningsgrund För att resultatet ska anses vara välgrundat måste alla designval, processer och utvärde-ringar baseras på väletablerad forskning. Att välja utvärderingsmetod betyder mycket för slutresultatet.

Design som sökprocess Design research är iterativt. Detta innebär att artefakten kontinuerligt förädlas tills dess status uppnår en tillfredsställande nivå ut-ifrån problemdenitionen. Varje cykel inom processen måste anpassas beroende på den förras resultat för att en förbättring ska ske. Problemet kanske måste delas upp i dellös-ningar och varje lösning måste testas om den gett önskat resultat och bieekter.

Kommunikation Arbetet måste beskrivas så de målgrupper som ämnas läsa arbetet kan förstå.

2.2 Forskningsansats

Vårt insteg i DSRM-modellen är en form av en målbaserad lösning, dvs steg två (g 1) . För att kunna göra välgrundade val har den första iterationen bestått av en undersökning av förutsättningarna för det praktiska arbetet. Efteråt påbörjade vi designen och utvecklingen av artefakten medan vi iterativt gick genom modellens alla steg. Våra designval grundades på relevant litteratur. Artefakten testades sedan och utvärderades för att vi skulle kunna bestämma detaljerna för nästa iteration av processen. När vi uppnått ett tillräckligt [12] resultat så avslutade vi med att publicera våra resultat. Vi har skapat en tabell likt den ovan för att beskriva hur vi förhållit oss till de sju riktlinjerna(se tabell 1) :

Tabell 2: Tabell över vårt förhållningssätt till Hevners riktlinjer. Riktlinje Beskrivning

Design som en artefakt I denna studie är artefakten den adapterpro-totyp vi utvecklar för energiplattformen. Problemrelevans Vårt verksamhetsproblem är att lösa

integra-tionen av Phillips Hue mot den energiplatt-formen.

Utvärdering Vi ska utvärdera resultatet genom att skriva testfall och att intervjua utvecklingsteamet för att kontrollera att vår lösning resulterat i något som är relevant för plattformen. Forskningsbidrag I vårt fall blir forskningsbidraget artefakten

(adaptern) och lösningen av integration mot plattformen.

Forskningsgrund Vi har läst relevanta artiklar och litteratur för att skapa insikt om hur vi ska lösa pro-blemet och motivera våra designval. Under uppbyggnaden av den energiplattform vi ska fokusera på skapades det dokumentation som vi kommer ta del av och analysera.

Design som sökprocess Vi följer denna riktlinje under en agil utveck-lingsprocess.

Kommunikation Denna studie kommer kommunicera våra re-sultat samt vår prototyp.

Eftersom design research är iterativ och inkrementell så måste varje cykel ut-värderas för att kunna bestämma om den enskilda iterationens delmål är

uppfyll-da. Om de är uppfyllda så går man vidare med utvecklingen till nästa iteration. Utvärderingen består i vårt fall av enhetstester där krav ställs på funktionalitet, överensstämmelse med existerande dokumentation och implementation. Den data vi kommer samla in för att genomföra vår studie kommer vara av följande typ:

• Dokumentation från plattformen.

• Resultat av design research processen under utvecklingsarbetet. • Resultat av testfall.

• Egna erfarenheter av utvecklingsprocessen.

Nedan följer en överblick över vilka iterationer vi studien genomför: Tabell 3: Överblick över iterationerna

Iteration Syfte Förväntat resultat Datatyp

1.Plattform Underlag för

integra-tion. Insikt och potentiellproblematik av krav på integrering.

Dokumentation och Praktiska erfarenhe-ter.

2.Hue Underlag för

integra-tion. Insikt och potentiellproblematik av integ-ration.

Dokumentation, resurser och insikt. 3.Integration Kodning av adaptern. Hue integrerad mot

plattformen. Adaptorprototyp. 4.Intervjuer Kvalitativ

undersök-ning. Bedömning av integ-rationens resultat. Dokumenterade inter-vjuer.

2.3 Metodavgränsning

Metoden design research har fokus på praktiska bidrag genom skapadet av en arte-fakt. Designprocessen är iterativ och söker lösningen på uppsatta mål. Därmed så är det svårt att bedöma hur många iterationer som behövs för att uppnå uppsatta mål och tidsbestämma arbetet.

2.4 Avgränsningar

Projektet har en tidsbegränsning på två månader. Man måste även räkna in felsök-ning av moment som inte fungerar enligt iterationens delmål. Philips Hue beskrivs

och används ur sitt ändamålsenliga sätt utan att utforska ickeociella användnings-områden och hack.

2.5 Metodkritik

Design research är en metod som använder sig av forskning och praktik tillsammans. Detta kan medföra problem när dessa två skiljer sig åt, vilket kan leda till att det blir en betoning på det ena eller andra. I vårt fall har det inte inneburit ett problem eftersom vi haft fria händer ur ett praktikperspektiv att utforska området vi stu-derat. Friheten som metoden har gett kan ses som en potentiell felkälla efter som det ökar risken för att man ändrar riktning till en som ur praktiskt perspektiv inte är relevant. Vi har undvikit detta genom att fysiskt arbeta på samma plats som utvecklarna. Därmed har vi fått kontinuerlig feedback och support under iteratio-nernas gång samt följt de riktlinjer vi etablerat [12]. När det gäller tidsbegränsningar så är det upp till de som utför studien att planera tidsåtgång och tidsbehov för varje iteration. Detta ger en bra exibilitet för metoden så att den kan skräddarsys för varje forskningsprojekt. Dock så öppnar det för att man missbedömer tidsåtgången för inplanerade iterationer vilket kan leda till en skev målbild.

3 Utvecklingsprocess

I denna sektion beskriver vi den process vi har gått igenom för att svara på våra forskningfrågor. Processen är iterativ och är baserad på Peers processmodell för de-sign research(se.g 1). Iterationerna inleds med ett stycke där problemen denieras, sedan följer en beskrivning om hur vi arbetat för att lösa problemet. Vi avslutar med att utvärdera iterationen och beskriver hur detta återkopplas till nästa iteration.

3.1 Iteration 1 - Plattformen

Den öppna energiplattformen vi kommer arbeta med kallas Elis: Mobile services for energy eciency in existing buildings. Elis-plattformen nansieras av Vinnova och är en plattform som stöder mjukvaruekosystem-tänk [2]. Tanken bakom Elis är att man ska kunna använda mobila enheter för att reglera värmen, ändra ljusbelysning och visualisera energikonsumption på ett mobilt och distribuerat sätt. Projektet

fokuse-rar på tjänstenivån och redan existerande hårdvara och infrastruktur. I stadsdelen Hyllie i Malmö nns Green Digital City som är ett projekt som drivs av Malmö Stad. Målet är att bli Sveriges mest miljövänliga stad och Hyllie är utvalt som ett pilotområde för utvecklingen av detta [6]. Elis-plattformen har som mål att stödja helhetslösningar från E.ON för lägenheter och Schneider Electric för skolor. Philips Hue är ett mindre fristående system som är mer anpassat för privatpersoner att själ-va installera i sina egna hem. Tanken är att Elis-plattformen ska kunna använda sig av dessa stand-alone lösningar med de existerande helhetslösningarna transparent. Öppna projekt som Elis-plattformen är i ständig förändring av sin egen natur. Där-för måste en överenskommelse inom projektets ramar denieras och efterföljas av de som bidrar till den, så att ny hårdvara likväl som nya tjänster kan stödjas. För att undvika konikter mellan olika subprojekt nns det versionshanteringsverktyg som till exempel Mercurial, Git, Apache Subversion för att skapa olika förgreningar. Elis-projeket ligger webbhotellet Github som använder Git. I dessa förgreningar jobbar man oberoende av varandra lokalt på sin egen gren, men kan sammanfoga till huvud-projeketet när man är klar. Vårt integrationsprojekt är en sådan förgrening. För att underlätta för externa utvecklare bör öppna projekt tillhandahålla dokumentation som beskriver plattformen och de regler som ska efterföljas vid utveckling [13]. Även så kallade referensimplementationer och andra resurser kan nnas som hjälp för den som vill arbeta mot ett öppet projekt. Om dessa resurser saknas eller är bristfälliga så försvåras arbetet med att jobba mot projektet avsevärt. Då vårt integrationspro-jekt är det första externa för huvudprointegrationspro-jektet att förhålla sig till är problemfokus i vår första iteration:

• Skapa en helhetsbild av huvudprojeketet. • Söka och studera dokumentationen. • Sätta upp sätta upp utvecklingsplattform.

• Undersökt möjligheterna för integration av Philips Hue.

För att kunna integrera ett externt projekt mot en öppen plattform så måste man skapa sig en helhetsbild av huvudprojektet Det krävs även att man kan sätta upp en fungerande utvecklingsmiljö så att man kan arbeta med projektet. När existerande dokumentation inte är tillräcklig kan det behövas en gemensam informationskanal,

såsom t.ex. ett forum för kunskapsförmedling. På detta sätt kan externa integra-tionsprojekt verka som ett sätt att validera huvudprojektets potential att verka för ett levande software ecosystem [2], något som alltså kräver mer än enbart tillgång till plattformens API. En rent API-driven diskussion för integration av system har även tidigare identierats som bristfällig [14]. Vi inledde vår utvecklingsprocess ge-nom att skapa oss en helhetsbild av Elis-plattformen och komponenterna den består av. Att få en insikt om de teknologier som plattformen använder sig av och sättet som den kommunicerar på är fundamental för att ha förståelse när plattformen lever i en distribuerad miljö. Detta gjorde vi genom att gå igenom dokumentation som skapats av utvecklingsteamet under projektets gång. När vi fått en övergripande bild av plattformen påbörjade vi installation av den arbetsmiljö som krävdes för att vi skulle kunna köra plattformen lokalt. Efter installationen så utvärderade vi vårt tillvägagångsätt och identierade ett antal punkter som vi tar upp. Elis är ett OSGI-projekt [15], skrivet i Java, som består av ett antal moduler kallade bundles som byggs med Maven[Maven]. Dessa anropar varandra enligt en hierarki bestämd i en metal. Fördelen med detta är att man kan anropa, stoppa, uppdatera och ta-bort moduler på ett distribuerat sätt under körtid [15]. Ramverket håller även reda på olika beroenden mellan bundlarna och kan därmed underhållas samtidigt som det körs. Elis använder ramverket ApacheFelix [15] som är en implementation av OSGi men det nns era. OSGi-arkitekturen är kärnan i Elis och utanpå nns skal av tjänster som består av bundles. Varje skal kombinerat med skalen längre in kan köras som ett självständigt system. Längst in nns ett kärnskal, Core Services Shell, som består av bland annat lagring och användarhanteringstjänster. Utanpå nns ytterligare tre skal som adderar tjänster till systemet i olika abstraktionsnivåer.

Större bild av denna skalstruktur nns i bilaga 7.3 , men eftersom syftet i denna sektion är att illustrera hur dessa skal sitter ihop med varandra har vi valt att inte i detalj diskutera varje skal. Publisher Shell och Consumer Shell är ett sammansatt skal. Publisher Shell är riktad åt utvecklare som ska bygga tjänster medan Con-sumer Shell är där hemstyrningssystemen kommer in underifrån. Figur 3 illusterar hur ett building management system/home management system (BMS/HMS) sy-stem kommunicerar med Consumer Shell och var våran adaptor ska ligga för att möjliggöra kommunikationen. Adaptern ska ligga mellan infrastructure adapter och BMS/HMS-boxen i gur 3.

Figur 2: Elis skalarkitektur.

Figur 3: Elis komponentarkitektur

I denna iteration var målet att skapa en helhetsbild av Elis, sätta upp utveck-lingsmiljö och undersöka möjligheterna för integration av Philips Hue. Under vårt arbete identierades tre typer av praktiska problem. Detta inkluderar bristfälligt uppdaterad installationsbeskrivning, operativsystem som inte stöds och en avsak-nad av fullständig referensimplementation. Denna studie blir ett praktiskt bidrag till Elis-projektet, men kan även ses som exempel för andra öppna projekt att beakta

Tabell 4: Matris för verktyg och tekniker använda i Elisplattformen.

Namn Beskrivning

OSGi OSGi (Open Service Gateway initiative) Är ett ramverk för Java som är gjort för att skapa dynamiska modulsystem. [15]

Apache Felix Felix är en implementation av OSGi R4 ramverket och är utvecklad av Apache Software Foundation. Felix är licensierat under Apache version,2.0. [15]

MySQL MySQL är en öppen relationell databashanterare som sköter lag-ringen av användarinformation i Elis.

Jersey Jersey är ett öppet ramverk för att skapa ?RESTful? webbtjänster. REST REST(Representational State Transfer) är ett arkitekturbegrepp för kommunikation mellan maskin-till-maskin med HTTP anrop. [16]

Apache Maven Maven är en kompilator för javaprojekt som kan ladda ner kom-ponenter under kompilation specicerade i en meta l där alla be-ståndsdelar nns beskrivna [Maven].

JSON JSON står för JavaScript Object Notation och är ett format för skicka data mellan en server och webbapplikation. [JSON]

för att främja ett eektivt software ecosystem i enlighet med t.ex. Bosch [2]. Denna typ av praktiska exempel är också till stor del utelämnat från relaterad forskning om software ecosystems, varför vår första iteration - gärna tillsammans med ytterligare studier av andra öppna plattformar - kan ligga till grund för vidare teoriutveckling inom software ecosystems. En attraktiv utvecklingsmiljö ställer krav på att API do-kumentationen så väl som arkitekturdokument och installationsdokumentation för plattformen hålls relevant vid förändring. Vi har uppmärksammat att den doku-mentationen som krävs för installation av plattformen och en beskrivning av hur man arbetar med plattformen inte alltid varit uppdaterad. Den har heller inte va-rit samlad på en webbplats eller anpassad för externa utvecklare. Ett exempel på detta är plattformens databas som efter sin tillämpning i plattformen inte ännu är dokumenterad. Detta är ett problem som vi inte har någon lösning på annat än att man i samband med utvecklingen tar tid till att hålla dokumentationen relevant. Studier har visat att en sådan metod av kontinuerlig dokumentation underlättar för potentiella intressenter av ett öppet källkodsprojekt att annamma och vidareutveck-la det [13]. Vi har kommit runt problemet genom att ta kontakt med utveckvidareutveck-lare i Elis-projeketet och fått ta del av information som inte nns dokumenterad i

nulä-get. Detta tillvägagångssätt bekräftas av (LaToza et.al.2006 [17]) som presenterar forskning som indikerar att informationsutbytet mellan människor är mer eektivt än text i en utvecklingskontext. Ett forum på en webbplats där även dokumentation för installation och API är samlad hade därför varit en lösning. Utvecklingsmiljön har en lång installationskjeda(se matris) av komponenter som samverkar för att bygga och köra plattformen. En fungerande utvecklingsmiljö kunde skapas på en av våra två datorer då operativsystemen (OS X) var samma som utvecklarna av Elis använder. I Windows 7 64 så fungerar inte installationsbeskrivningen utan att det uppstår fel beroende på OSGi-metadatan. Felet orsakar att bundlehierarkin inte kan köras. Efter intervju med utvecklarna så visade det sig vara relaterat till teckenupp-sättningens skillnad mellan de två operativsystemen Unix och Windows inte tolkas på samma sätt. Ett ytterligare förslag på lösning av detta problem kan vara att Elis-projeketet bistår med ett virtuell avbildning med hjälp av t.ex. VirtualBox [18] eller VMware Workstation [19] av ett operativsystem med utvecklingmiljön och plattfor-men installerad. Utifrån vad vi lärt oss i denna iteration kan vi dra slutsatsen att vi behöver få en förståelse av hur Philips Hue kommunicerar och fungerar. Målet är att vi i iteration 3 ska kunna implementera adaptern med kunskap från iteration 1 och 2.

3.2 Iteration 2 - Philips Hue

För att integrera Philips Hue mot Elis-plattformen krävs en förståelse för Hues API och dess funktionalitet. För att göra sig bekant med hur Philips Hue fungerar krävs det att man går igenom ett antal steg. Inledningsvis använder man dokumentation och guider tillhandahållna av Philips. Målet med detta är att skapa en övergripan-de bild av Hues existeranövergripan-de funktionalitet i relation till Elis-plattformen. Vidare är målet att identiera de specika tekniker som Hue bygger på, samt vilken testmiljö som är lämplig för att bekräfta en korrekt förståelse för Hue. För att till fullo svara mot den ovan identierade problembeskrivningen behöver avslutningsvis existerande relevanta resurser som ger tillgång till Hues funktionalitet identieras. Vidare krävs en testmiljö där man kan applicera sina teoretiska kunskaper och se hur de fysiska enheterna uppför sig. För att underlätta arbetet bör en undersökning av vilka redan existerande resurser nns för att tillämpa Hue API i ett mjukvaruprojekt undersökas. Philips Hue är uppsättning av interaktiva lampor som kommunicerar distribuerat på

ett wi-nätverk via ett protokoll kallat Zigbee Light Link [20]. Hue ansluts genom en medföljande gateway till det lokala nätverkets router. Denna fungerar sedan som brygga för all kommunikation mellan lamporna via Zigbee Light Link och det lokala nätverket. Hädanefter kommer vi kalla denna enhet för brygga. Användare upp-kopplade mot wi-nätverket kan ansluta till bryggan för att tända/släcka lampor, kontrollera ljusstyrka, ändra kulör, mättnad, skapa scheman, skapa egendenierade händelser och gruppera lamporna via exempelvis Phillips Hues egna mobila app [21]. Kommunikationen mellan applikation och brygga sker via ett REST [16] gräns-snitt och datan representeras i form av JSON-meddelanden [22]. Philips tillhan-dahåller dokumentation av sitt API samt guider för nya utvecklare på produktens hemsida [21]. Vi installerade ett antal lampor i en testmiljö under utvecklingen för att bekräfta att lamporna fungerade som förväntat. För att snabbt komma igång med att prova API och lamporna så använde vi oss av Philips medföljande API debug-verktyg. Verktyget är anpassat för REST baserade API och gav oss chans att se strukturen på de förfrågningar och svar man skickar och får tillbaka när vi ändrar status på lamporna. Som en del av iteration två låg fokus även på att identiera existerande implementationer, bibliotek, samt andra möjliga resurser av relevans. Ett komplett bibliotek som identierades på detta sätt är Jue [23]. Detta är ett Java-bibliotek som ger full tillgång till de tjänster som Hue tillhandahåller och som Philips själva rekommenderar för att bygga tjänster på Hue-plattformen. Jue-biblioteket abstraherar bort den programmeringen av HTTP kommunikation över REST som sker med Hues API. Resurser som denna kortar ner den utvecklingstid som krävs i iteration 3.

3.3 Iteration 3 - Integrera Philips Hue

Vårt nästa steg i Peers DSRM-modell(se gur 1) är att deniera och implementera vår artefakt, adapterprototypen. Vi har valt att designa vår adapter som en bund-le (se iteration 1 - Plattformen, s.10) för att efterfölja den OSGi-arkitektur som Elis består av. Vår bundleimplementation kommer bli en av komponenterna som ingår consumer-skalet, det vill säga där extern funktionalitet byggs in underifrån till plattformen(se bilaga 6.2, s.29). Adapterns design kommer att efterfölja sekventiell komponentdesign [24, s469.]. En komponent kan beskrivas som en entitet som kan

Figur 4: En översikt över hur Hue fungerar

köras oberoende av sin omgivning, används via två gränssnitt(krav/publicering) och bör inte ha något tillstånd [24, s.455]. Praktiskt innebär detta att en komponent blir återanvändbar sålänge det kontrakt som kravgränssnittet ställer på implemen-teringen uppfylls respektive de krav som Elis sätter på publiceringsgränssnittet. När

Figur 6: En komponents gränssnitt

detta utförts så har vi en bundle i Elis-plattformen som kommunicerar med Hue. Nästa steg är att implementera funktionalitét adaptern har. Uppgifterna adaptern ska sköta inkluderar att ansvara för mappning mellan funktionalitet, sköta kommu-nikationen i rätt ordning, säkerheten och omvandla data till rätt format(se tabell 5, s.17). Genom denna process och kunskapsinsamlingen i iteration 1 och 2 har vi ska-pat en grundförståelse för förutsättningarna för adapterns implementation [25][26]. Enligt Canal [25] måste vi iaktta problematik som är på signaturnivå, beteendenivå, semantisk nivå och tjänstenivå under implementering.

• Signaturnivå - problematik på signaturnivå relaterar till om alla beroenden som krävs av olika komponenter nns tillgängliga.

• Beteendenivå - den här nivån relaterar till hur komponenter kommunicerar och ödet av meddelanden.

• Semantisk nivå - på den här nivån hanteras de problem som uppstår när två identiska komponenter på gränssnittsnivå(signatur) och med samma medde-landehantering(beteende) hanterar kommunikation.

• Tjänstenivå - På tjänstenivå hanterar man problem som relaterar till tempo-rala aspekter av kommunikation(asynkron/synkron), säkerhet och pålitlighet.

Vår adapter är en komponent i form av en bundle. Skillnaden är att en bund-le och en komponent är att den förstnämnda har en manifest-l som beskriver dess innehåll och implementering. Det är med dessa manifestler man inom OSGi-arkitekturen komponerar bundles med varandra och denierar beroenden av andra bundles. Vår adapter kommer hamna i consumer-skalet, vilket denieras i mani-festet. Elis-projektet har ett skelett för hur en bundle ser ut kallad 'dummy bundle' som vi använt för att skapa adapatern. Ett annat krav för implementeringen är ja-vapaketet Elis device-api. Elis device-api är ett paket med de gränssnitt som krävs när vi implementerar våra klasser i adapterns publiceringsgränssnitt. Efter samtal med utvecklare i Elis-projeketet beslöt vi att påbörja vårt arbete med att implemen-tera en mjukvarugateway. En gateway är den enhet som håller samman och sköter kommunikationen mellan de fysiska enheterna. Vår gateway heter HueGateway och har mappats till Jue-bibliotekets klass HueBridge som uppfyller kravgränssnittet. HueBridge kommunicerar med Philips Hue api som i sin tur styr det fysiska lamporna (se gur7). Detta tillvägagångssätt uppnår både kraven som ställs av publicerings-gränssnittet(via device api) och krav-gränssnittet via HueBridge och Jue. Figur 7 illustrerar detta. Det innebär att vi nu har integrerat Hue till Elis och kan nu fo-kusera på att implementera funktionalitét och typkonvertera den data som skickas mellan systemen. Vi tittade på de nivåer av problematik som vanligtivs uppstod

Figur 7: Adaptern och dess beroenden

vid kodning av adaptorer som Canal beskrivit. På signaturnivå hittade vi skillnader på vårt kravgränssnitt och publiceringsgränssnitt. Detta innebär att anrop mellan systemen inte kan fungera utan viss konvertering av datan som skickas genom ad-aptern. När klassen HueGateway instansieras händer två saker. Först och främst hämtas namnet och IP-adress från från Hue och sparas för att kunna skilja HueGa-teway från andra gaHueGa-teways. Informationen sparas även i en databas för persistent

lagring. Andra steget är att en process som hämtar och lägger till alla lampor i en lista anropas. Varje lampa är ett så kallat FullLight objekt som är Jues namn på detaljerad information om en specik lampa. Ett device objekt av typen lampa i Elis ser annorlunda ut och därför måste en konvertering utföras. Därför implemen-terade vi klassen HueLight. Denna ärver av device-api ColoredLamp, PowerSwitch och Dimmer. HueLight-klassen implementerar gränsnitten alltså färgbytande-lampa, strömbrytare och dimmer för att säkerställa att den stödjer alla anrop som relaterar till en lampenhet. Konverteringen från ett FullLight-objekt till ett HueLight, hand-lar kortfattat om att konvertera värdena i ett FullLight objekt till ett HueLight eller tvärtom. Därefter returneras ett HueLight till den anropande metoden eller tvärtom. Ett exempel på detta kan vara HueLight som använder ett yttal mellan 0-1 för att ställa ljustyrka/dimning (0 min, 1 max) medans FullLight använder ett heltal mel-lan 0-255 (0 min, 255 max). Ett något större problem uppstår vid konvertering av färger mellan de två systemen. Att ändra färg på en Philips Hue lampa går att göra på ett antal olika sätt, se tabell 5.

Tabell 5: Överblick färgskalor

Namn Beskrivning Värde

Color-Temperature Mired färgtemperatur (i sin tur akronym för micro reciprocal), en alternativ måttenhet för färgtem-peratur.

Mellan 153 (6500K) till 500 (2000K).

XY X och Y kordinaterna i ett CIE

färgåtergivningsystem [27] Lista med två yttal mellan 0-1,ena värdet för X och andra för Y koordinaten.

Hue Ändrar kulör på lampan. Heltal mellan 0 och 65535 där bå-da värdena är röd. 25500 är grön och 46920 är blå.

Saturation Ändrar mättnad på lampan Heltal mellan 0-255 där 0 är vit och 255 är mest färg.

Brightness Ändrar ljusstyrkan på lampan. Heltal mellan 0-255 där 0 är låg styrka och 255 är max.

Dessa sätt att ändra färg skiljer sig från den metoden som Elis-plattformen valt att specicera i sitt gränssnitt ColoredLamp, som vi baserat HueLight på. Hue-Lights metod att hämta och sätta färg använder sig istället av RGB. RGB står för

red, green, blue och är en annan mycket utbredd färgmodell [28]. Man kan använda Java klassen Color för att sköta omvandlingen mellan Hue, Saturation och Bright-ness(HSB) till och från RGB [29]. Colors metod HSBtoRGB tar tre yttal i form av hue, saturation och brightness. Saturation och brightness är yttal mellan 0.0 och 1.0. Hue kan vara vilket yttal som helst, detta konverteras sedan även till det ett tal mellan 0.0 och 1.0. Metoden returnerar ett heltal som man sedan kan plocka ut RGB värden ur. Som tabell 5 illusterar använder sig Hue av värden mellan 0-255 för att visa mättnad och ljusstyrka. Dessa värden konverteras enkelt genom att dela dom på 255. Samma görs med kulören som delas på 65535. Denna konvertering ger tre yttal mellan 0.0 och 1.0 att skicka in till HSBtoRGB metoden som konverterar yttalen till tre heltal som representerar färgerna RGB. På signaturnivå har vi gjort ertalet liknade lösningar som ovan för att integrera ihop de två systemen. T.ex. har plattformen gränsnittet Dimmer, vars metod setDimLevel sätter ljusstyrka på en lampa med ett yttal mellan 0.0 och 1.0. Denna metod implementeras genom att mappa mot Hues brightness, efter en konvertering från 0-255 till 0.0-1.0, för att ställa dimnivå. Implementationen som vi beskriver ovan har möjliggjort att vi kan kontrollera de esta funktioner som relaterar till lampornas funktion. Detta inklude-rar autentisering av användare, anslutning till brygga, insamla anslutna lampor och deras status samt manipulering av dessa(av/på, toggle, dimmer, färg). Återstående funktioner som skulle göra adaptern fullständig består av schemaläggning. Dessutom nns det ingen automatisk hantering av när lampornas status ändras vilket gör att tredjepartsutvecklare själva måste implementera detta. En sådan funktionalitét är relevant för miljöer där lampornas status förändras ofta(se bilaga 6.3.2, intervju med Ulrik Eklund). Sammanfattningsvis så har denna iteration denierat vår ad-apter och beskrivit den problematik som uppkommit under utvecklingen. Vi har motiverat och beskrivit hur vi anpassat vår situation för att kunna integrera Philips Hue till Elis som en bundle. Vidare beskrivs de steg som tagits i processen och hur problem tacklats. Resurser som Jue-biblioteket och Philips Hues väldokumenterade webbplats för nya utvecklare har underlättat denna iteration. Denna dokumentation är ett exempel på hur bra underlag har sparat många timmars utvecklande. Då vi haft begränsat med tid är inte adapterprototypen helt fullständig. Vi har överlämnat vår kod till Elis utvecklare som kommer använda koden som underlag för framtida apdaptrar.

Tabell 6: Överblick iteration 3

Iteration Problematik/Syfte Lösning

1.Denition av

adapter Hur adaptern skulle utformas föratt på bästa sätt passa in i platt-formen.

Adaptern utformas som en bundle placerad i consumer-skalet.

2.Utformning av

adapter Vad som krävdes för att kopplaadaptern till de olika systemen. EttHue och publiceringsgräns-kravgränssnitt mot snitt som implementerade device-api mot Elis.

3.Denition av implementa-tionsprocess

Vilka problem kunde uppstå

un-der implemenering. Signaturnivå, beteendenivå,semantisk nivå, tjänstenivå. 4.1

Implementa-tion funkImplementa-tionali- funktionali-tét

Implementera de funktioner Hue

erbjuder. De funktioner vi hade attkonvertera var de som ha-de skillnaha-der på signaturni-vå. Detta innebar i stort sett all funktionalitét.

4.2

Typkonver-tering. Omvandla data för användningmed olika standarder. Denna skedde samtidigtsom funktionalitét imple-menterades. Problematiken här var att översätta värden för färgåtergivning. Se 5.

3.4 Iteration 4 - Intervjuer

Under arbetet med iteration 1 undersöktes plattformen Elis för att kartlägga dess struktur och design. Denna iteration söker svar på hur relevant en integration av Philips Hue är till Elis-plattformen och varför. Vi undersöker var Elis-plattformen existerar i ett sakernas internet och SECO perspektiv och får feedback på våra resul-tat. För att undersöka designen och problematiken gällande Elis beslutade vi oss för att göra intervjuer. Intervjuerna gjordes med Johan Holmberg(lead developer) och Ulrik Eklund(software architect) som valdes ut eftersom de har stor insikt i Elispro-jektet. Dessa intervjuer hade som uppgift att ge insikt om samt feedback gällande vår prototyp och våra resultat. I nedanstående stycke är en sammanställning av några av de frågor och svar som kom upp under intervjun. För en fullständig transkriberad version, se intervjubilaga. Vi intervjuade Johan och Ulrik om den utvecklingsprocces vi gått igenom och diskuterade varför plattformen och utvecklingsmiljö

inlednings-vis var svår att installera. Både Ulrik och Johan påpekade att dokumentation av installationen av plattformen inte varit prioriterad då fokus legat på att program-mera för att hålla tidsramarna i projektet. Ulrik berättade att dokumentationen riktad mot utomstående utvecklare av adaptrar inte ännu var prioriterad. Istället har fokus legat på att skapa en så enkel plattform för tredjepartsutvecklare som möjligt som ska bygga tjänster och appar uppe på plattformen. Båda anser att do-kumentering av öppna plattformar kan vara problematiskt. Detta beror främst på att stora delar av implementationen är lämnad öppen för tolkning. Öppenheten mås-te balanseras mot enkelhemås-ten att börja utveckla mot plattformen och möjlighemås-ten att utöka systemet med nya enheter och tjänster. Ulrik menar att man försökt göra plattformen enklare genom att utelämna viss funktionalitet som de underliggande systemen har. Det ska vara så enkelt som möjligt och stoppa in system som Philips Hue. Johan säger att utvecklarna i projektet i framtiden kommer lägga mer tid på både dokumentation och själva koda adaptrar för underliggande system som E.ON och Schnieder Electrics Struxware använder. De kommer även fokusera på att testa API och göra eventuella ändringar om det visar sig behövas. Johan menar att den studie vi genomför också kommer vara ett stöd för dom, då vi som externa utveckla-re kan komma med input på vad vi anser behöver förbätras. Om plattformen skulle varit ett kommersiellt projekt skulle en test-plattform varit prioriterad menar Ulrik. Detta skulle snabbstarta vår utveckling och underlättat mycket. När vi frågade vad dom såg för framtida lösningar där Philips Hue kan komma till användning ck vi era intressanta svar. Johan föreslog att lampornas färg kan återspegla bostadens energianvändning, där en grön färg indikerade ett energibesparande hem. Även att styra lampor, stämningsbelysning och spel var förslag han listade. Ulrik menar att hörselskadade kan få användning av integrerade Hue lampor som en visuell infor-mationskanal vid till exempel dörrklockor eller larm. Denna intervju har gett oss en insikt i hur utvecklarna i Elis resonerat kring designval och varför dom tagit de beslut dom gjort. Många av de frågor vi ställt och upptäkter vi gjort har att göra med att plattformen fortfarande inte är färdig. Dokumentationen har varit svår att skriva på grund av den öppenhet man vill åstadkomma och samtidigt har fokus legat på annat håll än vid utveckling av adaptrar för existerande underliggande system.

4 Diskussion

Detta kapitel kommer undersöka resultatet av vår studie relaterat till existerande forskning. Integrationen av två heterogena system i en öppen kontext är något som börjat få uppmärksamhet i och med sakernas internet [10]. Det nns ännu inga öppna plattformar som främjar utvecklingen av tredjepartstjänster som gynnar domänen hemautomation. Detta skapar en situation där det är svårt för tredjepartsutvecklare och kunder att inte bli låsta till en specik lösning. Elis är en öppen plattform som ämnar att lösa denna knut och vår studie har haft som mål att undersöka hur man kan integrera ett utomstående system för att främja plattformens tjänsteutbud inom sin domän. Elis är en energiplattform och därför kan det vara relevant för plattformen att ha stöd för Philips Hue. För att införliva stöd för Hue i Elis så skapade vi en adapterprototyp som är denna studies forskningbidrag tillsammans med den utvecklingsprocessen vi gått igenom ur en design research synvinkel. Utifrån design research perspektiv och med Peers [8] DSRM-modell denierades delmål och iterationer som resulterade i ett underlag för hur vi skulle skapa vår adapter (se iteration 1,2,3). Utmaningar som uppstod var relaterade till översikt, föränderlighet och komplexitet i Elis.

4.1 RQ1 - Vilka praktiska problem innebär integrationen av

den trådlösa belysningen(Philips Hue) till den

existeran-de plattformen(Elis)?

För att kunna utveckla mot plattformen så krävs det att man bekantar sig med platt-formens utvecklingsmiljö och teknologier. Installationen är omfattande. Vid tiden av studiens genomförande fanns det ertalet liknande installationsdokument som inte hade tydligt denierade krav. Vi försökte bland annat installera plattformen på en Windows 7 dator utan framgång. En tydligare plats för installationsdokument, där man uppdaterar dessa istället för att skapa era vore lämpligt. Vi föreslår även att utvecklarna skapar en virtuell avbildning där en testmiljö med en referensimplemen-tation av plattformen nns. Under intervju med Elis systemarkitekt Ulrik Eklund framkom det att, om projektet drivits som ett kommersiellt projekt så skulle man erbjudit utvecklarna någon typ av prototyp eller molnbaserad testplattform att ut-veckla mot(se intervjubilaga). Detta skulle minskat den uppstartstid som krävs för

att komma igång med utvecklingen. Jan Bosch menar att det är hjälpmedel som detta som underlättar för utvecklare, och att de är en av huvudfaktorerna för att en plattform ska bli attraktiv[1]. Plattformen använder sig av modulär arkitektur för att dela upp systemets funktionalitet i mindre utbytbara moduler. Vi hade ingen tidigare erfarenhet av programmering av modulära system och hade svårigheter att förstå helheten som alla moduler skapade tillsammans. Dokumentation av modulä-ra system har enligt Taulavuori ingen känd standard [30]. Detta gör att dokument och illustrationer som skapats internt i olika projektet ofta skiljer sig åt. Vi hade gärna sett en guide till utveckling mot plattformen med fokus på att skapa för-ståelse om hur modulerna hänger samman samt vilka som behövs och vilket syfte dom uppfyller. Eklund et al [14] skriver att infrastrukturen i en plattform bör va-ra dokumenteva-rad med förklava-rande beskrivning av alla tillgängliga komponenter och enheter. Detta är något vi inte kunnat ta del av då det ännu inte är sammanställt i projeket. En lista av denna typ vore användbart för oss när vi ifrågasatte vilken de olika modulernas funktion var och hur de hänger samman. Elis är designad på ett generellt sätt för att tillåta att externa system och produkter ska kunna integre-ras(se bilaga 2. Intervju Eklund). Det betyder att plattformen inte alltid är tydliggör i detalj hur implementationen ska utformas. Man lämnar det medvetet öppet för ut-vecklarna att själva bestämma. Vi hade under utvecklingen av adaptern problem med hur klasser skulle implementeras och metoder fungera på grund av de diusa riktlinjerna. Colored lamp heter den klass i Elis Api:t som vi har mappat Philips Hue till. Denna klass är skapad för just detta ändamål men det har ändå krävts en del anpassning för att få dem att fungera med varandra. Colored lamp har metoden setColor som använder RGB-skalan för att byta färg medan Philips Hue använder sig av färgschemat HSB [31]. Vi har fått göra en konvertering mellan dessa värden med hjälp av Javas inbyggda klass Color [29] (beskrivet i iteration 3). Detta är två exempel på när generell design skapar extra arbete vid integration av två system. API-dokumentation som nns tillgänglig var ett stort stöd, men en referensimple-mentation som visar hur man skulle kunna göra vore användbart. Vi hade hjälp av en likande adapter i plattformen riktad mot ett annat system, men den var inte uppdaterad efter den senaste versionen av plattformen. Slutligen vill vi understryka att Elis är en plattform som under denna studie inte ännu är släppt för release. Det betyder att dokumentationen inte heller är färdig, och i vissa fall kanske inte heller

prioriterad. Vi har fått använda den information som fanns tillgänglig och poäng-terar att man bör lägga stor vikt på dokumentation av ett öppen energiplattform av denna typ. Dokumentation om installation, guide av komponenter/moduler och referensimplementation anser vi bör vara prioriterade.

4.2 RQ2 - Vilka praktiska möjligheter medger integrationen?

Med hjälp av den adapterprototyp vi implementerat, har vi vid tester kunnat kon-trollera Philips Hue enheterna med Elisplattformen. Vi har utvecklat funktionerna för att tända, släcka, dimma och byta färg på enheterna. Värdet med detta blir tyd-ligast när man i ett senare stadie kan kombinerar lamporna med andra funktioner i plattformen. Under intervjuerna med utvecklarna framkom det ertalet använd-ningsområden där Philips Hue skulle ge ökat värde. Exempel som togs upp var att lamporna kan användas som information och ett hjälpmedel för döva i hemmet. Man kan med hjälp av färgkoder visa om det är någon som ringde på dörren, telefonen eller alarm(se intervju bilaga). Men det största värdet av vår studie kommer inte i form utav integrationen utan av den process som lett fram till vår implementation. Mycket arbete i studien relaterar till förståelse för hur en integration skulle kunna fungera i denna miljö utan några särskilda hänvisningar. För att kunna handskas med detta har vårt teoretiska ramverk hjälpt oss [12] [11]. Med DSRM och design research ramverkets 7 riktlinjer skapades våra iterationer och vårt förhållningssätt till vår designprocess. Resultatet av dessa och vår slutsats hoppas vi kan bidraga till ett underlag för utformandet av ett bättre stöd till framtida integrationer. Elisplatt-formen har under studien fått agera software ecosystem tack vare att vi som externa utvecklare har haft möjlighet att programmera vår adaptor mot den. Detta en väg mot utökad funktionalitet i plattformen. Utbudet av funktioner och egenskaper är en av drivkrafterna bakom uppkomsten av ett software ecosystem(Bosch s.111) [2].

4.3 RQ3 - Vilken problematik introducerar behovet av

ge-neralisering när man integrerar enheter mot existerande

system?

I våra intervjuer med Ulrik Eklund och Johan Holmberg (se bilaga 1.) bekräftades vår uppfattning om att man valt att designa generellt. Målet med detta är att ha

en så öppen plattform som möjligt där begränsningarna är få. Tyvärr får man även nackdelarna med en öppen plattform:  Den största fördelen är att du kan göra vad som helst med den. Det är också den största nackdelen med den naturligtvis. Ju mer generellt det är, ju svårare är det att göra saker enkel (Johan Holmberg,utvecklare Elis, se intervjubilaga). Dessutom kom det fram under intervju med Eklund att man fokuserat på det ska vara enkelt att bygga tjänster ovanpå plattformen.  Enkelhe-ten underifrån har inte varit fokus (Eklund, bilaga 2). Därför blir en studie som denna extra relevant som indikator på vilken problematik som riskerar att uppstå för utomstående aktör. Resultaten kan alltså peka på vad som kan förbättras i Elis för utomstående aktörer och integration mot plattformar generellt ur ett design re-search perspektiv. Vår erfarenhet av att jobba med Elis är att det tidvis har varit svårt att anpassa oss till den struktur som etablerats. Elis har till exempel en klass för att identiera varje enskild enhet som kommuniceras med. Det är upp till utveck-laren att bestämma hur denna implementeras just för den ska vara så generell som möjligt. Detta är ett exempel på hur generalisering skapat en mödosam situation då en Hue-enhet endast identieras med en enkel strängvariabel. Vi ck lägga ner extra tid på att förstå och skapa dessa identierare för alla klasser och vid varje identikation behöva hämta ut vår strängvariabel från identierarklassen.

4.4 Reektion av metodansats

Design Research [12] skiljer sig åt från de forskningsmetoder vi tidigare studerat. Fo-kus ligger på det praktiska bidraget, vår adapterprototyp och utvecklingsprocessen som genomfördes. Det fanns därför en viss inlärningströskel, men vi anser att meto-den varit ett bra val för att utföra vår studie. Det primära bidraget metometo-den tillfört studien har varit i form av ett systematiskt arbetssätt och en iterativ process. Vidare har DSRM [11](se g.1) varit ett stöd för stunder där utveckling i annat fall kan stan-na upp. Iterationerstan-na kan vara svåra att bestämma både tidsmässigt och målbilden med en iteration kan förvrängas. Tiden för studien var begränsad och vi ck lägga mer tid på kunskapsinsamling och installering av utvecklingsmiljön än planerat. Vi anser att design research har tillåtit oss svara på våra två första forskningsfrågor och våra resultat kan bidra till forskningsområdet software ecosystems samt utveck-lingen av en adapter till ett sådant. Vår tredje forskningsfråga besvarades med en kvalitativ metod i form av intervjuer med medlemmar i forskningsprojeketet Elis

samt utvärderingen av iteration 3, där vi implementerade adaptorn.

4.5 Sammanfattning

Ur ett sakernas internet [3] perspektiv så nns det fortfarande många utmaningar och möjligheter för innovation. Elis är en öppen plattform inom domänen för energi och hemautomation. Philips Hue är en stuprörslösning på en automation av hem-mabelysningen. Med hjälp av design research har vi undersökt förutsättningarna och skapat en adapterprototyp för att integrera Philips Hue till Elis. Vi har även beskrivit de tillvägagångssätt vi använt oss av och utmaningar vi stött på under vårt arbete. Vårt bidrag till Elis är vår adapterprototyp och vårt kunskapsbaserade bidrag är hur en extern aktör kan gå tillväga när man integrerar ett system till en plattform i en öppen källkodsmiljö. På nästa sida nns en tabell över de bidrag vi anser vi bidragit med i vår studie.

Tabell 7: Överblick över bidrag

Nr. Beskrivning Bidrag

1 Att arbeta med Elis som

tredjepart. Vår studie är ett bidrag till Elis-projektet ur SECO-perspektiv eftersom vi är de första externa utvecklarna som jobbar med plattformen. De erfarenhe-ter vi delar med oss av i denna studie kan leda till förbättringar när det gäller skapa ett software eco system.

2 Integration av Philips Hue Ger ökat värde i form av relevant funk-tionalitét till plattformen ur energiper-pektiv.

3 Vår artefakt,

adapterproto-typen Koden för vår adapterprototyp, repre-senterad som en bundle, kan användas som exempel för framtida adaptrar ut-över Philips Hue.

4 Integration ur ett design

re-search perspektiv Vi har beskrivit hur man kan utföra enintegration ur design research perspek-tiv.

5 Påverkan på projektet. Elisprojektet har gjort strukturmässiga ändringar samt uppdateringar av käll-koden som direkt resultat av studien. Ett exempel är det som tagits upp i diskussioen (se 4.3, s.25) angående de-viceidentier, som nu är borttagen ur Elis källkod.

6 Dokumentationen har va-rit bristfällig(ej uppdaterad, ej komplett, motsägelsefull och spridd på era platser) mycket på grund av att pro-jektet fortfarande är i ut-vecklingsfasen.

Vi har beskrivit problematik och för-slag på förbättringar.

5 Slutsats

Denna studie har fokuserat på att ta reda på det praktiska problem som uppkommer vid utveckling av en adapter mellan en öppen energiplattformen Elis och Philips Hue. Vilka möjligheter bidrar integrationen med och vilken problematik behöver man hantera. Utifrån de iterationer vi gjort genom design research modellen som vår forskningsmetod har vi kunnat skapa en adapterprototyp för Elis-plattformen utan någon erfarenhet av liknande arbete. Vi har även poängterat och gett förslag på för-bättringar till underlag angående framtida integrationsprojekt till Elis-plattformen för att underlätta dessa. Med intervjuer har vi undersökt integrationens verkan på Elis, för att undersöka arbetets relevans för Elisplattformen. Adapterprototypen är vårt konkreta bidrag och vår beskrivning av arbetet resonerar kring hur vi gjort och hur processen kan förbättras. Intervjuerna bekräftar studiens relevans för Elis och liknande integrationsprojekt.

Referenser

[1] Schneider-Electric, StruxureWare Software. [Online]. Avai-lable: http://www2.schneider-electric.com/sites/corporate/en/solutions/ struxureware/struxureware-applications.page

[2] J. Bosch, From software product lines to software ecosystems, Proceedings of the 13th International Software Product Line Conference, pp. 111119, 2009. [Online]. Available: http://dl.acm.org/citation.cfm?id=1753235.1753251

[3] F. Mattern and C. Floerkemeier, From the Internet of Computers to the In-ternet of Things.

[4] E. A. Lee, Cyber physical systems: Design challenges, EECS Department, University of California, Berkeley, Tech. Rep. UCB/EECS-2008-8, Jan 2008. [Online]. Available: http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/ EECS-2008-8.html

[5] R. Guérin and U. Pennsylvania, Functionality-rich Versus Minimalist Plat-forms : A Two-sided Market Analysis, vol. 41, no. 5, pp. 3643, 2011.

[6] Medea. Elis: Mobile services for energy eciency in ex-isting buildings. [Online]. Available: http://medea.mah.se/2012/11/ elis-mobile-services-for-energy-eciency-in-existing-buildings/

[7] Wikipedia. (2013) Adapter (computing). [Online]. Available: http://en. wikipedia.org/wiki/Adapter_(computing)

[8] J. Snyder and M. Matthews, Moodlight: Exploring Stress Management through Interactive Ambient Light. [Online]. Available: http://pac.cs.cornell. edu/rhythms/les/moodlight-jaime.pdf

[9] J. Fortmann, T. Stratmann, Claudus, S. Boll, B. Poppinga, and W. Heuten, Make me move at Work! An Ambient Light Display to Increase Physical Ac-tivity, 7th International Conference on Pervasive Computing Technologies for Healthcare and Workshops, 2013.

[10] M. Popa and A. Gambutan, Smart Homes. A Solution for a Smart Lighting System, 5th International Symposium on Applied Computational Intelligence and Informatics, 2009.

[11] K. Peers, T. Tuunanen, M. a. Rothenberger, and S. Chatterjee, A Design Science Research Methodology for Information Systems Research, Journal of Management Information Systems, vol. 24, no. 3, pp. 4577, Dec. 2007. [Online]. Available: http://mesharpe.metapress.com/openurl.asp?genre= article\&id=doi:10.2753/MIS0742-1222240302

[12] R. H. von Alan, S. T. March, J. Park, and S. Ram, Design science in informa-tion systems research, MIS quarterly, vol. 28, no. 1, pp. 75105, 2004.

[13] B. Dagenais and M. P. Robillard, Creating and Evolving Developer Docu-mentation : Understanding the Decisions of Open Source Contributors, pp. 127136, 2010.

[14] U. Eklund, C. M. Olsson, and M. Ljungblad, Characterising Software Plat-forms from an Architectural Perspective, pp. 25.

[15] N. Bartlett, OSGi In Practice, 2009.

[16] L. Richardson and S. Ruby, RESTful Web Services. O'Reilly Media, 2008. [Online]. Available: http://books.google.se/books?id=XUaErakHsoAC

[17] T. D. Latoza, G. Venolia, and R. Deline, Maintaining Mental Models : A Study of Developer Work Habits, pp. 492501, 2006.

[18] Oracle, Welcome to VirtualBox.org! 2014. [Online]. Available: https: //www.virtualbox.org/

[19] VMWare, VMWare Workstation, 2014. [Online]. Available: http://www. vmware.se/

[20] Z. Alliance, Zigbee Light Link Standard, v1.0. 2012.

[21] P. Electronics, Philips hue API, 2004-2013. [Online]. Available: http: //developers.meethue.com/1_lightsapi.html

[22] D. Crockford, The application/json Media Type for JavaScript Object Notation (JSON), 2006. [Online]. Available: http://tools.ietf.org/html/rfc4627 [23] Q42, Jue Documentation, 2013. [Online]. Available: https://github.com/

Q42/jue

[24] I. Sommerville, Software Engineering, 9th Edition. Pearson, 2011.

[25] C. Canal, J. M. Murillo, and P. Poizat, Software Adaptation, L'objet, vol. 12, no. 1, pp. 931, Mar. 2006. [Online]. Available: http://objet.revuesonline.com/ article.jsp?articleId=7948

[26] G. Couloris, J. Dollimore, T. Kindberg, G. Blair, A. K. Bhattacharjee, and M. Soumen, Distributed Systems, Concepts and design, 5th Edition. Pearson, 2012.

[27] P. Electronics, Philips hue API, Core concepts. [Online]. Available: http: //developers.meethue.com/coreconcepts.html#color_gets_more_complicated [28] Wikipedia, RGB color model, 2014. [Online]. Available: http://en.wikipedia.

org/wiki/RGB_color_model

[29] O. J. Doc, Class Color, 2014. [Online]. Available: http://docs.oracle.com/ javase/7/docs/api/java/awt/Color.html#getRGB()

[30] A. Taulavuori, Component documentation in the context of software product lines. VTT Publications 484, 2002.

[31] P. Electronics, Philips hue API, 2004-2013. [Online]. Available: http: //developers.meethue.com/1_lightsapi.html

6 Bilagor

6.1 DSRM-modellen

6.2 Elis skalarkitektur

6.3 Intervjuer

6.3.1 Intervju med Johan Holmberg

Intervju med: Johan Holmberg, lead developer i Elisprojektet. Ämne: Integration av Philips Hue till Elis.

Ansvariga: Joakim Lithell, Per Johansson. Datum intervju: 2014-05-15

Datum transkribering: 2014-05-15

Joakim Lithell: Vi har arbetat med att implementera Philips HUE och märkt att det nns den ganska komplex struktur i Elis. I vårat fall ville vi bara bygga en adaptor för en lampa som skulle kunna byta färg. Men det krävde ju en del imple-mentation av klasser som identiers till exempel. Vad är tanken med dom? Är det något som har med säkerheten och göra?

Johan Holmberg: Identiera nns till för att vi inte vet hur en enhet identi-era av sitt underliggande system. Därför har vi valt att abstrahidenti-era bort den biten och låter det vara upp till utvecklarna av adaptern. I många fall behövs den inte alls, i andra fall är dem ganska komplexa.

Joakim Lithell: Hur har ni tänkt dokumentera den biten? När det är så pass generellt är det ju svårt och dokumentera något som skiljer sig så mycket.

Johan Holmberg: Japp, det är det. Det vi tänkt skriva är att den är så pass generell att det är upp till digöch skriva, och vi har inte tänkt skriva mycket mer än så. Jag vet inte riktigt hur man skulle kunna göra på ett annat sätt, det är ett problem med alla system som är stora och generella Det är svårt och förklara det på ett bra sätt.

Joakim Lithell: Vi har märkt att det är rätt svårt och komma igång med ut-veckling mot plattformen. Har ni någon tanke på ett sätt där utvecklare kan komma igång snabbare med någon mockup version?

Johan Holmberg: Dels nns våra enhetstester som i sig är en form av doku-mentation Där nns även mockobjekt. Vi har även en slags början på att ha ett Dummy projektsom är ett skelett men det har vi inte hunnit hålla vid liv, det är fortfarande nedprioriterat.

Joakim Lithell: Vi har ju märkt att det nns dokumentation men det är många ställen där det nns luckor. Är detta något som kommer prioriteras mer mot slutet? Johan Holmberg: Vi hoppas det.

Joakim Lithell: Hur kommer den dokumentation hållas uppdaterad när platt-formen växer?

Johan Holmberg: Vi är snart i ett lägga i plattformsprojektet där det inte ska få växa mera. Då har vi sagda att vi är färdiga med själva plattformen. Det vi kommer göra då är att implementera er adapterar och liknande.

Joakim Lithell: Okej, så ni ska implementera adaptrar?

Johan Holmberg: Ja, och använda den insikt vi fått med att faktiskt dokumentera hur man gör saker och varför man gör saker.

Joakim Lithell: Ser du något värde i att vi implementerar en adapter för Philips HUE mot Plattformen?

Johan Holmberg: Jag ser era värden, även som HUE som i egen enhet. Den kan saker som det nuvarande system inte kan. Den kan även användas till mer än bara tända och slänka, det är lite mjukare värden också som är glädjefullt att an-vända som kan anan-vändas som en murbräcka in för att få saker att upplevas som trevligare för användaren vilket man ofta missar. Jag ser också ett stort demo-värde att koppla ihopa ett mer teknolt system som Elis där fokus är mer på att få saker gjorda, med HUE som är mer lekfullt och att få dom att prata med varandra på ett sätt som idag inte går. Det kan bli väldigt häftigt. Jag ser också en fördel med att

låta något annan än vi utvecklare i Elis utveckla en sån här adaptor för att kunna använda input på vad som är enkelt och vad som är svårt och göra. Och eventuellt tweaka(ändra) system eller något api. Och faktiskt få veta vad som behöver doku-menteras.

Joakim Lithell: Du påstod att Elis-plattformen var generell, vi anser det sam-ma. Det är ibland otydligt om vad som ska implementeras i vissa klasser. Ser du någon fördel med detta?

Johan Holmberg: Den största födelen är att du kan göra vad som helst med den. Det är också den största nackdelen med den naturligtvis. Ju mer generelt det är, ju svårare är det att göra saker enkelt. Så är det tyvärr. Det vi har fått fokusera på är sättet att representera objekt och sätt att kommunicera på ett standardiserat sätt. Det är svårt. Fördelen med ett mer generellt system är ju att du kan få era saker att prata med varandra som vanligtvis inte går.

Joakim Lithell: Hur tror du man kan hjälpa utvecklare att överkomma komplexi-teten i framtiden?

Johan Holmberg: Tydligare dokumentation, er exempel och låta apierna i platt-formen itereras ett varv till för att se vad man kan skala bort och vad man kan förtydliga. Ni kan till Ulrik ställa frågor om IoTA, en arkitektur som vi har haft och förhållt oss till men inte följt så skarpt. Vi har hamnat med med något sorts middleware tänk, även om vi haft det som mål.

Joakim Lithell: Per Johansson, under din installation stötte du på problem med installationen av plattformen, vad var det för problem?

Per Johansson: När jag installerar bundlarna med felix, så har ju dom en re-ferenstruktur där jag får många fel. Men sen när jag listar dom får jag upp att dom är aktiva. Så då har jag undrat på om dom fungerar eftersom jag får upp listan på att dom är aktiva trots att fel genereras när dom körs. Och sen när det läggs in i Eclipse, får jag fel med super-pom referenserna, och det är weard, det borde jag

kunna lösa men det räcker inte med att bara ändra referensen.

Johan Holmberg: Just super-pom är problemet är spännande, du kör Windows va? Per Johansson: Ja.

Johan Holmberg: Jag har märkt också va, att det blir ofta problem när man går från en Unix-miljö till en Windows-miljö.

Per Johansson: Jag har funderat på om det är någon teckenuppsättning?

Johan Holmberg: Ja det är det jag funderar på också. Jag har märkt när man har projekt och det gäller alla projekt även hobby projekt så blir det ofta problem när man går över till windows eftersom det ofta blir sökproblem och sådana grejer eftersom det hanteras inte på samma sätt. Det nns vissa sådan diskrepanser som gör att det inte fungerar lika bra i Windows.

Joakim Lithell: Så plattformen som det är nu är inte anpassad för Windows? Johan Holmberg: Den är skriven i Linux och Mac OS/x liksom. Ingen av oss som har skrivit den har skrivit i Windows. Vi har inte testat i Windows faktiskt. Joakim Lithell: Det kan vara en parentes i framtida dokumentation att det in-te är in-testat i Windows.

Per Johansson: Ja jag pratade med Marcus och han sa att han aldrig sett felet förut och att man skulle söka på google för en lösning.

Joakim Lithell: Där kommer det in också att det är en sak att sätta upp hela plattformen när man behöver den, bara för att utveckla en adapter kanske man inte behöver hela plattformen.