SCADA/HMI foundation
Source builds include the Rust gateway, browser runtime, form-based designer, tag flow, history, alarms, authentication, scripting, and a Rockwell-protocol simulator vertical slice.
Pre-alpha · Phase 4 in progress
Open-source SCADA/HMI for real machines.
Design operator views, run them in a browser, and connect plant-floor data through a Rust gateway. OpenWebHMI is a pre-alpha platform built in public for small and mid-size industrial systems.
Product path
A working SCADA/HMI foundation comes first. The reference demo and manufacturing features build on that foundation without expanding the v1.0 promise.
Default reference demo
One fictional manufacturing HMI will ship with deterministic offline simulation and an explicit real Rockwell PLC profile using the same screens and logical tags. It will never silently fall back between profiles.
Optional manufacturing modules
Production, downtime, OEE, reporting, and equipment modules are a post-1.0 direction—not shipped v1.0 features or an MES promise.
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 v1 driver targets: 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 |
|---|---|---|---|
| Core / runtime | Java 17 / JVM | C++/Qt native platform + C#/.NET NetLogic* | Rust |
| Designer | Java/Swing | C++/Qt + web technology; C#/.NET authoring* | Tauri + React/TypeScript |
| Web HMI | Perspective — React/TypeScript over Java | Web Presentation Engine — HTML5/browser | React + TypeScript |
| Scripting | Jython 2.7.4 — Python 2.7 language level | C#/.NET NetLogic | CPython 3.11+ in worker subprocesses |
| Open source? | ❌ | ❌ | ✅ AGPL core / MPL protocols |
*Optix is closed source. C++/Qt is supported by Rockwell's native-runtime documentation and current ASEM/Rockwell engineering roles, while C#/.NET NetLogic is publicly documented. The exact internal boundary between its designer and runtime is not public.
Why this combination matters
- Rust owns the always-on plant-facing core: protocol drivers, tags, alarms, history, and client fan-out get memory safety and a predictable footprint without a managed runtime.
- TypeScript owns the human interface: the designer, browser runtime, and component library share web standards and a broad contributor ecosystem instead of maintaining unrelated UI stacks.
- CPython owns user automation and data work: scripts run in worker subprocesses with gateway-enforced timeouts. Available third-party packages depend on the deployment environment; process separation is not a complete security sandbox.
- Open licensing makes operator control architectural: plants can audit, self-host, air-gap, modify, and retain the system under the AGPL core and MPL protocol terms without a per-server license.
The advantage is not that Java or C# are incapable. It is that each OpenWebHMI language has one clear job, and the complete platform remains inspectable and operator-owned.
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, an initial component set, hot reload.
- ✓ Phase 3 Core SCADA — historian, alarms, auth, trends, Python scripting host, Monaco script editor.
- In progress Phase 4 — five driver implementations are being hardened and integrated for the v1.0 envelope. Current closeout work includes CI hygiene, release packaging, website/docs refresh, and the physical Rockwell PLC 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 — optional manufacturing modules are post-1.0 direction, 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.