Keywords

1 Introduction

At present, the complexity, comprehensiveness and intelligence of airborne equipment are getting higher and higher. The traditional maintenance methods of regular maintenance and post maintenance are difficult to meet the needs of complex equipment maintenance, and the demand for Condition Based Maintenance (CBM) is becoming more and more urgent [1]. The basis of CBM is data, which can assess the current or future health status and provide maintenance decisions by capturing data and monitoring parameters related to the health of airborne equipment. In this process, multiple sensors, processing units and software are required to perform data processing functions, and it is expected that these components will be provided by different suppliers. In order to realize easy integration and interaction between components and realize technology reuse, it is necessary to establish an open CBM system architecture.

Through the use of standardized interfaces and data models to achieve interoperability between CBM components of multiple suppliers, American research institutions have proposed an open standard for CBM application development and integration, and further developed it into an Open System Architecture for Condition Based Maintenance (OSA-CBM) standard. OSA-CBM mainly focuses on PHM functions and related data models. Most OSA-CBM projects mainly come from Boeing, general aviation, ARL and Pennsylvania State University. Literature [2] discussed the benefits of OSA-CBM and reported its use in Boeing research projects. However, due to the proprietary nature of these works, it failed to provide information on how to implement OSA-CBM in engineering. Sreenuch [3, 4] et al. designed the software structure of OSA-CBM module and demonstrated its application through a distributed gearbox CM system. In addition, under the background of IVHM architecture, the distributed data mechanism is designed and analyzed for the communication between OSA-CBM modules. Bayoumi [5] et al. proposed a new scalable CBM architecture for naval fleet maintenance, including data distribution service (DDS) and OSA-CBM, which effectively solved the isolation between shipborne data and shore based analysis tools.

An important component of OSA-CBM is the standardization of data model. In this paper, the data is standardized based on OSA-CBM standard in the embedded environment to ensure that each CBM component uses the same set of data for data processing and data transmission, and each component can correctly identify this standardized data. In addition to the consideration of standardization, the data model also needs to be recognizable and traceable, and needs to be consistent with the data in the reliability and maintenance domain.

2 Data Model Based on OSA-CBM

Open system architecture for condition based maintenance (OSA-CBM) is an open standard, which aims to enhance the interoperability between software components of multiple suppliers and the integration of enterprise information systems. OSA-CBM is divided into data model and interface specification. These specifications are defined using unified modeling language (UML) and are designed to be platform independent and can be mapped to various programming languages and middleware technologies [6].

2.1 A Subsection Sample Data Model

OSA-CBM data model mainly describes the concept and use of metadata (data about data), that is, OSA-CBM data is always identifiable and traceable. In embedded systems, OSA-CBM mainly has two data types, DataEvent and Configuration.

DataEvent are dynamic data related to health management generated by the equipment module, such as sensor measurement data, state information or data processed by algorithms. Configuration provides information about the input source of the device module, an algorithm description for processing the input data, an output list, and various output details.

2.2 Interface Specification

The interface specification serves the data model and mainly describes how information is transmitted between functional blocks. There are four main types of interfaces to adapt to different purposes and technical capabilities: synchronous, asynchronous, service and subscription (see Fig. 1).

Fig. 1.
figure 1

Schematic diagram of four interface specifications

Full size image

Figure (a) is a synchronization interface, showing the data returned during the call; Figure (b) is an asynchronous interface that allows any number of higher modules to establish and maintain bidirectional connections when needed; Figure (c) is a service interface, which is used for one-way data input device and can be used for data storage service in the embedded system; Figure (d) is the subscription interface, which is similar to the alarm return or push all communication modes in the asynchronous interface. The upper module subscribes to the data, and the lower module sends the data regularly or in alarm.

3 Standard Method for Embedded Device Data

3.1 Dynamic Data Standardization

The DataEvent class constitutes an important part of the OSA-CBM data model. The DataEvent sub hierarchy is related to the specific abstract state monitoring data processing functions defined in ISO 13374 standard [7] (machine state monitoring and diagnosis - data processing, communication and representation). Under these classes, there are subclasses that describe specific data types. Function definitions can be regarded as knowledge that abstracts data to a higher and higher level of information abstraction. Data Acquisition (DA) data type is the collected sensor data, and its format is consistent. The DA data is then converted into one or more meaningful features in a Data Manipulation (DM) type data format. Compare these functions with the expected values, and the resulting enumeration condition indicators are stored in the State Detection (SD) DataEvent class. The data in Health Assessment (HA), Prognostic Assessment (PA) and Advisory Generation (AG) formats are related to the current health status of the machine, the predicted future faults and the recommended operation steps, respectively. The DataEvent class designed for the embedded system (see Fig. 2).

Fig. 2.
figure 2

Schematic diagram of DataEvent composition architecture

Full size image

The dynamic data DataEvent base class supports unique data identification (ID) and entity object identification (site) to distinguish data from different physical locations; Support data trustworthiness (confid), data sequence number (sequenceNum) and alarm status (alertstatus) to describe data dynamic information; The date/time (time) of referencing a specific time instance is supported.

3.2 Static Data Standardization

An important component of Configuration is Port, which is static data related to PHM events generated by embedded applications. It is associated with DataEvent through its attribute ID and site (see Fig. 3).

Fig. 3.
figure 3

Schematic diagram of Configuration composition architecture

Full size image

Port is associated with sensor location information (measloc), equipment asset information (asset), and algorithm description information (algorithm) through foreign keys. In the initialization stage of the embedded device, the Port and its associated information are designed as static data in the form of XML tables.

4 Data Standardization Verification and Test Analysis of Typical Embedded Devices

In this paper, an embedded device is selected as a typical application case to standardize the data of the device, and carry out data processing and threshold detection. Use the equipment to complete the DA block function, and select two zynq7000 development boards to complete the DM block and SD block functions respectively. Firstly, the data related to equipment health is collected through the DA block. Secondly, the data is preprocessed and sent to the DM block through the bus. The PHM algorithm application is called in the DM block for data processing. Finally, the processed data is sent to the SD block to realize the threshold detection and alarm functions.

The data collected by the DA block includes the low-pressure rotor speed (N), the outlet temperature of the high-pressure compressor (Temp), the static pressure after the fan stator (Ps) and the vibration signal of the turbine rear casing (Vib). The data collection period is 20 ms. Detailed data information is shown in Table 1.

Table 1. DA block generates data information.
Full size table

It is converted into digital signal at the DA block and generates DADataEvent. It calls the interface API conforming to the OSA-CBM interface specification and sends the data packet to the SD block through the RS422 bus. The execution cycle is 20 ms and the baud rate is 230400 bps. On the other hand, static data corresponding to DataEvent is generated, which exists in the form of XML file and is called when the program is initialized. The configuration information is shown in Table 2.

Table 2. DA block generates data configuration information.
Full size table

The DM block receives the data sent by the DA block. In order to verify the data standardization function, the PHM application algorithm is designed to process DataEvent, the mean filter algorithm is used to process N, Temp and Ps data, and the Fast Fourier Transform (FFT) is used to process Vib data. Convert the result processed by the algorithm into DMDataEvent, call the interface API conforming to the OSA-CBM interface specification, and send the data packet to the SD block through the extranet bus. The algorithm processing cycle is 40 ms.

In the SD block, the threshold detection algorithm is used to process data. If the threshold setting range is exceeded, an alarm will be triggered, and the alertstatus in the corresponding DataEvent will be set to 1. The ID of DataEvent can be traced to the configuration information, and the configuration information corresponding to the alarm information can be viewed.

In addition, in terms of performance overhead, compare the time required for “non-standardized” and “standardized” data processing tasks. The nonstandard data processing task is to collect data at the DA block, convert it into digital semaphore and send it directly to the DM block. After the DM block calls the PHM algorithm to process the data, the processing result is sent to the SD block, and the threshold detection is performed on the data at the SD block. By counting the running time of programs in DA block, DM block and SD block, (see Fig. 4). It can be found that the nonstandard data processing overhead is 7.541 ms, 15.239 ms and 5.632 ms respectively, while the standardized data processing overhead is 7.623 ms, 15.347 ms and 6.106 ms. The standardized data processing only takes 2.28% of the total overhead to obtain the maximum reusability and configurability. In this case, the performance overhead increased by data standardization is very low.

Fig. 4.
figure 4

Schematic diagram of performance overhead comparison

Full size image

5 Data Model Based on OSA-CBM

In order to meet the data interoperability between airborne equipment of different suppliers and the traceability and identifiability of cross embedded equipment, this paper studies the implementation of embedded data standardization based on OSA-CBM. A hierarchical data model conforming to 13374 standard and OSA-CBM standard is designed to realize the interoperability and identifiability of the data model with dynamic data DataEvent and support the traceability of the data model with static data configuration. And through an example, the functions of data acquisition, data processing and state detection in the embedded system are verified, as well as the higher ability to improve data standardization in the case of very small performance overhead. However, this paper only studies the functions of DA, DM and SD layers in the embedded system in the airborne environment, and will carry out further research on ha, PA and Ag layers on the ground.