This is Part 3 of a 3-part series on i3X and OPC UA. Part 1: When REST Meets Real-Time | Part 2: One API Call to Rule Them All

Update (July 2026): Revised for precision following continued discussion with Matthew Parris. The alarms section now distinguishes representing alarm data as objects (which i3X allows) from the standardized Alarms & Conditions lifecycle (which it does not yet define) — the earlier "zero concepts" wording was too absolute. The dynamic-models section likewise separates what the spec requires from what our early implementation happened to do. Thanks for the sharp read.

The Missing Safety Layer — and How to Bridge It

In Part 1, we saw that i3X and OPC UA share the same information-modeling DNA. In Part 2, we explored i3X's decomposable asset model — and the first cracks in monitoring. Now we face the hard questions: what happens when safety is on the line?

The alarm gap: when numbers aren't enough

OPC UA's Alarms & Conditions framework (Part 9) is a complete alarm management system used in every serious industrial deployment. It tracks the full lifecycle of an alarm through a state machine:

  Active ───▶ Acknowledged ───▶ Confirmed ───▶ Inactive
  Sev: 900     By: Operator      By: Shift       Auto
  Msg: "High   At: 14:23:05      Lead            Cleared
   High Temp"

Each alarm carries severity (0–1000), human-readable messages, source identification, and timestamps. Operators must acknowledge critical alarms. The system records who acknowledged, when, and whether it was confirmed. This audit trail is required by FDA 21 CFR Part 11, IEC 62443, and ISA-18.2.

i3X has no native equivalent. To be fair, nothing stops you representing an alarm as an object, with properties like severity or state, and reading those values like any other data. What the specification does not define is a standardized alarm model or the Alarms & Conditions lifecycle itself: no acknowledge/confirm round-trip, no state-machine semantics, no event subscription for condition changes. Two platforms would therefore model alarms differently, and none of the A&C guarantees carry across.

What this means in practice

Chemical reactor at 200°C:

Motor thermal overload:

The OPC UA server sends an OffNormalAlarm with severity 800 and the message "Motor M-4201 thermal overload." The operator acknowledges it. When the motor cools, the alarm clears. Full lifecycle tracked.

With i3X? The client sees a boolean go true → false. No severity, no message, no acknowledgement workflow.

In a pharmaceutical plant, an unacknowledged alarm during a batch process can invalidate the entire batch — a loss of $50K to $500K. In petrochemical, it's a safety risk that can cost lives.

The command gap: fire and pray

OPC UA Methods are typed remote procedure calls. You call a method, pass typed arguments, and get a result with a StatusCode confirming execution:

  OPC UA Method Call:
  ──▶ CallMethod("LoadTool", toolId=7)
  ◀── Result: { success: true,
                previousTool: 3,
                newTool: 7,
                estimatedTime: 12.5s }

i3X has no method invocation. The only option is to write a value and poll:

  i3X WriteValue:
  ──▶ PUT /objects/ToolRequest/value  body: 7
  ──▶ GET /objects/ToolCurrent/value  → 3 (not yet)
  ──▶ GET /objects/ToolCurrent/value  → 3 (still not)
  ──▶ GET /objects/ToolCurrent/value  → 7 (maybe done?)
       Did it succeed? Did it fail? No error info.

For emergency stops, this is critical. An OPC UA CallMethod("EmergencyStop") returns an immediate StatusCode confirming the PLC executed the stop. An i3X WriteValue("EStopRequest", true) writes successfully, but did the PLC act on it? You must poll and hope. The difference between "confirmed executed" and "write succeeded, hope it works" is the difference between compliance and catastrophe.

The invisible world: events, dynamic nodes, and stale metadata

Beyond alarms and commands, three more gaps emerge when you look at how real OPC UA servers behave in production.

Dynamic address space

OPC UA address spaces are dynamic by design. A coordinate measuring machine creates result nodes for each inspected part. An ISA-95 production line creates job objects on the fly. A DI (Devices Integration) server adds and removes device nodes when hardware is hot-swapped.

To be precise, nothing in the i3X spec forces a static model. The real problem is that the spec is silent on change: there is no model-version field, no model-changed event, and no instance-lifecycle hook. With no standard way to learn that the address space moved, many implementations (our own early build included) construct the model once at startup and cache it. Nodes created after that point return 404 for their elementIds. An MES polling such a server for quality data never receives the new measurement results, and parts ship without QC records. A standard model-change signal would let any implementation stay live instead of guessing.

OPC UA events

OPC UA's event system goes far beyond data value changes. AuditEventType logs every operator action and configuration change — the legally required electronic record for FDA 21 CFR Part 11. TransitionEventType captures state machine transitions with exact timestamps. Custom event types carry journal entries, treatment logs, and diagnostic messages.

Our current bridge recognizes eventSource nodes in its domain model but does not yet subscribe to their events — an implementation limitation we are closing, not a spec restriction. Audit trails are empty. State machine transitions are reduced to polling. Journal entries are completely invisible.

Semantic change detection

When a filling line switches products, the engineering units might change from mL to oz, the ranges shift, and temperature scales flip from °C to °F, all without changing any NodeId. OPC UA fires SemanticChangeEvent to notify clients. i3X has no equivalent signal, so a client reading metadata it cached earlier gets stale values: the operator reads "480" and assumes 480mL when it is actually 480oz. Wrong dosage. Product recall.

What Sterfive is building

This is where node-i3x goes beyond the spec. We're not waiting for the gaps to close — we're building the bridge.

Implemented: smart monitoring defaults

node-i3x detects the DataType of each OPC UA node and automatically selects the optimal monitoring strategy:

No i3X spec changes required. The intelligence lives in the server.

In development: command invocation

A custom extension endpoint for calling OPC UA Methods through REST:

POST /v1/objects/{elementId}/invoke
{
  "inputArguments": [
    { "value": 7, "dataType": "UInt32" }
  ]
}
→ { "success": true, "statusCode": 0,
    "outputArguments": [...] }

Full argument type coercion, OPC UA StatusCode in the response, and transactional semantics. Designed to be forward-compatible with a future i3X spec addition.

On the roadmap: alarms, events, and dynamic models

We are building extensions to address the remaining gaps — alarm lifecycle management via SSE, event subscriptions for audit trails and state machine transitions, dynamic model refresh triggered by GeneralModelChangeEvent, and semantic change detection. These are extensions we would be happy to propose to the i3X standard once they are battle-tested in production deployments.

The full picture

Get started: licensing and integration

node-i3x can be integrated directly into your existing OPC UA server — no separate gateway, no additional infrastructure.

Dual licensing:

• AGPL-3.0 — Free for open-source projects. If you deploy as a network service, you must share your source code under the same license.
• Commercial license — For proprietary or closed-source deployments. No copyleft obligations. Includes dedicated support and maintenance.

An optional @sterfive/opcua-optimized-client module delivers up to 200% performance improvement through intelligent transaction batching, automatic server-limit handling, and advanced auto-healing connection logic.

The bottom line

i3X and OPC UA are complementary. i3X excels at making industrial data accessible to the web. OPC UA provides the industrial-grade foundation — security, alarms, events, methods, dynamic models, deterministic real-time. The gaps in the i3X Beta spec are real, but they are the gaps of a young specification, not a flawed one.

Sterfive is building the bridge. We implement smart workarounds in node-i3x today, and we are developing extensions for commands, alarms, events, and dynamic model support that we would be happy to propose to the i3X standard. If you want to bring i3X to your OPC UA infrastructure — whether for dashboards, AI pipelines, or enterprise integration — we can help you get there.

New to i3X? Start with our practical introduction.

Ready to bring i3X to your OPC UA infrastructure? node-i3x is available today — open source under AGPL-3.0, or with a commercial license for proprietary deployments. We also offer consulting to help you design an architecture that leverages both i3X and OPC UA to their fullest. Contact Sterfive to get started.