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.

Exempel:

• Data som kommer från en specifik typ av sensor (informtionasmängd) kvalitetssäkras och transformeras i IoT-plattformen (informationsflöde) till beslutad informationsmodell. Informationsflödet och dess konfiguration dokumenteras i RefARK IoT:s mall för IoT-pipeline samt i versionshanterad systemdokumentation för ö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”

Detta krav är i och för sig viktigt men enligt erfarenheterna i Jkp och VGR spänner det över lite för mycket för att vara praktiskt användbart. I upphandlingarna ställdes en rad mer detaljerade krav som relaterar till detta. Samtidigt är det viktigt att efterfråga tydlig information från leverantörerna om man sitter i en upphandlingssituation. Även för en utvecklare torde detta krav behöva preciseras ytterligare.

Mer info.

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:

• på enkelt och användbart sätt implementera IoT-Pipeline inom IoT systemet.

• förstå hur regelkedjor är uppbyggda och för att skapa och underhålla dokumentation över IoT-Pipeline,

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.

• Möjligheten att nyttja verktyg med visuella regelkejdor som kan användas för att bearbeta och berika information och som kräver kort utbildning för användare, eller för användare att få en grundförståelse för hur regelkedjor är uppsatta och hur de fungerar.

Princip 4 “Bearbetning och berikning av information”

Bearbetning och berikning av information är grundfunktioner i ett IoT-system. Jkp och VGR upplevde dock att dessa krav behövde specificeras för praktisk användning vid upphandling eller utveckling.

Som upphandlingsgruppen i Jönköping upplevde det har detta också råkat bli två olika krav i ett. Man anser att berikning och bearbetning är två separata grundfunktioner i ett IoT-system.

Mer info och exempel på upphandlingskrav.

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”

Detta krav har man inte kunnat använda i någon av upphandlingarna. Det har i upphandlingarna i Jkp och VGR upplevts mer som ett krav för någon som ska ta fram en systemarkitektur och utvecklingsmiljö för IoT än krav som är lämpligt att ställa på en färdigutvecklad IoT-plattform. Samtidigt är frågeställningarna ändå viktiga så Jkp och VGR konstaterade att man ändå bör beakta dessa aspekter, kanske framför allt som utvecklare.

Mer info.

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.

Exempel:

• När en enhet ska provisioneras i nätverksoperatörens system ska detta kunna ske från verksamhetens centrala IoT-plattform

• När en enhet ska uppdateras ska detta kunna ske från verksamhetens centrala IoT-plattform

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.

• bedöm hur lösningsförslaget ger överblick och visualisering över IoT-pipelines för beställaren.

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

Detta krav har man inte kunnat använda i någon av upphandlingarna. Det har i upphandlingarna i Jkp och VGR upplevts mer som ett krav för någon som ska ta fram en systemarkitektur och utvecklingsmiljö för IoT än krav som är lämpligt att ställa på en färdigutvecklad IoT-plattform. Samtidigt är frågeställningarna ändå viktiga så Jkp och VGR konstaterade att man ändå bör beakta dessa aspekter, kanske framför allt som utvecklare.

Mer info.

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. I olika IoT-system talas det om regelmotorer, som kan vara uppbyggda på olika sätt och utföra detta i olika lager av IoT-systemet.

Exempel:

• När ett temperaturvärde (händelsedriven) från en termometer avviker mer än X grader ifrån tröskelvärdet för de senaste 30 dagarna (lagrad data) genereras ett larmärende i IoT-systemet (ny händelse/aktivitet) som kan konsumeras av en tillämpning.

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”

I Jkp och VGR var det viktigt att ställa krav på hur olika data kan resultera i nya händelser och/eller aktiviteter. Detta sågs som en viktig del av ett IoT-system. Som Jkp och VGR uppfattat det syftar RefARK-kravet till att adressera detta område. Samtidigt såg Jkp och VGR behov av att gå in mycket mer i detalj på hur detta kan ske. I upphandlingarna ställdes därför väldigt många andra och mycket mer detaljerade krav kring till exempel regelhantering mm i IoT-plattformen.

Mer info och exempel på upphandlingskrav.

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”

I Jkp och VGR begärdes en beskrivning. Upphandlingsgrupperna har gått på den linje som beskrivs under "Förtydligande av krav", dvs ställt krav på vilka prestanda man vill se vid en viss volym sensorer.

I VGR lades även till ett krav (baserat på Princip IoT 4) gällande prestanda baserat på aktiva antal användare och inte bara antal sensorer/mätvärden.

Kravet upplevdes också bra av Jkp och VGR eftersom man upplevde det som en överhängande risk att någon utvecklar IoT-funktioner utan att tänka på hur systemet ska klara en mycket stor mängd sensorer och inkommande data.

Mer info och exempel på upphandlingskrav.

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

Exempel:

• En sensor, med specifik tagg, skickar ett temperaturvärde. IoT-systemet har en lista för att omvandla tagg:en till en rumsidentitet. Rumsidentiteten har en relation till två styrdon, dels en ventil på en radiator som slås på om temperaturen är under ett gränsvärde och dels en ventialtionsfläkt om temperaturen överskrider annat gränsvärde. IoT-systemet kan på detta sätt skapa kontextmedvetenhet genom att hålla reda på relationer mellan sensorer och styrdon.

Förtydligande:

Det finns inom styr- och reglerteknik ett flertal standarder för att upprätthålla denna typ av relationer, tex BRICK, se Introduction.

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”

Att addera information om det sammanhang en sensor befinner sig i såg man i Jkp och VGR som helt nödvändigt. Därför ansåg man i JKP och VGR att detta krav var viktigt. Begreppet “kontextmedvetenhet” upplevde man dock som svårt att definiera och förstå. I upphandlingarna i Jönköping och Västra Götalandsregionen specificerades därför vilka kontextdata som IoT-data skulle kompletteras med, vilket gjorde kraven tydligare för leverantörerna.

Mer info och exempel på upphandlingskrav.

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.

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:

• 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.

• beskrivning av livscykelhantering av API:er, med fokus kring hur länge API:er och datamodeller beräknas vara bakåtkompatibla,

• åtaganden kring förvarning om ändringar av API:er och datamodeller

• hur väl beskrivningen uppfyller vedertagna normer för versionshantering, tex Semantic Versioning 2.0.0

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

Detta krav användes som det är formulerat.

Mer info och exempel på upphandlingskrav.

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

Förtydligande:

Det är viktigt för beställaren att förstå hur hela systemet är uppbyggt, vilka delar som pratar med varandra och på vilket sätt för att förstå möjligheterna till hantering och delning av data samt möjligheterna till att byta ut enskilda moduler.

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”

Detta krav användes som det är formulerat.

Mer info och exempel på upphandlingskrav.

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”

Detta krav användes men utvecklades ytterligare.

I Jönköping ställdes i stället krav på upprättande av miljö för användbarhetstest samt driftsmiljö, som man acceptanstestade.

I Västra Götaland ändrade man kravet till att det ska installeras i två miljöer, en för test och en för skarp drift (IoT 9). Man tog bort krav på acceptanstester då man kan göra det i testmiljön ifall man vill.

Mer info och exempel på upphandlingskrav.

Leverantör bör beskriva hur IoT-systemet kan nyttja Unika Identifierare för referens internt och externt.

Hur kan det utvärderas:

• Hur enskild observation kan identifieras

• Hur enskild Fysisk IoT-enhet kan identifieras

• Hur enskild Virtuell IoT-enhet kan identifieras

• Hur enskilda dataset kan identifieras

• Hur IoT-systemet stöder tex URI:er, eller andra typer av identiteter för länkning av data

• Hur väl lösningen stöder W3C rekommendationer kring Linked Data, se, https://www.w3.org/TR/dwbp/, i synnerhet Best-practices 9 och 10.

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”

I Jkp ställdes krav på standarder, men på ett annat sätt och både utifrån vad IoT-plattformen bygger på idag och hur Leverantören avser arbeta med standarder och engagera sig i standardiseringsarbete framöver.

I VGR har detta utvecklats ytterligare.

I båda upphandlingarna har man även hämtat och använt en mängd krav baserade på de 32 karaktäristikerna för ett IoT-system som listas i ISO/IEC 30141 – Internationella referensarkitekturen för IoT.

Mer info och exempel på upphandlingskrav.

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.

• Hur strukturerat arbetssätt gällande IoT-säkerhet redovisas.

• Hur vedertagen metod för cybersäkerhet tillämpas och refereras till.

• Hur samtliga faser av produktcykeln omfattas.

• Hur IT-säkerhet på ett relevant sätt testas och verifieras, tex via penetrationstester.

• Leverantören gör en självskattning utifrån ENISA:s GAP analys IoT Security Standards Gap Analysis | ENISA

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

I både Jkp och VGR ställdes egna och mer utvecklade säkerhetskrav, både IoT-specifika och allmänna. ENISA användes inte eftersom säkerhetsexperterna inte rekommenderade det. Jkp:s och VGR:s säkerhetsaspekter konstaterade att det finns många fler aspekter kring säkerhet och många andra vägledningar och standarder att beakta inom detta område. Jkp och VGR ansåg därför att RefARK behövde kompletteras med annat material för att kunna användas som grund för säkerhetsarbete eller upphandlingsunderlag.

Jkp och VGR noterade även att Enisa:s material, som RefARK refererar till, är från 2017.

Mer info och exempel på upphandlingskrav.

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å”

Jkp och VGR upplevde detta krav som viktigt. Man vände dock på frågeställningen i upphandlingarna och ställde i stället krav på att integration SKA kunna göras. Leverantörerna fick mervärde om de klarade respektive integration som listades.

Mer info och exempel på upphandlingskrav.

Leverantör bör beskriva hur data kan lagras

Exempel:

• IoT-Systemet lagrar alla rådata ifrån IoT-enheter, tillsammans med telemetridata, i en tidseriedatabas under 2 månader direkt i samband med gateway. Samtliga bearbetade och berikade data som kopplats till en virtuell IoT-enhet lagras i en relationsdatabas i 12 månader, därefter beräknas ett timmedelvärde för varje virtuel IoT-enhet och alla mellanliggande mätningar tas bort.

• Ett IoT-system som innehåller en kamera med lokal bearbetning, men som endast har ett LoRa-chip som kan skicka datan skulle kunna bearbeta bild och film lokalt, men saknar möjlighet att skicka bild & film via LoRa-nätet pga begränsning i payload. Detta bidrar till säkerhet då användare fysiskt måste koppla upp sig mot enheten med kabel för att komma åt lagrad bilddata.

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”

Jkp och VGR ställde i stället krav på de olika sätt man vill att data ska kunna lagras på.

Mer info och exempel på upphandlingskrav.

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 .

Exempel:

• Leverantör bör leverera produkt med fullständig manual som beskriver process för installation, utbyte och avkodning av data, kalibrering, konfiguration, service och underhåll

  • Beställaren kan överväga hur denna typ av service ska kunna hanteras av andra leverantörer, tex om en leverantör går i konkurs

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.

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

Jkp och VGR använde delar av kravet: Leverantören skall beskriva processen i IoT-plattformen för installation, utbyte och konfigurering av fysiska IoT-enheter.

I VGR och Jkp konstaterade man att man måste bestämma vad leverantören respektive man själv eller andra leverantörer ska ansvara för, särskilt om man köper IoT-utrustning från samma leverantör som IoT-plattformen.

I Jönköping köptes ofta sensorer från plattformsleverantören för tester, men projektet tog själv ansvar för installation, utbyte, service och batteribyte.

Mer info och exempel på upphandlingskrav.

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

Förtydligande av kravet:

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

Exempel:

• För öppna data behöver tidserier över dygnsgenomsnittstemperaturen i en badsjö uppdateras till en filexport varje dygn och tillgängliggöras öppet på internet, medan realtidsdata med timgenomsnitt enbart görs tillgängligt i diagram för fritidsförvaltningens karttjänst.

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.

• Möjligheten till att 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.

• möjligheten att uppfylla GDPR:s krav kring information om vad som är lagrat om en person samt i förekommande fall rätten att bli glömd. Dvs möjligheten att söka information respektive att radera.

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”

Jkp och VGR ställde i stället krav på de olika sätt man vill att data ska kunna lagras på och hanteras.

Mer info och exempel på upphandlingskrav.

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 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”

Jkp och VGR använde kravet i princip som det står.

Mer info och exempel på upphandlingskrav.

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”

Jkp och VGR använde kravet i princip som det står.

Mer info.

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:

• Finns definierade kodlistor/vokabulärer som översätter/beskriver informationsmängder? Följer kodlistor/vokabulärer 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.

• Hur prioriteras användningen av befintliga datamodeller över egna datamodeller

• Hur väl datamodellerna följer de rekommendationer som finns från https://semiceu.github.io/style-guide

• Att datamodell och ontologier finns beskrivna i digitalt format som beställaren också får nyttja. Likaså att dessa datamodeller och ontologier är tillgängliga och kan utnyttjas även av andra aktörer som vill nytta data som Beställaren tillhandahåller. Det är också värdefullt om datamodeller och ontologier fortsätter hållas öppet tillgängliga under lång tid fram över av leverantören.

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”

Jkp och VGR använde kravet utifrån dess andemening men delvis omformulerat utifrån "utvärderingskriterier" och "bidrag till principer".

Mer info och exempel på upphandlingskrav.

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 (AG) tar fram en kravkatalog. RefARK IoT har inte gjort en synkning mot detta arbete. Det kan därför vara lämpligt att den som kravställer IoT-system tittar till kravkatalogen och verifiera om den kan bidra till kravställan. Se AG:s Kravkatalog

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”

Jkp och VGR ställde i stället krav på fullständigt ägande. Likaså att man ska få hjälp att migrera data då avtalet upphör.

Mer info och exempel på upphandlingskrav.

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:

• 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).

• Beskrivningar av hur datamodeller kan beskrivas i form av standardiserade och öppna ontologier.

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”

Detta krav upplevde Jkp och VGR som viktigt för både generella IoT-plattformar och enskilda IoT-tillämpningar. För generella plattformar sågs det som en självklarhet eftersom de ska samla in och tillgängliggöra information. För enskilda tillämpningar ansåg Jkp och VGR det också viktigt för att möjliggöra datadelning.

I upphandlingarna ställdes detaljerade 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 på upphandlingskrav.

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”

Som Jkp och VGR såg det kan det vara svårt för leverantören att precisera krav, så köpare bör ställa krav som motsvarar deras behov, med olika nivåer att välja mellan. I Jkp och VGR specificerades önskade nivåer.

Öppen dokumentation ansågs inte nödvändig, men dokumentation skulle vara tillgänglig och användbar för beställaren och andra leverantörer. Som JKP och VGR såg det är öppen dokumentation främst fördelaktig för lösningar baserade på öppen källkod.

API:er behöver vara tillgängliga för andra systemleverantörer. Detaljerade servicenivåkrav inkluderades i upphandlingsavtalen.

Mer info och exempel på upphandlingskrav.

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”

I Jkp och VGR ansåg man att användning av termen “lösningsmönster” kan leda till missförstånd mellan beställare och leverantör om den inte är tydligt definierad. Detta, såg man, kan resultera i att leverantören svarar på ett sätt som inte motsvarar beställarens behov eller förväntningar. Därför formulerades egna och mer detaljerade krav i upphandlingarna.

Mer info och exempel på upphandlingskrav.

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”

Jkp och VGR såg det som viktigt att beskriva hur informationsmodellerna för en generell IoT-plattform kopplas till olika tillämpningar vid upphandling av båda. Hittills har upphandlingar fokuserat på antingen en generell plattform eller specifika tillämpningar. Vissa leverantörer erbjuder färdiga IoT-applikationer i en sammanhållen struktur, vilket kan ha gett upphov till detta krav. Kravet passade dock inte för upphandlingarna i JKP och VGR.

JKP och VGR upplevde en osäkerhet kring i vilken utsträckning standarder och guidlines som RefARK refererar till är kvalitetssäkrade och fortfarande används. Bland annat då man konstaterade att flera av dem har ganska många år på nacken samtidigt som IoT är ett område under stark och snabb utveckling.

Mer info.

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]”

Det här kravet upplevde deltagarna i upphandlingarna i JKP och VGR som svårt att tolka. I upphandlingarna såg man att det var intressant för beställaren hur data kan prepareras och struktureras för att kunna överföras till ett mottagande system som ställer krav på dataformat och datamodell för överföring från IoT-plattformen. Det var så man använde detta krav.

Mer info och exempel på upphandlingskrav.

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

Förtydligande av kravet:

• Uppdatering (tex uppdatering mjukvara, tex firmware)

• Konfiguration (tex hur ofta sensorn levererar värden)

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:

• hur lösningen stöder automatisk uppdatering och konfiguration av större grupper av eller enskilda IoT-enheter.

• hur uppdatering och konfiguration kan göras samlat på ett eller få gränssnitt (GUI eller funktion/API) inom IoT-systemet.

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

• hur uppdatering och konfiguration kan göras utan att fysiskt besöka IoT-enheten (tex OTA Over-The-Air). Titta även efter möjlighet att INTE ändra uppdatering och konfiguration OTA, om informationssäkerhetskraven är sådana.

• hur konfigurationer av IoT-enheter behålls vid uppdatering.

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

Detta upplevde Jkp och VGR som ett bra krav. I upphandlingarna ställdes dock i stället krav på ATT IoT-plattformen ska stödja detta.

Mer info och exempel på upphandlingskrav.

Leverantör bör beskriva hur IoT-systemet kan provisionera och deaktivera fysiska IoT-enheter.

Förtydligande:

• Provisionering - processen för hur en fysisk IoT-enhet sätts upp i IoT-systemet.

• Deaktivering (tex sluta lyssna på IoT-enheten eller ta bort virtuella IoT-enheten från IoT-systemet).

Utvärdera utifrån:

• leverantörens beskrivning av hur en eller flera fysiska IoT-enheter kan provisioneras eller deaktiveras, tex när hundratals sensorer ska inkluderas i IoT-systemet.

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

• möjligheter till batch hantering av fysiska IoT-enheter.

• möjligheten till aktivering eller deaktivering i hela kedjan, tex i både IoT-plattform och i nätverksoperatörs system.

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

Detta krav vände man på i upphandlingarna och ställde i stället krav på att detta ska kunna göras.

Mer info och exempel på upphandlingskrav.

Leverantör bör beskriva hur en fysisk IoT-enhet kan bytas men fortsatt kopplas till samma virtuella IoT-enhet.

Det är vanligt att en fysisk IoT-enhet av någon anledning behöver bytas ut. Den kanske blir förstörd eller skadad, slutar fungera så den skickar inga eller felaktiga värden, ett batteri som inte kan bytas laddar ur etc. Då behöver förvaltningen kunna ersätta den fysiska IoT-enheten men att tillämpningar utan ändring kan fortsätta interagera med den och data/tjänster ifrån den.

Exempel:

• En termometer (fysisk IoT-enhet) på bryggan vid badplatsen Solstranden behöver bytas mot en ny termometer av en annan modernare modell. I IoT-systemet kan administratören koppla den nya IoT-enheten med alla data och tjänster till virtuella IoT-enheten för badplatsen Solstranden.

Utvärdera utifrån:

• leverantörens beskrivning av vilka lösningsmönster finns, för att utföra detta på olika sätt.

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”

Detta krav vände man på i upphandlingarna och ställde i stället krav på att detta ska kunna göras.

Mer info och exempel på upphandlingskrav.

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.

Exempel:

• Enheten har ett unikt virtuellt ID, och ett unikt fysiskt ID då det möjliggör byte av den fysiska IoT-enheten utan att ändra på den virtuella IoT-enhetens unika ID.

Utvärdera utifrån:

• leverantörens beskrivning av vilka lösningsmönster finns, för att utföra detta på olika sätt.

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”

Detta krav vände man på i upphandlingarna och ställde i stället krav på att detta ska kunna göras.

Mer info.

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:

• hur förteckning över fysiska IoT-enheter uppdateras automatiskt

• vilken information som en förteckning innehåller. Tex konfigurationsdata, identifierare (namn/nummer), fabrikat, modell, kapabiliteter, strömförsörjning, IP eller annan klassning, vilken avkodare ska användas, vilken konnektivitet den använder.

• om enhetsinformationen i IoT-systemet är åtkomligt via ett GUI och även via API:er.

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

Detta krav tillhör grundfunktionalitet i ett IoT-system, som Jkp och VGR uppfattade det, och är därför viktigt och obligatoriskt. I upphandlingarna användes kravet i princip som det står fast lite mer utvecklat och uppdelat på flera krav.

Mer info och exempel på upphandlingskrav.

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:

• Beställaren bör beskriva i upphandlingsunderlag hur förvaltning av fysiska IoT-enheter görs inom beställarens organisation och utvärdera hur väl leverantörens beskrivning uppfyller den.

Princip 7 “IoT-systemet klarar att hantera fysiska IoT-enheter och deras koppling till IoT-systemet”

Jkp och VGR upplevde behörigheter i ett IoT-system som synnerligen viktiga. I upphandlingarna ställde man därför betydligt starkare krav på behörighetsstruktur och behörigheter.

Vi ställde inga krav på förvaltningsorganisation gentemot leverantören eftersom vi uppfatta detta som en fråga vi ansvarar för på beställarsidan.

Mer info och exempel på upphandlingskrav.

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.

Exempel:

• Enheten ska kunna meddela sin batteristatus

• IoT-systemet (mjukvara) ska ha möjlighet att förstå när avvikande värden överförs (t ex ett temperaturvärde på -250c kan indikera att en enhet har gått sönder)

  • Notera att detta är en mjukvarufråga och bör kravställas som en möjlighet i mjukvara och nödvändigtvis inte bör vara ett krav på den fysiska enheten att förstå och larma om.

Hur kan det utvärderas:

• Hur väl leverantörens lösning passar med befintlig infrastruktur, tex integrationer mot verksamhetssystem med larmfunktionalitet.

• Hur resultat av övervakning kan visualiseras för användare, tex diagram, kartor.

Princip 7 “IoT-systemet klarar att hantera fysiska IoT-enheter och deras koppling till IoT-systemet”

Detta ansåg JKPJkp och VGR som viktigt. I upphandlingarna i Jkp och VGR ställdes en större mängd och mycket mer detaljerade krav.

Mer info och exempel på upphandlingskrav.

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:

• Tex LoraWan, NB-IoT, Wifi, 4G, 5G, 6G, etc.

Exempel:

• IoT-plattformen ska ha stöd för LoRaWan, NB-IoT, Wifi, Bluetooth, 4g etc

• Den fysiska enheten ska ha stöd för LoRa (användning i område där täckning finns i form av GW)
  eller stöd för NB-IoT som alternativ (i område där täckning ej finns på LoRa-nätet, men det finns mobilmaster med täckning)

  • Typiskt användningsfall: LoRa-täckning finns på fastlandet

  • LoRa-täckning saknas ute på en ö

Utvärdera utifrån:

• vilka konnektivitetstekniker enskilt eller samtidigt kan användas för anslutning till IoT-systemet.

• vilka konnektivitetstekniker som ingår i leverantörens lösning och vilka som är tillval eller kräver egen anpassningar.

• hur komplett beskrivningen är kring process för anslutning av ytterligare konnektivitetstekniker.

• möjligheter för både IPv4 och IPv6 för kommunikation på nätverkslagret och med likvärdig funktionalitet.

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”

Kommunikation och förbindelserna mellan sensorer och plattformar uppfattades av Jkp och VGR som centralt i ett IoT-system. I stället för att be leverantören beskriva vad de kan ställdes dock i upphandlingarna krav på de kommunikationstekniker man önskade stöd för. Sedan fick leverantörerna merpoäng för de konnektivitets-tekniker de kunde erbjuda.

Man frågade också hur Leverantören kommer hantera nya tekniker och standarder.

Mer info.

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.

• Leverantör lämnar ifrån sig lösningsförslag baserat på tänkta tillämpningar.

Utvärdera utifrån:

• hur väl leverantör beskriver hur de fysikaliska förutsättningar/begränsningar som gäller för konnektivitetstekniken.

• det lösningsförslag som leverantören tar fram utifrån en beskrivning av de tänkta tillämpningarna, som beställaren bifogar.

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.”

Jkp och VGR användes i princip kravet som det står.

Mer info och exempel på upphandlingskrav.

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:

• hur starka utfästelser leverantören gör kring när nya releaser eller funktionalitet kommer till IoT-systemet, samt på vilket sätt dessa tillgängliggörs för beställaren.

• hur komplett leverantören beskriver alla ingående moduler i IoT-systemet, hur dessa utvecklas eller avvecklas.

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

Detta krav kanske tillhör mer HUR i StratPAK

Livscykelhantering är viktig men uppfattades i Jkp och VGR som leverantörens ansvar och inte något som tillförde värde för beställaren. Beställaren förväntade sig att IoT-plattformen skulle fungera så länge avtalet var giltigt och planerade att upphandla nya plattformar när systemen inte längre fyllde sin funktion.

Som Jkp och VGR såg det kan kravet variera beroende på om det gäller ett generellt IoT-system eller en specifik tillämpning.

Mer info.

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ö)

• Hur väl beskrivningen uppfyller PRINCIP 3: IoT-systemets informationsmodeller bygger på standarder i horisontell övergripande nivå och specifika vertikala nivåer.

• Vilka informationsmodeller virtuella enheter kan anta, tex egna eller standardiserade.

• I vilken grad kan samma IoT-system hantera flera samtidiga informationsmodeller?

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”

Rent generellt upplevde upphandlingsgrupperna i Jkp och VGR att det inte fanns någon direkt poäng med att ställa krav på datamodell och informationsmodell för de plattformar som skulle upphandlas. Man förväntade sig i stället att leverantören har ändamålsenlig informations- och datamodell för den funktionalitet de offererar.

För en utvecklare konstaterade man att detta dock kan viktigt men samtidigt kanske också ganska självklart.

Mer info.

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:

• internet tjänster, tex väderinformation från SMHI

• framräknade värden från flera olika fysiska eller virtuella IoT-enheter. Tex en virtuell IoT-enhet kan leverera medelvärde för flera temperatursensorer.

• andra system, tex SCADA system eller EDGE enheter.

Utvärdera utifrån:

• Hur komplett är leverantörens beskrivning av möjligheterna att skapa simulerade virtuella IoT-enheter.

• Hur väl lösningsmönstret passar in i beställarens helhetslösning.

Princip 8 “IoT-systemet klarar att hantera virtuella IoT-enheter och deras länkning till fysiska enheter”

Virtuella sensorer upplevde Jkp och VGS som viktiga i ett IoT-system. Man såg dock att det finns en rad olika användningsområden för virtuella sensorer, inte bara simulering. I upphandlingarna ställdes fler och mer detaljerade krav kring användningen av virtuella sensorer.

Mer info.

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:

• Hur komplett och visuellt gränssnittet för administration är.

• Möjligheten att se vilka tillämpningar som använder en virtuell IoT-enhet.

Princip 8 “IoT-systemet klarar att hantera virtuella IoT-enheter och deras länkning till fysiska enheter”

Jkp och VGR använde detta krav men vände på det och ställde i stället krav på att man skulle kunna göra detta. Man ställde också lite mer detaljerade krav.

Mer info.

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:

• Hur komplett är leverantörens beskrivning av möjligheterna är och hur användbar den är.

Princip 8 “IoT-systemet klarar att hantera virtuella IoT-enheter och deras länkning till fysiska enheter”

Man ställde i stället krav på att detta skulle gå att göra.

Mer info.

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 komplett beskrivningen är.

• hur starka åtaganden leverantören gör kring vad som ingår under avtalstiden

HUR KRAV → StratPAK

Som Jkp och VGR uppfattade det är det viktigt att slå fast vad som ingår i förvaltningen. Dock konstaterade Jkp och VGR att det kanske inte är leverantören som ska beskriva vad de ”har lust” att leverera. I stället kan man vilja beskriva vad man som beställare behöver och förväntar sig. Så gjorde man därför i upphandlingarna. Rent praktiskt gjordes det genom förslag till avtal som täckte det man behövde.

Mer info.

Leverantören bör beskriva hur styrning och orkestrering kan konfigureras, övervakas och modifieras.

Utvärdera utifrån:

• Hur komplett beskrivningen är.

• Hur informationsflöden kan övervakas.

• Hur god överblick verktygen ger

• Hur flexibel lösningen är för att ändra styrning och orkestrering, tex schedulering och skriptning.

• Möjligheter till avvikelser och anomali-detektering i datatrafik.

• Förmåga att kunna prioritera inkommande meddelanden efter konfigurerad prioriteringsordning.

• Möjlighet att styra meddelanden beroende på datainnehåll, det vill säga innehållet i meddelandet, enhetsinformation, informationsklassning och andra kategorier.

• möjlighet för funktionalitet att kunna skapa en spårbarhet (verifieringskedja) av hur ett meddelande har beabetats i IoT-systemet.

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

Se beskrivningarna för KIot-004. Detta är i stor utsträckning samma krav.

Mer info.

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:

• Hur komplett beskrivningen är

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

Se beskrivningarna under krav KIoT-023.

Mer info och exempel på upphandlingskrav.

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.

Förtydligande:

Det är inte nödvändigt att detta kan göras i en central IoT-plattform, utan det kan lika väl göras i extern programvara, t ex olika typer av verksamhetssystem, GIS-programvara eller BI-verktyg.

En offentlig verksamhets behov från centralt håll kan begränsa sig till att endast vara en central punkt för datalagring och för att slussa inkommande data.

Utvärdera utifrån:

• Möjliga typer av diagram.

• Möjlihet att visa data på kartor, både geografiska och logiska kartor (deployment diagrams).

• vilka datakällor inom och utanför IoT-systemet kan anslutas till visualiseringsverktyget.

• hur konsumenter kan använda visualiseringar, tex inbäddning i verksamhetssystem

• möjligheter att övervaka och prognostisera användandet av IoT-ssytemet i form av det totala dataflödet och per API med tillhörande svarstid. Detta för att kunna utföra kostnadsprognoser samt övervaka tillgänglighet.

• ge en översikt över lagrade data i IoT-systemet uppdelat på informationskategorier eller andra parametrar.

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”

Jkp och VGR ansåg att visualiseringen av data från IoT-enheter är centrala i ett IoT-system. Detta såg man dock att kunde göras på väldigt många olika sätt. I Jkp- och VGR-upphandlingarna ställde man därför väldigt många fler och betydligt mer detaljerade krav.

Mer info.

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:

• Möjligheten att i efterhand hämta in data som samlats in av sensorer då det insamlande IoT-systemet varit ur drift.

• Möjlighet att köa inkommande data så att inga data tappas även om det insamlade IoT-systemet inte förmår bearbeta data i den takt data kommer in.

• Möjlighet att sätta prioritet på vilka data som ska behandlas i vilken prioritetsordning vid hög belastning – FINNS i KIOT-041

• Möjligheten att kontrollera att inga data tappats

• Möjligheten att verifiera att data blivit korrupt

• Att det finns en tydlig beskrivning av hur leverantörens lösning löser dataloss problematiken

• Hur väl leverantören beskriver hur IoT-systemet kan verifiera att den mottagit alla av IoT-enheten skickade meddelanden

• Hur väl leverantören beskriver vilka metoder finns för att säkerställa att tillämpningar får tillgång till och information om insamlade data, tex datafusion, redundanta IoT-enheter, sekvensiering av meddelanden, ack-nack verifierat mottagande, omsändning, etc.

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”

Säkerhet och tillförlitlighet är viktiga krav enligt Jkp och VGR. I Jönköpings och Västra Götalands upphandlingar ställdes många detaljerade frågor om säkerhet. Detta krav har lagts till på senare tid i RefARK men hade varit nyttigt i VGR-upphandlingen, där man sannolikt då kunde ha krävt att sensorsdata ska komma fram komplett och oförvanskad.

Mer info och exempel på upphandlingskrav.

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:

• Hur kan datamängder från IoT-enheter minimeras

• Hur kan det konfigureras hur/när/vad som skickas ifrån IoT-enheter

• Hur kan data från olika typer av IoT-enheter prioriteras i hela kedjan från IoT-enhet till tillämpning

• Hur kan Quality of Service definieras och implementeras

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”

Jkp och VGR såg det som värdefullt att kunna minimera datatrafiken och till exempel slippa redundant data. Detta, såg man, kan ske på en rad olika sätt.

Detta krav har tillkommit relativt sent i RefARK. Från VGR sida konstaterar man att man snnolikt hade haft nytta av att ha med detta krav i VGR-upphandlingen.

Mer info och exempel på upphandlingskrav.

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”

För att säkerställa skalbarhet för IoT över tid, såg Jkp och VGR det som viktigt att definiera specifika skalningsscenarier som leverantörer kan prissätta. I Jönköpings upphandling krävdes ursprungligen kostnadsfri skalning, men efter leverantörernas feedback, under en av upphandlingens remissvändor till leverantörerna, ändrades detta till prissättning av olika volymsteg.

Efter en marknadsdialog som VGR-projektet genomförde i januari 2024 i samverkan med RISE Smart City Lab och IoT Sverige, diskuterades en ny prissättningsmodell för VGR. Denna skiljde sig något från Jönköpingsmodellen.

Mer info.