You’ve drawn up an architecture. The diagrams check out, the protocols are chosen, the network segmentation is on paper. Everyone has signed off. And then you’re standing on the factory floor — it’s 7 degrees, the PLC isn’t talking to your broker, and the technician who wired the panel swapped the RS-485 A and B lines.
Welcome to commissioning :)
I have to be honest: for the major machine builders, this is no longer a surprise. A Siemens, a Rockwell, an ABB — they’ve standardised their FAT and SAT processes to the point where commissioning is familiar territory. Hundreds of projects, hundreds of engineers, hundreds of times making the same mistakes and capturing them in procedures.
But most projects that go wrong aren’t standard machine-build projects. They’re startups setting up their first production line and not yet knowing what a SAT involves. They’re unique trajectories: a control system for a specific process, an integration between a legacy PLC and a new SCADA platform, or a monitoring system that has to bridge three vendors and two protocols.
There’s no mature SAT template you can just pull off the shelf for those. You have to think through risks, prerequisites, dependencies and fallback yourself. And that’s exactly where things often go wrong.
Commissioning is the moment you discover whether you solved that puzzle correctly.
The most honest moment in any project
Commissioning and Site Acceptance Testing (SAT) are the most honest phases in a technical project. Not because they show how beautiful your design is — but because they mercilessly expose what you assumed.
Every architecture diagram is a model of reality. And every model leaves things out. That’s not a flaw, that’s the function of a model. But during commissioning you pay the bill for everything you left out.
The cable length that wasn’t an issue on paper, but turns out to be just too long for reliable signal integrity in practice.
The 24V power supply that reads only 22.3V after forty metres of cable run.
The sensor that, according to the datasheet, works fine up to 85°C, but whose housing can’t withstand the client’s weekly pressure wash.
It’s rarely the major design decisions that catch you out. It’s the preconditions that nobody stated because they were “obvious.”
Two worlds, one cable
The core problem when commissioning OT/IT systems is that you’re connecting two worlds that think fundamentally differently about time, failure and responsibility.
In the IT world, a connection is either up or down. If it’s down, you have redundancy, a fallback, or a retry. Deployment is usually reversible. You can do a rollback.
In the OT world, a valve is open or closed. A pump is running or standing still. A heater switches on or it doesn’t. And if you make the wrong call, steam escapes, a pipe freezes or a process stops. There’s no rollback for that.
During commissioning you’re standing exactly at that intersection. You’re not just testing whether systems work — you’re testing whether they work together, under conditions that neither world has fully specified.
I experienced this literally when commissioning a de-icing control system for the air intake of a power station. The system had to automatically control heating based on outdoor temperature and humidity, so that ice formation on the intake grille wouldn’t shut down the plant.
On paper it was straightforward: sensor reads conditions, controller calculates risk, actuator switches.
In practice I ran into something no architecture diagram had captured: the difference between the dynamics of the control system and the physics of ice formation.
The sensor responded in milliseconds.
Ice formation played out over minutes.
But the consequences of switching too late couldn’t be resolved in minutes.
Once ice was on the grille, you were too late. The heater therefore had to switch on before conditions became critical, based on a trend you had to recognise in the sensor data.
That insight wasn’t in the diagram. It only became visible when I was standing next to the intake grille with a moisture meter.
SAT is not a checklist, it’s a negotiation
Most SAT documents I encounter are structured as an elaborate tick-list.
Item 4.3.2: “Verify that the system generates an alarm on sensor failure.”
Tick. On to 4.3.3.
That’s not what SAT should be.
SAT is the moment when you, as the engineer, show the client: this is what you bought, and this is how it behaves in your environment, under your conditions.
That’s fundamentally different from working through a checklist. It’s a demonstration of understanding.
And it’s far from always about the technology. The hardest SAT moments I’ve experienced weren’t about systems that didn’t work, but about operators who didn’t trust the system.
Technically everything checked out. Data came through. Alarms triggered at the right thresholds. The integrations did what they were supposed to do.
But the people who had to work with it were used to their own way of looking at things, their own rhythm, their own information sources. A new system that showed technically identical data but presented it in a different way was, for them, an operationally completely different experience.
At that point the SAT shifts from “does it work?” to:
Do the users trust it enough to act on it?
That’s a question you don’t answer with a test protocol. You answer it by standing next to the operator, listening, and adjusting the system until it fits their way of working.
What no architecture diagram tells you
After enough projects standing on site with a laptop and a multimeter, a few patterns keep coming back.
Documentation lies, but not intentionally.
Everyone documents with the best of intentions. But documentation describes the system as designed, not as built.
During commissioning you discover every deviation: the technician who routed a cable tray differently because the original route was blocked by a pipe that wasn’t on the construction drawing. The PLC running a different firmware version than specified because that version was no longer available. The sensor mounted in a different location because the original position turned out to be inaccessible in practice.
None of those deviations is necessarily wrong. But each of them can delay your commissioning.
Don’t test the system, test the integration.
Every individual component has probably already been tested by the vendor. Your job during commissioning isn’t to verify that a sensor measures or a valve switches.
Your job is to verify that the entire chain works:
sensor → signal → controller → logic → actuator → physical effect → feedback
Every transition between components is a potential failure scenario. That’s what you focus your test scenarios on.
Bring a withdrawal plan.
Every commissioning protocol should have a “fallback” section.
If the new system doesn’t do what it’s supposed to, how do you return to the previous situation?
In IT that’s a rollback. In OT that’s sometimes literal: disconnect wires, reconnect the old system, operate manually until you’ve resolved the problem.
That plan needs to be ready before you start testing.
The client tests with you, or you fail.
Commissioning without the operator present is pointless. Not because you need their approval — that comes at the SAT — but because they know the preconditions that aren’t in the specification.
“That valve always vibrates a bit when pressure goes above 6 bar.”
“In winter, condensation forms on that sensor housing.”
“After a power failure you have to bleed that pump manually.”
That information isn’t in your P&ID. It’s in the operator.
The value nobody sees
Commissioning and SAT are phases that are often underestimated in project planning. They get scheduled as “two weeks of testing” at the end of a project, as a buffer that can be shortened when construction overruns.
That’s exactly backwards.
Commissioning isn’t a residual item. It’s the phase in which your design assumptions confront physical reality. And that reality is always richer, messier and more specific than your model.
Yes, that makes projects expensive. Especially with startups and first-time clients, you sometimes see the quote cause a shock.
Why am I paying three times as much for a sensor I can buy for ten euros at an electronics shop?
Why does the planning show three days of commissioning for a system with eight sensors?
Why does an engineer need to be there when everything has already been tested?
I have a boat, and you learn the answer to that quickly.
Every component on a boat seems to cost three to five times as much as the equivalent at a hardware store. A hose clamp. A switch. A length of line.
But when you’re at sea in bad weather, two-metre waves and an engine that has to get you back to harbour, you don’t want the cheap hose clamp that comes loose after six months of salt water. You want the component that’s specified, tested and suitable for those conditions.
In industrial systems it’s no different.
The sensor that costs three times as much isn’t just three times as expensive because it has a brand name on it. It’s more expensive because it’s delivered calibrated. Because the measurement uncertainty is documented. Because it comes with a traceable calibration certificate. Because the manufacturer guarantees it does what the datasheet says — even after years in an environment with vibration, dust, moisture and temperature fluctuations.
Those extra costs aren’t just in the component. They’re in the certainty that your commissioning won’t derail because hardware behaves differently than specified.
And the same applies to time.
Those three days of commissioning aren’t spent pressing buttons. They’re spent walking through the chain. Finding deviations before they become production problems. Recognising assumptions that were logical on paper but don’t hold on site. Bringing operators, vendors and client into one working reality.
Commissioning costs time — not because you designed badly, but because reality always has more dimensions than your model.
And commissioning costs money — not because engineers are expensive, but because you’re paying for certainty at the moment the system has to work.
The engineers who are good at this aren’t necessarily the best architects or the best programmers. They’re people who are comfortable with ambiguity. Who can read an error message on an HMI screen and simultaneously listen to the sound a pump is making. Who know when a deviation is a bug, and when it’s a characteristic of the installation that you have to respect.
It’s the least glamorous part of the trade.
No whiteboards.
No architecture diagrams.
No clean code.
Just you, a system, and the question:
does this work, here, now, for these people?
That’s the question that matters.