User:Titus Pullo 2010/OSA-CBM Design Document

OSA-CBM Design

1. About this Document
The Open Systems Architecture for Condition-Based Maintenance (OSA-CBM) specification is a standard architecture for moving information in a condition-based maintenance system. A more in depth look reveals a way to reduce costs, improve interoperability, increase competition, incorporate design changes, and further cooperation in the realm of condition-based maintenance. This document is intended to serve as the primary starting point for individuals that are interested learning about the OSA-CBM standard. The following section provides an introduction to the standard itself. Section 3 summarizes the information types and interfaces that are defined in OSA-CBM. Section 4 provides an overview of the steps necessary to build a functioning OSA-CBM system. Section 5 covers the main data classes in the specification, while section 6 discusses the Data and Configuration information types. Finally, the OSA-CBM Synchronous interface is covered in section 7.

2. Introduction to OSA-CBM
Project managers implementing condition-based maintenance systems must take on the task of integrating a wide variety of software and hardware components as well as developing a framework for these components. OSA-CBM simplifies this process by specifying a standard architecture and framework for implementing condition-based maintenance systems. It describes the six functional blocks of CBM systems (Figure 1), as well as the interfaces between those blocks. The standard provides a means to integrate many disparate components and eases the process by specifying the inputs and outputs between the components. In short, it describes a standardized information delivery system for condition based monitoring. It describes the information that is moved around and how to move it. It also has built in meta-data to describe the processing that is occurring. The OSA-CBM v3.2 standard is defined using the Unified Modeling Language (UML) and is designed as a “multi-technological implementation,” meaning that it separates the information that can be exchanged in a condition-based maintenance system from the technical interfaces system integrators use to communicate the information. Vendors and integrators can implement the standard using the appropriate technology for their environment. For example, while aircraft health management vendors may elect to use a “real-time” implementation, a vendor developing a portable maintenance aid may elect to implement the standard using XML and web services.



Figure 1 – OSA-CBM Functional Blocks MIMOSA is the Machinery Information Management Open Standards Alliance (www.mimosa.org). It is a standards body with members from about 50 international companies and some branches of the US Department of Defense. MIMOSA manages and publishes the OSA-CBM standard. The Open Systems Architecture for Enterprise Application Integration (OSA-EAI) is another of the MIMOSA body’s family of standards. OSA-EAI defines data structures for storing and moving collective information about all aspects of equipment, including platform health and future capability, into enterprise applications. This includes the physical configuration of platforms as well as reliability, condition, and maintenance of platforms, systems, and subsystems. OSA-CBM uses many of the data elements that are defined by the OSA-EAI. The goal is to have OSA-CBM map totally seamless into OSA-EAI, with future releases. OSA-CBM defines the interfaces between the functional blocks in a CBM system. Vendors can develop algorithms to fit inside of these blocks, separating the information processing from how it is presented. This separation allows proprietary code and algorithms to be kept hidden inside each of the functional blocks (Figure 2). It also creates a plug and play capability where vendors can easily insert updates or roll back to previous versions without affecting other modules or programs relying on the functional blocks.

Figure 2 – Example of Proprietary Algorithm in an OSA-CBM Layer

OSA-CBM’s six independent blocks of functionality are defined by ISO-13374. ISO-13374 does not specify how to implement condition monitoring systems, what technologies to use, or what algorithms to implement. Rather, it provides a general framework for the condition monitoring and diagnostics domain (Figure 3). OSA-CBM defines the data types used for processing and results reported in a condition monitoring system as well as how that information is moved between process and storage points. This allows each layer or block of functionality to be developed independently.

Figure 3 - ISO-13374 Data Processing and Information Flows

The first three layers are typically technology specific (e.g. vibration monitoring, temperature monitoring, electrochemical monitoring) and provide these functions: Data Acquisition (DA): converts an output from the transducer to a digital parameter representing a physical quantity and related information (such as the time, calibration, data quality, and data collector utilized, sensor configuration). Data Manipulation (DM): performs signal analysis, computes meaningful descriptors, and derives virtual sensor readings from the raw measurements. State Detection (SD): facilitates the creation and maintenance of normal baseline “profiles”, searches for abnormalities whenever new data are acquired, and determines in which abnormality zone, if any, the data belong (e.g. alert or alarm). The second three layers combine human concepts with monitoring technologies in order to assess the current health of the machine, predict future failures and provide recommended action steps to operations and maintenance personnel: Health Assessment (HA): diagnoses any faults and rates the current health of the equipment or process, considering all state information. Prognostics Assessment (PA): determines future health states and failure modes based on the current health assessment and projected usage loads on the equipment and/or process, as well as remaining useful life. Advisory Generation (AG): provides actionable information regarding maintenance or operational changes required to optimize the life of the process and/or equipment. An OSA-CBM block often needs to request information from another block. For example, in a web services implementation one block can add a web reference to the web service providing another block. Although OSA-CBM is often shown as a hierarchical architecture from AG->PA->HA->SD->DM->DA, there is no restriction concerning what blocks can access another. Any block can access any other block, as long as one knows the proper location of the other block. The OSA-CBM standard encourages modularity between layers by defining the inputs and outputs of each layer. Generally speaking, the functionality of an OSA-CBM layer can be broken down into three steps:  Requesting data from another layer (if necessary) Processing data using proprietary algorithms Providing processed data to a client or clients 

3. OSA-CBM Information Types and Interfaces
OSA-CBM layers provide three main types of information: data, configuration, and explanation. Data is the information or event sets that the layer has generated. This would be sensor readings for the data acquisition layer and the health of a platform for the health assessment layer. Configuration provides information about a module’s input sources, descriptions of algorithms used for processing input data, a list of outputs, and various output specifics such as engineering units and thresholds for alerts. Explanation is the data or a reference to the data used by a module to produce an output. (There is also an Extensible information type which that is not regulated by the OSA-CBM standard. It is for application-specific purposes, where setup, control or error reporting may be required.) The OSA-CBM specification also defines four types of communication that may be used. They are synchronous, asynchronous, service, and subscription (data event server). Figure 4 describes the four interface types. The OSA-CBM UML defines the specific functions that each interface type utilizes. For example, an implementation using the synchronous interface would utilize the epRequestDataEventSet and epRequestConfig methods for obtaining Data and Configuration information, respectively. Listing 1 shows all eleven functions implemented by the synchronous interface.

Figure 4 - OSA-CBM Interface Types

4. Building an OSA-CBM System
Since OSA-CBM is a multi-technological implementation and defined only in UML, it may be implemented in any middleware programming language such as Web Services, CORBA, Java RMI, DCOM, etc… Two CBM systems developed using different languages will not be able to communicate, but the information they are communicating will be the same. This will make integrating them much simpler because the information and structure will be the same. New interfaces and protocols will not need to be developed.

To build an OSA-CBM system, the following steps can be followed:

  Choose a technology for implementation. This must be a middleware type technology such as DCOM, CORBA, Web Services, Java RMI, etc…   Turn the OSA-CBM UML into a usable format based on the technology chosen. For example, if web services were chosen, the UML would need to be changed to XML.  Choose one of the four communication types: synchronous, asynchronous, service or subscription.  Build OSA-CBM compliant interfaces for each block of functionality (layer) using the chosen technology and communication types. </li> <li>Build information processing modules for each block of functionality.</li> <li>Put the interfaces and processing modules together as a working system.</li> </ol>

5. OSA-CBM Data Model: Important Classes
The OSA-CBM standard is defined in UML and consists of a large collection of data classes, each with their own specific attributes. It is all of these classes together that comprises the information used within a CBM system. This section discusses the most important aspects of the OSA-CBM data model. Despite its large number of data classes, not every class in the standard will necessarily need to be utilized in a particular OSA-CBM implementation. In fact, a more efficient implementation would be the one that only uses or provides those classes which are necessary for the task at hand. There are, however, some important data classes that will most likely be utilized in almost all OSA-CBM systems. A quick perusal of the UML specification reveals the ubiquity of the following classes: Site, MIMKey2, MIMExtType, and MonitorId. Each of these classes will now be explained. It may be useful to refer to the UML document while reading this section.

Site
The MIMOSA Common Relational Information Schema (CRIS), from which many of the OSA-CBM classes were derived, defines a Site as an “enterprise-defined object (manufacturing plant, office facility, large fleet object) which is composed of functional Segments where serialized Assets may be installed over time.” In OSA-CBM, the Site class contains five attributes: category, siteId, regId, userTag and systemUserTag. The category parameter indicates a specific site type from an enumerated list called SITE_CATEGORY. The siteId attribute is a 16-character hexadecimal string, assigned by MIMOSA, which corresponds to a specific site. The attribute titled regId is a string assigned by MIMOSA for a specific registered user. userTag is a string uniquely assigned by a registered user for each of the user’s mobile platforms. A Site can be uniquely identified either by siteId or by a (regId, userTag) string combination.

MIMKey2
The MIMKey2 class contains information that references MIMOSA table keys. It has the following attributes: site, id and name. The id parameter is an unsigned long that references a specific MIMOSA “measurement location” or “agent”. MIMOSA defines a measurement location as “the physical position on an asset or segment where actual measurements will be taken”. An agent is “any ‘intelligent’ entity which might act on the MIMOSA database such as an Organization, Group, Individual, Intelligent Agent, or Software System.” All OSA-CBM layers have their associated data events. Data events from the lower three layers (DA, DM, and SD) correspond to measurement locations, whereas data events from the higher three layers (HA, PA, and AG) correspond to agents. Finally, the MIMKey2 attribute titled name is a string identifier for the measurement location or agent in question.

MIMExtType
MIMExtType, short for “MIMOSA Extensible Type”, is defined by the MIMKey3 class. It contains four attributes: code, dbId, name and site. The code parameter is an unsigned long value that refers to a MIMOSA type code. dbId is an unsigned long identifier for a specific MIMOSA database. A MIMOSA database is defined as “a repository of MIMOSA data or information at a Site. A Database is associated with exactly one Site.”

MonitorId
MonitorId is used to reference a monitored measurement location, agent, or item. It contains the following four attributes: site, id, type, and itemId. The attribute id is an unsigned long Site-associated identifier for a monitored component. type is an enumerated value (from DataIdType) that indicates whether id is referencing a measurement location or an agent. The itemId attribute is based on the ItemId class. ItemId references either a segment or an asset. MIMOSA defines a segment as a “functional location at/of a Site. Types of segments include enterprises (for enterprise-level monitoring or work assignments), sites (for site-level monitoring or work/assignments), platforms, facilities, production processes, process inputs and outputs, physical structures, systems, sub-systems, machine trains, mechanical devices, and mechanical device areas.” An asset is “a physical, non-intelligent instantiated object. An asset may be an entire facility, an entire functioning system, or a component piece of equipment, such as a specific instance of a bearing. An asset may be installed on/at a segment.” The ItemId class has five attributes: segOrAs, site, code (optional), userTag (optional), and name (optional). segOrAs is an enumerated value that specifies either a segment or an asset. The code parameter is an unsigned long that corresponds to either a MIMOSA asset type code or a MIMOSA segment type code. When using ItemId, either code or userTag must be entered to properly identify a system component. Now that the most commonly used classes in the standard have been discussed, an explanation of the two main information types in the OSA-CBM standard can be given.

6. Information Types
There are four main categories of information in OSA-CBM: Data, Configuration, Explanation and Extensible. The two most important types, Data and Configuration, are explained below.

6.1 Data
Data (or Dynamic Data), is the data provided by the layers of an OSA-CBM system. The principal classes for this information type are DataEvent and DataEventSet. A DataEvent contains the data generated by a layer’s output “port” (see Port class). In the UML specification, we see that each OSA-CBM layer has its own associated data event (DADataEvent, DMDataEvent, SDDataEvent…) that inherits directly from the DataEvent class. The DataEvent class has five attributes: id, site (optional), confid (optional), time (optional), and alertStatus (optional). The id attribute equates to either a MIMOSA measurement location or agent identifier. The confid attribute is the confidence in the accuracy of the value(s) supplied by the DataEvent (0 = no confidence, 100 = complete confidence). The next attribute, time, is an OsacbmTime parameter that provides the time associated with the particular DataEvent. The Boolean alertStatus parameter indicates whether or not the DataEvent has an alert associated with it. Each of the six OSA-CBM layers has its own section in the UML documentation. For Data Acquisition, we see that DADataEvent (which inherits from DataEvent) has seven child classes inheriting directly from it: DAWaveform, DABLOBData, DAVector, DADataSeq, DABool, DAReal, and DAInt. Because of their inheritance, any of these seven classes may be used as an event supplied by the DA layer. Similarly, the child classes listed on the following pages for the other five layers (DMVector, SDTestReal, HADataEvent, AGDataEvent, etc…) may be used as data events for their respective layers as well. For example, the Data Acquisition data event in a particular OSA-CBM system may contain waveform values that were read-in from a DAQ and stored as a DAWaveform. Another example for a data event could be an integer value stored as an SDInt in the SD layer. It is also important to note that the DADataEvent, DMDataEvent and SDDataEvent classes all contain an attribute called numAlerts that is defined by the NumAlert class. When a DataEvent value triggers an alert (see the AlertRegion class), it produces an associated NumAlert. The NumAlert class specifies when the alert occurred and contains a MIMOSA type code that identifies what the alert actually is. Finally, in the Data Event section of the UML, we see that it is possible for a layer to return multiple DataEvents by utilizing the DataEventSet class. This class must contain one or more DataEvents and has site, id, time, and alertStatus as attributes.

6.2 Configuration
Configuration provides information about an OSA-CBM module’s input sources, descriptions of the algorithms used for processing the input data, a list of outputs, and various output specifics such as engineering units and thresholds for alerts. The Configuration class is given in the Configuration section of the OSA-CBM specification. It has the following five attributes: inportModuleSet, algorithms, outPortSet, moduleId and supportingData. The inportModuleSet attribute provides information about where a module gets its data from. Specifically, it is defined by the ModuleRef class and contains a MIMKey2 reference to the source of data. The algorithm attribute describes the processes used to generate a data event given the input data. The Algorithm class provides information related to the type of algorithm(s) used, the input data, and the outputs produced. The outPortSet parameter is defined by the OutPortSet class. OutPortSet lists each output Port (or “out port”) for the module in question. An “Out Port” is defined as a “data output channel of a module” and the Port class contains the associated configuration/metadata information, such as engineering units. The Port class also has a child hierarchy inherited from it that associates to each OSA-CBM layer (DAPort, DMPort, SDPort, etc…). Configuration’s moduleId attribute is used to provide a top level description of an OSA-CBM module or entry point. It is defined by the ModuleDescriptor class, which contains the following attributes: modIdSite, modIdCode, modTag, modName, description and version. The supportingData attribute provides additional information about MIMOSA MIMKey references which may be used elsewhere in an OSA-CBM system. For example, agents are referred to only by their MIMKey2 handle; supportingData may be used to provide detailed information about them. It is defined by the SupportingData class, which contains the following attributes: items, funcs and agents.

7. The OSA-CBM Synchronous Interface
Now that the important aspects of the OSA-CBM data model have been covered, we can take a closer look at how to go about accessing and moving the data in an OSA-CBM system. As mentioned earlier, there are four interface types that can be used in an OSA-CBM system (Figure 4). The synchronous communication type is going to be discussed here. All four of the communication types can be found in the UML specification. In the synchronous interface, a request is sent to a layer, and the data is then returned back along the same path. Listing 1 shows the eleven functions used by the interface.

Listing 1 – Methods for a Synchronous OSA-CBM Layer

The DataEventSet class is used for providing one or more DataEvents. In order for an OSA-CBM layer to output a DataEventSet, it needs to receive a request for one, which is what the epRequestDataEvent function is for. This function has one input argument, MonitorIdGroup, which is used for referencing monitored measurement locations, agents and items (it may contain multiple MonitorIds). To request Configuration information, the epRequestConfig function is used. It has one input parameter, ConfigRequest. This data object can be used to select possible subsets of Configuration information, in order to reduce the size of the returned request, if desired.

The next four functions in the synchronous interface are related to Explanation information. The Explanation classes provide developers with four possible ways to describe where a layer acquired its data from. ExplanationDataSet provides the actual DataEventSet used in calculations. ExplanationDataSetRef is a handle to a well-known location where the data is stored, such as in a database. ExplanationSrcs and ExplanationSrcsStr provide two different ways of giving direct access to the modules supplying the data. The former is a set of direct pointers to the modules; the latter is a “stringified” form of a pointer. As we see in Listing 1, all four Explanation methods take MonitorIdGroups as inputs.

The remaining functions: epNotifyControl, epRequestControl, epNotifyApp, epRequestApp, and epRequestErr are all related to the Extensible Components section of the specification. They return XML strings that are not defined or regulated by the OSA-CBM standard. Their use is optional and can vary by application. Certain systems may utilize them for handling setup, control or error reporting. For example, the epRequestErr function was used in a PSU/ARL implementation to report errors for a layer. The functions epRequestControl and epNotifyControl were utilized for, respectively, requesting and changing various control parameters in the OSA-CBM layers (e.g. sampling rate, mission profiles, etc…). Appendix A: XML Extensibility Concept Extensible type classes are for application-specific purposes. Integrated vehicle health management (IVHM) applications may require specific categories of information for setup and control. These classes allow for a standard way to input and output application-specific XML. The getXML operation is a suggested method for a parent wrapper class to have. Implementations should have a getXML method to retrieve a transmittable XML form. The main concept is to have a class that is closed to modification but extensible to users. The XML string is used as the conveyor of data. Specific implementations can use the specific form class structure. See UML diagram below.

Appendix B: OSA-CBM and OSA-EAI Mapping Methodologies The overall goal is to have OSA-CBM map seamlessly into OSA-EAI. The OSA-CBM to OSA-EAI mapping will have the following components: 1.	A simple one-to-one information component mapping. 2.	OSA-CBM extensions to CRIS that have extra information that OSA-EAI does not need. 3.	A mapping document where difficult mappings or mappings that have many potential solutions are specified to be done only one way.

Perhaps 90% or more of OSA-CBM will map directly into OSA-EAI with ease. There will, though, be some changes and additions in OSA-EAI to facilitate with the mapping. There are certain differences and some OSA-CBM needs which are to be handled by OSA-CBM extensions in the MIMOSA specification. The main requirement for the extensions deal with the ability to get data out of database storage in the original OSA-CBM format with all class structures intact and easily retrievable by a generic mechanism. Main areas for extensions include: 1.	The OSA-CBM class-type definition specifics. The ability to know which OSA-CBM class was used to transmit the data. 2.	The OSA-CBM timestamp-based message identification scheme. In OSA-CBM, all messages such as measurement events, health assessments and proposed events are identified by agent or meas_location, time stamp, and, in the HA and PA layers, item id. OSA-CBM small signature vehicles are not expected to generate new integer primary key signatures. The ability to do that would require non-volatile memory storage of some form to remember the last number used. Instead, OSA-CBM offers a slightly different primary key basis (agent, time, item). All the same important information components like those found in OSA-EAI are there. When such a message reaches an OSA-EAI database location, the OSA-EAI proposed event primary key signature may be generated. 3.	OSA-EAI has been enhanced to accommodate Ambiguity Groups. 4.	Explanation is the ability to show a connection between the data used as input and the resultant data. The OSA-CBM Explanation classes use references within the OSA-CBM context. An OSA-CBM extensions Explanation table will be used by those desiring that this information be retrievable. OSA-EAI has many data tables for those desiring this information in the OSA-EAI context. Glossary

Advisory Generation (AG) Layer – One of the six OSA-CBM layers. The AG layer provides actionable information regarding maintenance or operational changes required to optimize process/equipment life.

Asynchronous Interface – Data is returned as available via an EntryPointSink object.

Configuration – Information about an OSA-CBM module’s input sources, description of algorithms used for processing input data, a list of outputs and a list of various output specifics such as engineering units, thresholds for alerts, etc.

Data Acquisition (DA) Layer – One of the six OSA-CBM layers. The DA layer converts an output from a transducer to a digital parameter representing a physical quantity or related type of information (such as time, calibration, data quality, and data collector utilized, sensor configuration).

Data Manipulation (DM) Layer – One of the six OSA-CBM layers. The DM layer performs signal analysis, computes meaningful descriptors, and derives virtual sensor readings from raw measurements.

Data Service Interface – Client only accepts data (for example, a database for archiving data).

DataEvent Server (Subscription) Interface – Client subscribes to data, which Server sends regularly or on alert.

Explanation – The data or a reference to the data used by a module to produce an output.

Health Assessment (HA) Layer – One of the six OSA-CBM layers. The HA layer diagnoses any faults and rates the current health of equipment/ processes using available state information.

LRU – Line Replaceable Unit.

Module – An implementation of an OSA-CBM layer.

Open Systems Architecture for Condition-Based Maintenance (OSA-CBM) – A standard architecture, defined in UML, for moving information in a condition-based maintenance system.

OSA-CBM Layer – One of the six layers in the OSA-CBM Specification (Data Acquisition, Data Manipulation, State Detection, Health Assessment, Prognostic Assessment, Advisory Generation).

Prognostics Assessment (PA) Layer – One of the six OSA-CBM layers. The PA layer determines future health states and failure modes based on the current health assessment and projected usage loads on equipment/processes, as well as remaining useful life values.

State Detection (SD) Layer – One of the six OSA-CBM layers. The SD layer facilitates the creation and maintenance of normal baseline “profiles”, searches for abnormalities whenever new data are acquired, and determines in which abnormality zone, if any, data belongs (e.g. alert or alarm).

Synchronous Interface – Data is returned by the Request method. References

Walter R., Lebold M., Boylan D., Puri G., “Data Standards for Processing, Transmitting and Archiving Prognostic Health Information.” Logistics Transformation Agency and Common Logistics Operating Environment Study. May 2006.

Walter R., “Open Systems Architecture for Condition-Based Maintenance (OSA-CBM) Primer.” August 2006.

Puri G., Boylan D., Walter R., Lebold M., “Building an OSA-CBM System: A Guide for Developers.” November 2006.

Walter R., Pike C., Boylan D., Puri G., “A Combined OSA-EAI and OSA-CBM Demonstration Application.” January 2008.

OSA-CBM UML Specification v3.2

MIMOSA Website: http://www.mimosa.org