JasperNode & JasperX

AI-Powered Industrial Automation

By: Alex Sharikov, Director / Lead Engineer at ControlX Engineering Pty Ltd
Revision: E | Revised: v2 architecture, headless runtime, cloud platform, safety trajectory
Last change: July 2026

Product website: https://www.jasperx.com.au/

Executive Summary

Industrial automation development is constrained by a shortage of skilled controls engineers, legacy toolchains that are slow to modify, and change management processes that rely on tribal knowledge. These constraints directly impact project timelines, commissioning costs, and the ability to maintain and troubleshoot systems after handover.

JasperNode is an industrial automation runtime that changes how control logic is developed and maintained. It ships as a single free executable for Linux edge devices, no driver installation, no firmware provisioning, no licensing dongles. Engineers describe requirements in natural language; the AI, resident on the JasperX cloud platform, authors structured JavaScript control logic through auditable tool calls against the node. Every harm-capable AI action passes through a Deploy Gate: the change is tested against the node’s dependency chain, then presented to the engineer for explicit approval before it can reach the field. The AI never actuates the machine on its own authority.

The runtime is built on an event-driven tag engine: logic executes only when its declared triggers change, so dormant logic consumes zero resources and an idle node runs in single-digit CPU percentage on a low-cost ARM device. It natively supports Modbus TCP/RTU, Siemens S7, EtherCAT, Serial, and LiDAR on the fieldbus side, with MQTT (including Sparkplug B and an embedded broker), InfluxDB, Modbus Server, and a built-in web HMI on the IT side. EtherNet/IP and OPC-UA are on the near-term roadmap.

Every change to a program, whether made by a human or by the AI on a human’s behalf, is recorded with who, when, and how, and shipped to the cloud for durable storage. This audit-first architecture is the foundation of JasperNode’s longer-term goal: IEC 61508 SIL-3 certification on the certified-runtime + certified-hardware model established by CODESYS Safety and TwinCAT Safety. The runtime is not yet certified; every architectural decision is made toward certifiability.

JasperNode is deployed in production across water/wastewater, chemical processing, maritime, and general industrial and manufacturing sites in Australia.

1. The Challenge: Where Development Time Actually Goes

Controls engineers know the bottleneck. It’s rarely the engineering problem itself, it’s the time consumed by everything around it:

The Skills Gap: There are not enough experienced controls and automation engineers to meet demand. Project timelines slip because the work queues behind a small number of qualified people.
Handover and Troubleshooting Friction: Traditional PLC code is difficult to read and understand, particularly when written by a different engineer, in a different era, with no documentation. The diagnostic information is locked inside proprietary toolchains and licensing structures, the engineer who gets called out often cannot access the logic without the original vendor’s software.
Change Management by Tribal Knowledge: Tracking who changed what, when, and why is frequently a manual process, if it happens at all. On multi-engineer projects, this creates real production risk.
Toolchain Overhead: Even simple logic changes can require specific software versions, compatible cables, firmware updates, and downtime windows. The ratio of engineering time to administrative overhead is often inverted.

These are structural problems, not competence problems. The tools are the bottleneck, not the engineers using them.

2. The Solution: A Runtime and a Platform

The product is two halves with a deliberately clean seam:

JasperNode, the free, headless edge runtime. It owns the tag engine, logic execution, fieldbus and IT connectors, and autonomous control. It runs the plant with or without a cloud connection.
JasperX, the cloud platform. It owns identity, projects and fleets, the browser IDE, the AI agent, program revisions, and durable audit storage. It is where humans and the AI meet the node.

Neither trusts the other’s availability: the node runs the plant; the cloud runs the product. A node that loses its uplink keeps executing logic, keeps logging, and reconciles with the cloud when it reconnects.

The critical design principle is unchanged from day one: the AI does not run the machine directly. It acts as an engineering agent, exploring the live system, authoring clear, standardised JavaScript control logic, and proposing changes. Deployment is a separate, gated act: generated logic is tested, presented for review, and approved by the engineer before it runs. Human oversight is enforced by the runtime itself, not by convention.

The entire runtime ships as a single executable. Install it and it runs.

3. Architecture

3.1 Everything Is a Tag

The heart of JasperNode is the tag engine, a single in-memory tree where every value in the system lives: field I/O, computed values, connector configuration, system health, even the node’s own settings. There are no separate configuration stores or hidden state. Anything the engineer or the AI needs to see or change is a tag with a value, a timestamp, and a recorded source, who set it last, and when.

This one decision pays off everywhere downstream: one place to look when troubleshooting, one subscription mechanism for the UI and the AI, one persistence path (batched to SQLite on the node), and one backup boundary, a node’s whole program is a serialisable set of tags and scripts.

3.2 The Event-Driven Engine

JasperNode replaces the traditional indiscriminate cyclic scan with a decoupled, event-driven architecture:

Connector cycles: Each fieldbus or IT connector runs its own optimised polling or event loop on its own thread, reading external data into the tag engine. Writes back to hardware occur when output tag values change.
Wake-on-write event detection: When a tag value changes, from a connector, the UI or a script, the engine wakes exactly the consumers that subscribed to that tag. There is no polling loop burning CPU while nothing happens.
The Logic Cycle: Scripts execute in an isolated worker, driven entirely by their declared triggers. Only logic whose inputs actually changed runs; dormant logic consumes zero resources. A watchdog bounds every script run.

This combines the predictability of a structured architecture with the efficiency of event-driven logic. The results are measurable: an idle JasperNode on a low-cost ARM Cortex-A53 edge device runs at under 9% of one core, including the engine, persistence, the web server, and the cloud link, leaving the machine’s headroom for actual I/O and logic.

For deterministic, hard-cadence control, a second execution engine, the High-Performance Cycle, a Rust-hosted loop running sandboxed WebAssembly logic at sub-millisecond rates, is built and on the roadmap for a subsequent release (see Section 9).

3.3 Atomic Tag Control

In JasperNode, each tag has one writer. A script can set only its own tag’s value. A connector writes only the tags its configuration declares as inputs. When a connector claims a tag and is enabled, scripts cannot write it, to simulate the field, the engineer disables the connector and attaches a script in its place, as an explicit, recorded act.

This eliminates the most common source of bugs in complex control programs: multiple code blocks writing to the same variable under different conditions. When troubleshooting, the engineer always knows exactly where a value comes from, there is only one place to look.

3.4 Traceable Logic, Wiring Derived from Code

Scripts read other tags through two explicit calls: on("path/tag"), read the value and re-run this script when it changes, and read("path/tag"), read the value without triggering. The engine extracts this wiring directly from the code at deploy time. There is no separately-maintained dependency list that can drift out of date, and no hidden coupling: the reactive chain, which change fires which script, which script feeds which, is always exact, inspectable in the IDE, and available to the AI when it reasons about the downstream impact of a change.

Deployment is atomic: a script’s code, wiring, and type metadata flip together as one unit, never as a partially-applied edit.

3.5 Fault Isolation

Connectors are isolated from the core and from each other. Fieldbus connectors are self-contained native modules, each running on its own OS thread with per-instance panic containment; IT connectors run in isolated workers; user script code runs in its own sandboxed worker so a runaway script cannot stall the engine. A fault in one connector takes down that connector, not the node.

3.6 Why JavaScript

JavaScript is an unconventional choice for industrial control, and that’s deliberate. Traditional PLC languages (Ladder Logic, Structured Text, Function Block Diagram) are powerful but create a closed ecosystem: only specialists trained in these languages can write, read, or modify the logic.

JavaScript is the world’s most widely understood programming language. This means:

A broader talent pool can contribute, IT developers, electrical technicians with scripting experience, and graduate engineers can read and review control logic without specialist PLC training.
The AI is at its strongest, modern AI models are more fluent and more reliable in JavaScript than in any proprietary PLC language, which directly improves the quality of generated logic and of AI-assisted review.
Performance is not a trade-off, the event-driven engine executes scripts with per-script overhead well under a millisecond, meeting the requirements of supervisory and process-control applications (see Section 6 for application suitability).

This is not about replacing engineering judgement with a lower-skilled workforce. It’s about removing an artificial language barrier that restricts who can participate in development, review, and troubleshooting.

4. AI Development with a Human in the Loop

All AI interaction is channelled through JasperX. The AI is cloud-resident and always available, it works at organisation, project, and node scope, and can even edit a program while its node is offline. At node scope it drives the tag engine through tool calls; the node is a tool target, not the AI host. JasperX provides the AI with system context, tag definitions, and guardrails, ensuring generated logic is relevant to the specific installation.

Three runtime mechanisms keep the AI accountable:

4.1 Node Modes

Every node is in one of three modes, development, commissioning, or production, set only by a human editor. The mode gates AI behaviour, not human edit rights:

Mode	AI test scope before deploy	Human sign-off
Development	Modified script, multiple trigger value sets	Not required
Commissioning	Modified script + one level of downstream effects	Required
Production	Modified script + the full downstream chain	Required

4.2 The AI Deploy Gate

Any AI action that can change how the node behaves at runtime or actuate the physical field, deploying control logic, or enabling a fieldbus connector whose outputs another script or connector is already driving, is hard-blocked at the Deploy Gate until it has been tested to the mode’s required depth and, where the mode demands it, a human has explicitly approved it. The AI cannot continue past the gate on its own. Direct human edits are not gated, the gate constrains AI agency, but they are audited all the same.

4.3 Machine-Checked Rules

Below the gate, an extensible rule registry checks every AI operation against hard-coded guardrails: read a script before modifying it; never delete a tag other logic depends on; never deploy a loop that doesn’t yield; never disable a writing connector in production without sign-off. Rules are individually testable and auditable, and new rules are added as the fleet teaches us.

4.4 Universal Audit

Every change to a program, tag, script, or connector, is recorded with who (cloud identity), when, and how (manual edit, or which AI acting on whose behalf), independent of the Deploy Gate. The node keeps a local audit log and ships it to JasperX for durable, tamper-evident storage.

4.5 Ask-Mode for Everyone Else

Not every user should change the program, but everyone should be able to understand it. Read-only AI ask-mode lets viewers, operators, and incoming engineers ask how the system works, what is faulty, and why a value is what it is, without any ability to modify logic. The built-in web HMI extends the same idea to the plant floor.

5. The Cloud Platform: Programs, Revisions, and Fleets

JasperNode is headless: all human interaction happens in the JasperX browser IDE. That single decision unlocks capabilities no local-first toolchain can offer:

Programs are independent of hardware. A program, tags, scripts, connectors, can be created and developed with no node attached, edited against the cloud copy, and run on a virtual node (a stock JasperNode container with no field hardware) for develop-before-hardware and simulation. Binding it to real hardware swaps only the connector endpoints, never the logic.
Revisions, online or offline. The cloud holds every program and its revision history. An engineer can open and edit a node’s program while the node is offline, test against simulated values, and save the result as a new revision.
Controlled deployment, never silent overwrite. When a node reconnects behind a newer cloud revision, the IDE offers a staged deployment, connectors reviewed one by one, scripts together or individually, with the Deploy Gate applying throughout. Or a full, explicit restore.
Fleet overview. Every node publishes a lightweight health summary, running state, error counts, connector status, so a project or site dashboard shows which nodes are healthy without streaming full live data.
Remote access without VPN plumbing. Node-hosted web UIs (such as the HMI) are reachable through a secure outbound tunnel, as if local. The tunnel carries no control traffic, command paths are separate by design (Section 8).

6. Application Suitability

JasperNode today is designed for industrial applications where hard real-time performance and certified functional safety are not primary requirements. It excels in general industrial control, process control, building automation, machine control (where safety functions are implemented by external hardware such as safety relays), data logging, and IIoT gateway applications.

Table 6.1. Application Fit (current release)

Application Attribute	1 (Poor Fit)	2	3 (Neutral)	4	5 (Excellent Fit)
Real-Time Requirement	Hard Real-Time	Firm Real-Time	-	Soft Real-Time	Non-Real-Time
Functional Safety	SIL 3/4 Critical	SIL 1/2 Required	Monitored Safety, SIL 2 outsourced to specialised hardware	Process Safety Only	No Safety Requirement
Logic Complexity	Simple On/Off	Basic Timers/Counters	Multiple Loops	Multi-state Sequential	Highly Interdependent Logic
Data Integration Needs	Isolated / Air-gapped	Serial Comms Only	Local HMI	Database Logging	Cloud/Web Service API
Dev. Speed Requirement	Low (Months/Years)	-	Medium (Weeks)	-	High (Minutes/Hours)
User Technical Profile	Certified Controls Eng.	PLC Programmer	Electrical Technician	IT Developer	Process Expert (No Code)
Cost Sensitivity	Low (Cost is no object)	Medium	-	High	Very High (DIY Budget)

6.1 Where JasperNode Sits in the Control Systems Landscape

JasperNode does not yet replace safety-rated controllers or hard real-time motion control systems. It operates in the space where the vast majority of industrial control logic actually lives: process sequencing, monitoring, data integration, alarm management, and supervisory control.

For sites running traditional PLCs, JasperNode operates alongside existing controllers, reading data from Siemens S7, Allen-Bradley, or Modbus devices and providing a supervisory or data integration layer without replacing the existing field-level control.

For greenfield projects where hard real-time and SIL-rated safety are not required, JasperNode replaces the traditional PLC entirely, with dramatically faster development, simpler maintenance, and lower total cost of engineering.

6.2 The Safety Trajectory

The end goal is larger: IEC 61508 SIL-3 certification on the model proven by CODESYS Safety and TwinCAT Safety, a certified runtime on a certified hardware partner, with the customer’s safety application compiled to sandboxed WebAssembly on the deterministic High-Performance Cycle, orchestrating SIL-rated peers (EtherCAT FSoE, safety PLCs over OPC-UA Safety) without compromising their safety case.

The runtime is not yet certified, and this paper makes no safety claim beyond it. What is true today is that the supervisory layer is auditably safer than convention: three-mode change gating, human approval of harm-capable AI actions, atomic deployment, machine-checked AI rules, and a universal, cloud-shipped audit trail, mechanisms conventional PLC toolchains simply do not have. Every architectural decision, the deterministic HPC, the WASM sandbox, the Deploy Gate, the segregation of safety and non-safety state, is made toward certifiability. Full certification (HARA, SRS traceability, V-model V&V, toolchain qualification, paired hardware certification) lands in a later release on certified hardware.

7. Connectivity

Fieldbus (OT), native, self-contained modules:

Protocol	Notes
Modbus TCP & RTU	Client (master), multi-instance
Siemens S7	S7-300/400/1200/1500 over Ethernet
EtherCAT	Full master; 1–4 ms cycles, opt-in sub-millisecond real-time mode
Serial	Raw serial framing for legacy devices
JasperMate I/O	JasperX’s plug-and-claim edge I/O hardware
LiDAR	Sweep geometry streamed as first-class binary tags

IT & integration:

Protocol	Notes
MQTT client	Including Sparkplug B
MQTT broker	Embedded broker, the node can be the site broker
InfluxDB	Time series logging to user-owned databases
Modbus Server	Expose tags to SCADA/BMS as a Modbus slave
HMI	Built-in web HMI served by the node itself

EtherNet/IP and OPC-UA (including OPC-UA Safety) are on the near-term roadmap. Connectors are modular by design: new protocol types land as independently installable, signed packages without a core runtime update across the fleet.

8. Security Architecture: Zero Trust Model

JasperNode’s security architecture is built on Zero Trust principles, every device, user, and application must prove its identity and authorisation for every action, with no implicit trust granted to any network location.

Cryptographic device identity. Every node is provisioned with a server-signed identity; devices hold no reusable shared secrets. Every API interaction is authenticated with short-lived signed tokens.
Cloud identity, no local users. All human identity, roles (Owner / Editor / Viewer), and sharing live on JasperX. The node consumes the identity and permissions the cloud asserts, there is no local account to leave behind on a decommissioned box.
Least privilege. AI interaction is read-only by default; destructive operations require explicit human approval at the Deploy Gate. System and application tags are protected from user modification, so operational infrastructure cannot be accidentally disrupted.
Segmented paths. Command, data, and remote-access paths are strictly separated. Commands reach the node only through the authenticated cloud command channel; the remote-access tunnel proxies web UIs only and carries no control traffic.

Roadmap: cryptographic signing of safety-rated artefacts, with signatures travelling alongside the audit record.

9. Roadmap

The near-term direction, in the order it is being built:

Cloud IDE completion, the browser IDE on JasperX becomes the primary development surface; the node-hosted IDE retires to a fallback role.
Fleet operations, health summaries, site/project dashboards, historian (selected tags streamed to timeseries storage), alarms with email/SMS/push and acknowledge tracking.
Virtual nodes everywhere, programs developed and simulated with no hardware attached, then bound to real nodes; cloud-side chain testing for the Deploy Gate.
High-Performance Cycle, the deterministic Rust/WebAssembly execution engine for sub-millisecond, hard-cadence control; already built, shipping when the authoring experience is ready.
New connectors, EtherNet/IP, OPC-UA, node-to-node streaming, email; delivered as independently installable signed packages.
Safety program, safety/non-safety segregation in the runtime (safety_rated logic isolated by machine-checked rules), signed safety artefacts, then the formal IEC 61508 SIL-3 certification program with a certified hardware partner.

10. Platform and Commercial Model

Hardware. JasperNode runs on a wide range of Linux devices, from IIoT gateways to servers. The typical target is a 4-core, 4 GB ARM edge device; the floor is 2 cores and 2 GB running a trimmed headless Linux. macOS and Windows are supported for development inside a Linux container. EtherCAT requires bare-metal Linux, real-time fieldbus and virtualisation layers do not mix.

Commercial. The JasperNode binary is free, download it, run it, keep your plant running on it forever. Commercial value is the JasperX platform: the AI agent, the cloud IDE, fleet management, revisions, and audit storage, sold as subscription tiers with AI usage allowances. Read-only ask-mode is included in every tier. There is no per-point licensing, no runtime license on the edge, and no toolchain purchase standing between an engineer and the logic.

11. Conclusion

JasperNode pairs a free, event-driven edge runtime with a cloud platform where an always-available AI does the authoring and humans keep the authority. The engineering workflow is: describe the requirement in natural language; review the tested, generated logic; approve. Every change is attributed, revisioned, and auditable from the first deploy, and the same audit-first architecture is the road to certified functional safety.

For engineers and system integrators working under skills constraints, tight project timelines, and the ongoing burden of maintaining systems they didn’t build, JasperNode is a tool designed around how you actually work.

About ControlX Engineering

ControlX Engineering is a Newcastle-based industrial automation company with a decade of experience delivering complex control system projects for clients in manufacturing, mining, and utilities. JasperNode was developed by our engineering team to solve the real-world bottlenecks we faced on our own projects. It is now used on all new ControlX automation projects and is available as a standalone product.