Skip to main content

Connect Live Data

A digital twin is only useful while it reflects the state of the physical world. 3dverse applications can be connected to virtually any live data source — MQTT brokers, OPC UA servers, Azure Event Hubs, REST APIs, message queues, or custom systems — to synchronize a scene with real-world operations.

Incoming data can be used to:

  • update live telemetry displayed in the scene,
  • move robots, AGVs, conveyors, or other equipment,
  • trigger animations and state changes,
  • synchronize simulations with industrial systems.

Rather than embedding protocol-specific code inside your application, 3dverse introduces a headless client called the Livelink Agent. The agent receives events from your existing systems and applies the corresponding updates to one or more running scenes.

This section explains the architecture behind the agent, how events are mapped to entities, and how to connect different types of live data sources.

The Livelink Agent is a headless Livelink client with no viewport. It authenticates against a scene, joins one or more rendering sessions, and reads and writes entities through the same APIs as a browser client — it simply never receives video. See headless clients for where it sits in the platform.

That makes it the natural place to connect external systems to a running scene, whether the source is industrial telemetry, a simulation, a scheduled process, or any other event stream.

The agent runs wherever JavaScript runs. It can be deployed as a Node.js service close to your industrial infrastructure, or directly inside a browser when the data source is web-accessible.

Every integration answers three questions

Connecting live data to a scene always comes down to three independent concerns:

QuestionObjectResponsibility
Where do events come from?TransportReads MQTT, OPC UA, Azure Event Hubs, playback, or any custom source.
How do events update the scene?Event MappingDefines which events affect which entities and what components are updated.
Which scene receives the updates?AgentConnects to one or more running sessions and applies the updates.

The Event Mapping is typically the only application-specific part. The transport and deployment mode can usually be changed without modifying the mapping itself.

Architecture — how data flows to the scene

The agent sits between your data sources and the 3D scene. Events flow through a transport, are mapped to entity updates, and applied to running scenes. Commands flow back the same way.

One event's journey

Two layers do this work, and you can use either alone:

  • IngestionPipeline runs the mappings. It has no idea what an agent, a session or a broker is — you bind scenes to it and push events in. That is what makes a mapping straightforward to unit-test, to drive from a webhook, and to replay one frame at a time.
  • SceneIngestion is the wiring around it: it binds each ready session's scene to the pipeline, unbinds it when the session goes, and starts the data sources on the first binding.

Choosing a source

Which transport you need depends on where your data already is, and on one detail that is easy to miss: each transport puts something different in an event's channel, which decides whether a mapping can route on it.

Data sources has the comparison table, the install line and runtime for each transport, and the two shortcuts worth knowing before you start — when to prefer MQTT over OPC UA, and why to build your mapping against a recording first.

When not to use the ingestion layer

The mapping model covers "an external event stream drives entities in the scene". It is not the only thing an agent can do, and it is opt-in — the Agent class underneath is datasource-agnostic and gives you the entity API and typed lifecycle events directly.

Reach past the ingestion layer when the mapping model does not fit — you need to read entity changes made by other clients and publish them back out, you already have an ingestion layer of your own, or the work is not event-shaped at all. What you take back on is the bookkeeping the pipeline was doing quietly: resolving ids to entities, skipping redundant writes, and turning off broadcast on the entities you drive. See using the agent directly.

You can also keep the pipeline and skip everything else: IngestionPipeline works with a scene from any Livelink client, agent or not.

Next steps