Industrial IoT

Five end-to-end industrial showcases riding the same platform — sandboxed Go/Python in k8s Jobs, LLM reasoning over the signals, pipelines fanning out alerts, work orders, designs, and shift reports.

Step 1 · Deploy Go DSP Asset

pump-dsp-correction · runs as a k8s Job on every window

Step 2 · Deploy RUL Estimator

rul-estimator · optional — smoothens cold-start estimates

Live systemMQTT…TSDB…Connectors 0…Live mode✗

Live mode

Step 3 · Stream vibration windows through the pipeline

10 windows over ~30s. Scripted fault trajectory: healthy → early bearing wear → acute imbalance. Each window runs validate → Go DSP (k8s Job)→ LLM diagnosis → RUL estimator → severity router → (CRITICAL/WARN: maintenance planner) → persist.

Deploy the Go DSP asset first.

Run on the edge

Same vibration window, but the classifier runs on a gateway pod next to the sensor — no WAN round-trip. Compare cloud vs. edge severity + latency below.

Edge agent: iot-pump-edge-classifierRuntime: RustGateway: edge-cluster-default

Industrial IoT · Scenario A

Predictive Maintenance for Rotating Machinery

Rotating equipment — centrifugal pumps, compressors, fans, motors — is the single biggest source of unplanned downtime in process industries. Every 24 hours a fault progresses, a plant loses 1–3% of its output capacity. This scenario shows the platform catching a developing fault beforethe outage.

Sampling rate

2 kHz

Shaft RPM

1800

Windows

10 over ~5 min

Latency target

<300 ms/window

The signal

A tri-axial accelerometer mounted on the pump housing streams raw vibration at 2 kHz. Every 250 ms we send one window (500 samples) into the pipeline.

The scripted trajectory goes healthy → early bearing wear → acute imbalance so you can watch the platform escalate its diagnosis window-over-window.

The Go DSP asset

Deployed from the browser as acode_asset — runs as a single-use k8s Job per invocation in the abenixnamespace, image golang:1.22-alpine.

Pipeline: detrend → median de-noise → FFT (Cooley–Tukey radix-2) → RMS / peak / crest / kurtosis → per-fault scoring → ISO 10816-3 zone.

LLM diagnosis

An agent reads the DSP output and decides severity + probable root cause. Rule-based thresholds get fooled when multiple faults overlap (bearing harmonics often sit right on 2× shaft), so the LLM reasons over the pattern, not just the numbers.

It cross-references against the tenant's knowledge base (ISO 10816 excerpts, failure mode catalogues) via knowledge_search.

RUL + work-order planning

A tiny exponential fit on recent health indices gives remaining useful life in hours. Optionally this can route to the uploaded Python RUL estimator for richer fits on long histories.

On CRITICAL a second agent drafts a structured work order (parts, crew, window) that could be handed directly to a CMMS.

Pipeline shape

validate → dsp (k8s) → diagnose (LLM) → rul → severity_router → plan_maintenance → final_report

Deterministic number-crunching stays in Go; pattern interpretation stays in the LLM. Nothing that can be cheaply reduced to a formula goes through tokens.

Why it matters

Bring-your-own code — no container push, no registry hassle.
Same request path runs on minikube locally and AKS in prod.
Every agent + tool call is recorded under /executions for audit.
Budgets, rate-limits, moderation gates apply to this flow like every other.

What runs under the hood

Every output on this page comes from one of the agents below. No client-side rule engine. The pipeline is wired live to the platform runtime.

agentiot-pump-pipeline

when · click "Start Stream"

inputs · one vibration window per call: {samples[], sample_rate_hz, sensor_id, shaft_rpm} + the pump_dsp_asset_id from the deployed Code Asset

outputs · severity (OK/WATCH/WARN/CRIT), root_cause, RUL hours, recommended action, work-order draft when severity is high

toolpump-dsp-correction

when · pipeline node 2 — Code Asset (Go)

inputs · raw vibration samples (uploaded as a sandboxed k8s Job)

outputs · FFT spectrum + dominant frequencies + crest factor + kurtosis + per-fault scores (bearing / imbalance / misalignment / cavitation) + ISO 10816 zone

agentiot-pump-diagnosis

when · pipeline node 3 — interprets the DSP read-out

inputs · structured FFT features from the Go DSP step

outputs · diagnosis JSON: severity + root_cause + confidence + 2-3 sentence rationale + recommended_next_reading_hours

toolrul-estimator

when · pipeline node 4 — Code Asset (Python)

inputs · historical health trajectory for the sensor

outputs · remaining-useful-life hours + confidence (rule-of-thumb fallback when there is not enough history yet)

agentiot-maintenance-planner

when · pipeline node 6 — fires only when severity_router says plan_required

inputs · diagnosis + RUL + the industrial-iot-knowledge KB (SOPs, FAA AC 120-78, GDP guidelines)

outputs · work-order draft with parts, hours, technician skill, urgency tier

What's simulated vs. live

In production — the source is a tri-axial accelerometer wired to a PLC / OPC-UA server (e.g. Siemens S7, AB ControlLogix). Samples are pushed at 2 kHz to an MQTT broker, queued in Kafka topicvibration.raw, and a long-running consumer dispatches one window every 250 ms into this same pipeline. Work-orders write back to the CMMS (SAP PM / Maximo / IBM TRIRIGA) via REST.

In the demo — the 10-window trajectory (healthy → early bearing wear → acute imbalance) is generated in-memory bylib/synthetic.ts when you click Start Stream. No timer, no MQTT, no Kafka — each window is POSTed to the standalone API one at a time, which forwards to the platform pipeline. The FFT, diagnosis, RUL, and work-order all come from the agents and sandboxed Code Assets above. Nothing is hardcoded on the client.

Click Start Stream to drive the pipeline through the scripted trajectory. Each window runs the full DAG — expect ~5 minutes end-to-end because real LLM round-trips are the long pole.