Most manufacturers have now heard the pitch for virtual commissioning. Fewer have a clear picture of what it actually proves, and that matters, because the value is entirely in the specifics. A simulation that makes a nice video and a simulation that saves you three weeks on site are different pieces of work.
The short version: simulation lets you find the problems that would otherwise be found by a team of engineers standing in front of live equipment, at the point where fixing them is most expensive and most disruptive. What follows is what can realistically be proven offline, how the approach changes with the size of the system, and the one area that tends to get skipped.
What simulation actually proves
For a robotic cell or line, a properly built model will confirm the following before anything is installed:
- Reach and access. Whether the robot can get to every position, in every product variant, without a singularity or an awkward wrist flip at the worst possible moment
- Collisions. Robot to fixture, robot to robot, tooling to guarding, cable management through the full range of motion
- Cycle time. Real motion profiles against the actual sequence, rather than an estimate based on nominal move times
- Interlocks and sequencing. Zone interlocking between robots, handshakes with conveyors and upstream machines, and behaviour when two cells contend for the same space
- PLC logic. With the real PLC code connected to the model, the control sequence is tested as it will actually run, not as it was intended to run
What simulation does not prove is anything that depends on physical reality: grip on a real product, how a pack behaves when it is slightly damp, tolerance stack-up in a fixture that was made 0.5mm out. Those still have to be found on site. A good simulation narrows the on-site work down to exactly that category, which is the point.
The aim is not to eliminate on-site commissioning. It is to arrive on site with only the problems that could not have been found anywhere else.
Small systems and large systems need different approaches
Single cells and small installations
For a palletising cell, a machine tending application or a single robot on an end of line, the value is concentrated in reach, cycle time and pattern validation. This work is usually done in the robot manufacturer's own environment, which keeps it proportionate to the size of the job.
For palletising in particular, the pattern work alone justifies it. Proving every pallet pattern offline, including the awkward part-layer cases, removes days of fiddling at the cell with a stack of product and a teach pendant. And because the programs are generated against the real cell geometry, they transfer rather than needing to be rebuilt on site.
Full lines and multi-robot systems
Once you have several robots interacting, conveyors feeding them and a PLC coordinating the lot, the interesting failures are no longer about any individual robot. They are about sequencing, contention and what happens when one part of the system stops while the rest keeps going.
That is where a full virtual commissioning model earns its cost, with the PLC connected to a model of the mechanical system so the control logic is exercised properly. On a large system, the number of interactions is well beyond what anyone can reason about from a functional specification alone.
Key point: On a single cell, simulation mostly de-risks the robot. On a full line, it mostly de-risks the PLC. The larger the system, the more the value sits in the control logic rather than the motion.
The tools
The platform matters less than what you do with it, but the practical landscape looks like this.
Siemens Process Simulate is the standard where multi-robot lines and PLC-connected virtual commissioning are involved, and is deeply entrenched in automotive. Where a customer already works to a Process Simulate standard, or their OEM mandates it, that decision is usually made for you.
fe.screen-sim from F.EE is a strong alternative for digital twin and PLC simulation, particularly in mechanical engineering and plant construction. We have used it to validate robot programming and PLC logic across multiple stations, and on that programme eight weeks of planned on-site startup came down to four days.
Robot manufacturers' own environments — ABB RobotStudio, FANUC ROBOGUIDE, KUKA.Sim — are well suited to single cells and to generating production-ready programs for their own robots, without the overhead of a full line model.
For conveyor and material handling systems, where the questions are about flow, accumulation and throughput rather than robot motion, emulation tools built around material flow are the better fit.
Different customers want different things here, and that is reasonable. Some have a corporate standard and no appetite to deviate from it. Some want the lowest cost route to proving one cell. Some need a model that will be maintained for the life of the line rather than thrown away after startup. Those are different requirements and they point at different tools.
The right question to ask a supplier is not which package they own. It is what they intend to prove with it, and how the output reaches your equipment. A simulation that produces a video but no transferable programs has done half the job.
Fault recovery: the part that gets skipped
Almost every simulation proves the happy path. The robot picks, moves, places, returns. Far fewer test what happens when it does not.
This matters because the happy path is the easy part, and it is not where commissioning time is lost. Time is lost on the cases nobody scripted:
- An emergency stop mid-cycle, with the robot holding a part halfway between two stations
- A downstream machine stopping while the upstream one is still feeding
- Restarting after a fault with product left in the system, rather than from an empty line
- A part arriving slightly out of position, or not arriving at all
- Recovering to home from every intermediate position without collecting the fixture on the way
Every one of those can be tested in simulation, and every one of them is genuinely unpleasant to test on live equipment. Testing recovery on a real cell means deliberately breaking a running system, repeatedly, usually with the whole commissioning team waiting. It is slow, it is the sort of testing that gets quietly dropped when a programme is behind schedule, and skipping it is precisely how lines end up needing a person stationed nearby to sort out every stoppage by hand.
Planning a new cell or line?
We build the model, validate the logic and prove the recovery cases before your equipment is installed, so site time is spent commissioning rather than debugging.
Virtual Commissioning →The safety argument
The commercial case usually gets made on schedule, but the safety case is at least as strong. Every hour of debugging that happens in a model is an hour nobody spends inside a guarded cell with a partially proven program, working in teach mode alongside equipment whose behaviour is not yet fully understood.
Untested recovery logic is a safety issue in its own right. If the only way to clear a fault is for someone to enter the cell and move things by hand, that becomes routine, and routine access to a cell is a risk that compounds over the life of the system.
Where the savings come from
The headline figures quoted around virtual commissioning tend to focus on startup duration, and the compression is real — the multi-station programme mentioned above went from eight weeks of planned on-site startup to four days. But the schedule is only part of it.
| Where the cost sits | Without simulation | With simulation |
|---|---|---|
| Reach and collision issues | Found at install, often needing mechanical rework | Found in the model, fixed on a drawing |
| Robot programming | Written on the pendant, on site, on the clock | Generated offline, transferred and touched up |
| PLC sequence debugging | Against live equipment, one fault at a time | Against the model, before equipment arrives |
| Fault recovery testing | Deliberately breaking a live line, or skipped | Tested exhaustively at no risk |
| Engineers on site | Large team, long duration, travel and accommodation | Smaller team, short duration |
The line people tend to overlook is the last one. On-site engineering is the most expensive way to buy engineering time, because it comes with travel, accommodation, shift working and the unavoidable dead time of a site that is not yet ready. Moving that work offline changes what it costs as well as when it happens.
What it takes to do properly
Simulation is only as good as what goes into it. To build a model worth trusting you need reasonably accurate 3D data for the cell, correct tooling geometry, the real product dimensions across every variant, and a sequence definition that describes what the system is meant to do rather than what it looks like. Where that data is poor, the model will confirm things that are not true, which is worse than not modelling at all.
It is also worth being honest about when it is not warranted. A single robot doing one simple task, in a cell with plenty of clearance and no interaction with anything else, probably does not need a full virtual commissioning exercise. The threshold is interaction: as soon as multiple machines have to coordinate, or product has to arrive in a particular state at a particular time, the number of ways it can go wrong grows faster than anyone's ability to predict them from a document.
The question to ask
If you are specifying a new cell or line, ask your integrator what they will prove offline before they arrive, and ask specifically about fault recovery. The answer tells you a great deal about how the commissioning phase is going to go, and about whether the line you take delivery of will run on its own or need people standing next to it.