How do you couple PLC platforms to the digital twin and virtual commissioning?

Virtual commissioning is a method where machine control logic is tested against a representative model of the machine before the line is finished and wired. The PLC runs sequences, interlocks, modes and HMI commands. The digital twin represents motion, sensors, material flow and operator context.

Switching PLC family mid-project to get a particular simulation feature is rarely realistic. The choice is how the platform you already have can take part in a Unity test environment.

B&R, Beckhoff, Siemens and Rockwell differ in how far you can get on an engineering PC, how you couple that runtime to Unity through neexo Gateway, and when a physical controller is still required for network, I/O or fieldbus tests. Other vendors can join the same test system if their runtime or hardware can exchange the agreed signals.

A PLC simulation can test logic, alarms and HMI flows without a 3D model. Virtual commissioning starts when that PLC logic is also tested against a model that represents the machine behaviour and the signals the PLC program expects.

neexo Gateway is the integration layer between the PLC platform, other data sources and the Unity model. Unity handles geometry, kinematics, physics, sensors, material flow and operator context. The Gateway handles the controlled signal exchange between the model and the automation system.

In practice the Gateway reads commands and status values from the PLC, translates them to the agreed data types and sends them to the Unity model. The model then computes the relevant machine behaviour and returns sensor status, position feedback, material presence or fault states to the PLC.

The Gateway is the documented contract between the controls team and the digital twin team. It defines signal names, data types, read and write direction, forced signals, source priority and mapping version control.

That contract also lets several data sources feed the same Unity model. One machine section can run on a physical PLC while an adjacent module runs on a simulated PLC runtime. Robots, databases, test tools and emulated external equipment can join as extra sources if their role in the test system is clearly defined.

The Unity model does not replace PLC logic. It represents the process and the physical behaviour of the machine. The PLC program still owns sequences, interlocks and operator functions.

B&R Automation Studio includes Automation Runtime Simulation, often called ARsim, and ACOPOS Simulation for relevant motion scenarios. That lets the PLC application and parts of the motion logic run on an engineering PC before the physical controller and cabinet are ready.

ARsim is useful for early tests of sequences, alarms, modes and HMI logic. In the same loop the Unity model can represent limit switches, sensor feedback, material flow and the spatial behaviour the PLC program depends on. B&R describes ARsim and ACOPOS Simulation as part of its model-based development and simulation environment. See B&R's modelling and simulation page.

neexo Gateway can couple the B&R application to Unity through a project-defined interface, for example PLC-exposed data or B&R's PVI interface. Some architectures also use OPC UA when the PLC side exposes the relevant tags.

The mapping has to rest on the same authoritative tag list as the PLC project. Signals for commands, sensors, axis states, acknowledgements and faults need one defined owner. Unity should only return the signals the model actually represents.

A physical B&R controller is relevant when the test requirement includes the controller's actual network behaviour, fieldbus configuration, physical I/O or communication with external equipment. ARsim is often enough for daily development and early regression. HIL is typically reserved for selected runs before virtual FAT or physical FAT.

TwinCAT 3 Usermode Runtime can execute the same PLC program on an engineering PC, without EtherCAT and without the deterministic properties of a normal real-time runtime. That is enough for daily sequence, alarm and HMI tests against a Unity model. It is not enough when physical EtherCAT I/O, hardware-dependent loops or real-time behaviour are part of the FAT risk.

Beckhoff's TwinCAT 3 Usermode Runtime documentation covers engineering, external-control and fast-as-possible scenarios. TwinCAT is a good fit for running PLC sequences and HMI flows with a Unity model while the mechanical response is simulated in the model. Kinematics, sensors, collision detection and material flow still have to be modelled on purpose. See Beckhoff's TwinCAT 3 Usermode Runtime product page.

The Gateway gathers the signals into a shared mapping, so Unity does not need to know the concrete TwinCAT structure. Swapping a software runtime for a physical controller then does not require a new Unity model or a second tag list.

A typical path uses Usermode Runtime for daily tests and a physical Beckhoff controller for the cases where hardware and network are part of the risk. ADS is often the practical Gateway choice when the Unity model couples tightly to one TwinCAT installation. OPC UA is easier when several systems need the same PLC variables.

Siemens S7-PLCSIM Advanced can run several virtual controllers and talk to external test tools. That is the distinctive starting point on Siemens projects: logic, alarms, recipes and HMI flows can already run before a Unity model exists.

For many projects, PLC and HMI simulation is a natural first step. The team can test sequence logic, alarms, recipes and operator flows without a finished machine model. Once Unity is coupled, the same PLC logic can be tested against representative sensor and process feedback from the digital twin. See Siemens' S7-PLCSIM Advanced overview.

neexo Gateway can couple to Siemens through S7 communication over TCP/IP, the S7-PLCSIM Advanced API or OPC UA, depending on PLC type, network setup and the intended test architecture. The choice should start from which data has to be exchanged, how many virtual controllers take part, and whether the Unity model runs on the same network as the PLC runtime.

The Gateway should keep the boundary between PLC and model visible. The PLC might send commands to a conveyor or robot cell, while Unity returns sensors, position status and material presence. The test plan should state which signals represent real machine behaviour and which temporarily stub equipment that is not in the model.

HIL with a physical Siemens controller is relevant when the test includes PROFINET devices, communication between physical controllers, physical I/O or a customer-specific network configuration. The same applies when risk sits in hardware-dependent modules or links to external equipment. S7-PLCSIM Advanced is strong for early logic tests, but it does not replace physical validation of networks, safety hardware or process equipment. The Unity model can be used in both setups if the signal mapping stays stable across runtime and physical PLC.

Rockwell Automation offers FactoryTalk Logix Echo to emulate Logix controllers. That lets teams test Logix applications before the physical controller is ready, and it is useful for early trials of sequences, alarms and HMI logic.

Rockwell also has Emulate3D as a separate 3D simulation product. That is worth knowing on Rockwell projects, but a Unity-based digital twin can couple to the Logix application through neexo Gateway without being tied to Rockwell's 3D environment. See Rockwell's FactoryTalk Logix Echo product page.

neexo Gateway can couple Unity to physical or emulated Logix controllers through CIP-based tag communication over EtherNet/IP or other interfaces agreed in the project. The Gateway reads the tags the PLC program uses and exchanges only the signals needed for that machine model.

The same Unity model can then be used in a software-based test loop and in a HIL setup. The PLC program can keep its Logix structure, while the Unity team works from a clear mapping between controller tags and the model's signals.

A physical Rockwell controller is relevant when the test requirement includes physical EtherNet/IP communication, I/O modules, drives, safety components or integration with other Rockwell and customer equipment. FactoryTalk Logix Echo is a solid starting point for early application-logic tests, but it cannot on its own document the full hardware and network behaviour.

Software in the loop, often shortened to SIL, is usually the right place to start. The PLC code runs on an engineering PC or in a virtual runtime, and the Unity model returns the signals the PLC expects from the physical machine. Iteration stays short because a PLC change can be tested again quickly.

SIL is especially useful for sequence logic, interlocks, alarms, modes, HMI flows and repeatable regression tests. It is also where the project can catch signal-mapping faults before physical hardware and customer time are involved.

Hardware in the loop, HIL, uses a physical controller while the machine process and part of the I/O stay digital. Choose HIL when the test requirement is the controller's actual execution, network connections, fieldbus, hardware interfaces or interaction with external equipment.

Many projects benefit from using both. SIL covers day-to-day development. HIL covers targeted test cases before virtual FAT. The Unity model and neexo Gateway should be the same in both environments, so the move does not create a new manual mapping or a parallel tag list.

The table is a technical overview, not a substitute for an integration review. The concrete PLC type, software version, licence model, network architecture and the machine's risk profile still decide the final choice.

Signal mapping is the link between PLC logic and the value of the digital twin. If a PLC tag changes name, data type or function, that change has to be visible and handled in the Unity project. Otherwise the team can run a test with signals that look right but no longer match the PLC program.

One authoritative signal source should feed both the PLC project and the Gateway mapping. That can be a tag export, a structured I/O list or another controlled project artefact. Avoid maintaining a separate copy of the signals in spreadsheets, emails or local notes. The mapping should record whether a signal is read or written, its data type, which PLC or data source owns it, and which part of the Unity model uses it. With several data sources, it should also state which source has priority in the current test run.

Machines rarely run in isolation. A packaging machine may have to handle signals from upstream and downstream equipment, robots, vision systems, conveyors or the customer's existing line control. Modelling the whole production line is not always relevant or possible. neexo Gateway can collect several sources and present them to the Unity model through the same structured signal model. A passed virtual commissioning scenario is only credible if simulated response times, acknowledgements and fault states are realistic enough for what you need to verify.

When a PLC release changes a tag structure, the Gateway and the Unity model should fail visibly instead of continuing with an incomplete mapping. That turns drift into an engineering question that can be solved before it becomes a wrong test result.

A digital twin can move a large share of test work earlier in the project. It does not replace final physical validation. Safety functions, the safety controller, Performance Level, SIL requirements, electromechanical performance and actual process properties still have to be verified on the real machine. The same applies to mechanical tolerances, cable motion, pneumatic and hydraulic response, real product variation and process conditions the model does not represent.

Start with the test areas that carry the largest FAT risk: safety-related sequences, mode changes, critical machine cycles, central HMI flows and interfaces to other equipment. Agree how detailed the Unity model needs to be, then define the architecture: software runtime or physical hardware, how the Gateway reaches the controller, and which data sources take part. Before the customer is invited to virtual FAT, the project team should run an internal dress rehearsal with the PLC owner, HMI operator, digital twin owner and test owner.