What factors can be leveraged from a drive system to support and allow predictive maintenance?

In general, we expect a number of motor characteristics to change over the lifetime of a product. One of the obvious ones is how much torque the motor produces over time. We can expect that there will be changes in torque during a product’s lifetime due to bearings wearing out or components beginning to rub or becoming loose. Depending on the various types of failure or degradation, these changes can be monitored.  

Some common characteristics to look for may include motor vibration, time to stop, or motor noise. In terms of monitoring these characteristics, we can put limits on what normal operation looks like and then be able to tell when it's outside of those limits, which would suggest that it may be time for maintenance. We won't know exactly what those limits are, and those tell-tale signs will of course differ depending on the product, therefore FPT’s good product experience is key to understanding this.  

What are the trends and what are the things that could go wrong?
‍
Analysing this helps us identify the acceptable limits where it becomes predictive maintenance rather than just standard maintenance.

We know the relationships of motor torque and motor currents and what the motor controller can pick up within those. There is a second step where more abnormal things could come up. For example, noise or some vibration or perhaps something in the bearing. It might not be a bearing load as such, or the motor torque having to work harder, but maybe there are some high frequency signals or some variation in those motor parameters that indicates something is going wrong. Our teams will put in more development work to pick up these kinds of things.  

We run life testing for the motors that we produce before they go into production, and we have a lot of data logging and sensing on those tests running. One aspect we look at is high level performance metrics such as noise or vibration levels. By extracting internal data from the controller, we can access high frequency variables being used to run the motor and provide additional insights into what is happening within the system. By doing this, we may be able to predict any external changes.  

R&D plays a big part in predictive maintenance. It is more prominent in industrial applications where downtime can be costly for a company. For us, reliability testing, or life testing, makes up a sizable part of a product’s development time. For example, our highest reliability testing is at least four to six months. If we can predict earlier in that time that something will go wrong – say after 1000 hours rather than waiting 5000 hours, that's a big benefit for our customer and a huge amount of time that can be saved.  

However, with any kind of model – e.g., product degradation or failure, it will only be as good as what you put into it. We need the core data to feed into it. What does a failure do to the performance? How does that impact things like reliability? We can perform that research to find out what they are, and perhaps be able to estimate the product is three months away from failure, for example. The controller will have a way of signaling this impending failure, by way of an alarm or a message to an app, in order to alert a service technician.  
‍

Predictive failure

When we talk about predictive maintenance, we are also referencing predictive failure. We log the data using machine learning or simply analyse the data ourselves, so we can see potential trends through the motor signals that we have.  

For example, to predict that this mode of torque is rising very quickly and that's a sign it's rising at a rate that isn't going to get us to the end, so by stopping the test, we can change something before getting to that point. However, we will only change something if it is a component we don’t want to test. If it is a critical component, it is often beneficial to run the test until failure.  

Similarly, anomaly detection is used if we're running a reliability test for R&D and something changes, a warning is issued so a technician can go in and see if there is something obviously going wrong, rather than waiting until something finally fails. By missing some of those early signs, the issue could escalate or longer testing periods will be required.