Open Architecture for Condition Based Maintenance - Engineering ...

ARL
Penn State
Slide 1
OSA-CBM: OSA CBM: An Open
System Architecture for
Machinery Monitoring
Structural Health Monitoring COE Inaugural Meeting
– April 13 th 2007 -
Contact at ARL
Mitchell Lebold
814.865.8958 (voice)
814.863.0673 (Fax)
Lebold@psu.edu
http://www.arl.psu.edu

ARL
Penn State
Slide 2
• Condition Based Maintenance
(CBM) Systems
• OSA-CBM Development Team
• OSA-CBM Architecture
– Data and Control
– Data Models
• UML
• AIDL
– Middleware Technologies
• CORBA
• COM/DCOM
• XML over HTTP
– Design Flexibility and Examples
• OSA-CBM Website
Health
Assessment
Faulty
Uncertain
Healthy
Condition
Monitor
Accelerometer
Data
Band-Pass
Filter
Band-Pass
Filtered
Signal
Half-wave
or
Full-wave
Rectifier
Envelope Detector
Rectified
Signal
Peak-Hold
Smoothing
Envelope
Detected
Signal
Data
Manipulation
N
4
N∑
( ri
− r )
i=
1
NA4
=
2
⎧ m N
1 ⎡
2 ⎤⎫
⎨ ∑∑ ⎢ ( rij
− rj
) ⎥⎬
⎩m
j=
1⎣i= 1 ⎦⎭
Overview
Prognostics
Distributed
Computing
Technology
Data
Acquisition
Traditional
Sensor
Smart Sensor
Decision
Support
Presentation

ARL
Penn State
Slide 3
Typical Condition Based
Maintenance System Design

ARL
Penn State
Slide 4
Complex
System Complex
System
Data
Acquisition
Passive/
Smart Sensor
Array
S1
S2
.
.
.
SN
Data
Manipulation
- Pre-processing
- Feature
Extraction
- Signal
Charact.
i
Condition
Monitor
- Thresholds
- Fuzzy Logic
CBM Systems
Typical CBM System Design:
Health
Assessment
- Component
Specific
Feature
Extraction
- Anomaly &
Diagnostic
Reasoners
Prognostics
- Feature-Based
Prognostics
- Model-Based
Prognostics
Physical Models
Automatic
Decision
Reasoning
- Data
Fusion
- Classifier
- Response
Generator
Mission Plans
Human -
Computer
Interface

ARL
Penn State
Slide 5
Complex
System Complex
System
Data
Acquisition
Passive/
Smart Sensor
Array
S1
S2
.
.
.
SN
Data
Manipulation
- Pre-processing
- Feature
Extraction
- Signal
Charact.
General
Concerns:
i
Condition
Monitor
- Thresholds
- Fuzzy Logic
Health
Assessment
- Component
Specific
Feature
Extraction
- Anomaly &
Diagnostic
Reasoners
CBM Systems
• Complex design
• Propriety algorithms
• Large amounts of data
• Inflexible designs
Prognostics
- Feature-Based
Prognostics
- Model-Based
Prognostics
Physical Models
Automatic
Decision
Reasoning
- Data
Fusion
- Classifier
- Response
Generator
Mission Plans
Human -
Computer
Interface

ARL
Penn State
Slide 6
Complex
System Complex
System
Data
Acquisition
Passive/
Smart Sensor
Array
S1
S2
.
.
.
SN
Data
Manipulation
- Pre-processing
- Feature
Extraction
- Signal
Charact.
i
Condition
Monitor
- Thresholds
- Fuzzy Logic
CBM Systems
Resulting in“Black Box” and
“Stove Pipe” Solutions:
Health
Assessment
- Component
Specific
Feature
Extraction
- Anomaly &
Diagnostic
Reasoners
Prognostics
- Feature-Based
Prognostics
- Model-Based
Prognostics
Physical Models
Automatic
Decision
Reasoning
- Data
Fusion
- Classifier
- Response
Generator
Mission Plans
Human -
Computer
Interface

ARL
Penn State
Slide 7
OSA-CBM Development Team

ARL
Penn State
Slide 8
OSA-CBM Development Team
• 2001 - 2 year DUST program sponsored by ONR
and PEO Carriers:
– The Office of Naval Research under research grant
number: N00014-00-1-0155 OSA-CBM Boeing DUST
• Numerous team members and contributors:
Boeing, Caterpillar, Rockwell Automation, Penn
State/ARL, Newport News, Oceana Sensor
Technologies, Rockwell Scientific, MIMOSA, RLW,
…

ARL
Penn State
Slide 9
OSA-CBM Focus
Open System Architecture for Condition Based Maintenance
• Goals of the OSA-CBM program:
– Define and Development open standards for distributed
Condition Based Maintenance
– Define an open architecture not exclusive to any specific
hardware implementations, operating systems, or software
technology
• Software Architecture Description
– Define classical CBM functions and behavior
– Define module interfaces
– Developed multiple middleware implementations

ARL
Penn State
Slide 10
System
Developer/Engineer:
Project Manager:
OEM / Company:
Customer:
Why OSA-CBM?
• Only one non-priority interface to learn
• Standardized information exchange methods
• Reduce integration issues
• Increased security
• Remote module instantiation
• Broad choose of technologies
• Reduce time-to-market
• Increase profit margins
• Scalability, upgradability, and
interchangeability
• Broader supplier community
• Increased market competition resulting in
decreased prices

ARL
Penn State
Slide 11
OSA-CBM Architecture

ARL
Penn State
Slide 12
Open System Architecture for
Condition Based Maintenance
• Standardized architecture
for health and condition
monitoring systems
• Breaks monitoring system
into functional layers
• OSA-CBM standard
defines I/O for each
processing layer
• Promotes scalability and
upgradability
• Modules not confined to
one locale
• Middleware technology
independent
• www.osacbm.org

ARL
Penn State
Slide 14
Components of the
OSA-CBM Framework

ARL
Penn State
Slide 15
EP 1 EP 2
Component
EP 1 EP 2
Component
Generic Component Description
EP 1 EP 2
Component
EP 1 EP 2
Component
OSA-CBM Software Components
… implement the functionality of
individual layers of the architecture
… communicate in a client/server
relationship
… have EntryPoints that serve the
information needs of specific clients
… provide access to synchronized data
channel sets and to background
information through their interfaces

ARL
Penn State
Slide 16
Interfaces
- ReqXXData
• GetXXData
- GetXXExplanation
- GetXXConfig
EP 1 EP 2
Component
Generic Component Description
Interface Descriptions
Request Data: prompts a measurement or
calculation update
Get Data: returns dynamic measurement
data or a calculated result to the client
Get Explanation: returns a data structure
which describes the input data and data
transformation processes used in the
calculation of the associated output data set
Get Config.: returns static information
about the monitoring system and the
monitored system configuration

ARL
Penn State
Slide 17
Condition Monitor Module
CM
Configuration
INI File
OSA-CBM data model supports:
Synchronous, Asynchronous,
Service, and Subscription transfers
OSA-CBM Implementation
(5) Notify (3) Notify
(6) Access (4) Access
Data Manipulation Module
(1) RequestData (2) RequestData
DM
Configuration
INI File
Data Acquisition Module
DA
Configuration
INI File

ARL
Penn State
Slide 18
OSA-CBM Models

ARL
Penn State
Slide 19
Top Level UML Model
util::MIMExtType
+id : MIMKey3
ProcStrType
-child
InPort
-parent 0..1
0..*
MeasLocType
1
0..*
0..*
0..1
-type
0..*
0..*
-inPort
Function -func
+userTag : String
-name : String
0..*
AlgPort
+id : RemoteKey
0..1
PortType
Asset
-child
-by
AssetType
+source
0..*
-outPort
-portType
0..*
0..*
0..1
-serialNo : String
1..*
OutPort
+lastUpdate : OSACBMTime
-dataType : String
-parent
Item
+id : MIMKey2
+userTag : String
1..*
1
0..*
+outPort
-dataEvent
-topItem
Algorithm
+id : RemoteKey
-name : String
-version : String
1
+outPort
0..1
1
+outPort
1..* 1
0..1
-synchEvts 1..*
DataEventSet
+time : OSACBMTime
1..*
1..*
+algorithm
DataEvent
+confid : Double
0..*
OSA-CBM UML Models
+dataEvent
-dataEvent
OutPortSet
1
1
0..1
-eventSet
Segment
-segmGroup : Boolean
SegmentType
«singleton»
Module
1
1..*
+entryPoints
EntryPoint
+entryPtType : String
1
+expl
1
+outPortSet
+eventData
-type
0..1
Explanation
1..*
0..*
0..1
1
-expl
+EP
EventData
1..*
+inputEP
-expl
0..*
da
measEv propEv
dm cm ha pa
data
Organized in general, utility,
and layer packages
RED - Associated classes are exposed by
the data interface
GREEN - Associated classes are exposed
by the explanation
interface
BLUE - Associated classes are exposed by
the configuration interface
BLACK - Associations which are utilized
by all interfaces (common
concepts)
VIOLET - Represents a relationship
between data elements
which is not represented
by the OSACBM
interfaces.
util

ARL
Penn State
Slide 20
OSA-CBM UML Models
UML Modules
top – Top Module, Common Classes
da – Data Acquisition Module
dm – Data Manipulation Module
sd – State Detection Module
ha – Health Assessment Module
pa – Prognostics Assessment Module
ag – Advisory Generation Module
measEv – Measurement Event Module
propEv – Proposed Event Module
data – Data Module
util – Utility Module

ARL
Penn State
Slide 21
UML
enum EntryPointType {
da, dm, cm, ha, pa, ds, other
};
Manual
Conversion
/* 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;
};
AIDL
Abstract Interface
Document Language
Tags:
• Interface
[data][config]
[expl][org]
UML
syntax
• Class Type
[abstract]
• Multiplicity
[sequence]
[optional]
AIDL Equivalent
1 no optional tag, no sequence
0..1 optional tag, no sequence
1..* no optional tag, sequence
0..* optional tag, sequence

ARL
Penn State
Slide 22
UML
enum EntryPointType {
da, dm, cm, ha, pa, ds, other
}; enum EntryPointType {
da, dm, cm, ha, pa, ds, other
/* Entry }; point. enum */ EntryPointType {
interface EntryPoint da, dm, { cm, ha, pa, ds, other
/* /* Identification Entry }; point. enum
of */ OSA/CBM
EntryPointType
layer. */
{
interface EntryPoint EntryPointType
da, dm, { cm, ha,
entryPtType;
pa, ds, other
/* The /* set /* Identification Entry of ports
}; point. served of */ OSA/CBM by this entry layer. point. */ */
[data] [config] interface [expl] EntryPoint EntryPointType [async] { entryPtType;
/* The /* set OutPortSet
/* Identification Entry COM/DCOM
of COM/DCOM
ports point. served of */ OSA/CBM outPortSet; by this entry layer. point. */ */
/* Explanation [data] [config] interface
of what [expl] sources
EntryPoint EntryPointType [async] were
{
used by entryPtType; this module for its output. */
[expl] /* The /* set OutPortSet Identification of ports served of OSA/CBM outPortSet; by this entry layer. point. */ */
[optional] /* Explanation [data] Explanation [config] of what expl; [expl] sources EntryPointType [async] were used by entryPtType; this module for its output. */
}; [expl] /* The set OutPortSet of ports served outPortSet; by this entry point. */
[optional] /* Explanation [data] Explanation [config] of what expl; [expl] sources [async] were used by this module for its output. */
}; [expl]
OutPortSet outPortSet;
[optional] /* Explanation Explanation of what expl; sources were used by this module for its output. */
}; [expl]
[optional] Explanation expl;
};
enum EntryPointType {
da, dm, cm, ha, pa, ds, other
};
AIDL
/* 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;
};
enum EntryPointType {
da, dm, cm, ha, pa, ds, other
}; enum EntryPointType {
da, dm, cm, ha, pa, ds, other
/* Entry }; point. enum */ EntryPointType {
interface EntryPoint da, dm, { cm, ha, pa, ds, other
/* /* Identification Entry }; point. enum
of */ OSA/CBM
EntryPointType
layer. */
{
interface EntryPoint EntryPointType
da, dm, { cm, ha,
entryPtType;
pa, ds, other
/* The /* set /* Identification Entry of ports
}; point. served of */ OSA/CBM by this entry layer. point. */ */
[data] [config] interface [expl] EntryPoint EntryPointType [async] { entryPtType;
/* The /* set OutPortSet
/* Identification Entry of ports point. served of */ OSA/CBM CORBA
outPortSet; by this entry layer. point. */ */
/* Explanation [data] [config] interface
of what [expl] sources
EntryPoint EntryPointType [async] were
{
used by entryPtType; this module for its output. */
[expl] /* The /* set OutPortSet Identification of ports served of OSA/CBM outPortSet; by this entry layer. point. */ */
[optional] /* Explanation [data] Explanation [config] of what expl; [expl] sources EntryPointType [async] were used by entryPtType; this module for its output. */
}; [expl] /* The set OutPortSet of ports served outPortSet; by this entry point. */
[optional] /* Explanation [data] Explanation [config] of what expl; [expl] sources [async] were used by this module for its output. */
}; [expl]
OutPortSet outPortSet;
[optional] /* Explanation Explanation of what expl; sources were used by this module for its output. */
}; [expl]
[optional] Explanation expl;
};
AIDL
AIDL provides the
mechanism for porting
to any Middleware
Technologies
Middleware Technologies
enum EntryPointType {
da, dm, cm, ha, pa, ds, other
}; enum EntryPointType {
da, dm, cm, ha, pa, ds, other
/* Entry }; point. enum */ EntryPointType {
interface EntryPoint da, dm, { cm, ha, pa, ds, other
/* /* Identification Entry }; point. enum
of */ OSA/CBM
EntryPointType
layer. */
{
interface EntryPoint EntryPointType
da, dm, { cm, ha,
entryPtType;
pa, ds, other
/* The /* set /* Identification Entry of ports
}; point. served of */ OSA/CBM by this entry layer. point. */ */
[data] [config] interface [expl] EntryPoint EntryPointType [async] XSD { entryPtType;
/* The /* set OutPortSet
/* Identification Entry of ports point. XSD using
served of */ using
OSA/CBM outPortSet; by this entry layer. point. */ */
/* Explanation [data] [config] interface
of what [expl] sources
EntryPoint EntryPointType [async] were
{
used by entryPtType; this module for its output. */
[expl] /* The /* set OutPortSet Identification of ports served of OSA/CBM outPortSet; by this entry layer. point. */ */
[optional] /* Explanation [data] Explanation [config] of what expl; [expl] sources EntryPointType [async] were used by entryPtType; this module for its output. */
}; [expl] /* Web The set OutPortSet of ports served outPortSet; by Services
this entry point. */
[optional] /* Explanation [data] Explanation [config] of what expl; [expl] sources [async] were used by this module for its output. */
}; [expl]
OutPortSet outPortSet;
[optional] /* Explanation Explanation of what expl; sources were used by this module for its output. */
}; [expl]
[optional] Explanation expl;
};

ARL
Penn State
Slide 23
Middleware Technologies

ARL
Penn State
Slide 24
Applications
Data
Acquisition
Endsystem
Data
Manipulation
Condition
Monitor
Middleware Technology
Health
Assessment
Applications
Decision
Support
Domain-Specific Services
Common Services
Distribution Middleware
Infrastructure Middleware
COM/DCOM, CORBA, SOAP, JAVA-RMI,…
}
Benefits
•Hide underlying complexity,
•Share common services,
•Synchronize program execution,
•Balance system load,
•Real-time solutions,
•Cross-language, and
•Cross-platform support
Domain-Specific Services
Common Services
Distribution Middleware
Infrastructure Middleware
Wired/Wireless Networks
Prognostic
Assessment
Middleware Middleware
Operating System Operating System
}
Distributed Computing ‘Glue’
Software layer between application and
communication networking layer
Endsystem

ARL
Penn State
Slide 25
Middleware Technologies
CORBA
– Common Object Request Broker Architecture
(CORBA) is the Object Management Group's
answer to the need for interoperability among the
rapidly proliferating number of hardware and
software products available today.
– Introduced CORBA 1.1 in 1991
– The OMG's CORBA is a specification, not a
software implementation of a middleware.
– Real-time version available

ARL
Penn State
Slide 26
Middleware Technologies
COM/DCOM
– Component Object Model (COM)/ Distributed
Component Object Model (DCOM) is a Microsoft
Technology to replace Object Linking and
Embedding (OLE) and Dynamic Data Exchange
(DDE).
– DCOM emerged to address COM's shortcomings in
supporting remote components. DCOM is an
extension to COM that allows networked
interaction between two programs even if they are
written in different programming languages.

ARL
Penn State
Slide 27
Benefits of COM/DCOM
• Increased Security
• Remote Module Instantiation
• Standardized Information
Exchange
• Client Control (lifetime, termination,
Reference,...)
• Internal Pinging Mechanism
COM/DCOM Interfaces:
• requestOutPortSet(id, sink)
• notifyOutPortSet(id, data)
• getTaskStatus(Seconds)
• getExpl(expl)
Use of ID’s:
• Allow flexible/tailored design
• Control how data is updated
• Control how data is processed
COM/DCOM
Sink and Data Pointers:
• Allows asynchronous
communication between
modules
• Contains relevant information
about the data: Time, Eng.
Units, Confid., asset and
organizational info…

ARL
Penn State
Slide 28
Gearbox Prognostic
Application
COM/DCOM
Modules Developed:
• DA
• DM
• CM
• HA
• PA
• PL
COM/DCOM

ARL
Penn State
Slide 29
XML over HTTP
Middleware Technologies
– XML (eXtensible Markup Language) is not a
middleware technology, it is simply a userdefinable
data format
– However, XML may be used with any networking
technology for data transfer.
– Tag structure format similar to HTML
– XML started in 1996 and has been a World Wide
Web Consortium (W3C) recommendation since
February 1998
– Use SOAP or Web Services to transfer data

ARL
Penn State
Slide 30
SOAP Interfaces:
• requestData(request)
• forceNewData(request)
• getAvailableData(request)
XML over SOAP
Benefits of using SOAP
• Platform Independence
• Language Independence
• Reduced Network
Restrictions
(uses port 80)
• Standardized Information
Exchange

ARL
Penn State
Slide 31
OSA-CBM Design Flexibility

ARL
Penn State
Slide 32
OSA-CBM Design Examples

ARL
Penn State
Slide 33
Engine
Monitoring
Hardware
Maintenance Information Backbone (MIB)
Example
MIB Demonstration System
MIB Software

ARL
Penn State
Slide 34
OSA-CBM Design Examples

ARL
Penn State
Slide 35
MIMOSA (OSA-CBM) Website

ARL
Penn State
Slide 36
WWW.OSACBM.ORG
WWW.MIMOSA.ORG
OSA-CBM Website
• Documents and
Presentations
• OSA-CBM Models
• UML
• AIDL
• COM/DCOM IDL
• CORBA IDL
• XML Schema
• Training Material
• Developer’s Tools
and Example Code
• Real-time Demo
• Glossary
• Useful References

ARL
Penn State
Slide 37
• This work was supported by:
Acknowledgements
– The Office of Naval Research under research grant
number: N00014-00-1-0155 OSA-CBM Boeing DUST
• OSA/CBM team members and contributors
include: Boeing, Caterpillar, Rockwell Automation,
Penn State, Newport News, Oceana Sensor
Technologies, Rockwell Scientific, MIMOSA…

ARL
Penn State
Slide 38
OSA-CBM: OSA CBM: An Open
System Architecture for
Machinery Monitoring
Structural Health Monitoring COE Inaugural Meeting
– April 13 th 2007 -
Contact at ARL
Mitchell Lebold
814.865.8958 (voice)
814.863.0673 (Fax)
Lebold@psu.edu
http://www.arl.psu.edu

ARL
Penn State
Slide 39
Backup Slides

ARL
Penn State
Slide 40
MIMOSA and OSA-CBM
MIMOSA is a standard for data exchange between
Asset Management systems
OSA-CBM is a specification for transactions
between components within a Condition-Based
Maintenance system
util::EngUnit
0..1
0..1
-amplEU
-xAxisEU
0..*
0..*
-daAmpl
-daXAxis
WaveForm
+xAxisDelta : Double
#value : Double
-xAxisStart : Double
top::EventData
DAEventData
BLOB
-MEvBlobType
0..*
1
util::MIMExtType
+id : MIMKey3
0..1
+data
1
MEventBlobType
data::BLOB
+contentType : Mime
#data : byte
• The core of the OSA-CBM standard is the
Object Oriented data model, defined using
UML (Unified Modeling Language) syntax
• The OSA-CBM UML data model is a
mapping of key concepts from the MIMOSA
CRIS with extensions for diagnostics,
prognostics and data transactions