OSA-CBM: An Open Contact at ARL System Architecture for …cjl9:lebold_arl.pdf · Overview • Condition Based Maintenance (CBM) Systems • OSA-CBM Development Team • OSA-CBM Architecture

ARLPenn State

Slide 1

OSAOSA--CBM: An Open CBM: An Open System Architecture for System Architecture for Machinery MonitoringMachinery Monitoring

Contact at ARL

Structural Health Monitoring COE Inaugural Meeting– April 13th 2007 -

Mitchell Lebold814.865.8958 (voice)814.863.0673 (Fax)[email protected]://www.arl.psu.edu

ARLPenn State

Slide 2

Overview

• 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

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

ARLPenn State

Slide 3

Typical Condition Based Maintenance System Design

ARLPenn State

Slide 4

i

CBM Systems

DataAcquisition

Passive/Smart Sensor

Array

ComplexSystem

ComplexSystem

S1

S2

SN

DataManipulation

- Pre-processing

- Feature Extraction

- Signal Charact.

ConditionMonitor

- Thresholds

- Fuzzy Logic

AutomaticDecision

Reasoning

- Data Fusion

- Classifier

- Response Generator

Physical Models

Human -ComputerInterface.

.

.

HealthAssessment

- Component Specific Feature Extraction

- Anomaly & Diagnostic Reasoners

Prognostics

- Feature-Based Prognostics

- Model-Based Prognostics

Mission Plans

Typical CBM System Design:

ARLPenn State

Slide 5

i

CBM Systems

DataAcquisition


Array

ComplexSystem

ComplexSystem

S1

S2

SN

DataManipulation

- Pre-processing


- Signal Charact.

ConditionMonitor

- Thresholds

- Fuzzy Logic

AutomaticDecision

Reasoning

- Data Fusion

- Classifier


Physical Models


.

.

HealthAssessment



Prognostics



Mission Plans

• Complex design• Propriety algorithms• Large amounts of data• Inflexible designs

General Concerns:

ARLPenn State

Slide 6

i

CBM Systems

DataAcquisition


Array

ComplexSystem

ComplexSystem

S1

S2

SN

DataManipulation

- Pre-processing


- Signal Charact.

ConditionMonitor

- Thresholds

- Fuzzy Logic

AutomaticDecision

Reasoning

- Data Fusion

- Classifier


Physical Models


.

.

HealthAssessment



Prognostics



Mission Plans

Resulting in“Black Box” and “Stove Pipe” Solutions:

ARLPenn State

Slide 7

OSA-CBM Development Team

ARLPenn 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, …

ARLPenn State

Slide 9

OSA-CBM Focus

• 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

Open System Architecture for Condition Based Maintenance

• Software Architecture Description– Define classical CBM functions and behavior– Define module interfaces– Developed multiple middleware implementations

ARLPenn State

Slide 10

Why OSA-CBM?

System Developer/Engineer:

Project Manager:

OEM / Company:

Customer:

• 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

ARLPenn State

Slide 11

OSA-CBM Architecture

ARLPenn 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

ARLPenn State

Slide 14

Components of the OSA-CBM Framework

ARLPenn State

Slide 15

Generic Component Description

Component

EP 1 EP 2

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

Component

EP 1 EP 2

Component

EP 1 EP 2

Component

EP 1 EP 2

ARLPenn State

Slide 16

Generic Component Description

Component

EP 1 EP 2

Interfaces- ReqXXData

• GetXXData- GetXXExplanation- GetXXConfig

Interface Descriptions

Request Data: prompts a measurement or calculation update

Get Data: returns dynamic measurementdata 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

ARLPenn State

Slide 17

OSA-CBM Implementation

Data Acquisition ModuleData Manipulation ModuleCondition Monitor Module

DAConfiguration

INI File

DMConfiguration

INI File

CMConfiguration

INI File

(1) RequestData (2) RequestData

(5) Notify (3) Notify

(6) Access (4) Access

OSA-CBM data model supports:Synchronous, Asynchronous, Service, and Subscription transfers

ARLPenn State

Slide 18

OSA-CBM Models

ARLPenn State

Slide 19

OSA-CBM UML Models

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.

«singleton»Module

+entryPtType : StringEntryPoint

1+entryPoints1..*

+outPort1

-dataEvent

0..1

+confid : DoubleDataEvent

+lastUpdate : OSACBMTime-dataType : String

OutPort

+time : OSACBMTimeDataEventSet

1..*-synchEvts0..1

1..*

+dataEvent1..*

OutPortSet+outPort

1..* 1

1

+outPortSet

1

Explanation

EventData

1

+eventData

1..*

+id : MIMKey2+userTag : String

Item

-child

0..*

-parent0..*

-segmGroup : BooleanSegment

-type

0..1

0..*

-type

0..1

0..*

SegmentTypeAssetType

+id : MIMKey3util::MIMExtType

+id : RemoteKey-name : String-version : String

Algorithm

+id : RemoteKeyAlgPort

InPort

1

-inPort

0..*+algorithm1

+outPort1..*

-outPort

0..*

-portType0..1

PortTypeProcStrType 0..*1

-dataEvent0..*

-topItem

0..*

-serialNo : StringAsset

+userTag : String-name : String

Function -func

0..*

-by

0..1

-parent 0..1

-child

0..*

+source

1..*0..* +EP1

-expl0..1

-expl

0..*

+inputEP

1..*

+expl1

-eventSet

0..1

MeasLocType

da

utildata

dm cm ha pa

measEv propEv

Top Level UML Model

Organized in general, utility, and layer packages

ARLPenn State

Slide 20

OSA-CBM UML Models

UML Modulestop – Top Module, Common Classes

da – Data Acquisition Moduledm – Data Manipulation Modulesd – State Detection Moduleha – Health Assessment Modulepa – Prognostics Assessment Moduleag – Advisory Generation Module

measEv – Measurement Event ModulepropEv – Proposed Event Moduledata – Data Moduleutil – Utility Module

ARLPenn State

Slide 21

AIDL

Abstract Interface Document Language

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;

};

Tags:• Interface

[data][config][expl][org]

• Class Type[abstract]

• Multiplicity[sequence][optional]

UML syntax

AIDL Equivalent

1 no optional tag, no sequence

0..1 optional tag, no sequence

1..* no optional tag, sequence

0..* optional tag, sequence

UMLManual

Conversion

ARLPenn State

Slide 22

AIDL

UML


};





};

AIDL


};





};


};





};


};





};


};





};

COM/DCOMCOM/DCOM


};





};


};





};


};





};


};





};

CORBACORBA


};





};


};





};


};





};


};





};

XSD usingXSD usingWeb ServicesWeb Services

Middleware TechnologiesMiddleware Technologies

AIDL provides the mechanism for porting

to any Middleware Technologies

ARLPenn State

Slide 23

Middleware Technologies

ARLPenn State

Slide 24

Middleware Technology

Applications

Endsystem

Applications

Endsystem

Common Services Common Services

Distribution Middleware Distribution Middleware

Infrastructure Middleware Infrastructure Middleware

Domain-Specific Services Domain-Specific Services

Wired/Wireless Networks

DataAcquisition

PrognosticAssessment

Data Manipulation

ConditionMonitor

Health Assessment

Benefits

•Hide underlying complexity,•Share common services,•Synchronize program execution,•Balance system load,•Real-time solutions,•Cross-language, and •Cross-platform support

Benefits

•Hide underlying complexity,•Share common services,•Synchronize program execution,•Balance system load,•Real-time solutions,•Cross-language, and •Cross-platform support

} }

Operating System Operating System

Middleware Middleware

Distributed Computing ‘Glue’Software layer between application and communication networking layer

Decision Support

COM/DCOM, CORBA, SOAP, JAVA-RMI,…

ARLPenn State

Slide 25


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

ARLPenn State

Slide 26


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.

ARLPenn State

Slide 27

COM/DCOM

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

Sink and Data Pointers:• Allows asynchronous communication between modules• Contains relevant information about the data: Time, Eng. Units, Confid., asset and organizational info…

Benefits of COM/DCOM• Increased Security• Remote Module Instantiation• Standardized Information

Exchange• Client Control (lifetime, termination, Reference,...)• Internal Pinging Mechanism

ARLPenn State

Slide 28

COM/DCOM

COM/DCOM Modules Developed:

• HA• PA• PL

Gearbox Prognostic Application

• DA• DM• CM

ARLPenn State

Slide 29


XML over HTTP– XML (eXtensible Markup Language) is not a

middleware technology, it is simply a user- definable 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

ARLPenn State

Slide 30

XML over SOAP

SOAP Interfaces:• requestData(request)• forceNewData(request)• getAvailableData(request)

Benefits of using SOAP• Platform Independence

• Language Independence

• Reduced Network Restrictions(uses port 80)

• Standardized InformationExchange

ARLPenn State

Slide 31

OSA-CBM Design Flexibility

ARLPenn State

Slide 32

OSA-CBM Design Examples

ARLPenn State

Slide 33

MIB Software

Maintenance Information Backbone (MIB) Example

MIB Demonstration System

Engine Monitoring Hardware

ARLPenn State

Slide 34

OSA-CBM Design Examples

ARLPenn State

Slide 35

MIMOSA (OSA-CBM) Website

ARLPenn State

Slide 36

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

WWW.OSACBM.ORGWWW.MIMOSA.ORG

ARLPenn State

Slide 37

Acknowledgements

• This work was supported by: – 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…

ARLPenn State

Slide 38

OSAOSA--CBM: An Open CBM: An Open System Architecture for System Architecture for Machinery MonitoringMachinery Monitoring

Contact at ARL

Structural Health Monitoring COE Inaugural Meeting– April 13th 2007 -

Mitchell Lebold814.865.8958 (voice)814.863.0673 (Fax)[email protected]://www.arl.psu.edu

ARLPenn State

Slide 39

Backup Slides

ARLPenn State

Slide 40

MIMOSA and OSA-CBM

• 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

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

DAEventData

+xAxisDelta : Double#value : Double-xAxisStart : Double

WaveForm

-daAmpl

0..*

-amplEU

0..1util::EngUnit

top::EventData

-daXAxis

0..*

-xAxisEU

0..1

BLOB+contentType : Mime#data : byte

data::BLOB

1

+data

1

MEventBlobType

+id : MIMKey3util::MIMExtType

0..*

-MEvBlobType

0..1