Embedded AI Anomaly Detection: Architecture of an

By IOTINNOV — Embedded engineering team · August 22, 2026

Embedded AI Anomaly Detection: Architecture of an Industrial Edge AI Pipeline

In Industry 4.0, predictive maintenance is no longer a luxury: it is a regulatory and economic requirement. Yet sending every sensor reading to a centralised cloud brings latency, bandwidth and cost. The answer? An Edge AI pipeline that handles the anomaly as close to the source as possible — on the microcontroller itself.

This article describes a real architecture: an IMU and a pressure sensor on an ESP32-S3, a TensorFlow Lite Micro pipeline with an 8-bit quantised LSTM model, and local decision-making with an MQTT alert sent only when an anomaly is detected. No abstract theory: every architectural choice is justified by real memory, energy and latency constraints.

The problem: why the cloud alone fails

An industrial site with 50 connected compactors generates roughly 1.2 TB of raw data per month (3-axis IMU at 200 Hz plus pressure sensors at 50 Hz, 16 bits). Transferring all of it to a cloud costs bandwidth, storage and processing. But the real problem is not cost: it is detection time.

A mechanical defect (bearing wear, a slowly developing hydraulic seal leak) evolves over time scales ranging from minutes to a few hours. If detection goes through the cloud, the accumulated latency (acquisition → transmission → processing → alerting) reaches 30 to 90 seconds under real conditions (3G/4G with variable signal, shared network). Yet a failing bearing on a compactor can cause a major breakdown in under 5 minutes under maximum load.

The cloud remains essential for aggregation, visualisation and model retraining. But detection has to be local.

Architecture of the Edge AI pipeline

The system described rests on four independent layers that communicate through defined interfaces:

Layer 1 — Raw acquisition (sensors and analogue front end). Two sensors are used: a BNO08x IMU (orientation, acceleration, gyroscope, 9 DOF) to detect abnormal vibration, and a differential pressure sensor to track fill level and seal condition. Sampling is synchronised by a hardware timer on the ESP32-S3 (t = 5 ms, that is 200 Hz) and buffered in a circular memory of 512 samples (2.56 s of history).

Layer 2 — Embedded pre-processing. Before reaching the model, the data goes through a real-time signal-processing pipeline on the ESP32-S3: a Butterworth low-pass filter (fc = 20 Hz) to remove motor switching noise, sliding-window normalisation (mean and standard deviation over 1 s), and extraction of 12 features (RMS values, kurtosis, skewness of the 3 axes, amplitude of the dominant frequency peak). This processing consumes ~8 % of the ESP32-S3 CPU (240 MHz, dual-core Xtensa LX7) and runs in a dedicated thread isolated from the network thread.

Layer 3 — TensorFlow Lite Micro inference model. The model is an int8-quantised LSTM (Long Short-Term Memory) network trained on a corpus of 3,200 hours of industrial recordings (machines in good condition and machines with known defects: worn bearing, hydraulic leak, shaft misalignment). Model architecture: input shape (timesteps=32, features=12), one LSTM layer with 32 units, one dense layer with 16 neurons and ReLU, and a binary output (normal / anomaly) with a threshold of 0.78. The quantised model weighs 84 KB, fits in the ESP32-S3 RAM (8 MB of total SRAM, 2 MB reserved for the model, buffers and stack) and runs inference in 23 ms per window.

Layer 4 — Decision and conditional transmission. If the model returns an anomaly probability above the threshold (0.78), the system triggers two actions: (a) an immediate alert message over MQTT (topic iot/compactor/alert, JSON payload with timestamp, estimated anomaly type, sensor value and confidence score) sent in under 100 ms, and (b) a local save of the raw data segment (the 2.56 s preceding the alert) to SPI flash memory (4 MB) for post-incident analysis. If the model returns normal, nothing is transmitted to the network — a bandwidth saving estimated at 97 % compared with continuous transmission.

Model training and quantisation

Training is done offline, on a server equipped with an NVIDIA A100 GPU, with the source code versioned in Git. The dataset consists of 320,000 windows of 32 samples (about 3,200 h of data). The training procedure: (1) z-score normalisation across all features, (2) train/val/test split (70/15/15), (3) LSTM training with Adam (lr = 1e-3, batch = 128, epochs = 50 with early stopping on validation loss), (4) evaluation: 94.2 % precision, 91.7 % recall, 92.9 % F1.

After training, int8 quantisation is applied with the TensorFlow Lite Converter: the float32 model (2.1 MB) is converted into a quantised model (84 KB) with a precision gap of less than 2 % on the test set. This quantisation is essential: a float32 model would not fit in the ESP32-S3 RAM and inference would take several seconds — unacceptable for a real-time system.

One critical step is often forgotten: validation on deployment data. After quantisation, the model must be tested on real hardware with data collected on site, because quantisation can introduce systematic errors on certain features (notably kurtosis, which is particularly sensitive to int8 rounding). We recommend a 48-hour calibration phase per site before going into production.

Performance and real-world constraints

The benchmarks measured on an ESP32-S3 (rev 1.2, ESP-IDF 5.3 firmware, 240 MHz) are as follows:

Inference time (32 × 12 window): 23 ± 3 ms
RAM used (model + buffers + stack): 2.1 MB out of 8 MB available
Power consumption (inference + conditional MQTT transmission, 1 h average): 78 mA at 3.3 V (0.26 W), that is ~6.2 Wh/day — compatible with a 10 W solar panel plus a 12 Ah LiFePO4 battery
Alert latency (detection → MQTT published): 98 ± 15 ms (3G with average signal)
On-site accuracy (3 months of operation, 2 industrial sites): 92.8 % (slight degradation compared with validation, due to noise in the specific environment)
Reduction in transmitted data: 97 % (only alerts and a heartbeat every 15 min are sent)

The LSTM model was chosen over a CNN or a Transformer for two reasons: (a) the LSTM captures the temporal dynamics of sensor series better, and (b) its parameter count is lower (32,768 parameters compared with 128,000+ for an equivalent CNN). For multidimensional data with a strong temporal component, the LSTM remains the best trade-off between accuracy, size and speed on a microcontroller.

Integration into a multi-equipment system

An industrial site does not have one piece of equipment, but several. The pipeline described above can be replicated on each unit (compactor, skip, pump, generator set) with parameters adapted to the type of machine. Aggregation at site level is done through an MQTT broker (Mosquitto or HiveMQ) that receives only the conditional alerts from each unit. The supervision dashboard (React + WebSocket) then displays a consolidated status without having to process raw data streams.

This architecture follows two essential principles: independence of local processing (each unit can operate on its own, even if the network goes down) and bandwidth efficiency (only the signal of interest crosses the network). It applies directly to industrial telemanagement systems where the number of units and the reliability of connectivity are primary constraints.

Conclusion. Edge AI is not a substitute for the cloud: it is a pre-processing layer that makes the industrial system faster, more robust and less costly. On an ESP32-S3, a quantised LSTM model of 84 KB reaches 92.8 % accuracy with an inference latency of 23 ms. For a technical decision-maker the message is clear: anomaly detection no longer needs a datacenter. It needs a good sensor, a good model, and an architecture that knows when to speak — and when to stay silent.

IOTINNOV designs and implements these pipelines on real industrial equipment: industrial-grade sensors, secured MQTT architectures and embedded processing boards. Our telemanagement platform, proven on industrial compactors, can be adapted to your needs.

Pipeline security: authentication and integrity

An anomaly pipeline targeting an industrial machine is also a network access point. Possible attacks fall into three categories: (1) data injection — an attacker replaces the sensor stream with false data, preventing a real anomaly from being detected; (2) MQTT broker spoofing — an attacker publishes false alerts to trigger unnecessary interventions; (3) model extraction — the LSTM model is intellectual property and must be protected.

At the acquisition layer, each sensor communicates with the ESP32-S3 over I2C with a CRC-8 checksum on every frame. Corrupted data is rejected (not written into the circular buffer), which prevents injection in the form of noise. At the MQTT layer, the broker uses TLS 1.3 with mTLS: each unit holds an X.509 certificate signed by an internal CA, and the broker verifies the client certificate before accepting the connection. The topic iot/compactor/alert is protected by an ACL: only the compactor key can publish, and only the supervision dashboard can subscribe. To protect the model, the .tflite file is stored in flash memory with a SHA-256 hash verified at boot. Any modification of the model (corruption or malicious replacement) triggers a safe shutdown of the system and a report to the supervision centre.

Comparison with embedded alternatives

Choosing an LSTM on an ESP32-S3 is not the only option. Three alternatives are commonly evaluated:

Edge Impulse (quantised CNN on ESP32): excellent for vision and frequency-domain signal processing, but less suited to multivariate time series. Inference time ~18 ms, accuracy 89 % on the same dataset — below the LSTM on this specific data.
ONNX Runtime Micro: more generic and compatible with several models (ResNet, BERT-lite), but the runtime occupies 1.8 MB of RAM and inference is slower (45 ms for an equivalent model). Useful when the same unit has to run several different models.
Micro-ML (TensorFlow Lite Micro with custom models): similar to the pipeline described, but with finer control over quantisation (int4 is possible on some architectures). Not tested on the ESP32-S3 because of the lack of compiler support for int4.

For a system dedicated to anomaly detection on industrial sensors, the quantised LSTM remains the best trade-off between accuracy, size, speed and power consumption.

A worked example: a multi-machine industrial site

To illustrate what this changes in the field, take a site running a dozen compactors over a quarter. The pipeline surfaced several genuine anomalies, all confirmed by physical inspection — bearing wear on two machines, a seal leak on one, shaft misalignment on the others. A couple of false alarms were also triggered by an exceptional event (an accidental chemical spill that temporarily changed the vibration signature). After retraining the model on those extra examples, accuracy rose from 92.8 % to 94.1 %.

The economics are easy to grasp: an undetected failure on an industrial compactor generally means an emergency call-out, unplanned downtime and a replacement part fitted under pressure, whereas an anomaly caught by the model is handled in a planned intervention at a fraction of the cost. In the scenario above, every anomaly surfaced by the pipeline was repaired on schedule rather than in emergency mode.