For health monitoring, the fundamental data sources are the vibration recordings. From the recording from each component, a set of condition indicators are derived. These are parameterizations of the raw vibration signals, and are closely correlated with the state of the underlying assets. The indicators are aggregated by a classi.cation system able to detect the presence of mechanical degradation. A set of event markers are produced by the classi.cation system. This set of markers represents observations of assumed mechanical degradation, and compliments the set of markers representing anticipated faults generated by the usage monitoring.

This makes a total of .ve datatypes for the HUMS. Two fundamental once; .ight data parameters and vibration recordings, and three derived once; indicators, event markers and event marker .elds (Fig. 4.2).
The event marker .elds are the contextual information companying each event marker. The work distribution between the airborne segment and the ground station is proprietary to each HUMS solution. Regardless, all .ve datatypes will eventually end up in the data storage of the ground station.
4.3. ARCHITECTURAL LAYERS

4.3 Architectural Layers
Although the data from every HUMS can be generalized into a set of standard datatypes, the storage format in proprietary to each HUMS. Most HUMS so-lutions on the market today use either a proprietary directory / .le structure or
a
third
party
SQL
database
(Sec.
B.1).
Even
though
SQL
databases
have
standard interfaces, the table structure is still proprietary to each HUMS version.
This barrier has been overcome by developing a data storage driver for each supported HUMS version. A storage driver is an implementation of standardized Application Program Interface (API). The functions de.ned in the API provide the necessary tools to connect to a data storage, enumerate the elements of each datatype, and extract the underlying data. Although the inner workings of each driver is very di.erent, the outside interfaces are identical
(Sec.
B.2.1).

The common interface layer exposes this standardized interface to any third
party
application
through
ActiveX
(Sec.
B.2.3)
and
.net
(Sec.
B.2.4).
This layer accepts connection requests from any third party application, loads the driver corresponding to the HUMS version provided in the connection request, and connects to the speci.ed target data source. Once a connection is open, the third party application can interrogate data objects within any supported HUMS data storage without any knowledge about its underlying structure
(Fig.
4.3).
The
choice
of
Microsoft-based
component
models,
over
more
open
solutions
like
Java
　
中國航空網(wǎng) www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：OPTIMIZATION OF FAULT DIAGNOSIS IN HELICOPTER HEALTH AND USA(35)