One context over many systems
Sensors, GIS layers, BIM models and asset registries become NGSI-LD entities of the same shape. A query written once reaches all of them, whichever supplier built the system underneath.
NGSI-LD · federated digital twins
Connect the digital twins you already have
Cities, regions and plants run several digital twins, bought years apart from different suppliers. We put one NGSI-LD context over them so a single query reaches all of them, while each organisation keeps its data where it is and decides who may see which part.
Data stays where it lives
Nothing moves into a central database. Brokers register with each other, a query travels to whoever holds the entities, and the answers come back merged. In our reference deployment the regional broker answered for sixteen events and stored only its own six.
Policy decides what a partner sees
A partner organisation queries your twin and receives the subset your policy allows, even when its query asks for more. The rest never leaves your broker.
Standards you get to keep
NGSI-LD from ETSI, the Dataspace Protocol, OGC SensorThings and the published Smart Data Models. Replace a supplier, or replace us, and the models still describe your city.
Protocols and standards we connect
- NGSI-LD
- JSON-LD
- OGC SensorThings
- MQTT
- LoRaWAN
- OPC UA
- WFS · PostGIS
- IFC · BIM
- Smart Data Models
The problem we work on
Digital twins arrive one project at a time. Transport buys one, the energy utility buys another, the water utility keeps a third, and the building department maintains a BIM model nobody else can open. Each of them describes the same street and the same building in its own vocabulary, so a question that crosses two departments turns into a meeting instead of a query.
A standard API closes only half of that gap. NGSI-LD defines how one system reads from another. It says nothing about how the owner limits what a neighbour may see, so a city that wants to share its twin with the region can open it in full or not at all. We built the layer that does both: joins the twins into one context, and lets each owner decide who reads which part.
Six parts, one platform
01 · Sources
Adapters turn what your systems already emit, MQTT, LoRaWAN, OPC UA, WFS, IFC, into NGSI-LD entities. Nothing is rewritten on the source side.
02 · Context
A context broker holds one description of each street, meter and room, with its properties, its relationships and its
@context.03 · Federation
Brokers register with each other. A question sent to one broker is answered by whoever holds the entities, and no copy is made along the way.
04 · Policy
Access rules name who may do what with which entities under which condition. The gateway rewrites each query so it can only return what the caller is entitled to.
05 · Data space
Between organisations, Dataspace Protocol connectors negotiate the terms once. After that a federated query costs a few milliseconds more than a plain one.
06 · Consumers
Grafana and other unmodified NGSI-LD clients read across the federation as if it were a single broker. Your teams keep the tools they open in the morning.
Measured across three organisations
We deployed the platform for a city, its self-governing region and a university, each on its own Kubernetes cluster with its own credentials and no shared administrator, and measured it over a wide-area network. The numbers below come from that deployment and are published, request by request, with the research paper we wrote with Matej Bel University.
- Sending a federated query through a data space connector costs 2 ms more than plain broker-to-broker federation for one entity, 4 ms for ten. Federating at all costs about 31 ms over a direct query, and enforcing policy on the result another 18 to 19 ms.
- Fourteen of fourteen access-control cases held, among them a forged token, a token rewritten to claim the admin role, and a policy engine taken offline. The gateway denied instead of letting the request through.
- A read-only partner queried 103 vehicles held by another organisation and received the 100 it was allowed to see, also when its own query named the scope it was not allowed to read.
- Grafana with its standard NGSI-LD data source read events, air quality and vehicle positions across all three organisations with no adapter in between.
How a project starts
- Inventory. We map every system that holds twin data: protocol, model, owner, refresh rate, and who is allowed to read it.
- Pilot on one question. We take a question your teams already ask across two or three systems and make it answerable in a single NGSI-LD query.
- Roll out. Adapters, models and access rules move to your infrastructure or ours. Your teams carry on working in the tools they know.
- Open to partners. When a neighbouring organisation should read part of your twin, its connector negotiates the terms and your policy decides the rest.
Bring your twins into one context
Send us the list of systems you run. We come back with what can be joined today, what needs an adapter first, and what each one takes.