Platform

Kontekstlaget

Hvert system, I forbinder, beholder sin egen database. Ovenover kører vi en NGSI-LD context broker, der holder én beskrivelse af hver virkelig ting: en gade, en transformerstation, en sensor, et rum. Jeres applikationer stiller så brokeren ét spørgsmål i stedet for at stille tolv systemer tolv forskellige.

En NGSI-LD-entitet bærer sine egenskaber, sine relationer og sin @context. Det er nok til, at en forespørgsel som “hver temperatursensor i dette kvarter og den bygning, den hører til” kan krydse systemgrænser uden limkode skrevet til lejligheden.

{
  "id": "urn:ngsi-ld:Streetlight:BB-1042",
  "type": "Streetlight",
  "powerState": { "type": "Property", "value": "off",
                    "observedAt": "2026-08-30T19:04:00Z" },
  "location": { "type": "GeoProperty",
                 "value": { "type": "Point", "coordinates": [19.146, 48.736] } },
  "refRoadSegment": { "type": "Relationship",
                       "object": "urn:ngsi-ld:RoadSegment:BB-Nam-SNP" },
  "@context": ["https://smartdatamodels.org/context.jsonld"]
}

Tre måder en applikation kobler sig på

Hvor data bor, når de er kommet frem, afgør hvor meget dobbelthold og synkronisering et projekt bærer rundt på, så vi sorterer hver applikation i én af tre typer, før noget bliver bygget.

• Tilstandsløs. Applikationen har ingen egne data. Den læser fra brokeren og skriver tilbage til den, og brokeren er den eneste kilde til sandheden.
• Delvis kopi. Applikationen har brug for en delmængde af entiteterne i sin egen database, til fritekstsøgning eller tung analyse, som brokeren ikke er bygget til. Vi holder den delmængde synkroniseret og dokumenterer, hvad der kopieres.
• Applikationsejet. Applikationen taler allerede NGSI-LD og beholder sine data. Brokeren holder en registrering, der peger på den, og videresender de forespørgsler, der matcher, så et leverandørsystem kobler sig på platformen uden at noget gemmes to gange.

Hvordan brokere deler

Én broker for en hel organisation bliver sjældent vedtaget. Afdelinger ejer deres data og er varsomme med at give dem fra sig, hvilket er rimeligt. Så brokere registrerer sig hos hinanden som kontekstkilder: en forespørgsel ankommer til én broker, rejser videre til den broker eller adapter, der har entiteterne, og kommer tilbage som ét samlet svar.

Vandselskabet beholder sin database og sine adgangsregler. Et bydashboard viser stadig vanddata ved siden af trafiktællinger. Vi kontrollerer, at intet blev kopieret, i stedet for at gå ud fra det: den samme forespørgsel begrænset til lokalt gemte entiteter returnerer kun det, den broker selv ejer.

Hvem ser hvad

NGSI-LD lader med vilje adgangskontrol stå uden for standarden. Vi lægger den i gatewayen foran brokeren. Hver regel nævner et subjekt, en handling, en ressource og en betingelse: denne partner må forespørge disse entitetstyper inden for dette scope. Gatewayen holder hver forespørgsel op mod policy-motoren, og kan motoren ikke nås, afvises forespørgslen frem for at blive vinket igennem.

Det, der betyder noget for en delt tvilling, er, hvordan en regel håndhæves. Gatewayen filtrerer ikke svaret bagefter. Den skriver forespørgslen om, før brokeren ser den, så forespørgslen kun kan matche entiteter, kalderen har ret til, uanset hvad kalderen skrev. En partner, der beder om et scope, den ikke må læse, får den tilladte delmængde og intet andet, og svaret er stadig et almindeligt NGSI-LD-svar. Uændrede klienter bag det arbejder videre.

Mellem organisationer

Inden for én organisation er føderation mellem brokere nok. Mellem en by og dens region, eller et anlæg og dets forsyningsselskab, vil ejeren have en kontrakt, før den første byte flytter sig. Hver organisation kører en Dataspace Protocol-konnektor ved siden af sin broker. Forbrugerens konnektor beder om kataloget, forhandler tilbuddet og får et transferendpoint; brokerens føderation peger derefter på det endpoint i stedet for direkte på modparten.

Forhandlingen sker én gang pr. relation og tager få sekunder. Derefter koster en fødereret forespørgsel gennem konnektoren 2 ms mere end almindelig føderation mellem brokere for én entitet og 4 ms for ti, målt mellem tre organisationer over et wide area-netværk. Suverænitet er ikke det, der gør føderation dyr.

Adaptere og indlæsning

Det meste af arbejdet i ethvert projekt ligger under brokeren.

• IoT og telemetri: MQTT-, LoRaWAN- og OPC UA-feeds, normaliseret til entiteter og opdateret, efterhånden som målinger kommer ind. Et feed fra den kollektive trafik med omkring 400 køretøjer og én besked pr. køretøj pr. sekund er en normal belastning.
• Geodata: WFS-, GeoJSON- og PostGIS-lag, så entiteter beholder rigtig geometri frem for et par koordinater.
• Sensorobservationer: OGC SensorThings og STA-kompatible tjenester til tidsserier.
• Registre og filer: aktivdatabaser, CSV-eksporter, BIM- og IFC-udtræk, matrikeloplysninger.

Modeller, der bevarer deres betydning

En entitet rejser kun mellem systemer, hvis begge mener det samme med den. Vi bygger på de offentliggjorte Smart Data Models, hvor de passer, og udvider dem, hvor de ikke gør, og hver udvidelse skrives ned som en del af leverancen. I ejer de JSON-LD-kontekster, der kommer ud af det, versionerer dem som ethvert andet artefakt og tager dem med jer.

Enighed om et model-IRI er det, der gør arbejdet. Da to organisationer udgav den samme PM2.5-måling under forskellige attributnavne, hver mappet til den fælles model, modtog en forbruger begge under én nøgle uden oversættelseskode på vejen. En attribut, ingen havde mappet, blev liggende for sig, hvilket er det rigtige udfald: platformen viser et hul i ordforrådet i stedet for at skjule det.

Sådan kører det

Stakken er open source: Scorpio som context broker, Apache APISIX og Open Policy Agent til håndhævelse, Keycloak til identitet, en Eclipse Dataspace Components-distribution som konnektor, alt sammen på Kubernetes. Det kører på jeres klynge, på en administreret klynge i en EU-region, I vælger, eller på én server til en pilot. I får installationen som kode, modellerne, adapterne og en runbook skrevet til en, der ikke var med i projektet. Skift os ud senere, og det hele kører videre.

Hvad der ikke er der endnu

Vi vil hellere selv sige det. Fødererede forespørgsler dækker den aktuelle tilstand af en partners entiteter; deres historik skal stadig replikeres, før den kan tegnes i en graf. At skrive ind i en partners tvilling under kontrakt er designet og endnu ikke leveret, så i dag læser en partner. Under vedvarende programmatisk belastning leverer den fødererede vej omkring en fjerdedel af en direkte forespørgsels gennemløb, hvilket er langt over det, dashboards har brug for, og værd at vide, før I lægger et offentligt API ovenpå.

Hvad vi overlader til andre

Vi sælger ikke tvillinger, dashboards eller enheder. Visualisering går til det værktøj, jeres hold i forvejen åbner om morgenen, og vi rækker det en samlet kontekst at tegne ud fra.