Version Control and HIL for PLC Code

The situation

For years the plant's controls logic lived where most controls logic lives: on the laptop of whoever last touched it. No version history, no second set of eyes before a change went in, and no real way to test logic except on a running controller. When something broke, working out what changed and when came down to memory. The team knew the risk and wanted the same safety net software developers have taken for granted for two decades.

The defect

The real gap was not a missing tool, it was a missing process. A change could go straight from an idea to a live PLC with nothing in between - no review, no record, no clean way back. Two engineers could edit the same logic and quietly overwrite each other. And because the only place to run code was the actual plant, testing often meant watching the process and hoping. On critical infrastructure, that is a lot of trust placed in memory and good intentions.

What we engineered

• Stood up CI/CD pipelines for PLC code on self-hosted AWS runners, so builds and checks run automatically on every change.
• Moved controls logic into GitHub-based review, giving every edit an author, a history, and a second engineer's sign-off before merge.
• Adopted Copia for controls version control, built for the file formats PLC platforms actually use.
• Added hardware-in-the-loop simulation so each change is proven against a simulated plant before it reaches a live controller.
• Wired in read-back verification to confirm what landed on the controller matches what was reviewed.

The result

Controls changes now move through the same discipline as modern software. Every edit is recorded, reviewed, and tested against a simulated plant before it touches production, so mistakes get caught on a laptop instead of on the grid. The team can see who changed what and step back cleanly when they need to. It is the clearest example of an idea SCADADOG keeps coming back to: the practices that made software reliable belong in the controls world too.