The part of the AI story that matters on the factory floor
For a PLC engineer, the phrase artificial intelligence can sound almost disconnected from everyday work. Production still has to start on time. Motors still need interlocks. Valves still need permissives. A safety circuit still has to behave predictably when everything else is having a bad day.
That is why the useful question is not whether AI will replace PLCs. It will not, at least not in the sense implied by the popular discussion around generative AI. The more useful question is where probabilistic software can sit around a deterministic control system without making the control system less safe, less understandable or harder to maintain.
Once the problem is framed that way, the picture becomes much clearer. AI is strongest where the plant already produces a lot of information but the information is difficult to interpret manually: quality deviations, repeated alarms, subtle process drift, large maintenance histories, free-text engineering documentation and relationships between variables that are difficult to encode as fixed rules.
A PLC and an AI model solve different classes of problems
A PLC is exceptionally good at executing a known logic sequence with well-defined timing and states. If a guard is open, the machine should not enter the hazardous state. If a pressure switch is below its permissive, the sequence should wait. If a servo has reached its position, the next step can proceed. Those are not statistical questions.
Industrial AI is much more comfortable with questions such as: Is this vibration pattern becoming abnormal? or Does this temperature profile look like previous batches that later failed quality inspection? There may be no single threshold that answers those questions reliably across all operating conditions.
This distinction suggests a sensible architecture. Deterministic control remains in the PLC or safety system. Data is exposed to higher layers through normal industrial interfaces. AI consumes selected data, builds context, produces a prediction or recommendation, and sends that information to a human or a supervisory application. The AI does not need to own the machine state to be useful.
Where PLC engineers will feel the change first
The first impact is usually not in the PLC editor. It appears in engineering work around the PLC: documentation, diagnostics, commissioning support, alarm analysis, data preparation and troubleshooting.
Imagine a plant with several hundred devices and a historian containing years of process data. A senior engineer can diagnose many problems because they have learned how the machine behaves. A junior engineer has the same tag list but not the same mental model. An AI-assisted diagnostic system can search historical patterns, combine alarm sequences with operating states and present a shortlist of likely causes. That does not remove engineering judgement; it makes the judgement easier to apply.
The same principle applies to program reviews. An LLM can explain a complicated Structured Text routine, point out suspicious duplication, draft documentation, or compare a software change against an existing coding convention. The engineer still decides whether the observation is correct. In a production environment, that distinction is fundamental.
The new engineering boundary: control, data and intelligence
Many plants have historically been discussed as two worlds: OT and IT. AI introduces a third practical layer that is neither a PLC program nor an ERP system. It is the data and intelligence layer connecting operational information to engineering decisions.
A useful mental model is:
- Control layer: PLCs, DCS, drives, I/O and safety systems. Deterministic, state-based, time-sensitive.
- Supervisory layer: SCADA, HMI, historians and alarm management. Contextual and operator-facing.
- Manufacturing layer: MES, batch records, genealogy, quality and production reporting.
- Intelligence layer: machine learning, statistical models, retrieval systems and decision support.
Keeping these responsibilities distinct makes architecture and validation easier. It also gives engineers a much more practical way to evaluate new AI products. Instead of asking whether a vendor has an AI feature, ask where the feature lives, which decisions it influences, what data it uses and how a human can override it.
Why deterministic thinking still matters
Industrial engineers tend to be skeptical of systems that behave differently on the same input. That skepticism is healthy. A machine-learning model can be very accurate and still occasionally be wrong in ways that are difficult to predict. The mistake is not using AI; the mistake is putting a probabilistic component in charge of a function whose acceptable behaviour is deterministic.
For example, an anomaly detector can flag a motor as unusual. It should not quietly change the motor command because the model has a high confidence score. A better design is to generate a diagnostic event, enrich it with operating context, and let an existing control or maintenance workflow determine the response.
The data engineering problem nobody gets to skip
AI projects in manufacturing are often described as modelling projects. Most of the hard work is actually data engineering.
Signals need stable naming. Units need to be understood. Timestamps have to be trustworthy. Equipment states must be reconstructed. Batch and order identifiers have to be correlated with process history. Maintenance records need to be aligned with sensor data. A temperature value sampled every second and a maintenance note written once a week do not magically become one dataset just because both are stored in the cloud.
PLC engineers are increasingly valuable here because they understand the meaning of the signals. They know which tag represents a command, which one represents feedback, and which one is merely a derived HMI value. That semantic knowledge is difficult to recover from raw databases.
What a good first project looks like
A sensible first project is usually narrow. Alarm rationalisation, a maintenance diagnostic, energy-pattern analysis or quality anomaly detection can all be good candidates because the output can remain advisory while the team learns.
A weak first project sounds like: “We want to use AI across the factory.” A stronger project sounds like: “We want to detect a specific failure pattern two hours earlier using the signals already available from these three machines.” The second statement gives engineers something they can validate.
Success criteria should include more than model accuracy. Measure false alarms, missed events, engineering time saved, operator acceptance, response time and maintenance impact. A 95% accurate model that creates 200 unnecessary alerts a day is not a successful industrial system.
What PLC engineers should learn next
The most useful transition is not from PLC programming to becoming a full-time data scientist. It is learning enough data and AI engineering to understand the entire chain.
Python, SQL, time-series analysis, basic statistics, model evaluation, API concepts and data visualisation provide a strong foundation. On the industrial side, OPC UA, MQTT, historians, MES concepts and good tag semantics remain important. An engineer who understands both worlds can ask better questions than someone who knows only the algorithm.
The practical future is therefore not “PLC engineer versus AI.” It is the engineer who understands why a PLC behaves deterministically, why a model behaves probabilistically, and how to connect the two without confusing their roles.