The open-source SCADA & HMI platform.
Web-first runtime, cross-platform desktop designer, plant-floor connectivity. Built on Rust, TypeScript, and modern Python for in-platform AI/ML — not Java, not .NET, not Jython 2.7.
Why another platform?
Industrial automation has been locked behind closed source tooling and expensive gateway licensing for decades. Tools like Inductive Automation Ignition and Rockwell FactoryTalk Optix are excellent, but there is no equivalent open-source platform a small or mid-size plant could actually run. OpenWebHMI's goal is to change that.
AI-assisted development makes the timeline plausible in a way it wasn't five years ago.
v1.0 scope
Concrete bounds. If anything in the project implies bigger numbers, it's wrong and gets fixed.
- Single gateway per deployment
- ≤ 10,000 live tags per gateway
- ≤ 50 concurrent runtime clients per gateway
- Five shipped drivers: Rockwell EtherNet/IP, OPC UA, Modbus TCP/RTU, MQTT (incl. Sparkplug B), Beckhoff ADS
- Web-only runtime; Tauri desktop runtime is post-1.0
- Linux, macOS, Windows for gateway and designer
Stack at a glance
| Layer | Ignition | Optix | OpenWebHMI |
|---|---|---|---|
| Gateway | Java (JVM) | C# / .NET | Rust (single static binary) |
| Designer | Java + Swing | Visual Studio (Win-only) | Tauri + React/TS (Win + Mac) |
| Web HMI | Perspective (React/TS over Java) | Optix WebPresentation | React + TypeScript |
| Scripting | Jython 2.7 (frozen 2010) | C# / JS | CPython 3.11+ in worker subprocesses |
| Open source? | ❌ | ❌ | ✅ MIT |
The CPython 3.11+ scripting layer is the headline differentiator:
numpy, pandas, scikit-learn,
torch, and LLM SDKs all run natively in scripts.
In-platform predictive maintenance and AI-assisted authoring become
normal features, not external integration projects.
v1.x feature highlights
- Audit-log 21 CFR Part 11 framing: tamper-evident SHA-256 hash chain, verify CLI, and an engineering coverage map with every clause marked partial or out-of-scope. Read the mapping ↗
- Project themes and Material-inspired demo widgets: light/dark CSS-variable themes plus an opt-in demo pack covering representative controls without changing widget prop contracts. Theme editor ↗ Widget packs ↗
- Historian capacity and retention planning: SQLite-backed storage with sizing formulas, online backup/restore, and explicit opt-in pruning primitives. Historian guide ↗
- Raspberry Pi 4/5 edge deployment guide: native Pi build path, systemd unit, reverse-proxy guidance, and honest hardware-smoke boundaries for operator validation. Pi deployment ↗
- Widget export/import between projects:
human-readable
.owhmi-widgetfiles, schema-version checks, tag-binding warnings, and regenerated component ids on import. Widget transfer ↗
Where we are
- ✓ Phase 0 Foundations — gateway boots, simulated tags flow to a browser.
- ✓ Phase 1 Vertical slice — Rockwell driver wired end-to-end, validated against a simulator. Released as v0.1.0.
- ✓ Phase 2 Designer MVP — form-based authoring, 6 essential components, hot reload.
- ✓ Phase 3 Core SCADA — historian, alarms, auth, trends, Python scripting host, Monaco script editor.
- In progress Phase 4 — five drivers are in place for the v1.0 envelope; the current closeout work is CI hygiene, release packaging, website/docs refresh, and the real-hardware validation gate before 1.0. Recent v1.x additions include audit-log Part 11 framing, themes, widget transfer, historian retention planning, and Raspberry Pi deployment notes.
What we explicitly don't try to be
- A hard-real-time control platform.
- A safety-rated (IEC 61508 / SIL) system.
- A replacement for vendor-specific PLC engineering tooling.
- An MES platform — that's a year-2+ conversation, not a 1.0 promise.
- An enterprise-scale (>10K tag, >50 client, multi-gateway) system in v1.
Want to follow along?
The repo is the source of truth — every architectural decision, task brief, code review, and validation run is in markdown alongside the code.