How online monitoring helped to detect sludge in pump pipes – a diagnostician’s view
The diagnostician receives an alert about an anomaly on the pump. Before stopping the pump operation, the diagnostician checks the nGuard diagnostic tool for the possible cause of the fault. 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 at this with us:
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, 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.
Notification comes by email/SMS
We’ll go through the case from start to finish. The customer-diagnostic receives an email notification 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 alerts, the diagnostician opens a dashboard where he can see all his machines. He can filter them by company, project and location. To better filter and 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.
Fig. At this moment the diagnostician sees a warning on pump 112A.
At a glance, you can see if the machine is OK and therefore if it shows any anomalies. As we can see, there was some anomalous event on pump 112A that resulted in a change in sound outside 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.
Concrete machine with alert
Because the diagnostician wants to find out more information about this particular machine with the fault, he clicks on the tab in question and thus gets to the overview of the machine (see the figure 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 behaviour 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 which sensor has detected the change in sound energy = increased volume (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.
If necessary, a user note on the event, if someone has already added it. 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.
1. Selecting a time period and comparing it with the nominal sound
The analytical tool integrated in nGuard is used to easily and quickly evaluate the sound that triggered the alert. Here, the diagnostician clicks in the graph on the location 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/she decides to make any other modifications to the selected data (change the time, remove the selection or manually enter a new date), he/she can do so by clicking on the “manage times for analysis” button.
2. 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.
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.
Just below the plotted audio signal is a spectrogram. As in the previous case, this shows the change in sound over time (horizontal axis), but also contains information about which frequencies this change is occurring 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.
At the bottom of the analysis tab, the user does not see the plotted frequency spectrum of his selected time periods. This is a great tool for examining specific faults and finding defects based on vibrodiagnostic 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 linear and logarithmic display 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.
Thanks to this analysis, the diagnostician ruled out a fault directly at the pump. The vibration frequencies don’t match. The data from the analytical tool points more 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:
3. Other tools – 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 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, misalignment and mechanical loosening and generate alerts for these types of faults.
4. Verdict / evaluation – assisted alerting
After using all the available functions and tools, the user/diagnostic technician has to give a verdict 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 the 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 an overview of events on the machine in the form of a list, he can use the events tab to do so, where he can again filter between different types of events, edit them and there is also an option to resolve generated alerts.
After the user/diagnostic evaluates the anomalies detected by the system, he/she can handle the alerts as he/she 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 enabled the service technician to be alerted several hours in advance in time to replace the pump circuit and clean the sludge from the pipework at the appropriate time.
The nGuard tool helped a customer-side diagnostician at a 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 allows 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 pick up 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 optimise 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.