| | | | |
|---|
IoT-1 | IoT-Systemet möjliggör för byte av moduler oberoende av varandra 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. 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.
|
IoT-2 | Data, information och kontextmedvetenhet (Context-awareness) i IoT-systemet bevaras vid modul och system byten
| 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 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.
|
IoT-3 | IoT-systemets informationsmodeller byggs i horisontell övergripande nivå och specifika vertikala nivåer | För att uppnå informations interoperabilitet mellan system och applikationer behöver informationsmodellerna vara löst kopplade till varandra. Ofta kan det delas upp i tre nivåer, den horisontella toppnivån, ex oneM2M, som binder ihop vertikala nivåer, tex informationsmodellen för SAREF för smarta hem. Den tredje nivån är applikationsnivån där informationsmodellen är anpassad för en specifik applikations behov. En best-practice är att bygga informationsmodellerna på standardiserade och brett vedertagna ontologier. Horisontella ontologier - Interoperabilitet mellan vertikala ontologier
Vertikala ontologier - Interoperabilitet inom specifik verksamhetsdomän.
Applikations-ontologi - Inom en specifik applikation | 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. 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.
|
IoT-4 | IoT-Systemet möjliggör bearbetning och berikning av information [på olika sätt] | 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:
| 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.
|
IoT-5 | IoT-Systemet stöder att data lagras på olika sätt utifrån informationens karaktär och användningsbehov | 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.
| 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.
|
IoT-6 | IoT-systemet klarar att möta en definierad risk- och konsekvensnivå [för att uppnå avsedd 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: 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. 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 en 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.
|
IoT-7 | IoT-systemet klarar digital hantering av fysiska IoT-enheter och deras koppling till IoT-systemet | 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: kunna hantera uppdateringar av fysiska IoT-enheter, tex firmware, konfigurationer, avkodning via IoT-systemet. 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: | Skapar förutsättningar för förvaltningsbarhet och översikt över vilka fysiska IoT-enheter som finns tillgängliga inom IoT Systemet Vid varje givit 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.
|
IoT-8 | IoT-systemet klarar att hantera 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äknad 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.
| |
IoT-9 | IoT-systemet möjliggör styrning och orkestrering av händelsedrivna informationsflöden 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 en IoT-systemet. Det är därför viktigt för beställaren att säkerställa en kostnadseffektiv design, som grundas 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.
|
IoT-10 | IoT-systemets information, tjänster och data är tillgängliga för tillämpningar Definition: Med tillämpning avses en applikation, system eller tjänst som nyttjar IoT-systemets information, data och tjänster. | 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.
|
