Innehållsförteckning

Vägledning till att förstå och använda RefARK

Inledning och syfte

RefARK är ett omfattande material med många guldkorn som, rätt använt, kan vara till mycket stor nytta för den som vill upphandla, utveckla eller använda IoT inom kommunal och regional verksamhet. Samtidigt finns det, som vi upplevde det från Jönköpings läns och Västra Götalands läns upphandlingar, delar i nuvarande RefARK som kan behöva utvecklas ytterligare eller korrigeras för att vara användbara fullt ut. Detta kan göra det svårt att i dagsläget dra full nytta av RefARK.

Detta avsnitt, “Vägledning till att förstå och använda RefARK” kan ses som ett komplement till övriga beskrivningar av materialet och syftar till att öka förståelsen för RefARK samt göra det enklare för dig som vill använda RefARK. Förhoppningsvis kan det även göra det lättare att hitta det som är mest relevant för dig och er i materialet.

Vi försöker här från VGR:s och Jkp:s sida:

1. Återkoppla erfarenheter av hur respektive princip och krav fungerade när vi använt delar av RefARK som underlag i upphandlingar av IoT-plattformar i IoT-projekt i Jönköpings län och i Västra Götalands län.

2. Beskriva saker man som användare av RefARK kan tänka på för att undvika svårigheter/utmaningar men ändå dra nytta av RefARK i nuvarande version.

3. Indikera vem vi upplevde kan tänkas ha mest nytta av en viss princip eller krav.

4. Ge konkreta exempel på hur krav formulerats i den senast IoT-upphandlingen för Västtra Götalands län, där närmare 50 kommuner, 80 bolag och kommunalförbund samt Region Västra Götaland deltog.

Då Jönköpingsprojektet även bidrog med representant som så kallad utförare i arbetet med RefARK 1.3 refererar vi även i vissa fall till hur själva RefARK-arbetet och processen med framtagningen upplevdes ur Jönköpings-projektets perspektiv.

”OBS! I erfarenhetsbeskrivningen nedan refereras huvudsakligen till Principerna / Kraven som de såg ut i RefARK 1.3 eftersom det var dessa som användes i Jkp och VGR. Formuleringarna för en del principer och krav har ändrats nu i RefARK 2.0.”

Något om bakgrunden till Refark – för ökad förståelse

För att kunna dra maximal nytta av RefARK kan det, till att börja med, vara värdefullt att förstå lite mer hur RefARK kommit till. För oss i upphandlingarna i Jkp och VR bidrog detta till skapa en god förståelse för varför materialet ser ut som det gör i dagsläget.

Stora delar av RefARK har utvecklats av representanter för kommuner och regioner vid en tidpunkt då IoT fortfarande var väldigt mycket i sin linda. IoT-området är dock under stark utveckling och vi såg det därför, som användare av RefARK, som mycket viktigt att jämföra materialet med våra egna erfarenheter och kunskap.

Man bör också ha respekt och förståelse för att RefARK-arbetet fick bedrivas med de resurser som fanns till förfogande och med de personer som hade tid och möjlighet att engagera sig. Tidvis deltog relativt få personer. Flera av arbetsmötena i det tidiga RefARK-arbetet genomfördes med endast projektledaren + ytterligare EN person närvarande även om det varierade vem den personen var. Det innebär att vissa delar av materialet i RefARK 1.3 producerats i princip av huvudsakligen 1–2 personer. Detta kan jämföras med till exempel upphandlingen i Jönköping där cirka 7–8 personer deltog kontinuerligt under flera månader vid framtagningen av upphandlingsunderlaget samt i VGR där cirka 10–12 personer medverkade under ungefär ett halvår.

Efter framtagningen har RefARK-materialet inte granskats på något strukturerat sätt i RefARK-projektets regi förrän sommaren 2024. Sannolikt hade materialet vunnit på att ha granskats tidigare. Man kan som en jämförelse notera att i arbetet kring ISO/IEC 30141, den internationella referensarkitekturen för IoT, skickas varje version av arbetsdokumentet ut till de nationella kommittéerna i hela världen. Dessa består sammantaget av uppskattningsvis c:a 460 experter som granskar hela innehållet både tekniskt och språkligt.

I RefARK-arbetet lutade vi oss också mot material vi hittade på annat håll. Samtidigt hade vi inte tid och möjlighet att kvalificera om och i så fall hur ”up to date” dvs fortlöpande underhållna sådana andra dokument, standarder, vägledningar med mera var och hur väl spridda och utnyttjade dessa var och är idag i praktiken.

Med visst facit i hand är det en hel del av det vi tänkte kring RefARK som stämmer väl med hur utvecklingen inom IoT-området fortskridit. I flera avseenden hade RefARK-gruppen som helhet ganska god pejl på vad framtiden bar med sig. En del har dock utvecklats i andra riktningar eller på andra sätt. Ytterligare delar kanske vi helt enkelt inte förstod tillräckligt eller tänkte fel kring redan från början.

Allmänt om användningen av RefARK i upphandlingarna i Jkp och VGR

För ytterligare förståelse av var RefARK-materialet befann sig rent utvecklingsmässigt i sin första version (1.3) kan det vara värdefullt med statistik från användningen i två upphandlingar som utnyttjat material från RefARK 1.3. Sedan RefARK 1.3 (som användes i upphandlingarna) har ytterligare material tillförts RefARK samtidigt som ursprungsmaterialet till stora delar är oförändrat även om vissa ändringar och förbättringar genomförts men anledning av extern granskning av RefARK sommaren 2024.

Jönköpings län

RefARK var ett värdefullt bidrag till upphandlingsunderlaget när Jönköpings län skulle upphandla dels IoT-plattform för ett 2-årigt pilotprojekt, dels upphandling av långsiktig IoT-plattform (med möjligt kontrakt upp till 10 år) för 13 kommuner, c:a 50 bolag och kommunalförbund samt Region Jönköpings län.

Av de c:a 500 kraven i den senare, långsiktiga upphandlingen var c:a 10% av kraven baserade på material från RefARK.

När det gäller de 44 kraven i RefARK så kunde vi använda dem så här:

• 16 krav kunde vi använda i sin helhet som de är formulerade i RefARK

• 2 krav kunde vi använda delvis som de är formulerade i RefARK

• 15 krav kunde vi använda genom att skriva om eller vända på frågeställningen från RefARK. När till exempel RefARK anger att man ska be leverantören beskriva en frågeställning och sedan utvärdera på olika saker så vände vi på detta. Vi ställde i stället specifika krav på förekomsten av det som RefARK föreslår skulle utvärderas. Se konkreta exempel nedan.

• 11 av kraven kunde vi inte använda. Framför allt för att dessa var skrivna för annat syfte än upphandling eller för att kravet var felaktigt, svårtolkat eller på en för hög och abstrakt nivå för att vara användbart.

Västra Götalands län

Upphandlingsmaterialet från Jönköping återanvändes i en upphandling av en IoT-plattform i Västra Götaland under 2024 där närmare 50 kommuner, 80 bolag och kommunalförbund samt Västra Götalandsregionen deltagog. Även denna upphandling gällde en generell horisontell IoT-plattform med möjlig kontraktstid på upp till 10 år.

I denna upphandling ökade antalet krav till c:a 750 krav. RefARK 1.4 granskades ingående av projektgruppen under hösten 2023 för att se om materialet kunde tillföra något ytterligare. Projektgruppen kunde konstatera att så inte var fallet. Slutsatsen är att vi i Jönköpingsprojektet hade lyckats extrahera det som var användbart i RefARK för upphandlingssyfte och att inget tillförts RefARK som föranledde ändringar eller nya krav i upphandlingen i Västra Götaland.

Detta innebär att c:a 7% av kraven i upphandlingsmaterialet i VGR-upphandlingen är relaterade till materialet i RefARK.  

Några allmänna slutsatser

Efter användningen av RefARK i ovanstående upphandlingar kan man dra några generella slutsatser:

a. Det finns mycket som är bra och användbart i RefARK.

b. Det finns material som kommer vinna på att vidareutvecklas.

c. RefARK täcker flera aspekter som man behöver tänka på i kommun och region kring IoT men är dock inte ett heltäckande material.

Detta gör att det krävs förhållandevis mycket arbete för att hitta och välja ut det man kan och bör använda från RefARK. Utmaningen här är att RefARK är tänkt kunna användas av och vara till hjälp för den som inte har tillräcklig egen kunskap kring IoT. Samtidigt är det svårt för en person att kunna bedöma vilka delar av RefARK som är användbara. Är man tillräckligt kunnig för att avgöra detta så behöver man kanske inte RefARK.

Förhoppningen är att erfarenheter nedan från användningen i Jönköpings län och Västra Götalands län kan underlätta och ge vägledning.       

Erfarenheterna avser ETT av flera möjliga användningsområden för RefARK

När man läser detta material och erfarenheterna från projekten i Jönköping och Västra Götaland bör man ha i åtanke att erfarenheterna från dessa IoT-satsningar handlat om att använda RefARK för upphandling av en horisontell generell IoT-plattform. RefARK kan användas för flera andra ändamål, till exempel upphandling av andra typer av IoT-system för specifika tillämpningar. Då kan kraven i någon mån uppfattas eller användas på annat sätt än i Jkp och VGR.

Likaså är flera av kraven i RefARK mer lämpade för någon som vill utveckla ett IoT-system än för den som vill upphandla. I beskrivningarna av erfarenheterna från Jönköping och Västra Götaland har vi försökt indikera vilken typ av användare som har nytta av respektive krav.

Erfarenheter av principer i RefARK - utökat material

I högra kolumnen i principkatalogen för RefARK finns kortfattande beskrivningar av erferenheter från Jönköpings län och Västra Götalands län. Nedan finns mer material och mer utförliga beskrivningar samt exempel på upphandlingskrav i Västra Götalands upphandling av långsiktig länsgemensam IoT-plattform.

Princip IoT-1

IoT-Systemet möjliggör för byte av moduler oberoende av varandra

Kortnamn: Modularitet

Erfarenheter från JKP och VGR för Princip IoT-1

Denna princip är lite av ett skolboksexempel i nuläget men svår att tillämpa i praktiken.

Grundidén i principen är mycket god. Självklart vill vi att alla system blir uppbyggda så här. I praktiken och som IoT-världen ser ut idag är det dock i princip omöjligt att följa denna princip varken i upphandling eller utveckling. De flesta befintliga IoT-leverantörer har inte byggt sina system så här, framför allt för att det inte finns några standarder att utgå från för att skapa sådan modularitet och utbytbarhet. Även om några leverantörer försökt bygga system med detta i åtanke finns det för få andra leverantörer som gjort på samma sätt för att det i dagsläget ska ge önskad nytta i praktiken.

Det saknas också en enhetlig beskrivning överenskommen på lokal eller internationell nivå för hur uppdelningen i olika moduler skulle kunna se ut och hur gränssnittet dem emellan skulle utformas. Även om det finns kommunikationsprotokoll och API:er som bidrar till viss standardisering, är vi ändå långt ifrån en beskrivning av hur en modularitet för utbytbarhet skulle kunna se ut och skapas.

Dock finns det inspiration att hämta, till exempel inom öppna källkods-communities för IoT. I en sådan grupp kan man enas om vilka moduler som ska finnas och hur de ska vara uppbyggda och inom gruppen skapa utbytbarhet. Nyttan blir visserligen begränsad men är ändå ett steg i rätt riktning. I en upphandling är man dock tyvärr inte särskilt behjälpt av modularitet inom en begränsad krets av leverantörer och aktörer.

Ovanstående gjorde att vi vare sig i Jkp eller VGR såg möjlighet att använda princip IoT-1 eller ställa krav på att modulerna i upphandlat IoT-system skulle vara helt utbytbara. Det vi gjorde istället var dels att ge merpoäng för ett bör-krav kring ”utbytbarhet”, dels krävde vi att leverantören skulle beskriva hur systemet var uppbyggt med tydligt avgränsade moduler samt beskriva varje modul på ett för beställaren tydligt sätt. Detta för att ändå premiera ett modulärt systemtänk.

Inte heller för en systemutvecklare blir denna princip riktigt meningsfull eftersom det saknas enhetliga standarder som en utvecklare kan luta sig mot för att bygga utbytbara moduler i sitt IoT-system. Principen kan dock ändå tjäna som vägledning för utvecklare för att markera att detta är viktigt även om det nog inte är någon utvecklare idag som inte strävar efter att bygga sina IT-system modulära så långt som möjligt.

Angående beskrivningen under implikationer så behöver principen INTE innebära att det blir en ansvarsförflyttning i riktning mot beställaren. I en upphandling kan man ställa krav på leverantören i anslutning till idéerna i denna princip, som man kan utvärdera och poängsätta.

Det kan krävas mer arbete för att uppnå intentionen i principen i och med att befintliga verksamhetssystem inte är medvetna om eller förberedda för data, information och tjänster från IoT-system. Det är därför viktigt att beställaren beaktar detta i sin design.

De principer (utanför RefARK) som nämns under ”Motivering” är, som vi bedömt det, mest intressanta för dem som är bekanta med dessa principer och önskar följa dessa.

För vem

Detta är en värdefull grundidé för både upphandlare och utvecklare även om kravet inte är möjligt att uppfylla i dagsläget. Man kan till exempel hämta idéer från ”Utvärdera till exempel utifrån” för att utveckla egna krav.

Förslag till vidare utveckling av Princip IoT-1

Till att börja med kan det kanske vara vettigt att omformulera principen till att i stället lyda något i stil med: ”För IoT-system bör man eftersträva en systemuppbyggnad och standardiserade gränssnitt som, så långt det är möjligt, underlättar för byte av systemmoduler i IoT-systemet oberoende av varandra”.

I en vidare utveckling av RefARK kan RefARK också sannolikt bidra till att komma närmare en lösning på detta problem, som i princip alla IoT-leverantörer i världen mer eller mindre brottas med. Även om det inte går att åstadkomma ideal modularitet fullt ut kan flera saker göras för att driva utvecklingen åt rätt håll. Till exempel kan det vara värdefullt att:

1. Detektera olika typer av moduler som ett IoT-system kan bestå av.

2. Beskriva och förstå dessa modulers beroenden till varandra

3. Undersöka vilka tekniker och vilka standarder som kan utnyttjas för de olika gränssnitten mellan de olika modulerna

4. Skapa krav i RefARK på olika beståndsdelar som kan bidra till och öka möjligheten för att på sikt hitta enighet och standarder för uppdelning i moduler och gränssnitten mellan dessa.

5. Utveckla kravlistan från punkt 4. till att även gälla för olika typer av IoT-system, beroende på vad det specifika IoT-systemet har för syfte (kan skilja stort i behov av moduler beroende på om exempelvis ett IoT-system enbart ska hantera en IoT-tillämpning med hög krav på säkerhet, eller om ett IoT-system ska hantera många IoT-tillämpningar med låg säkerhet).

Exempel på korresponderande krav i VGR-upphandlingen

Utbytbarhet – Composability

Krav tillhör kravområde 1. IoT-plattformen generellt.

Detta krav är hämtat från ISO/IEC 30141 – Internationella referensarkitekturen för IoT

Utbytbarhet ställer strängare krav än Interoperabilitet, eftersom det kräver moduler som inte bara är kompatibla i sina gränssnitt, utan är utbytbara med andra moduler av samma slag. Utbyte kan till exempel innebära byte till en nyare/bättre modul som då behöver ha åtminstone liknande konstruktion som den ursprungliga modulen men förbättrade egenskaper, till exempel prestanda, skalbarhet och/eller säkerhet.

När en modul ersätts med en annan av samma slag som är kompatibel, bör systemets övergripande funktioner och egenskaper ha utformats för att stödja sådant utbyte.

Utbytbarhet innebär även att IoT-plattformen bör stödja möjligheten att byta ut och uppgradera IoT-enheter som anslutits till IoT-plattformen. Detta kommer sannolikt att vara viktigt i takt med att efterfrågan på IoT-enheter ökar och kan överskrida olika leverantörers produktions- och leveranskapacitet.

För mervärde lämnas en kortfattad skriftlig redogörelse som kommer att bedömas utifrån följande kriterier:

1. Leverantörens beskrivning av hur IoT-plattformen är uppbyggd och strukturerad med avseende på utbytbarhet (Composability). Det vill säga hur systemintegration och interoperabilitet för de funktionella modulerna är uppbyggda för att bilda ett komplett IoT- system och hur denna uppbyggnad kan stötta utbytbarhet av enskilda delar i systemet.

2. Vilket stöd det finns för och hur enkelt det går att byta ut en IoT-enhet som anslutits till IoT- plattformen till en ny IoT-enhet med motsvarande eller alternativt utökad eller förbättrad funktionalitet.

3. Hur all annan tillhörande data i IoT-plattformen, till exempel regler, metadata etcetera kan bevaras vid sådant utbyte.

Beställarens definition av modularitet:

• Modularitet är en egenskap hos komponenter som kan kombineras för att bilda större system av komponenter. Modulära komponenter kan tas bort rent från ett system och ersättas med en modul av liknande storlek och med liknande fysiska och logiska gränssnitt.

• Modularitet gör att komponenter kan kombineras i olika konfigurationer för att bilda system efter behov. Genom att fokusera på standardiserade gränssnitt och inte specificera de interna funktionerna för varje komponent, har implementationer flexibilitet i utformningen av komponenter och IoT-system.

• Modulariteten för ett IoT-system skiljer sig inte från den önskade modulariteten för andra IT-system. Dock anser Beställaren att det i en snabbväxande teknologi som inom IoT-området är ännu viktigare att kontinuerligt kunna uppgradera separata delar av IoT-systemet.

OBS! Det är tillåtet för leverantören att tillhandhålla moduler från tredje part som logiskt hänger samman i den sammantagna IoT-plattformen. Moduler behöver således inte vara kompilerade till en gemensam exekverbar modul utan kan utgöras av flera fristående programvaror

Krav på systembeskrivning:

Krav tillhör kravområde 1. IoT-plattformen generellt.

Leverantören ska beskriva systemarkitekturen för offererad IoT-plattform. Av beskrivningen skall framgå samtliga utvecklingsmiljöer, ramverk och tekniker plattformen är baserad på och följer samt systemarkitektur för plattformen inklusive utvecklingsmiljö och programvarukomponenter. Till det ska det beskrivas hur systemet är uppbyggt i olika moduler och respektive moduls funktion.

Leverantören ska lämna en kortfattad skriftlig redogörelse och kommer att bedömas utifrån följande kriterier:

• Hur väl Leverantören har beskrivit uppbyggnaden av systemarkitekturen.

• Hur väl denna beskrivning motsvarar de Deltagande organisationernas behov.

• Hur väl uppdelad IoT-plattformen är i tydliga och funktionsmässigt väl avgränsade moduler.

• Om offererad IoT-plattform är byggd för en struktur med System av system eller om det finns planer för att stödja en sådan struktur dvs där flera instanser av IoT-plattformen kan utgöra undersystem till en övergripande instans av IoT-plattformen.

Princip IoT-2

Data, information och kontextmedvetenhet (Context- awareness) i IoT-systemet bevaras vid modul- och systembyten

Kortnamn: Kontextmedvetenhet

Erfarenheter från JKP och VGR för Princip IoT-2

Denna princip täcker flera olika aspekter:

1. Vikten av att berika sensordata med metadata, så kallad kontextdata.

2. Vikten av att äga data själv

3. Vikten av att bevara alla data vid systembyte

4. Vikten av att kunna exportera data.

5. Det är dock egentligen lika viktigt att kunna importera data vilket inte täcks av denna princip just nu.

Alla dessa delar i IoT-2 samt importmöjligheter täcktes av en rad olika krav i de båda upphandlingarna. För så kallad kontextdata ställde vi i stället explicita krav på vilken typ av data som sensordata skulle kunna kompletteras med.  

Gällande implikation punkt 3 så visar erfarenheterna från användningen av de IoT-plattformar/system som upphandlats i Jönköping och Västra Götalandsregionen att det inte är enbart beställarens ansvar att säkerställa att sensordata översätts till användbara data. Det är IoT-systemet som tar emot data i en mängd olika format och modeller och därmed IoT-plattformen/systemets jobb att översätta denna data till för en människa läsbara data. Det kan vara mycket svårt för ett IoT-system att veta just vilken människa som ska läsa denna data och hur den därför ska anpassas till just det syfte man vill. Det är en kombination av IoT-systemets roll att översätta den sensordata som kommer in till något läsbart för en människa med användarens ansvar att se till att denna data är anpassad till just det syfte den ska uppfylla.

För vem

Detta är viktiga frågor för såväl utvecklare som upphandlare.

Förslag till vidare utveckling av Princip IoT-2

Lämpligen delar man upp denna princip i 5 principer (om man även inkluderar möjligheterna till import). för att lättare utveckla principerna och knyta krav till dem.

Exempel på korresponderande krav i VGR-upphandlingen

Det finns inget krav som korresponderar direkt mot hur Princip IoT-2 är skriven just nu. Däremot finns det krav som kan relateras till de de 5 aspekterna av denna princip. Dvs de 5 aspekterna listade ovan.

1. Vikten av att kunna berika sensordata med metadata, så kallad kontextdata. Några exempel:

2. Vikten av att äga data själv. Exempel:

3. Vikten av att bevara alla data vid systembyte. Exempel:

2.6.46 Avveckling och överlämning

Krav tillhör kravområde 21. Leverantörsstöd.

Leverantör ska vara behjälplig vid avtalets upphörande och Deltagande organisationers avveckling av leverantörens IoT-plattform samt eventuell överlämning till ny leverantör av IoT-plattform. Leverantören skall då:

• Tillgodose Deltagande organisationers behov av god rådgivning, planering samt ansvarsfull och väl utförd avveckling från Leverantörens sida.

• Hjälpa Deltagande organisationer att på ett kostnadseffektivt sätt migrera såväl sensordata som all metadata i IoT-plattformen till eventuell ny IoT-plattform från annan leverantör.

• Vara Deltagande organisationer behjälplig med frånkoppling och överlämning av IoT-utrustning till ny leverantör.

Leverantören ska lämna en kortfattad skriftlig redogörelse som kommer att bedömas utifrån följande kriterier:

1. Hur väl leverantören beskriver avvecklings- och överlämningsprocessen.

2. Leverantörens tekniska assistans och överlämning av driftdokumentation.

3. Hur leverantören kan vara behjälplig med att planera för och, i förekommande fall, genomföra en migrering av befintliga tillämpningar och data till en ny IoT-plattform.

4. Hur väl utvecklade rutiner och rutinbeskrivningar leverantören har för att säkerställa att all information som VGR lagrat i leverantörens IoT-plattform exporteras på ett sätt som möjliggör senare import i annan IoT-plattform.

5. Hur leverantören under överlämnandefasen kan bidra med sin nyckelkompetens om avtalsföremål till Deltagande organisationer och/eller tredje part (t.ex. ny leverantör av IoT-plattform) i den omfattning som efterfrågas.

6. Vikten av att kunna exportera data. Samt,

7. Vikten av att kunna importera data.

2.6.37 Fullständig import/export

Krav tillhör kravområde 10. Datalager.

Leverantör ska beskriva hur data, information och kontextmedvetenhet på ett fullödigt och detaljerat sätt kan importeras till respektive exporteras ifrån IoT-systemets moduler. Leverantören ska lämna en kortfattad skriftlig redogörelse som kommer att bedömas utifrån följande kriterier:

1. Vilka informationsmodeller och ontologier som data kan exporteras och importeras som.

2. Hur kontextdata, dvs data knutet till sensordata, kan exporteras / importeras.

3. Hur import från Deltagande organisationers befintliga IoT-system kan göras.

4. Hur komplett den informationsmängd är som kan importeras respektive exporteras till/från IoT-systemets moduler.

5. Hur väl leverantören beskriver processen.

6. Hur komplett beskrivningen kring export av data och kontextinformation är.

7. Vilka åtaganden leverantören gör kring detta.

Princip IoT-3

IoT-systemets informationsmodeller byggs på horisontell övergripande nivå och på specifika vertikala nivåer

Kortnamn: Informationsmodeller

Erfarenheter från JKP och VGR för Princip IoT-3

Denna princip kan vara lite svårtolkad för den som inte deltagit i framtagningen av RefARK. Samtidigt pekar principen på en av de stora utmaningarna i den kommunala IoT-världen: när ska man använda en horisontell och generell IoT-plattform men en horisontell datamodell och när ska man upphandla och införa mer stuprörsbetonade applikationer.

Principen lyfter också fram en fråga om vad det är man vill upphandla. Vill man upphandla en generell horisontell IoT-plattform eller vill man upphandla ett antal verksamhetsspecifika lösningar eller både och?

I Jkp och VGR upplevde vi att det svårt att ställa krav relaterat till denna princip. Däremot var det viktigt att förtydliga att de upphandlingarna gällde en generell, horisontell IoT-plattform. Visserligen efterfrågade vi ett antal tillämpningar men dessa syftade dock huvudsakligen till att kunna verifiera leveransen och ha tillgång till indata för acceptanstester och utbildning mm.

Det kan vara värt att notera att en del av beskrivningarna är inte helt korrekta. Uppdelningen i horisontella och vertikala datamodeller säkerställer inte interoperabilitet i sig självt. Definitionerna av Horisontella ontologier och Vertikala ontologier är inte korrekta.

För vem

Detta är ett krav som huvudsakligen kan vara något att beakta för en systemarkitekt eller en utvecklare. I en upphandling är principen förhållandevis svår att tillämpa.

Förslag till vidare utveckling av Princip IoT-3

Man kan antagligen vinna mycket på att till exempel jämföra uppbyggnaden i en generell horisontell IoT-plattform med mer stuprörsbetonade lösningar och vilka krav som kan vara relaterade till respektive typ av IoT-system. Det är dock ändå oklart vad denna princip ska syfta till.

Exempel på korresponderande krav i VGR-upphandlingen

Det som upphandlades var en horisontell generell IoT-plattform. Detta gjordes tydligt i både upphandlingsförfarandet och i kravställningen. Kravställningen säger i flera fall inte exakt hur leverantörerna ska bygga sina lösningar, bara att de ska klara av att göra vissa saker och lämnar lösningen till leverantörerna att göra som de tycker är bäst.

Några exempel på krav för att bygga en horisontell IoT-plattform utöver krav på API:er och integrationsmöjligheter var därmed:

Princip IoT-4

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

Kortnamn: Bearbetning och berikning

Erfarenheter från JKP och VGR för Princip IoT-4

Denna princip beskriver egentligen huvudfunktionerna i ett generellt horisontellt IoT-system. Samtidigt är detta en beskrivning och princip på väldigt hög nivå.

I Jönköping och VGR använde vi inte denna princip i sig själv men ställde en stor mängd mycket mer detaljerade krav som på sätt och vis kan sägas omfattas av denna princip.  

För vem

Principen är en självklarhet för såväl utvecklare som upphandlare. Det behövs dock mer ”kött på benen”.

Förslag till vidare utveckling av Princip IoT-4

Denna princip skulle behöva brytas ner till ett antal mer konkreta principer för olika typer av bearbetningar och berikningar.

Exempel på korresponderande krav i VGR-upphandlingen

Det finns en stor mängd krav i VGR-upphandlingen som relaterar till denna princip. Vissa krav fokuserar specfikt på berikning eller bearbetning.

Gällande bearbetning av information utöver krav på till exempel regelhantering där man också kan bearbeta data, så kravställs följande:

Princip IoT-5

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

Kortnamn Lagring

Erfarenheter från JKP och VGR för Princip IoT-5

Principen är viktig. Det man kanske framför allt behöver fundera på och utgå ifrån är informationsklassificering av informationen som i sin tur ställer krav på hur och var man kan och vill lagra informationen.

I Jkp- och VGR-upphandlingarna ställde vi krav både på hur och var man skulle kunna drifta IoT-plattformarna men också att man skulle kunna lagra och vidareförmedla den insamlade informationen på olika sätt.

Eftersom många organisationer deltog i upphandlingarna i Jönköpings län och Västra Götaland var det också viktigt att varje deltagande organisation skulle kunna drifta IoT-systemet lokalt och även lagra data lokalt i den egna IT-miljön om man så vill.

För vem

Detta är en viktig princip för både upphandlare och utvecklare.

Förslag till vidare utveckling av Princip IoT-5

Denna princip kan utvecklas med fler exempel. Principen tar upp flera av de viktiga aspekter som även använts i upphandlingarna i Jönköping och VGR och som återspeglas hos leverantörernas produkter. Dock skulle man kunna utveckla en del av punkterna samt addera möjligheten till olika typer av serverhantering, dvs drift av leverantör, tredje part eller av beställaren/användaren själv. Man kan då knyta ihop de olika typerna av lagring med behovet att skydda olika data olika mycket beroende på informations-klassificering.

Exempel på korresponderande krav i VGR-upphandlingen

Det fanns ett helt avsnitt med krav gällande datalagring i upphandlingen samt andra krav på att tjänsten ska tillhandahållas antingen genom drift av leverantör, tredje part eller av beställaren/användarorganisationerna själva. Gällande detta fanns både krav som leverantören fick svara på genom att beskriva sina lösningar samt vanliga krav som man kunde svara Ja/nej på.

Nedan följer ett av flera likartade krav på driftmiljö från VGR-upphandlingen samt några exempel av många på krav för datalagring. 

2.6.6 Möjlighet till drift i Deltagande organisationers driftsmiljöer

Krav tillhör kravområde 1: IoT-plattformen generellt

För Deltagande organisationer är det av stort värde att ha en stor flexibilitet kring valet av driftsmiljö. I ett senare skede kan det vara av intresse för Deltagande organisationer att själv ansvara för drift av en egen installation/instans av IoT-plattformen var för sig eller tillsammans, dvs att Leverantören installerar IoT-plattformen i IT-miljö hos en eller flera Deltagande organisationer för de enskilda organisationernas egna bruk. I dessa fall ansvarar Deltagande organisation för driften av IoT-plattformen samt den eller de servrar som IoT-plattformen driftas på.

Vid störningar avseende själva IoT-plattformen har Leverantören även i detta fall ansvar för support och åtgärder. Leverantören ansvarar även för uppgraderingar av IoT-plattformen i den Deltagande organisationens driftmiljö. Vid uppdatering av OS i den Deltagande organisationens driftmiljö ska Deltagande organisation och Leverantören samråda för att säkerställa att uppgradering av OS inte påverkar IoT-plattformens funktionalitet och prestanda. Deltagande organisation ansvarar i detta fall för upprättande av backup-rutiner, redundant drift och liknande.

Leverantören ska ange huruvida det för den offererade IoT-plattformen finns möjlighet till drift i Deltagande organisationers driftsmiljöer.

 Om Leverantören kan erbjuda detta ska Leverantören lämna en kortfattad skriftlig redogörelse som bedöms utifrån följande kriterier:

1. Hur väl Leverantören har beskrivit möjligheten att drifta IoT-plattformen i sin helhet i Deltagande organisationers egna driftmiljöer.

2. Hur väl denna beskrivning motsvarar Deltagande organisationers behov.

3. Att detta kan ske på ett för Deltagande organisationer kostnadseffektivt sätt.

4. Att det tydligt framgår vilka krav detta ställer på Deltagande organisationers driftmiljöer.

Om Leverantören kan erbjuda detta ska priser för detta anges i bilaga 2 Prisbilaga.

OBS! Dessa priser i bilaga 2 Prisbilaga kommer INTE att användas för utvärderingen av anbudet avseende sammantaget pris. Angivna priser för detta krav kommer i stället utgöra en del av utvärderingen av detta krav för erhållande av mervärde.

Fler exempel på krav:

Princip IoT-6

IoT-systemet klarar att möta en definierad risk- och konsekvensnivå [för att uppnå avsedd informationssäkerhet]

Kortnamn: Informationssäkerhet

Erfarenheter från JKP och VGR för Princip IoT-6

Informationssäkerhet är självfallet oerhört viktigt, inte minst för ett IoT-system som har fler attackytor och sårbarheter än många andra system. Vet man redan i förväg exakt vad man ska använda sitt IoT-system till, till exempel om man upphandlar ett IoT-system för en viss specifik tillämpning, så går det också att definiera en risk- och konsekvensnivå. Upphandlar man däremot, som i Jkp och VGR, en generell horisontell IoT-plattform vet man inte i förväg vad den ska användas till och behöver därför ta höjd för möjliga framtida användningsområden.

I Jkp- och VGR-upphandlingen gjordes ett ganska omfattande arbete kring säkerhetsfrågorna som inte ryms i denna beskrivning här i RefARK. En utgångspunkt vad bland annat SKR:s Klassa och Klassa för IoT i kombination med säkerhetskrav från deltagande organisationers IT-avdelningar.

Vi använde oss av flera olika vägledningar för informations- och cybersäkerhet. Dock inte ENISA Baseline Security Recommendations for IoT. Vi kan därför inte uttala oss om ENISA:s rekommendationer.

Det noterades också att denna princip har ett nära samband med Princip IoT-5.

I RefARK 1.3 duckade vi egentligen hela frågeställningen eftersom fleratalet av oss i RefARK-arbetet inte hade tillräckliga kunskaper inom området. Vi hade inte heller tid att fördjupa oss kring detta. Det var ett av skälen att gruppen valde att hänvisa till ENISAS rekommendationer för att i alla fall peka på något som kunde vara användbart.

För vem

Detta är självfallet oerhört viktiga frågor för såväl utvecklare som för upphandlare.

Förslag till vidare utveckling av Princip IoT-06

Hela området kring informations- och cybersäkerhet behöver vidareutvecklas.

Exempel på korresponderande krav i VGR-upphandlingen

I kravmassan fanns flera delar som täckte cyber- och informationssäkerhet. Ett eget avsnitt var taget från SKRs Klassa med nivå 3, vilket är den näst högsta nivån. Den högsta är nivå 4 - Informationstillgångar som är av betydelse för Sveriges säkerhet, vilket är en indikator att informationstillgången omfattas av säkerhetsskyddslagen (2018:585).

Dessa krav anpassades till just denna upphandling då de i grunden är generella och tänkta att inte tas rakt av. Det arbetet gjordes i samarbete med de experter från SKR som tagit fram materialet, samt med experter inom informationssäkerhet från VGR.

Princip IoT-7

IoT-systemet klarar digital hantering av fysiska IoT- enheter och deras koppling till IoT-systemet

Kortnamn: Fysiska IoT-enheter

Erfarenheter från JKP och VGR för Princip IoT-7

Detta är en viktig princip och en viktig egenskap för ett IoT-system. I JKP och VGR utvecklade vi en rad krav relaterade till denna princip.

För vem

Detta är självfallet viktigt för såväl utvecklare som upphandlare.

Förslag till vidare utveckling av Princip IoT-7

Behöver antagligen inte vidareutvecklas.

Exempel på korresponderande krav i VGR-upphandlingen

Några exempel av många:

Princip IoT-8

IoT-systemet klarar att hantera virtuella IoT-enheter

Kortnamn: Virtuella IoT-enheter

Erfarenheter från JKP och VGR för Princip IoT-8

Det är viktigt med virtuella IoT-enheter i ett IoT-system. RefARK:s texter och beskrivningar av ”Simulerade IoT-enheter” är inte korrekta då simulerade IoT-enheter bara är en av flera olika typer av virtuella IoT-enheter man vill att ett IoT-system ska hantera. Se mer info om detta under avsnittet ”Datamodellen” nedan.

För vem

Detta är viktigt för både utvecklar och upphandlare.

Förslag till vidare utveckling av Princip IoT-8

Det kan vara värdefullt att beskriva olika typer av virtuella sensorer som kan förekomma. Eventuellt kan man baka ihop denna princip samt Princip IoT-7 till ”under-principer” under en generell princip som hanterar just IoT-enheter och deras koppling till IoT-systemet.

Exempel på korresponderande krav i VGR-upphandlingen

Princip IoT-9

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

Kortnamn: Orkestrering

Erfarenheter från JKP och VGR för Princip IoT-9

I JGP och VGR hade vi lite svårt att förstå hur denna princip skulle förstås och tillämpas. Vi upplevde principen mer som något en utvecklare behöver ha i åtanke än något som vi som beställare behövde eller kunde ställa krav på.

Dock kan man absolut efterfråga beskrivningar från leverantören kring hur informationsflödena i IoT-systemet ser ut.

Det finns oftast informationsflöden som är inbyggda i ett IoT-system för att systemet ska fungera, och som är optimerade för att det ska fungera så bra som möjligt. Dessa kan för en slutanvändare vara svåra att styra eller orkestrera. Det kan istället eventuellt göras av en administratör eller av leverantören av IoT-systemet. Sedan finns det informationsflöden som är byggda för att kunna styras och orkestreras av en slutanvändare. För att kunna styra dessa informationsflöden i ett IoT-system använder man oftast någon form av regelmotor eller regelhantering. Detta är en av de centrala funktionerna i ett IoT-system och något vi ställde många ganska ingående krav på i samtliga upphandlingar.

Det finns olika uppfattningar om vad man menar med ”händelsedriven”. Uppfattningen i JKP och VGR var att det i ett IoT-system kan finnas informationsflöden som inte är händelsestyrda, till exempel för strömmande data.

För vem

Detta är framför allt viktigt för utvecklare. För upphandlare blir denna princip svårare att ställa krav på.

Förslag till vidare utveckling av Princip IoT-9

Här behöver man nog fundera igenom vad man menar och dela upp denna princip i mer lättförståeliga och tydliga delar. Flera som lämnat synpunkter på RefARK tidigare har påpekat att om man tar bort ordet ”händelsedrivna” så att principen blir mer heltäckande.

Exempel på korresponderande krav i VGR-upphandlingen

Princip IoT-10

IoT-systemets information, tjänster och data är tillgängliga för tillämpningar

Kortnamn: Dela Data

Erfarenheter från JKP och VGR för Princip IoT-10

Denna princip är viktig för ett IoT-system oavsett om vi pratar om en generell horisontell IoT-plattform eller en enskild IoT-tillämpning.

För en generell IoT-plattform är denna princip en självklarhet, eftersom det är en av huvuduppgifterna för en sådan plattform att samla in och tillgängliggöra informationen ihop med diverse tjänster och gränssnitt.  

För en enskild IoT-tillämpning kanske principen inte är lika självklar men trots det är principen lika viktig. I både Sverige och EU går vi alltmer mot att kunna dela data mellan olika aktörer. Det är oerhört viktigt att information och data inte blir inlåsta i stuprörs-system utan kan delas och göras tillgängliga för andra tillämpningar än inom det egna systemet.

I upphandlingarna ställde vi en stor mängd krav relaterade till denna princip, bland annat på olika kommunikationsgränssnitt. Leverantörerna kunde även få merpoäng om de hade färdiga integrationer från sin IoT-plattform gentemot andra system. Bland annat hade vi i upphandlingarna ett helt eget avsnitt för integration och interoperabilitet med olika kart- och GIS-verktyg, som ofta är det naturliga sättet att visa upp, presentera eller söka efter IoT-data.  

Referenserna är värdefulla främst för dem som har en relation till något av det som RefARK refererar till. Man behöver inte leta i dessa referenser för förståelsen av själva principen.

För vem

Detta är en central princip både vid upphandling och utveckling.

Förslag till vidare utveckling av Princip IoT-10

Principen kan utvecklas ytterligare genom att beskriva hur den kan tillämpas för olika typer av IoT-system. Vidare kan det vara värdefullt att spalta upp och beskriva de olika sätt man behöver åstadkomma interoperabilitet på, samt varför.

Exempel på korresponderande krav i VGR-upphandlingen