/
Data- och informationsmodeller - Resonemang

Data- och informationsmodeller - Resonemang

Owned by arkitekturgemenskapen@inera.se
juni 27, 2022
8 min read

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:

  • Skapa förutsättningar för vidarenyttjande av data i verksamhetssystem

    • Underlätta att öppna upp silosystem och tillgängliggöra data.

    • Underlätta för horisontal integration av data

  • Skapa förutsättningar för data driven innovation

  • Underlätta för kommuner och regioner att konkurrensutsätta IoT-system och systemdelar.

OBS: I denna sida använder vi begreppet informationsmodell för att beskriva informationsmodeller, datamodeller och ontologier. Detta är inte helt optimalt men görs för att förenkla. Det är inte helt självklart vad som är vad när information hämtas från respektive utgivare.

Arbetsgruppen har tittat på olika datamodeller 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.

För analysens skull har gruppen delat upp informationsmängderna i tre delar i hela det här avsnittet:

  • Sensor domä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

  • Applikations domä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.

Arbetsgruppen har tittat på LightWeightM2M, OneM2M, OGC/W3C SSN/SOSA och FIWARE.

 

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.

LightWeightM2M

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

•What is LwM2M? Lightweight M2M Protocol Overview

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

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.

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.

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

  • Kostnad för förvaltning av data och information från IoT system

    • Arbetsgruppen ser att kostnaden att lagra data och information är försumbar i det flesta fall, däremot är kostnaden för att förvalta insamlade data mer kännbar kostnad. Förvaltning av data och information kräver att kommuner och regioner beskriver kvalitet på information, har informationsägare, sköter informationsförvaltning, hanterar information enligt aktuell lagstiftning (tex arkivering, gallring, GDPR, sekretesslagstiftning, etc ), sköter om informationen (lagring, backup, datadelning etc.).

  • Informationsägande för data och information från IoT system

    • Inom varje kommun och region behöver det finnas någon/några som äger data och information insamlad i IoT system. Utan ett aktivt informationsägande är det stor risk att det lagras för mycket eller för lite data och information, vilket kan få stora konsekvenser för verksamheterna som nyttjar informationen från IoT-systmet. Informationsägaren ansvarar för att den information som kommer in från IoT-systemen är värdefull för de tillämpningar som nyttjar informationen.

    • Informationsägaren behöver säkerställa att all relevant lagstiftning rörande data och information efterlevs för sina datamängder. I praktikten innebär det att data utan informationsägare inte bör uppstå.

Information och data från IoT-system kan förenklat beskrivas enligt bilden nedan. Här delas informationen in i tre olika domäner, beroende på dess karaktär. En kommun/region behöver hantera information och data i alla tre domänerna på ett eller annat sätt. Arbetsgruppen har utgått ifrån ovan skiss i resonemangen kring information och data.

BESKRIVNING AV BILD: [MA tar fram text]

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.

Informationsförvaltaren kan variera i dataflödet för IoT data. Arbetsgruppen resonerar som att informationsförvaltare kan betraktas som ansvariga för:

  1. De system som hanterar och bearbetar IoT data och information på dess väg mellan IoT-enhet och tillämpning.

    1. En informationsförvaltare kanske förvaltar ett specifikt värde under enbart några millisekunder, när det transporteras (tex i mobilnät).

    2. En annan informationsförvaltare förvaltar lagrad information under längre tid.

    3. Ytterligare en informationsförvaltare har ansvar för att bearbeta informationen, tex tillsätta context, kvalitetstsäkra dataserier etc.

    4. Ytterligare informationsförvaltare kan vara ansvariga för tillämpningen av data, dvs att verksamheten får de tjänster och data den behöver.

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.

I samma IoT-system kan olika strategier väljas för olika datamängder, det är alltid tillämpningens behov som ska tillgodoses.

  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.

  • Vilka lagkrav finns kring det insamlade datat?

    • Personuppgifter (Personuppgiftsbiträde, Personuppgiftsansvarig), arkivering, Open Data Directive, offentlighetsprincip, öppna data, etc.

  • Hur viktigt det är att kunna ändra historiska bearbetade data?

    • Tex om det är fel i bearbetningsrutiner, ta höjd tillkommande tilllämpningar.

  • Hur viktigt är det att kunna använda och förstå data och dess kvalitet efter en längre tid?

    • Detta ställer krav på hur väl dokumenterade data ska vara.

Related content

http://arkitekturgemenskapen.inera.se - arkitekturgemenskapen@inera.se