Bringing DevOps and AI to the Plant Floor

The plant floor is becoming software

For most of its history, industrial automation lived in its own world. PLC code was edited on a single engineering laptop, tested by hand, and “versioned” by copying a folder with a date in its name. Meanwhile, the software industry spent twenty years building version control, automated testing, and continuous delivery.

That gap is finally closing. The work I find most interesting right now sits exactly on that line — where operational technology (OT) meets modern software engineering. Three things I keep coming back to are AI tooling for physical hardware, substation automation, and DevOps for embedded and PLC work. They look like separate topics. They’re really the same shift.

AI tooling for physical hardware

Everyone is connecting AI assistants to codebases and documents. Far fewer people are connecting them to physical test benches — and that’s where it gets genuinely useful in automation.

A test rack is a messy place. There are devices to flash, networks to scan, logs to read, and a dozen small troubleshooting steps a human repeats every day. Most of that is structured enough for a language model to drive, if you give it the right tools.

The key is the Model Context Protocol (MCP) — a way to expose concrete, safe actions to an AI agent: “upload this firmware,” “scan the network for devices,” “pull and summarize the last test log,” “tell me why rack 3 isn’t responding.” The agent doesn’t magically understand your hardware. You hand it a set of well-defined tools, and it orchestrates them, reads the results, and explains what happened.

The lesson I’ve taken from building this kind of tooling:

• The model is the orchestrator, not the expert. Your engineering knowledge lives in the tools and their guardrails.
• Evidence beats confidence. Every useful result points back to a log line, a scan output, or a measurement — not a guess.
• Narrow actions, wide reach. A handful of reliable tools covers a surprising amount of daily troubleshooting.

This is the newest of the three themes, and the one with the least competition. Almost nobody is wiring AI agents to real industrial hardware yet.

Substation automation: rigor by necessity

If AI tooling is the frontier, substation automation is the discipline. When you integrate protection relays into a distributed control system over IEC 61850, there is no room for “we’ll fix it in production.” A misconfigured GOOSE message or a wrong dataset reference is found at the Factory Acceptance Test if you’re lucky — or on site, after a flight, if you’re not.

What that world taught me is the value of structure and validation before deployment:

• The system is described in standardized files (SCL), which means it can be checked mechanically, not just reviewed by eye.
• Factory Acceptance Testing forces you to prove communication, control logic, and visualization behave correctly before anything ships.
• Interoperability between vendors only works because everyone agrees on the same protocols and conformance rules.

Substation engineering already thinks the way good software teams think: define the system precisely, validate it automatically, and don’t trust anything you haven’t tested. The tooling is just less developed — which is exactly the opportunity.

DevOps for embedded and PLC work

Here’s the uncomfortable truth: automation engineering is roughly a decade behind software engineering on delivery practices. Many teams still build firmware or PLC applications by hand, test manually, and have no pipeline at all.

Bringing DevOps to this world isn’t about buzzwords — it’s about applying three boring, powerful ideas:

1. Version control for everything, including PLC projects and test code, so changes are traceable and reviewable.
2. Automated testing against real hardware. A Python-based framework can orchestrate end-to-end validation across physical test racks — exercising industrial protocols like PROFINET, DCP, SNMP, and LLDP — far more thoroughly and repeatably than manual signal-level checks.
3. Continuous integration and delivery. A pipeline on something like Azure DevOps can unify builds, deployments, and test execution into one workflow, so every firmware change runs through the same gauntlet automatically.

The payoff is the same one software teams discovered years ago: you catch regressions early, you increase test coverage without increasing effort, and the raw test data becomes something you can actually learn from — trends, defect analytics, flaky tests — instead of a pile of logs nobody reads.

Why these three belong together

The thread connecting all three is simple: treat industrial systems like software. Describe them precisely, test them automatically, deliver them through pipelines — and now, let AI agents take over the repetitive orchestration on top.

A concrete example of where this converges is co-simulation: coupling a professional power-system simulator with a real PLC controller over OPC UA, so control algorithms can be validated against a detailed grid model before anyone touches hardware on site. That’s substation rigor, software-style testing, and tooling for physical systems in a single project.

Industrial automation isn’t going to turn into web development. The constraints are real — safety, determinism, long equipment lifecycles. But the practices that made software reliable at scale are arriving on the plant floor, and the engineers who can speak both languages are going to be the ones building that bridge.

That’s the work I care about. If you’re doing something similar — or want help bringing test automation, CI/CD, or AI tooling into your industrial workflow — get in touch.