Eldric's closed-loop control path connects the policy worker (xLSTM) to your industrial endpoints. Five transport options cover different deployment shapes, and a watchdog-driven safety fallback keeps the loop sane when the policy worker misses its deadline. License tiers vary per transport — see the table below.
The control loop ticks at a rate you set (typically 10–100 Hz). On each tick:
If any step takes longer than the watchdog timeout, the loop applies the configured safety fallback instead and counts the miss. Repeated misses trigger a state transition; sustained misses can hand the binding off to a failover worker if you've configured one.
| Transport | Status | License tier | Typical use |
|---|---|---|---|
| WebSocket | GA | Standard+ | Sub-tick latency, 50–100 Hz loops |
| Modbus TCP | GA | Standard+ | Legacy industrial equipment, drives, sensors |
| OPC-UA | Preview | Pro+ | PLC fleets, multi-vendor industrial |
| MQTT (Sparkplug B), publish | GA | Pro+ | Push policy actions to actuator fleet |
| MQTT (Sparkplug B), subscribe | Preview | Pro+ | Pull observations from sensor fleet |
| File tail (test) | GA | Standard+ | Deterministic test rigs, dev loops |
WebSocket, Modbus, MQTT-publish and the deterministic file-tail transports are GA in 5.0. OPC-UA ships at preview through 5.0 RC1 — the C++ source is in the release, the open62541 library bundles into the cluster RPM at the next cut. MQTT-subscribe (pulling observations from a Sparkplug-B sensor fleet through the policy worker) stays preview through the 5.0 line; the per-binding background subscriber + ring buffer arrives in 5.1. See known issues for the current preview state.
When the control loop ticks faster than HTTP round-trip latency comfortably allows, the WebSocket transport keeps a long-lived connection open to the policy worker. The IoT worker streams observations; the policy worker streams actions back. No per-tick connection setup; latency drops to the underlying network round-trip plus inference time.
When to use: 50–100 Hz control loops, jitter-sensitive workloads, anything where the connection-setup overhead per request would eat into your time budget.
Failure modes: if the WebSocket drops, the IoT worker transitions the binding to degraded state immediately. The safety fallback engages while a reconnect attempt runs in the background.
Modbus over TCP is the workhorse protocol for older industrial drives, sensors and PLCs. The Modbus transport reads observation registers, sends them to the policy worker, and writes the validated action back to configured Modbus addresses. GA in 5.0.
When to use: integrating with motor drives, VFDs, energy meters, water-treatment equipment, anything where Modbus is already the operational protocol. Pairs naturally with WebSocket for the policy side and Modbus on the actuator side, when latency requirements are tight on the model call but the actuator is happy with Modbus polling rates.
Failure modes: connection loss is caught by the watchdog; the safety fallback engages and the binding state-machines toward failover if configured.
The OPC-UA transport binds the control loop to a PLC over the OPC-UA protocol. Subscribe to a set of OPC-UA tag values; the IoT worker assembles them into the observation; the policy worker returns the action; the IoT worker writes the action values back to the configured OPC-UA write tags. Pro+ tier. Preview through 5.0 RC1 — the C++ source ships in the release; the open62541 library bundles into the cluster RPM at the next cut, flipping the transport to GA.
When to use: existing PLC infrastructure, multi-vendor industrial fleets, anything where OPC-UA is the de-facto integration point. The platform speaks OPC-UA directly without a vendor-specific shim.
Failure modes: the OPC-UA session is monitored by the same watchdog. PLC connection loss triggers the safety fallback and reconnect.
The MQTT transport, configured for Sparkplug B namespacing, fans observations and actions out to a sensor / actuator fleet over an MQTT broker. Two halves with different status at GA: publish (actions to actuator topics) is GA — the IoT worker pushes validated policy outputs into your Sparkplug-B fleet via a per-actuator publish path. Subscribe (observations from sensor topics) stays preview — pulling observations through the policy worker needs a per-binding background subscriber + ring buffer that lands in the 5.0 patch line. Pro+ tier on both halves.
When to use: distributed sensor fleets where the actuators aren't co-located with the policy worker, IoT environments already using MQTT-Sparkplug-B for telemetry, deployments where the policy worker drives many independent control loops via one broker.
Failure modes: MQTT delivery is at-most-once on the actuator side by configuration (control commands shouldn't replay); the watchdog detects publish backpressure or broker disconnection and engages the safety fallback.
The watchdog is the line of defence between an unhealthy policy worker and your actuators. The watchdog enforces a per-tick latency budget — if a tick exceeds it, the IoT worker discards the late action and applies a configured fallback instead. Three fallback modes:
Write zero (or the actuator's configured zero) on every output. Safe default for actuators where "no command" is a quiescent state — robotic joints, motor torque, pump speed.
Write the last validated action again. Continues whatever the actuator was doing. Useful where the most recent action was known-safe and a sudden stop would be worse than continuing — e.g. coasting a moving robot to a stop rather than emergency-braking.
Hold the last action that passed all safety checks (clamps, limits, NaN). Stronger than freeze because it skips the most recent action if it was approaching a safety limit.
The state machine: a single missed tick puts the binding in degraded state; sustained misses past a configurable threshold trigger failover to a backup policy worker (if you've configured one) or stop the binding entirely (if you haven't). The configuration choice is yours per binding.
For control loops that must not stop, an admin configures a failover strategy on the binding:
For the broader robotics / industrial context, read robotics and smart manufacturing. For the IoT worker's complete protocol coverage, see the features catalogue § 10. For specific deployment questions: office@eldric.ai.