Cengiz Özemli
Academic
- Thread Author
- #1
🤔 Communication Breakdowns: Technology or People?
A few months ago, one of our engineers went to a site, installed the OEM software, but no matter what he did, he couldn't establish communication. The reason? The physical cable between the APC server and the DCS was never connected! Such stories are still common for those of us who have been conducting integrated factory acceptance tests (IFATs) for over fifteen years to integrate and test controllers, OEM systems, and DCS platforms. Not because technology has gotten worse, but because it has gotten better. The remaining errors are almost always about people, not protocols.
✅ "See" the Preparation, Don't Just "Hear" It
The most common error we encounter is not hardware-related. The plant confirms that the equipment is on-site, communication has been tested, and every starting item has been closed. However, when the integration team arrives, they find that nothing has happened beyond the hardware delivery. A verbal confirmation is not the same as a demonstrated confirmation.
- Before committing a team's travel and schedule to a date, ask for a photo of the working communication link or a short demo call showing the logic live on the vendor's hardware. This costs an afternoon; skipping it costs a week.
🗓️ Treat IFATs as True Milestones
When these tests are managed as strict project milestones, rework is noticeably reduced. When treated as fluid (i.e., nice-to-do, informal steps), activities remain loose even after hardware ships, and this uncertainty resurfaces later as hidden configuration changes that no one approved.
- DCS logic is changed behind your own firewall between IFAT and commissioning more often than anyone would like. Scheduling pre-commissioning tests closer to the start narrows this gap. Treating the milestone as a milestone from day one closes this gap.
📊 When Two Systems Don't Match: Log File First, Then Opinion
Intermittent errors, erroneous values, and tags that stop reading are the hardest problems to catch in a fixed test window. They are also the fastest way for a technical problem to devolve into a stalemate over whose system is at fault. On one project, the values coming into our console seemed almost random compared to what was displayed on the DCS screen. The tag names matched, and understandably, the vendor didn't think it was their problem since their 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 demonstrate this, the vendor got engaged within hours. Lesson: Before a problem turns into a conflict, get the data that proves it's a shared problem, not two separate ones.
🏭 Always Conduct Acceptance Tests at Vendor Sites
This is the easiest point to state but practically difficult for some situations or customers. Doing IFAT at the vendor site brings together the most resources and support, but it has the disadvantage of everything being built on a dummy/ideal system. Doing it at the plant means testing on your actual network, with your own operators, but with less vendor support if something goes wrong. Ideally, you'd want to do both, but if we had to choose one, we'd choose vendor sites.
- The ownership and accountability you see at vendor sites are hard to replicate at customer sites.
In summary, technology has fixed decades of technical errors. OPC UA has replaced fragile DCOM connections, orchestration has replaced manual setups, and AI-powered troubleshooting now turns an cryptic error code into a specific next step in minutes instead of hours. What remains is entirely about how clearly your team, your integrator, and your vendors agree on who owns what before the equipment leaves the factory floor.
