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 https://brickschema.org/.

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 https://semver.org/

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 https://www.enisa.europa.eu/publications/iot-security-standards-gap-analysis

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.