- Pavel Trojanek
- September 15, 2021
- 12:15 pm
How nGuard online monitoring helped to detect sludge in the pump pipe – a diagnostician’s view
A diagnostician receives an alert about a pump anomaly. Before stopping the pump, he checks the possible cause of the fault in the nGuard diagnostic tool. Through remote analysis, he determines that the fault is not directly on the pump, but in the piping upstream of the pump. Based on this, a decision is made to shut down the pump outside of core operating hours and to check the piping.
The anomaly is resolved. How does the diagnostician work with the nGuard portal to be able to find and evaluate the cause? Come take a closer look:
A pharmaceutical company operates several coolant pumps to provide cooling for manufactured drugs. These pumps provide cooling for the compressor that distributes the coolant to the refrigeration bodies.
Sludge that is not removed from the lines in time could cause inadequate cooling of the compressor, and similarly, the resistance of the sludge liquid could cause the pump motor to burn out. Losses run into thousands of euros for the pump itself and tens of thousands of euros for the non-cooling and deterioration of products in the freezers.
Thanks to the early detection of sludge in the pipes, these losses were avoided. As part of a planned upgrade of the maintenance process, the pharmaceutical company deployed the Neuron Soundware continuous remote monitoring service.
Now the diagnostician has a comprehensive overview of the current (and past) status of all monitored machines. Maintenance has a number of available indicators and tools that can assist in diagnosing machine status, as we will show below.
Alerts come via email/SMS
We will go through the entire case from start to finish. The customer-diagnostician receives an email alert every time an alert occurs on the machine. In this case, the alert comes about an anomaly detected on a sensor located in front of the pump:
All devices at a glance
Based on the alert, the diagnostician opens a dashboard where he can see all his machines. He can filter them by company, project, and location. For better filtering and to find specific machines or machines that are in a certain state, he can use the quick filter buttons or he can use the search boxes to directly find the specific machine that is currently affected by the fault.
At a glance, it can be seen if the machine is OK and therefore does not show any anomaly. As we can see, there was some anomalous event on pump 112A that resulted in a change in sound outside of the trained data set. Based on this, the system created an alert on that machine and it was displayed on the card of the respective machine.
The specific machine with the alert
Because the diagnostician wants to find out more information about this particular machine with the fault, he clicks on the appropriate tab to get directed to the overview of that machine (see image below). The default is the graphs tab, where he can see the machine’s operation for the last 7 days. This time range can be freely adjusted to see the behavior of the machine at any point in its monitoring.
In this case, the model has evaluated the anomaly and created an appropriate event. This is then visible as a red vertical line in the graphs at the appropriate time.
The graphs section is divided into three parts – machine utilization, an overview graph for all sensors, and a graph for each individual sensor.
Here, the diagnostician can see on which sensor there is a change in sound energy = increased loudness has been detected (green curve). If there is only one sensor on the machine, the summary graph is the same as the graph for that sensor. However, if the machine is larger or more complex and is monitored by a larger number of sensors, hovering the mouse cursor over an alert marker in the graph will display a description of the event -and on which sensor(s) it was located.
In the figure, we can see that the change in sound corresponds to an increase in the anomaly score (yellow curve) calculated by AI Neuron Soundware. The system generated an alert because a set threshold was exceeded. And for the diagnostician, this indicates an event that needs to be addressed.
Selecting a time period and comparing it to the nominal sound
To easily and quickly evaluate the sound that triggered the alert, the analysis tool integrated into nGuard is used. Here, the diagnostician clicks on the graph on the point of interest in terms of changes in the sound. He then selects the option “add to analysis”. He can repeat this process as many times as he wants and select all the areas of interest he wants to include in the analysis.
When he is satisfied with his selection, he clicks on the “go to analysis” button, which takes him to the analysis tab. Alternatively, he can also go to this tab from the top menu of the machine.
If he decides to make any more adjustments to the selected data (change the time, remove the selection or manually enter a new date), he can do so by clicking on the “manage analysis times” button.
Data analysis
The diagnostician then has several options for checking the data to look for a specific fault. In the analysis tab, after selecting the data, the sensor location and the number of samples to be plotted, he can have a comprehensive diagnostic overview of the selected sounds plotted.
Sound analysis
At the top of the analysis, the user sees a plot of the audio signal and its intensity. Of course, the sound can be played back and also downloaded if the user would like to use another external instrument for the analysis. Often it is already clear from listening if the machine is working as it should or if there is a problem.
Spectrogram
Just below the plotted audio signal is the spectrogram. As in the previous example, it shows the change in sound over time (horizontal axis), but also contains information about which frequencies this change occurs at. This makes it particularly useful for quick evaluation and to track rapid changes that might eventually occur in a recording, such as bumps, hits, rapid and sudden changes, etc.
Frequency spectrum
In the bottom part of the analysis tab, the user can see the plotted frequency spectrum of the selected time periods. This is a great tool for examining specific faults and finding defects based on Vibro diagnostic empirical findings. The individual waveforms have an order corresponding to the order in which the user has selected them.
The diagnostician has the possibility to switch between the linear and logarithmic displays of the vertical axis, as well as the possibility to keep this axis in a fixed range of values or to make it behave dynamically and adapt to the plotted values. Of course, clicking and dragging can zoom in on the frequency region of interest to the user, or the fields above the graph can be used to specify the exact range of frequencies.
The conclusion from data analysis
Thanks to this analysis, the diagnostician has ruled out a fault directly at the pump. The vibration frequencies do not correspond to this. Rather, the data from the analysis tool points to the piping upstream of the pump.
For larger machines, it is still possible to verify the fault through further, additional measurements. In this case, the additional measurement was not necessary, it was enough to look at the analysis tool. Even so, for completeness we present this insight here:
Other tools – velocity RMS (root mean square), bands – for rotating machines
Two other tools can help the user as additional guides in dealing with anomalies. The first is the value of instantaneous RMS velocity in mm/s. By tracking this value, similar to the anomaly score, the user can monitor the long-term trend of vibration change and take timely action.
In addition, it is possible to assign a machine group from the international standard ISO 20816 to each machine. This results in the automatic generation of alerts when the recommended RMS speed values given by the standard are exceeded.
The second tool is to monitor frequency “bands”, or frequency-dependent faults in rotating machines. NSW is thus able to automatically evaluate suspected misalignment and mechanical loosening and generate alerts for these types of faults.
Verdict / evaluation – assisted alerting
After using all the available functions and tools, the user/diagnostic technician has to give a verdict on whether it is really a malfunction or just an anomaly caused by a change in the operating mode, which entails a change in the sound, which may not be contained in the original training set of the machine and thus creates “false alarms”.
If the customer has a service in assisted alerting mode, the NSW diagnostician always performs the analysis of any alerts and informs the customer if deemed appropriate. The customer will thus only receive pre-checked events, which he then decides how to deal with.
Overview of events on a specific machine
If the user is interested in or prefers to have an overview of events on a machine in the form of a list, he can use the events tab, where he can again filter and edit between different types of events and there is also an option to resolve generated alerts.
After the user/diagnostic evaluates the anomalies detected by the system, he can deal with the alerts as he sees fit. That is, close the alerts as false alarms or notify someone else about them. A dialog box is used to allow the user to send an email with a detailed description of the event to the person in charge.
The diagnosed anomaly was caused by sludge in the piping around the pump. The recorded anomaly thus allowed the service technician to be alerted several hours in advance so that he switch to the backup cooling circuit at the appropriate time, thus avoiding irreversible destruction of the pump and damage to products worth tens of thousands of euros.
Conclusion
The nGuard tool helped the customer-side diagnostician at the pharmaceutical company detect an impending pump failure. This was done by capturing the evolution of the sound around the pump in question.
The nGuard portal enables the maintenance and repair records of each machine to be kept. It provides the possibility to quickly and independently (without the need for a specialist) listen to/check the running of the machine to see if it is OK – if the customer hears something there himself, he can call a specialist service who will provide him with an accurate diagnosis (i.e. he does not have to send someone there regularly and for all machines but only when he gets an alert from us and for a specific machine/location).
The solution can also be used where there is noise at the machine and a human operator would not hear the problem even if they were standing next to the machine – they can listen to the machine sound in the nGuard portal without any problems. Thanks to continuous recording, the solution can also capture shorter sounds (e.g. bangs) as it can accommodate a wider range of problems that vibrodiagnostics will not pick up as part of periodic checks.
This makes it possible to optimize the number and frequency of service interventions and therefore overall maintenance management. This saves the customer in this case both time and money on maintenance and on salvaged products that have remained cooled to the required temperature.
Recent Posts
