January 9, 2026 · virtual-commissioningtia-portalplcsimcommissioningsiemens
I found and fixed 18 issues in a control system before I ever set foot on the customer’s site.
That sentence might sound like marketing, but it is a real number from a real project. Last month I was preparing for commissioning on an industrial oven control system – multi-zone temperature control, recipe management, safety interlocks, data logging. A typical mid-complexity project by industrial automation standards.
Before packing my tools, I ran the entire system in simulation. S7-1200 in PLCSIM, HMI in the WinCC Unified simulator, and a thermal model to simulate actual oven behavior. What I found was eye-opening, even for me.
Why Virtual Commissioning Matters
Every engineer who has done live commissioning knows the feeling: you arrive on-site, power up the system, and discover that something does not work as expected. Maybe the temperature scaling is wrong. Maybe the recipe logic has a gap. Maybe the data logging does not trigger when it should.
Each of these discoveries costs real money. You are on-site. The customer is watching. Their production line might be down. Travel and accommodation costs are already committed. And you are debugging under pressure instead of methodically testing in your office.
Virtual commissioning flips this equation. A day in simulation costs me my time and nothing else. A day on-site costs travel, accommodation, the customer’s production time, and the stress of fixing problems live.
The 18 Issues: Three Categories
What struck me about this project was how the issues spanned multiple system layers. They were not all in one place – they touched thermal control logic, state machine architecture, and HMI/data logging. Here is the breakdown.
Thermal Control Problems (10 Fixes)
This category had the most issues, which makes sense – temperature control involves tight interaction between sensors, PID controllers, recipe logic, and safety systems.
Temperature scaling mismatch. The displayed temperature was off by a factor of 2.5. In simulation, I caught this immediately because the thermal model showed realistic values while the HMI showed nonsense. On-site, this would have been the first confusing hour of commissioning.
Setpoint ramping architecture. I had placed the ramping logic in OB1, where cycle times are not deterministic. The ramp rate was inconsistent and broke recipe execution. Moving it to a cyclic interrupt OB with a fixed cycle time solved it – but that is a change you want to make at your desk, not while standing next to an oven.
PID output stuck at 0%. The PID_Compact block’s mode configuration was wrong. Outputs stayed at zero regardless of the error signal. A quick configuration fix, but one that would have been baffling during live commissioning without access to the simulation environment.
Recipe stop command failure. The stop command did not work during mid-execution. The state machine accepted a stop request only during certain states, and the recipe execution state was not one of them.
Safety fault chain gaps. The three-layer safety fault propagation (operator level, hardware level, zone level) had missing links. Faults were detected but did not propagate correctly to shut down heaters.
Additional fixes included smart setpoint initialization (starting from actual temperature instead of a hardcoded 70 degrees), thermal model parameter tuning, and several fault-handling edge cases.
State Machine Logic (4 Fixes)
The state machine issues were more subtle but would have been equally frustrating to debug on-site.
Fault reset did not propagate. The fault reset button on the HMI worked at the operator level, but faults did not clear through the full chain – from operator to hardware to zones to individual heaters. Pressing reset looked like it worked, but the system stayed faulted.
Incorrect state display. Zones showed “HEATING” when they should have shown “STOPPED.” The state machine was in the right state internally, but the status output to the HMI was mapped incorrectly.
Circular dependency deadlock. A chicken-and-egg problem: zones waited for a system-level “ready” flag before starting, but the system-level flag waited for all zones to be ready. During startup, this caused a deadlock that would have been very difficult to diagnose on-site without simulation tools.
Hold time and cooldown logic. Minor issues with how hold time was displayed and how cooldown behavior worked after recipe completion.
HMI and Data Logging (4 Fixes)
These were the most interesting issues because they involved WinCC Unified platform limitations that are not well-documented.
CSV export timing. The data export to CSV only triggered on manual stop, not on recipe completion. This meant the customer would lose their production data every time a recipe ran to completion normally.
Alarm mapping. Temperature shutdown alarms fired constantly in simulation because I had not mapped the simulation IO correctly. A quick fix, but one that would have caused alarm fatigue and confusion on-site.
WinCC Unified TagLogging API returns null. This was the big discovery. The WinCC Unified Basic panel’s TagLogging API simply does not work – it returns null. There is very little documentation about this limitation. I had to build a custom CSV logging solution from scratch using scripting. Discovering this during live commissioning would have meant telling the customer “data logging does not work” and going back to the office to build a workaround.
Alarm API fails from scheduled tasks. The GetActiveAlarms API does not function correctly when called from WinCC scheduled tasks, only from direct script execution. Another undocumented platform limitation caught in simulation.
The Business Result
Every single one of these 18 issues would have surfaced during on-site commissioning. Some would have taken minutes to fix. Others – like the TagLogging API issue – would have required going back to the office, researching the problem, building a workaround, and returning to site.
Instead, I arrived on-site with a system that had been thoroughly tested. The commissioning focused on tuning real-world behavior and validating against actual process conditions, not debugging logic errors.
The math is straightforward. This was not a complex factory automation project. It was a multi-zone oven. And simulation still found 18 issues. How many issues are hiding in the systems you are about to commission?
Getting Started with Virtual Commissioning
If you are not already using simulation before going on-site, here is what you need:
- PLCSIM or PLCSIM Advanced for your PLC logic
- WinCC Unified simulator for your HMI
- A process model – even a simple one that simulates basic sensor behavior
- Time – budget simulation time into your project, not as an afterthought
The investment pays for itself the first time you catch something that would have cost you an extra day on-site.
Planning a project? Contact us to discuss how we can help.
