Predictive Maintenance on a Linux Edge Gateway

From One Vibration Node to a Plant-Wide System

A single vibration node tells you when one bearing is degrading. A plant-wide predictive maintenance system tells you which of two hundred machines to inspect this week, why, and what to do about it. The gap between those two is not a better model — it is an aggregation and reasoning layer that lives on a Linux edge gateway.

Device-level predictive maintenance is mature and cheap. An MCU with a MEMS accelerometer runs an on-device anomaly detector and flags deviations from a learned baseline. Guides like ESP32 predictive maintenance with Edge Impulse and STM32F4 predictive maintenance with TFLite cover that node-level work end to end. Each node does one job well: decide locally whether this machine looks abnormal.

What a single node cannot do:

• Correlate across machines. A vibration spike on a conveyor motor means something different when the upstream press is also drawing abnormal current.
• Apply process context. Anomaly scores during a known cleaning cycle or a product changeover should be suppressed, not alerted on.
• Integrate with the business. A flag has to become a work order in the CMMS, with the right asset, priority, and recommended action.
• Survive fleet scale. Two hundred nodes generate two hundred independent alert streams. Without correlation, that is alert fatigue, not insight.

That is the role of the gateway.

What the Gateway Aggregates

The gateway sits above the OT devices and pulls their data together. In a typical line it ingests:

Source	Protocol	Example signal
Vibration / current MCU nodes	MQTT	Anomaly score, FFT features
PLCs and drives	Modbus TCP/RTU	Motor load, speed, fault bits
Modern PLCs / SCADA	OPC-UA	Tag values, alarms, machine state
Energy meters	Modbus	Power, current per phase
Process historian	MQTT / REST	Setpoints, recipe, shift

Standards like ISO 13374 (condition monitoring and diagnostics of machines) describe this exact data-processing chain — data acquisition, manipulation, state detection, health assessment, prognostics, and advisory generation. The device nodes handle acquisition and state detection; the gateway is where health assessment, prognostics, and advisory generation come together across assets.

Correlating Signals Across Machines

Single-machine anomaly detection produces a stream of “this looks different” events. Correlation turns those into ranked, contextualized findings.

Concrete examples of cross-machine reasoning the gateway can do that a node cannot:

• Causal ordering. If the upstream gearbox anomaly consistently precedes the downstream motor anomaly, the gearbox is the lead indicator — alert there first.
• Common-cause suppression. If every node on a line spikes simultaneously, the cause is usually shared (supply voltage sag, ambient temperature) rather than two hundred simultaneous failures.
• Operating-context gating. Cross-reference the OPC-UA machine state. An elevated vibration score while running at high speed under load is expected; the same score at idle is not.

This is where combining ML anomaly scores with rule logic earns its keep. The model says “abnormal”; the rules encode what the plant already knows about its process.

Combining ML, Rules, and LLM-Assisted Diagnostics

A robust gateway decision blends three layers:

1. ML anomaly scores from the device nodes (and optionally larger models on the gateway).
2. Deterministic rules — thresholds, debounce windows, operating-state gates, maintenance-window suppression.
3. LLM-assisted diagnostics — a language model summarizes the correlated evidence into a plain-language hypothesis and recommended next step for the technician.

The LLM is an advisor, not an oracle. It explains why the gateway is raising a finding (“motor 12 vibration and current both trending up over 6 days, consistent with bearing wear, no recent maintenance logged”) so the human triages faster. The deterministic rules — not the LLM — decide whether an alert fires.

sensor/MCU nodes (MQTT) ──┐
PLC / drives (Modbus) ─────┼──► gateway ──► [ML scores] ──► [rules] ──► [LLM summary]
SCADA tags (OPC-UA) ───────┘                                                │
                                                                            ▼
                                                          CMMS work order / dashboard alert

Alerting and CMMS / Work-Order Integration

A predictive maintenance finding is only useful if it reaches the maintenance workflow. The gateway should:

• Create or update a CMMS work order (Maximo, Fiix, UpKeep, SAP PM) via REST/API, pre-filled with asset ID, evidence, and suggested action.
• Push dashboard alerts (Grafana, MQTT topic, email/Teams) with severity derived from the rule layer.
• Deduplicate — one open finding per asset until resolved, not a new alert every inference cycle.

Keeping the PLC Authoritative

This is the non-negotiable boundary. The gateway is advisory, not control. It reads from the OT network and writes to maintenance and analytics systems — it does not close control loops, does not write setpoints that affect safety, and does not override PLC interlocks. The PLC remains the system of record for control and safety. That separation keeps the existing safety case intact and makes the predictive maintenance layer something you can add without re-certifying the machine.

Data Retention and Auditability

Reliability and audit functions need to reconstruct why a finding was raised months later. The gateway should retain:

• Raw and derived signals at the resolution needed for replay (full waveform on event, downsampled trends otherwise).
• The anomaly scores and the model version that produced them.
• Which rules fired, with their thresholds at that time.
• Any LLM reasoning text and the action taken (work order ID, acknowledgement, outcome).

With those records, every decision is replayable from its inputs — the basis for trusting an advisory system and for tuning it as the plant changes.

How ForestHub Fits

ForestHub is the edge agents orchestration platform. It runs on your Linux edge gateway as a Go binary in Docker — reading sensors and machines over MQTT, Modbus, and OPC-UA — and orchestrates the sense-reason-act loop as a deterministic graph where the LLM is one node among many: inspectable, replayable, auditable.

In predictive maintenance terms, ForestHub is the gateway layer described above. The device nodes keep doing inference on the machine; ForestHub aggregates their scores, correlates across the line, applies your rule logic, uses the LLM node for diagnostic summaries, and raises the CMMS work order — while the PLC stays authoritative over control. Because the loop is a graph rather than opaque prompt chaining, every finding is traceable from raw signal to action. See ForestHub solutions for plant-level deployment patterns.

Start at the device with a node-level guide such as ESP32 anomaly detection with Edge Impulse, then bring those nodes together on the gateway.