February 2021

Special Focus: Digital Transformation

Data historian-based machine condition monitoring

Machine condition monitoring has been playing an increasingly important role in industrial asset healthcare for many years.

Hastings, M., Brüel & Kjær Vibro A/S

Machine condition monitoring has been playing an increasingly important role in industrial asset healthcare for many years. More machines are being monitored—not just the critical ones—and more comprehensive and in-depth monitoring techniques are employed. Although vibration analysis theory, the primary basis of condition monitoring, has not changed much in the last 50 yr, monitoring techniques have evolved considerably. This is partly due to experience, monitoring system technology and data science. Industrial Internet of Things (IIoT) technologies and strategies have been changing the information landscape drastically in many industries, but has it also affected machine condition monitoring?

Machine condition monitoring systems and their limitations

Condition monitoring systems (CMSs) offer various levels of insight into machine healthcare but all have a common purpose: to reduce both downtime and lifecycle costs of running and maintaining plant machinery. This is done by detecting and diagnosing machine potential failure modes at an early enough stage of development so focused maintenance can be cost-effectively scheduled ahead of time without interrupting the machine’s production capacity. The CMS does not perform process control or other enterprise functions, so it is more or less a stand-alone system consisting of its own sensors, signal conditioning unit, CM server and database.

Many of the systems are still based on proprietary servers with restricted license access, so in many cases, the user becomes completely dependent on the CMS provider and their expertise. If the CMS specialists are unavailable for an urgent machine diagnostic issue, the option of using a remote third-party analyst can be challenging simply due to restricted CMS access. Even if the CMS data was available for third-party analysis, measurement configuration information regarding signal filtering and processing would be most likely unknown, thus complicating the task of doing a reliable diagnosis.

The disadvantages of a proprietary CMS are not just limited to restricted data access for analyzing a specific machine fault. It also makes it difficult to get an overview of the general machine healthcare awareness of a specific monitored machine or fleet of machines, especially if some of the data is monitored by other systems. Correlating process data and monitoring data from other CMSs to vibration measurements is an important means for improving the reliability of fault detection and diagnostics for all operating conditions. Although many CMSs can import process data, this is often done at the discretion of the CMS supplier at the time of installation and cannot always be easily changed when new process information is available.

Lastly, there is the question of security and economy of scale of installing, running and maintaining a proprietary system installation within the IT infrastructure. As the user interface is different from one system to the next, CMS training also must be individualized.

With all the advancements of CMS technology, is there a solution to resolve these issues?

Data historian enhances plant and machine healthcare

Distributed control systems (DCSs), supervisory control and data acquisition (SCADA) and programmable logic controllers (PLCs) are used by industry to control production to a high level of reliability, safety and efficiency. These systems represent the pinnacle of information and control technology. Regarding data storage, historically speaking, a DCS typically stored data for only a week or so, which was considered to be more than sufficient from a control perspective, but insufficient from a maintenance point of view. The data historian concept consequently emerged to fill this gap. With advanced data processing and storage capability, the data historian extended DCS/PLC capability by offering much more insight into production reliability, quality and performance for the entire plant, as well as for the individual machines.

Moreover, the historian provided tools that can work extensively with the data. These tools are continuously being developed but presently include functionality for historical and current machine performance visualization, navigation for finding data, event handling of anomalies, notification of events, reporting, and even calculated measurements for specialized monitoring and Boolean logic for generating alarms.

For all practical purposes, the data historian seemed like the perfect solution match for integrating a CMS. Both systems depend on big data and use much of the same information processing tools. The integration, however, has been slow. Why?

Machine condition monitoring in the data historian

In the beginning, the data historian data was limited to the DCS/PLC plant-wide process control data, whereas the CMS stand-alone systems were focused on machine vibration data. This was initially a technology-based decision since raw vibration data and spectral data required a data sampling rate and resolution that far exceeded that required for process data. An even greater obstacle for the migration of CMS data into the historian was the question of how to manage vibration diagnostic expertise.

Much of the work in a data historian is simply to detect and trend measurement amplitude changes to identify process changes or developing machine faults. A CMS also does this, but a major function of the CMS and the specialists who work with the system is to also identify and localize the detected fault, determine the nature and severity of it, and estimate lead-time to service. This is fault diagnostics, a specialist area for vibration analysts, where most who work in the data historian space are traditionally not trained in. Although many vibration measurements, such as the bandpass for running speed (1x) and the second and third harmonics (2x, 3x), can easily be stored, detected and trended in the historian. Expertise is needed to evaluate the relationship of this data to perform proper diagnostics.

A CMS specialist (inhouse or from the CMS supplier) is needed to look at and diagnose the data stored in the historian. Moreover, the CMS specialist utilizes diagnostic tools in the system that are not normally available in the historian, as shown in FIG. 1. Therefore, even if many vibration scalar measurements can be stored, detected and trended in the historian, most of the diagnostic work is actually done in the CMS itself. Therefore, many have questioned the actual benefits of storing the vibration scalar values in the historian rather than in the CMS server.

FIG. 1. An example of a proprietary diagnostic tool offered by a monitoring system supplier.

Because of the diagnostic expertise barrier, condition monitoring functionalities that could otherwise be done in the historian remain in the traditional CMS, namely data storage, visualization, navigation, event handling, notification and reporting. This makes the CMS an isolated world of its own. Is any work being done to change this?

Historian-based condition monitoring

Recent events have been changing the coexistence between the historian and CMS. A new generation of CMS suppliers within the data historian environment have begun to challenge the lofty positions of the traditional CMS suppliers. Most of the newer supplier condition monitoring functions are now done in the historian itself, including data storage. However, for the diagnostic functionality part of the system, such as diagnostic algorithms, specialized measurements and plots, this is still separated from the historian. However, even this has been improved. Diagnostic plot functions and their corresponding measurements (FIG. 1) can now be accessed directly from the historian user interface with a single mouse click, as shown in FIG. 2.

FIG. 2. An example of a data historian view screen showing the health status for a compressor train. The circled vibration signal in the upper left-hand corner is a link to the diagnostic tools shown in FIG. 1.

One of the most important advances, however, is that it is now possible to store high-resolution vibration time waveforms in the historian database. This was the initial stumbling block for CMS-data historian integration; it has finally been removed so all data can now be stored in the historian, both scalar and dynamic values. This means raw data in the historian can be re-processed by service providers either as a second opinion, or in the case where the normal diagnostic specialists are unavailable. There is still no standardized way of associating measurement configuration information to the raw data stored in the historian, but this is expected to change, as well.

Now, diagnostic services are not only more readily available, but they can be performed more reliably and accurately (FIG. 3). The vast amount of process and machine monitoring data in the historian can now be analyzed by statistical analysis to further refine symptom detection earlier and provide more reliable prognosis to service with greater lead-time. CMS suppliers are now also offering automatic diagnostic services through a cloud-based webserver, so no client diagnostic server hardware or software is required. This cloud can then be connected to the historian as a seamless interface.

FIG. 3. An example of an overview plot in the data historian. By clicking on the Unit 1 Compressor A, FIG. 2 appears.

More and more historian-based condition monitoring applications are being developed, such as specific monitoring techniques like thermodynamic performance monitoring of turbomachinery, or for specific machines, such as reciprocating compressors.

Another important area of improvement with historian-based condition monitoring solution integration is the expanded user base. More specialists can contribute to the machine healthcare knowledge base, and more stakeholders who make important asset reliability decisions can have access to this information.

Takeaway

The IIoT has been the main driver for successfully breaking down proprietary interfaces in the information world for a large part of the industry, and the machine condition monitoring domain is no exception. As a result, historian-base condition monitoring has become much more intuitive, reliable, transparent and widespread. A lot of work remains to optimize the historian-based condition monitoring solution, but this is expected to be refined over time. HP

The Author

Related Articles

From the Archive

Comments

Comments

{{ error }}
{{ comment.comment.Name }} • {{ comment.timeAgo }}
{{ comment.comment.Text }}