Predictive Maintenance Using IoT: Building a Prototype

This blog post is a transcription of our joint webinar with Toradex, presented by our IoT and embedded systems team lead Andrei Andreyanov.

In the following sections we provide an overview of the prototype development project, as well as the specifics of how we combined machine learning, cloud computing, and IoT technologies to achieve project success. Predictive maintenance using IoT is an area poised for continued growth in the industrial sector, which was our inspiration for this prototype project.

For a brief overview of this project go to the predictive maintenance IoT case study page. The full webinar is available on our YouTube channel:

Drive your digital transformation to the next level with our world-class cloud migration and development services

Intro to Prototype Project

Our IoT and embedded technology team successfully created a predictive maintenance system that detects and analyzes the state of a brushless DC electric motor.

The system collects motor performance parameters, transmits them to Amazon Web Services (AWS), and applies machine learning algorithms to identify the motor state.

We primarily used Amazon Greengrass and Amazon Lambda technologies.

Project Concept

No modern production process is possible without the use of electric motors (regardless of the industry). So, we set our sights on the creation of a solution that assesses the behavior of an electric motor. Based on that behavioral assessment, we could then determine the status of the motor in real-time.

For this project, the embedded and IoT development teams were tasked with building a predictive maintenance IoT prototype that analyzes the state of a motor based on vibration frequency and force. In our project concept, we decided that focusing on the vibration and force of the motor would be the best way to analyze its behavior and operating status.

We needed to establish a baseline of motor activity (e.g. normal operation boundaries, on/off, failure, etc.). For example, if the main shaft of the motor is bent, the motor vibrates and produces fluctuations that are different than those occurring in the normal operating state.

Project Goals: Practical & Technical

Practical Goals

  • From the practical perspective, businesses need to continuously monitor their production assets (including machines remotely connected to their network/the internet).
  • One of our goals with this project was to create a fully functional alert feature. This would signal any issues, problems, or variations in the state of the motor directly to the end user.

Technical Goals

  • In the technical context, we were focused around truly getting the most out of modern technology to enhance the monitoring functionality of the motor state.
  • That’s why we chose to rely on AI technology to detect abnormal motor behavior via data analytics and pre-trained machine learning models.
  • We also implemented simultaneous algorithm updates across all devices on the network, which enables better analysis of the results and also provides real-time data updates.

Why We Chose a Cloud-Based Solution

If companies opt to go a more traditional route (i.e. solutions not rooted in cloud technology), there are a few key requirements that cannot be overlooked:

  • The entire solution needs to be developed and implemented in a protected environment.
  • Traditional solutions require dedicated servers for updates.
  • Dedicated servers require additional employees to manage them.
  • Non-cloud solutions don’t provide sufficient system and data monitoring.
  • Traditional solutions are quite time consuming and implementation will likely be very expensive.
  • Algorithm maintenance is already complex, and if an algorithm fails in a non-cloud solution it is very difficult to stop or reload.

For predictive maintenance using IoT, we opted for cloud technologies because they provide significant advantages over traditional solutions. The cloud enables streamlined software development, updating, and monitoring, as well as increased security and flexibility.

Azure vs AWS

When choosing a cloud solution for our system we decided to use MS Azure (Microsoft IoT Edge) and AWS (Greengrass). We decided to use two different cloud technologies because we wanted a flexible system that wouldn’t be locked to a singular provider.

So that’s why we trained our system using Azure, while using AWS for the actual deployment.

Read also. Comparison AWS vs Azure vs Google.

Platform Interaction Scheme

We attached a vibration sensor to the brushless DC motor. The sensor acquires vibration data from the motor, and transmits it to the Toradex development board. On the board we implemented Amazon Greengrass, which analyzes the state of the motor in real-time.

There are three main states that it recognizes:

  1. Off (when the motor is stopped).
  2. Normal (when the motor is on).
  3. Abnormal state (which identifies malfunctions such as being under or overvoltage, or other abnormal states).

The model used for computation can be deployed for predictive maintenance using IoT via an IoT or edge computing-enabled device through AWS, Azure cloud storage, etc.

The board reports the motor status via a web interface or various communication protocols such as MQTT, SMTP, etc. (depending on the company’s business requirements).

Training Process

The training process has three steps. We collected parameters that are specific to each motor state:

  1. When the motor is operating
  2. When it is stopped
  3. When it is operating abnormally

We trained the model based on these specifications, and the data is collected via the InvenSense MPU6050 sensor.

Prediction Process

The sensor collects data which is then sent to the pre-trained model. Each dataset matches a specific class (e.g. off, running, or fail). The model collects the datasets and arranges it according to these parameters.

  • The result can be displayed through a web interface, LCD, or one of the supported communication protocols.
  • The state that is displayed by the prediction model depends on the collected data and the current state of the motor – it’s presented and updated in real-time.

Toradex Computer-on-Module

As the framework for our predictive maintenance prototype we used the Toradex NXP i.MX 6ULL ARM CPU (Colibri iMX6ULL).

  • The connection interface is SODIMM compatible, and the COM features support for wireless and bluetooth communication.
  • The model also provides LTS support through 2028, which is convenient for industrial use cases.
  • The COM’s operational temperature ranges from -30 to 85+ degrees celsius, making it useful in a wide range of environments.

Vibration Sensor Details

predictive maintenance using IoT with the InvenSense MPU-6500

We used the MPU6050 by InvenSense, which combines two different types of devices under one hood.

  • The sensor contains two 3-axis devices: a MEMS gyro and MEMS accelerometer. Both of these devices are also combined with a digital motion processor.
  • This sensor provides the ideal level of accuracy for gyro and accelerometer data processing.
  • While it’s in active mode, it features a low level of power consumption, and also has numerous control interface options.

Predictive Maintenance Using IoT Project Success

  • We successfully developed a predictive maintenance prototype that produces 85-99% accurate prediction results.
  • For model training, we successfully implemented AI-based algorithms for enhanced data collection and analysis.
  • We used innovative IoT, cloud computing, and edge computing technologies. These technologies allowed us to create a high-power system that provides accurate motor state predictions.
  • The Toradex board we utilized provided us with the proper technical requirements for building an industrial predictive maintenance system.

Video Demo

Watch the live prototype demo on our YouTube channel here, or simply click the play button below:

Are you looking for outsource software development? Get a free consultation and estimate from tech experts!

About Toradex:

  • Toradex was founded in 2003 in Switzerland, and has over 3,000 active customers across the world. A fast-growing company with 100+ employees across nine countries.

SaM Solutions’ IoT expertise:

  • SaM Solutions’ IoT expertise has been utilized by companies across numerous industries including retail, automotive, consumer products, and manufacturing. For more information check out our IoT development services page. Predictive maintenance using IoT technology has been an area we’ve been focusing on for numerous years, which is one of the reasons why we initiated this prototype development project.

Andrei Andreyanov, SaM Solutions senior software engineer:

  • Embedded systems lead and Linux developer experienced in kernel drivers development/integration, bootloader/kernel customization for project-specific needs including DeviceTree, BSP (board-support packages), Yocto, cross-compilation, and scripting. Significant experience in developing solutions for ESP-32, ARM, AM335x, Samsung S3C2410 CPU, Atmel’s AVR; PCB prototyping/soldering and hardware design.

Author

Dmitry Koshkin

Dmitry Koshkin

Managing Director, SaM Solutions USA

FAQ

Is there potential to scale the solution to more complex multi-sensor systems? What are the options and constraints?
In our case, I think we would be able to easily scale the prototype via additional sensors (e.g. optical sensors, microphones, etc.). Taking precise data from different sources, for example taking voltage level sensors to detect the state of controller or motor. To help the system predict when something might go wrong we can use the pre-trained model as well as the data collected from voltage sensors. It just depends on the specific requirements of the project.
Which model did you use on the iMX6ULL and which framework?
Jupyter Notebook and Keras. Both Jupyter and Keras can be used on Azure and AWS. The main feature that I think is important, we can use the algorithm on either Azure or AWS, which can be very convenient depending on customer needs. Some customers require Azure, some require AWS, so we pushed the concept that the solution can be implemented on both and transferred between platforms with no issues.
What other hardware models could we use on a similar project?
(Toradex answer): You could possibly use a lot of hardware models we have for such a project, because the interface requirements aren’t that high. You can search for products, and filter product requirements on our webpage (toradex.com). There are numerous boards that could be used for such projects. It always depends on what your requirements are, and then you should choose the best-fitting hardware for your needs.
Does the solution have the potential to scale the machine learning concept? What are the constraints, and can you give us an example of such cases?
It can definitely be extended and scaled, because it is possible such functionality when the model can be trained by itself. But, it will require much more effort to do so, but yes it’s possible. For example, using AWS or Azure solutions, the device can update itself using new data and to make the prediction results more precise, or add extra functionality. This might require additional staff, for example to update Amazon Lambda. The algorithm consists of two parts. Lambda has the code written on Python,or node.js, which is then deployed from AWS to the board using Greengrass.
  • Lambda runs the machine learning model, and collects the prediction data from the sensor.
  • Lambda then passes this data to the model, and provides the prediction results to the web or video interface.
So in this type of case, additional staff would be needed to ensure the training is running properly and prediction results remain accurate.
Are there any delays in data collection and transferring with this system?
There may be the possibility of some slight delays (i.e. two microseconds). Some packages, say one or two, might be lost. In the case of our prototype, this isn’t really a problem. But in a real-world system, it would require real-time operation, more precise sensors, and maybe other types of interfaces such as SPI. SPI communicates at a higher speed than I²C interfaces. Using something like SPI would deliver the results faster than I²C. It just depends on the project.
Why use near real-time processing in the demo? Is there an option to go real-time for example in IIoT scenarios?
Yeah sure, it’s possible to go real-time. In this case, it would require using some type of pre-kernel firmware, which is kind of a pre-OS operating system. This would allow code and hardware access to be implemented in real-time. In the case of a real-time operating system, the pre-OS level technology would provide real-time operation while the OS-level technology would provide user interface communication.