How do you connect a PLC to a digital twin?

A demo is easy. One PLC variable moves a cylinder in Unity, a few signals change state, and the connection looks solved. The harder part starts when the setup has to support a real machine through PLC revisions, mechanical changes and product variants.

If the Unity model knows concrete OPC UA NodeIds, connection settings and platform-specific addresses, the 3D application becomes tightly coupled to one controller setup. A change in the PLC project can then turn into a change in the Unity application. That is a poor boundary between automation engineering and software.

Diagnostics are another problem. If a valve does not react in the virtual machine, the team needs to see whether the fault is in the PLC logic, the connection, the signal mapping or the model. When all of that knowledge is hidden inside Unity code, support tends to depend on the person who built the first version.

The problem becomes clearer for machine builders working across several platforms or machine variants. Siemens, B&R, Beckhoff, Rockwell and robot controllers do not expose exactly the same runtime and integration options. It is more maintainable to keep those differences in an integration layer than to rebuild the digital twin around every controller.

We built Gateway because the same integration problem kept appearing in our digital twin and virtual commissioning projects. A project-specific connector can solve the first machine, but it quickly becomes technical debt on the next one.

neexo Gateway is our product for that part of the solution. 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 works with stable variable names and IDs instead of raw OPC UA NodeIds. Unity therefore does not need to know every detail of the underlying PLC connection. That gives us a cleaner boundary between machine software and the 3D application.

For the customer, the value is not another software component. The value is making the integration visible, maintainable and reusable instead of burying it in project-specific code that only the original developer understands.

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

A machine configuration can group several controller sources under the same active machine. Gateway can connect those sources together while Unity continues to work against the same realtime layer. That matters on machines and lines where the control system does not come from a single vendor.

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

Consider a machine station with sensors, a pair of servo axes and a PLC sequence. Unity should not need to know how every signal is addressed in that specific controller. Gateway owns that connection and mapping, while Unity works with the signals the model actually needs.

Gateway also provides diagnostics, runtime status, local logs and tooling for collecting support data. The core PLC-to-Unity runtime runs locally. That is less visible than the 3D model, but it matters 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.

The first benefit is clearer ownership. The PLC program owns the machine logic. The digital twin owns virtual behaviour and visualization. Gateway owns the connection between them.

That makes parts of the setup easier to reuse on the next machine. A new variant may still need new signals and new model behaviour, but the team does not start by inventing the complete connection again. The same principle matters when a customer changes controller platform or uses different control systems across a product family.

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

There is a commercial benefit as well. A digital twin is easier to sell as a real engineering deliverable when the customer can see how it connects to existing machine software and how that connection can be operated and supported later. Gateway makes that part of the delivery more consistent and less dependent on one-off integration code.

That matters to us because neexo is not trying to deliver a polished 3D model in isolation. The useful result is a setup where automation, HMI, simulation and the digital machine model can work together in a way the machine builder's own team can understand.

Yes. That is a central part of the architecture. A Gateway machine configuration can contain several controller connections, and Gateway can connect those sources for the active machine. Unity still works against the same realtime layer instead of needing a separate integration architecture for each PLC.

That reflects real machines and production lines more closely. 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, provided each connection can be handled by a supported connector or protocol.

This is what vendor independence means here: the Unity side is independent of the 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 we do not claim that every PLC is plug-and-play.

For a machine builder, that means the same Unity simulation and model structure can be used across mixed control systems and machine variants without moving vendor-specific details into the 3D code. The signal mapping still has to be correct, but the integration architecture does not have to be reinvented each time.

In virtual commissioning, the connection is not the end goal. It exists so the real machine logic can be tested against a model that reacts in a controlled and 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 gives that workflow 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. This is particularly useful as a project moves from early simulation into more realistic test setups.

Gateway therefore sits naturally alongside our work with PLC integration, motion control, HMI and Unity-based digital twins. It does not replace those disciplines. It gives them a controlled place to 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 represented 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 should not be understood as a universal fieldbus emulator either. 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, not the same product problem Gateway solves today.

That boundary is deliberate. We would rather be clear about what a digital test can prove than turn virtual commissioning into a claim that physical commissioning disappears.

Gateway is relevant when a digital twin needs to go beyond visualization and work with the actual machine software. It is especially useful 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.

A useful first question is not which 3D engine should we use. It is: Which controllers does the machine use, which signals does the model need, 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.