On many automation projects, the first time the logic runs against something that behaves like a process is during commissioning: the site team is waiting, the schedule is under pressure and the operators are discovering their screens. Virtual commissioning moves that moment months earlier.
We run the real control system configuration — DeltaV or Siemens — together with the operator graphics on a VMware virtual machine, connected to a simple process simulation. Nothing is wired yet, and that is the point. But a virtual machine on its own proves nothing: what matters is what you test on it. Below are the five areas we work through systematically before the first cable is pulled, and why each one pays off at FAT, SAT and start-up.
What the virtual machine contains
Three layers that talk to each other exactly as they will on site:
- Operator graphics — the displays, faceplates and navigation the control room will use;
- The control system configuration — the actual DeltaV configuration or Siemens PLC program, not a mock-up written for the test;
- A process simulation — levels, flows, temperatures and equipment feedback that respond to the logic, so that sequences can actually progress.
The process model does not need to be a high-fidelity dynamic simulator. Its job is to make the logic move: a tank fills when a valve opens, a pump answers its start command, a temperature rises when heating is on. The level of detail is agreed at the start of the project, unit by unit.
1. Sequences, step by step
Every sequence is run from its initial step to its final step, and each transition is checked against the functional analysis. In practice:
- every transition condition is made true and false on purpose, not just once along the happy path;
- every action in every step is verified: which valve opens, which pump starts, which setpoint is written;
- every timer is checked, including its behaviour when the step is left early;
- hold, restart and step jumps, where they exist, leave the equipment in a defined state.
A sequence such as FILL → HEAT → TRANSFER looks simple on paper. On the virtual machine, you quickly find the missing condition that lets it move to TRANSFER while the heating is still on.
2. Abnormal situations
Most sequence problems on site do not show up in the normal run. They show up when something goes wrong. So we deliberately break things in the simulation:
- a pump trips while running (P-101 loses its run feedback);
- a valve does not reach its open position within the expected time;
- an instrument goes to bad quality or out of range;
- the operator holds, aborts or restarts the phase in the middle of a step;
- a utility is lost — instrument air, power to a package — and then comes back.
For each case the question is the same: what does the sequence do next, what does the operator see, and how does the unit get back to a safe, restartable state? If the answer is not written in the functional analysis, it is a design question. It is far cheaper to answer it in the office than in the middle of the night during start-up.
3. Interlocks and permissives
Interlocks protect people and equipment, so they deserve their own test campaign, separate from the sequences. With the alarm and interlock database as the reference, we check each line:
- the cause really triggers the effect, with the delay specified, if any;
- the reset behaviour is the one described: automatic, manual, or after acknowledgement;
- permissives block the start when they should, and the operator can see which one is missing;
- bypasses, where allowed, are visible and limited to what the design says.
The output is a line-by-line record showing that each interlock does what the database says. That record becomes the starting point of the formal FAT tests.
4. Alarms
Alarms are tested for their content as much as for their function. Each alarm must come up with the right priority and a message that an operator understands without opening a manual. We also look at what happens during upsets: a single trip should not bury the operator under a flood of consequential alarms. The simulated failure scenarios are the ideal place to spot alarm floods and fix them — with suppression rules, better grouping, or simply by removing alarms nobody needs.
5. Operator graphics
Finally, the graphics are tested the way operators will use them: navigation between displays, faceplates, trends, access to alarms and, above all, what the operator sees when something goes wrong. Running the abnormal scenarios with a future operator or shift supervisor at the keyboard is one of the most valuable sessions of the whole project. It also turns the virtual machine into an operator training tool long before start-up: on day one, the screens are already familiar.
What this changes at FAT, SAT and start-up
Each defect found on the virtual machine is one less surprise later. The FAT is no longer the first complete run of the logic; it confirms something that has already been exercised. At SAT and start-up, the team can focus on what cannot be simulated: field wiring, instruments, mechanical equipment and the real process. After start-up, the virtual machine remains useful to train new operators and to test modifications offline before they reach the live plant.
In short
Virtual commissioning is not a demo. It is a structured test campaign — sequences, abnormal cases, interlocks, alarms and graphics — run on the real configuration while changes are still cheap. To see how we set it up on DeltaV and Siemens projects, visit our virtual commissioning page or our DeltaV engineering services.
Planning a new unit, an extension or a migration?
Tell us about your project: we will show you how a virtual machine would fit into it.