EdgeGuard AI: Arm-Optimized Predictive Maintenance

Smarter Machines. Safer Labs. Powered by Arm Edge AI.

Comment

EdgeGuard AI: Arm-Optimized Predictive Maintenance

Inspiration

Engineering laboratories, educational workshops, and small industries commonly use motors, fans, pumps, and other rotating equipment. These machines may develop abnormal vibration, overheating, or excessive current between scheduled inspections. If such conditions are not detected early, they can cause equipment failure, laboratory downtime, energy loss, or safety hazards.

This inspired me to develop EdgeGuard AI, a low-cost Physical AI system that performs predictive maintenance directly on an Arm-powered edge device. Instead of sending sensitive sensor data to the cloud, EdgeGuard AI makes decisions locally, providing low latency, offline operation, and improved privacy.

What It Does

EdgeGuard AI monitors ten equipment-condition features derived from:

  • Vibration RMS and peak values
  • Vibration crest factor
  • Temperature and temperature rise rate
  • RMS and peak current
  • Supply voltage
  • Sound level
  • RPM variation

The AI model classifies equipment condition into four categories:

  1. Normal
  2. Mechanical imbalance
  3. Overheating
  4. Electrical overload

Based on the detected condition, the system recommends an appropriate action, such as continuing operation, inspecting shaft alignment, activating cooling, or isolating an overloaded machine.

A live browser dashboard displays sensor readings, class probabilities, risk score, inference time, historical trends, and the recommended action. Optional Raspberry Pi GPIO outputs can activate an LED, buzzer, or safely isolated relay interface.

How I Built It

I created a deterministic synthetic dataset representing the operating characteristics of small rotating equipment. Synthetic data made the project reproducible and allowed all fault scenarios to be demonstrated without requiring judges to own a particular motor or sensor kit.

The machine-learning model is a multilayer perceptron with:

  • 10 input features
  • Two hidden layers using ReLU activation
  • 4 output classes
  • Softmax-based class probabilities

The model was trained using Python and scikit-learn. A held-out validation dataset is included in the repository so that the FP32 and INT8 implementations can be evaluated using identical samples.

For deployment, I implemented the inference engine in C++17. The web dashboard uses Python’s standard HTTP library with offline HTML, CSS, and JavaScript, avoiding heavy frameworks and unnecessary dependencies.

The complete Physical AI workflow is:

Sensor Features → Local AI Inference → Risk Classification
       → Maintenance Decision → Alert or Actuator Request

Arm-Specific Optimization

The baseline model stores its parameters as 32-bit floating-point values. The optimized model uses symmetric signed INT8 quantization.

For each weight tensor, the quantization scale is calculated as:

[ s_w = \frac{\max(|w|)}{127} ]

The quantized weight is obtained using:

[ q_w = \operatorname{clip}\left(\operatorname{round}\left(\frac{w}{s_w}\right),-127,127\right) ]

During inference, the approximate dense-layer output is reconstructed as:

[ \hat{y}=s_xs_w\sum_i q_{x_i}q_{w_i}+b ]

where (s_x) and (s_w) are the input and weight scales, while (b) is the floating-point bias.

The native inference engine uses Arm NEON intrinsics for INT8 matrix-vector operations when compiled on supported Arm hardware. A portable scalar implementation is also included for development and testing on non-Arm computers.

The supplied benchmarking tool compares:

  • FP32 and INT8 model sizes
  • Mean inference latency
  • Classification accuracy
  • Prediction agreement
  • Optimization speed-up or latency trade-off

All performance results are generated directly on the target device so that the reported values are transparent and reproducible.

Challenges I Faced

One major challenge was ensuring that quantization reduced model storage without significantly changing the model’s predictions. I addressed this by testing the FP32 and INT8 implementations on the same held-out validation examples and automatically checking their accuracy and prediction agreement.

Another challenge was creating a genuine Physical AI demonstration without making specialised sensors mandatory. I developed a realistic sensor-feature simulator that feeds the same inference pipeline intended for real hardware. This allows normal operation, imbalance, overheating, and overload to be demonstrated instantly.

Maintaining compatibility with different Arm devices was also important. The INT8 kernel therefore uses broadly supported NEON operations and does not require newer dot-product extensions.

Finally, GPIO control introduced safety considerations. The relay output is disabled by default and requires explicit activation. The documentation clearly states that a Raspberry Pi must never be connected directly to mains voltage or high-current equipment.

What I Learned

This project taught me that edge-AI optimization involves more than simply converting weights to INT8. Model size, accuracy, latency, hardware architecture, compiler optimization, and runtime overhead must be evaluated together.

I also learned the importance of reproducibility. Including the training script, model-export process, validation dataset, automated tests, and benchmark artifact makes the project easier for other developers to verify and extend.

Most importantly, EdgeGuard AI demonstrated how Arm-powered devices can combine embedded systems, machine learning, sensor processing, and physical actions in a practical offline application.

Accomplishments

  • Developed a complete sensor-to-decision Physical AI workflow.
  • Implemented FP32 and INT8 inference engines.
  • Added an Arm NEON-optimized INT8 kernel.
  • Created an offline professional monitoring dashboard.
  • Included automated tests and reproducible benchmarking.
  • Supported simulated sensors and optional Raspberry Pi GPIO.
  • Provided one-command setup and detailed documentation.
  • Released the complete project under the MIT License.

What’s Next

Future development will include collecting labelled data from real motors, integrating ADXL345 or MPU6050 vibration sensors, adding isolated current and temperature sensors, and comparing performance across different Arm processor generations.

I also plan to add machine-specific calibration, remaining-useful-life prediction, and maintenance scheduling. These improvements could transform EdgeGuard AI from an educational prototype into a practical low-cost condition-monitoring platform for laboratories and small industries.

Built With

Share this project:

Updates

Submission history