StateTick
Virtual commissioning usually answers one question: does the control program run the machine correctly? You build the digital twin, connect the PLC logic, start the sequence and watch the machine cycle. That’s valuable, but it only proves the machine works when the machine behaves.
Real machines don’t stay on the happy path. Air pressure drops. A nozzle clogs, or sticks open. A motor stalls. A sensor stays high forever, or stops detecting altogether. Mechanics get slower without failing outright.
So the more useful question is: what does the control program do when the machine stops cooperating? That’s where mechanical fault injection and automated, scenario-driven testing turn virtual commissioning from a demo into an engineering tool.
A twin that only renders a successful production cycle has nothing to say about the day the machine misbehaves.
A digital twin shouldn’t just be a 3D rendering of a successful production cycle. It can be a test rig for the real control program.
In StateTick, the TwinTick digital twin is driven by the same controller that runs the machine application. The twin supplies the mechanical world — motion, sensors, products, physics — while the controller executes its normal logic.
So the first step is the familiar one. Validate the expected sequence on a bottle filling line: the bottle arrives, the stopper engages, position is confirmed, filling runs and completes, and the bottle is released. The happy path works.
Then we deliberately break that assumption.
The controller is never told what went wrong. It has to work that out from the signals it already reads.
The usual shortcut is to fake faults inside the controller by forcing a variable like Fault := TRUE. That tests almost nothing, because the program is simply told what went wrong.
Instead, we change how the virtual machine behaves underneath the controller:
The controller is never told “the cylinder has low pressure.” It sees the same consequences it would see on the real machine, through its normal feedback, timing and interlocks, and has to work out for itself that something is wrong. Faults can alter physical behavior, degrade performance, or make feedback disagree with reality.
That distinction is the whole point. Now you’re testing the control logic, not the fault simulator.
“Does the sequence reach the next state?” stops being the interesting question.
With faults in play, the questions become sharper. Does the program notice that commanded motion never completed? Does it flag a sensor that has been active for an impossible length of time? Can it tell a stalled conveyor from an empty one? Does it refuse to fill when bottle position can’t be confirmed? Does it detect that filling continued after it was commanded to stop? Does it time out cleanly, stop in a controlled state, and recover?
Sometimes the answer is more important than a software bug. You may find that the machine doesn’t give the controller enough information to tell two failures apart. That isn’t a programming problem. It means a sensor is missing, an actuator needs feedback, a process measurement is absent, or an interlock needs redesigning.
This is where virtual commissioning starts feeding back into machine design, instead of just validating code after the mechanics are frozen.
Fault injection creates better test conditions. It doesn’t create a better testing process on its own.
An engineer can still enable a fault, press Start, watch the state machine, eyeball a few variables, decide it “looked right,” reset, and repeat. That’s validation by eye. It’s hard to reproduce, it depends on remembering what to watch, and after the next code change someone has to do it all again.
Write the test down instead of keeping it in your head.
The fix is to write the test down as an explicit scenario. For example:
Scenario: pneumatic pressure loss during bottle positioning
Whatever the machine specification requires becomes part of the test.
StateTick’s Test Manager is built around exactly this structure: state and preconditions, trigger, advance, assert. When a case fails, you can trace it back to the specific step and control-logic execution that caused it. TwinTick faults are bindable, so a test case can inject a mechanical failure itself and then verify the response. Because fault behavior is deterministic, a failure can be reproduced exactly instead of approximated later.
The result stops being “I tried low pressure once and it looked okay.” It becomes something the team runs again after changing the sequence, after adjusting a timeout, after adding a recovery state, and six months later when someone modifies another part of the machine. That’s where automated PLC testing becomes regression testing.
Each piece is useful alone. Together they are something else.
A digital twin lets you validate behavior before the hardware exists. Fault injection lets you explore failure paths. Scenario-driven testing lets you check expected behavior automatically.
Combined, they give you something stronger: a repeatable failure becomes a repeatable test. A motor stall is no longer something someone remembers to try during commissioning. It’s a test case, and so is a stuck sensor, low air pressure, a clogged nozzle or one stuck open. Once those cases exist, every new version of the control program is challenged against all of them, automatically, as the machine evolves.
The next step isn’t a prettier 3D model.
The first generation of virtual commissioning let us run machines before they physically existed. The next step isn’t a prettier 3D model. It’s a virtual machine hostile enough to challenge the control program, with those challenges automated enough to run continuously.
Build the control logic. Connect the digital twin. Validate the happy path. Then deliberately break the machine, find the assumptions hidden in the code, and improve the logic, or the machine itself. Turn every discovery into a scenario, and run them all whenever anything changes.
That moves virtual commissioning beyond proving a machine can work, toward proving how the control system behaves when the real world does something it wasn’t supposed to do.
Changing how the virtual machine behaves underneath the controller — a slow cylinder, a blocked nozzle, a stalled motor, a sensor that sticks or flickers — without telling the control program anything. It detects the fault the way it would on site, or it does not detect it at all.
Because the program is then simply told what went wrong. Nothing about its ability to notice a real failure has been tested.
State and preconditions, inject the fault, trigger and advance, then assert the required outcome. Deterministic fault behavior means the failure reproduces exactly on every run.
That the machine may not give the controller enough information to tell two failures apart — a missing sensor, an actuator without feedback, an interlock that needs redesigning.
StateTick Studio and Touch Studio are free to use, with no limit on program size, and TwinTick comes with a 20-day evaluation. Download the suite and run the bottle filling line yourself.
Fault Injection in TwinTick — every fault the twin can inject, and the rule they all follow.
The Test Manager — turning a fault scenario into a test that runs on every change.
TwinTick — Digital Twin — building the twin the faults run on.