Factory and site acceptance testing: what each proves, and how to write a test that tests the design
Where the factory and site acceptance tests sit between design and start-up, what each can and cannot prove, how a test procedure is written so it tests the design rather than the code, the categories of test, how fails become punch items, and what has to leave each test for the next stage to start. With a free checklist template.
Key takeaways
- A factory acceptance test proves a system does what the specification says, at the vendor's works, against simulated inputs, before it ships. A site acceptance test proves it does the same thing installed, with the real field devices, power and networks.
- The two tests are not the same test run twice. The FAT finds design and configuration faults where they are cheap to fix. The SAT finds installation, wiring and integration faults, which the FAT cannot see.
- A test is only a test if the expected result was written down before it ran, from the narrative, the cause and effect or the specification. A procedure written from the code proves the code does what the code does.
- Every fail is a punch item with an owner, and the test is not accepted until the punch items that matter are closed and retested. A signed test record with open fails is a list of things the site will find later.
- What leaves each test matters as much as the result: the punch list, the as-tested configuration backup and the signed record are what the next stage starts from.
A control panel arrives on site, is installed and wired, and at start-up the belt drift trip stops the conveyor on one switch and not the other. The logic change was approved months ago. The vendor's test was passed. The problem was that the vendor's test was written from the vendor's program, which did not have the change, so it tested that the program did what the program did. Three days of a commissioning team's time went on finding that.
Acceptance testing exists to find that fault at the vendor's bench, where it costs an afternoon. The factory acceptance test proves the system as built does what the specification says, against simulated inputs, before it ships. The site acceptance test proves it does the same thing installed, with the real field, the real power and the real networks. They are different tests that find different faults, and a project that skips either pays for it at commissioning.
This guide sets out where the two tests sit between design and start-up, what each can and cannot prove, how a test procedure is written so that it tests the design rather than the code, the categories of test and what each covers, how fails are handled, what has to leave each test for the next stage to start, and the ways acceptance testing is commonly wasted. A checklist template comes with it. It sits beside the commissioning guide, which covers what follows the SAT.
Free download
FAT and SAT checklist template
A test record with the test, the method, the expected result written before the test and the actual result after, a pass or fail, the punch reference, who tested and who witnessed, eight worked rows from a conveyor control system's FAT and SAT, and the test categories and the stages on sheets of their own.
Where the tests sit
Both tests sit between the design being settled and process material being introduced, and each is the gate to the next stage's spending. The FAT gates shipment: nothing is paid for delivery, and nothing goes on a truck, until the system has done what the specification says in front of the owner's witness. The SAT gates commissioning: no process material goes near the plant until the installed system has done the same thing with its real inputs. IEC 62381 sets out both for automation systems in the process industry, and adds the site integration test for the interfaces between separately tested systems.
The tests only work if the documents they test against are settled first. A FAT procedure is written from the functional design specification, the cause and effect matrix and the IO list at an issued revision, and the first test on the list is that the drawings, the narrative and the software are at that revision. A test run against a draft is a test of a draft.
1Design review
Engineering office
The specification, the control narrative, the cause and effect and the IO list agree with each other and with the P&ID
Leaves behind
Reviewed documents at an issued revision, the test procedure drafted from them
2FAT
Vendor's works
The system as built and configured does what the specification says, tested against simulated inputs before it leaves the factory
Leaves behind
The signed test record, the punch list, the configuration backup taken at the end of the test
3Delivery and installation
Site
The system arrived as tested, was installed to the drawings and wired to the field
Leaves behind
Inspection and test records, the installation punch list
4SAT
Site, installed and connected
The system works with the real field devices, the real network, the real power and the other systems it talks to
Leaves behind
The signed test record, the loop check sheets, the punch list, the as-left configuration backup
5Commissioning
Site, with process material
The plant does what the design said under real conditions, system by system
Leaves behind
Functional and performance test records, the pre-startup safety review
Simulated inputs. A fault costs days
→ Real field, real network. A fault costs weeks, and the schedule is waiting
FAT and SAT side by side
The two are often described as the same test run twice, once at the factory and once on site, and that is the misunderstanding that wastes them. They have different inputs, so they can prove different things. The FAT has simulated inputs, so it can prove the design and the configuration and nothing about the installation. The SAT has real inputs, so it can prove the installation and the integration, and it repeats only the parts of the FAT that the installation could have changed. The table puts them side by side.
The last row is the one that justifies the travel. A fault found at the FAT is fixed at the vendor's bench by the people who built the system, with the test rig in front of them, that day. The same fault found at the SAT is fixed on site, by whoever the vendor can send, with the commissioning team waiting and the schedule slipping a day for every day of delay. Projects that skip the FAT to save a week's travel usually spend it twice at the SAT.
| FAT | SAT | |
|---|---|---|
| Where | The vendor's works, before shipment | On site, after installation |
| Inputs | Simulated: a test panel, a simulator or forced values | Real: the installed instruments, drives, valves and networks |
| What it proves | The system does what the specification says | The system does it here, connected to everything it has to work with |
| What it cannot prove | Anything about the field wiring, the site network or the other systems | Anything that needs process material, which waits for commissioning |
| Who witnesses | The owner's engineer, often with operations | The owner, operations and maintenance, often the vendor |
| What a failure costs | A fix at the vendor's bench, days | A fix on site with the schedule waiting, weeks |
| Leaves behind | A punch list and a configuration backup the SAT starts from | A punch list and the as-left backup that commissioning starts from |
The FAT proves the design. The SAT proves the installation. Neither can prove the other's part.
Writing a test that tests the design
A test has four parts: what is tested, how, what should happen, and what did. The third part is where procedures go wrong. The expected result is written before the test, from the design documents, in their words: the cause and effect says this cause produces these effects, so the test is to make the cause and check for each effect and for nothing else. If the expected result is written from the program, or filled in from what was observed, the test cannot fail and proves nothing.
That is also why the vendor does not write the procedure alone. The vendor's engineer knows the system. The owner's engineer knows what was specified and what has changed since. The management of change register is read before the procedure is finalised, because a change approved during the design that did not reach the vendor's program is exactly the fault the FAT exists to find. The columns of the test record are set out in the template, and the one that matters most is the expected result.
| Column | What goes in it |
|---|---|
| Test no. | Numbered within the procedure |
| System | The system or panel under test |
| Category | As it says |
| Test | What is tested, in one line |
| Method | How: what is forced, operated or measured, and with what |
| Expected result | From the narrative, the cause and effect or the specification, never from what happened |
| Actual result | What was observed, in the same terms |
| Result | As it says |
| Punch ref | The punch item raised for a fail |
| Tested by | As it says |
| Witnessed by | The owner's representative |
| Date | As it says |
| Comments | As it says |
The categories of test
A procedure runs through the categories in order, because each depends on the one before: there is no point testing logic until every input is proved to arrive at the right address, and no point testing the HMI until the logic behind it works. The table lists the categories, what each checks and how the FAT and the SAT differ on each. The IO check is the heart of the FAT and becomes the loop check at the SAT, when the simulator is replaced by the real switch at the tail of the conveyor and the real transmitter on the gearbox.
Two categories are the ones most often cut when time is short, and they are the ones that find the faults the site will otherwise meet at the worst moment. Failure modes: pull the network cable, kill a power supply, fail a processor over, restart from cold, and watch what the system does. Communications: the links to the historian, the DCS, the weigher and the drives, which the factory can only partly test and which the SAT exists to finish.
| Category | What is checked | At the FAT | At the SAT |
|---|---|---|---|
| Documents | The drawings, the narrative, the cause and effect, the IO list and the software are at the revision the test is written against | Yes | Yes, updated from the FAT punch list |
| Inspection | Panels, labels, terminations, earthing, segregation, spare capacity, against the drawings and the specification | Yes | Installation and field wiring |
| Power-up | Supplies, voltages, redundancy, failover of power supplies and processors, battery and UPS behaviour | Yes | On site power, with the real UPS |
| IO check | Every input and output on the IO list, end to end, at the right address, the right range and the right engineering units | To a simulator or a test panel | To the field device: the loop check |
| Logic and interlocks | Every cause in the cause and effect produces every effect, and nothing else | Yes, by forcing | Yes, from the field device where it can be done safely |
| Sequences | Start, stop, hold and restart sequences run as the narrative says, including the abnormal paths | Yes | Yes, with the real drives and valves |
| Alarms and trips | Each alarm at its setpoint, priority and message; each trip to its final element | Yes | Yes, and the trip timed where it matters |
| HMI | Graphics match the P&ID, every tag is on a display, navigation and permissions work, trends and the historian record | Yes | With the site displays and accounts |
| Communications | Links to other systems: the DCS, the historian, the MES, the drives, the weighers, the third-party packages | Only what can be brought to the factory | Yes, the main thing the SAT adds |
| Failure modes | Loss of power, loss of a network link, a processor failover, a bad input, a restart from cold | Yes | Yes, with the real network |
| Documentation | The manuals, the backups, the as-tested configuration, the licence records and the punch list handed over | At the end of the test | At the end of the test |
Fails, punch items and retests
A fail is not a problem. A fail is the test working. What matters is what happens next: every fail becomes a punch item with an owner, a category that says what it must be closed before, and a retest when it is closed. The punch list that commissioning will run from starts here, at the FAT, and the same categories apply. A fail that stops shipment is closed and retested before the system leaves. A fail that can be fixed on site without affecting the SAT is carried, with its owner and its date, and the SAT procedure includes the retest.
The record is signed when the procedure is complete, with every test marked pass, fail with a punch reference, not applicable with a reason, or deferred with a reason and a date. A signed record with open fails and no punch references is the record of a test that was stopped, not finished, and it is worth refusing to sign.
A fail at the FAT is the cheapest fault the project will ever find. Treat the fails as the product of the test.
What leaves each test
The result of a test is not a signature. It is a set of things the next stage starts from. From the FAT: the signed record, the punch list with its owners and dates, and the configuration backup taken at the end of the test, so that what was tested is what ships and what the SAT installs. From the SAT: the signed record, the loop check sheets for every IO on the list, the punch list carried into commissioning, and the as-left backup, which is the baseline the document control register holds and every later change is made from.
The backups are the item most often lost. A FAT passed on program version 1.5, a site where version 1.4 was loaded from a laptop, and nobody can say which is running. The configuration tested is named in the record, backed up at the end of the test, and the SAT's first test is that the configuration installed is the one the FAT passed.
Where acceptance testing is wasted
- A procedure written by the vendor from the program, so the expected results describe the code rather than the design.
- The FAT skipped to save a week, and the week spent twice at the SAT with the schedule waiting.
- Witnessed by nobody who will own or run the system, so the questions that matter are not asked.
- Failure modes and communications cut for time, which are the categories that find the faults commissioning will otherwise meet.
- Fails recorded as comments rather than punch items, so nothing has an owner and nothing is retested.
- The record signed with open fails and no plan for them.
- No configuration backup at the end, so what was tested and what was installed cannot be shown to be the same thing.
- The SAT run as a repeat of the FAT with the simulator still connected, proving nothing about the field.
Common questions
What is a factory acceptance test?
A test of a system, usually a control system, a switchboard, a drive or a packaged unit, carried out at the vendor's works before it is shipped, witnessed by the buyer, to prove that the system as built and configured meets the specification. Inputs are simulated, because the field is not there. It is the last point at which a fault can be fixed at the vendor's bench rather than on site.
What is a site acceptance test?
The test of the same system after installation on site, connected to the real field devices, the real power supplies, the site network and the other systems it has to work with. It repeats the parts of the FAT that the installation could have affected and adds what the factory could not test: the loop checks, the communications to other systems, the behaviour on the real network. It is the gate to commissioning with process material.
What is the difference between FAT and SAT?
Where they happen and what they can prove. The FAT happens at the vendor's works with simulated inputs and proves the design and the configuration. The SAT happens on site with real inputs and proves the installation and the integration. A fault found at the FAT costs a day at the bench. The same fault found at the SAT costs a site visit with the schedule waiting. That is why the FAT is worth the travel.
What is a site integration test?
A test, named in IEC 62381, of the connections between systems that were tested separately: the control system to the DCS, the drives, the historian, the MES, the third-party packages. On a small project it is part of the SAT. On a large one with many vendors it is its own stage, after each vendor's SAT, because no single vendor owns the interfaces between them.
Who should witness a FAT?
The owner's control or electrical engineer at least, because they will own the system for its life, and an operations representative where the HMI and the sequences are being tested, because they will run it. The test is witnessed, not performed, by the owner: the vendor runs the procedure and the witness checks each result against the expected result and signs it. A FAT witnessed by nobody from the owner is a vendor's internal test with a different name.
What does a FAT or SAT procedure contain?
A numbered list of tests, each with what is tested, how, the expected result written from the design documents, space for the actual result, a pass or fail, a punch reference for a fail, and who tested and witnessed it. The tests are grouped by category in the order they run: documents, inspection, power-up, IO, logic, sequences, alarms and trips, HMI, communications, failure modes and documentation. The template with this guide follows that shape.
Key terms
Plain-language definitions from our glossary for the concepts this article leans on.
Standards and further reading
- IEC 62381:2024 Automation systems in the process industry: factory acceptance test (FAT), site acceptance test (SAT) and site integration test (SIT) (IEC)
- IEC 62337:2012 Commissioning of electrical, instrumentation and control systems in the process industry: specific phases and milestones (IEC)
- IEC 62682:2022 Management of alarm systems for the process industries (IEC)
- ISA-101.01-2015 Human machine interfaces for process automation systems (ISA)
Related case studies and tools
- Operational readiness for a new plant asset (case study)
Related reading
Working through something like this?
See how we approach these initiatives, or tell us what you are dealing with.