What a Factory Acceptance Test Should Actually Test

A factory acceptance test exists to move risk before the equipment moves. While the machine is on the builder's floor and the final payment is unpaid, problems are theirs. After it ships, they are yours — physically, contractually and in the schedule. Everything about how a FAT should be run follows from that, and almost nothing about how FATs are usually run does.

The typical FAT is a demonstration. The vendor runs the machine through the sequence it was designed for, using product they selected, on a network with nothing else on it, with the engineer who wrote the code standing at the keyboard. Everything works, everyone signs, and the failures are discovered on site three months later. Nothing was tested; something was shown.

A useful FAT tests the paths nobody wants to demonstrate. Disconnect the network mid-cycle and watch what the machine does — does it stop safely, does it queue, does it lose the batch record. Pull a sensor connector while it runs. Trigger the emergency stop mid-motion and then work through the full recovery procedure, because recovery is where machines actually cost you time and it is the part least likely to have been exercised. Cut power during a write to the recipe store and see whether the machine comes back knowing what it was doing. Fill the buffer. Start a cycle with no recipe loaded, with the wrong recipe, with a recipe half-edited by someone else at the same time. Feed it the deformed product, the double-fed sheet, the underweight fill.

Test the alarms as their own item, because they are software nobody wrote deliberately. Force every alarm on the list and check three things for each: that it appears with the right priority, that its text says what happened and what to do, and that it clears the way the documentation claims. An alarm list that has never been forced is a list of intentions.

Test the data path explicitly. Confirm the tag list matches reality name by name, that engineering units are what the specification says, that scaling is right at both ends of the range rather than only at zero, that timestamps are in the expected zone and resolution, and that the values actually arrive in the historian rather than only appearing on the HMI. It is much cheaper to discover a wrong scaling factor at FAT than to explain a year of bad data later.

Test the security posture while the vendor is still motivated to fix it. What is the state of the industrial PC — patch level, antivirus, what else is installed. Are there default credentials anywhere in the stack, including the HMI, the drives, the switches and the safety controller. What ports are open. How does the vendor expect to connect for remote support, and is that an inbound path you are willing to own. Who holds administrator rights after handover, and can you change the passwords without voiding support. These are much harder conversations after the machine is running production.

Test the documentation as a deliverable in its own right. Do the as-built drawings match the panel in front of you. Does the IO list match the terminals. Is there a spare parts list with real part numbers rather than internal assembly codes. And — the item most often skipped — take a complete software backup at FAT: PLC program, HMI project, drive parameters, safety configuration, vision recipes, licence files. Take it yourself, onto your own media, and verify you can open it. Vendors go out of business, engineers move on, and the backup nobody made is the reason a working machine becomes unmaintainable.

The punch list is the actual output. Every item numbered, described in terms of the acceptance criterion it failed, with an owner and a date, and each one classified as blocking shipment or not. That classification is a commercial decision as much as a technical one, and making it explicitly at the table is far better than discovering later that both parties assumed differently.

Site acceptance testing is not a repeat performance. FAT proves the machine works; SAT proves it works here — on the real utilities with real voltage dips, on the real network with real traffic, with the real product at real temperature and humidity, operated by the people who will actually operate it. Retest the interfaces to upstream and downstream equipment, because those are the joints a factory cannot simulate, and retest the emergency stop and recovery procedure with the maintenance technician performing it rather than the commissioning engineer.

Which raises the one decision that improves a FAT more than any test list: send the people who will live with the machine. The technician who will be called at two in the morning notices different things than the project engineer who will hand it over and move on — where the guarding blocks access to a filter, whether the fault code means anything, how long a belt change takes. Their objections are cheap to fix on the builder's floor and expensive everywhere else.

The blunt test of whether a FAT was worthwhile: it found something. A test protocol that passes every item on the first attempt did not probe hard enough, because no machine of any complexity is right the first time and the failures are still in there, waiting to be discovered by production.