IoT-Systemet möjliggör för byte av moduler oberoende av varandra

Kortnamn: Modularitet

Definitioner relevanta för principen:

• Modul avser här: En logisk samling av funktioner inom IoT systemet. - Eller “Any of a number of distinct but interrelated units from which a program may be built up or into which a complex activity may be analysed.”

• Förvaltningsbarhet definieras som ett mått på hur anpassat ett system är till förvaltning.

IoT-systemets ingående moduler kan bytas ut eller versionsuppgraderas vartefter att arkitekturen utvecklas utan att datatransporten eller funktionen i kringliggande moduler påverkas negativt.

Det går att byta ut en modul eller versionsuppgradera den utan att det uppstår behov av att förändra kringliggande moduler eller systemets informationshantering, inkluderat informationsmodeller och metadata.

Det modulära perspektivet gäller alltså både IoT-systemets ingående funktioner som data-/informationshantering.

Det är av vikt att design av, och implementationen av, moduler bygger på en tydlighet av gränssnitten så att modulerna görs kompatibla med varandra.

IoT-systemet möjliggör att andra IoT-lösningar kan anslutas till vissa moduler eller på olika nivåer. Tex att fastighetsregleringssystem som lagrar data till den gemensamma lagringsarean men är i övrigt ett fristående system.

• Denna princip är viktig för att minska inlåsningseffekter.

• För att över tid skaffa sig förvaltningsbarhet örvaltningsbarhet.

• För att över tid sänka kostnader, förbättra funktionalitet och få bättre kvalitet.

• Möjliggöra arkitekturell och teknisk flexibilitet över tid.

• Det är viktigt att kunna konkurrensutsätta varje modul med tanke på LOU och LUFS.

• Möjliggör att Sensorer och Styrdon kommer från flertal leverantörer och kan bytas.

• Gör det möjligt att byta ut moduler och migrera exportera information när en modul byts eller avvecklas.

• Bidrar till EIF Principle 5: technological neutrality and data portability

• Bidrar till princip M6 “Livscykelkostnaden tas i beaktande vid investering i och finansiering av digitala lösningar” i SKR:s Utveckling i en digital tid.

• Det kan bli längre uppstartssträcka och ökar ansvaret på upphandlande organisation eftersom alla gränssnitt och moduler behöver definieras

• Det blir en ansvarsförflyttning i riktning mot den beställande organisationen, tex när det gäller integration. Därför krävs mer eftertanke i form av arkitektur och IT strategier.

• Det kan krävas mer arbete för att uppnå intentionen i principen i och med att befintliga verksamhetssystem inte är medvetna om eller förberedda kring data, information och tjänster från IoT-system. Det är därför viktigt att beställaren beaktar detta i designen av IoT-systemet.

• Utifrån ett affärsperspektiv är det viktigt att avtal och upphandling stödjer utbytbarhet av moduler. Leverantörer bör beskriva hur detta kan gå till och hur prissättning av detta är.

• Avtal med leverantörer behöver stödja principen, så att det inte finns avtalmässiga låsningar som förhindrar utbytbarhet.

Principen om modularitet och utbytbarhet i IoT-system visade sig i upphandlingarna vara teoretiskt bra men svår att tillämpa i praktiken i upphandlingen och tillhörande utveckling, på grund av bristen på standarder och enhetliga beskrivningar. De involverade IoT-leverantörerna har därför inte kunnat bygga eller beskriva sina system enligt principen fullt ut. Det finns idéer om modularitet som man kan hämta från en del öppna källkods-samarbeten. Nyttan av modulariteten som definieras inom sådana samarbeten är dock oftast begränsad huvudsakligen till dem som deltar i det samarbetet.
RefARK IoT lyfter att det i upphandlingar kan ges merpoäng för utbytbarhet, krävas in tydliga beskrivningar av systemets moduler, samt att det är viktigt att beställare beaktar detta i designen av IoT-systemet. RefARK IoT saknar dock enhetliga standarder som vägledning för utvecklare, men principen kan ändå fungera som vägledning.
I Jönköpings och VGRs upphandlingar gavs merpoäng för utbytbarhet och tydliga beskrivningar av systemets moduler.

Mer info och exempel.

Data, information och kontextmedvetenhet (Context-awareness) i IoT-systemet bevaras vid modul och system byten

Kortnamn: Kontextmedvetenhet

Data, information och kontextmedvetenhet överlever systembyten och offentliga upphandlingar. Beställarorganisationen behöver därför ta full kontroll över hur data lagras och används inom organisationen.

Beställarorganisationen behöver säkerställa ägande- och nyttjanderätt till de data, information och kontextmedvetenhet som skapas i IoT-systemet. Utan detta är det svårt att få framtida nytta av insamlad information.

Kontextmedvetenhet är en central del av ett IoT-system som kräver att kommun eller region bygger upp en kontext-baserad struktur som täcker hela organisationens behov. Den behöver vara utbyggbar för att täcka mer än enbart de behov som uttrycks idag för att täcka in framtidens behov.

• Data är det som är bestående och är en tillgång

• Denna princip bidrar till att uppfylla EIRA principer 4,5,10,11

• Beställarorganisationen vill ha rimliga kostnader för att flytta data.

• Möjliggör att byta ut moduler och migrera exportera information när en modul byts eller avvecklas.

• Beställarorganisationen kan alltid få ut de datamängder som skapats i varje modul i ett standardiserat format.

• Bidrar till EIF Principle 11: preservation of information

• Det kan bli längre uppstartssträcka och ökar ansvaret på upphandlande organisation eftersom alla gränssnitt och moduler behöver definieras.

• Det krävs en förståelse hos beställaren för den data och den informationsmängd som bygger kontextmedvetenheten och hur den ska hanteras på kort och lång sikt.

• Det är beställarens ansvar att säkerställa att sensordata översätts till användbara data.

• Det finns en risk att efterlevnad av principen kan resultera i en hög komplexitet eller trögrörligt IoT-systemet om uppbyggnaden inte är väl genomtänkt från början. Därför krävs ett större mått av eftertanke i form av arkitekturer och IT strategier i initiala faser i beställaren organisation.

• Avtal med leverantörer behöver säkerställa beställarens ägande- och nyttjanderätt till de data, information och kontextmedvetenhet som skapas i IoT-systemet.

• Beställaren behöver säkerställa långsiktig tillgång till beskrivningar av datamodell för IoT-systemet och mätdata.

Principen betonar flera viktiga aspekter:

1. Berikning av sensordata med kontextdata och även metadata

2. Eget ägande av data.

3. Bevarande av all data vid systembyte.

4. Möjlighet att exportera data.

I upphandlingarna i Jönköping och Västra Götaland täcktes dessa aspekter genom olika krav, inklusive explicita krav på kontextdata. Erfarenheter från Jönköping och Västra Götalandsregionen visar att en lämplig väg är att IoT-systemets ansvarar för att översätta sensordata till läsbara data, medan Tillämpningen ansvarar för att anpassa data till sitt syfte.
För beställare kan följande vara viktigt att addera; Komplettera kravställning kring möjlighet att importera data.

Mer info och exempel.

IoT-systemets data, information och tjänster bygger på väldokumenterade, standardiserade, tillgängliga och öppna data- och informationsmodeller

Kortnamn: Informationsmodeller

För att uppnå informations interoperabilitet mellan system och applikationer behöver informationsmodellerna vara löst kopplade till varandra.

En best-practice är att bygga informationsmodellerna på standardiserade och brett vedertagna ontologier.

Beställaren behöver för att uppnå interoperabilitet säkerställa långsiktig tillgång till datamodeller för IoT-systemet och dess data.

• Detta säkerställer interoperabilitet både internt och externt.

• Det säkerställer att Informationen förstås oberoende av data och system. Alltså minskar risken för inlåsningseffekter, för höga transformationskostnader.

• Är i linje med MIM2 från OASC.

• Informationsmodellerna blir förvaltningsbara och återanvändbara.

• Följer FAIR principer för data, se FORCE11

• Följer DIN 91357:2017-12 avsnitt 7.2.6 Extended Interoperability, standard för referensarkitektur för Open Urban Platform.

• Bidrar till 5e principen “Återanvänd från andra” och 6e principen “Se till att information och data kan överföras” i DIGG:s “Grundläggande principer för digital samverkan”

• Bidrar till princip M9 “Öppna internationella standarder används för informationsutbyte, avsteg ska vara väl motiverade” i SKR:s Utveckling i en digital tid.

• Det krävs expertis inom området

• Ställer krav på leverantörerna behöver förstå vilka standarder som finns och kunna implementera standardiserade informationsmodeller.

• Det krävs att beställaren skapar ett incitament hos leverantörer att lösa detta.

• Kräver att beställare och beställarorganisationer är aktiva inom standardiseringsorganisationerna för att säkerställa att behoven av standardisering uppfylls.

• Prioritera användning eller utveckling av befintliga datamodeller framför att skapa nya.

• Om det inte är möjligt att hitta färdiga lämpliga datamodeller eller vidareutveckla befintliga, bör standardkoncept och vokabulär användas så långt det går för att möjliggöra en "tillräckligt bra" nivå av överensstämmelse med andra, mer etablerade datamodeller.

• När nya datamodeller behöver skapas, på grund av att ingen lämplig standardiserad datamodell finns tillgänglig, bör de nya datamodellerna vara tydligt definierade med hjälp av en konsekvent och explicit process för att underlätta relationer och transformation mellan de nya datamodellerna och andra standardiserade datamodeller.

Principen visade sig svårtolkad i upphandlingarna, samtidigt belyser den en utmaning i kommunal IoT kring behovet av standardiserade, definierade och beskrivna datamodeller kontra olika applikationers specifika behov av datamodeller. I Jönköping och Västra Götaland var det svårt att ställa krav enligt denna princip, men det är då viktigt att klargöra att upphandlingarna gällde en generell IoT-plattform.

Mer info och exempel.

IoT-Systemet möjliggör bearbetning och berikning av information [på olika sätt]

Kortnamn: Bearbetning och berikning

Information kan bearbetas och berikas beroende på vilka behov som ska lösas. Exempelvis:

• Omvandla data till IoT systemets informationsmodell.

• IoT systemet innehåller mekanismer för att bearbeta data oavsett om det är att kunna skapa händelser, analysera strömmande och/eller vilande data, inkludera eller exkludera data från lagring/bearbetning. Exempelvis:

  • kvalitetskontrolleras,

  • kombineras med verksamhetsdata,

  • ursprungsmärkas,

  • intra/extrapoleras, samplas,

  • kombineras med context-information.

• EDGE bearbetning av dataintensiva/ datavoluminösa sensorer/lösningar kan göra lokal bearbetning. EDGE bearbetning kan också vara lämpligt vid bearbetning av känslig information (bilder/video, persondata) så att denna informationsmängd ”termineras” där och inte förs vidare in i IoT-systemet.

• Grundläggande funktion för att kunna skapa tillämpningar mha IoT systemet som levererar nytta till verksamheten.

• Grundläggande funktion för att kunna åstadkomma kontext i IoT systemet. I ett följande steg kan en kontextmedvetenhet (Context-Awareness) åstadkommas.

• Ger större möjlighet i nyttjandet av information från IoT systemet genom att:

  • information kan lättare konsumeras av olika applikationer

  • information kan lättare anpassas till olika applikationer

• Samma information kan finnas i olika förädlingsgrad på olika ställen i IoT-systemet och därför blir det viktigt att hålla god ordning på all information och hur bearbetning av data går till.

• Kräver att det finns kompetens kring hur IoT-systemets informationsmängd och informationsmodell är uppbyggd och hur den ska förvaltas.

• Avtal med leverantörer och den valda arkitekturen behöver hänga ihop så att drift- och förvaltningskostnader kan hanteras på effektivt sätt.

Denna princip beskriver på sätt och vis många av huvudfunktionerna i ett generellt horisontellt IoT-system. Samtidigt är detta en beskrivning och princip på väldigt hög nivå.

I Jönköping och VGR använde vi inte denna princip i sig själv men ställde en stor mängd mycket mer detaljerade krav som på sätt och vis kan sägas omfattas av denna princip.

Mer info och exempel.

IoT-Systemet stöder att data lagras på olika sätt utifrån informationens karaktär och användningsbehov

Kortnamn Lagring

Ofta behöver samma eller mycket liknande data lagras i olika lagring pga prestandakrav eller andra krav. Eller därför att organisationen vill byta lagrings-lösning. Exempelvis behöver lagringen:

• kunna hantera data som är tidserie-baserat

• uppfylla möjligheter till “retention policies”, för att kunna gallra data efter en viss tid.

• uppfylla organisationens krav på informationssäkerhet, lagkrav och policies

• kunna spara ostrukturerade och strukturerade data, bilder, video, etc.

• Kunna livscykelhantera data och information, tex rådata, verifierad rådata, bearbetad rådata, publicerad data och arkiverade data. I detta ingår hur data gallras i respektive steg.

• Olika verksamhetsbehov ställer olika informationssäkerhetskrav som behöver uppfyllas

• En väl utformad lagring ger möjlighet till analys av information på ett strukturerat sätt

• Ger möjlighet att hantera lagringskostnader

• Ger möjlighet till bredare användning

• En offentlig beställare behöver uppfylla och följa den informationshanteringsplan som är beslutad inom respektive organisation.

• Ett riskbaserat och systematiskt informationssäkerhetsarbete hos beställaren är en förutsättning inför och under lagerhållning av information för vidareutnyttjande eller bearbetning/berikning

• IoT-system kan resultera i stora datamängder och/eller innehålla känslig information. Organisationen behöver därför kartlägga vilka data som ska lagras och bedöma vilka data som är viktiga att lagras, arkiveras respektive gallras.

• En offentlig beställare behöver ta fram och följa den informationshanteringsplan som är beslutad inom respektive nämnd. Den tekniska lösningen behöver därför bidra till att stödja beställaren med detta.

• Beställaren behöver förstå vilka alternativ som står till buds och som uppfyller It-systemets behov .

• Avtal med leverantörer och den valda arkitekturen behöver hänga ihop så att drift- och förvaltningskostnader kan hanteras på effektivt sätt.

Principen är viktig.

I Jönköpings- och Västra Götalands-upphandlingarna, där det var många deltagande organisationer, ställdes krav både på hur och var drift och lagring skulle kunna göras. Detta för att lösa de deltagande organisationernas krav på egen drift och lagring, men också för att kunna lagra och vidareförmedla den insamlade informationen på olika sätt.

Mer info och exempel.

IoT-systemet klarar att möta en definierad risk- och konsekvensnivå [för att uppnå avsedd informationssäkerhet]

Kortnamn: Informationssäkerhet

En tillämpning av IoT systemet har en specifik nivå på risker och konsekvenser. Denna nivå måste alltid vara lika med eller lägre än den risk och konsekvensnivå som IoT systemet ska kunna möta tillämpningens nivå. Därför krävs det:

1. En tillämpnings behov av IoT behöver uttrycka vilka krav den ställer för att uppfylla sin risk och konsekvensnivå. Dessa behöver utvärderas mot IoT-systemet för att bedöma lämpligheten eller behoven av utbyggnad för att uppfylla kraven. För varje tillämpning behöver det därför bedömas om IoT Systemet kan användas.

2. IoT systemet behöver ha väl beskrivna förmågor, som beskriver vad det kan leverera, samt relevant teknisk beskrivning, så att tillämpningar kan förstå vad de kan förvänta sig av IoT systemet.

En risk och konsekvensnivå kan rimligen göras mha SKR:s Klassa med dess vägledning “Klassa för IoT” där hela kedjan från sensor/ställdon till applikation/tillämpning hanteras.

• Centralt för att uppnå och vidmakthålla den efterfrågade informationssäkerheten.

• Ett IoT-system som ska klara av att hantera mycket stora risker och konsekvenser kommer att bli dyrt att införskaffa och förvalta.

• När IoT-systemets förmåga är väl beskriven är det enklare att skala upp, nå en ökad innovationstakt och nå en flexibel lösning som kan användas av flera.

• Bättre stödja informationsägare

• Stödja verksamhet och IT i att hantera åtkomst och behörighet till information och tjänster

• Bidrar till 9e principen “Gör det säkert” i DIGG:s “Grundläggande principer för digital samverkan”

• Bidrar till princip M8 “Arbetet med informationssäkerhet sker systematiskt och riskbaserat” i SKR:s Utveckling i en digital tid.

• En tillämpning behöver tydligt uttrycka vilka krav den ställer på IoT systemet för att uppfylla sin risk- och konsekvensnivå.

• En tillämpning är ur ett risk- och konsekvensperspektiv är lika stark som dess svagaste länk. Därför bör lösningar granskas så att de utvärderas mot ett generellt IoT system.

• Utvärdera IoT-arkitekturens lämplighet utifrån tillämpningens specifika risk- eller konsekvensnivåer.

• Det kan krävas olika IoT system för specifika ändamål, beroende på risk och konsekvensnivå.

• Beställaren behöver säkerställa att informationssäkerheten i IoT-systemets alla moduler fungerar tillsammans. Nyttja gärna avsnitten 4.1, 4.2, 4.3 och 6 (High level recommendations) i ENISA Baseline Security Recommendations for IoT eller liknande.

• Beställaren behöver säkerställa att alla i IoT-systemet ingående leverantörers SLA räcker för att säkerställa tillämpningarnas specifika risk- och konsekvensnivå.

• Beställaren behöver bedöma om leverantörens organisation uppfyller krav på interna informationssäkerhetsrutiner.

• Beställaren behöver säkerställa att ingående leverantörer uppfyller de krav ställs för att uppfylla informations-säkerhetskraven.

• Beställaren behöver säkerställa att ingående leverantörers SLA kan ändras, antingen uppåt eller neråt, till en kontrollerbar kostnad.

• Organisationen behöver definiera vilken risk och konsekvensnivå som den ställer krav på.

• Beställarorganisationen kan behöva söka tillstånd från länsstyrelser eller myndigheter för att sätta upp sensorer på allmänna platser.

• En beställare behöver alltid säkerställa HELA informationsflödet, i IoT fallet från/till IoT-enhet till/från tillämpning. För att göra detta kan segmentering utifrån risk och konsekvensnivå vara en rimlig väg. Segmentering kan avse tex konnektivitet, nätverk, datalagring, drifthallar.

  En beställare som avser att implementera IoT lösningar, särskilt när delsystem integreras, behöver anamma ENISA:s princip om ”security by design”. Självklart behöver varje delsystem även anamma principen om ”security by design”.

I upphandlingarna i Jönköping och Västra Götaland upphandlades en generell IoT-plattform, där drift och lagring ska kunna hanteras lokalt. I en generell IoT-plattform vet upphandlaren inte i förväg vilken typ av information som kommer att hanteras. I arbetet har SKR:s Klassa och andra säkerhetskrav från IT-avdelningarna använts. Rekommendationerna från ENISA användes ej.

Mer info och exempel.

IoT-systemet klarar digital hantering av fysiska IoT-enheter och deras koppling till IoT-systemet

Kortnamn: Fysiska IoT-enheter

Denna princip hanterar den inledande provisionering av IoT-enheter och den digitala hanteringen av IoT-enheter under livscykeln.

Till IoT-systemet kommer det kopplas mängder med IoT-enheter. Det är därför viktigt att IoT-systemet är flexibelt och kan hantera olika fysiska IoT-enheter och konnektivitet.

För att vid varje givit tillfälle veta vilka IoT-enheter finns och vilken status de har avsett t.ex. konnektivitet och funktion behöver IoT-systemet:

1. kunna hantera uppdateringar av fysiska IoT-enheter, tex firmware, konfigurationer, avkodning via IoT-systemet.

2. hantera provisionering av fysiska IoT-enheter, som är länkade till en central hantering av de virtuella IoT-enheterna. Därmed fås en automatisk och dynamisk förteckning över alla fysiska IoT-enheter som är provisionerade till IoT-systemet.

Definitioner:

• Provisionering: processen för hur en virtuell IoT-enhet skapas och hur en fysisks IoT-enhet kopplas upp mot IoT-systemet.

• Skapar förutsättningar för förvaltningsbarhet och översikt över vilka fysiska IoT-enheter som finns tillgängliga inom IoT Systemet

• Vid varje givet tillfälle veta vilka sensorer finns och vilken status de har avsett t.ex. konnektivitet och funktion.

• Underlätta felsökning i fysiska IoT-enheter.

• Kräver att det finns kompetens kring IoT-systemets uppbyggnad och de processer som krävs för livscykelhantering av IoT-enheter.

• Kräver att det finns en organisation (och eventuella avtal med leverantörer) som sköter och hanterar IoT-enheter så att IoT-enheterna uppfyller de krav som de olika tillämpningarna ställer.

Detta är en viktig princip och en viktig egenskap för ett IoT-system. I Jönköping och Västra Götaland utvecklades en rad krav relaterade till denna princip.

Med info och exempel.

IoT-systemet klarar att hantera virtuella IoT-enheter

Kortnamn: Virtuella IoT-enheter

Definitioner relevanta för principen:

• “Virtuell IoT-enhet” - Representerar en fysisk IoT-enhet eller en simulerad IoT-enhet.

• “Simulerad IoT-enhet” avser en virtuell IoT-enhet som inte är direkt kopplad till en fysisk IoT-enhet, tex ett framräknat värde. Arbetsgruppen har avgränsat sig till IoT-enheter, dvs sensor eller ställdon.

Inom IoT-systemet är den virtuella IoT-enheten det objekt som tillämpningar interagerar med. Den virtuella IoT-enheten hanterar i sin tur interaktionen med den fysiska IoT-enheten.

Den virtuella IoT-enheten håller information och metadata om sig själv.

En virtuell IoT-enhet kan leverera ett beräknat värde från ett fysisk värde eller till och med finnas utan att det finns en fysisk IoT-enhet.

Virtuell IoT-enhet kan vara direkt kopplad till en fysisk IoT-enhet eller vara en simulerad IoT-enhet som får sina data från tex ett framräknat värde, informationskällor på internet, data från ett SCADA system eller annat IoT-system, etc.

NOTERING: ISO 20924 hanterar inte simulerade virtuella IoT-enheter, vilket är en begränsning som inte upplevs rimlig. Därför har arbetsgruppen i detta arbete utökat med simulerade IoT-enheter som en delmängd av virtuella IoT-enheter.

• Genom att skilja på fysiska och virtuella IoT-enheter förenklas tillämpningsutveckling och förvaltningsbarheten ökas.

• Att skilja på virtuella och fysiska IoT-enheter är en förutsättning för att kunna koppla ihop IoT-system både för generella horisontella lösningar och vertikala lösningar.

• Hjälper till att skapa lösa kopplingar i IoT-systemet och därmed bidrar till att kunna byta ut moduler och fysiska IoT-enheter.

• En virtuell representation av den fysiska IoT-enheten är viktig då tillämpning inte kan ha direkt kontakt med den fysiska IoT-enheten.

• Det är viktigt att kunna hantera informationen på samma sätt även om informationskällan inte alltid utgörs av en fysisk IoT-enhet, därför behöver vi hantera simulerade IoT-enheter.

• Inga Implikationer identifierade

I Jönköping och VGR ställdes olika krav relaterade till virtuella IoT-enheter eftersom dessa är viktiga. Begreppet ”Simulerade enheter” användes dock inte.

Mer info och exempel.

IoT-systemet möjliggör styrning och orkestrering av händelsedrivna informationsflöden

Kortnamn: Orkestrering

Definition: Händelsedrivet informationsflöde

Se wikipedia

Definition: Orkestrering

Se wikipedia

I IoT-systemet förflyttas händelsedriven information mellan noder där information berikas eller bearbetas för att tillämpningar ska kunna nyttja informationen, därför är det centralt att hålla koll på informationsflödena vilket görs genom bra verktyg för orkestrering.

Inom och utanför IoT-systemet kommer flera applikationer att behöva nyttja data och information från virtuella IoT-enheter. Funktionen att styra och orkestrera flödet av information inom och utåt från Iot-Systemet är därför helt central för ett välfungerande IoT-System.

Det behöver finnas möjlighet att i IoT-systemet definiera producerade o konsumerande tjänster, för både interna och externa informationsflöden. Detta löses ofta med publish/subscribe tjänster och det finns även inslag av ETL(Extract/Transform/Load)-tjänster och köhantering kring detta.

Exempel på lösningar för detta är Apache Kafka, MQTT, Amazon Kinesis, Google Sub/Pub, Microsoft DataFactory. Dessa tjänster behöver beskriva vilka API:er/accesspunkter som kan användas.

• En grundläggande funktion i IoT-system för att kunna dela och nyttja IoT-information i och mellan olika system och verksamheter.

• En förutsättning för att uppnå Princip 4: IoT-Systemet möjliggör bearbetning och berikning av information [på olika sätt]

• IoT-Systemet bygger på att information flödar mellan noder där information berikas eller bearbetas (se princip 4) för att nå en skalbarhet och förvaltningsbarhet är det därför centralt att hålla koll på informationsflödena vilket görs genom bra verktyg för orkestrering.

• Kräver god kännedom om organisationens informationsmodeller och hanteringsregler för data i de olika tillämpningarna.

• Design av händelsestyrda informationsflöden kan starkt påverka kostnaderna för informationshanteringen i IoT-systemet. Det är därför viktigt för beställaren att säkerställa en kostnadseffektiv design, som grundas i de krav som ställs av respektive tillämpning.

• Avtal med leverantörer och den valda arkitekturen behöver hänga ihop så att drift- och förvaltningskostnader kan hanteras på effektivt sätt.

I Jönköping och Västra Götaland var det svårt att förstå och tillämpa denna princip, som kanske är mer relevant för utvecklare än för beställare. Man kan dock begära beskrivningar från leverantören om informationsflöden i IoT-systemet.

I flera IoT-system finns inbyggda informationsflöden som är optimerade för systemets funktion, vilka kan vara svåra för slutanvändare att styra, men möjliga att styra för administratörer eller leverantörer. Andra informationsflöden kan styras av slutanvändare med hjälp av regelmotorer, vilket är centralt i IoT-system och något som ställdes många krav på i upphandlingarna.

Det finns olika uppfattningar om vad som menas med “händelsedriven”. I Jönköping och Västra Götaland ansåg man att vissa informationsflöden i IoT-system inte är händelsestyrda, som t.ex. strömmande data.

Mer info och exempel.

IoT-systemets information, tjänster och data är tillgängliga för tillämpningar

Kortnamn: Dela Data

IoT-systemet ger tillgång till information, data och tjänster med korrekt behörighet (kan även avse öppna data utan begränsningar).

Information från sensorer, händelsedriven information eller historiska data, görs tillgängliga via IoT-systemet. Tillgång ska även kunna ges till styrdons tjänster (ex släcka en lampa).

För att uppnå principen bör krav ställas på vilka gränssnitt (API:er) som IoT-systemet exponerar. En bra riktlinje är att följa DIGGs principer för tillgängliggörande av information
och vägledning för att tillgängliggöra information.

• Tillgång till information, tjänster och data, på ett över tid stabilt sätt, är en förutsättning för att uppnå användbarhet och förvaltningsbarhet för de applikationer som använder IoT-systemet.

• För ökad förvaltningsbarhet för de applikationer som nyttjar IoT-systemets gränssnitt (API:er), behöver gränssnitten bygga på etablerade och öppna standarder, se princip 3 “IoT-systemets informationsmodeller bygger på standarder i horisontell övergripande nivå och specifika vertikala nivåer”.

• Open Data and PSI Directive - dvs EU:s direktiv för öppna data direkt som stipulerar att data insamlade av offentliga aktörer i möjligaste mån ska tillgängliggöras.

• Värdet av information uppstår när informationen används.

• I linje med DIGG:s “Grundläggande principer för digital samverkan” princip 3 “Öppna upp”, 6 “Se till att information och data kan överföras” och 13 “Ha helhetssyn på informationshantering”.

• Bidrar till princip M7 “Ett gemensamt ramverk för arkitektur finns och används för alla förvaltningsgemensamma digitala funktioner”, M11 “All data som får delas ska delas så öppet som möjligt på standardiserade format” och M12 “En digital infrastruktur möjliggör informationsutbyte inom offentlig sektor och mellan offentlig och privat sektor” i SKR:s Utveckling i en digital tid.

• Beställarorganisationen behöver ha en tydlig bild över vilka och hur information, tjänster och data tillgängliggörs. Öppna data är en av kanalerna som information kan tillgängliggöras via.

• Beställarorganisationen behöver kartlägga sin egen kompetens att kring införskaffande och förvaltning av ett IoT-system. Om kompetensen är hög så kan beställaren ha en lösning som är flexibel och kan kräva mindre av dokumentation, medan om kompetensen är lägre behöver krav på dokumentation vara högre.

• Beställaren behöver säkerställa att användare av information, tjänster och data har tillgång till support och dokumentation för att kunna nyttja information, tjänster och data på effektivt sätt.

• Avtal med leverantörer och den valda arkitekturen behöver hänga ihop så att drift- och förvaltningskostnader kan hanteras på effektivt sätt.

• Beskrivningar av datamodell för IoT-systemet behöver tillgängliggörs som ontologier i digitalt format för andra tillämpningar som vill komma åt och utnyttja informationen.

Principen om att dela data är avgörande för IoT-system, både för generella IoT-plattformar och specifika IoT-tillämpningar. För generella plattformar är det en självklarhet, medan det för specifika tillämpningar är lika viktigt för att undvika inlåsning av data. I Sverige och EU strävar vi efter att dela data mellan system.

Vid upphandlingarna ställdes krav på kommunikationsgränssnitt och integrationer, med extra poäng för färdiga integrationer med andra system, särskilt kart- och GIS-verktyg.

Mer info och exempel.