A factory test can confirm that a control sequence works with simulated inputs. It cannot prove that every field cable has been installed correctly at the customer’s plant. Treating those two checks as interchangeable creates a gap exactly where the project changes hands.
Factory Acceptance Testing (FAT) and Site Acceptance Testing (SAT) should share requirements, but they serve different environments. Build the test plan around what can actually be demonstrated at each stage.
Separate the test environment from the acceptance decision
FAT normally takes place before delivery, at the supplier’s facility or another agreed test location. SAT evaluates the system after installation at the destination. Siemens describes the factory test as evidence that the system is sufficiently ready to proceed to installation and subsequent on-site testing in its validation guideline.
For your project, define whether a milestone authorizes shipment, installation, production trials, or final acceptance. These are separate decisions. A signed factory test with open site-dependent checks should make those conditions visible.
Use one requirements-to-test matrix
| Requirement | Possible factory evidence | Site-dependent evidence |
|---|---|---|
| Panel matches approved design | Inspection against drawings and BOM | Record installation changes and final configuration |
| Sequence behaves as specified | Tests with available equipment or documented simulation | Confirm behavior with installed process equipment |
| Field devices map correctly | Verify panel-side identification and simulated logic response | Verify actual device-to-terminal-to-program mapping |
| Process meets acceptance target | Trial using agreed representative conditions, if available | Trial under the agreed production and site conditions |
| Plant interfaces operate correctly | Interface tests against an agreed simulator or available system | Confirm actual upstream, downstream, and plant connections |
Give each requirement an identifier and retain it through the test sheets, issue list, and final record. This avoids the ambiguous statement that an item was “tested somewhere.”
Write test cases that another person can repeat
A useful test case records the starting configuration, action, expected response, actual result, evidence, and disposition. Include the software and drawing revision. If someone changes the program during testing, identify which cases must be repeated.
Suppose a simulated downstream conveyor is held “not ready.” The expected response might be a blocked transfer request and a specific operator message. Record that this was a simulated interface test. It does not establish that the real conveyor will send the correct signal or that its installation is ready.
Fault and recovery tests need particular care. Qualified personnel must plan physical tests under the site’s procedures; this article is a planning framework, not an instruction to bypass safeguards or energize equipment.
Give every open item a consequence
A punch list should include the issue, owner, due date, required evidence, and the milestone it blocks. “Open” alone is not enough. An unresolved drawing note may be handled differently from a missing protective function, but the authorized project team must make that classification.
Separate defects from new requests. If a requested HMI feature was absent from the agreed scope, track its commercial disposition instead of quietly changing the acceptance baseline. Conversely, calling a requirement a “future enhancement” does not close a failed test.
Plan the handoff before the meeting
Assign who can witness, record, and approve the tests. Confirm availability of representative parts, utilities, upstream and downstream equipment, and customer specialists. Agree how evidence is stored and who updates the final drawings and software backups.
The deliverable should be a traceable test record plus a controlled open-issues list. That package helps the site team see what has been demonstrated, under which conditions, and what still needs to be proven. It is far more useful than an unqualified “FAT complete” email.
