Machine Learning, Deep Learning and AI in a Plant: What the Words Mean

Three words used as if they were one

Artificial intelligence is the broad field. Machine learning is a way of doing it, in which a program improves at a task from examples rather than from rules somebody wrote. Deep learning is a kind of machine learning that uses neural networks with many layers, and which happens to be very good at images, sound and language.

So: all deep learning is machine learning, all machine learning is AI, and most of the AI in a factory is neither exotic nor new.

That framing matters because vendors use the words interchangeably in sales material, and an engineer who cannot tell them apart cannot tell an appropriate solution from an expensive one.

Rules or examples

The useful question on a plant is not which technique to use. It is whether the problem should be solved with a rule at all.

If you can write the rule, write the rule. "Trip the motor if the current exceeds this value for this long" needs no learning of any kind, and a PLC will do it deterministically and forever. Most of what a plant does is like this, and it should stay like this.

Learning earns its place where the rule is genuinely unknown or unwritable. Nobody can write the rule that distinguishes a good weld from a bad one in an image. Nobody can write the rule for when a particular bearing on a particular machine is about to fail, because it depends on that machine's history.

That is the line. On one side, control. On the other, judgement about patterns.

What machine learning solves here

Predictive maintenance. You have vibration, current and temperature on a motor, and a maintenance history. A model learns what the weeks before a failure looked like and flags the pattern when it recurs. This is the most common industrial application and the most oversold: it needs a lot of run-to-failure history, and most plants do not have it. Anomaly detection, which only needs to know what normal looks like, is often the realistic version.

Quality prediction. Process parameters in, likely defect rate out. Useful where the test is destructive or slow.

Energy and yield optimisation. Recommending setpoints that a person then approves. Note the person: on a running plant, models advise far more often than they act.

What deep learning solves here

Almost entirely perception.

Vision inspection is the big one. Surface defects, print verification, presence and absence, assembly completeness. Where classical vision needs a fixed and predictable scene, a trained model copes with variation, different lighting, slightly different positions, defects that do not look identical.

Reading things. Serial numbers, batch codes, labels, gauges on old equipment with no digital output.

Acoustic monitoring, which is closer to research on most sites but does work.

A useful reality check: classical rule-based vision is still the right answer for a great many inspection tasks, and it is cheaper, faster and easier to justify to an auditor. Reach for deep learning when the thing you are looking for genuinely varies.

Where an automation engineer fits

You are not being asked to become a data scientist. You are being asked to be the person who makes these systems work on real plant, and that is a distinct job.

It involves getting the data out in the first place, at a sample rate that means something, with timestamps that line up. Most industrial machine learning projects fail here rather than at the model.

It involves knowing which signals matter, because you understand the process and the data scientist does not.

It involves integration: the model produces a result, and something has to act on it. A reject gate has to fire, an alarm has to be raised, a value has to reach the historian. That is PLC and SCADA work.

And it involves knowing what to do when the model is wrong, because it will be. What happens to a part the vision system is not confident about? Where does it go? Who looks at it?

What to actually learn

Python, to the point where you can load a CSV, plot it, and be suspicious of it. Not to the point of writing frameworks.

Enough statistics to know why a model that is right 99% of the time can still be useless when one part in a thousand is defective.

How to get data off a PLC properly, OPC UA, MQTT, a historian, because this is the part you will genuinely own.

One vision system, hands on, end to end: camera, lighting, trigger, result, and the PLC that acts on it. Lighting will teach you more than the model does.

Enough understanding of training and validation to ask whether a vendor tested their model on data it had already seen. They often have.

The claim to be sceptical of

Anything promising a model will run your process better than your operators, with no history, no integration work and no changes to your instrumentation.

The plants getting real value from this are doing narrow, well-defined things: one inspection station, one critical asset monitored properly, one quality parameter predicted early enough to matter. They got there because somebody understood both the process and the data, and that person is usually an automation engineer who learned some machine learning, rather than a machine learning specialist who learned some plant.