Sammanfattning

Avsnittet innehåller ett ett resonemang för att öka läsarens förståelse för den problematik som data- och informationsmodeller inom IoT hanterar. Data- och informationsmodeller har av arbetsgruppen grovt indelats utifrån om deras huvudsakliga fokus är kring sensordomänen, iot-domänen eller applikationsdomänen. I kartläggningen har arbetsgruppen inte sett modeller som hanterar hela kedjan för många applikationsområden. En kommun eller region blir därför ofta hänvisad till att ta fram egna data- och informationsmodeller för att hantera och dela insamlade data.

...

Hantering av rådata respektive förädlad data har vidare hanterats och resulterat i synsättet att det kostsamma kring data är inte lagringen utan förvaltningen. Förvaltningen av en informationsmängd i termer av organisatorisk kostnad att hålla metadata, förvaltning och kunskap är en avsevärt större kostnad än lagringen.

Bakgrund

Syftet med arbetsgruppens arbete med datamodeller är att försöka ge en bild av hur de olika datamodeller och initiativ som finns på marknaden hänger ihop. Det är på inget sätt ett fullödigt arbete utan har som syfte att ge en beställare en bättre bild av vad den kan förvänta sig av olika modeller. Arbetsgruppens syfte är:

...

• Sensordomänen - det som ligger närmast sensorn och hanterar information som ligger nära sensor

• IoT-domänen - det som är fokuserat på att kunna dela information mellan olika applikationer

• Applikationsdomänen - där det är applikationens behov som styr utformningen.

...

Om informations- och datamodeller för IoT

De olika modellerna som arbetsgruppen tittat på har kunnat klassats som informationsmodell, datamodell eller onotologi eller någon form av blandning mellan dessa. Varje sådan är tänkt att fylla ett specifikt syfte. Det är detta syfte som skapar nytta för den som ska implementera den. Samtidigt ställer det ju till det för att vissa av modellerna är ganska hårt styrda i sitt innehåll. Medan andra är hårdare styrda i sin strutkur.

...

Ovan bild är tänkt att visualisera hur de olika standarderna förhåller sig till ovan nämnda informationsdomäner. Arbetsgruppen vill poängtera att detta inte är någon exakt vetenskap utan ett sätt att försöka förtydliga hur landskapet kring informationsmodeller ser ut.

Länkar till mer information om datamodeller

Synchronicity

Synchronicity har tagit fram en rekommendation om vilka datamodeller som borde användas för IoT lösningar.

• Synchronicity Datamodeller

• Synchronicity (Minimal Interoperability Mechanism)•

LightWeightM2M

LightWeightM2M har tagit fram ett antal standarder för datamodeller.

...

•https://technical.openmobilealliance.org/Overviews/lightweightm2m_overview.html

Open Geospatial Consortium och W3C

Open Geospatial Consortium och W3C har tillsammans tagit fram förslag till sätt att komma åt information från fysiska IoT-enheter.

• https://www.w3.org/TR/vocab-ssn/#Developments

SAREF

SAREF, en del av ETSI (standardorgan inom telekom), har tagit fram en referens ontology för IoT området, se här. SAREF:s ontology finns i en såkallad core, och extensions. Dessa extensions finns för flera områden tex Energy, Environment, Building, eHealth/Aging-well, Water. OASC MIM:s rekommenderar användningen av SAREF.

OneM2M

OneM2M (organ för öppna industristandarder inom IoT) har en uttalad strategi att kunna dela data mellan silos, se här. Ontologien bygger på idén att vara ett “Common Service Layer”. OneM2M inkluderar ett REST API, där data översätt mellan olika datamodeller.

FIWARE

FIWARE är ramverk, för att uppnå interoperabilitet, med ett antal datamodeller, som de kallar Smart Data Models. I samband med datamodellerna implementeras en context-broker som bygger på NGSI-LD standard från ETSI. Dessa datamodeller är rekommenderade av OASC (Open Agile Smart Cities), samt NGSI rekommenderas av CEF (Connecting Europe Facility).

Problemen kring datamodeller i kommunal/regional kontext

För IoT är problemen kring datamodeller inget nytt, utan det är ett klassiskt integrationsproblem mellan branscher och sektorer som redan har etablerade datamodeller. Men i IoT blir problemet extra tydligt eftersom IoT-data ska delas och användas i ett flertal verksamhetssystem. För detta finns ett antal olika lösningsmönster. Datamodellerna blir därför ofta frågan om ett sensorperspektiv eller verksamhetsperspektiv.

...

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

Data och informationshantering i IoT system - resonemang

Arbetsgruppen ser att följande faktorer är viktiga för kommuner och regioner att beakta i hantering av data och information från IoT system

...

Ovan bild beskriver hur data och information flödar mellan IoT-Enhet och tillämpningar.

Frågor som en beställare behöver ta ställning till rörande data och information

Vem är informationsägare och vem är informationsförvaltare?

I ett IoT system flyter data och information mellan IoT-enheten (sensor/styrdon) och tillämpningen. IoT systemet erbjuder en mängd olika tjänster för att hantera data och information längs med den vägen. Det kan röra sig om processer som ändrar data och information (tex databearbetning och berikning), lagringstjänster etc. Ett rimligt antagande är att det finns en och endast en informationsägare som äger informationen i alla system som hanterar den på vägen till tillämpningen, tex en informationsägare för badtemperaturer i hela informationsflödet. Informationsägaren behöver då ansvara för att säkerställa alla tillämpningars behov.

...

I IoT systemet anser Arbetsgruppen att det är en viktig aspekt att lyfta informationsägande aspekten ifrån ett specifikt system och istället se till informationens hela flöde och nytta i verksamheten.

Vilka data ska eller bör en kommun/region lagra?

Vilka data som ska lagras och hur länge beror helt och hållet på de verksamhetsbehov som ska uppfyllas. En kommun/region kan välja olika angreppssätt kring hur data och infomration lagras, nedan listas några av dessa med för- och nackdelar.

...

1. Lagra allt (både råddata och bearbetade data)

   1. En kommun/region kan ta det säkra för det osäkra och kräva att alla data ska lagras.

   2. Fördelar med att lagra alla data

      1. Alla data finns och det blir lätt att ändra antingen i rådata eller bearbetade data.

   3. Nackdelar med att lagra alla data

      1. En sådan strategi riskerar bli kostsam för kommun/region, främst eftersom förvaltningen av data och information är kostsam (se ovan resonemang om varför förvaltning av data är kostsam).

      2. Samma information riskerar att finnas i många olika versioner och bearbetningar i IoT-systemet, med risk för att data används felaktigt.

      3. Det finns en ökad risk att bryta mot olika lagstiftningar genom att lagra alla data.

2. Lagra enbart rådata och ha definierade kvalitetsprocesser för bearbetning av data till tillämpningar

   1. Kompletterande beskrivning: All rådata lagras som minsta gemensamma nämnare [minimum] för alla tillämpningar som nyttjar data från IoT-systemet. Kommun/region definierar vilka bearbetningsprocesser ska finnas för de olika tillämpningarna och rutiner för dessa tas fram.

   2. Fördelar med att lagra enbart rådata

      1. Rådata finns för att kunna återskapa bearbetade data

      2. Det är relativt enkelt att ändra i bearbetningsprocesser och bibehålla komplett historik (tex om det upptäckts bugg i bearbetningsprocesser).

      3. Data lagras enbart en gång, med undantag för den bearbetningsmängd som lagras i respektive tillämpning.

   3. Nackdelar med att lagra enbart rådata

      1. Genom att lagra rådata finns en risk att kommun/region lagrar stora mängder data som aldrig kommer användas.

      2. Bearbetningsprocesserna kan bli komplicerade att underhålla om de ska ta hänsyn till olika kvalitet i data från olika sensorer eller tidsepoker. Av samma anledning kan metadata bli komplexa, svårförståeliga och därmed blir data svåra att nyttja.

3. Lagra enbart bearbetade data

   1. I detta förförande lagras enbart de bearbetade data som skapas. Rådata och intermediera data raderas.

   2. Fördelar med att lagra enbart bearbetade data

      1. Mindre datamängder att förvalta, lagra och beskriva.

   3. Nackdelar med att lagra enbart bearbetade data

      1. Inga rådata finns för att återskapa bearbetade data tex vid bugg i bearbetningsprocesser eller om ny tillämpning behöver anpassade historiska data.

Några frågor att ställa för att skapa en bild av vilka data kommun/region vill lagra

En användbar strategi kring detta är att redan i början av insamlingstadiet bestämma hur data ska gallras och raderas. Viss data kan behöva arkiveras, kanske överlämnas till arkiv för framtida generationer.

...