Datamodeller
Det här är lagret som gör data till kunskap, och det är det som flest projekt underskattar.
Ett dataformat säger att värdet är 21.6. En datamodell säger att det är en temperatur, i Celsius,
observerad vid en viss tidpunkt, av en sensor som hör till rum 101. Det ena kan du sätta i ett
diagram. Det andra kan du ställa frågor till: vilka rum på norrsidan är kalla, vilka mätare hör till
vilken hyresgäst, vad kostar den här byggnaden egentligen att värma.
Vad en modell tillför
Tre saker som en naken payload inte har:
- Identitet. En stabil, unik referens till saken, så att två system är överens om att de menar samma sensor.
- Innebörd. Vad värdet är, i vilken enhet, mätt när.
- Relationer. Vad saken tillhör, innehåller eller betjänar, så att data kan navigeras och inte bara listas.
De tre du kommer att möta
| NGSI-LD | RealEstateCore | Open BIM (IFC) | |
|---|---|---|---|
| Fokus | IoT-data och semantisk integration | Digital tvilling med semantik | Byggnadens struktur och komponenter |
| Format | JSON-LD, RDF | DTDL, JSON-LD | IFC/EXPRESS, BCF |
| Realtidsdata | Ja, främst sensordata | Ja, kan innehålla sensorer | Nej, statiskt |
| Relationer | Entiteter, egenskaper, relationer | Entiteter och relationer | Objektbaserade hierarkier |
| Används för | IoT-plattformar, smarta byggnader | Byggnadsdigitalisering och analys | Projektering, byggande, samarbete |
Open BIM är byggnadens statiska digitala modell. RealEstateCore och NGSI-LD bär dynamisk semantisk data och sensoravläsningar. Smarta byggnader använder ofta Open BIM som grund med NGSI-LD eller RealEstateCore ovanpå för realtidsdatan.
NGSI-LD
NGSI-LD är modellen som är byggd för IoT-data. Allt är en entitet med ett id, en type, egenskaper
och relationer.
Den finns i två former som bär samma information.
Det platta formatet, eller nyckel-värde-formatet, är kompakt och lätt att läsa:
{
"id": "urn:ngsi-ld:TemperatureSensor:001",
"type": "TemperatureSensor",
"temperature": 21.6,
"unitCode": "CEL",
"observedAt": "2025-09-16T13:00:00Z",
"isPointOf": "urn:ngsi-ld:Room:101"
}
Det normaliserade formatet gör varje egenskap till ett objekt med egen metadata, vilket är mer utförligt och mer precist:
{
"id": "urn:ngsi-ld:TemperatureSensor:001",
"type": "TemperatureSensor",
"temperature": {
"type": "Property",
"value": 21.6,
"unitCode": "CEL",
"observedAt": "2025-09-16T13:00:00Z"
},
"isPointOf": {
"type": "Relationship",
"object": "urn:ngsi-ld:Room:101"
}
}
Så läser du fälten:
ididentifierar entiteten unikt. Prefixeturn:ngsi-ld:är en konvention som håller identifierare unika mellan system.typeär entitetens typ, här en temperatursensor.valueär mätvärdet.unitCodeär enheten, enligt standardens kodlista, därCELär grader Celsius.observedAtär när mätningen gjordes, vilket inte är samma sak som när den kom fram.isPointOfär en relation som knyter sensorn till rummet den mäter.
Skillnaden mellan en egenskap och en relation är modellens kärna. En egenskap har ett värde; en relation pekar på en annan entitet. Följ tillräckligt många relationer så kan du gå från ett mätvärde till rummet, till våningen, till byggnaden, till ägaren.
Yggio använder det platta NGSI-LD-formatet, med attribut som hålls i translator attributes. Det valet spelar roll: det betyder att Yggio inte är låst till ett vokabulär och kan bära godtyckliga datamodeller i stället för att tvinga varje projekt genom en enda fast modell.
RealEstateCore
RealEstateCore är en digital tvillingmodell för byggnader, uttryckt i DTDL eller JSON-LD. Den beskriver byggnaden och dess utrustning såväl som avläsningarna, och används brett inom fastighetsförvaltning.
{
"@context": [
"https://w3id.org/rec/v1.0",
"https://www.w3.org/2019/10/td/v1",
"https://w3id.org/rec/rec-vocab"
],
"@type": "Temperature_Sensor",
"id": "urn:rec:TemperatureSensor:001",
"lastKnownValue": {
"@type": "TemperatureObservation",
"value": 21.6,
"unitCode": "CEL",
"observedAt": "2025-09-16T13:00:00Z"
},
"isPointOf": {
"@type": "Room",
"id": "urn:rec:Room:101"
}
}
@context anger vilka vokabulär dokumentet bygger på, vilket är det som gör att typnamnen betyder
något bestämt snarare än att vara lokala etiketter.
Mycket av konverteringen mellan RealEstateCore och NGSI-LD går att automatisera. Grundläggande sensor- och rumsdata mappas rakt av; mer komplexa byggnadsstrukturer kräver anpassning.
Yggio har connectors som omvandlar NGSI-LD till RealEstateCore, så att samma avläsningar kan betjäna ett IoT-team och ett fastighetsteam i den form var och en förväntar sig.
Open BIM
Open BIM är något annat, och att blanda ihop det med de två andra ställer till verklig skada i projekt. Det modellerar byggnader statiskt, för filbaserad interoperabilitet, snarare än att bära levande data.
- Fokus: en standardiserad representation av byggnader, deras komponenter och deras egenskaper.
- Format: IFC (Industry Foundation Classes), det mest använda, baserat på EXPRESS-schemat; och BCF (BIM Collaboration Format), för att kommunicera problem och ändringar mellan BIM-applikationer.
- Innehåll: arkitektur, konstruktion och installationer som HVAC, rör och el, plus metadata om komponenterna inklusive dimensioner, material och placering.
Relationen till IoT är att Open BIM beskriver byggnaden, och att IoT-data länkas till den genom referenser till sensorer. Själva Open BIM-filen innehåller inga levande värden, så en fråga som "vad är temperaturen i det här rummet nu" besvaras av IoT-plattformen, som använder Open BIM-modellen för att veta vilket rum som är vilket.
Att välja och kombinera
Du kommer oftast inte att välja en. En fungerande smart byggnad har den statiska modellen från projektering och byggande, den semantiska byggnadsmodellen för drift, och IoT-modellen för realtidsdata, med identifierare som knyter ihop dem.
Vad som spelar roll i praktiken:
- Kom överens om identifierarna först. Allt annat går att konvertera; identitet går inte att återskapa i efterhand.
- Registrera enhet och observationstidpunkt med varje värde, alltid.
- Behåll relationerna, även om den första tillämpningen inte använder dem. Det är de som gör den andra och tredje tillämpningen billig.