Motor Thermal Monitoring Digital Twin

01 — Overview

Beyond the alarm threshold

Industrial motors are among the most failure-prone components in manufacturing environments. Thermal stress causes insulation breakdown, bearing seizure, and catastrophic failure — often with no warning. This project builds a Motor Thermal Digital Twin that maintains a continuous model of the motor's thermal behaviour, classifies every reading with machine learning, controls a cooling fan automatically, and estimates time-to-failure before the motor gets there.

4

Swappable ML classifiers

30–60s

Predictive lead time

7

Docker services

50k

LSTM training sequences

2s

Sensor publish interval

5

MQTT topics

02 — Architecture

Edge-to-cloud, layer by layer

The system follows a layered architecture with five clearly separated concerns. The key design decision: reactive and predictive AI run in completely independent containers. A crash in the predictive service cannot affect fan control logic that keeps the motor safe.

system-architecture.diagram

Device Layer

🔌 ESP32 + LDR Sensor ADC1 / GPIO34

🐍 python-device (simulator) profile

Messaging Layer

📡 Eclipse Mosquitto 2.0 :1883

▼ MQTT publish-subscribe ▼

Reactive AI (python-edge)

⚡ Z-Score Baseline default

🌳 Decision Tree

🌲 Isolation Forest adaptive

🌳 Random Forest robust

Predictive AI (python-predict)

📈 Linear Slope Baseline fast

🧠 LSTM Neural Network 30–60s lead

▼ MQTT alerts + risk scores ▼

HMI Layer

🖥 Node-RED Dashboard :1880

Storage & Visualisation

🗄 InfluxDB 2.7 :8086

📊 Grafana Digital Twin :3000

03 — Reactive Classification

Four algorithms, one interface

All four algorithms share an identical two-function contract — load_model() and classify(temperature, window). Switching is a single commented import line and a container rebuild.

ALGORITHM 0

Z-Score Baseline

No training Stateless < 0.1 MB

Computes z = (T − μ₅₀) / σ₅₀ and applies hard thresholds. Acts as the regression baseline — if any other algorithm performs worse on known test scenarios, something is wrong.

ALGORITHM 1

Decision Tree

~1s training Explainable < 1 MB

Trained on synthetic Gaussian regimes with max_depth=6 and balanced class weights. Rules can be printed and read by a human — invaluable when debugging edge cases.

ALGORITHM 2

Isolation Forest

~400s live Unsupervised ~5 MB

No labels needed. Learns what "normal" looks like and flags deviations. Self-calibrates thresholds from live data and refits every 1,000 readings — the only algorithm that adapts to hardware drift.

ALGORITHM 3

Random Forest

~3–5s training Probabilistic ~10 MB

100 trees with tunable probability thresholds (WARNING ≥ 0.40, CRITICAL ≥ 0.50). Lower WARNING threshold intentionally catches early cases at the cost of minor false-positives — a sound safety tradeoff.

04 — Predictive Maintenance

Know before it happens

The predictive service estimates whether the warning threshold will be crossed within the next few minutes, based on a sliding buffer of the last 30 readings (60 seconds of history). It publishes a continuous risk score from 0 to 1 and an estimated time-to-warning.

30–60s

Early warning lead time achieved with the LSTM model.
The risk score crosses 0.5 approximately 30–60 seconds before the temperature reaches the 85 °C warning threshold — giving operators time to slow a production line, dispatch a technician, or increase monitoring frequency before the reactive alarm fires.

LSTM Architecture

Input: 30 time steps × 3 features (temperature, delta, z-score)
→ LSTM(64 units)
→ Dropout(0.2)
→ Dense(32, ReLU)
→ Dense(1, sigmoid) → risk probability 0–1

Trained on 50,000 synthetic sequences · tflite-runtime inference (~5 MB) · Target AUC-ROC ≥ 0.95

05 — MQTT Topics

Five topics, clear ownership

Raw sensor readings stay local. Only processed alerts are forwarded to the cloud SCADA broker — reducing bandwidth and avoiding off-site leakage of operational data.

Topic	Publisher	Purpose
sensors/group10/motorTemp/data	ESP32 / simulator	Raw temperature every 2 s — local only
alerts/group10/motorTemp/status	python-edge	Anomaly status + score → local & cloud SCADA
control/group10/motorTemp/fan	python-edge / Node-RED	Fan relay ON/OFF command to ESP32
control/group10/motorTemp/mode	Node-RED	AUTO / MANUAL switch (retained message)
predict/group10/motorTemp/risk	python-predict	Risk score 0–1 + ETA minutes

06 — Quick Start

One command to run everything

The entire stack — broker, edge AI, predictive service, historian, and dashboards — starts with a single command. No manual configuration needed.

bash

# Clone the repository

$ git clone https://github.com/cepdnaclk/e20-co326-Motor-Thermal-Monitoring-Digital-Twin.git

$ cd e20-co326-Motor-Thermal-Monitoring-Digital-Twin

# Start with real ESP32

$ docker compose up --build

# Or start with the software simulator (no hardware needed)

$ docker compose --profile simulation up --build

# Watch the edge AI classify in real time

$ docker logs -f python-edge

[EDGE ] temp=86.10°C z=+2.841 status=WARNING ai_fan=ON mode=AUTO window=50

[EDGE ] temp=91.73°C z=+3.902 status=CRITICAL ai_fan=ON mode=AUTO window=50

[EDGE ] temp=68.20°C z=+0.182 status=NORMAL ai_fan=ON mode=AUTO window=50

07 — Team

Group 10

Department of Computer Engineering · University of Peradeniya · CO326, 2026

Haritha Bandara

E/20/037

Architecture edge_ai.py Fan hysteresis Cloud SCADA

Yohan Senanayake

E/20/363

ML algorithms Feature engineering Isolation Forest Random Forest

Chamodi Senarathne

E/20/365

LSTM Predictive service InfluxDB Grafana

Janith Wanasinghe

E/20/420

Docker Compose Hardware (ESP32) InfluxDB routing Provisioning