Diego Galar

Professor, Dr

diego.galar@ltu.se

Behzad Ghodrati

Associate Professor, PhD

behzad.ghodrati@ltu.se

Luleå U niversity of

Technology

Sweden

Although there have been many recent efforts to collect and maintain large repositories of CMMS and CM data, relatively few studies identify the ways that these two datasets could be related. It is only logical to assume that written maintenance record histories are linked to the measurements of onboard sensors and it is in the interest of CBM researchers to develop means to merge these datasets consistently and reliably.

Full integration of CMMS and CM datasets requires a more advanced interfacing to model more appropriately the real-world relationships between the observed maintenance and sensor data. So far the case studies have been generated by individuals who identify related events based on their knowledge of the systems involved. For example, an abrupt change in a vibration sensor on a gearbox is assumed to be related to the recorded replacement of a nearby part. It is rather complex to take an analytical approach to this decision-making process since the determination of causality and dependence is often performed through a highly subjective process.

The overall goal of enhanced interfacing should be to automate the complex process of linking events from different datasets. Developing this system begins with a four-step investigation: historical data collection, importation into a single database, data abstraction and data analysis. Using a vast wealth of historical information in combination with knowledge of system components, software agents are being developed to bridge the gap between the data types allowing evaluation for the proximity, severity and rarity of events across datasets.

The instances where CM data is reflected by real-world events can be identified regularly through an integrated CM and CMMS system. This allows an objective determination of asset parts prone to failure and the evaluation of CM effectiveness to monitor these areas.

Based on these evaluations feedback can be given to CMMS and CM developers to refine the means to collect the data and devise the strategies for the next generation of fully integrated CBM systems. 

Click Image to Enlarge

Depiction of the four-stage integration process.

Data Source Collection

Since the history of Maintenance Management Systems predates the information age, they have traditionally been delegated to the operational unit level for implementation. Collecting data for investigation studies has required the permission of various operational units, thus limiting the scale of CMMS research to date. As a result the efforts to centralize CMMS data have been slow to materialize, and therefore the data collection for early integration studies remains just as a small sample of the future capabilities of a centralized CBM system. In contrast, CM developers have relied on automated data centralization to evaluate and validate their systems since their inception.

Relational Data Importation

Modern CMMS information is stored in very large relational, or tabular databases and there is a large number of software tools available to query and investigate tables in these formats. Only certain fields are required for historical analysis allowing for any sensitive data to be removed or filtered; the data subset still contains a full history of component faults and related actions providing a comprehensive maintenance history profile while alleviating any security concerns.

Importing CM data into a relational database is more challenging since each type of sensor generates different data classes, sampling rates and number of compiled indicators. Furthermore each manufacturer stores the collected information in unique proprietary formats requiring platform-specific software to enable exporting of the CM data from the original interface. Once importing CM data into a relational database is accomplished, the benefits are tremendous as multiple manufacturer and cross-platform data can be viewed through generic data classes.

Preprocessing and Data Abstraction

Although when both CMMS and CM data co-exist in a single database so that it can be queried and explored, automating the discovery of linked events requires additional processing. In their original form the datasets only have two common fields, asset identification and date. Relating a given maintenance fault or action in textual format to some arbitrary data class type sensor data can be accomplished only through the compilation of overlapping metadata. The generated fields characterize the location and significance of events, creating a quantified set of parameters which enables the comparison of the disparate data.

Textual CMMS data is processed using artificial intelligence (AI) tools applied to language processing (LP) [3], a subfield of both artificial intelligence as well as linguistics covering a very large variety of applications from machine translation to speech recognition.

The specific context of maintenance management data with descriptions of assets faults and performed actions restricts the lexical domain and the textual CMMS fields can be analyzed separately to create a set of interpreters which extract key information from the fault or action description.

The output of the AI LP tool shows the component to which the record is referencing and a list of other descriptor keywords. Categorical statistical analyses are performed to characterize the rarity of a given record and a preprogrammed scoring chart assigns the severity to each record based on the available keywords.

An additional level of data abstraction for CM records is generated differently depending on the data class involved. Rarity parameters can be assigned through statistical distribution analysis to one-dimensional and dimensionless quantities, higher dimensional data requires using neural networks to identify anomalies. The identification of the component that a particular sensor or indicator is monitoring is predefined by the CM manufacturer.

Analysis and Correlation

The metadata is extracted from all available records into a single events table containing asset identification, component name, event time, a rarity parameter and a severity parameter. The simplest method to determine the event relation is through a proximity study of the metadata and by categorizing the results by component. It is then possible to identify parts of the assets where CM devices have a high success rate in identifying component faults or reflecting maintenance actions.

Known problematic subsystems which do not have a high count of related CMMS and CM events, indicate that revision to the sensing strategy or changes in indicator definition are needed. Further analysis of the raw data of these components can be performed to discover new algorithms for condition indicator computation.

This computation is however extremely complex due to the multi-location structure of many companies with lots of information systems related to maintenance (CMMS, CM, phones, PDA’s, laptops, SCADA, ERP...). Replication of all data in order to perform this correlation is not feasible and would require enormous computation resources, which is why the concept of cloud computing is coming up as a solution in creating metadata from all available information sources. 

Conclusion

A thorough understanding of the requirements and constraints from maintenance and ICT perspectives is necessary when implementing an e-maintenance system.

Users get lots of benefits from IT Hardware and Software integration, the main benefit from this process is the insight into the future establishment of CM data format standards. Early integration attempts will identify data structures that are most conducive and useful for long-term storage and searching.

A general set of guidelines for file formats can be established with the coordination of CM developers and this will enhance the potential for research by the scientific community increasing greatly the usefulness of CM platforms. Users of CM and CMMS products have been increasingly applying pressure on system vendors to establish a common data exchange framework and this pressure has spawned the birth of the Machinery Information Open Systems Alliance – MIMOSA. This organization has made remarkable advances in the area of open information exchange, but at this time only the conceptual model of linking CM and CMMS data has been established. So far MIMOSA has concentrated on efforts to define the information model and to extend MIMOSA data tables to include information that should be communicated to a CMMS.

Following the implementation of an integrated system, its usefulness will expand from just guidance tools to automated diagnostic systems. These integrated systems will constantly compare sensor readings to the wealth of historical records and forecast plausible maintenance events based upon historical precedence. This will allow for more efficient logistics and component performance evaluation and furthermore, these systems will identify unexplained or common modes of failure directing the efforts of scientific component testing, which will drive design modifications to make the assets increasingly more reliable.

Integration process of centrifugal pump info.

Need for cloud computing in CMMS and CM integration.

The final system will manifest itself as an automated maintenance exploration interface. Users will be able to identify quickly the possible diagnoses of faults and retrieve historical maintenance actions which have proven to be effective in resolving the problem. Such a system would be easily scalable across several CM platforms, several asset types and several locations allowing maintainers to have information of a variety of practices which have been performed across the field.

All vendors recognize the necessity to move forward quickly and all attempts to integrate CMMS and CM will be a key part of maintenance technology in the future; currently this integration consists only of a common framework for data exchange. No real relations and contextual information is extracted from the huge amount of data included in these data warehouses.

»»References ››1. Baptiste J., A case study of remote diagnosis and e-maintenance information system, e-Proceedings of Intelligent Maintenance System, 15–17 July, 2004, ArIes, France. ››2. Kahn, J. and Klemme- Wolf, H. (2004), O verview of MIMOSA and the O pen System Architecture for Enterprise Application Integration, Proceedings of the 17th European Maintenance Congress, pp. 333–341, May 2004. ››3. Manning, C. and Schutze , H. Foundations of Statistical Natural L anguage Processing. MIT 1999. Press, Cambridge, MA. ››4. Parida A. and Kumar U., Managing Information is key to Maintenance Effectiveness,e-Proceedings oflntelligent Maintenance System, 15–17 July, 2004, Arles, France. ››5. Thomas B ., Denis R., Jacek S., T. Jean-Pierre and Z. Noureddine, PROTEUS – An Integration Platform for Distributed Maintenance Systems, e-Proceedings of Intelligent Maintenance System’ (IMS’ 2004), 15–17 July, 2004, ArIes, France. ››6. Vouk M. A., 2008. Cloud computing Issues, research and implementations. In 30th International Conference on Information Technology Interfaces (ITI 2008). Cavtat/ Dubrovnik, Croatia, June 2008, 31–40. ››7. Wang X., L iu C. and L ee J., Intelligent Maintenance B ased on Multi-sensor Data Fusion to Web-enabled Automation Systems, e-Proceedings of Intelligent Maintenance System, 15–17 July, 2004, Arles, France.