Innehållsförteckning

För vem är materialet skapat

I första hand för beställare av IoT-system inom kommunal och regional kontext. Med beställare avses personer som är involverade i tekniska, affärsmässiga och arkitekturella aspekter vid införskaffande av IoT-system. Materialet kan även användas för komplettering och utveckling av IoT System, samt för att benchmarka och utvärdera befintliga IoT system.

Kan ge leverantörer en bild av vilka krav regioner och kommuner kan komma ställa på IoT system i framtiden.

Hur materialet är uppbyggt

Principkatalog för den som vill införskaffa IoT lösningar finns här https://inera.atlassian.net/wiki/spaces/AR/pages/2491025008

1. För varje princip ska det finnas ett eller flera krav som bidrar till den.

2. De flesta principer är relaterade till EIRA, DIGG, SKR:s “Utveckling i Digital tid” eller liknande.

Kravkatalog för den som vill införskaffa IoT lösningar finns här https://inera.atlassian.net/wiki/spaces/AR/pages/2491024993. Notera: Dessa krav kan INTE obearbetade användas direkt i en upphandling!

1. Varje krav bidrar till att uppfylla en eller flera principer.

2. För varje krav finns en idé om hur leveranskrav för det kan verifieras.

Begreppsdefinitioner finns här https://inera.atlassian.net/wiki/spaces/AR/pages/2491025045

Bildvisualiseringaar för hur principer och RefARK hänger ihop finns här

Exempel på hur RefARK kan användas finns här

Hur kan detta material användas

Situationer när detta material är lämpligt att använda

1. Beställaren ska införskaffa IoT-system.

2. Beställaren köper vertikalt system (specifikt för en verksamhet) och vill integrera mot IoT-system.

3. Beställaren köper sensorer som ska kopplas mot IoT-system.

4. Beställaren utvecklar tillämpning som ansluts till IoT-system.

5. Vid utveckling av arkitektur för IoT inom beställarens organisation.

6. För att öka beställarens förståelse för IoT området.

7. En leverantör kan använda materialet för att förstå hur kommuner/regioner kommer anskaffa IoT lösningar.

8. Utvärdering av leverantörers lösningar

9. Utvärdera befintliga IoT lösningar - se under exempel.

I en upphandlingssituation

Det framtagna materialet kan inte utan bearbetning användas direkt i upphandling. Innan materialet kan användas i en upphandling behöver beställaren göra minst följande:

1. Precisera och anpassa kraven till beställarens situation

   1. Värdera vilka krav som behöver läggas till från annat håll hos beställaren

   2. Värdera vilka krav som formuleras som SKA krav (kan ej utvärderas) och BÖR krav (kan utvärderas)

   3. BÖR krav ges en maximal poäng som de bidrar till en eller flera principer med.

2. Värdera vikten av respektive princip i utvärderingen av leverantörens lösning.

Avgränsningar i materialet

Materialet hanterar det som händer mellan en sensorer/styrdon och tillämpning av IoT.

OBS: Materialet hanterar enbart det som är specifikt för IoT-system och det förväntas att den beställande organisationen har (eller ser till att ha) en väl fungerande IT-miljö, IT-organisation och upphandlingsorganisation. En mer detaljerad avgränsning kring krav finns under .

Hur har materialet tagits fram

Materialet har tagits fram i samarbete mellan representanter för kommuner och regioner. Materialet bygger på gott och ont på den kunskap som deltagarna i arbetsgruppen kunnat tillföra. Förslag till förbättringar tas tacksamt emot. Notera att detta material tagits fram genom frivilligt engagemang från kommuner och regioner som velat bidra med kunskap och erfarenhet.

Relevant dokumentation

Referensarkitekturer som arbetsgruppen hänvisar till

Referensarkitekturer med nedbrytning av moduler som kan vara av värde för den som ska införskaffa IoT system. Bla. följande referensarkitekturer anser arbetsgruppen att det är värt att titta på:

• ISO-IEC 30141-2018 sid 44 resp 48.

• NPR 8284-2020 sid 32

• DIN spec 91357 sid 12

Arbetsgruppen tar inte ställning till vilken av ovan standarder är bättre eller sämre utan alla har en del att bidra med för den som vill införskaffa ett IoT system.

Referensdokumentation

Inom uppdraget finns länksamling till viktiga dokument/tjänster

Datamodeller

Synchronicity Datamodeller

Synchronicity (Minimal Interoperability Mechanism)

Arbetsgruppen har tittat på olika datamodeller (2021-06) i syfte att ge en beställare bättre bild av framkomliga vägar, men då det är en spretig marknad där förändringar sker fort har arbetsgruppen inte kunnat ge specifika riktlinjer eller guidelines utöver de rekommendationer som finns i principerna IoT-2 och IoT-3. Det arbetas kontinuerligt med datamodeller på olika håll i världen och beställare behöver därför kontinuerligt följa utvecklingen.

Det arbetsgruppen sett är att problemen med datamodeller kan brytas ner i fyra olika beståndsdelar som behöver beaktas:

• Första problemet - objektdefinitionen

  • Vad är objektet. En badplats är olika saker för olika aktörer/förvaltningar (Fritidsförvaltningen som ska hålla reda på allt där, Planering som bara vill planera in en badplats, Kommunikation som ska publicera badvattentemp). I detta fall vet vi inte om alla tre överens om att det faktiskt är en badplats. Nån kanske tycker det är ett friluftsbad, badstrand, etc.

    • I IoT perspektivet handlar detta om att definiera de olika objekten som hanteras.

    • Den fysiska verkligheten (i flera ontologier definierad som FeatureOfInterest) - tex vattentemperaturen i Albysjön

    • Det virtuella objekt som beskriver FeatureOfInterest - tex fältet för temperaturvärde, koordinaten för sjön

  • Egentligen kan man säga att första problemet handlar om begreppsmodellen som ska användas

• Andra problemet - objektbeskrivningen

  • Hur beskrivs de objekt som definierats? Finns en lista/listor att utgå ifrån?

  • I IoT perspektivet handlar det om de informationsmodeller och klassificeringar som finns att tillgå för att beskriva både FeatureOfInterest, Observation, Sensor och ObservableProperty (se definitioner här https://www.w3.org/TR/vocab-ssn)

• Tredje problemet - generaliseringsgraden eller LevelOfDetail(LOD)

  • Är egentligen ett delproblem till första och andra problemet. Tex beskrivs en badplats med en detaljerad polygon eller en punkt.  Eller är det ett byggnadskomplex eller vägg i ett rum.

  • Detta problem är starkt kopplat till digitala tvillingar.

• Fjärde problemet - Hur modelleraa den digitala modellen (som i någon mån ska representera verkligheten)

  • Här finns en uppsjö med modeller, SAREF, FIWARE, OneM2M etc.

Material kring IoT andra tagit fram

Stadsnätsföreningens Robust Digital Infrastruktur

ITsäkerhetskrav för IoT området från ENISA

ETSI Connencting Things

Övrigt

Fiware

Atos Eindhoven

Syncronicity

EU Context Broker

OASC