SV

Plattform

Ett federerat NGSI-LD-kontextlager med policytillämpning och datarumskonnektorer, adaptrar för de system ni redan driver, och datamodeller som behåller sin innebörd genom dem alla.

Kontextlagret

Varje system ni kopplar in behåller sin egen databas. Ovanför dem kör vi en NGSI-LD context broker som håller en beskrivning av varje verklig sak: en gata, en nätstation, en sensor, ett rum. Era applikationer ställer sedan en fråga till brokern i stället för tolv olika frågor till tolv system.

En NGSI-LD-entitet bär sina egenskaper, sina relationer och sin @context. Det räcker för att en fråga som “varje temperatursensor i den här stadsdelen och byggnaden den hör till” ska korsa systemgränser utan limkod skriven för tillfället.

GET /ngsi-ld/v1/entities/urn:ngsi-ld:Streetlight:BB-1042
{
  "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"]
}
En gatlykta som NGSI-LD-entitet: ett tillstånd, en plats, en relation till vägen den står vid.

Tre sätt en applikation kopplar in sig

Var data bor när de väl kommit fram avgör hur mycket dubblering och synkronisering ett projekt bär på, så vi sorterar varje applikation i en av tre typer innan något byggs.

  • Tillståndslös. Applikationen håller inga egna data. Den läser från brokern och skriver tillbaka till den, och brokern är den enda sanningskällan.
  • Delvis kopia. Applikationen behöver en delmängd av entiteterna i sin egen databas, för fritextsökning eller tung analys som brokern inte är byggd för. Vi håller den delmängden i synk och dokumenterar vad som kopieras.
  • Applikationsägd. Applikationen talar redan NGSI-LD och håller sina data. Brokern håller en registrering som pekar på den och vidarebefordrar matchande frågor, så ett leverantörssystem kopplas in i plattformen utan att något lagras två gånger.

Hur brokers delar

En enda broker för en hel organisation går sällan igenom. Förvaltningar äger sina data och är försiktiga med att lämna ifrån sig dem, vilket är rimligt. Så brokers registrerar sig hos varandra som kontextkällor: en fråga kommer till en broker, reser vidare till den broker eller adapter som håller entiteterna, och kommer tillbaka som ett enda sammanslaget svar.

Vattenbolaget behåller sin databas och sina åtkomstregler. En instrumentpanel för staden visar ändå vattendata bredvid trafikräkningar. Vi kontrollerar att inget kopierades i stället för att anta det: samma fråga begränsad till lokalt lagrade entiteter returnerar bara det den brokern själv äger.

fråga ett svar Trafik context broker behåller sina egna data registrerad som kontextkälla Vatten context broker behåller sina egna data Energi context broker behåller sina egna data
En fråga når en broker och besvaras av alla tre. Inga data kopierades.

Vem ser vad

NGSI-LD lämnar avsiktligt åtkomstkontrollen utanför standarden. Vi lägger till den i gatewayen framför brokern. Varje regel anger ett subjekt, en handling, en resurs och ett villkor: den här partnern får fråga efter dessa entitetstyper inom det här omfånget. Gatewayen prövar varje begäran mot policymotorn, och om motorn inte kan nås nekas begäran i stället för att vinkas igenom.

Det som betyder något för en delad tvilling är hur en regel tillämpas. Gatewayen filtrerar inte svaret i efterhand. Den skriver om frågan innan brokern ser den, så att frågan bara kan matcha entiteter anroparen har rätt till, vad anroparen än skrev. En partner som ber om ett omfång den inte får läsa får den tillåtna delmängden och inget annat, och svaret är fortfarande ett vanligt NGSI-LD-svar. Oförändrade klienter bakom det fortsätter fungera.

Mellan organisationer

Inom en organisation räcker federering mellan brokers. Mellan en stad och dess region, eller en anläggning och dess nätbolag, vill ägaren ha ett avtal innan första byten rör sig. Varje organisation kör en Dataspace Protocol-konnektor bredvid sin broker. Konsumentens konnektor begär katalogen, förhandlar erbjudandet och får en överföringsändpunkt; brokerns federering pekar sedan på den ändpunkten i stället för direkt på motparten.

Förhandlingen sker en gång per relation och tar några sekunder. Därefter kostar en federerad fråga genom konnektorn 2 ms mer än vanlig federering mellan brokers för en entitet och 4 ms för tio, mätt mellan tre organisationer över ett vidsträckt nät. Det är inte suveräniteten som gör federering dyr.

Adaptrar och inläsning

Det mesta arbetet i varje projekt ligger under brokern.

  • IoT och telemetri: MQTT-, LoRaWAN- och OPC UA-flöden, normaliserade till entiteter och uppdaterade allteftersom mätvärden kommer in. Ett kollektivtrafikflöde med omkring 400 fordon och ett meddelande per fordon och sekund är en normal last.
  • Geodata: WFS-, GeoJSON- och PostGIS-lager, så att entiteter behåller riktig geometri i stället för ett koordinatpar.
  • Sensorobservationer: OGC SensorThings och STA-kompatibla tjänster för tidsserier.
  • Register och filer: anläggningsdatabaser, CSV-exporter, BIM- och IFC-utdrag, fastighetsregisteruppgifter.
MQTT LoRaWAN OPC UA SCADA WFS · PostGIS GeoJSON SensorThings STA CSV · IFC BIM Adapter normaliserar NGSI-LD entiteter, sökbara
Det som föder kontexten: protokoll in, NGSI-LD-entiteter ut.

Modeller som behåller sin innebörd

En entitet reser mellan system bara om båda menar samma sak med den. Vi bygger på de publicerade Smart Data Models där de passar och utvidgar dem där de inte gör det, och varje utvidgning skrivs ner som en del av leveransen. De JSON-LD-kontexter som blir resultatet är era, ni versionshanterar dem som vilken annan artefakt som helst och tar dem med er.

Det som gör jobbet är enigheten om en modell-IRI. När två organisationer publicerade samma PM2.5-avläsning under olika attributnamn, båda mappade till den gemensamma modellen, fick en konsument båda under en nyckel utan översättningskod på vägen. Ett attribut som ingen hade mappat blev kvar för sig, vilket är rätt utfall: plattformen visar luckan i vokabuläret i stället för att dölja den.

Att driva det

Stacken är öppen källkod: Scorpio som context broker, Apache APISIX och Open Policy Agent för tillämpningen, Keycloak för identitet, en Eclipse Dataspace Components-distribution som konnektor, allt på Kubernetes. Det körs på ert kluster, på ett hanterat kluster i en EU-region ni väljer, eller på en enda server för en pilot. Ni får installationen som kod, modellerna, adaptrarna och en runbook skriven för någon som inte var med i projektet. Byt ut oss senare och allt fortsätter fungera.

Vad som inte finns ännu

Vi säger det hellre själva. Federerade frågor täcker det aktuella tillståndet hos en partners entiteter; deras historik måste fortfarande replikeras innan den kan ritas upp. Att skriva in i en partners tvilling under avtal är konstruerat men ännu inte levererat, så i dag läser en partner. Under ihållande programmatisk last betjänar den federerade vägen ungefär en fjärdedel av genomströmningen hos en direkt fråga, vilket är långt över vad instrumentpaneler behöver och värt att veta innan ni lägger ett publikt API ovanpå.

Vad vi lämnar till andra

Vi säljer inte tvillingar, instrumentpaneler eller enheter. Visualiseringen går till det verktyg era team ändå öppnar på morgonen, och vi räcker det en sammanfogad kontext att rita ur.

Fråga om era system