PLC to Model: Where Industrial AI Actually Breaks

Mostafa Dhouib·September 7, 2026·7 min read

PLC to Model: Where Industrial AI Actually Breaks

The short answer. Industrial AI projects rarely fail at the model. They fail in the path between the controller and the model, and that path has four properties nobody owns: the controller behaves as it implements the protocol rather than as the standard describes, the loop deadline includes the protocol round-trip, the equipment cannot be taken out of service to investigate, and the boundary sits between an automation team and a data team who each stop at it.

A vision or maintenance system on a factory floor is usually presented as a machine learning project. It is mostly a systems project with a model at one end.

Here is where it actually breaks, in the order the failures show up.

One: the controller implements the protocol, not the standard

Modbus is a specification. What is on your floor is a vendor's implementation of it, and those are different objects.

Register maps that do not match the documentation. Word ordering that differs between vendors for the same 32-bit value. Coils that read back a state different from what you wrote. Function codes that are documented but return an exception. Off-by-one on register addressing, which is close to a tradition. Behaviour on a malformed request that ranges from a clean exception to silence to a device that stops responding until it is power-cycled.

Code written from the standard works on the bench and fails intermittently against the real controller. And "intermittently" is doing a lot of work in that sentence, because the failures cluster under load and during specific operations, which is precisely when investigation is hardest.

The practice that works: treat the device as the specification. Read every register you intend to use, on the actual unit, and record what came back. Write down the observed behaviour rather than the documented behaviour, and keep the record with the code. That document is the most valuable artifact in a floor integration and it almost never exists.

Two: the round-trip is inside the deadline

A control loop has a deadline. If the model is inside that loop, the protocol round-trip is inside the deadline too, and that is frequently discovered after the model has been chosen.

The budget is not the inference time. It is: read the inputs over the protocol, plus whatever the controller's scan cycle adds, plus preprocessing, plus inference, plus post-processing, plus the write back, plus the controller's next scan before the write takes effect. On a busy link with other masters, add contention.

Two failure modes follow, and they look completely different from each other.

The deadline is missed occasionally. Under load, or when another master is active. This presents as a system that mostly works, which is the hardest kind to get taken seriously.

The deadline is met by the model and missed by the loop. Everyone measures the inference and it is comfortably inside budget. The loop still misses, because nobody added up the other six terms.

The fix is to measure the whole path end to end from the beginning, before anything is chosen, and to hold a written budget with one owner. That is the same discipline as an edge latency envelope: the budget exists first and constrains the design, rather than being validated after.

Three: you cannot take it out of service

The investigative move that works everywhere else, take it offline and reproduce, is unavailable. The equipment is producing.

That constrains diagnosis in ways that are worth planning for rather than discovering.

You get one attempt per maintenance window. So the value of a hypothesis is not just whether it is right, it is whether the window will distinguish it from the alternatives. Plan the window to produce a decision, not to try a fix.

Passive instrumentation is worth more than active testing. A tap on the link that records every transaction, timing included, costs nothing in availability and answers questions you have not thought to ask yet. This is the highest-return thing to install on day one, before there is a problem.

Shadow mode is available and underused. Run the new logic alongside the live one, reading the same inputs, writing nowhere. You get production conditions with no production risk, and the comparison against what the live system did is the evidence you cannot otherwise obtain.

Four: the boundary belongs to nobody

The structural problem, and the one that consumes the schedule.

The automation team owns the controller and stops at the network boundary. The data team owns the model and starts at the data it receives. Between them is the protocol layer, the timing, the units, and the failure semantics, and it is the third party in a two-party arrangement.

You can hear it in the status updates. "We send the values correctly." "We process what we receive correctly." Both true, both competent, and the failure is in the space neither described.

The rows that break floor integrations most often, all of them at this boundary:

Units and scaling. A controller reporting tenths of a bar and a model expecting bar. Both sides correct, the number wrong by ten.

Word order. A 32-bit float read with the words swapped produces a plausible number, not an error. Plausible is the problem.

Stale versus fresh. A read that returns the last value on failure, so the model receives a valid-looking number that describes a moment that has passed. Nothing raises.

Timestamp alignment. Two signals read in separate transactions and treated as simultaneous. At speed, they are not.

Failure semantics. What the read returns when the device does not respond. If the answer is a default, the model consumes a default, and the fallback path is silent by design.

The last one deserves a counter of its own. How many times yesterday did a read fail and return a default? If nobody knows, that is the finding, and it is an hour of work to change.

What to do first

Install the passive tap before you need it. Record every transaction and its timing. When something goes wrong, you have the evidence rather than a maintenance window and a guess.

Write the observed-behaviour document. Every register you touch, what it actually returned, on the actual unit.

Count the fallback reads. One number, an hour of work, and it changes what people believe about the system more often than any other single measurement.

Own the boundary explicitly. One party accountable for the agreement between the controller and the model, with authority to change either side. Not the automation team, not the data team, and not a coordination meeting between them.

That last one is the whole argument for how industrial automation work should be structured. The engineering across the sensor, the control law, the timing, and the protocol is not exotic. The failure is that it is usually split across parties who each stop at the line where the problem lives.

FAQ

Why do industrial AI projects fail? Usually not at the model. They fail in the path between the controller and the model: protocol implementations that differ from the standard, a loop deadline that includes the round-trip, equipment that cannot be taken offline to investigate, and a boundary that neither the automation team nor the data team owns.

Why doesn't Modbus code written from the specification work? Because the controller implements the protocol as the vendor built it. Register maps differ from documentation, word ordering varies between vendors, coils read back differently from what was written, and malformed-request behaviour ranges from a clean exception to a device that needs power-cycling. Treat the device as the specification.

What belongs in an industrial control loop timing budget? The protocol read, the controller's scan cycle, preprocessing, inference, post-processing, the write back, and the next scan before the write takes effect, plus contention if other masters share the link. Inference time alone is a small part, and measuring only that is how loops miss deadlines that everyone believed were met.

How do you diagnose a system that cannot be taken offline? Install a passive tap that records every transaction with timing, which costs nothing in availability. Use shadow mode to run new logic against live inputs while writing nowhere. Plan each maintenance window to produce a decision between hypotheses rather than to try a fix.

What is the most common silent failure at the PLC boundary? A failed read that returns a default or the last value instead of raising, so the model consumes a plausible number describing a moment that has passed. Counting how often that happened yesterday is an hour of work and frequently the whole finding.