EN

Platform

A federated NGSI-LD context layer with policy enforcement and data space connectors, adapters for the systems you already run, and data models that keep their meaning across all of them.

The context layer

Every system you connect keeps its own database. Above them we run an NGSI-LD context broker that holds one description of each real thing: a street, a substation, a sensor, a room. Your applications then ask the broker one question instead of asking twelve systems twelve different ones.

An NGSI-LD entity carries its properties, its relationships and its @context. That is enough for a query like “every temperature sensor in this district and the building it belongs to” to cross system borders with no glue code written for the occasion.

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"]
}
One street lamp as an NGSI-LD entity: a state, a location, a relationship to the road it stands on.

Three ways an application connects

Where the data lives once it arrives decides how much duplication and synchronisation a project carries, so we sort every application into one of three types before anything is built.

  • Stateless. The application keeps no data of its own. It reads from the broker and writes back to it, and the broker is the single source of truth.
  • Partial copy. The application needs a subset of the entities in its own database, for full-text search or heavy analysis the broker is not built for. We keep that subset in sync and document what is copied.
  • Application-owned. The application already speaks NGSI-LD and keeps its data. The broker holds a registration pointing at it and forwards matching queries, so a vendor system plugs into the platform with nothing stored twice.

How brokers share

One broker for a whole organisation rarely gets agreed to. Departments own their data and are careful about handing it over, which is reasonable. So brokers register with each other as context sources: a query arrives at one broker, travels on to whichever broker or adapter holds those entities, and comes back as a single merged answer.

The water utility keeps its database and its access rules. A city dashboard still shows water data next to traffic counts. We check that nothing was copied rather than assume it: the same query restricted to locally stored entities returns only what that broker owns.

query one answer Traffic context broker keeps its own data registered as context source Water context broker keeps its own data Energy context broker keeps its own data
A query reaches one broker and is answered by all three. No data was copied.

Who sees what

NGSI-LD leaves access control out of the standard on purpose. We add it at the gateway in front of the broker. Each rule names a subject, an action, a resource and a condition: this partner may query these entity types within this scope. The gateway checks every request against the policy engine, and if the engine cannot be reached the request is refused rather than waved through.

The part that matters for a shared twin is how a rule is enforced. The gateway does not filter the answer afterwards. It rewrites the query before the broker sees it, so that the query can only match entities the caller is entitled to, whatever the caller wrote. A partner who asks for a scope it may not read gets the permitted subset and nothing else, and the response is still an ordinary NGSI-LD response. Unmodified clients keep working behind it.

Between organisations

Inside one organisation, federation between brokers is enough. Between a city and its region, or a plant and its utility, the owner wants a contract before the first byte moves. Each organisation runs a Dataspace Protocol connector next to its broker. The consumer’s connector requests the catalogue, negotiates the offer and receives a transfer endpoint; the broker’s federation then points at that endpoint instead of at the peer directly.

The negotiation happens once per relationship and takes a few seconds. After that, a federated query through the connector costs 2 ms more than plain broker-to-broker federation for one entity and 4 ms for ten, measured between three organisations over a wide-area network. Sovereignty is not what makes federation expensive.

Adapters and ingestion

Most of the work in any project sits below the broker.

  • IoT and telemetry: MQTT, LoRaWAN and OPC UA feeds, normalised into entities and updated as measurements arrive. A public transport feed of roughly 400 vehicles at one message per vehicle per second is a normal load.
  • Geospatial: WFS, GeoJSON and PostGIS layers, so entities keep real geometry rather than a pair of coordinates.
  • Sensor observations: OGC SensorThings and STA-compatible services for time series.
  • Registries and files: asset databases, CSV exports, BIM and IFC extracts, cadastral records.
MQTT LoRaWAN OPC UA SCADA WFS · PostGIS GeoJSON SensorThings STA CSV · IFC BIM Adapter normalises NGSI-LD entities, queryable
What feeds the context: protocols in, NGSI-LD entities out.

Models that keep their meaning

An entity travels between systems only if both of them mean the same thing by it. We build on the published Smart Data Models where they fit and extend them where they do not, and every extension gets written down as part of the delivery. You own the resulting JSON-LD contexts, version them like any other artefact, and take them with you.

Agreement on a model IRI is what does the work. When two organisations published the same PM2.5 reading under different attribute names, each mapped to the shared model, a consumer received both under one key with no translation code on the path. An attribute nobody had mapped stayed separate, which is the correct outcome: the platform shows a vocabulary gap instead of hiding it.

Running it

The stack is open source: Scorpio as the context broker, Apache APISIX and Open Policy Agent for enforcement, Keycloak for identity, an Eclipse Dataspace Components distribution as the connector, all on Kubernetes. It runs on your cluster, on a managed cluster in an EU region you pick, or on one server for a pilot. You get the deployment as code, the models, the adapters and a runbook written for somebody who was not in the project. Replace us later and it all keeps running.

What is not there yet

We would rather you hear it from us. Federated queries cover the current state of a partner’s entities; their history still has to be replicated before it can be charted. Writing into a partner’s twin under contract is designed for and not yet delivered, so today a partner reads. Under sustained programmatic load the federated path serves about a quarter of the throughput of a direct query, which is far above what dashboards need and worth knowing before you put a public API on it.

What we leave to others

We do not sell twins, dashboards or devices. Visualisation goes to whatever tool your teams already open in the morning, and we hand it a joined context to draw from.

Ask about your systems