Low-Cost Industrial IoT System for Wireless Monitoring of Electric Motors Condition

Abstract

Condition monitoring of industrial equipment has become a critical aspect in Industry 4.0. This paper shows the design, implementation and testing of a low-cost Industrial Internet of Things (IIoT) system designed to monitor electric motors in real-time. This system can be used to detect operating anomalies and paves the way for building predictive maintenance models. The system is built using low-cost hardware components (wireless multi-sensor modules and single-board computers as gateways), open-source software and open cloud services, where all the relevant information is stored. The module collects real-time vibration data from electric motors. Vibration analyses in the temporal and frequency domains were carried out in both modules and gateways to compare their capabilities. This approach is also a springboard to using edge/fog computing to save cloud resources. A system prototype has been tested in the laboratory and in an industrial dairy plant. The results show that the proposed system can be used for continuous monitoring of any rotatory machine with similar accuracy to professional monitoring devices but at a significantly lower cost.

Introduction

Electric motors are essential in the modern industry: they are ubiquitous in manufacturing, electric power generation and petrochemical plants to name but a few. Unforeseen failures of equipment powered by electric motors can provoke high economic losses, making equipment maintenance essential.

Traditional reactive maintenance only carries out maintenance activities after failure detection. Widespread preventive maintenance implies periodic maintenance activities based on previous experience about the periodicity of failure. Predictive maintenance is an ideal approach for saving costs and preventing equipment failure. In Industry 4.0, failures are predicted based on real-time information received from sensors in industrial equipment [1].

Condition monitoring is now the most powerful tool for predictive maintenance. It is based on online monitoring of physical variables for fault diagnosis. Most failures can be identified as anomalous vibration, sound or electric current profiles, in the time and frequency domains [2].

In this paper, we present a prototype of a real-time monitoring system based on low-cost wireless multi-sensor modules. It can be used to detect operating anomalies and to collect vibration datasets for implementing predictive maintenance of electric motors. Apart from having a significantly lower cost than professional monitoring devices, it offers continuous monitoring, vibration frequency analysis and fog computing. It can collect measurements efficiently and as accurately as portable vibration analysers. However, this system requires neither specialized staff nor third-party licensed software to analyse the collected data.

The rest of the paper is organized as follows. Previous research works are outlined in Section 2. The proposed monitoring system is presented in Section 3. Section 4 details the experimental plan carried out. Results are discussed in Section 5. Finally, Section 6 contains the concluding remarks and outlines future work.

Background

Condition monitoring is one of the bases of Industry 4.0 [3]. Many systems have been developed to monitor current, pressure, temperature and other variables in industrial plants. With the advances in microelectromechanical systems, it is possible to deploy myriads of low-cost sensors capable of sensing, computing and communicating wirelessly to gather information for environment and equipment monitoring [4]. These sensors are connected using wireless sensor networks. They send data to the cloud for storage or further processing using IoT protocols and technologies [5]. Many public cloud service providers offer IoT services using standard protocols for real-time storage and develop analytics from the data. This makes it possible to use historical data to predict future equipment failures.

On occasions, the amount of data to be sent to the cloud or the latency of sending data to the cloud and back to the sensors/actuators is excessive. In these cases, moving part of the computation close to the sensors may alleviate the resources consumed in the network and the cloud. The fog computing paradigm promotes the use of resources of smart sensors and gateways interconnecting sensors in conjunction with the cloud resources [6, 23]. Fog deployments require defining the topology for interconnecting sensors and with gateways providing access to the cloud. Sensors usually generate data streams that can be pre-processed, aggregated or filtered before reaching the cloud [7]. Similarly, some of the data analytics may be carried out by gateways. Thus, the organization of the fog is critical for balancing computing load and network resource consumption in order to save public cloud costs and reduce latency.

Detection of operation anomalies can be carried out even when no data from previous failures in the equipment is available [8]. When available, machine-learning models based on binary classification are used to predict failures in the near future in order to plan repairs or equipment replacement [9]. The prediction models are trained and tested using the historical labelled data with information about previous failures in the equipment. The amount of historical data can be huge, so real-time storage in the cloud is an effective solution, giving rise to cloud based predictive maintenance [10].

Induction electric motors are major actuators in most industrial factories, so cloud based predictive maintenance of electric motors is of special importance. This is supported by the amount of research work in the field in recent years [11]. Mechanical and electrical failures produce vibration in electric motors with different amplitudes and frequencies [12]. Thus, solutions monitoring the health of motors mainly focus on measuring vibration and temperature.

Currently, there are two main types of systems used to measure vibrations in industrial rotatory machinery. Firstly, there are sensors directly installed by the manufacturers of the machinery. These are designed to be used with specific software and proprietary data formats from the manufacturer. Secondly, there are portable vibration analysers [13, 14]. Not only do they use specific software and proprietary data formats, but they are also expensive devices not suitable for continuous monitoring due to the need to carry out in-place analysis by specialized staff.

An IoT solution for the monitoring of industrial machinery in an electric plant is presented in [15]. The authors use an IoT protocol stack composed of 802.15.4, 6LoWPAN, RPL and CoAP to monitor temperature and vibration of several pumps. However, they do not analyse vibration in the frequency domain nor include any cloud processing.

There are also solutions using the cloud as storage for further processing of the monitored temperature and/or vibration signals of inductive motors [16, 17]. The main drawback of this approach is that data is rarely filtered or pre-processed taking advantage of intermediate systems between the sensors and the cloud. The authors in [18] propose sending raw data to a private cloud in order to prepare training and testing datasets to be sent to a machine-learning model in the public cloud.

Finally, there are deployments using low-cost equipment to monitor vibration in industrial equipment [19,20,21]. A framework for distributing computationally demanding tasks across sensors, fog nodes and the cloud is presented in [22]. Gateways at the fog layer perform computation and classification of vibration signals coming from sensors attached to motors. However, this solution does not analyse vibration in the frequency domain.

The main contribution of this paper is the development of a prototype that brings together continuous monitoring with low-cost multi-sensor modules and gateways, vibration frequency analysis and fog computing, proposing an innovative way towards predictive maintenance applications in Industry 4.0. It efficiently collects measurements comparable with portable vibration analysers without the need of specialized staff.

Monitoring system

The following subsections present the architecture, components and software features of the monitoring system.

System architecture

As can be seen in Fig. 1, the system architecture is composed of three layers in which the information can be processed. The first layer is the edge layer, which is composed of all the IoT sensors. The second layer is the fog layer, which contains the gateways. The last layer is the cloud, where all the relevant data is stored, visualized and analysed.

Fig. 1

System architecture

All the layers have computing capacity. In the edge layer, the filtering, aggregation and data transformation is carried out directly by the sensors. The fog layer allows the gateways to collect data from multiple sensors using Bluetooth Low Energy (BLE) and continue processing them. Both the edge and fog layers help distribute the processing of information between sensors and the cloud, improving latency and reducing the amount of data to transfer to the cloud.

System components

The multi-sensor module used in the edge layer is the low-cost SensorTile.box by ST Microelectronics (Fig. 2), which features an ARM Cortex-M4 processor with DSP and FPU, 2 MB of programmable flash memory and eight integrated sensors, including movement and humidity sensors. LM6DSOX is the movement sensor. It has an accelerometer, a magnetometer and a gyro, measuring vibrations with an output data rate of up to 5 kHz. The humidity sensor is the HTS221. It measures the relative humidity and the temperature of the environment. The module supports wireless communication with the BLE protocol. The wireless nature of the module allows for very fast and economical deployment in the industrial environment.

Fig. 2

Multi-sensor module (left) and gateway (right)

The gateway used in the fog layer is the low-cost single-board computer Raspberry Pi 4 Model B, shown in Fig. 2. It features 4 GiB RAM, two micro-HDMI ports, two USB 2.0 ports, two USB 3.0 ports, as well as one CSI and one DSI port to connect a camera and a touchscreen. The Ethernet interface supports data rates up to 1 Gbps. It also includes WiFi, Bluetooth 5.0 and BLE interfaces. The CPU + GPU is the Broadcom BCM2711 (4C Cortex-A72 ARM v8 64-bit SoC @1.5 GHz). It has been integrated into an aluminum case with a fan to keep the temperature of the device stable.

Fig. 3

Cloud

Finally, the cloud layer is composed of an MQTT broker, Node-RED, InfluxDB and Grafana (see Fig. 3). The gateway is connected to the MQTT broker and publishes messages with the bin amplitudes of the computed spectra. These messages are received, processed and stored in an InfluxDB database by various Node-RED flows. Finally, this data is displayed on a dashboard using Grafana. It is an open-source cloud which can be containerized, facilitating its deployment in any infrastructure, public or private.

System software

A custom firmware for the multi-sensor module has been developed, allowing the accelerometer to sample vibration at 5 kHz with a range of 8 G. These samples in time domain do not provide enough insight into the vibration of the electric motor to identify anomalous conditions. Two steps must be followed. First, acceleration data is filtered and integrated to obtain velocity. Second, raw velocity data is transformed into the frequency domain using the Fast Fourier Transformation (FFT). Data is windowed using a Hanning window to prevent aliasing. The output of the FFT is the root mean square (RMS) velocity amplitude as a function of frequency. FFT is computed in both the multi-sensor module and the gateway to evaluate the capacity of each to support that processing task. Within the module, the library used is the CMSIS DSP software library, designed for use in Cortex-M processor based devices. The FFT computation using this library uses an array with a maximum of 8192 velocity samples over time, due to memory limitations. Within the gateway, the function used is FFT from the SciPy python library, using an array of up to 65536 samples. These intervals, of 8192 and 65536 samples, equivalent to 1.6 and 13 seconds of motor operation, monitor enough revolutions of the motor to cover its whole dynamic behaviour while allowing good precision (number of bins) in the frequency spectrum.

Multi-sensor modules and gateways communicate using the BLE protocol, which is used to transmit small packets of data read by the multi-sensor modules, while consuming less battery power than other protocols. The main drawback of this protocol is its communication range: no more than a few meters can be reached between two BLE devices in indoor areas. Finally, data is transferred from the gateway to the cloud layer using MQTT.

Experimental plan

An IIoT prototype addressing the proposed architectural model has been developed and deployed in two scenarios. The prototype was initially deployed and tested in the laboratory to monitor a low-power motor with no workload. Using the results of these tests, the prototype was upgraded and deployed in an industrial factory to monitor two electric motors with real workload.

Scenario 1: Low-power motor in laboratory

The first scenario uses a single-phase asynchronous electric motor with a permanent capacitor and a speed of 1500 rpm. It has a power output of 0.25 kW and a voltage of 250 V/50 Hz. This motor was bolted to the floor of the laboratory to avoid vibrations due to loose mounting. The multi-sensor module was stuck to the motor plate using double-sided adhesive tape. The gateway was positioned close to the module. The gateway processes the data received from the module and sends the captured data to the cloud layer.

Scenario 2: Pumps in an industrial dairy plant

The second scenario corresponds to an industrial dairy plant (see Fig. 4). In this case, two pumps are monitored. These pumps have a speed of 3000 rpm, a power output of 15 kW and a voltage of 230 V/50 Hz. The pumps work in different production lines and are monitored in different months of the annual maintenance cycle for changing bearings. Two multi-sensor modules (front and back) are fixed to each pump using metal zip ties (see Fig. 5) and connected to a gateway that communicates with the cloud layer via a WiFi Access Point (AP). Figure 6 shows the location of the pumps and the corresponding gateways in the dairy plant.

Fig. 4

Scenario 2: industrial factory

Fig. 5

Scenario 2: multi-sensor modules locations

Fig. 6

Scenario 2: pumps and gateways locations

Keeping BLE radio on most of the time to send raw acceleration samples may be a concern in the multi-sensor modules from the point of view of energy consumption. However, multi-sensor modules may be powered with the same power lines used for the motors, so batteries are not necessary.

Results

This section shows the results of testing the prototype in the laboratory and the industrial scenario.

Scenario 1

The fast Fourier transform was used to calculate the amplitude spectrum (0 to 2500 Hz) in both multi-sensor (edge layer) and gateway (fog layer) devices to assess the maximum resolution achieved and the resources consumed. Figure 7 shows the lowest 500 Hz of the amplitude spectra computed by the multi-sensor module, the gateway and a popular portable vibration analyser (model COMMTEST VB8). Although the spectra in Fig. 7 are not directly comparable as they correspond to different times of the motor operation, all the graphs show three relevant amplitudes in frequency bins around 100, 200 and 300 Hz. These frequencies are harmonics of the double line frequency (2XLF), which is 50 Hz in Europe.

Fig. 7

Spectra

The resolution of the spectrum computed in the gateway is 0.076 Hz, but higher resolutions are also possible at the cost of longer capturing and transmission times. In contrast, the maximum resolution achieved in the spectra computed in the multi-sensor module is 0.61 Hz due to limitations of the CMSIS DSP library. In most conditions this resolution is enough. However, on occasions a higher resolution spectra may be necessary to differentiate close frequency components or sidebands.

Fig. 8

Data processing time for FFT

Figure 8 shows the time needed to run the FFT algorithm in the multi-sensor module and the gateway. FFT sizes over 8192 samples are not possible in the multi-sensor module due to CMSIS DSP library limitations. In the case of the gateway, it is possible to compute FFTs of 65536 samples. The figure shows that the higher computing power of the gateway causes the time difference to increase with the FFT size. Nevertheless, the processing times in both the multi-sensor module and the gateway are adequate for most applications.

Fig. 9

Latency components

Table 1 Components of data latency

Depending on where the spectrum is computed, the total latency until the captured signal is transformed into the frequency domain and available at the gateway may vary. This latency has two components (see Fig. 9): the time to compute the FFT (either at the multi-sensor module or the gateway) and the transmission time of data from the multi-sensor to the gateway. There are two situations to consider for the transmission time. When the FFT is computed at the multi-sensor module, this time corresponds to the transmission of the resulting FFT bin amplitudes (see Fig. 9a), while when the FFT is computed at the gateway, this time corresponds to the transmission of the raw acceleration samples (see Fig. 9b). The times indicated in Fig. 9 are defined in Table 1.

The capture of acceleration samples is carried out using two memory buffers, so that while one of them is being filled the other is transmitted. Thus, most of the transmission time of the raw data to the gateway is overlapped with the capture ($t_{t1}$). However, the BLE link limits the transfer speed, so the transmission time grows dramatically with large FFT sizes, since large numbers of raw samples must be transmitted.

Fig. 10

Latency when processing FFT

Figure 10 shows the contribution of each component to the latency when processing FFTs of different sizes at the multi-sensor module and gateway. In both cases, the transmission time is the factor that contributes to the latency the most. Latencies reduce in the gateway due mainly to lower transmission times. Depending on the application, latency may be critical. Long-term detection of operation anomalies in the motor due to component wear do not benefit from low latency processing. However, low latency is necessary to achieve real-time monitoring and fast short-term detection of operation anomalies. Immediate identification of loose, imbalanced or incorrect mounting of motors bearings after a scheduled maintenance shutdown is essential to prevent personal or equipment damage.

Transmission speed mainly depends on the network link strength. A study was carried out to determine the maximum distance possible between the multi-sensor module and the gateway. A gateway was positioned at a fixed point and a multi-sensor module was moved progressively further from the gateway, with no obstacles between them, taking the RSSI level between the devices for each position. In order for a signal to be considered good, providing reliable packet forwarding, it must have an RSSI level above -80 dBm [25]. According to the results shown in Fig. 11, the RSSI level is above -80 dBm for distances under 11 meters.

Fig. 11

RSSI vs. distance gateway-multisensor

In addition to a maximum distance, BLE imposes some restrictions on the number of multi-sensor modules that can be handled by a single gateway. As empirically tested, the maximum number of multi-sensor modules that can be managed at the same time by a gateway is 15. Additional modules fail to connect to the gateway. Therefore, a gateway can handle up to 15 multi-sensor modules simultaneously as long as they are within a range of 10 meters.

The gateway has to deal with most of the computational workload in the case that FFTs are computed at the gateway. Figure 12 shows the average time needed to compute the FFT in the worst case, when the gateway is computing the FFTs of all the multi-sensor modules simultaneously. The computation time depends on the sizes of the FFTs and the number of modules. The figure shows that time increases linearly with the size of the FFTs.

Fig. 12

FFT computing time from 1 to 15 sensors

Scenario 2

The spectra from the two pumps in the dairy plant exhibit peaks at close frequencies and sidebands, so high precision spectra are necessary. Thus, FFTs are only computed at the gateway (fog layer) in this scenario: the multi-sensor modules periodically send raw acceleration samples to the gateways.

Wireless communications are challenging in the industrial dairy plant, not only because there are metal pipes all over the plant, but also because the pumps where the multi-sensor modules were deployed, as well as the gateways, are placed in metallic cabinets to protect them from frequent floor cleaning operations with water (see Fig. 6) . Therefore, although the distances separating multi-sensor modules and gateways are within the optimal range (around 5 meters), obstacles between them significantly reduce the maximum transfer speed. As a result, the latency of communications dramatically increases.

Fig. 13

Latency in scenario 2 (FFT at gateway)

Figure 13 shows the components of the latency when computing FFTs of different sizes at the gateway for a single axis. The processing time corresponds to 2 concurrent FFTs, one for each multi-sensor module, and its contribution to latency is negligible. As expected, the transmission time is prevalent because the period between packet transmissions must be enlarged to avoid packet loss. Comparing this figure with Fig. 10, latency is seen to increase 8-10 times, reaching the order of minutes for the highest FFT size. This information is essential when taking a decision about the FFT size. A trade-off between latency and resolution of the spectrum must be considered. According to this analysis, spectra with the highest resolution (using 65536 acceleration samples) can be computed for the three axes every 6 minutes.

Fig. 14

Dashboard window to monitor vibrations of pump 1

Fig. 15

Amplitude spectrum of pump 1 with zoom-in details

A visualization dashboard has been built in Grafana for continuous monitoring of the front and back vibration (at the three axes) of the two pumps in the dairy plant. Figure 14 shows one of the windows in dashboard corresponding to the front broadband RMS vibration amplitudes, at the three axes, for pump 1. The temporal resolution in the window is 6 minutes and the whole period represented corresponds to one operation cycle of the pump (40 hours approximately). The coloured horizontal lines correspond to thresholds established by International Standard 20916-1:2016 [24] to indicate the severity level of vibrations. The dashboard helps monitor the health of the pumps throughout their operating cycles and detect possible anomalies in the operation, such as the peak observed close to the centre of the window.

The vibration spectrum at every point in the dashboard window can also be computed to further analyse the vibration signal. This can be used to look for anomalies during pump operation. Figure 15 shows the spectrum of the vibration signal corresponding to one of the samples depicted in Fig. 14. Feature extraction techniques can be used to select important frequency bins from the spectrum. The amplitude and the evolution of the amplitude for these bins during pump operation is critical. As an example, two relevant frequency bins in the spectrum shown in Fig. 15 are those around 49.2 Hz and 246 Hz. The first bin corresponds to the running speed of the pump motor (1X) and the second bin corresponds to the vane pass frequency (VPF) of the pump. As the pump impeller has 5 vanes, the VPF is 5 times the 1X frequency. The actual amplitudes of the frequency bins can be calculated based on the amplitudes of close bins around the peak ($A_j$) and the noise power bandwidth of the window used (1.5 for the Hanning window) with Eq. 1.

$$\begin{aligned} A_\text {estimated} = \frac{\sum _{i = j - 3}^{j + 3}\text {A}_i}{\text {noise power bandwidth of window}} \end{aligned}$$

(1)

Fig. 16

1X and VPF amplitude evolution in pump 1

Figure 16 shows the variation of amplitude corresponding to 1X and VPF peaks during an operation cycle of pump 1. The variations in amplitude during the cycle are due to changes in the pressure of the milk rather than to changes in the pump state. This spectrum analysis can be used for automatic detection and diagnosis of anomalies during the pump operation.

Conclusions and future work

The design, implementation and testing of a low-cost IIoT system for condition monitoring of electric motors in real-time has been presented. The system is designed using low-cost hardware components: wireless multi-sensor modules and single-board computers as gateways, open-source software and open services in the cloud. The modules collect real-time vibration data from electric motors. Vibration analyses in the temporal and frequency domains have been conducted to detect operation anomalies and facilitate predictive maintenance of electric motors through low-cost real-time monitoring.

The proposed system architecture considers edge and fog computing layers as an alternative to cloud layer for computing application tasks. The capabilities of multi-sensor modules on the edge layer and of the gateways on the fog layer are compared. Vibration frequency is analysed as an example of a critical application task. The results of the comparison are easily applicable to other modules and gateways with similar characteristics, aiding in the decision as to where to compute the critical task most efficiently.

Future work will be geared towards developing an automatic anomaly detection system at the gateway. If the gateway detects important changes in the amplitudes of the relevant frequency bins, it will notify the maintenance technicians, warning that there may be a relevant change in the condition of the motor and preventing unforeseen outages.