Electronic Components
Stay ahead of the storm
Industrial Automation
Industrial Automation at your fingertips
Source: Andrey Popov/stock.adobe.com
When an automation project runs into trouble during commissioning, the first instinct is usually to look at the controls: the logic, sequencing, I/O, wiring, drive behavior, network configuration, or software. That instinct makes sense—controls are tangible, testable, and present when the problem appears. But in practice, many commissioning issues blamed on control engineering actually originate much earlier.
This blog explores how experienced industrial automation teams reduce commissioning risk by proving key assumptions early, designing for support, aligning operational technology (OT) and information technology (IT), and preparing operators before the project ships.
I started as a programmer at B&R Industrial Automation, now part of ABB, and spent more than 24 years moving between technical and management roles across the industrial automation ecosystem. Technical execution matters enormously.
In my experience, many project outcomes are shaped long before commissioning begins. The teams that consistently deliver successful projects are not necessarily those with the strongest control engineers. More often, they are the teams that got the coordination right early, surfaced risks while they were still inexpensive to address, and designed beyond the narrow goal of “passing startup.”
By the time a technician is troubleshooting on the floor, the controls often reveal only a problem that started months earlier: an assumption that was never documented, a tradeoff that was never confirmed with the people affected, or an agreement that existed only at one level of the organization. When the coordination tasks are executed effectively, commissioning is mostly a verification exercise. When it is not, commissioning turns into discovery, and discovery at that stage is typically more expensive because it adds field labor, rework, production delay, and prolonged stabilization on top of the engineering effort already invested.
I learned this lesson early in my career. At a project kickoff, we discussed having a machine “running by summer”. Within the engineering group, that meant the motion layer: axes tuned, movements verified, and a stable platform ready for application code. To the customer, however, it meant something closer to a first usable version of the machine, with sequences implemented and the process functioning in a recognizable way.
Both interpretations were reasonable, and both groups spent months believing the project was on track. The gap surfaced only when the schedule tightened, and expectations were compared directly. What looked like an engineering delay turned out to be a coordination failure that had started in the very first conversation. The phrase "machine running" had meant two different things to two groups of professionals, and nobody had made either interpretation explicit.
The cost was real. The engineering team faced the consequences of a misunderstanding that was not their fault. The schedule had not slipped because the work was poorly executed. It slipped because the milestone meant different things to different people, and that was never made concrete while it was still cheap to fix.
Small, aligned teams often resolve expectation mismatches and misunderstandings naturally through their day-to-day interactions. The person implementing the solution hears service concerns directly, while the person interacting with the customer understands the engineering team’s priorities and constraints. As a result, assumptions surface and are corrected while they are still easy to address.
Large projects tend to lose this advantage. Management talks to management, engineering talks to engineering, and operations enters the discussion later than it should. Everyone may leave a meeting believing there is alignment, but each group is carrying a slightly different version of the same decision. Nobody has to be careless for this to happen. The agreement exists at too high a level. Beneath it sit multiple versions of the same decision, each internally consistent and quietly incompatible. The challenge in a large project is to deliberately create the shared understanding that small teams develop naturally through everyday interactions. In my experience, four areas make the greatest difference in preventing misalignment across project teams and reducing risk before commissioning even begins:
The first area is strategic governance. The teams that handle strategic governance well start every project with an honest accounting of what they do not yet know. Not what they need to build, but what they need to prove. These are different questions, and failing to distinguish between them is one of the most common causes of late-stage rework. For most projects, the unknowns that matter most are the ones where being wrong is most expensive: new process behavior, unproven control strategies, integration constraints, and throughput assumptions. When one of these turns out to be wrong late in the project, the fix usually requires revisiting decisions that the rest of the work was already built around. A shared list of what the team must prove, in priority order, makes those unknowns visible early and forces a clearer conversation about what is known and what is still being assumed.
The same discipline applies to planning for the Factory Acceptance Test (FAT) and the Site Acceptance Test (SAT). Well-run projects decide early what will be verified at FAT and what will be explicitly deferred to SAT or startup. That clarity prevents risk from quietly migrating downstream with the schedule while strengthening the supplier-customer relationship, because both sides agree on what “ready” means before testing begins.
When this step is skipped, the problems are predictable. A line may be mechanically complete before anyone proves the process can sustain the required throughput. A control sequence may work in simulation but fail when real device timing, network load, or the behavior of upstream and downstream equipment is introduced. These are not just technical misses. They are issues that could have been identified earlier but remained hidden until they became far more expensive to resolve.
The second area is operational continuity. The teams that get operational continuity right bring service and maintenance into the design conversation early, not as reviewers but as sources of requirements. The service and maintenance questions that determine whether a machine is supportable must be addressed during design, because addressing them later usually means revisiting decisions already embedded in the system.
The operational continuity questions are specific. Can the machine be diagnosed remotely? Does the event history provide enough context to explain what caused a fault, not just that one occurred? Can maintenance isolate a problem in the human-machine interface (HMI) without contacting the original equipment manufacturer (OEM)? What will a technician see when something goes wrong, and will it guide them to the fault or merely indicate that something is wrong?
Mechanical teams usually ask these questions naturally. They consider access panels, replacement procedures, and component layout because those concerns are visible during design. In controls and software, the equivalent thinking is easier to skip precisely because the gaps remain invisible until the machine is in production.
The economics make early engagement worthwhile. Up to the point when the machine leaves the facility, mistakes primarily cost engineering time. After that, they can lead to production downtime, emergency support, site visits, and lost customer trust.
A machine that passes every functional test can still generate excessive support calls if the diagnostic pathway is unclear. The operator sees one alarm, maintenance sees a different symptom, and support receives a description based largely on guesswork. At that point, a seemingly minor design decision becomes an ongoing operational cost.
The third area is technical resilience. Teams that manage it well treat OT and IT alignment as a design requirement rather than an integration task. They bring the right people from both sides into the same conversation before architecture choices are finalized, because the cost of misalignment rises sharply once those choices are locked in.
OT teams optimize for uptime and recoverability, while IT teams optimize for control, security, and manageability. These perspectives are not incompatible, but they lead to different architectural choices when developed in isolation.
When an OT team designs around a flat network topology for fast recovery and IT enters the conversation only after the architecture is committed, the machine may still be commissioned on time. But if segmentation is then required for security compliance, reliable software updates to field controllers can take months to resolve after handoff. The system worked at commissioning, but it becomes harder to update, secure, and support over its operating life.
From a project standpoint, the requirement is straightforward: the system must be updatable, diagnosable, and supportable after deployment, not just functional at commissioning. This means version control, configuration baselines, diagnostic logging, and audit trails must be treated as design requirements from the start, not as documentation tasks at the end.
The practical shift is to treat OT/IT alignment as a project deliverable alongside the controls work, with clear owners and explicit readiness criteria, rather than leaving it to the two sides to resolve after the architecture is finalized.
The final area is adoption and sustainment. Well-run projects plan for operational handoff long before commissioning. The people who will run and maintain the system are part of the conversation before the design is finalized. Training focuses on the failure conditions most likely to occur in the field, not just on normal operation. Documentation reflects the software version that was actually released. Alarm messages provide the context a technician needs to act, not just a fault code.
The standard for holding the project to is not simply “does the machine work?” but “can the people responsible for it run it, troubleshoot it, and recover from failures without calling the project team?” These are different questions, and delivery pressure reliably leads teams to answer only the first.
In practice, the things that matter most here are often unglamorous: consistent alarm classes that help operators and maintenance personnel assess urgency, fault presentation that guides a technician to the problem rather than simply indicating that something is wrong, naming conventions that match what operators see on screen, and displays that provide enough context for technicians to understand the machine’s state without having to make a phone call. None of these are technically difficult. They become expensive only when treated as finishing details rather than as design requirements.
What helps most is usually simpler than teams expect, and most of it can be set up at the start of the project.
The single most useful habit is to write down assumptions. Every project runs on assumptions that everyone believes, but no one has documented. A shared list, with an owner and a review date for each item, makes them visible before they harden into commitments. It also shows that, while the cost of acting is still low, some beliefs are well-founded while others have never really been tested.
The same discipline applied to decisions helps just as much. A brief record of what was decided, by whom, and what must remain true for it to hold prevents those decisions from being quietly re-litigated as people change or the project evolves.
Two practices are especially worth establishing from the start because teams often leave them too late. The first is the test specification. Early in my career, our team shipped a new software version for a machine. We had done real engineering work: updates, feature changes, and improvements. Then the machine would not start. Not figuratively. The start button did not work. We were focused on what had changed and lacked a test specification that forced us to verify the most fundamental expected behavior first. Something everybody knows is often the very thing nobody explicitly checks. That experience is why the test specification matters.
A test specification should start with the most fundamental expected machine behavior: the start button, the stop command, and the basic cycle, then build outward from there. Not because advanced behavior does not matter, but because basic behavior is exactly what everyone assumes has already been verified, even when it has not.
The second is traceability. Before the machine goes to the site, the team should be able to clearly state which software version is running, which configuration was deployed, and what diagnostic data will be available if something goes wrong in the field. If those answers require a search, field support will rely on guesswork rather than on evidence.
This approach is not about replacing engineering with process. It is about equipping engineers, operators, service teams, and customers with the information they need to make good decisions while keeping the cost of those decisions manageable.
Every project runs on assumptions. What usually separates a manageable project from a painful one is when those assumptions are tested.
Found early, there are tradeoffs.
Found at commissioning, they are reworked.
Found in production, they become a cost, a delay, and a support burden.
The projects that go well are not the most formally managed or the best documented. They are the ones where the right people talk to each other early, before designs are finalized, before commitments are made, and before the machine leaves the building.
That is how a large automation project begins to operate more like a small, aligned team. The useful question on every project is not just what might go wrong at commissioning, but what needs to be known early enough to keep the project on track.
Patric Thysell is an independent industrial automation consultant working at the intersection of software, systems, and people. With 24+ years in the B&R automation ecosystem, he helps teams simplify complex IT/OT environments, reduce platform complexity, and improve reliability. He focuses on practical solutions that work in real-world operations. You can connect with him at thepassionateprogrammer.com.
