HKD | USD

Use a Kit to Rapidly Develop an Industrial Predictive Maintenance Application

By Stephen Evanczuk

Contributed By Digi-Key's North American Editors

The availability of low-cost smart sensors has enabled increasing levels of industrial equipment monitoring to the point that predictive maintenance is now possible. For many developers, however, the tasks of gathering, structuring, communicating, analyzing, and applying sensor data for predictive maintenance remains elusive because of the complexity of both the required hardware and application software.

To meet rapidly growing interest in predictive maintenance, semiconductor vendors are making available comprehensive platform solutions that combine much of the required hardware and software. With such platforms, industrial applications developers can more quickly and cost effectively get predictive maintenance systems up and running.

This article discusses the modern concept of predictive maintenance using the Internet of Things (IoT) and how it can greatly improve processes and outcomes. It then introduces a predictive maintenance platform from STMicroelectronics and shows how developers can use this hardware and software to evaluate predictive maintenance functionality and develop their own applications.

The evolution of maintenance from guesswork to prediction

Industrial engineers have for years used vibration analysis and other methods to detect problems in machinery. In the past, engineers relied on handheld analyzers or other dedicated test equipment for collecting and processing data for equipment analysis. Enabled by IoT concepts, manufacturers can now instrument critical equipment with low-cost sensors able to provide the detailed data streams needed for real-time monitoring.

The ability to continuously assess equipment performance offers an important advantage for factory operations. Now, industrial engineers can use local or remote monitoring applications to augment or even replace scheduled manual maintenance programs that expend effort where no problem exists, or that come too late to prevent small problems from escalating to equipment damage. Instead of reacting to problems that can shut down production lines, factory operators can use sensor-based methods to identify those problems in advance, stage required resources or even replacement machinery, and perform repairs at a time that minimizes disruption to production.

Predictive maintenance presents the opportunity for facilities managers to catch problems before they become catastrophic failures, allowing them to maintain the integrity of the production line and the safety of workers, while also analyzing that data to improve processes and outcomes. The challenge for developers becomes one of creating a platform able to gather data at the bandwidth and resolution required to detect signs of underlying problems in the monitored equipment.

For vibration analysis, industrial engineers typically collect vibration data in both time and frequency domains. Experienced engineers can identify mechanical problems in equipment just by viewing data in these two domains. For example, periodic short duration pulses with a wide frequency bandwidth typically indicate that a component such as a ball bearing has a defect that causes it to strike the wall of its track at each rotation. Conversely, long duration events with narrow bandwidth can indicate that components are rubbing against each other, eventually leading to wear and possible failure.

To capture this data reliably, however, vibration sensors need to be sufficiently robust to maintain their operation despite sudden shocks, intense vibration, or any of the other characteristics commonly encountered in industrial environments. Even under normal operation, industrial equipment can generate vibration and mechanical shock that can exceed the capabilities of earlier vibration sensors. The emergence of sensors based on microelectromechanical systems (MEMS) technology has largely eliminated that concern. MEMS sensors like the STMicroelectronics ISM330DLC can survive bursts of acceleration up to 10,000 g for 0.2 milliseconds (ms), yet recover quickly enough to provide linear acceleration measurements with milli-g sensitivity.

Although reliable data from motion sensors is essential for failure analysis, vibration is only one indicator of machine health. Just as experienced engineers can discern specific failure modes from vibration data, they use other sensor modalities to determine the time from detection of a symptom to the functional failure of the equipment, called the potential-to-failure (P-F) interval. For example, increased power consumption, noise, or heat typically suggests a decreased P-F interval for most machinery (Figure 1).

Graph of vibration analysis typically enables early detection

Figure 1: Different sensor modalities can reveal conditions that indicate a machine's potential to fail, but vibration analysis typically enables early detection and helps eliminate downtime due to sudden failure. (Image source: STMicroelectronics)

To capture these additional indicators, engineers need to create sensor systems able to capture vibration, audio, pressure, temperature, and humidity at a minimum. For developers, however, the practical challenges of combining these sensors in a robust design can significantly delay progress toward larger objectives for equipment analysis. The STMicroelectronics STEVAL-BFA001V1B development kit and associated software provide a comprehensive platform that lets engineers jumpstart applications for equipment monitoring and predictive maintenance.

Reference platform

The STEVAL-BFA001V1B kit serves as both a reference design and off-the-shelf solution that includes an industrial sensor board and associated software for predictive maintenance. The board is a complete standalone sensor system (Figure 2). It combines a high-performance STMicroelectronics 32-bit Arm® Cortex®-M4 STM32F469 MCU with a full set of sensors, including the ISM330DLC motion sensor for vibration measurement mentioned earlier, as well as STMicroelectronics’:

Diagram of STMicroelectronics STEVAL-BFA001V1B development kit

Figure 2: Included in the STMicroelectronics STEVAL-BFA001V1B development kit, the MCU-based industrial sensor board design includes a full complement of sensors typically required for equipment monitoring. (Image source: STMicroelectronics)

The system supplements the microcontroller's integrated 2 Mbyte flash memory with STMicroelectronics’ M95M01-DF 1 Mbit EEPROM, and includes power management capabilities with the STMicroelectronics L6984A switching regulator and LDK220 low dropout (LDO) regulator. To simplify deployment in industrial environments, the board includes an M12 connector on one end, supported by an ST L6362A IO-Link transceiver. On the other end of the board, an expansion connector provides developers with access to the microcontroller's GPIO, analog-to-digital converter (ADC), and I2C serial interface. The result is a robust system that is only slightly larger than an M12 industrial cable yet capable of meeting the full set of requirements for equipment monitoring (Figure 3).

Image of STMicroelectronics STEVAL-BFA001V1B industrial sensor board

Figure 3: The STMicroelectronics STEVAL-BFA001V1B industrial sensor board includes the microcontroller-based multisensor system, expansion connectors, serial wire debug (SWD) connector, and M12 connector in a form factor only slightly larger than an industrial cable. (Image source: STMicroelectronics)

Developers can use the M12 cable included in the kit or add their own M12 connectors. The kit includes an adaptor board for connecting the M12 sensor board's serial output to the ST-LINK/V2-1 interface that comes with an STMicroelectronics STM32 Nucleo-64 development board. To power the board, developers can supply power themselves through the M12 cable or plug the M12 cable into the ST STEVAL-IDP004V1 IO-Link evaluation board. Using this IO-Link board provides the most rapid path to development as developers can quickly connect multiple industrial sensor boards and use STMicroelectronics’ Windows-based STEVAL-IDP005V1-GUI_v1.0 graphical user interface (GUI) to configure them (Figure 4).

Image of ST Windows GUI

Figure 4: Using the ST Windows GUI, developers can quickly configure sensor boards, perform data collection, and view results for frequency and time domain motion data, as well as environmental data. (Image source: STMicroelectronics)

After they complete setup on the configuration screen, developers can move to the Vibration Analysis screen for data collection. After clicking on the start button, developers can view vibration frequency and rotational speed measurements collected in the x, y, and z axes (Figure 5). A separate screen for environmental measurements (ENV Measures tab) allows developers to view pressure, temperature, and humidity data collected by each sensor board.

Image of ST Windows GUI offers a simple approach (click to enlarge)

Figure 5: The ST Windows GUI offers a simple approach for evaluating sensor data with its ability to present frequency and time domain results from the motion sensor. (Image source: STMicroelectronics)

Software development

Although the GUI application provides quick access to the sensor board's capabilities, developers will need a more flexible approach for creating their own predictive maintenance applications. For custom development, STMicroelectronics’ STSW-BFA001V1 software package provides a full set of C software modules including drivers, libraries, and sample applications (Figure 6).

Diagram of ST STSW-BFA001V1 software distribution

Figure 6: The ST STSW-BFA001V1 software distribution provides a complete set of drivers and middleware along with sample applications that developers can run immediately and use later as the basis for their custom applications. (Image source: STMicroelectronics)

Among its software samples, the STSW-BFA001V1 package includes a condition monitoring application that demonstrates the process of collecting sensor data and generating frequency domain, RMS, and peak acceleration values from a motion sensor. For a production design, developers could upload this data to a host application designed to detect failures. The predictive maintenance application extends this data collection foundation with features designed to generate warnings of possible failures.

There are many advantages to this approach, but the most compelling is the ability to extend P-F intervals by providing early detection of conditions that signal potential failures. Another advantage is the movement of failure detection closer to the equipment, providing a more immediate recognition of failures.

The STMicroelectronics predictive maintenance application demonstrates how developers can perform this early detection by comparing sensor readings with a series of threshold values for speed, acceleration, and frequency components. In a production system, selection of these threshold values depends on multiple factors well beyond the scope of this article.

However, it’s important to note that there are standards to use for reference. For example, ISO 10816 provides guidance on vibration values for four classes of machines running in four different operating zones including Zone A (good), Zone B (satisfactory), Zone C (unsuitable for continuous operation), and Zone D (critical with possible damage with continued operation). As these zones suggest, operators should be warned when a machine's vibration levels reach Zone C and be presented with a more urgent alarm when those levels reach Zone D.

STMicroelectronics designed its predictive maintenance application to support this specific use model. A header file (MotionSP_Threshold.h) within the sample application software set includes threshold values for both warning and alarm levels. In this case, STMicroelectronics defined warning thresholds at the ISO 10816 recommended values for operation between the boundary of Zone B and C. Alarm threshold values are ISO 10816 values between the boundary of Zone C and D. Because a typical motion sensor such as the STMicroelectronics ISM330DLC provides data in the x, y, and z planes, three values are provided each for warning, and alarm thresholds for each monitored quantity – RMS speed, acceleration, and fast Fourier transform (FFT). The application uses thresholds for FFTs in four different spectral subranges.

The result is a set of threshold values consistent with a wide range of realistic machine operational states. Nevertheless, developers would of course need to adjust these warning and alarm threshold values to match the specific characteristics of their monitored equipment and overall objectives for warnings and alarms.

While the header file provides the operational targets for monitoring, the main routine (main.c) provides the logic for detecting threshold excursions in data collected by the industrial board's sensors. After initializing the hardware and associated software structures, the main routine enters an endless loop for generating the FFT for vibration data, measuring RMS and peak acceleration, detecting threshold crossings, and transmitting warnings (Listing 1).

Copy
  /* Initialize the motion sensor */
  MotionSensorInit();
  MotionSP_TimeDomainAlarmInit(&sTdAlarm,&sTimeDomainVal,&sTdRmsThresholds,&sTdPkThresholds);
  MotionSP_FreqDomainAlarmInit(&FDWarnThresh,&FDAlarmThresh,&THR_Fft_Alarms,MotionSP_Parameters.subrange_num);
  /****************************************************************************/
 
  while (1)
  {
    /* Vibration Analysis */
    MotionSP_Vibration_manager_run(&MotionSP_Parameters);
    /* Status check during Time domain Analysis */
    MotionSP_TimeDomainAlarm(&sTdAlarm,&sTimeDomainVal,
                             &sTdRmsThresholds,
                             &sTdPkThresholds,
                             &sTimeDomain);
    if(FinishAvgFlag == 1)
    {
      SendVibrationResult();
      TD_Thresholds_DataSend(&sTdAlarm,&sTimeDomainVal);
   
      MotionSP_FreqDomainAlarm (&SRAmplitude, FDWarnThresh, FDAlarmThresh,
                                MotionSP_Parameters.subrange_num,
                                &THR_Check, 
                                &THR_Fft_Alarms);
      
      FD_Thresholds_DataSend(MotionSP_Parameters.subrange_num,
                             &SRBinVal,
                             &THR_Fft_Alarms,
                             &THR_Check);
      
      MotionSP_TotalStatusAlarm(&sTdAlarm,
                                &THR_Fft_Alarms,
                                MotionSP_Parameters.subrange_num,
                                &TotalTDAlarm,
                                &TotalFDAlarm);
      
      Thresholds_DataSend(&TotalTDAlarm, &TotalFDAlarm);
      
      FinishAvgFlag = 0;
      RestartFlag = 1;
 
      // wait while the UART is transmitting
      while((HAL_UART_GetState(&hSrvUart) & HAL_UART_STATE_BUSY_TX ) == HAL_UART_STATE_BUSY_TX);
      strcpy((char *)SrvUartTxBuffer, "\r\n|#################### Next Measurement ####################\r\n");
      HAL_UART_Transmit(&hSrvUart, SrvUartTxBuffer, strlen((char *)SrvUartTxBuffer), SRV_UART_TIMEOUT_MAX);
     
      MotionSP_TimeDomainAlarmInit(&sTdAlarm,&sTimeDomainVal,
                                   &sTdRmsThresholds,&sTdPkThresholds);
      MotionSP_FreqDomainAlarmInit(&FDWarnThresh,
                                   &FDAlarmThresh,
                                   &THR_Fft_Alarms,
                                   MotionSP_Parameters.subrange_num);
 
      /* Configure the Hardware using parameters in RAM */
      MotionSP_Vibration_manager_init(&MotionSP_Parameters, 1);
 
      Accelero_MeasurementInit();
    }
  }

Listing 1: The STMicroelectronics predictive maintenance application demonstrates use of an endless loop for identifying and transmitting alarms based on frequency and time domain sensor data measurements. (Code source: STMicroelectronics)

As the loop continues to execute, sensor drivers and service handlers in the board support package read data and fill buffers monitored by higher level routines. The STMicroelectronics sample software assigns handlers at the application level, allowing developers to easily substitute their own routines to meet unique requirements without plunging deeply into the software architecture.

At each iteration of the main loop, the main routine calls MotionSP_TimeDomainAlarm() to check thresholds for RMS speed and peak acceleration. For frequency domain checks, the main loop repeatedly calls MotionSP_Vibration_manager_run(), which indirectly calls another module's routine, MotionSP_FrequencyDomainProcess(), which finally calls a middleware FFT calculation routine if the required circular buffer (AccCircBuffer) is sufficiently full and the FFT is enabled (Listing 2). As it happens, the basic condition monitoring application uses this same pattern.

Copy
/**
  * @brief  Frequency Domain Processing starting from the Circular Buffer
  * @param pMotionSP_Parameters: Pointer to board parameters
  * @return None
  */  
void MotionSP_FrequencyDomainProcess(sMotionSP_Parameter_t *pMotionSP_Parameters)
{
#define FFTSIZEDELTA  (MotionSP_Parameters.size*((100.0-MotionSP_Parameters.ovl)/100.0))
 
  if (fftIsEnabled == 1) {
      if (!accCircBuffIndexWaitForOvf) {
        if (AccCircBuffer.IdPos >= accCircBuffIndexForFft) {
        
        MotionSP_FFT_All_Axes();
        
        accCircBuffIndexForFft += FFTSIZEDELTA;
        if (accCircBuffIndexForFft >= AccCircBuffer.Size) {
          accCircBuffIndexForFft -= AccCircBuffer.Size;
          accCircBuffIndexWaitForOvf = 1;
        }
      }
    }
    else {
      if (AccCircBuffer.Ovf) {
        AccCircBuffer.Ovf = 0;
        accCircBuffIndexWaitForOvf = 0;
      }
    }
  }
}

Listing 2: This routine from the STMicroelectronics sample application illustrates a mechanism for working with a circular buffer of data from a motion sensor for frequency domain analysis. (Code source: STMicroelectronics)

At the end of each measurement epoch, the application uses another routine (MotionSP_TotalStatusAlarm()) to examine each attribute of motion data, setting the frequency domain alarm (pTotalFDAlarm) and time domain alarm (pTotalTDAlarm) to the maximum alarm value (Listing 3). In turn, the main routine in Listing 1 transmits these alarms via UART connection before reinitializing the system for the next measurement epoch.

Copy
void MotionSP_TotalStatusAlarm(sTimeDomainAlarm_t *pTdAlarm,
                               sFreqDomainAlarm_t *pTHR_Fft_Alarms,
                               uint8_t subrange_num,
                               Alarm_Type_t *pTotalTDAlarm,
                               Alarm_Type_t *pTotalFDAlarm)
{
 Alarm_Type_t TempAlarm = GOOD;
 Alarm_Type_t TempFDAlarm = GOOD;
 
 TempAlarm = MAX4(TempAlarm,
                  pTdAlarm->PK_STATUS_AXIS_X,
                  pTdAlarm->PK_STATUS_AXIS_Y,
                  pTdAlarm->PK_STATUS_AXIS_Z);
 
 
 TempAlarm = MAX4(TempAlarm,
                  pTdAlarm->RMS_STATUS_AXIS_X,
                  pTdAlarm->RMS_STATUS_AXIS_Y,
                  pTdAlarm->RMS_STATUS_AXIS_Z);
 
 for(int i=0; i<subrange_num; i++)
 {
   TempFDAlarm = MAX4(TempFDAlarm,
                      pTHR_Fft_Alarms->STATUS_AXIS_X[i],
                      pTHR_Fft_Alarms->STATUS_AXIS_Y[i],
                      pTHR_Fft_Alarms->STATUS_AXIS_Z[i]);
 }
 
 *pTotalTDAlarm = TempAlarm;
 *pTotalFDAlarm = TempFDAlarm; 
  
}

Listing 3: The STMicroelectronics sample application demonstrates the basic design pattern for working with multiple alarm sources in a predictive maintenance application. (Code source: STMicroelectronics)

The STMicroelectronics sample application allows developers to quickly evaluate predictive maintenance features and functionality. More directly, developers can simply connect to the industrial sensor board through a terminal emulation program to immediately begin viewing measured values and warning/alarm status.

For a production application, however, developers will more likely use the sensor board's serial interface to connect to upstream resources for more sophisticated application monitoring and control. Major cloud service providers already offer advanced machine learning solutions for predictive maintenance. For example, among its offerings, Microsoft Azure offers a predictive maintenance solution among its set of IoT solution accelerators.

Developers can even get an early start with the Azure accelerator, which includes simulated devices able to present multiple streams of sensor data taken from NASA jet engines. At the end of the tool chain for this accelerator, Azure machine learning services deliver a trained model based on this data. In some cases, developers could employ transfer learning methods that use a pretrained model, such as the Azure predictive maintenance model, as the starting point for their own custom machine learning model.

Conclusion

To meet growing interest in predictive maintenance, developers need to be able to rapidly deploy robust multisensor systems suitable for industrial environments. A comprehensive development solution from STMicroelectronics combines a hardware sensor board and software environment designed specifically for predictive maintenance requirements.

Using this system solution, developers can immediately begin evaluating predictive maintenance, rapidly develop their own predictive maintenance applications, and leverage emerging cloud-based machine learning resources to create more sophisticated predictive maintenance capabilities.

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this author

Stephen Evanczuk

Stephen Evanczuk has more than 20 years of experience writing for and about the electronics industry on a wide range of topics including hardware, software, systems, and applications including the IoT. He received his Ph.D. in neuroscience on neuronal networks and worked in the aerospace industry on massively distributed secure systems and algorithm acceleration methods. Currently, when he's not writing articles on technology and engineering, he's working on applications of deep learning to recognition and recommendation systems.

About this publisher

Digi-Key's North American Editors