Before a control system or SCADA package leaves the integrator's shop and heads to site, there is usually one formal milestone where the customer comes to watch it work: the factory acceptance test. It is the checkpoint that catches problems while they are still cheap and easy to fix - in the shop, with the whole system on the bench - rather than expensive to fix later in a remote field cabinet. This guide explains what a FAT is, what actually gets tested, who attends, how a FAT protocol is written, what punch items are, and how it fits with the on-site test that follows.
Factory Acceptance Test (FAT) in one line: A factory acceptance test, or FAT, is a structured test in which the customer verifies a control system or SCADA package at the integrator's facility, before it ships, against an agreed procedure. The integrator sets the panels and software up on the bench, and the two parties work through a written protocol confirming that the hardware, logic, alarms, and displays behave as specified. Anything that does not pass is recorded as a punch item to be corrected, and a successful FAT is the customer's sign-off that the system is ready to ship.
A FAT exists to move discovery of problems as early as possible in the project. Once a control system is installed at a remote site, fixing a wiring error, a logic mistake, or a missing display means mobilizing people to the field, working in a cramped cabinet, and possibly delaying a startup that everyone is waiting on. In the integrator's shop the same system sits fully assembled on the bench with power, network, and engineering tools at hand, and a problem can be corrected in minutes with the right person a few steps away. The FAT deliberately concentrates the finding and fixing of defects in that favorable setting.
It is also a contractual and relationship milestone, not just a technical one. The FAT is where the customer formally confirms that what the integrator built matches what was ordered, and passing it is typically tied to a payment stage and to authorization to ship. Because both parties have a stake in the outcome, the test is run against an agreed procedure rather than improvised, so there is no ambiguity later about what was and was not demonstrated. A clean FAT gives the customer confidence to accept the system and the integrator a documented record that the work met the spec.
What a FAT can and cannot prove is worth being honest about. It verifies the system in isolation - the panels, the logic, the SCADA application - using simulated inputs rather than real field instruments and wiring. It cannot prove that the field devices are wired correctly or that the installed system works end to end, because those things do not exist yet at the shop. That is precisely why a separate on-site test follows later; the FAT proves the delivered package is internally correct, and the site test proves it works with the real plant.
The FAT works through the system against the agreed protocol, and the scope typically spans hardware, software, and the human interface. On the hardware side, the panels are inspected against the drawings, power-up is checked, and I/O is exercised - inputs are simulated and the system's response observed, outputs are commanded and confirmed at the terminals. On the logic side, control sequences, interlocks, and alarm conditions are forced and the system's behavior verified against the specification. On the SCADA and HMI side, displays, trends, alarm handling, navigation, and any reports are reviewed to confirm they present the process as designed. Communications between controllers, servers, and the operator interface are checked to confirm the pieces talk to each other.
Because field instruments are not connected, inputs are simulated - signal generators, switches, or software forcing stand in for real transmitters and contacts - so the test proves the system responds correctly to given inputs, not that the field will supply them correctly. That is a deliberate boundary of the FAT scope. The depth of testing is set by the protocol, which may call for demonstrating every point and every sequence, or a representative sample, depending on the criticality of the system and what the customer and integrator agreed.
Attendance usually brings the two sides together in one room. From the customer, the project engineer and often an operations or controls representative attend to witness the tests and make acceptance decisions. From the integrator, the engineers who built the system run the tests and address issues on the spot. On larger projects a third-party inspector or the end user's specialists may also attend. Having the decision-makers present is the point - questions get answered, judgment calls get made, and issues get agreed and logged as they arise, rather than debated by email weeks later.
A FAT is only as good as the protocol it runs against. The FAT protocol is a written document, agreed before the test, that lists each item to be verified, the steps to perform, the expected result, and a place to record the actual result and pass or fail. It is derived from the project specification and functional descriptions, so passing the protocol means demonstrating the agreed requirements. Writing it well - specific, testable steps with unambiguous expected outcomes - is what makes the test objective rather than a matter of opinion, and the completed, signed protocol becomes the permanent record of what was demonstrated.
Not everything passes on the first try, and that is expected. Items that fail, or that reveal something to correct, are logged as punch items on a punch list - a running record of open issues with enough detail to act on and a way to track them to closure. Punch items are triaged: minor ones may be agreed for correction before shipment or even at site, while significant failures may have to be fixed and retested before the FAT can be considered passed. The punch list is the honest ledger of the test, and clearing it is part of what completing the FAT means.
For a SCADA package in particular, the FAT is where the platform, screens, alarms, and data handling are proven before they meet the field. When that SCADA is a cloud platform such as Merobix, much of the FAT can exercise the real application - the actual dashboards, alarm configuration, and historical trending that operators will use - fed by simulated data, so the customer sees the genuine operator experience rather than a mock-up. Because a cloud platform is not a box being crated up, its configuration carries straight through to the site test and into production unchanged, so what the customer accepts at FAT is what they will run. The FAT then hands off cleanly to the on-site test, where the same verified system is checked against real field wiring and instruments before operations takes it over.
A factory acceptance test (FAT) verifies the system at the integrator's shop before shipment, using simulated inputs, to prove the delivered package is internally correct. A site acceptance test (SAT) verifies the same system after installation at the actual site, connected to real field wiring and instruments, to prove it works end to end in place. The FAT catches build errors early where they are cheap to fix; the SAT confirms the installed system before handover to operations.
Typically the customer's project engineer and often an operations or controls representative attend to witness the tests and make acceptance decisions, while the integrator's engineers run the tests and resolve issues on the spot. On larger projects a third-party inspector or the end user's specialists may also attend. The point of gathering the decision-makers is that questions get answered and issues get agreed and logged as they arise rather than debated later.
A punch item is an issue found during the FAT that needs correction - a failed test, a deviation from spec, or something to fix. Punch items are recorded on a punch list with enough detail to act on and tracked to closure. Minor items may be agreed for fixing before shipment or at site, while significant failures usually have to be corrected and retested before the FAT is considered passed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.