Most AI troubleshooting tools were designed for a demo, not a down line. What fault diagnosis actually requires, where AI genuinely helps, and the deployment constraints a real plant imposes.
A line is down, the fault on the HMI says almost nothing, and the person who knew this machine's habits retired in March. That is the situation AI troubleshooting tools claim to help with, and the honest answer is that some of the claim holds up and some of it does not. We have spent the last few years finding out which is which by running our system, Nexus, on real production floors. Here is where the line actually sits.
What Troubleshooting Actually Is
Strip away the tooling and PLC troubleshooting is a search problem under time pressure. The symptom is visible: a stalled conveyor, a valve that will not open, an alarm that keeps returning. The cause is buried somewhere in thousands of rungs of control logic, the live tag values, the interlock chain from an upstream machine, a change someone made two years ago, or a sensor drifting out of spec. The skilled engineer is doing recall and correlation: which rung drives this output, what is examining that tag, what changed, what does this fault pattern usually mean on this machine.
Every one of those steps is something a machine can be genuinely good at, provided it can actually see the operation.
Where AI Genuinely Helps
The wins we see in practice are specific:
- Tracing. Given a misbehaving output, walking the logic backward through every condition that gates it, across routines and controllers, in seconds instead of an afternoon of cross-referencing.
- Correlation. Connecting the supervisory data to the logic. The alarm history, the tag trends, and the rungs that produce them are usually three separate windows and one person's short-term memory. Reading them as one picture is exactly what software should do.
- Recall. The machine manual, the OEM drawings, the work orders from the last three failures. None of that is hard to store. All of it is hard to find at 2 a.m. with a line down.
- Explanation. Answering "why did this trip" in plain language, cited to the exact rung, so a newer technician can act on it without ten years of tribal knowledge.
Notice what is not on the list. The system does not decide whether to restart the line. It does not override an interlock. Our research position is that the division of labor should be explicit: the system handles recall and correlation, and people keep the consequential judgment. A diagnosis you can verify beats an action you have to trust.
The useful question is not "can AI fix my machine." It is "can it put the cause in front of a person fast enough to matter, with evidence attached."
The Constraints a Real Plant Imposes
This is where most tools designed in a demo environment fall over. A production floor imposes conditions that are not negotiable.
Answers must be exact and reproducible. A probabilistic guess about which rung caused a trip is worse than no answer, because chasing a hallucinated cause costs real downtime. Nexus is built as a deterministic engine: the logic is parsed completely, every answer is cited to the rung, and the same question returns the same answer. We validated the reading on 509 real PLC project files with zero parser errors, because the whole approach collapses if the reading is approximate.
It has to run where the plant runs. Defense, utilities, and pharma will not ship control logic to someone's cloud, and plenty of floors have no route out anyway. On premise and air-gap capable is the default shape, with the system keeping a persistent local memory of the operation.
It has to read what is actually installed. Real plants are cross-vendor. Studio 5000 next to a CODESYS machine under an Ignition SCADA layer is a normal Tuesday. A troubleshooting tool that reads one vendor's format diagnoses one fraction of your downtime.
What to Ask Any Vendor
If you are evaluating AI for troubleshooting, industrial or otherwise, the questions that separate substance from demo are short. Can it cite the rung, not just name a plausible cause? Is the answer reproducible? Does it run on premise? What was it validated on, and was that real production data or a synthetic benchmark? Who graded the output, and would they sign their name to it? For our part, the program documentation Nexus writes was graded rung-accurate on 137 of 137 documents by three independent Controls Engineers, and we publish that number because it is the kind we would demand from anyone else.
AI does not replace the engineer standing at the panel. Done properly, it hands that engineer the picture in seconds that used to take the whole shift to assemble. That difference shows up directly in downtime, and downtime is the only benchmark a plant actually cares about.