One of our engineers showed up on site few months ago, installed the OEM software, and could not bring up communication no matter what he tried.

The reason turned out to be almost impossible to guess from a spec sheet: the hard cable between the APC server and the DCS had never been physically connected!

We’ve run integrated factory acceptance tests (IFAT) for combining and testing controllers, OEM systems, and DCS platforms for over fifteen years, and stories like that one are still common. Not because the technology got worse. Because the technology got better. The failures that are left are almost always about people, not protocols.

Here’s what we’d tell any new SI engineer, manufacturer, or processor gearing up for one.

Ask to ‘see’ readiness, not just hear about it 

The most consistent failure we see has nothing to do with hardware. Many times, a plant confirms that the equipment is on site, communication has been tested, and every kickoff action item is closed. The integration team arrives and finds that none of it, aside from maybe the hardware delivery, actually happened. A stated confirmation and a demonstrated one are not the same thing. 

Before you commit a team’s travel and schedule to a date, ask for a photo of the running communication link or a short demo call showing the logic live on the vendor’s hardware. It costs an afternoon. Skipping it costs a week.

Treat the IFAT as real milestones, not flexible checkpoints 

Where these tests are managed as firm project milestones, rework drops noticeably on the back end. Where they’re treated as fluid (essentially nice-to-do informal steps), activities stay loosely defined even after hardware ships, and that ambiguity resurfaces later as hidden configuration changes nobody signed off on.

The DCS logic touching your control system gets modified behind your own firewall between the IFAT and commissioning more often than anyone would like. Scheduling pre-commissioning closer to startup narrows that gap. Treating the milestone as a milestone from day one closes it.

When two systems sisagree, get a log file before you get an opinion 

Intermittent faults, errant values, and tags that stop reading are the hardest problems to catch inside a fixed test window, and the fastest way for a technical issue to turn into a standoff over whose system is at fault. On one project, values arriving at our console looked almost random against what the DCS screen showed. Tag names matched, and understandably, the vendor didn’t think it was their problem, since their own screen looked correct.

What changed the conversation was reproducing the exact behavior across independent tools and putting it in front of them. Once we could show it, the vendor engaged within hours. The lesson: before an issue becomes a conflict, get the data that proves it’s one shared problem, not two separate ones.

Always run the acceptance tests at the vendor sites 

This should be the easiest point to make, but practically hard for certain cases or customers. Running the IFAT at the vendor site puts the most resources and support in the room, with the tradeoff being everything is built on a dummy/ideal system. Running it at the plant means testing on the real network you’ll actually operate, with your own operators in the room, at the cost of thinner vendor support if something goes wrong. Ideally, you want to be able to do both, but if we had to pick one, it would be the vendor sites. 

The ownership and accountability that you see at vendor sites is hard to replicate at client sites. 

In summary, the technology fixed a decade of technical failures. OPC UA replaced brittle DCOM connections, sequencing replaced manual installs, and AI-assisted troubleshooting now turns a cryptic fault code into a specific next step in minutes instead of hours. What’s left is entirely about how clearly your team, your integrator, and your vendors agree on who owns what before the equipment ever leaves the factory floor.