NY Kravkatalog IoT
I denna sida dokumenteras relevanta krav att ställa på IoT. Arkitekturgemenskapens riktlinjer för krav finns här Krav
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”.
Exempel på hur kravkatalogen kan omvandlas till upphandlingskrav.
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änn 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
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:
|
| 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. Kravet är mkt viktigt för att förvaltare/beställare ska kunna:
| Utvärdera tex utifrån:
|
| 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:
|
| 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:
|
| 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:
|
| 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:
| Utvärdera tex utifrån:
|
| 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:
|
| 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:
|
| 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:
Kravet kan behöva omformuleras av beställaren beroende på vem som beslutar över arkitekturen. IoT-systemet kan förväntas ha integrationer med andra system som är beroende av IoT-systemets datamodeller. Leverantören bör därför beskriva hur processen för eventuell förändring av datamodell i samband med ny version av IoT-systemet hanteras. Bland annat hur kund och eventuella samarbetspartners informeras om förändringar och hur Leverantören säkerställer bakåtkompatibilitet till dess att övriga systemleverantörer hunnit göra eventuella nödvändiga förändringar för att befintliga integrationer ska fungera. | Hur kan det utvärderas:
|
| 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:
|
| 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:
|
| Princip 1 “IoT-Systemet möjliggör för byte av moduler oberoende av varandra” |
KIOT-011 | Leverantör bör beskriva hur IoT-systemet kan nyttja Unika Identifierare för referens internt och externt.
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:
|
| 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:
| Hur kan det utvärderas:
|
| 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:
|
| 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:
|
| 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:
|
| 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:
|
| 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:
|
| 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. | Datamodellen bör finnas digitalt beskriven på ett maskinläsbart sätt. Beskrivningen bör innehålla tillräckligt mycket kontextinformation för att datamodellen ska kunna bearbetas av annan applikation och uppfylla användarnas behov. | Utvärdera utifrån:
|
| 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. | .DIGG har tagit fram underlag för stöd vid upphandling av data https://www.digg.se/kunskap-och-stod/oppna-och-delade-data/offentliga-aktorer/rekommendationer-for-upphandling-av-data#h-sv-default-anchor-0 Arkitekturgemenskapen tar fram en kravkatalog. RefARK IoT har inte gjort en synkning mot detta arbete. Det kan därför vara lämpligt för den som kravställer IoT-system tittar till kravkatalogen och verifiera om den kan bidra till kravställan. Se Arkitekturgemenskapens kravkatalog https://inera.atlassian.net/wiki/spaces/AR/pages/3171156130 | Utvärdera utifrån:
|
| 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, samt beskrivningar av datamodeller 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:
| 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):
|
| 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:
|
| 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)
|
| 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:
|
| 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)
|
| 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. Definitioner:
| En beställare kan överväga att dela upp detta krav i ett krav för konfiguration och ett för uppdatering om det fyller en funktion i införskaffning. | Utvärdera utifrån:
|
| Princip 7 “IoT-systemet klarar digital hantering av fysiska IoT-enheter och deras koppling till IoT-systemet.” |
KIOT-027 | Leverantör bör beskriva hur IoT-systemet kan provisionera och deaktivera fysiska IoT-enheter. Definitioner:
|
| Utvärdera utifrån:
|
| Princip 7 “IoT-systemet klarar digital hantering av fysiska IoT-enheter och deras koppling till IoT-systemet.” |
KIOT-028 | Leverantör bör beskriva hur en fysisk IoT-enhet kan bytas men fortsatt kopplas till samma virtuella IoT-enhet. |
| Utvärdera utifrån:
|
| Princip 7 “IoT-systemet klarar digital hantering av fysiska IoT-enheter och deras koppling till IoT-systemet.” Princip 8 “IoT-systemet klarar att hantera virtuella IoT-enheter och deras länkning till fysiska enheter” |
KIOT-029 | Leverantör bör beskriva hur den virtuella IoT-enheten kan ändras för att ta in värden från annan fysisk IoT-enhet. |
| Utvärdera utifrån:
|
| Princip 7 “IoT-systemet klarar digital hantering av fysiska IoT-enheter och deras koppling till IoT-systemet.” Princip 8 “IoT-systemet klarar att hantera virtuella IoT-enheter och deras länkning till fysiska enheter” |
KIOT-030 | Leverantör bör beskriva hur fysiska IoT-enheter som hanteras i IoT-systemet representeras och beskrivs i något slags förteckning. |
| Utvärdera utifrån:
|
| Princip 7 “IoT-systemet klarar digital hantering av fysiska IoT-enheter och deras koppling till IoT-systemet.” |
KIOT-031 | Leverantör bör beskriva hur organisatoriskt ägarsskap och förvaltningsorganisation för fysiska IoT-enheter kan dokumenteras på ett strukturerat och tydligt sätt och tillgängliggöras för beställaren.
|
| Hur kan det utvärderas:
|
| Princip 7 “IoT-systemet klarar att hantera fysiska IoT-enheter och deras koppling till IoT-systemet” |
KIOT-032 | Leverantör bör beskriva hur övervakning av fysiska IoT-enheter kan göras i IoT-systemet. | Beställaren behöver ta ställning till hur övervakning ska göras, i egna befintliga system /infrastruktur eller i leverantörens system. | Hur kan det utvärderas:
|
| Princip 7 “IoT-systemet klarar att hantera fysiska IoT-enheter och deras koppling till IoT-systemet” |
KIOT-033 | Leverantör bör beskriva vilka konnektivitetstekniker som kan användas för anslutning av IoT-enheter i IoT-systemet och under vilka förutsättningar. Definition konnektivitetsteknik:
|
| Utvärdera utifrån:
|
| Princip 7 “IoT-systemet klarar digital hantering av fysiska IoT-enheter och deras koppling till IoT-systemet.” Princip 1 “IoT-Systemet möjliggör för byte av moduler oberoende av varandra” |
KIOT-034 | För respektive konnektivitetsteknik bör leverantör beskriva vilka fysikaliska begränsningar som gäller för antal, avstånd, täthet, bandbredd, räckvidd, latency etc för fysiska IoT-enheter.
| KRAV kring fysiska IoT-enheter - När beställaren äger och förvaltar IoT-enheterna. | Utvärdera utifrån:
|
| 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.” |
KIOT-035 | Leverantör bör beskriva livscykelhanteringen av IoT-systemet och dess komponenter. | Kravet handlar om att utvärdera leverantörens förmåga att långsiktigt vara en partner till beställaren. | Utvärdera utifrån:
|
| Princip 1 “IoT-Systemet möjliggör för byte av moduler oberoende av varandra” Detta krav kanske tillhör mer HUR i StratPAK |
KIOT-036 | Leverantören bör beskriva hur virtuella IoT-enheter följer IoT-systemets informationsmodeller. |
| Utvärdera utifrån: (beställare bör anpassa nedan krav till IT-miljö)
|
| Princip 3 “IoT-systemets informationsmodeller bygger på standarder i horisontell övergripande nivå och specifika vertikala nivåer” Princip 8 “IoT-systemet klarar att hantera virtuella IoT-enheter och deras länkning till fysiska enheter” |
KIOT-037 | Leverantör bör beskriva hur en virtuell IoT-enhet kan skapas och användas utan koppling till någon fysisk IoT-enhet (dvs simulerad virtuell IoT-enhet). | En virtuell IoT-enhet kan hämta data från andra håll än fysiska IoT-enheter än de som är kopplade till IoT-systemet. Tex kan en virtuell IoT-enhet hämta information ifrån:
| Utvärdera utifrån:
|
| Princip 8 “IoT-systemet klarar att hantera virtuella IoT-enheter och deras länkning till fysiska enheter” |
KIOT-038 | Leverantör bör beskriva hur [administratör av] IoT-systemet kan skapa, konfigurera, granska och ta bort virtuella IoT-enheter. |
| Utvärdera utifrån:
|
| Princip 8 “IoT-systemet klarar att hantera virtuella IoT-enheter och deras länkning till fysiska enheter” |
KIOT-039 | Leverantör bör beskriva hur virtuell IoT-enhet kan användas för att få tillgång till både händelsedriven information och historiska data. |
| Utvärdera utifrån:
|
| Princip 8 “IoT-systemet klarar att hantera virtuella IoT-enheter och deras länkning till fysiska enheter” |
KIOT-040 | Leverantören bör beskriva vad som ingår i förvaltning av IoT-systemet under avtalstiden. | Frågan är av vikt för att skapa transparens mellan leverantör och beställare. Det handlar om att förstå vad som ingår i leverantörens åtagande kring förvaltning och underhåll. | Utvärdera utifrån:
|
| HUR KRAV → StratPAK |
KIOT-041 | Leverantören bör beskriva hur styrning och orkestrering kan konfigureras, övervakas och modifieras. |
| Utvärdera utifrån:
|
| Princip 9 “IoT-systemet möjliggör styrning och orkestrering av händelsedrivna informationsflöden” |
KIOT-042 | Leverantören bör beskriva vilka lösningsmönster för styrning och orkestrering som lösningen tillhandahåller. | Exempel på lösningsmönster kan vara ex. COAP, MQTT, LWM2M (Lightweight M2M), API:er, händelsestyrd köhantering. Beställaren bör överväga som minimum att: IoT-systemet SKA stödja minst följande dataprotokoll för applikations/presentationslagret: REST och MQTT.
| Utvärdera utifrån:
|
| Princip 9 “IoT-systemet möjliggör styrning och orkestrering av händelsedrivna informationsflöden” |
KIOT-043 | Leverantören bör beskriva möjligheter för att visualisera data från fysiska och virtuella IoT-enheter i diagram, tabeller, kartor och liknande. |
| Utvärdera utifrån:
|
| Princip 7 “IoT-systemet klarar digital hantering av fysiska IoT-enheter och deras koppling till IoT-systemet.” Princip 8 “IoT-systemet klarar att hantera virtuella IoT-enheter och deras länkning till fysiska enheter” Princip 9 “IoT-systemet möjliggör styrning och orkestrering av händelsedrivna informationsflöden” |
KIOT-044 | Leverantören bör beskriva hur IoT-systemet kan säkerställa att skickade sensorsdata kommer komplett och oförvanskad till mottagaren. | För kritiska applikationer eller applikationer där det t.ex. är viktigt med kontinuerliga tidsserier eller de ackumulerade insamlade värdena är av stor betydelse vill man inte tappa inkommande data, tex i händelse av driftsstörningar eller om uppkopplingen bryts. Det är därför viktigt att det finns funktioner för att säkerställa att data lagras och kan kommas åt och bearbetas i efterhand då IoT-systemet fungerar normalt igen. Då antalet sensorer vuxit kan det uppstå situationer där belastningen på IoT-systemet vid vissa tillfällen överstiger systemets förmåga att ta emot och bearbeta inkommande data. Då är det viktigt att IoT-systemet kan tex köa upp inkommande data och bearbeta denna i lämplig ordning. Helst vill man då även ha möjlighet att sätta prioritet så att data för de mest kritiska tillämpningarna blir prioriterade. | Utvärdera ifrån:
|
| Princip 10 “IoT-systemets information, tjänster och data är tillgängliga för applikationer och användare” 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” |
KIOT-45 | Leverantör bör beskriva hur IoT-systemet och dess IoT-enheter kan konfigureras/styras för att enbart skicka nödvändiga data när det behövs |
| Utvärdera utifrån:
|
| 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” |