Rethinking the SCADA Stack: Rust Runtime, Python 3.11+ Scripting

The current state of industrial HMI scripting is more complicated than the usual vendor-bashing version of the story. Ignition, one of the most important modern SCADA/HMI platforms, still centers its built-in scripting story on Jython 2.7: Python 2.7 semantics on the JVM. Inductive Automation supports that runtime and maintains its own Jython codebase, but the upstream Python project officially sunset Python 2 on January 1, 2020. FactoryTalk Optix moves in a different direction with C# scripting and .NET integration, which is a real improvement for many teams, but it still points the platform toward a specific vendor stack.

That is the state of the art for many small and mid-size factories in 2026: mature platforms, serious engineering, and scripting environments that do not line up cleanly with the Python ecosystem where most modern data, ML, and AI work is happening.

Why this matters

The issue is not whether you can write useful scripts in Jython 2.7. You can. Many plants do it every day. The issue is what becomes hard or awkward when the scripting layer is separated from modern CPython. Inductive Automation's own documentation notes the core tradeoff: Jython can access Java libraries, but C libraries are not accessible in the same way they are from CPython.

• No normal path to production-grade numpy, pandas, scikit-learn, torch, or modern LLM SDKs inside the platform scripting runtime.
• No Python 3 language features such as asyncio, f-strings, useful type hints, or dataclasses.
• No standard CPython packaging story for libraries with native extensions.
• No simple way to treat ML and data-science code as first-class platform code instead of an external integration.

The result is predictable. Predictive maintenance, anomaly detection, ML-driven quality inspection, and AI-assisted operator interfaces often end up outside the HMI as separate projects. Even Inductive Automation's own machine-learning material discusses Python 3 environments running alongside Ignition for TensorFlow, PyTorch, scikit-learn, and similar tools. That can be the right architecture for some systems, but it should not be the only path.

Why the industry got stuck here

The fair version of the argument matters. Jython made sense. The JVM was a strong deployment target, especially when industrial platforms needed cross-platform behavior, long-lived runtimes, and access to Java libraries. Embedding CPython directly was not a clean choice for every product architecture.

Industrial customers also value stability over novelty. In a plant, "this scripting layer has not changed much in years" can sound like a feature, not a defect. A platform with deployed customer scripts going back many years cannot casually replace its scripting engine without breaking real production systems. Inductive Automation has also been public that Python 3 migration is a real engineering problem, not a matter of simply flipping a version number.

That is why I do not think the right conclusion is "the incumbents are lazy." The better conclusion is that platforms designed around older runtime assumptions eventually accumulate architectural debt. At some point, that debt becomes visible to customers who want modern computation inside industrial software.

What changed

Several things are different now. First, CPython does not have to be embedded directly into the runtime process. A platform can run Python as a worker process, communicate over IPC, supervise execution, control resources, and isolate failures. That architecture is easier to reason about than forcing the entire HMI runtime to become a Python host.

Second, Rust has matured into a serious choice for long-lived industrial runtime software. It gives you memory safety without a garbage collector, strong async networking, a single-binary deployment story, and a good fit for protocol drivers where bytes, timing, and error boundaries matter.

Third, the Python ML ecosystem is no longer optional infrastructure. If a modern industrial platform cannot run normal Python libraries without strange workarounds, that limitation is visible to engineers evaluating it. Python is where much of the practical work in ML, optimization, data analysis, and AI integration happens.

Finally, AI-assisted development has changed what a small team can build. That does not remove the need for engineering judgment, testing, or domain expertise. It does make open-source industrial software viable at scopes that would have looked unrealistic for one or two people a few years ago.

The OpenWebHMI architecture

OpenWebHMI is built around a simple idea: keep the plant-floor runtime small, predictable, and boring, while making modern computation first-class.

The gateway is written in Rust because it has to run for months, speak industrial protocols, poll tags, serve clients, and fail in ways that are observable rather than mysterious. A single static binary matters in small plants. Predictable memory behavior matters. A runtime without GC pauses matters. Industrial protocol work is often low-level systems work, and Rust is good at that category of problem.

Scripting runs on CPython 3.11+ worker subprocesses. That choice is deliberate. It means Python libraries from PyPI work as Python libraries, including the ones with native extensions. It means numpy, pandas, scikit-learn, and modern ML tooling are not special integration projects. It also gives the platform a cleaner sandbox boundary: supervise the worker, communicate over IPC, and keep the core gateway insulated from script failures.

The designer and runtime use React and TypeScript because industrial UI is already moving toward web technology. Ignition Perspective and FactoryTalk Optix both point in that direction. Tauri gives the designer a path to cross-platform desktop packaging without splitting the UI stack from the web runtime.

The MIT license is also part of the architecture. Licensing economics are one of the reasons small and mid-size industrial systems get stuck with either expensive enterprise platforms or fragile custom tools. A free-as-in-freedom SCADA/HMI option fills a real gap if it is scoped honestly.

What this is, and what it is not

OpenWebHMI is not trying to replace every Ignition or FactoryTalk Optix installation. The first target is deliberately smaller: one gateway, up to about 10,000 tags, up to about 50 clients, and a limited driver set. The goal is to be useful for small and mid-size industrial systems before pretending to be an enterprise platform.

It is not hard-real-time control. It is not SIL-rated safety software. It is not an MES. It is not a universal replacement for a platform that already runs a large site with years of modules and integrations. That scope is not a weakness. It is the only way to make the project technically honest.

The open questions

The approach still has to prove itself. The biggest question is long-term operational behavior under real plant conditions. I have hardware validation on the EtherNet/IP driver, but the full OpenWebHMI platform still has to earn that same level of evidence.

Driver coverage is another open question. A focused set of protocols can be enough to make the platform useful, but it will not be universal. Community is the third question. An open-source SCADA/HMI platform has to become more than one person's project if it is going to outlive its founder.

The argument

My argument is not that existing SCADA platforms are bad. They solved real problems and continue to run real factories. My argument is that the next layer of industrial software needs a different foundation: modern systems programming for the runtime, modern Python for computation, and an open licensing model for teams that cannot justify enterprise economics.

That is what OpenWebHMI is trying to explore. Not a marketing wrapper around the same old stack, but a smaller, sharper architecture for the industrial systems that need modern software without losing contact with the machines.