Resumé. marts, 2012 Version 1.0

Transkript

1 - - -

2 Resumé marts, 2012 Dette notat har et overordnet formål om at belyse og kvalificere aspektet og vigtigheden omkring interoperabilitet især i Internet-of-Things-løsninger. Det er i dag ikke vanskeligt at udpege en række drivere, der på centrale områder udfordrer os og kræver, at store dele af visionen om Internet-of-Things snart skal realiseres. Hvis op til 50% af vores energi skal stamme fra vedvarende energikilder indenfor år, skal der tilvejebringes et mere intelligent forsynings- og distributionsnet et SmartGrid der baserer sig på centrale elementer i visionen for Internet-of-Things. En anden driver er velfærdsteknologier, der i fremtiden med smarte løsninger skal bistå os i at være mere selvhjulpne borgere og aflaste sundhedssystemet, fordi både gruppen af ældre medborgere og kronikere vokser. Begge drivere kalder på teknologi-løsninger, der på tværs af løsninger og interessenter skal bidrage til bedre beslutningsstøtte, bedre styring og sikrere kommunikation. Det kan være vanskeligt at udpege én killer-applikation eller én driver for Internet-of-Things. Derimod er det ikke svært at udpege en dræber for den videre innovation og udvikling: nemlig manglende interoperabilitet og deraf høje omkostninger til udvikling og integration til følge. Sikring af interoperabilitet er den klart største enkelt-udfordring for Internet-of-Things. Det betyder fx at: - Systemer skal kommunikere med systemer, som de slet ikke oprindeligt var planlagt til at kommunikere med på sikker og pålidelige vis - Der er behov for fælles retningslinjer for interoperabilitet og hvor det er muligt håndhævelse af disse, - Der må ske en væsentlig reduktion i antallet af standarder en leverandør er nødt til at understøtte for at kunne opnå interoperabilitet i et åbent marked - Parter og organisationer skal have de nødvendige værktøjer til at indgå aftaler omkring brug og behandling af data og på betryggende vis beskytte privatliv og personfølsomme data Åbne standarder er et væsentligt elementer i at sikre interoperabilitet og holde udviklingsomkostningerne nede. Men mens både aftagere og udviklere af Internetof-Things-løsningerne venter på disse standarder, er der en række ting, man kan iværksætte på projekt-niveau og et mere lokalt koordinerende niveau, for bedre at understøtte interoperabiliteten af system-til-system kommunikation og Internet-of- Things-løsninger. I dette notat beskrives erfaringer fra eksisterende løsninger, som peger på, at det er muligt at opnå op til 60% i direkte besparelser på udviklingsomkostninger ved at bruge open source-baserede platforme til sine løsninger. Og endog endnu større besparelser ved udvikling og indførelse af fælles kode-biblioteker til håndtering af sikkerhed og integration mellem flere parter.

3 Det økosystem, der sikrer udviklere og aftagere af Internet-of-Things veldefinerede og klarere rammer for udvikling og adoption af løsninger, ligger endnu et stykke ude i fremtiden. Notatet identificerer en række af elementerne i dette nødvendige økosystem. Samtidig inddrages erfaringer og erfaringstal fra systemintegration, der kan udpege oplagte kandidater til fælles strategier og aktiviteter, der kan forenkle og forbedre vilkårene for både udviklere og aftagere af Internet-of-Things-løsninger. Notatet er udarbejdet for Digitaliseringsstyrelsen af Lakeside A/S. marts, 2012

4 Indhold marts, Indledning hvorfor kommunikerende objekter? Anvendelse af dette dokument Målgruppe Forbehold 6 2 Internet-of-Things en arkitektur-udfordring Applikationer for Internet-of-Things Et øko-system for Internet-of-Things-løsninger? 9 3 System-til-system hvad koster det? Karakteristika for Internet-of-Things-løsninger Interoperabilitet Åbenhed Sikkerhed Eksempler på kendte projekters placering Estimeringfaktorer for Internet-of-Things-løsninger Erfaringstal Case 1 Seal Case 2 Styr din varmepunpe Case 3 EPM/PACO 20 4 Sikring af interoperabilitet Niveauer af Interoperabilitet Konkret bistand til at sikre interoperabilitet 24 5 Sammenfatning og nøglepointer 26

5 1 Indledning hvorfor kommunikerende objekter? Vi ved, at vi samfundsmæssigt står overfor store udfordringer, hvor teknologien i stigende grad må bistå os. Det er udtryk som et klart politisk ønske fra centralt hold, at det fremtidige el-system skal gøre det muligt at håndtere op til 50 procent el fra vindkraft i Dette markante mål stiller krav om en intelligent regulering langt ud i distributionsnettet. Vi står ligeledes også overfor en global samfundsudvikling, hvor flere og flere borgere pga. alder eller kroniske lidelser har et stigende behov for hjælp og understøttelse af hverdagen. Både på arbejdspladsen, i samfundet og i hjemmet. Det er en udfordring, hvor teknologien må træde til og gøre den enkelte i stand til at mobilisere en højere grad af selv-hjælp. Fx ved at give os som brugere mulighed for at trække bedre beslutninger eller ved at systemerne omkring os automatisk kan foretage den nødvendige regulering. Side 5 af 28 Den teknologi-støtte, der er nødvendig for at ovenstående udfordringer kan imødekommes, ligger for en stor dels vedkommende i visionen for Internet-of- Things. En vision om at fysiske objekter med indbygget intelligens, der er forbundet i et fælles kommunikationsnetværk, kan blive den platform, som kan realisere en teknologi-understøttet livsførelse. Det kan være vanskeligt at udpege én killer-applikation for Internet-of-Things, der med ét slag synliggør og indfrier det fulde potentiale i fx intelligent og automatisk forbrugsaflæsning eller hjemme-behandling. Derimod er det ikke svært at udpege en dræber for den videre innovation og udvikling: nemlig manglende interoperabilitet og deraf høje omkostninger til udvikling og integration til følge. System-til-system integration og interoperabilitet er en udfordring på mange niveauer i forhold til Internet-of-Things: - Systemer skal gøres klar til at kommunikere med andre systemer, som de måske slet ikke oprindeligt var planlagt til at kommunikere med de deler ikke informationsmodeller og dataformat. - Rent teknisk skal der tilvejebringes en pålidelig og måske sikker kommunikationskanal og protokol. - Organisatorisk skal parterne indgå aftaler omkring (gen)-brug og behandling af data. - Fælles standarder og retningslinjer skal indføres og håndhæves. - Juridiske forhold omkring beskyttelse af privatliv og behandling af personfølsomme data skal afklares og løbende reguleres. 1 [Klima, Energi- og Bygningsministeriet 2011]

6 Der er en lang række aktiviteter i gang på alle ovenstående punkter både på nationalt og internationalt plan. Udfordringen er i høj grad at bibeholde et overblik og løbende vurdere hvilke standarder eller arkitekturer, man bør vælge at følge i bestræbelserne på at skabe den fornødne interoperabilitet. Og mens vi venter på standarderne: hvilke aktiviteter vi kan sætte i værk for bedst muligt at fremme interoperabilitet mellem systemer. Side 6 af Anvendelse af dette dokument Dette notat har et overordnet formål om at belyse og kvalificere aspektet og vigtigheden omkring interoperabilitet især i Internet-of-Things-løsninger. Mere specifikt er formålet igennem en række cases at illustrere, at der er store ressourcer at spare, hvis der allerede på et arkitektur-niveau tages nogle principielle beslutninger. Fx til hvilke elementer og hvilke komponenter, der kan udvikles i fælleskab med andre interessenter og at inddragelse af open source som strategisk element også kan spille en væsentlig rolle i at optimere sin udviklingsindsats. Det er ambitionen, at disse erfaringstal (Kapitel 3.2) og en udarbejdet checkliste (Kapitel 4 samt bilag 3) kan fungere som beslutningsstøtte til nye projekter, der har sikring af interoperabilitet som en vigtig parameter. 1.2 Målgruppe Man er som læser i målgruppen for dette dokument, hvis man har vis teknisk baggrund og befinder sig på et beslutningstager eller projektleder-niveau. Dokumentet henvender sig til bredt mod projektledere, arkitekter og tekniske beslutningstagere både indenfor de centrale aktører (regulering og governance), udbydere (fx forsynings- og distributionsselskaber) samt leverandører (fx af komponenter- eller integrationsløsninger). 1.3 Forbehold Fokus i dette notat er alene på software-delen af en given system-til-system integration. Fokus er lagt på interoperabilitet, fordi en stadig stigende andel den samlede systemudvikling efterhånden udgøres af software- og sikring af integration.

7 2 Internet-of-Things en arkitekturudfordring The Internet of Things er først og fremmest en vision om, at vores omverden bliver udstyret med intelligens, så vi med sensorer kan fange data om den, og at vi kan sende et feedback tilbage til vores omverden så den reagerer. Internet-of-Things er også et mere konkret koncept for, hvordan Internettet skal udvide sit virkefelt i takt med at sensorer og intelligens indbygges i de fysiske objekter, som vi omgiver os med. Én interessant vinkel på Internet-of-Things er skala. På et tidspunkt omkring 2008 overhalede antallet af genstande, der var forbundet til internettet, antallet af mennesker på vores planet. 2 En tendens der vil resultere i, at hver person på Jorden i 2020 vil være omgivet af mindst 6 kommunikerende enheder. Præcis hvornår dette indtræffer, i hvilken grad det indtræffer og indenfor hvilke felter det først indtræffer, er usikkert. Sikkert er det dog, at udbredelsestakten er hurtig og at potentialet i en mere intelligent monitorering, styring og kommunikation er kolossal. Side 7 af 28 Verdens befolkning Forbundne enheder 6,3 mia. 6,8 mia. 7,2 mia. 7,6 mia. 500 mio. 12,5 mia. 25 mia. 50 mia. Forbundne enheder pr. person Flere forbundne enheder end individer på jorden 0,8 1,84 3,47 6, Figur 1: Illustration af udviklingen af Internet-of-Things tilvirket efter [Cisco IBSG 2011] Udviklingen for Internet-of-Things beskriver et skred fra en ret lokal og kontrollérbar kontekst til et langt mere åbent og komplekst landskab. Et landskab der er vanskeligt at overskue og som ikke lader sig kontrollere eller styre af den enkelte interessent. En anden vinkel, man kan anlægge på Internet-of-Things, er adoption. Analysefirmaet Gartner Group har i deres 2011-udgave af Hype Cycle for Emerging 2 Estimaterne i henholdsvis [Uckelmann,2011] og [Cisco IBSG 2011] er forskellige på dette punkt.

8 Technologies placeret Internet-of-Things som ét af de fænomener, der er på vej op ad forventningskurven med en forventning om, at vi indenfor 5-10 år vil se Internet-of- Things applikationer i mainstream-markedet. 3 Dette ligger godt i tråd med en generel opfattelse af, at vi måske først nu er ved at forstå det fulde potentiale i Internet-of-Things og at de første applikationsområder fx SmartGrid giver os de første erfaringer og ideer om, hvilke udfordringer der ligger forude og hvor store de er. Side 8 af 28 Dette notat lægger sig midt imellem de 2 ovenstående vinkler: skala og adoption. Hvis Internet-of-Things skal lykkes i stor skala og med bred adoption af applikationer skal interoperabiliteten og mulighederne for integration sikres på forskellig vis. Dette notat vil med erfaringstal fra en række cases kvalificere og illustrere hvilken effekt fx brug af åbne platforme og brug af fælles integrationskomponenter kan forventes at have for udvikling af Internet-of-Things-løsninger. 2.1 Applikationer for Internet-of-Things Tre områder kan vi allerede i dag se trækker på visionen af Internet-of-Things og faktisk realiserer nogle af elementerne i Internet-of-Things. SmartGrid, Home Automation og Velfærdsteknologi tegner nogle klare mønstre for realiseringen og udviklingsretningen for Internet-of-Things. SmartGrid For at imødekomme en række af de fremtidige udfordringer for produktion, distribution og forbrug af energi skal en intelligent infrastruktur etableres fx via smarte forbrugsmålere. Home automation Automatiseringen af en række funktioner i hjemmet eller arbejdspladsen skal gøre det muligt for brugeren og for andre interessenter fx forsynings- og alarmselskaber at overvåge og på passende vis regulere eller justere boligen og boligens enheder. Velfærdsteknologi Velfærdsteknologi kan anskues som teknologier og løsninger, der i hjemmet eller i en arbejdssituation bistår borgeren eller medarbejderen i at udføre en given opgave sikkert og med den støtte, der er nødvendig. Fx løsninger der øger graden af tryghed og selvhjulpenhed for ældre i eget hjem. Hver af de 3 applikationsområder har nogle fælles mønstre, der gør det oplagt at behandle dem i et samlet arkitektur-perspektiv. Det er alle tre områder, der stiller store krav til den intelligens, der skal bygges ind i de fysiske objekter og den kommunikationsinfrastruktur, der skal binde løsningernes elementer sammen. Et roadmap, der uddyber de 3 områder og deres relation til Internet-of-Things er angivet i bilag 1 Roadmap for applikationsområder Internet-of-Things.. 3

9 2.2 Et øko-system for Internet-of-Things-løsninger? En stor del af visionen omkring Internet-of-Things handler i virkeligheden ikke om teknologi, men i langt højere grad om at skabe et økosystem, der sikrer interoperabilitet mellem mange løsninger og interessenter. Et økosystem handler om at tilbyde en ramme, hvor der er sikkerhed for både en teknisk og forretningsmæssige interoperabilitet. En ramme hvor udbyderen eller leverandøren har garanti for at en given løsning, som han introducerer på markedet, vil fungere og hvor aftageren har en sikkerhed for, at løsningen fungerer og de forretningsmæssige vilkår for at benytte den er regulerede og gennemskuelige. Side 9 af 28 Analogien til udviklingen på området for mobiltelefoni er helt parallel: her er den klassiske killer-applikation at kunne tale sammen blevet erstattet af evnen til at kunne levere services og helt ny funktionalitet til brugeren via app s. Her har et eller rettere flere økosystemer accelereret udviklingen markant. Den høje grad af styring og governance som et økosystem leverer hvad enten modellen er åben (Android / Google og andre) eller lukket (ios / Apple) er nødvendig og tydeligvis værdifuld for både udvikler og slutbruger. Estimater angiver således, at det samlede marked for smartphone-apps i 2014 vil andrage mellem 29,5 4 og 35 5 mia. dollars. Vender man sig mod Machine-to-machine (M2M) er tendensen tilsvarende. Dog er prognoserne for dette marked for system-til-system kommunikationsløsninger stadig behæftet med stor varians og uensartet dataindsamling, så det er vanskeligtat konkludere entydigt. Men tendensen er klar og stigende: systemer, der kommunikerer med andre systemer på tværs af organisatoriske og tekniske afgrænsninger er stigende i både antal og kompleksitet. Hvilke faktorer er afgørende for et bæredygtigt øko-system for Internet-of-Thingsløsninger? Nedenfor er der med afsæt i et rammeværk for Home automation angivet en række centrale faktorer for et produktivt og bæredygtigt økosystem : Faktor 6 Hvad betyder det? Valideret interoperabilitet At protokoller og løsninger baserer sig på godkendte standarder, afstemning af data- og informationsmodeller på semantisk niveau og at løsningerne fx er testet op imod referenceimplementeringer Robust besked- og Kommunikation til og fra løsninger skal kunne kommunikationsmekanisme valideres/garanteres og være generel dvs. ikke bundet på én specifik applikation 4 Gartner Group: Dataquest Insight: Application Stores; The Revenue Opportunity Beyond the Hype 5 IDC: Worldwide and U.S. Mobile Applications, Storefronts, and Developer Forecast and Year-End 2010 Vendor Shares: The "Appification" of Everything 6 Tilvirket med afsæt i [AHAM 2010]

10 Faktor 6 Hvad betyder det? Adopteret og afprøvet teknologi At den teknologiske platform er modnet og omfavnet af markedet og at der findes flere leverandører af en given teknologi samt support Acceptable kost-sænkende At fravalg af funktionalitet for at sænke prisen prioriteringer i funktionalitet og dermed potentielt øge markedsaccepten Lave indgangsbarrierer for udviklere og service-udbydere Kompatibilitet både frem og tilbage i tid Nemt at vedligeholde (og evt. udskifte) ikke kompromitterer basale bruger-krav At det er enkelt og overskueligt at udvikle og levere services via værktøjer, biblioteker og gennemskuelige forretningsmodeller Standarder, profiler og referenceimplementeringer skal arbejde for, at både slutbrugerens og udviklerens investering er sikret bedst muligt. Godt design og gode arkitektur-principper gør det muligt, at løsninger kan vedligeholdes og sikres en levetid, der rækker længere end den enkelte del-komponents eller enkelt-teknologi Side 10 af 28 Hvorfor er fokus på et øko-system så væsentlig? Fordi det entydigt er det element, der vil kunne vokse og åbne markedet for services og skal afværge det mindst ønskværdige scenarie: at der bliver udviklet meget smalle og vertikalt orienterede Internet-of-Things-løsninger, der kun tilgodeser enkelte interessenters forretningsmæssige behov og ønsker. SmartGrid er det område, der har det største momentum i disse år med den store opmærksomhed på udfordringerne på klima- og energi-området. Derfor høstes der i øjeblikket erfaringer flere steder med udrulninger af fjernaflæste forbrugsmålere, der skal bruges til at modne dette marked, synliggøre værdikæderne og skal sætte rammerne for et økosystem for energiområdet. 7 Den fjernaflæste måler skal naturligvis være sikker og aflæsningen skal kunne foregå korrekt, så både forbruger og forsyningsselskab kan stole på resultatet. Men den fjernaflæste måler kan også indgå en central kommunikationsgateway, hvor det mindst ønskværdige scenarie vil være, at disse gateways etablerer sine egne topologier og kommunikationsmodeller med egne sikkerhedsløsninger baseret på platforme, der ikke er tilstrækkeligt åbne og dermed låser både forsyningsselskab og forbrugere til et smalt udsnit af leverandører. Måske endda med et forretningsmæssigt snævert sigte, der udelukkende går på at løse forsyningsselskabernes forretningsmæssige behov og ikke inddrager forbrugeren eller andre service-leverandører i værdikæden. 7 [Klima, Energi- og Bygningsministeriet 2011] og [Energinet.dk 2011]

11 Dette eller lignende scenarier bliver flere steder benævnt som the fight for the gateway 8, som understreger hvor vigtig en komponent gateways, er i SmartGrid og andre Internet-of-Things-applikationer. Gatewayen ses som det punkt, der skal samle og rute kommunikation fra én del af topologien fx hjemmets alarm og safety-system og videre til den eksterne gateway fx den intelligente forbrugsmåler eller kommunikationsrouter og videre ud til den rette serviceleverandør. Side 11 af 28 Der ligger derfor en opgave i løbende at sikre vilkårene for, at et økosystem for Internet-of-Things kan tilvejebringes. Standardisering gør det ikke alene. Særligt er der forhold af mere politisk karakter, der sigter efter at skabe et mere åbent marked som fx på energiområdet, hvor forbrugere lettere skal kunne skifte mellem udbydere, måske eje egne data og tilvælge services fra tredjepartsleverandører. Dette notat vil alene stille skarpt på nogle af de mere tekniske karakteristika ved Internet-of-Things-løsninger, som i væsentlig grad vil kunne løftes, hvis der var et øget fokus på fælles økosystem og flere fælles rammer for udvikling og sikring af interoperabilitet. 8 Fx i [Gunther 2009]

12 3 System-til-system hvad koster det? Til støtte i estimeringen af integrationsprojekter, vil dette afsnit præsentere de karakteristika, der er fremtrædende ved Internet-of-Things-løsninger. Side 12 af Karakteristika for Internet-of-Things-løsninger Der er tre centrale karakteristika ved Internet-of-Things-løsninger, som dette notat vil beskrive og udfolde: interoperabilitet, åbenhed og sikkerhed Interoperabilitet Standarder, profilering og certificering af løsninger er et vigtigt element i sikringen af interoperabilitet, men de er kun i begrænset omfang udbredte endnu og adoptionen er langt fra tilstrækkelig til at løsninger kan påkalde sig interoperabilitet via standarder. Selv på domænet for SmartGrid, hvor der trods alt er begyndt at være en vis mængde projekter og løsninger, er der stadig lang vej at gå før standarder dominerer. Interoperabilitet behandles særskilt nedenfor i kapitlet 4 Sikring af interoperabilitet Åbenhed De senere år har budt på en øget udbredelse og opmærksomhed på åbne standarder og anvendelse af open source software (OSS). Selv på slutbrugervendte systemer som pc ere, smartphones og senest smart-tv s 9 begynder adoptionen af åbne platforme at opnå kritisk masse. Dog er diskussionen omkring open software versus lukket software langt fra overstået og derfor også en diskussionspunkt for Internet-of-Things-løsninger. Time-to-market har tvunget mange producenter af udstyr og ikt-løsninger til at se i retning af fælles, åbne platforme. De ser det som et middel til at opnå højere produktivitet og en strategisk vej til at kunne frigøre ressourcer til at levere præcis den funktionalitet og innovation til kunderne, som der efterspørges. Kommunikation og integration er sjældent noget markedet specifikt efterspørger det er nødvendige elementer, som forventes at være tilstede. At netop kommunikation og integration er centrale karakteristika ved Internet-of-Thingsløsninger taler for, at der er et stort potentiale i etablering af fælles, åbne løsninger og komponenter, der har dette fokus Sikkerhed Parallelt med diskussionen om åbenhed pågår der løbende en debat omkring sikkerheden i Internet-of-Things- og især SmartGrid-løsninger. 10 Ikke blot en diskussion om den fysiske sikkerhed og om at lukke den kriminelle tredjepart ude, men også en diskussion omkring sikring af privatlivets fred Samsung har således lagt et roadmap for at gøre deres smartphone OS open source og introducere det som åben platform til deres Smart-TV som direkte modsvar til Googles delvis åbne OS Android og Apples lukkede - ios [Knapp 2011], [Flick 2011], [ForskEL 2010] og [MIT 2011] kapitel 9 11 [Bundesamt 2011]

13 Grunden til disse diskussioner og bekymringer er åbenlyse. Et udbygget Internet-of- Things-økosystem bestående af mange tusinde enheder, vil ret nøje kunne følge og lagre alt om en persons færden, forbrug og vaner. Uretmæssig adgang til disse data vil kunne benyttes til formål, som borgeren ikke har givet tilladelse til eller simpelthen til udøvelse af kriminalitet og identitetstyveri. Cyberangreb på infrastruktur er et andet sikkerhedsaspekt, der naturligt har et stort fokus. Mens sikkerhedsrisikoen og konsekvensen ved at én husstands varmepumpe fx angribes og manipuleres er lille, er det aggregerede trusselsbillede, hvor varmepumper i et område manipuleres i et koordineret angreb, et helt andet trusselsbillede. En trussel og effekter der har national skala og betydning. Derfor er en verificeret sikkerhedsmodel baseret på velafprøvede koncepter og teknologier nødvendig. De 2 karakteristika åbenhed og sikkerhed kan med fordel illustreres i sammenhæng: Side 13 af 28 Figur 2: 4 scenarier for Internet-of-Things-løsninger Retning / tendens Beskrivelse

14 Åben kodebase: Et projekt, hvor kodebasen ligger frit tilgængelig under en anerkendt open source-licens. Projekterne er oftest baseret på internationale/nationale anerkendte standarder. Projekter, der ligger yderst på denne akse, er projekter, hvor koden er frit tilgængelig. Dvs. licensen er åben og uden restriktioner i forhold til videre anvendelse. Midt på denne akse ligger projekter, hvor koden stadig er tilgængelig men kun må bruges under en mere restriktiv licens og måske baserer sig på helt eller delvist på proprietære protokoller, som ikke følger anerkendte standarder. Lukket kodebase: Er projekter, hvor kodebasen er underlagt restriktive licensbetingelser og hvor koden i sig selv ikke er tilgængelig. Typisk gældende for proprietære kommercielle løsninger. Yderst på denne akse ligger projekter, hvor teknologistakken er lukket. Dvs. koden er ikke tilgængelig, protokollen er proprietær og protokollen er i øvrigt hemmeligholdt. Projekter der ligger mere mod midten på denne akse er kommercielle projekter, hvor protokollerne er offentlige og dokumenterede måske endda konforme i forhold til standarder og hvor andre frit kan benytte protokollen. Side 14 af 28 For den vertikale akse (sikkerhedsmodel) gælder følgende definitioner: Retning / tendens Beskrivelse Verificeret Et projekt, hvor sikkerhedsmodellen bygger på en sikkerhedsmodel: international anerkendt og verificeret arkitektur, fx OSA 12. Derudover er selve implementeringen gennemprøvet og verificeret af én eller flere eksterne, anerkendte og uafhængige instanser. Herunder review, test og evt. Ikke-verificeret sikkerhedsmodel: certificering. Et projekt, hvor sikkerhedsmodellen enten ikke er kendt (security by obscurity) eller ikke er verificeret af eksterne uafhængige instanser. Man kan generelt ikke konkludere, at ikke-verificerede sikkerhedsmodeller er mere usikre end verificerede sikkerhedsmodeller. Men det er normalt en god antagelse, at jo flere, der har verificeret, genbrugt og justeret en sikkerhedsmodel, jo mere modstandsdygtig og stabil over tid viser den sig ofte at være Eksempler på kendte projekters placering Placering Eksempler 12

15 Placering Venstre, øverst: (Åben kodebase og ikke-verificeret sikkerhedsmodel) Venstre, nederst: (Åben kodebase og verificeret sikkerhedsmodel) Højre, øverst: (Lukket kodebase og ikke-verificeret sikkerhedsmodel) Højre, nederst: (Lukket kodebase og verificeret sikkerhedsmodel) Eksempler I dette område ligger typisk open source projekter i deres tidlige faser. Dvs. projekter, hvor sikkerheden enten ikke er blevet analyseret, eller ikke har fået fokus endnu. Et eksempel på denne type projekter kunne fx være Styr din varmepumpe. (Se erfaringstal nedenfor) I denne kategori ligger også open source projekter, som ikke længere vedligeholdes. Eksempler på dette kunne være projekter, som baserer sig på sikkerheds- og krypteringsalgoritmer, som sidenhen er blevet knækket. I dette område ligger typisk modne, gennemprøvede og vedligeholdte open source projekter. Det er projekter, hvor mange instanser har verificeret sikkerheden og hvor kodebasen vedligeholdes med nye sikkerhedstiltag. Eksempler på dette er fx Linux kernen, men også mindre projekter som fx den Nationale Service Platform (NSP), der drives for sundhedsvæsenets parter i Danmark. I dette område ligger nok langt størstedelen af de kommercielle it-produkter og løsninger. Kodebasen er lukket, og kan derfor ikke umiddelbart verificeres af uafhængige instanser. Såfremt nogle opnår adgang til den lukkede kode igennem adgang til kildekode eller reverse engineering kan sikkerheden blive kompromitteret. Sonys Playstation 3 13 og Symantecs PCAnyWhere 14 er 2 meget synlige og meget eksponerede eksempler på denne type løsninger, der indenfor den seneste tid er blevet udsat for kompromittering. Begge er eksempler på, at en stor del af sikkerheden har ligget i, at kodebasen har været lukket. I dette område ligger produkter, hvor kodebasen er lukket for offentligheden, men hvor sikkerheden alligevel er verificeret af eksterne instanser. I denne kategori ligger typisk software, hvor brugerne selv har ekstrem fokus på sikkerhed. Fx systemer og løsninger til militære formål. Side 15 af 28 Ovenstående Internet-of-Things-scenarier repræsenterer den meget brede palette af anvendelser og applikationsområder, som Internet-of-Things-løsningerne kommer til at bevæge sig indenfor ore_stolen_source_code?taxonomyid=82

16 3.1.5 Estimeringfaktorer for Internet-of-Things-løsninger Der er 4 overordnede faktorer, der erfaringsmæssigt har stor indflydelse på ressourceforbruget og dermed i sidste ende prisen på den tekniske udvikling af itsystemer: Faktor Beskrivelse Snitflader Det har stor indflydelse på udvikling af it-systemer, hvor stor en eksponeringsflade systemet skal have. Hvor mange forskellige protokoller og kommunikationssnitflader skal systemet udstille og integrere med? Funktionalitet Hvor kompleks er den funktionalitet eller forretningslogik, der skal implementeres? Få use cases med få operationer på få data, eller mange use cases og komplekse datasæt? Brugerflade (UI) Hvor brugervendt er systemet? Denne faktor er i nogen grad relateret til funktionalitet, men udvikling af effektive brugerflader - der hvor funktionaliteten møder brugeren - har erfaringsmæssig stor indflydelse på den samlede kost. Vedligeholdelse og support Hvilket niveau af support og vedligeholdelse er nødvendig? Kan systemet fx opdateres Over-the-air så fysisk adgang kan undgås? Hvis systemet har en stor eksponeringsflade (mange eksterne integrationer) kan man typisk forvente, at der også skal afsættes en del ressourcer til løbende vedligeholdelse - fx opdatering af snitflader - og vidensmæssig support af andre interessenters udviklingsaktiviteter. Side 16 af 28 Ovenstående karakteristika og faktorer vil i det følgende blive brugt som oplæg for en model til at nedbryde og estimere udviklingen af software-delen af en Internet-of-Things-løsning. 3.2 Erfaringstal Der er endnu ganske få løsninger på feltet for Internet-of-Things der er udrullet i en grad, så der er erfaringer med både udvikling og vedligeholdelse, da området stadig er under definition. Derfor er det også vanskeligt at finde og indsamle solide erfaringstal. Men der findes erfaringstal fra andre typer løsninger, fra beslægtede domæner, der deler nogle af de samme karakteristika som Internet-of- Things-løsninger vil have. Til at illustrere disse karakteristika vil der i dette afsnit blive fremlagt erfaringstal fra 3 udvalgte cases. De 3 cases er valgt ud fra 3 hovedkriterier: Erfaringstal for casen skal være kendte og tilgængelige enten via dokumentation eller gennem interviews af nøglepersoner Casen skal belyse mindst 2 af de tre karakteristika ved Internet-of-Thingsløsninger: åbenhed, sikkerhed og sikring af interoperabilitet Casen skal være realiseret og udrullet, således at der er erfaringstal på support og vedligeholdelse.

17 Tallene i nedenstående er uddraget igennem review af projektdokumentation fra udvalgte projekter samt interview af udvalgte nøglepersoner. (Se Bilag 4 Interview med ressource-personer). Det er vurderingen, at de tre cases samlet set belyser de væsentligste udviklingsaspekter omkring udvikling af systemer med høj grad af sikkerhed, åbenhed og interoperabilitet og at disse erfaringstal overordnet kan overføres til feltet for Internet-of-Things. Side 17 af Case 1 Seal I forbindelse med etableringen af sundhedssektorens centrale service platform (NSP), valgte man i 2005 fra centralt hold at udvikle et integrationsbibliotek til hjælp for parterne i og omkring NSP-platformen. 15 Denne komponent blev udviklet til Java og.net platformen og fik navnet Seal. 16 Seal-komponenten blev udviklet til at varetage de mere komplekse og kedsommelige aspekter af sikkerheds- og kommunikationsområdet, herunder håndteringen af Den gode webservice, Id-kort og certifikater. Seal-biblioteket er open source og har siden 2007 været frit tilgængeligt for alle interessenter, der skal lave sikker systemintegration baseret på web-services primært mellem parter i sundhedssektoren. Seal-biblioteket benyttes i dag af en række EPJ-systemer, NSP-komponenter og lægepraksis-systemer. Biblioteket er løbende blevet vedligeholdt og opdateret. Senest er Seal-bibliotekets funktionaliteten blevet udvidet med understøttelse af udvalgte dele af IDWSH-standarden, der er en profilering af standarden for identitetsbaserede web services til anvendelse indenfor sundhedssektoren. Den interne fordeling af udviklingsindsatsen for Seal-projektet fordeler sig cirka som følger: Kategori % - værdi Kommunikation: 5 % Funktionalitet: 85 % Brugerflade: 0 % Andet: 10 % Erfaringstal fra Seal-projektet sammenholdt med et estimat for hvad en individuel, ikke-fælles løsning ville andrage: Seal Hvis individuel løsning Udv. omkostninger: 2000 timer. 500 timer. Ny protokol: 400 timer. 400 timer. Vedligehold: 25 timer pr. måned. 15 minutter pr. måned. Antal brugere: Se og 16 Som i segl til forsegling

18 De reelle erfaringstal (venstre kolonne i ovenstående) og de estimerede tal (højre kolonne) giver en indikation af, at allerede ved ca. 4 parter i en integrationsløsning er omkostningerne ved at udvikle en individuel løsning de samme som for at udvikle et fælles bibliotek, som hver part efterfølgende kan anvende. Ved hver yderligere part, der accepterer og anvender komponenten, høster hver enkelt part dermed en gevinst på vegne af projektet igennem brugen af det fælles bibliotek. Side 18 af Seal (timer) Individuel (timer) Figur 3 - Timeforbruget for Seal sammenholdt med individuelle løsninger i timer ud fra antallet af brugere. Gevinsten er dels økonomisk i form af sparede ressourcer til udvikling men også en gevinst i høj kvalitet og en valideret sikkerhedsmodel. Seal-projektet er derfor et godt eksempel på, at integrationsløsninger der tilvejebringes med fælles biblioteker og komponenter effektivt kan nedbringe omkostninger i integrationsprojekter så som Internet-of-Things-løsninger. Ud over at lette selve besværet med integration, så fungerer Seal-biblioteket også som reference-implementation for den underliggende specifikation. Dette eliminerer i sig selv en række udgifter forbundet med at sikre interoperabilitet og nedbringer antallet af tvister omkring fortolkning af specifikationen mellem interessenterne. Dette punkt er af én af interview-personerne specifikt blevet fremhævet som én af de absolut største gevinster ved Seal-komponenten næsten større end det konkrete udviklingsarbejde, som komponenten repræsenterer og potentielt sparer anvenderne for. Opsummering Udvikling og anvendelse af fællesbiblioteker i integrationsprojekter, som Internet-of- Things-løsninger typisk repræsenterer, tilføjer projektet følgende: - Reducerer de samlede omkostninger forbundet med integration ved genbrug af fælles kodebase og reference-implementeringer. - Reducerer med en anerkendt reference-implementation kraftigt antallet af problemer med interoperabilitet og ikke mindst tvister vedr. fortolkning af den underliggende specifikation. - Sikkerhed er dyrt og kræver løbende vedligehold. En fælles integrationskomponent på fx sikkerhedsområdet reducerer

19 omkostningerne og øger sikkerhedsniveauet for det samlede system ved at tilbyde en valideret sikkerhedsmodel Case 2 Styr din varmepumpe I begyndelsen af 2010 finansierede Energinet.dk et udviklingsprojekt i samarbejde med Nordjysk Elhandel og firmaet LIAB. 17 Det udviklede system blev bl.a. baseret på Linux og andre open source-projekter. Det udviklede system er i dag implementeret hos ca. 200 forbrugere og yderligere 100 forventes at anvende systemet indenfor det næste halve år. Side 19 af 28 Projektet havde to formål: - Dels skulle der udvikles, opbygges og demonstreres en intelligent styring, som kunne fjernstyre varmepumper i private husstande uden at forbrugerne ville mærke nogen ændring af komfort. - Dels skulle projektet demonstrere, hvordan en aktør som Nordjysk Elhandel, der er såkaldt balanceansvarlig for 35 % af al dansk elproduktion, kunne bruge varmepumperne til aktivt at flytte elforbruget efter vindkraftproduktionen og dermed byde ind med op- eller nedreguleringsydelser i det overordnede el-system. Projektet fokuserede primært på disse to formål, mens hele sikkerhedsområdet bevidst blev nedprioriteret til et minimum. Projektet valgte desuden at basere sig på, at virksomhedspartneren i projektet - LIAB - allerede havde både eksisterende kompetencer indenfor Linux og havde en hardware-platform, som løsningen kunne basere sig på. Denne case gjorde derfor stor brug af eksisterende løsninger både hvad angår hardware og software. Den interne fordeling af udviklingsindsatsen er cirka fordelt som følger: Kategori % - andel Kommunikation: 50 % Funktionalitet: 25 % Brugerflade: 15 % Andet: 10 % Erfaringstal fra udviklingsforløbet: Ved brug af Open Source-platform Estimat hvis udvikling af egen platform Samlede omkostninger: kr kr. SW/HW omkostninger: kr kr. Vedligehold: kr kr. Antal brugere: Se mere på

20 Erfaringstallene indikerer derved at der er en betragtelig besparelse i dette tilfælde ca. 60 % - ved brug af eksisterende open source komponenter. Styr din varmepumpe er derfor et godt eksempel på hvilke store besparelser, der kan indløses ved brug af Open source software og open hardware. Det skal dog retfærdigvis siges, at den relative besparelse i denne case bliver så stor, fordi LIAB allerede havde tilvejebragt en del af platformen. På den anden side ville anvendelsen af en lukket, kommerciel OEM-platform muligvis kunne spare en del af udviklingsomkostningerne, men ville typisk igennem licens-betaling fordyre løsningen i takt med antallet af brugere. Udover den direkte besparelse ved brug af open source, sikrer projektet sig også muligheden for at forfølge en fler-leverandør strategi samt en position der kan sikre en længere levetid, idet projektet ikke er afhængigt af lukkede kommercielle løsninger. Løsninger, der pludselig kan bliver forladt af en leverandør. Med organiseringen i et open source-projekt kan man ikke garantere dette ikke sker projektet kan jo blive forladt eller gå i stå af andre årsager men man holder muligheden åben for, at andre interessenter kan overtage eller bidrage til udviklingen og vedligeholdelsen af komponenter, såfremt de oprindelige interessenter forlader projektet. Side 20 af 28 Erfaringstallene illustrerer derudover, at sikkerhed er en kraftig fordyrende faktor. Sammenligner man med fordelingen af ressourcerne fra case 1 med denne case, så fremgår det tydeligt, at Seal-projektet, der havde stort fokus på sikkerhed og kun en begrænset funktionalitet, har været væsentlig dyrere, end etableringen af servere og klienter i Styr-din-varmepumpe, der havde et begrænset fokus på sikkerhed. Opsummering Brugen af open source software og open hardware (se Bilag 2 Om brug af Open Source), kan bidrage til en kraftig reduktion af udviklingsomkostningerne til en samlet løsning. Da Internet-of-Things-løsninger nok typisk vil være sammensat af en lang række elementer og del-projekter kan indløsningen af denne gevinst ske både lokalt i den specifikke løsning men også mere globalt på et niveau af økosystem. Det sidste vil dog forudsætte at der foreligger en decideret strategi for brug af åbne platforme. I punktform ser gevinsterne således ud: - Reducerer de samlede omkostninger forbundet med den samlede løsning - Øger mulighederne for en flerleverandørstrategi - Sikrer længere levetid af det udviklede system, da koden og hardwaren ikke er ejet og beskyttet af én interessent og derfor frit kan videreudvikles og vedligeholdes af andre Case 3 EPM/PACO I begyndelse af 2003 påbegyndtes udviklingen af det Elektroniske Medicin Modul (EPM) til det daværende Hovedstadens Sygehusselskab (H:S).

21 EPM systemet bestod af en tyk klient, en webklient, og en serverinstallation. Kommunikationsprotokollen mellem klient og server blev baseret på Java RMI, og fulgte derudover anerkendte kommunikationsmønstre via denne protokol. Projektet havde stor fokus på brugergrænseflade ( 70 forskellige dialoger/vinduer). Sideløbende med EPM udviklingen blev der udviklet en integrationskomponent (PACO), til integration mellem bl.a. EPM og regionens Hovedstadens 18 PAS 19 system. PACO-komponenten var en ren server-installation og derfor helt uden UI (User interface / brugerflade). Kommunikationsprotokollen var igen baseret på RMI. Side 21 af 28 Den interne fordeling af udviklingsindsatsen er cirka fordelt som følger for EPM: Kategori % - værdi Kommunikation: 5 % Funktionalitet: 20 % Brugerflade: 60 % Andet: 15 % Erfaringsfordelingstal for PACO: Kategori % - værdi Kommunikation: 5 % Funktionalitet: 80 % Brugerflade: 0 % Andet: 15 % Omfangsmæssigt var PACO ca. en faktor 25 mindre end EPM projektet. Case 3 illustrerer hvor store omkostninger, der ligger forbundet med udvikling af brugerflader (UI). En enkel ikke overraskende konklusion er, at jo simplere selve eksponeringsfladen mod brugeren kan gøres, jo billigere bliver et projekt. Derudover er UI s næsten altid forbundet med en platform fx Windows eller en browser, som i en lang række tilfælde er den foretrukne måde at give brugeren adgang til en brugerflade. Denne platform (operativsystem eller browser) udvikler sig udenfor projektets rammer og dette medfører typisk yderligere vedligehold. Fx at brugerne oplever, at et system ikke virker eller opfører sig uhensigtsmæssigt efter en systemopdatering. Erfaringstallene fra EPM/PACO viser også, at omkostningerne til brugervendt vedligeholdelse og support er væsentlig større for EPM end for PACO. Ikke overraskende fordi EPM har en brugerflade, men denne brugerflade var typisk vendt mod ikke tekniske slutbrugere og lagde et stor overhead på udviklingsindsatsen, som det kan læses ud af ovenstående 2 tabeller. 18 På dette tidspunkt var sammenlægningen 19 PAS = Patient Administrations System

22 Opsummering Udvikling af (G)UI i forbindelse med softwareprojekter er omkostningstunge især hvis de skal fungere godt og brugerfladerne kræver efterfølgende en del ressourcer til vedligeholdelse og vidensmæssig support. - UI kræver vedligehold, idet platformen der bringer brugeren i kontakt med UI (Operativsystem, browser, smartphone, etc.) ligger udenfor projektets rammer/rækkevidde, men ændrer sig med tiden. - UI s har en større eksponeringsflade end rene tekniske integrationsløsninger, og brugerflader er typisk mere ressourcekrævende at teste pga. antallet af platforme og forskelligheden blandt i brugerne. Side 22 af 28

23 4 Sikring af interoperabilitet At sikre interoperabilitet mellem systemer er én af hovedopgaverne for en itarkitektur og er i særlig grad vigtig i forhold til Internet-of-Things-løsninger, da de er karakteriseret ved de stort set uden undtagelse indgår som et element i andre løsninger via integration og kommunikation. Sikring af interoperabilitet er en udfordring ved Internet-of-Things, fordi applikationerne typisk går på tværs af mange perimetre og fordi Internet-of-Things med en binding i hardware typisk har en lang levetid. Standarder, profilering og certificering af løsninger er et vigtigt element i denne sikring, men de er kun i begrænset omfang udbredte endnu og adoptionen er langt fra tilstrækkelig til, at løsninger kan påkalde sig interoperabilitet via standarder. Selv på domænet for SmartGrid, hvor der trods alt er begyndt at være en vis mængde projekter og løsninger, er der stadig lang vej at gå, før standarder dominerer. Version 0.72 Side 23 af 28 Dette afsnit vil kort præsentere aspekterne omkring systemmæssig interoperabilitet og vil opstille en checkliste, der kan bistå beslutningstagere fx projektledere og teknisk ansvarlige hos aftagere og udbydere af Internet-of-Thingsløsninger i at vurdere i hvilket omfang interoperabilitet er sikret i forhold til et givent projekt, et løsningsoplæg eller udviklingsplan. 4.1 Niveauer af Interoperabilitet Det begreb om interoperabilitet, som vi har benyttet igennem dette notat, er en bred betegnelse, der dækker flere aspekter af systemers evne og egnethed til at kommunikere og udveksle data: Aspekt af interoperabilitet Beskrivelse Teknisk interoperabilitet Dækker aspektet omkring det rent fysiske og den kommunikationsinfrastruktur, der forbinder systemer og enheder lige fra fysiske forbindelser til de lav-niveau protokoller, der tilvejebringer den basale kommunikation. Informations- eller datainteroperabilitet Dækker over dataindhold, dataformater, informationsmodeller og de aftaler, der skal etableres på et semantisk plan for at fx dataudveksling og genbrug af information kan finde sted uden risiko for tab og forvanskning Organisatorisk interoperabilitet Er aspektet omkring de aftaler der skal indgås for at sikre en passende regulering eller governance. Dvs. forhold omkring jura, licenser, fysisk og intellektuelt ejerskab, dataansvar og økonomi. Alle tre aspekter skal være adresseret for at opnå en effektiv og stabil interoperabilitet mellem systemer. Vægtningen af de tre aspekter varierer naturligvis alt efter, om interoperabilitet og system-integrationen skal fungere indenfor rammerne af én organisation eller som vil være det typiske scenarie i

24 Internet-of-Things mellem flere organisationer eller enheder, der kun har få eller ingen formel forbindelse Konkret bistand til at sikre interoperabilitet Som et konkret bidrag til at bistå beslutningstagere omkring Internet-of-Thingsaktiviteter er der nedenfor foreslået en checkliste. Checklisten skal bidrage til bedre at kunne belyse og kvalificere om indsatsen for at sikre interoperabilitet mellem systemer er tilstrækkelig adresseret. Checklisten kan bruges som en praktisk og pragmatisk værktøj til at identificere områder, der skal styrkes og hvor en ekstra indsats og fokus er påkrævet. Checklisten er et foreslået udgangspunkt, der kan udvides med andre relevante punkter og mere specifikke spørgsmål. Det er vigtigt at understrege, at disse checklister er et startpunkt i forhold til at understøtte arbejdet med at sikre interoperabilitet mellem systemer og ikke et endemål. Checklisten er ikke en kravliste eller et redskab til mål-opfyldelse. Det er alene et værktøj til inspiration, belysning, sammenligning og beslutningsstøtte. Version 0.72 Side 24 af 28 Checklisten består af i alt 3 dele: Checkliste-opbygning (Se bilag for den egentlige checkliste) 20 Generel del Henvendt til Aftagere og udbydere af Internet-of-Things-løsninger Fokus - Er den overordnede arkitektur åben? Dvs. dokumenteret og forberedt for integration og indførelse af elementer og komponenter fra 3. Part. - Er snitflader og kommunikationsinterfaces veldefinerede og dokumenterede? - Benytter og inddrager arkitekturen i tilstrækkelig grad anerkendte standarder? Hvis ikke: hvorfor? - Er der taget stilling til håndtering af sikkerhed og sikring af personlige data? Dette er primært af hensyn til interoperabilitet og udveksling af data/informationer. - Er der gjort overvejelser omkring levetidshåndtering? - Er der gjort overvejelser om hvordan man kan undgå stærke bindinger i forhold til specifikke teknologier eller leverandører? - Er der gjort overvejelser omkring, hvorledes elementerne kan kommunikere og interagere med nye elementer, som først tilføjes i fremtiden? (eller ikke er kendte på designtidspunktet) 20 Checklisten er tilvirket og generaliseret med afsæt i: GridWise Architecture Council Interoperability Constitution White Paper (November 2005),

25 Checkliste-opbygning (Se bilag for den egentlige checkliste) 20 Typisk anvendelse Checklisten kan til evaluering af projektoplæg eller løsningsforslag og have en generel vurdering af alle tre aspekter af interoperabilitet: den organisatoriske, tekniske og informations-interoperabilitet. Tillæg til aftagere / kunder Henvendt til Aftagere af Internet-of-Things-løsninger. Fokus - Sektorielle krav til organisatorisk interoperabilitet. - Standarder og håndtering af indførsel ad disse. - Leverandør- og løsningsstrategi til sikring mod lock-in. - Konkrete politikker for efterprøvning af interoperabilitet. Typisk anvendelse Checklisten kan bidrage kunde-siden med at få belyst og vurderet hvad der, i forhold til en given leverance eller leverandør, er blevet iværksat eller overvejet for at sikre interoperabilitet. Tillæg til udbydere / leverandører Henvendt til Udbydere og leverandører af Internet-of-Things-løsninger. Fokus - Sektorielle krav til især informationsmæssig - interoperabilitet - Standarder og håndtering af indførsel ad disse - Åbenhed og sikring af interoperabilitet - Konkrete politikker for efterprøvning af interoperabilitet Typisk anvendelse Checklisten kan bidrage med at få belyst og kvalificeret hvordan aftagersiden er forberedt og evt. har af forventninger til interoperabilitet. Version 0.72 Side 25 af 28 De konkrete checklister findes som bilag til dette dokument se Bilag 3 Checklister til sikring af interoperabilitet.

26 5 Sammenfatning og nøglepointer Potentialet for nyttige og nødvendige Internet-of-Things-løsninger er uomtvisteligt. Vi ser energi- og velfærdsløsninger, der er på vej på markedet og som er første skridt i teknologisk at adressere nogle af de samfundsmæssige udfordringer vi står overfor på disse områder. Notatet her har afdækket en række centrale parametre, der erfaringsmæssigt er afgørende for en velfungerende system-til-system integration og ud fra 3 cases kvalificeret dem med erfaringstal. Version 0.72 Side 26 af 28 - Sikring af interoperabilitet er den væsentligste enkeltparameter, der er bestemmende for Internet-of-Things-løsningers succes. Standarder er kun en del af denne sikring og Internet-of-Things-løsningers særlige karakteristika gør, at man er nødt til at sikre denne interoperabilitet på flere niveauer: på organisatorisk, for data- og informationer samt det rent tekniske niveau. Sikring af interoperabilitet bør derfor have top-prioritet i planlægningen og designet af Internet-of-Things-løsninger. - Brug af open source og åbne platforme reducerer væsentligt udgifterne for et projekt. Erfaringstallene peger på at en 60 % besparelse ikke er urealistisk i et projekt. 21 En strategi for og brug af åbne, fælles platforme bør altid overvejes i Internet-of-Thingsløsninger, hvor der typisk er mange interessenter involveret og dermed basis for store synergi-effekter af en fælles, åben platform. - Lang levetid er et væsentligt karakteristika ved Internet-of-Things-løsninger. Åbne platforme baseret på open source software og open hardware rummer et klart potentiale for at sikre og måske endda forlænge den potentielle levetid af et projekt eller Internet-of-Things-løsning. 22 Internet-of-Things-projekter bør lægge en strategi for levetiden (life cycle management) af løsningen og platformen. Åbenhed og transparens i forhold til platformen bør indgå som strategisk element fx i form af indførelse af et open source-princip på centrale løsningselementer. - Lang levetid og snæver binding til én leverandør er en giftig cocktail. Brug af fx åbne platforme for både hard- og software sikrer i højere grad muligheden for, at man kan implementere en ægte fler-leverandørstrategi. Til at sikre fortsat innovation og dynamik bør Internet-of-Things-løsninger formulere principper og strategier for at der er et reelt leverandør-alternativ fx igennem krav om brug af åbne platforme/komponenter på strategiske områder i arkitekturen. 21 Case: Styr-din-varmepumpe 22 Case: Seal-projektet har løbende over 6 år udviklet og vedligehold sit open source sikkerhedsbibliotek til system-integration