Virtual FAT vs. physical FAT: what is the difference?
9 min read · By neexo engineering team · Vejle, Denmark
Published: 2 July 2026
Virtual FAT runs Factory Acceptance Test scenarios against a digital twin linked to real PLC code, letting buyers and builders validate logic, HMI flows, and safety sequences without full hardware in the room. It prepares teams for physical FAT but does not replace signed acceptance on the actual machine.
For a full definition of virtual commissioning, read our guide first →
What is a Factory Acceptance Test (FAT)?
A Factory Acceptance Test is the formal run where a buyer verifies that a machine meets agreed specifications before it ships. Tests cover safety, cycle behaviour, HMI operation, documentation, and often specific performance metrics. Results feed the acceptance record: pass, conditional pass, or fail with rework.
What is virtual FAT?
Virtual FAT applies the same acceptance mindset to a digital twin coupled to real control software. Test cases are executed against simulated I/O and representative motion instead of the full physical line. Stakeholders can join remotely, log defects with reproduction steps, and rerun suites after PLC drops without occupying the build hall.
The discipline mirrors physical FAT: named cases, expected results, observers, and documented outcomes. The difference is the plant floor is simulated. Alarms can be injected safely; edge conditions that are hazardous or wasteful on hardware (jammed product, failed vacuum, repeated e-stop cycles) can be repeated until the recovery path is correct.
Link virtual FAT cases to requirement IDs from the functional spec when possible. Traceability makes it obvious which contract clauses were exercised digitally and which still need a witness on steel.
Buyers increasingly ask for visibility before travel. A virtual FAT gives them a structured window into behaviour without standing in noise and PPE for a full week. Builders keep control of the schedule: pause for fixes, branch PLC builds, and resume the same case list when ready.
Naming matters for project communication. Some teams label these sessions digital FAT, simulated acceptance, or pre-FAT: pick one term in the quality plan so stakeholders know whether signatures are in scope. Ambiguous naming is how virtual runs get mistaken for contractual closure.
The output is evidence: screen recordings, test logs, and issue lists that shape the physical FAT agenda. Contracts still define what counts as formal acceptance; virtual FAT is preparation and risk reduction, not a substitute for signatures on the shipped machine unless explicitly agreed.
What is the difference between virtual FAT and physical FAT?
Both aim to prove the machine meets intent; they differ in environment, evidence type, and what classes of defects surface first. Virtual FAT excels at logic, sequences, and operator flows. Physical FAT remains authoritative for mechanical fit, real sensors, noise, vibration, and installed utilities.
Physical FAT also carries contractual weight: witness names, punch lists tied to shipment, and often financial triggers. Virtual FAT rarely appears in signature blocks unless legal and quality teams write it in. Treat virtual results as inputs to the formal pack, not automatic substitutes.
Another split is repeatability. Virtual suites can run overnight after a patch; physical reruns may need staff, materials, and hall time. That asymmetry is why teams front-load software-heavy cases digitally, they get more iterations per calendar day.
Risk ownership differs too. Virtual FAT findings are usually builder-led fixes before the customer travels. Physical FAT findings may trigger contractual remedies, shipment holds, or joint root-cause reviews with higher stakes.
When both gates are planned together, sequence matters: run virtual FAT early enough that fixes ship in the PLC build customers will see on steel, not in a last-minute patch during physical week.
Use the comparison below when planning split responsibilities between engineering, quality, and the customer team. The goal is complementary coverage: not arguing which gate “counts more.”
| Dimension | Virtual FAT | Physical FAT |
|---|---|---|
| Primary purpose | Validate control logic, HMI flows, and sequences against agreed test cases | Verify the assembled machine meets contract specs on real hardware |
| Environment | Digital twin with soft or coupled PLC runtime; simulated I/O and motion | Build hall or customer site with installed utilities and real materials |
| Hardware required | Engineering PCs, PLC runtime, twin model; optional HIL for timing | Complete machine, tooling, product samples, safety systems commissioned |
| Typical timing | Weeks before ship; repeatable after each software release | Near shipment; limited windows for rework before logistics lock |
| Stakeholder access | Remote-friendly; many observers without travel | On-site capacity limits; shop-floor safety rules apply |
| Defect discovery | Logic, sequence, HMI, and procedural gaps surface early | Mechanical, sensor, environmental, and throughput issues dominate |
| Documentation output | Test logs, recordings, issue tracker exports; draft FAT evidence pack | Signed acceptance records, punch lists, formal deviation notes |
What should you test virtually vs. physically?
Run virtually first: mode changes, safety interlocks, alarm and acknowledge paths, recipe handling, HMI navigation, data logging triggers, and communication handshakes with MES or upstream systems when stubs exist. These defects are expensive to debug with customer observers in the room.
Include negative tests: wrong SKU selected, guard opened mid-cycle, communication timeout to upstream, and recovery after e-stop. Virtual environments make these repeatable without scrap or safety exposure.
Reserve physical FAT for what the model cannot represent faithfully: actual cycle time under load, pneumatic and vacuum behaviour, vision tuning, environmental EMI, guarding interactions, and material variability. Mark gaps explicitly in the test plan so virtual pass results are not over-interpreted.
Split the test plan into columns: virtual-eligible, physical-only, and hybrid. Hybrid cases might verify motion profiles virtually for collision risk, then confirm throughput on steel. Quality reviewers can sign each column without mixing standards.
Operator training fits the virtual column when procedure (lockout steps, acknowledge order, data entry) matters more than line speed. Run operators through fault scenarios on the twin before they touch the real HMI under pressure.
Document twin limitations beside each virtual case: simplified friction, ideal sensors, assumed upstream availability. Reviewers can then accept virtual pass with eyes open and schedule physical confirmation only where the assumption matters.
A useful rule: if the failure mode is primarily in software or procedure, virtual; if it depends on physics or installation, physical. Grey areas (motion profiles, precise timing) may need both, with HIL bridging the gap.
- Virtual: interlocks, sequences, HMI states, safety recovery, MES message flows
- Physical: throughput, mechanical wear points, real sensors, installed safety distances
- Both: document assumptions when the twin simplifies reality
How do you run a virtual FAT session?
Treat it like a formal meeting. Distribute the test plan and build revision in advance. Assign roles: operator on HMI, engineer on PLC, facilitator capturing results, and customer observers with a defined voice on pass/fail. Start with safety and mode checks before cycle demos.
Open with a twin fidelity statement: what is modelled accurately, what is stubbed, and which cases are out of scope. Two minutes here prevents hour-long debates when a test “fails” because physics was simplified.
A half-day session works for a scoped cell with ten to fifteen critical cases already scripted. A full-day session fits broader coverage, multiple recipes, or remote teams across time zones. Build in breaks for hotfixes and reruns: the advantage of virtual is fast iteration when a fix lands.
Use a visible scoreboard: cases passed, failed, blocked, deferred to physical. Blocked cases usually mean missing model fidelity or unfinished HMI, record the reason so physical FAT owners know what is coming.
For remote observers, share one camera on the HMI and one on the twin screen; lag is less important than synchronized narration of what was clicked and what the PLC did. Record the session even if everyone is live, timezone gaps will surface later.
After the session, publish a readout within one business day: pass/fail summary, open defects, and explicit list of cases deferred to physical FAT. Speed here builds credibility faster than perfect graphics.
Close with actions: open defects, owners, target dates, and which cases must repeat on hardware. Attach recordings or logs to the FAT pack so physical FAT opens with shared context instead of rediscovering the same issues.
What ROI can you expect from virtual FAT?
Payoff shows up as shorter physical FAT rework and fewer emergency trips. Teams that rehearse acceptance digitally often enter the build hall with a prioritized punch list instead of open-ended debug. Siemens has published customer examples where virtual commissioning reduced onsite time, outcomes vary by machine complexity and how rigorously tests are maintained.
Translate savings into line items your finance team recognizes: reduced standby days, fewer flights, less overtime on the build team, and lower probability of shipment delay penalties. A single avoided FAT extension can exceed the modelling budget on complex custom equipment.
Intangible gains matter too: customer confidence before shipment, smoother handover to service, and operators who have already seen fault flows. Those reduce support calls in the first production month even when the formal ROI spreadsheet stays conservative.
Compare against your last project’s FAT burn-down chart if you have one. Hours spent on logic versus mechanics tell you whether virtual FAT deserves a line in the quote template for the next bid.
Skip virtual FAT when the machine is trivial, acceptance is local and informal, or control code is frozen and proven from a prior identical build. The cost of modeling outweighs benefit if no one will maintain cases or attend sessions.
Estimate ROI from your own numbers: daily FAT cost, travel, rework hours, and delay penalties. Our impact calculator helps structure that conversation; published industry cases are benchmarks, not guarantees for your line.
Revisit the estimate after your first virtual FAT cycle. Real defect counts and rework hours from project one are the strongest input for quoting simulation on project two, stronger than any generic industry percentage.
See a digital commissioning test plan in practice
How one team linked virtual FAT scenarios to a structured test plan before install, and carried the same cases to physical acceptance.
Read the case studyFrequently asked questions
Is virtual FAT the same as a digital twin demo?
No. A demo shows capability; virtual FAT executes agreed test cases with pass/fail criteria. Demos skip edge cases; FAT rehearsals deliberately stress alarms, recovery, and mode restrictions. Without a written plan and logging, you get marketing value but not acceptance evidence. Treat virtual FAT as a disciplined run with roles, defects, and reruns: the twin is the test bench, not the deliverable. Customers should see the same cases they will sign off on physically, minus what only hardware can prove.
Does virtual FAT count as formal FAT?
Usually not unless your contract explicitly says so. Most purchase agreements define FAT on the physical machine with named witnesses and signature blocks. Virtual FAT produces preparatory evidence (logs, recordings, resolved issues) that makes formal FAT shorter and more predictable. Align with quality and the buyer early: which cases can be pre-accepted digitally, which must repeat on hardware, and how deviations are recorded. Clarity here prevents disputes when shipment dates are tight.
What do we need prepared before a virtual FAT?
Stable PLC and HMI builds, a frozen I/O or signal map for the twin, and a test plan tied to contract specs. Assign facilitators and observers, and confirm remote access if buyers join online. Prepare rollback if a critical fix fails: snapshots of PLC projects and twin versions save hours. Without a build list and test scripts, sessions drift into ad-hoc clicking. One day of preparation typically saves multiple days of physical FAT churn.
Can customers refuse to recognize virtual FAT results?
They can, and some quality systems require physical re-run regardless. Reduce friction by involving the buyer when you define which cases are virtual-eligible and how evidence is stored. Share recordings and issue closure status before they travel. When customers participate in virtual sessions, physical FAT often becomes confirmation rather than discovery. If recognition is uncertain, position virtual FAT as internal and customer-optional rehearsal with no claim on formal acceptance until contract language catches up.
How does virtual FAT interact with SAT on site?
Site Acceptance Test verifies install, utilities, and production context after shipment. Virtual FAT and physical FAT focus on builder-side readiness before or at ship. Carry forward unresolved virtual defects as explicit SAT risks if they could not be tested digitally. Conversely, SAT findings about foundation, feeding, or plant interfaces rarely belong in virtual FAT scope. A three-stage map: virtual, physical FAT, SAT, keeps each gate focused and stops one test type from being blamed for another's gaps.
Related reading
Start by copying your last physical FAT plan and highlighting cases that do not require real product or installed utilities. Those rows are your first virtual FAT scope. Run them once internally, fix what breaks, and invite the customer to the second pass: physical FAT should confirm, not surprise.
Open the ROI calculator