How do PLC brands connect to virtual commissioning?

Virtual commissioning is not a single product you buy from one vendor. It is the discipline of running your real control logic against a representative machine model before the hardware is fully wired. The PLC stack you already use determines which coupling paths are practical: a soft-PLC on the engineering workstation, mirrored I/O into a simulation layer, or standardized data exchange over OPC UA.

Machine builders rarely switch PLC families mid-project to chase a simulation feature, and they should not. The better question is how to connect the controller you have to the twin you are building, without maintaining two parallel tag lists that drift apart after the first automation change.

B&R, Beckhoff, and Siemens are common choices in European custom machinery. Each ecosystem has mature tools for logic development, but the depth of 3D twin coupling varies. Some workflows are smooth as long as you stay inside the vendor toolchain; others need an explicit bridge when the visual twin lives in Unity or another external runtime.

Honest scoping reduces late integration rework. A project that assumes full motion fidelity on day one will stall if the chosen coupling only handles digital I/O at first. Start from what you need to prove at FAT: interlocks, mode changes, recipe handling, and motion where spatial behaviour matters. Then pick the coupling pattern that covers those risks, not the one with the best-looking architecture slide.

B&R is a comfortable starting point for teams that want control software and a testable machine model in one place. Automation Studio keeps logic, visualization, and motion in a single toolchain. Coupling an external twin still requires a defined interface and controlled signal mapping; tags can be exported or mirrored, but the mapping work does not disappear.

Many B&R teams already run their projects in ARsim, the soft-PLC that ships with Automation Studio, so sequences execute long before panels are built. When you add a 3D layer, the twin consumes the same digital and analog signals the PLC program expects: limit switches, acknowledgements, mode bits, and drive status words. The PLC application can usually stay production-intent, but the integration still needs interface mapping and representative machine behaviour.

Motion-heavy B&R lines benefit when the twin respects the axis status signals the project actually uses: in position, error, homed, and other drive or controller bits the sequence waits on. You do not need photoreal graphics to test whether a sequence waits for the correct status word before advancing. You do need those words mapped with the same names and scaling as in the PLC project. Simulated safety-status signals may support sequence testing; they do not validate the safety function itself.

OPC UA is the usual bridge when the visual twin runs outside Automation Studio. The PLC side exposes nodes; the twin subscribes and publishes at agreed update rates. Document which variables are authoritative and which are twin-only stubs for equipment you have not modelled yet.

One practical architecture pairs a B&R runtime with a Unity-based twin through OPC UA, so operators see spatial context while the same interlocks run in software. The pattern works when someone owns the signal mapping as a living deliverable and updates it whenever I/O or HMI flows change.

Beckhoff TwinCAT is a staple on custom machines where PC-based control and deterministic I/O matter. For virtual commissioning, the TwinCAT runtime can execute your control code on the engineering PC without target hardware, which lets teams exercise logic before cabinets arrive. That alone covers early interlock testing and HMI mode navigation.

TwinCAT's strength is that PLC, motion, and I/O configuration live in one project. Connecting to an external 3D twin usually means routing process data over ADS or OPC UA, depending on what the simulation layer speaks. ADS is fast and familiar in Beckhoff-centric shops; OPC UA earns its keep when several clients, including a Unity runtime, need the same variables.

Motion integration deserves explicit scope. TwinCAT NC/PTP simulation axes support axis-command and sequence testing. Mechanical kinematics, collisions, cable chains, and real-world backlash require a separate model. State that in the test plan so FAT participants know which behaviours were proven virtually.

Remote stakeholders can follow TwinCAT sessions when the runtime and the twin share a stable network path. Treat those sessions as FAT rehearsals, not acceptance. Log software versions, the runtime type, and which I/O was real and which was simulated.

Teams that standardize on Beckhoff should extend their existing tag naming into the twin early. Renaming after the logic has matured creates silent mismatches that show up as false passes in virtual runs.

Siemens brings a broad portfolio: TIA Portal, PLCSIM, and PLCSIM Advanced for virtual controller instances, plus workflows that connect to simulation partners. For many machine builders that is enough to validate logic, alarms, and HMI screens without any 3D model, and it is legitimate virtual commissioning for a large share of typical FAT scope.

The honest boundary is coupling to a spatial twin. Siemens-native simulation excels at PLC-centric testing. When you want operator sight lines, clearance checks, or robot reach in the same session as S7 logic, you typically add a bridge: OPC UA, the S7-PLCSIM Advanced API, or partner tooling. Siemens-native mechanical workflows can use NX Mechatronics Concept Designer. Budget integration time; it is rarely a single export step.

S7-PLCSIM Advanced adds capabilities including multiple virtual controller instances, TCP/IP communication, an open co-simulation API, and broader support for S7-1500 and ET 200SP families compared with basic S7-PLCSIM. OPC UA on the instance needs a TCP/IP adapter configuration, not Softbus alone. It still does not replace mechanical verification. Use it to prove sequence logic and communication between PLCs on a line, then extend coverage in a 3D twin where spatial faults appear.

Check supported operating environments, licensing, virtual-network adapter configuration, and site IT policy before integration. Dedicated VMs or centralized licensing are site-specific choices. Solve networking and access rules in week one, not the week before customer FAT.

If your customer standardizes on Siemens, set expectations early: Siemens tools plus a Unity twin is a combined architecture, not a single feature you switch on in TIA Portal. Agree who updates the twin when the TIA project version changes.

OPC UA is the neutral layer when the PLC toolchain and the 3D runtime come from different vendors. Instead of writing custom sockets for every project, you publish a structured address space: digital inputs from simulated sensors, outputs that drive animations, analog values with engineering units, and method calls for rare actions like reset or recipe download.

Design the address space for commissioning, not for every internal helper bit. Bloated address spaces slow clients down and invite copy-paste errors. Group signals by machine module: infeed, process station, outfeed, safety, utilities. Mirror that modularity in the PLC project so a twin developer can map one module at a time.

Security and performance need upfront agreement. Will the twin connect locally on the engineering VLAN during development only, or will remote viewers subscribe during customer reviews? Use certificates and roles where policy requires them. Agree sampling and publishing intervals: a 3D scene may not need millisecond updates for every door sensor. Axis command and status data may need higher rates than discrete signals, but hard real-time servo exchange should use an appropriate deterministic interface, not OPC UA alone.

Version the OPC UA information model alongside PLC releases. When a tag is renamed in the PLC, the twin must fail visibly instead of silently reading stale nodes. A CI check that diffs exported tag lists against the UA model catches drift early.

OPC UA does not remove the need for a test plan. It takes the friction out of the connection between logic and model. Pass/fail criteria still live in your commissioning documents, tied to the same signals the UA server exposes.

Software-in-the-loop with a soft-PLC is common for early integration. Control code runs on the engineering workstation or a VM, exchanges I/O with the twin, and iterates quickly after each logic change. Depending on model fidelity and test scope, many sequence, alarm, and HMI tests can complete at this level.

Hardware-in-the-loop (HIL) puts real controllers on the network with simulated I/O. Use it when real-controller execution, representative network behaviour, or hardware interfaces matter before FAT. HIL costs more setup time and lab space, and it can reveal issues a software runtime does not reproduce, but final timing and safety validation remain hardware tasks.

Hybrid projects are normal: soft-PLC for the daily developer loop, HIL for regression before customer representatives arrive. The twin should support both without remapping tags from scratch, which implies one canonical signal list consumed by different runtimes.

Do not choose HIL to impress a customer when your FAT risks are mostly logic and spatial behaviour. Choose it when production timing has burned you before: PROFINET device faults, cross-PLC handshakes, or safety relay feedback paths that only behave realistically with real hardware in the loop.

A testable signal mapping is the deliverable that turns vendor choice into virtual FAT value. Export I/O from the PLC project in a format both the automation and twin teams accept: CSV, vendor XML, or OPC UA node lists derived from the same source. Ban parallel spreadsheets that live only in email.

Attach each signal to a test requirement where you can. If DI_ConveyorReady must be true before M_ConveyorRun energizes, the twin should log that relationship during scripted runs. Build a small library of these requirements from your last FAT defect list; that is how virtual commissioning earns trust.

Stub upstream and downstream equipment explicitly. Machines rarely run in isolation. When the twin simulates a packaging machine, label which handshake bits represent real customer systems and which are placeholders. Review those stubs with the integrator so a virtual pass does not rest on interlocks that exist only in the model.

Think one level up as well. The same Unity model that reads B&R or Beckhoff signals over OPC UA can later support operator training and service documentation, provided geometry and tags stay maintained. Our guides on virtual commissioning and Unity digital twins cover that bigger picture.

Before you invite customers, run a dry session with the same roles as FAT: a PLC owner, an HMI operator, and a scribe logging deviations. Fix mapping gaps then, not on the day the customer is in the room. That rehearsal proves that platform, bridge, and twin behave as one system.