SCADA as code: what Ignition 8.3 actually changes

On most multi-plant sites we walk into, two gateways running the same SCADA platform have drifted a few versions apart — because every graphic change was made by hand, in a Designer tool, by whoever was on shift. There is no diff. There is no history. There is often no record of who changed an alarm setpoint, or why.

That is the world Ignition 8.3 just broke.

The change is boring, which is why it matters

Through its 8.3 release, Inductive Automation moved the entire project onto the filesystem — not as an export, but as the default project model.

Tags are JSON. Perspective views — the modern HMI screens — are JSON. Named queries are files. Scripts are .py. You can git clone a project, open a pull request on a graphic change, git blame a tag definition, and git revert a bad deploy. None of that was meaningfully possible in mainstream SCADA before.

Why this is a bigger deal than it sounds

Outside OT, version control is thirty years old and unremarkable. Inside it, the plant floor has spent those thirty years insisting industrial software is different — that control-room engineers shouldn’t have to learn git.

What makes 8.3 notable is not that file-based SCADA is possible. It’s that it shipped into the upgrade path of the installed base. Rockwell put git-style version control into FactoryTalk Optix and Design Studio — but those are separate, cloud-leaning products for greenfield work; the View SE/ME stack running millions of existing plants doesn’t have it. AVEVA System Platform stays where it is. Ignition 8.3 put filesystem-first into the same gateways teams are already running.

That’s the choice worth noticing: retrofit into the installed base, not sandbox in a parallel product.

What it unlocks

• Pull-request review on plant changes. An engineer branches, opens a PR, a reviewer reads the unified diff on the alarm config or the HMI binding — and the operator who has to live with that change has seen it before it shipped.
• The Primary-to-DR drift problem dies. One commit, one pipeline, both sites — same graphics, same logic, same alarms, atomically. The single biggest operational headache at every two-site install goes away.
• Multi-plant rollouts become configuration. Build the chiller-train template once; onboarding a new plant is a parameter overlay on a shared repo, not three months of hand-drawn screens.
• Auditability regulators actually like. Every change carries a commit, an author, a reviewer, a timestamp. The paper trail exists automatically instead of as a procedure someone has to remember to follow.

There’s a fifth consequence we care about more than the rest. Once a project is structured text, a model can read it, search it, and reason against it — list every tag that hasn’t been historised in thirty days, propose deadbands for the top nuisance alarms from an event log, generate a Sparkplug topic plan from a tag tree. The path to AI that touches the control layer runs through file-based projects. Literally, not metaphorically.

Where it still bleeds

We’d tell any client this on day one: 8.3 is a direction, not a finished story.

• resource.json churns. Opening a Perspective view regenerates its signature even with no functional change, so diffs are noisier than they should be — and renaming a tag provider can touch thousands of these files at once.
• A binary blob still sits at the root. global-props/data.bin mutates on simple config changes and can’t be reviewed in a pull request — an awkward exception in a project model that otherwise reads as text.
• The runtime is still Jython 2.7. This trips up a lot of the current writing on 8.3. You get full Java library access, but C-extension libraries — numpy, pandas, anything ML-shaped — still need a CPython sidecar over a subprocess or REST.
• The pipeline glue is yours to build. Inductive ships the file format and a deploy API. The lint stages, smoke tests, secret injection, and rollback are all DIY, and most teams underspend here.

What we take from it

The next decade of OT tooling — air-gap-compatible copilots, automated change management, templated multi-site deploys — assumes the SCADA layer is structured, diff-able, version-controlled text. 8.3 isn’t the cause; it’s the first mainstream vendor accepting that the boundary has moved.

That assumption is the ground we build on. If you’re scoping an OT modernisation right now and the plan is “stay with what we’ve got,” it’s worth reading the 8.3 release notes before committing to the next five years of drift — because the payoff on the other side is the plant floor finally using the same tools the software team has had for twenty years.