A FRAMEWORK FOR NEXT GENERATION MACHINERY MONITORING AND DIAGNOSTICS

Mitchell Lebold Karl Reichard

Applied Research Laboratory Penn State University

P.O. Box 30 State College, PA 16804-0030

Petr Hejda Jan Bezdicek

Rockwell Automation Americka 22

120 00 Praha 2 Czech Republic

Mike Thurston National Center for Remanufacturing

Rochester Institute of Technology

133 Lomb Memorial Dr. Rochester, NY 14623-5608

Abstract: A framework for the next generation machinery monitoring and diagnostic systems is being addressed through the OSA-CBM development team. This framework employs the use of an open system architecture standard that uses a distributed software model approach. A distributed software model was selected due to the recent emergence of enabling software technologies and the benefits of the approach. In particular, the availability of network connectivity provides a ready hardware backbone over which the software system may be distributed. A good overview for OSA-CBM development and insight into an XML- based implementation is provided. Keywords: Condition-based Maintenance; Condition Monitor; Health Assessment; Middleware-based Distributed System; MIMOSA; Open System Architecture; Prognostics Introduction: Condition Based Maintenance (CBM) is becoming more wide-spread within industry and the military. Condition Based Maintenance entails the maintenance of systems and equipment based on an accurate and reliable prediction of current and projected condition (or health). This is a philosophy in which equipment is maintained only when there is objective evidence of an impending failure. Maintenance and monitoring go hand in hand. CBM is being used in conjunction with the traditional approaches of corrective maintenance (run to failure) and preventative maintenance (PM). It is the optimizing of maintenance and monitoring which achieves the lowest system costs. The factors that have driven an increase in the use of CBM include the need for: reduced maintenance and logistics costs, improved equipment availability, and protection against failure of mission critical equipment. The implementation of a CBM system usually requires the integration of a variety of hardware and software components. A complete CBM system is composed of a number of functional capabilities: sensing and data acquisition, data manipulation, condition monitoring, health assessment/diagnostics, prognostics, and decision reasoning. In addition, some form of a Human System Interface (HSI) is required to provide user access to the system and provide a means of displaying vital information to the user. Across the range of military and industrial application of CBM, there is a broad spectrum

of system level requirements including: communication and integration with legacy systems, protection of proprietary data and algorithms, a need for upgradeable systems, implementation time and cost limits. A CBM interface standard should provide the functional capabilities while providing flexibility to the broad range of application requirements. Standardization of specifications within the community of CBM users will, ideally, drive CBM suppliers to produce interchangeable hardware and software components. A widely adopted non-proprietary standard will result in a free market for CBM components. The potential benefits of a robust non-proprietary standard include: improved ease of upgrading for system components, a broader supplier community resulting in more technology choices, more rapid technology development, and reduced prices. This paper will describe an effort underway to develop an open system standard for CBM systems with emphasis on the framework development. Open Systems and Standards: Openness is a general concept that denotes free and unconstrained sharing of information. In its broadest interpretation, the term “open systems” applies to a systems design approach that facilitates the integration and interchangeability of components from a variety of sources. For a particular system integration task, an open systems approach requires a set of public component interface standards and may also require a separate set of public specifications for the functional behavior of the components. The underlying standards of an open system may result from the activities of a standards organization, an industry consortium team, or may be the result of market domination by particular product (or product architecture). Standards produced by recognized standards organizations are called de jure standards. De facto standards are those that arise from the market-place, including those generated by industrial consortia. Regardless of the development history of the standards that support an open system, it is required that the standards are published, and publicly available at a minimal cost. An example of an open de jure standard is the IEEE 802.3 that defines medium access protocols and physical media specifications for LAN Ethernet connections. An example of a proprietary de facto standard is the Windows OS (operating system). Examples of open de facto standards are the UNIX OS and HTTP. An open system standard that receives wide-spread market acceptance can have great benefits to consumers and also to suppliers of conformant products. In addition to commercial issues, the interchangeability of components enabled by an open system architecture yields several technical benefits: system capability can be readily extended by adding additional components, and system performance can be readily enhanced by adding components with improved or upgraded capabilities. OSA-CBM Development Team: An industry led team has been partially funded by the Navy through a DUST (Dual Use Science and Technology) program to develop and demonstrate an Open System Architecture for Condition Based Maintenance. The team participants cover a wide range of industrial, commercial, and military applications of CBM technology: Boeing, Caterpillar, Rockwell Automation, Rockwell Scientific Company, Newport News, and Oceana Sensor Technologies. Other team contributors

include the Applied Research Laboratory at Penn State and MIMOSA (Machinery Information Management Open System Alliance). The focus of the team is the development and demonstration of a software architecture that facilitates interoperability of CBM software modules. After evaluating a variety of architectural options, a decision was made by the team to develop an object-oriented architecture based upon a client-server approach to distributed computing. The initial architecture development direction was focused towards the loosely coupled Web-based approach and XML messages over HTTP. Due to performance concerns with this approach and the performance benefits of alternate distributed software technologies, the approach that was ultimately adopted was to develop a technology-neutral abstract design specification. The abstract specification is mapped to implementations utilizing leading software technologies. A key development strategy was the use of an object oriented design methodology. CBM Architectures: A complete architecture for CBM systems should cover the range of functions from data collection through the recommendation of specific maintenance actions. The key functions that facilitate CBM include:

- Sensing and data acquisition - Signal processing and feature extraction - Production of alarms or alerts - Failure or fault diagnosis and health assessment - Prognostics: projection of health profiles to future health or

estimation of RUL (remaining useful life) - Decision reasoning: maintenance recommendations, or

evaluation of asset readiness for a particular operational scenario - Management and control of data flows or test sequences - Management of historical data storage and historical data access - System configuration management - Human system interface

Typically, CBM system integrators will utilize a variety of COTS (commercial off the shelf) hardware and software products (using a combination of proprietary and open standards). Due to the difficulty in integrating products from multiple vendors, the integrator is often limited in the system capabilities that can be readily deployed. For some applications a system developer will engineer application specific solutions. When user requirements drive custom solutions, a significant part of the overall systems engineering effort is the definition and specification of system interfaces. The use of open interface standards would significantly reduce the time required to develop and integrate specialized system components. CBM system developers and suppliers must make decisions about how the functional capabilities are distributed, or clustered within the system. Due to integration difficulties in the current environment, suppliers are encouraged to design and build components that integrate a number of CBM functions. Furthermore, proprietary interfaces are often used to lock customers into a single source

solution, especially for software components. An ideal Open System Architecture for CBM should support both granular approaches (individual components implement individual functions) and integrated approaches (individual components integrate a number of CBM functions). Current PC, Networking, and Internet technologies provide a readily available, cost effective, easily implemented communications backbone for CBM systems. These computer networks are built over a combination of open and proprietary standards. Software technologies are rapidly developing to support distributed software architectures over the Internet and across LANs. There is a large potential payback associated with market acceptance of an open standard for distributed CBM system architectures. With the ready availability of network connectivity, the largest need is in the area of standards for a distributed software component architecture. One model for distributed computing is Web-based computing. The Web-based model utilizes HTTP servers that function primarily as document servers. The most common medium of information transport on the Web is the HTML page; HTML is a format for describing the content and appearance of a document. An alternate format for information transport over the Web is becoming increasingly popular; XML (eXtensible Mark-up Language). In contrast to HTML, XML is focused on describing information content and information relationships. XML is readily parsed into data elements that application programs can understand and serves as an ideal means of data and information transport over the web. The web-based distributed computing model requires that each data server have HTTP server software. With the development of compact and embedded HTTP server software it remains a feasible approach. With the growth of distributed computing, a class of software solutions is evolving which enables tighter coupling of distributed applications and hides some of the inherent complexities of distributed software systems. The general term for these software solutions is middleware. Fundamentally, middleware allows application programs to communicate with remote application programs as if the two programs were located on the same computer. Current middleware technologies include: OMG CORBA, Microsoft’s COM/DCOM, SUN’s Java-RMI, DCE and Web-based RPC (Remote Procedure Call). For a more detailed description on Middleware technologies refer to reference [1][2][3][4][5]. Looking ahead, it is likely that the market will support a Web-based middleware and one or more full-service middlewares. It is very difficult however, to predict which (if any) of the current technologies will dominate, or when some new technology will come along and make the current technologies obsolete. A wise approach is to develop a core architecture standard that is technology independent, and extend the core architecture with implementation specifications for several of the current implementation technologies. OSA-CBM Architecture: In order to standardize an architecture for a CBM system, the system must be broken down into generalized components or functions. This software architecture has been described in terms of functional layers. Starting with sensing and data acquisition and progressing towards decision support, the general functions of the

layers are specified below. A detailed description of the inputs and outputs required for all the given layers is beyond the scope of this paper, but is available through the OSA-CBM website [6]. Each layer has the capability of requesting data from any functional layer as needed, however data flow will usually occur between adjacent functional layers. Layer 1 – Data Acquisition: The data acquisition module has been generalized to represent the software module that provides system access to digitized sensor or transducer data. The data acquisition module may represent a specialized data acquisition module that has analog feeds from legacy sensors, or it may collect and consolidate sensor signals from a data bus. Alternately, it might represent the software interface to a smart sensor (e.g. IEEE 1451 compliant sensor). The data acquisition module is basically a server of calibrated digitized sensor data records. Layer 2 – Data Manipulation: The data manipulation module may perform single and/or multi-channel signal transformations along with specialized CBM feature extraction algorithms. Layer 3 – Condition Monitor: The primary function of the condition monitor is to compare features against expected values or operational limits and output enumerated condition indicators (e.g. level low, level normal, level high, etc). The condition monitor may also generate alerts based on defined operational limits. When appropriate data is available, the condition monitor may generate assessments of operational context (current operational state or operational environment). Layer 4 – Health Assessment: The primary function of the health assessment layer is to determine if the health of a monitored system, subsystem, or piece of equipment is degraded. If the health is degraded, this layer may generate a diagnostic record that proposes one or more possible fault conditions with an associated confidence. The health assessment module should take into account trends in the health history, operational status and loading, and the maintenance history. Layer 5 – Prognostics: The primary function of the prognostics layer is to project the current health state of equipment into the future, taking into account estimates of future usage profiles. The prognostics layer may report health status at a future time, or may estimate the remaining useful life (RUL) of an asset given its projected usage profile. Assessments of future health or RUL may also have an associated diagnosis of the projected fault condition. Layer 6 – Decision Support: The primary function of the decision support module is to provide recommended actions and alternatives and the implications of each recommended action. Recommendations include maintenance action schedules, modifying the operational configuration of equipment in order to accomplish mission objectives, or modifying mission profiles to allow mission completion. The decision support module needs to take into account operational history (including usage and maintenance), current and future mission profiles, high-level unit objectives, and resource constraints.

Layer 7 – Human Interface (Presentation Layer): Typically high-level status (health assessments, prognostic assessments, or decision support recommendations) and alerts would be displayed at this layer, with the ability to drill down when anomalies are reported. In many cases the human interface layer will have multiple layers of access depending on the information needs of the user. After the specification is defined and developed for each CBM module, the modules can be constructed into a complete functional CBM system. Figure 1 shows how the OSA modules may interact with each other to form a complete integrated system. The hub of the wheel structure represents the communications medium between the modules, which may be accomplished using popular communication and middleware technologies. Therefore, the modules do not need to reside on the same machine but may reside anywhere on a local or worldwide network. Open systems architecture design enables the integration of improved prognostic capability within new or existing system designs, allowing maximum flexibility and upgradability of the system. Additional information about the OSA-CBM standard development and architecture may be found in the following references: [7][8].

Uncertain

Healthy

Faulty

DecisionSupport

Prognostics

HealthAssessment

PresentationConditionMonitor

DataAcquisition

Envelope Detector

Band-PassFilter

Half-waveor

Full-waveRectifier

Peak-HoldSmoothing

AccelerometerData

Band-PassFilteredSignal

RectifiedSignal

EnvelopeDetected

Signal

( )

( )2

1 1

2

1

4

14

−

−=

∑ ∑

∑

= =

=

m

j

N

ijij

N

ii

rrm

rrNNA

DataManipulation

TraditionalSensor

Smart Sensor

DistributedComputingTechnology

Figure 1 - Data Flow within an Open System CBM Design OSA-CBM Framework: The OSA-CBM framework was developed around input from the functional layer descriptions and existing and emerging standards for monitoring and maintenance, such as the MIMOSA CRIS [9], AI-ESTATE, and IEEE 1451.2. The

OSA-CBM framework currently excludes the decision support layer since it is application specific. The presentation layer was designed as a client-only layer in order to stay open to any user interface technology; no interfaces are therefore defined as part of the standard. The first step was defining an object oriented data model in Unified Modeling Language (UML) for each layer that was then converted into an abstract interface specification. The abstract specification can then be converted to the desired middleware language for a specific interface definition. The components of the OSA-CBM development architecture are shown in Figure 2. The UML object model defines interfaces only. For a given layer of the architecture, the data model does not prescribe the object classes that would be required for a software implementation. The focus is on describing the structure of the information that might be of interest to clients of that layer. OSA-CBM does not impose any requirements on the internal structure of compliant software modules. The architectural constraints are applied to the structure of the public interface and to the behavior of the modules. This approach allows complete encapsulation of proprietary algorithms and software design approaches within the software module.

Figure 2 – OSA-CBM Development Architecture

Once the UML data model was defined for each layer, it was converted into a Pseudo-code language that could be ported to concrete interface definition languages. Abstract Interface Definition Language (AIDL) was selected as the Pseudo-code language. Using a custom Java program, this AIDL code was then converted into an XML Schema. The AIDL file is also used to generate COM/DCOM IDL files and documentation. Note, that the UML, AIDL, COM/DCOM, OMG CORBA IDL, and XML Schema files are provided for each layer (excluding the decision support layer), therefore generation of these files is not necessary by the system developer. A brief discussion about the UML, AIDL, XML, OMG CORBA IDL, and COM/DCOM IDL files are provided in the following sections.

UML Model: Unified Modeling Language (UML) is an object modeling technique that evolved and is now the de facto standard for software modeling. UML provides developers with a blueprint so they know exactly what they need to create. It also provides a bridge between technical developers and their non-technical users. A UML model consists of a set of interrelated diagrams of the various parts of the system [10][11]. Figure 3 reveals a small portion of the UML model that is used for one of the OSA-CBM layers. Each box in UML diagram represents a class. The boxes are divided into three parts; the top part is the class name of the class, the middle contains any attributes, and the bottom box contains any functions. Abstract classes are denoted by the class name appearing in italics. Classes can be related to other classes in one of two ways; it can either be inherited from another class or it can be associated with another class. In UML, inheritance is denoted by a hollow triangle. Inheritance means that the child class includes everything that the parent class does, as well anything additional declared in the child class, while a two-sided arrow denotes association. The name located near the association or inheritance link indicates the name of the association, while the numbers near the line indicate the number of elements in the association set. The color of the associations and inheritances lines relates to one of the three OSA-CBM interfaces (data, configuration, or explanation). For more information about the OSA-CBM UML models please visit the OSA-CBM website [6].

Figure 3 – Representation of a UML Model AIDL Model: The purpose of the AIDL model was to provide a mapping of the OSA-CBM definitions to different technologies by describing a set of common data structures and interface configurations. For OMG CORBA and Microsoft COM/DCOM implementations, the software interfaces are formally described using their own specific Interface Definition Languages (IDL). The AIDL model was defined (using CORBA IDL syntax) in order to promote interoperability between implementations done in different technologies. Figure 4 shows an example of the AIDL notation.

enum EntryPointType {da, dm, cm, ha, pa, ds, other

};

/* Entry point. */interface EntryPoint {

/* Identification of OSA/CBM layer. */EntryPointType entryPtType;

/* The set of ports served by this entry point. */[data] [config] [expl] [async]

OutPortSet outPortSet;/* Explanation of what sources were used by this module for its output. */[expl][optional] Explanation expl;

};

Figure 4 – Representation of AIDL Syntax XML Schema: A schema is a model for describing the structure of information. XML schemas can be used to test the validity of documents; this is an important aspect, especially when web-based applications are receiving and sending information to and from many sources. If you are receiving XML transactions over the web, you do not want your application processing invalid XML data (improper type or syntax). XML inherited Document Type Definitions (DTDs) from Standard Generalized Markup Language (SGML). DTDs are the schema mechanism for SGML. XML Schemas are the first wide-spread attempt to replace DTDs. DTDs have a number of limitations:

- They are written in a different (non-XML) syntax. - They have no support for namespaces. - There is no means for describing numbers, dates and currency values. - They have a complex and fragile extension mechanism based on little more

than string substitution. - The DTD extension mechanism (parameter entities) does not make

relationships explicit. Two elements defined to have the same content models are not the same thing in any explicit way.

<?xml version="1.0" encoding="UTF-8"?><!--XML Schema for da data--><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"><xsd:element name="entryPoint" type="EntryPoint"/>

<xsd:complexType name="EntryPoint"><xsd:sequence>

<xsd:element name="entryPtType" type="EntryPtTypeEnum" minOccurs="1" maxOccurs="1"/><xsd:element name="dataPage" type="xsd:anyURI" minOccurs="1" maxOccurs="1"/><xsd:element name="outPortSet" type="OutPortSet" minOccurs="1" maxOccurs="1"/>

</xsd:sequence></xsd:complexType><xsd:complexType name="EntryPtTypeEnum">

<xsd:simpleContent><xsd:restriction base="xsd:string">

<xsd:enumeration value="DA"/><xsd:enumeration value="DM"/><xsd:enumeration value="CM"/><xsd:enumeration value="HA"/><xsd:enumeration value="PA"/>

</xsd:restriction></xsd:simpleContent>

</xsd:complexType></xsd:schema>

Figure 5 – Representation of XML Schema Syntax

When mapping the UML model to a XML Schema, certain rules had to be established. These rules are necessary because there are multiple ways to do the same thing in Schemas, and a certain degree of regularity was needed to simplify the conversion. Once these rules were set into place, creating the Schemas was generally straightforward. However, at times there are certain things that need to be denoted in the XML, but are not included in the UML model. Many times these apparent discrepancies are based on intricacies that are not stated in the UML model, but rather must be known by experience. Whenever this happened, a comment was placed in the Schema explaining why the Schema deviates from the UML model. COM/DCOM IDL: The definition of OSA/CBM interfaces for Microsoft COM/DCOM middleware was done using the standard IDL files. OSA/CBM standard defines a set of eleven IDL files. The IDL files define interfaces of the OSA/CBM layers in this way:

q Data Acquisition – da.idl, basicTypes.idl, top.idl, util.idl q Data Manipulation – dm.idl, basicTypes.idl, top.idl, util.idl, data.idl q Condition Monitor – cm.idl, basicTypes.idl, top.idl, util.idl, measEv.idl q Health Assessment – ha.idl, basicTypes.idl, top.idl, util.idl, propEv.idl q Prognostics – pa.idl, basicTypes.idl, top.idl, util.idl, propEv.idl q Presentation – can use all IDL files as a client.

Figure 6 contains an example of the IDL definition.

Figure 6 Representation of COM/DCOM IDL Language

OMG CORBA: Layer interfaces for OMG CORBA are defined using standard IDL files. The specification was divided into three parts: the Data Structures, Source Interface, and Sink Interface. Not all OSA-CBM data model names were kept the same, some changes had to be made for the CORBA IDL processor to work. In such cases names were chosen to be similar. Some names also had strings added to them to indicate the OSA-CBM data model class to which they correspond. Example of CORBA definition is show in Figure 7.

Figure 7 Representation of OMG CORBA IDL Language Current Status: The architecture that has been discussed was successfully applied in several demonstrations across a variety of different CBM applications as a part of the DUST program. The demonstrations covered several of the technologies that were discussed, and associated implementation standards were developed. Lessons learned

during the implementation process were used to update and improve the core architecture. Both ARMY and NAVY are evaluating this architecture for transition into their programs. The ARMY is evaluating the use of MIMOSA and OSA-CBM standards as a part of their maintenance architecture. NAVY research programs, in the area of CBM, are being directed to consider the OSA-CBM architecture in system and component designs [12][13]. Acknowledgment: This work was supported by the Office of Naval Research through the OSA-CBM Boeing DUST (Grant Number N00014-00-1-0155). The content of the information does not necessarily reflect the position or policy of the Government, and no official endorsement should be inferred. References:

[1] Serain, D. Middleware. London: Springer-Verlag, 1999.

[2] Object Management Group (OMG) Website, http://www.omg.org/

[3] Microsoft. “COM: Delivering on the Promises of Component Technology.” http://www.microsoft.com/com/default.asp

[4] Sun Microsystems. “Remote Method Invocation over IIOP.” http://java.sun.com/products/rmi-iiop.

[5] Shirley, J., Hu W., and Magid, D. Guide to Writing DCE Applications. O’ Reilly 1994

[6] OSA-CBM Website, http://www.osacbm.org/

[7] Thurston, M. and Lebold M, “Standards Development For Condition-Based Maintenance Systems,” Improving Productivity Through Applications of Condition Monitoring, 55th Meeting of the Society for Machinery Failure Prevention Technology, April, 2001.

[8] Lebold, M. and Thurston, M., “Open Standards for Condition-Based Maintenance and Prognostic Systems,” Maintenance and Reliability Conference (MARCON), May 6-9, 2001.

[9] MIMOSA Website, http://www.mimosa.org/

[10] Grady Booch, James Rumbaugh and Ivar Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999

[11] David Carlson, Modeling XML Applications with UML, Addison-Wesley, 2001

[12] Roemer, M. J., et. al, “Prognostic Enhancements to Naval Condition-Based Maintenance Systems,” Improving Productivity Through Applications of Condition Monitoring, 55th Meeting of the Society for Machinery Failure Prevention Technology, April, 2001.

[13] Orsagh, R. “Development of Performance and Effectiveness Metrics For Mechanical Diagnostic Technologies,” Improving Productivity Through Applications of Condition Monitoring, 55th Meeting of the Society for Machinery Failure Prevention Technology, April, 2001.