How do you connect a PLC to a digital twin?

A one-PLC demo can look finished: a variable moves a cylinder in Unity, a few signals change state, and the link appears to work. The work starts when that setup has to survive PLC revisions, mechanical changes and product variants on a real machine.

If the Unity model knows concrete OPC UA NodeIds, connection settings and platform-specific addresses, the 3D application is tied to one controller setup. A change in the PLC project then becomes a change in Unity. Automation engineering and the 3D application need a clearer boundary than that.

Diagnostics are the next problem. If a valve does not move in the virtual machine, the team needs to see whether the fault sits in the PLC logic, the connection, the signal mapping or the model. When that knowledge lives only in Unity code, support depends on whoever built the first version.

Machine builders who work across several platforms or variants see this faster. Siemens, B&R, Beckhoff, Rockwell and robot controllers do not expose the same runtime and integration options. Those differences belong in an integration layer, not in a rebuilt digital twin for each controller.

The same integration problem kept showing up in our digital twin and virtual commissioning projects. A project-specific connector can get the first machine running, then becomes technical debt on the next one.

neexo Gateway is our product for that layer. It runs locally between machine control and Unity and keeps connections, variables, signal bindings, runtime values and diagnostics in one place.

On the Unity side, our PowerTools client uses stable variable names and IDs instead of raw OPC UA NodeIds. Unity does not need every detail of the underlying PLC connection. That keeps machine software and the 3D application on opposite sides of a stable interface.

For the customer, the integration has to stay visible and maintainable, so the next machine can reuse it. Buried project-specific code that only the original developer understands does not survive that handoff.

Engineers use Gateway Cockpit to configure the machine connection. They can create several connections, browse variables the controllers expose, select tags, create signal bindings and inspect live values. The runtime handles the ongoing data exchange with Unity.

A machine configuration can group several controller connections under the same active machine. Unity then talks to one real-time interface instead of a separate integration for each PLC, robot or simulator. That matters on machines and lines where the control system does not come from a single vendor.

Gateway currently has connectors for OPC UA, Siemens S7 and PLCSIM Advanced, Beckhoff TwinCAT ADS, FactoryTalk Logix Echo, Universal Robots and MQTT. Those connectors do not all have the same level of validation against physical hardware, so we distinguish between implemented capability and what has been verified on a real installation.

Gateway also has diagnostics, runtime status, local logs and tooling for collecting support data. The local runtime between PLC and Unity is less visible than the 3D model, but it is what you need when the system has to be supported after the first demonstration.

Gateway can be packaged as a local Windows component together with a Unity Digital Twin. It can be launched as part of the solution and can also run as a Windows Service for more permanent installations.

Ownership becomes clearer. The PLC program owns the machine logic. The digital twin owns virtual behaviour and visualization. Gateway owns the connection between them.

Parts of the setup then transfer to the next machine. A new variant may still need new signals and new model behaviour, but the team does not invent the complete connection again.

Discussions between automation, software and mechanical teams also get more concrete. Engineers can inspect the connection, the variable and the current value instead of asking whether Unity is getting the right data. That shortens the path from a symptom to the part of the system that needs attention.

There is a commercial side. A digital twin is easier to sell as an engineering deliverable when the customer can see how it connects to existing machine software, and how that connection can be operated and supported later.

What we deliver is a setup where automation, HMI, simulation and the digital machine model work together in a way the machine builder's own team can understand.

One active machine configuration can group several controller connections, including mixed vendors, as long as each connection has a supported connector.

That matches how many machines and production lines are built. A system may have a main PLC, a separate controller for one subsystem and a robot controller. They do not have to come from the same vendor.

Vendor independence here means the Unity side does not depend on concrete controller addresses and protocols. The controller side is still specific. Siemens S7, TwinCAT ADS, OPC UA, Logix Echo, Universal Robots and MQTT do not use the same setup, and not every PLC is plug-and-play.

For a machine builder, the same Unity simulation and model structure can be used across mixed control systems and machine variants. The signal mapping still has to be correct. The integration architecture does not have to be reinvented each time.

In virtual commissioning the connection exists so real machine logic can be tested against a model that reacts in a controlled, understandable way.

When the PLC sets an output, the virtual machine should respond. When a simulated sensor changes state, the PLC should receive the relevant input. If a sequence stops, the team should be able to inspect both the controller state and the response of the virtual machine.

Gateway puts a stable boundary between controller and twin. The Unity model can work with variable names and signal bindings while the connection to the actual controller is handled separately. That helps as a project moves from early simulation into more realistic test setups.

Gateway sits alongside our work with PLC integration, motion control, HMI and Unity-based digital twins. Those disciplines still need their own engineering. Gateway is the place they meet.

Gateway does not replace PLC engineering. It does not fix a poor sequence design, and it cannot make a model more accurate than the behaviour and data in that model.

It also does not replace safety validation or physical commissioning. Interlocks and safe states can be exercised as logic, but the real machine still has to be verified with the actual safety equipment, mechanics, sensors and installation.

Gateway is also not a universal fieldbus emulator. Timing, network behaviour and hardware effects that matter on the final installation must be tested in an environment that can prove those properties. Emulation is a separate development track from the product problem Gateway solves today.

Gateway is relevant when a digital twin has to work with the actual machine software, not only visualization. It helps most when the setup has to be repeated across machines, variants or projects, and when the customer needs to understand and support the integration themselves.

It can be part of a virtual commissioning delivery, a Unity Digital Twin or an engineering setup where automation and software teams work in parallel. In those projects we use Gateway as a neexo product, not as hidden internal glue code.

Start with the machine, not the 3D engine: which controllers it uses, which signals the model needs, what should be simulated, and what still has to be proven on real hardware?

From there we can draw the boundary between the controllers, Gateway and the digital twin before the integration becomes an expensive afterthought.