-Kravkatalog IoT

-Kravkatalog IoT

This content is archived.

I denna sida dokumenteras relevanta krav att ställa på IoT.

Kravkatalogen är framtagen för att vara en riktlinje och stöd för hur ett IoT-system kan införskaffas, vilka aspekter en beställare behöver ta ställning till och hantera. Fokus ligger på att till en potentiell leverantör ställa frågor, som sedan kan utvärderas. Normalt bidrar ett krav till en eller flera principer. Följaktligen kan en potentiell leverantörs lösningsförslag utvärderas utifrån hur de bidrar till de olika principerna.

OBS: Nedan krav kan INTE ställas direkt i en upphandling. Innan en upphandling behöver dessa formuleras om och anpassas för den aktuella upphandlingens behov och syften. Detta inkluderar tex att formulera vilka SKA krav beställaren behöver ställa i sin upphandling. Generella IT krav eller sådant som skiljer avsevärt mellan beställares organisationer, finns inte beskrivna i Kravkatalogen IoT och behöver kompletteras av beställaren, se mer i avsnittet “Områden som Kravkatalogen inte täcker utan anses som allmän IT kunskap”.

Hur läses kravkatalogen för IoT

  • Ett krav kan betraktas som en aspekt som behöver bedömas i ett specifikt IoT-system. Det finns därför en frågeställning (kravformulering) som är till för att få kunskap om hur lösningen är konstruerad.

  • Till flertalet av kraven finns ett förtydligande av kravet. Tex varför det ställs, varför det är viktigt, eller annan beskrivning som en beställare kan behöva ta ställning till.

  • Vidare finns ett “Förslag till utvärdering”, där arbetsgruppen har listat vilka områden den ser att är viktiga att utvärdera kring respektive krav. En beställare kan ha andra utvärderingsaspekter som den behöver lägga till.

  • Vilka principer ett krav bidrar till.

Områden som Kravkatalogen inte täcker utan som anses allmän IT kunskap

  • Förvaltning, support, övervakning och drift av IT system

  • Ledningssystem för informationssäkerhet

  • Generella IT krav som kan skilja sig avsevärt mellan beställarorganisationer

    • Dokumentation

      • Det finns några beskrivningskrav för att förtydliga vissa IoT specifika områden.

    • Källkodshantering

    • Livscykelhantering

    • Kravhantering

    • Testning

      • Det finns dock ett beskrivningskrav under IoT-1 kring detta.

    • Loggning / Observabilitet

Beskrivning av färgkodning för Krav:

  • Vit Bakgrund - Kravet är helt klar och granskat. Kraven är avstämda mot principer

  • Grön bakgrund - Kravet är mer eller mindre färdig formulerat, skulle kunna påbörja granskning

  • Gul bakgrund - Kravet är välformulerat, behöver kontrolleras och interngranskas

  • Röd bakgrund - Arbetsgruppens arbetsmaterial som ej är färdigt eller redo för någon form av granskning

 

Kravnr.

Kravformulering

Förtydligande av krav

Förslag till utvärdering

Kravområde / Arbetsmaterial

Bidrag till Principer

KIOT-001

Leverantör bör beskriva hur informationsmängd, informationsflöde och informationsmodell i IoT-systemet hanteras, konfigureras, upprätthållas, tillgängliggörs och ger överblick åt beställaren.

 

Utvärdera utifrån:

  • hur god överblick dokumentationen ger

  • hur väl det beskrivs hur dokumentation underhålls och förvaltas

  • hur väl det är beskrivet kring verktyg eller metoder för att få överblick över hur tex ett värde har tagit fram

 

Princip 4 “Bearbetning och berikning av information”

KIOT-002

Leverantör bör redovisa hur information kan bearbetas och berikas på alla eller flera nivåer i IoT-systemet.

Möjligheten att berika och bearbeta information är central i ett IoT-system. Vilka beriknings- och bearbetningsmöjligheter som behövs är väldigt starkt beroende av vilka tillämpningar ska använda information.

 

 

Utvärdera tex utifrån:

  • möjligheter för statistiska analyser av data, tex vilka statistikpaket erbjuds.

  • möjligheter att använda för IoT-systemet externa bearbetnings-lösningar, tex en webservice eller andra programmeringsspråk.

  • möjligheter att kombinera data från olika källor.

  • utvärdera utifrån möjlighet för anomali-detektering.

  • möjligheter för maskininlärning för hantering av aggregerade tidserier, tex prognostisering av framtida mätvärden.

  • möjligheter för transformering av data mellan olika datamodeller.

  • möjligheter att utföra filtrering och aggregering av dataströmmar för att kunna tillgängliggöra data med olika frekvens (sekund, 1 minut, 15 minuter, 1 timme eller annan tidsperiod) direkt på strömmande data.

  • berika insamlad data med metadata och masterdata från andra datakällor direkt på det strömmande datat.

  • Vad är det som ingår i leverantörens lösning och vad är tillägg.

 

Princip 4 “Bearbetning och berikning av information”

 

KIOT-003

Leverantör bör beskriva hur konfiguration och administration av moduler för bearbetning och berikning kan göras, tex ändring i transformering av datamodeller, ändring i anomali-detektering, etc.

 

Utvärdera utifrån:

  • möjligheten att utföra åtgärderna enkelt i ett webgränsnitt (NoCode/LowCode) av drift/förvaltningspersonal, utan att installera eller ändra i driftmiljön, och utan att ta hjälp av leverantörens utvecklare.

  • bedöm användbarheten i lösningsförslaget.

 

Princip 4 “Bearbetning och berikning av information”

KIOT-004

Leverantör bör beskriva hur konfiguration och administration av moduler för styrning och orkestrering och berikning kan göras, tex inställning av regelverk, tröskelnivåer, nya/ändrade flöden.

 

Utvärdera utifrån:

  • möjligheten att utföra åtgärderna enkelt i ett webgränsnitt (NoCode/LowCode) av drift/förvaltningspersonal, utan att installera eller ändra i driftmiljön, och utan att ta hjälp av leverantörens utvecklare.

  • bedöm användbarheten i lösningsförslaget.

 

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

KIOT-005

Leverantör bör redovisa hur händelsedriven och lagrad data i IoT-systemet kan resultera i nya händelser och/eller aktiviteter.

Möjligheten att reagera på information är central i ett IoT-system. Vilka möjligheter till att reagera på information är väldigt starkt beroende av vilka tillämpningar ska använda information. Ibland pratas det om detta som regelmotor. Dessa regelmotorer kan vara uppbyggda på olika sätt.

Utvärdera tex utifrån:

  • möjligheten till att skapa regler inom IoT-systemet.

  • möjligheten och graden av konfigurering för att skapa regler.

  • möjligheten för att nyttja AI eller maskininlärning för att skapa regler.

 

Princip 4 “Bearbetning och berikning av information”

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

KIOT-006

Leverantör bör beskriva vad som inverkar på prestanda och kapacitet, samt hur skalning påverkar den inom IoT-systemet.

Beställaren bör utöver detta beskrivningskrav överväga att ställa ett antal SKA krav kring prestanda, beroende på de krav som tillämpningen ställer. Dessa krav kan röra, tex:

  • antal fysiska IoT-enheter eller virtuella IoT-enheter, och hur antal påverkar prestanda i övriga IoT-systemet.

  • svarstider i bearbetning och berikning av data.

  • svarstider i lagring.

  • lagringskapacitet.

  • Genomströmning (Through-Put) av data.

Utvärdera tex utifrån:

  • Hur komplett bild leverantören ger av vad som påverkar prestanda, kapacitet och skalning.

  • Hur komplett bild leverantören ger av vilka åtgärder kan vidtas för att öka kapacitet i IoT-systemet utan att införa ytterligare hårdvara.

  • Hur starka åtaganden kring prestanda, kapacitet och skalning leverantören gör i sina svar.

  • Vilka prestanda- och kapacitetsparametrar IoT-systemet erbjuder för mätning och övervakning, både internt och till externa övervakningssystem.

  • Utvärdera utifrån skalbarhet versus kostnad.

 

Princip 1 “IoT-Systemet möjliggör för byte av moduler oberoende av varandra”

Princip 4 “Bearbetning och berikning av information”

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

Princip 6 “IoT-systemet klarar att möta en definierad risk- och konsekvensnivå”

Princip 7 “IoT-systemet klarar digital hantering av fysiska IoT-enheter och deras koppling till IoT-systemet.”

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

Princip 10 “IoT-systemets information, tjänster och data är tillgängliga för applikationer och användare”

KIOT-006

Leverantör bör beskriva kostnadspåverkan för olika skalningsscenarier.

Beställaren bör beskriva några scenarier för nutida/framtida kapacitetsbehov i IoT-systemet, dessa bör leverantören estimera och som sedan kan ingå i utvärderingen.

Utvärdera utifrån:

  • kostnadsuppskattningar för de olika scenarierna.

 

Princip 1 “IoT-Systemet möjliggör för byte av moduler oberoende av varandra”

Princip 4 “Bearbetning och berikning av information”

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

Princip 7 “IoT-systemet klarar digital hantering av fysiska IoT-enheter och deras koppling till IoT-systemet.”

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

Princip 10 “IoT-systemets information, tjänster och data är tillgängliga för applikationer och användare”

KIOT-007

Leverantör bör redovisa hur kontextmedvetenhet skapas och upprätthålls inom IoT-systemet.

 

Hur kan det utvärderas:

  • Hur heltäckande beskrivningen är.

  • Hur väl det uppfyller Princip 4 och Princip 2.

 

Princip 4 “Bearbetning och berikning av information”

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

KIOT-008

Leverantören bör redovisa hur versionshantering går till för IoT-systemets arkitektur som helhet samt för dess ingående moduler och gränssnitt.

Varför är kravet viktigt:

IoT-systemet kommer behöva växa och förändras organiskt över tid, därför är det viktigt att följande punkter hanteras i införskaffandet av IoT-systemet:

  • bakåtkompatibilitet mellan moduler

  • versionshantering av moduler, ex uppgradering av databassystem

  • versionshantering av gränssnitt/standarder för dataöverföring

  • versionshantering av arkitekturen som helhet

Kravet kan behöva omformuleras av beställaren beroende på vem som beslutar över arkitekturen.

Hur kan det utvärderas:

  • bakåtkompatibilitet mellan moduler.

  • versionshantering av moduler, ex uppgradering av databassystem.

  • versionshantering av gränssnitt/standarder för dataöverföring.

  • versionshantering av arkitekturen som helhet.

 

Princip 1 “IoT-Systemet möjliggör för byte av moduler oberoende av varandra”

KIOT-009

Leverantören bör ge en en arkitekturell beskrivning över IoT-systemet, som innehåller dess modulära uppbyggnad och respektive moduls funktion.

 

Hur kan det utvärderas:

  • Utvärdera lösningen utifrån hur väl funktionsmässigt avgränsade moduler den har.

  • Utvärdera den arkitekturella beskrivning leverantören lämnar tex utifrån relevanta delar av Annex A i DIN SPEC 91357 (vilka delar måste framgå av upphandlingsunderlaget).

 

Princip 1 “IoT-Systemet möjliggör för byte av moduler oberoende av varandra”

KIOT-010

Leverantör bör beskriva hur en test- och en acceptansmiljö kan upprättas för IoT-systemet och dess fysiska IoT-enheter.

 

Hur kan det utvärderas:

  • Utvärdera utifrån hur komplett beskrivningen är.

  • Utifrån hur enkelt det är för en utvecklare att testa dataflöden.

  • Utifrån hur enkelt det är att utvärdera och testa nya sensorer.

 

Princip 1 “IoT-Systemet möjliggör för byte av moduler oberoende av varandra”

KIOT-011

Leverantören bör redovisa hur alla modulers gränssnitt och datamodeller, i IoT-systemet, kan bygga på etablerade standarder.

 

Hur kan det utvärderas:

  • Utvärdera lösningen utifrån hur standardiserade dataformat som används för överföring mellan moduler.

 

Princip 1 “IoT-Systemet möjliggör för byte av moduler oberoende av varandra”

Princip 3 “IoT-systemets informationsmodeller bygger på standarder i horisontell övergripande nivå och specifika vertikala nivåer”

KIOT-012

Leverantör bör redovisa hur varje modul i IoT-systemet uppfyller de informationssäkerhetsåtgärder som finns i avsnitten 4.1, 4.2 och 4.3 i ENISA Baseline Security Recommendations for IoT eller liknande.

Varför är kravet viktigt:

Informationssäkerhet behöver inkluderas by-design i IoT -systemet. Att uppfylla ENISA:s informationssäkerhetsåtgärder är ett bra sätt att få en lämplig nivå av säkerhet för tillämpningen.

IoT-systemet kommer i de flesta organisationer involvera flera parter, tex driftsorganisationer, förvaltningsorganisationer, nätverkssystem. Det är därför centralt att beställaren hanterar ansvarsfrågor mellan moduler på adekvat sätt.

Beställaren kan överväga att använda följande material som guideline för bedömning av relevanta informationssäkerhetsåtgärder:

  • MSB Vägledning för grundläggande kryptering

  • MSB Vägledning för fysisk informationssäkerhet i it-utrymmen

  • Stadsnätsföreningens “Robust och Säker IoT

  • SKR:s Klassa för IoT

Hur kan det utvärderas:

  • Utvärdera Leverantörens svar utifrån vilket ansvar den tar för upprätthållande av informations-säkerhetsåtgärder under hela livscykeln för respektive modul.

  • Beställaren bör överväga att bryta upp och utvärdera leverantörens svar i delar, utifrån ENISA:s uppdelning alternativt utifrån moduler.

  • Beställaren bör överväga att utvärdera utifrån hur leverantören kan anpassa IoT-systemet till befintliga moduler och förmågor i beställarens IT-miljö, tex för autentisering och auktorisering.

  • Utvärdera leverantörens svar utifrån hur väl de definierar ansvarsfördelning mellan olika aktörer i IoT-systemet.

 

Princip 6 “IoT-systemet klarar att möta en definierad risk- och konsekvensnivå”

KIOT-013

Leverantör bör redovisa hur IoT-systemets olika moduler kan integreras mot beställarens autentiserings och auktoriserings system. (Beställaren bifogar beskrivning av befintlig lösning)

Beställaren behöver beskriva vilka krav som faktiskt behöver beställas. Dessa krav är väldigt specifika för respektive organisation.

 

 

Princip 6 “IoT-systemet klarar att möta en definierad risk- och konsekvensnivå”

KIOT-015

OM det finns processer kring fysiska IoT-enheter som en leverantör ska hantera:

Leverantör bör beskriva processen för installation, utbyte, kalibrering, service eller underhåll (tex byte av batterier) av fysiska IoT-enheter vid behov .

 

 

Utvärdera utifrån hur lösningen:

  • Hur leverantören beskriver preventiva alternativ reaktiva aktiviteter.

  • Hur respektive process bedöms påverka tillgängligheten i dataflöde relativt informationssäkerhet kring tillgänglig.

 

Detta krav tillhör “HUR” frågan, dvs stratPAK, snarare än RefARK.

KIOT-014

Leverantör bör beskriva hur data kan lagras

 

 

Utvärdera utifrån hur lösningen:

  • Hanterar data som är tidserie-baserat.

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

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

  • Möjlighet till flexibilitet i vart och hur data kan lagras, tex i moln, on-prem, data-lake, databas eller liknande.

  • Kan hantera stora/enorma datamängder, utifrån prestanda respektive kostnader.

  • Hur informationen kan lagras på olika lagringsytor beroende på tex informations-säkerhetsklassning.

  • Utvärdera kostnader utifrån import, lagring, åtkomst och export/migrering

 

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

 

KIOT-016

 

Leverantör bör beskriva hur lagrade data kan bearbetas och hanteras.

Beskrivning av kravet:

I detta krav avses främst bearbetning av historiska data som görs för någon typ av arkiv ändamål.

Utvärdera utifrån hur lösningen:

  • Uppfyller möjligheter till “retention policies”, för att kunna gallra och aggregera data tex efter en viss tid. Tex en månadsvis automatisk process som reducerar sekundmätning till minutvärde, eller manuellt ta bort mätningar äldre än 2 år.

  • möjlighet för att flytta data mellan olika lagringsmedier/ytor/datasjöar för att kunna uppnå den effektivaste lagringsplatsen beroende på till exempel informationssäkerhetsnivå, format, ålder, användning och lagringskostnad.

  • möjlighet för att lagra alla inströmmande data i ett förinställd tid, tex 10 minuter eller 30 dagar.

 

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

Princip 4 “Bearbetning och berikning av information”

KIOT-017

Leverantör bör beskriva hur data kan migreras till och från lagringsmodulen.

 

Beskrivning av kravet:

Den upphandlande myndigheten kommer med allra största sannolikhet behöva flytta data mellan lagringsmoduler under informationens livslängd. Det är därför viktigt att ha en i början av ett uppdrag ha en tydlig bild av hur kostnaderna ser ut vid byte till annan lagringsmodul.

Utvärdera utifrån:

  • Kostnad och möjligheter för att föra in information i lagringslösningen, både transaktioner från sensorer och massinladdning av befintlig information

  • Kostnad för att ha information lagrad

  • Kostnad och möjligheter för att exportera information i standardiserade format.

 

Princip 1 “IoT-systemet möjliggör för byte av moduler oberoende av varandra”

Princip 5 “IoT-systemet stöder att data lagras på olika sätt utifrån informationens karaktär och användningsbehov”

 

KIOT-018

Leverantör bör beskriva hur data, information och kontextmedvetenhet på ett fullödigt och detaljerat sätt kan importeras till respektive exporteras ifrån IoT-systemets moduler.

Beskrivning av kravet:

Den upphandlande myndigheten kommer med allra största sannolikhet behöva flytta data mellan IoT-system under informationens livslängd. Det är därför viktigt att ha en i början av ett uppdrag ha en tydlig bild av hur data kan migreras mellan IoT-system.

Utvärdera utifrån:

  • Vilka informationsmodeller och ontologier som data kan exporteras som. Jo mer standardiserade format (dvs ISO respektive öppna standarder) desto bättre.

  • Lägg stort fokus kring kontextmedvetenhet. I dagsläget (2020) bedömer arbetsgruppen att detta kan vara svårt att nå i en nära framtid.

  • OM AKTUELLT: Hur import från tex beställarens befintliga IoT-system (utifrån bifogad beskrivning) kan göras.

  • Utifrån hur komplett informationsmängd kan importeras respektive exporteras till/från IoT-systemets moduler

  • Hur väl leverantören beskriver processen och hur tydlig kostnadsbilden för detta är.

  • hur komplett beskrivningen kring export av data information och kontextmedvetenhet är och vilka åtaganden leverantören gör kring detta.

 

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

Princip 3 “IoT-systemets informationsmodeller bygger på standarder i horisontell övergripande nivå och specifika vertikala nivåer”

KIOT-019

Leverantör bör beskriva informationsmodeller och informationsutbytesmodeller inom IoT-systemet, inklusive hur de bygger på etablerade och/eller öppna standarder.

Beskrivning av kravet:

  • Den information som leverantör beskriver kommer med stor sannolikhet att betraktas som affärshemlig. Det är därför viktigt att förtydliga för leverantör att information kommer hanteras som i enlighet med det.

Utvärdera utifrån:

  • Finns definierade kodlistor som översätter/beskriver informationsmängder? Följer kodlistor någon form av standard?

  • Finns en ontologi som beskriver informationsmodeller och informationsutbytesmodeller som inkluderar kodlistor?

  • Hur kontextmedvetenhet är strukturerad och beskriven

  • Används SI enheter och finns de definierade i informations-modellen?

  • Finns stödjande dokumentation som beskriver informationsmängden?

  • Finns definierade verksamhetsobjekt och hur de hänger ihop?

  • Vilka etablerade eller öppna standarder beskrivs?

  • Säkerställ att ägande- eller nyttjanderätt till samtlig information ovan tillhör beställaren vid avtalsslut.

 

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

Princip 3 “IoT-systemets informationsmodeller bygger på standarder i horisontell övergripande nivå och specifika vertikala nivåer”

KIOT-020

Leverantör bör beskriva hur det säkerställs att beställaren har full ägande- och nyttjanderätt till samtliga data, metadata, kontextmedvetenhet och informationsmodeller både under avtalstiden och efter avtalstiden.

 

Utvärdera utifrån:

  • Hur beskriver leverantör beställarens ägande- och nyttjanderätt till samtlig angiven information?

  • Hur behjälplig leverantören är med att hjälpa beställaren att migrera data, metadata, kontextmedvetenhet och informationsmodeller till en ny leverantör.

 

Princip 2 “Data, information och kontextmedvetenhet (Context-awareness) i IoT-Systemet bevaras vid modul och system byten”

Princip 3 “IoT-systemets informationsmodeller bygger på standarder i horisontell övergripande nivå och specifika vertikala nivåer”

KIOT-021

Leverantör bör beskriva hur information, data och tjänster från IoT-systemet, både händelsedriven information och historiska data, kan tillgängliggöras för tillämpningar och användare via standardiserade gränssnitt (API:er).

 

 

Detta krav behöver anpassas efter varje organisations specifika behov och IT-miljö. Detta för att det IoT-system införskaffas är anpassat till beställarens organisation.

 

Beskrivning av kravet:

  • Beställaren behöver definiera hur tillgängliggörandet av information ska gå till ex för andra applikationer, öppna data, API:er, standardiserade dataformat, etc.

  • Beställaren behöver definiera i vilka format data SKA och/eller BÖR kunna tillgängliggöras i.

  • Beställaren är den som äger informationen och behöver säkerställa sin tillgång till informationen.

Utvärdera exempelvis utifrån (och då utifrån beställarorganisationens förutsättningar och vilka lösningar som finns på plats idag och som tydligt beskrivs i upphandlingsunderlagen):

  • Vilka gränssnitt (API:er/filer ex. csv) som IoT-systemet kan tillgängliggöra.

  • Vilka standarder, etablerade och/eller öppna som IoT-systemet kan tillgängliggöra som standarder, samt hur väl de täcker dessa. Tex ETSI-NGSI-LD, W3C Web Of Things. [Beställaren bör här komplettera med de standarder och specifikationer som den behöver].

  • Hur väl leverantör beskriver versionshantering och bakåtkompatibilitet för gränssnitt (API:er).

  • Hur väl den uppfyller organisationens krav på informationssäkerhet, lagkrav och policies (dessa bör beskrivas i upphandlingsunderlagen).

  • Att leverantör beskriver hur mycket arbete det är att anpassa ett gränssnitt (API/filer).

 

Princip 10 “IoT-systemets information, tjänster och data är tillgängliga för applikationer och användare”

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

KIOT-022

Leverantör bör beskriva vilken service, support och dokumentation som leverantören erbjuder för IoT-systemet.

 

 

Utvärdera utifrån:

  • Hur detaljerad dokumentation över gränssnitt (API:er/filer) som leverantör tillgängliggör. Glöm inte metadata över den information som tillgängliggörs i API:er/filer.

  • Dokumentation finns öppet tillgänglig. Dokumentation som inte är öppet tillgänglig värderas lägre.

  • Vilken support och användningsstöd leverantören erbjuder.

 

Princip 10 “IoT-systemets information, tjänster och data är tillgängliga för applikationer och användare”

KIOT-023

Leverantör bör redovisa vilka lösningsmönster som finns tillgängliga i IoT-systemet för tillgänglighet till information, data och tjänster.

 

Utvärdera utifrån: (och då utifrån vilka lösningar som finns på plats idag hos beställarorganisationens)

  • Vilka möjligheter till lösningsmönster som erbjuds.

  • möjligheter kring prenumeration av data (Pub/Sub).

  • möjligheter kring hämtning av aktuella och historiska data med samma slags gränssnitt (API).

  • lösningsmönster kring aktivering av styrdon.

  • hur väl leverantören beskriver lösningens referensarkitektur.

 

Princip 10 “IoT-systemets information, tjänster och data är tillgängliga för applikationer och användare”

KIOT-024

Leverantör bör redovisa hur olika vertikala (domänspecifika) informationsmodeller (ontologier) kopplas till övergripande horisontell informationsmodell.

 

Utvärdera utifrån:

  • hur dynamiska och anpassnings-bara informationsmodellerna är, tex för att hantera SI-enheter, beskrivningar av kontext-medvetenhet, bära information om funktion, produkt, och placering.

  • hur väl beskriven informations-modell[en/erna] är.

  • vilka angivna standarder för informationsmodeller anges, ex SOSA, oneM2M, SAREF.

  • vilken nivå av interoperabilitet som standarderna ger (teknisk [tex REST, → syntaktisk [tex JSON, XML] → semantisk [tex ontology] interoperabilitet )

  • hur tydlig uppdelningen mellan de vertikala och horisontella nivåerna är.

 

Princip 3 “IoT-systemets informationsmodeller bygger på standarder i horisontell övergripande nivå och specifika vertikala nivåer”

KIOT-025

Leverantör bör redovisa hur en tillämpning som nyttjar IoT-systemet kan få en informationsmodell anpassad till sina specifika behov.

 

Utvärdera utifrån: (för utvärdering är det bra att beställaren bifogar beskrivning av specifika lösningar som kan behöva anpassas)

  • vilka standardiserade informations-modeller, som ingår i IoT-systemet, finns för tillämpningar.

  • vilka anpassningar leverantören kan göra till en tillämpning och hur komplex denna verkar.

 

Princip 3 “IoT-systemets informationsmodeller bygger på standarder i horisontell övergripande nivå och specifika vertikala nivåer”

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

KIOT-026

Leverantör bör beskriva hur IoT-systemet kan stödja uppdatering och konfiguration av fysiska IoT-enheter.