...
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 Principkatalog IoT
För varje princip ska det finnas ett eller flera krav som bidrar till den.
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 Kravkatalog IoT. Notera: Dessa krav kan INTE obearbetade användas direkt i en upphandling!
...
Begreppsdefinitioner finns här Begreppsdefinitioner för IoT
Bildvisualiseringaar för hur principer och RefARK hänger ihop finns här Visualisering av hur RefARKs principer hänger ihop
Exempel på hur RefARK kan användas finns här Exempel på hur RefARK kan användas
Hur kan detta material användas
Situationer när detta material är lämpligt att använda
Beställaren ska införskaffa IoT-system.
Beställaren köper vertikalt system (specifikt för en verksamhet) och vill integrera mot IoT-system.
Beställaren köper sensorer som ska kopplas mot IoT-system.
Beställaren utvecklar tillämpning som ansluts till IoT-system.
Vid utveckling av arkitektur för IoT inom beställarens organisation.
För att öka beställarens förståelse för IoT området.
En leverantör kan använda materialet för att förstå hur kommuner/regioner kommer anskaffa IoT lösningar.
Utvärdering av leverantörers lösningar
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:
Precisera och anpassa kraven till beställarens situation
Värdera vilka krav som behöver läggas till från annat håll hos beställaren
Värdera vilka krav som formuleras som SKA krav (kan ej utvärderas) och BÖR krav (kan utvärderas)
BÖR krav ges en maximal poäng som de bidrar till en eller flera principer med.
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 Kravkatalog IoT.
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å:
...
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
...
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
Övrigt
...