Infotech@Aerospace 2011 AIAA 2011-1468

29 - 31 March 2011, St. Louis, Missouri

Application of the Data Distribution Service for

Implementing OSA-CBM Standard
Tarapong Sreenuch1, Antonios Tsourdos2 and Peter Silson4
Department of Informatics & Systems Engineering, Cranfield University-CDS, Shrivenham, Swindon SN6 8LA, UK

and

Ian Jennions3
Integrated Vehicle Health Management Centre, Cranfield University, Cranfield, Bedford MK43 0FQ, UK

As unmanned systems become standard equipment, the ability to monitor and manage
system health is not just an enabling technology, but is required in order to meet platform
availability and supportability goals. Its unique requirements can affect the selection of
hardware, the strategy for collecting and processing data, and the integration of health-
related information with other subsystems. The Open System Architecture for Condition
Based Maintenance (OSA-CBM) is a standard aimed to reduce the development and
integration cost of Integrated Vehicle Health Management (IVHM) systems and to achieve a
higher level of performance that includes totally integrated diagnostics and prognostic
capabilities. However, despite the well-known advantages of the approach, there have been a
few implementation examples of the standard. In this paper, we discuss the applicability of
the data centric publish/subscribe model for the design and development of OSA-CBM
systems. Computational power and bandwidth are always the key constraints in IVHM
application deployments. The publish/subscribe software model is used to form a
fundamental structure of the OSA-CBM software, both module’s internal components and
inter-module (middleware) communications. The primary benefit of publish/subscribe
interaction style is that it abstracts the message transport from the software components or
modules and allows them to be uncoupled. The module can add/change/remove internal
components from the internal publish/subscribe data domain, called blackboard, and
subscribe to local add/change/remove notification. Module blackboards are to assure
scalability and reconfigurable. The resulting OSA-CBM design provides software enabling
capability to distribute/reconfigure IVHM data processing algorithms across the hardware
platforms to meet the required computation and bandwidth constraints. Moreover, another
system potential would be a rapid deployment capability, which a generic OSA-CBM
module can be programmed via a process description script change. This frees developers to
concentrate on the domain-specific issues of their application. Finally, an example
application is presented based on a Machine Fault Simulator Gearbox to illustrate the
described aspects.

Nomenclature
AG = Advisory Generation
API = Application Programming Interface
CBM = Condition Based Maintenance
DA = Data Acquisition
DM = Data Manipulation
EPS = Electrical Power System

1
Research Fellow, Dpt. Informatics & Systems Engineering, Cranfield University, UK.
2
Professor, Dpt. Informatics & Systems Engineering, Cranfield University, UK.
3
Professor, Integrated Vehicle Heath Management Centre, Cranfield University, UK.
4
Senior Lecturer, Dpt. Informatics & Systems Engineering, Cranfield University, UK.
1
American Institute of Aeronautics and Astronautics

Copyright © 2011 by Cranfield University. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.
HA = Health Assessment
HM = Health Monitoring
IVHM = Integrated Vehicle Health Management
OSA-CBM = Open System Architecture for Condition Based Maintenance
PA = Prognostic Assessment
RMI = Remote Methode Invocation
SD = State Detection
UDP = User Datagram Protocol
UML = Unified Modelling Language
XML = Extensible Markup Language

I. Introduction

I N today’s unmanned aerial vehicle (UAV) mission scenarios, UAVs are demanded to provide continuous
surveillance coverage over extended periods of time and hence the operators are to seek a comprehensive fleet
management system. More reliance is now placed on Integrated Vehicle Health Management (IVHM) systems to
extend functional life and to allow repairs to maximize affordability. From systems integration viewpoint, a major
obstacle in implementing IVHM systems is the integration of health management technology into the platform
avionics and existing off-board software architecture. A standard like Open System Architecture for Condition
Based Maintenance (OSA-CBM) provides a great deal of benefit toward ease of integration between providers.
Careful consideration of the costs associated with applying a standard is required to make an intelligent decision
about how to make use of the standard (Ref. 1).
However, implementing the standard is by no means a trivial task, and very little information is available in the
literature. OSA-CBM developers have to implement not only the core software used to build up the OSA-CBM
module, but also data processing aspects, such as Fast Fourier Transform (FFT) algorithm, k-means clustering,
Bayesian reasoned, etc. These make the development process of OSA-CBM software troublesome and time-
consuming. In this paper, a software framework for development of OSA-CBM applications is proposed. It would
enable adopting companies to accelerate or ease the integration process of IVHM systems. The framework defines a
common or generic software structure used for constructing OSA-CBM modules. This allows the data processing
problem to be separated from the module construction problem. Developers could concentrate on the specific
Condition Based Maintenance (CBM) data processing logic rather than worrying about the software and interfacing
issues. Hence, the development efficiency is significantly improved.
The rest of the paper is organized as follows. Section II briefly describes the OSA-CBM specification and its
interpretation. Section III outlines the proposed OSA-CBM software structure and the ways in which the primary
components would suit for IVHM applications. An example of how the proposed framework is applied to a specific
IVHM application, i.e. Machine Fault Simulator (MFS) gearbox, is described in section IV.

II. OSA-CBM Specification

The OSA-CBM specification is defined by the Machine Information Management Open Systems Alliance
(MIMOSA) as a standard architecture for moving information in a condition-based maintenance system. The
architecture is divided into the information and interface specifications (see Fig. 1). These specifications are defined
using the Unified Modeling Language (UML) and intended to be platform independent which can be mapped into
various technologies.
The interface specification describes how information will be moved. There are 4 primary types of interface
defined in the specification: Synchronous, Asynchronous, Service and Subscription (see Fig. 1). In general, these
interfaces follow client-server style functional calls (i.e. Application Programming Interfaces (APIs)), where a
request is made to get information from an OSA-CBM module and a notification is made to input information into
an OSA-CBM module. It is not compulsory that all APIs within a chosen type of interface are implemented. An
OSA-CBM application is allowed to select only appropriate APIs from the subset to be implemented.
The information specification defines the form of information (data + metadata) that can be moved around in an
IVHM system (see Fig. 1). The data model of IVHM related data events is a direct map to the 6 abstract CBM data
processing functionalities/algorithms (see Fig. 2) categorized in ISO standard for Condition Monitoring and
Diagnostics of Machines - Data Processing, Communication and Presentation (Ref. 3). Functional definitions can be
viewed as abstractions of data into knowledge with higher and higher abstraction level of information. The data
generated by a DA-type algorithm is acquired sensor data that is formatted into a consistent form (Ref. 4). The DA
2
American Institute of Aeronautics and Astronautics
data is then manipulated and converted into more meaningful features by DM-type algorithms. An SD-type
algorithm compares features against expected values and outputs resulting data which enumerate condition
indicators. The data generated by next three layered algorithms are data related to current health of the machine,
predicted future failures and recommended action steps.

DataEvent
Sensor Inputs, Features,
Conditions, Health and
Prognostic Assessments,
and Action
Main EntryPoint Interface Forms
• Synchronous
• Asynchronous Configuration
• Data Service Explanation
Algorithms, Module
• DataEvent Server Descriptions, Input
Data’s Reference/Pointer
sources, outputs,
Interface Specification Engineering Units, etc.

Information Specification

Interface

OSA-CBM Module OSA-CBM Module

Data

Figure 1. OSA-CBM Specification.

Advisory Generation (AG) HADataEvent PADataEvent

Health Grade, Diagnosed Health Grade of Future
Fault, Failure with PDF Time, Remain Useful Lif e
Prognosis Assessment (PA)

Health Assessment (HA) SDDataEvent AGDataEvent

Enumerate state, Prioritized Operations,
Threshold, Severity of Maintenance Action
Threshold
State Detection (SD)

OSA-CBM
Data Manipulation (DM) DMDataEvent DADataEvent
Mapping Feature, Frequency Floating Point Value, Time
Series Data, Sample Test
Domain Data,
Normalization Results
Data Acquisition (DA)
DataEvent
ISO 13374’s 6 abstract data
processing functionalities OSA-CBM data model related to ISO-defined
data processing functionalities

Figure 2. Mapping ISO Defined 6 CBM Data Processing Functionalities to OSA-CBM DataEvent Model.

3
American Institute of Aeronautics and Astronautics
 In addition, the information specification also defines data model that are related to the OSA-CBM module
configuration. These include information about an OSA-CBM module’s input sources, a description of algorithms
used for processing input data, a list of outputs and various output specifics such as engineering units, thresholds for
alerts, etc. Explanation data model defines the data or a reference to the data used by a module to produce an output.
Compliant OSA-CBM module comprises of one or more types of internal data processing software components
defined above. The API provided by the module gives access to one or more data outputted from the data processing
components. Examples of compliant module are shown in Fig. 3. Modules #1and #2 have only the DA-type and
DM-type components, respectively. Module #4 has three types of data processing components: DA, DM and SD. In
this case, it may not be possible to read and use the DA and DM data due to limitations of the algorithms. Module #5
consists of SD-, HA- and PA-type components, and provides interfaces for HA and PA data.

OSA-CBM Module OSA-CBM Module OSA-CBM Module

#2 #3 #5
Advisory Generation (AG)

Prognosis Assessment (PA)

Health Assessment (HA)

State Detection (SD)

OSA-CBM Module OSA-CBM Module
Data Manipulation (DM)
#1 #4
Data Acquisition (DA)

Figure 3. Examples of OSA-CBM Compliant Modules.

III. Application Framework

To provide the reusability and configurability of the software development library, we build several key features
into the OSA-CBM application framework. The framework adopts a component-based approach, illustrated in Fig.
3, in designing a software structure for OSA-CBM module. For simplicity in implementation, the OSA-CBM
DataEvent Server interface (which has the least API methods) is selected in this paper. The main components are
described as follows:

DataEvent
Server DataEvent
Blackboard
Observer
DataEvent
Observer
DataEvent
Function Observer
Function
DataEvent Function

Receiver Central Logic

XML configuration file

OSA-CBM Module

Figure 4. OSA-CBM Component Model.

1. Entry Points
The OSA-CBM interface specification’s DataEvent Server subset defines two interfaces for an OSA-CBM
module (see Fig. 5): DataEventServer and DataEventReceiver. DataEventServer is the interface provided by an
OSA-CBM module to other OSA-CBM modules that have an interest in getting data from it. When a module wants
data from a server module, the requesting/client module uses the server module’s DataEventServer interface to make
a request. During the requesting process, the client module will provide a DataEventObserver to the server module.
4
American Institute of Aeronautics and Astronautics
The DataEventObserver contains a reference to the DataEventReceiver of the client and have the notification
method to be called by the server module when a new data is ready.

Figure 5. OSA-CBM DataEvent Server Interface.

2. Function
A Function is self-contained wrapper software for the data processing algorithm so that it can be used in an
OSA-CBM module. Functions communicate only with the OSA-CBM module’s internal components, reacting to
Blackboard data events and publishing results to the Blackboard. All Functions are implemented by
extending/inheriting from one of the basis Functions, i.e. TransducerFunction and DataProcessingFunction in Fig. 6.
Most if not all Functions, specialized behaviors are implemented by overriding the pre-defined methods of the
inherited Function, e.g. NiCDaqFnuction, RmsFunction, TsaFunction and ReasonerFunction in Fig. 6. In this way,
Functions bring functionality to the OSA-CBM module; they are the essential computing engines of each OSA-
CBM module.

Function
Abstract/generic

Data
Transducer Receiver Sender
Processing
Function Function Function
Function

NI RMS
CDAQ TSA Reasoner

NiCDaq Rms TSA Reasoner

Function Function Function Function

Figure 6. Example of Basis and Specialized Functions.

3. Blackboard
The Blackboard provides Functions with the ability to specify and interact with data event of specific interest to
that Function, see also (Ref. 5). It acts as an OSA-CBM module’s shared data space. The model of communication
5
American Institute of Aeronautics and Astronautics
between Blackboard and Functions is data-driven via publish-subscribe mechanism. The Blackboard tracks all
changes in the data event and distributes the updates to all interested subscribed Functions. Fig. 5 illustrates a linear
representation of the OSA-CBM module and Function activity as the module processes a single data event. In terms
of OSA-CBM application development, Function or algorithm developers would only have to focus on the
specialized Functions that are labeled Function #.. in the Fig. 7.

Receive Send
Function Function #.. Function #.. Function

Central Logic Central Logic

Boundary Blackboard Boundary

Figure 7. Function Data Processing Flow.

These few generic software components (i.e. Entry Points, Blackboard and Functions) act as building blocks of an
OSA-CBM module. The components are dynamically loaded and connected together at application start time. The
component interaction is through abstract interfaces, for example publish-subscribe API calls are used to pass data
between Blackboard and Functions. Complex data processing flows or complex algorithms are built using
combination of simple specialized Functions. This flexibility allows the developer to easily reuse pre-developed
Functions in and customize OSA-CBM application construction.
Until this end, our aims are to understand OSA-CBM and to create a sounded software framework for
development of OSA-CBM applications. The process is very experimental and highly iterative. As a matter of fact,
it takes about 4 times less to code in Java than to code in C++, and hence we have chosen Java to be the
development programming language and the Java’s Remote Method Invocation (RMI) to be the distributed
middleware. Time and ease of coding offered by Java outweigh the performance and portability offered by C++ in
this case.

IV. MFS Gearbox Application – A Case Study

Fig. 8 shows the rotating machinery test equipment for illustrating the design of a simple OSA-CBM based
vibration monitoring system. The experimental set up bases on the MFS equipped with the one-stage gearbox. The
undamaged and damaged with missing tooth gears are used to simulate rotating machine normal and fault behaviors
(see Fig. 9 (right)). The measurement comprises of 3 vibration channels, recorded using 3 accelerometers installed
on the gearbox case (see Fig. 9 (left)). The average speed is measured using a laser speed sensor and reflective tape
attached to the drive wheel of the belt transmission. All signals are recorded using the National Instrument (NI)
cDAQ data acquisition hardware. In this particular experiment setup, Ref. 6 shows that the vertical channel provides
the best difference of standard deviation for features from undamaged and damaged gears.
A variety of feature extraction methods for the detection of gear faults are described in the literature. The five
processing groups are: 1) Raw Signal, 2) Time Synchronous Averaged (TSA) Signal, 3) Residual Signal (RES), 4)
Difference Signal and 5) Band-Pass Mesh Signal (BPM) (Ref. 7). These five groups along with the associated
preprocessing and features are shown in Fig. 10 (left). In this paper, only the RAW and TSA groups are considered,
where Crest Factor, Kurtosis and FM0 are selected features. These features are fed into the classification algorithm,
i.e. a simple k-Nearest Neighbors (k-NN) algorithm, to detect faults in the gearbox. In this example, the underlying
algorithms are NI cDAQ Interface, Crest Factor, Kurtosis, TSA, FM0 and k-NN.

6
American Institute of Aeronautics and Astronautics
 Figure 8. MFS Damaged Gearbox Experimental Setup.

Figure 9. A Gearbox with Installed Accelerometers and a Damaged Gear with Missing Tooth.

OSA-CBM
Mapping
Advisory Generation (AG)

Prognosis Assessment (PA)

Health Assessment (HA)

RMS
Signal DC Offset Kurtosis State Detection (SD) K-Nearest Neighbour
Raw Signal Crest Factor
Conditioning Removal
Enveloping Crest Factor, Kurtosis, TSA, FFT, FM0
Conditioned Data Manipulation (DM)
Demodulation
Raw Signal
Skewness
Tacho
Time Synchronous Comblet Data Acquisition (DA) NI CDAQ
Averaging Interstitial
Wavelet

TSA Signal FM0

Remove BP around
Fundamental shaft fundamental mesh OSA-CBM
frequencies and frequency
harmonics including Wrapper
sidebands
NA4 Residual
NA4* Signal NB4
Function
Remove 1st order
sidebands
FM4
M6A Band-Pass Mesh Signal
M8A

Difference K-Nearest Neighbor Data

Signal Bayesian Transducer Receiver Sender
Processing
Fuzzy Function Function Function
Support Vector Machine Function

NI Crest
CDAQ Factor Kurtosis TSA FM0 FFT K-NN

NiCDaq CrestFactor Kurtosis TSA FM0 FFT KNN

Function Function Function Function Function Function Function

Figure 10. OSA-CBM Wrappers for the MFS Gearbox Algorithms.

7
American Institute of Aeronautics and Astronautics
 The OSA-CBM development framework described in section III is employed in building our OSA-CBM based
vibration monitoring system. The underlying algorithms are categorized according to the OSA-CBM abstract
functionalities shown in Fig. 10 (top-right), i.e. DA – NI cDAQ Interface, DM – Crest Factor, Kurtosis, TSA and
FM0 and SD – k-NN. These algorithms are the wrapped by extending/inheriting either the TransducerFunction or
DataProcessingFunction, and the resulting MFS gearbox specific Functions are shown in Fig. 10 (bottom-right). The
processed data outputted from the NiCDaqFunction, CrestFactorFunction, KurtosisFunction, TsaFunction,
Fm0Fucntion and KNNFucntion are OSA-CBM types of DAWaveform, DMReal, DMReal, RealWaveform,
DMReal and SDEnum, respectively. Finally, the XML configuration files are created, each files contain the
module’s specific configuration information. Fig. 11 shows one possible example of the OSA-CBM system for the
MFS gearbox application. The diagram shows the connection between the modules and details which abstract and
gearbox-related Functions are used in each individual modules.
The experiment is performed at constant shaft speed of ~400 rpm. The vertical acceleration and tacho channels are
sampled at 25 kHz, and the data frames used are 20 seconds in the tacho and vertical acceleration channels. Fig. 11
shows one possible example of the hierarchical OSA-CBM system. The diagram shows the connection between the
modules and details which abstract and gearbox-related Functions are used in each individual modules. An example
of technical displays is shown in Fig. 12, in particular the SD display where two train data sets of one sample, i.e. no
damage on teeth and missing tooth, are collected for the construction of neighboring sets used in the k-NN
algorithm.

KNN

K-NN

Receiver Sender
Function KNN Function
Function

Module #4
FM0
Crest Factor
Kurtosis

Crest
TSA FM0
Factor Kurtosis FFT

Receiver Receiver Sender

CrestFactor Kurtosis Sender TSA FFT FM0 Function
Function Function Function
Function Function Function Function Function

Module #2 Module #3
Acceleration Tacho

Acceleration
NI
CDAQ
Advisory Generation (AG)
Receiver NiCDaq Sender
Prognosis Assessment (PA)
Function Function
Function
Health Assessment (HA)
Module #1
State Detection (SD)

Data Manipulation (DM)

Data Acquisition (DA)

z-axis Acceleration and Tacho Signals

Figure 11. OSA-CBM Module Layout for the MFS Gearbox Application.

8
American Institute of Aeronautics and Astronautics
 Sample

Figure 12. Examples of OSA-CBM Module Technical Display.

V. Conclusion
A standard like OSA-CBM provides a benefit towards ease of integration between IVHM software components.
But it addresses only parts of the IVHM implementation problem, i.e. common interface and information schema.
To also enable reuse, process partitioning, configurable and rapid deployment, a development framework likes the
one described in section 3 is required. The proposed component model eases the OSA-CBM implementation process
as the common/generic OSA-CBM tasks are handled by the framework and the developed OSA-CBM algorithms
can be reused in a new application. Developers can concentrate on the application logic, i.e. CBM data processing,
rather than worrying about the software issues. With Off-the-Shelf or pre-existing OSA-CBM algorithm libraries,
the task of creating a new OSA-CBM application could be simplified to a matter of writing the OSA-CBM module
configuration files.

Acknowledgments
This research is funded by the IVHM Centre, Cranfield University. The authors would like to thank K. Keller
and D. Followell at the Boeing Company, St. Louis for giving numerous suggestions and guidance during the
workgroup meetings and also for helping in many other ways.

References
1
Swearingen, K. and Keller, K., “Health Ready Systems,” Proceedings of the IEEE AUTOTESTCON, Baltimore, MD, 2007,
pp. 625–631.
2
MIMOSA, “OSA-CBM UML Specification 3.3.1 Release,” Machine Information Management Open Systems Alliance,
Tuscaloosa, AL, 2010.
3
ISO, “13374-2 Condition Monitoring and Diagnostics of Machines - Data Processing, Communication and Presentation -
Part 2: Data Processing,” International Organization for Standardization, Geneva, 2007.

9
American Institute of Aeronautics and Astronautics
 4
Swearingen, K., Majkowski, W., Bruggeman, B. and Gilbertson, D., Dunsdon, J. and Sykes, B., 2007a. “An Open System
Architecture for Condition Based Maintenance Overview,” Proceedings of the IEEE Aerospace Conference, Big Sky, MT, 2007,
pp. 3717–3724.
5
Helsinger, A., and Wright, T., “Cougaar: A Robust Configurable Mulit-Agent Platform,” Proceedings of the IEEE
Aerospace Conference, Big Sky, MT, 2005.
6
Gelman, L., Jennions, I., and Petrunin, I., “Diagnosis of Local Tooth Damage for Gear by Residual Signal Technology,”
Technical report, Cranfield University, Bedfordshire, UK, 2010.
7
Lebold, M., McClintic, K., Campbell, R., Byington, C. and Song, E., “Review of vibration analysis methods for gearbox
diagnostics and prognostics,” The 54th Meeting of the Society for Machinery Failure Prevention Technology, Virginia Beach,
VA, 2000, pp. 623–634.

10
American Institute of Aeronautics and Astronautics