Rotorcraft Health Management System (RHMS)

Transcription

1 AIAC-11 Eleventh Australian International Aerospace Congress Rotorcraft Health Management System (RHMS) Robab Safa-Bakhsh 1, Dmitry Cherkassky 2 1 The Boeing Company, Phantom Works Philadelphia Center for Math and Computing, robab.safa-bakhsh@boeing.com 2 Dovetail Concepts, Inc., dc@dovetailconcepts.com Summary: This paper describes Rotorcraft Health Management System (RHMS), which is a set of ground - based tools for acquisition, management and interchange of data collected by on-board health and usage monitoring systems (HUMS). Development of sophisticated health monitoring algorithms requires specialized technical knowledge specific to particular components. In addition, development, testing and maturation of algorithms usually involve large volumes of health and operational data from test beds, flight tests and operations. Such factors lead to complex health monitoring systems developed and operated by diverse organizations. The RHMS facilitates and reduces costs of research, development and maturation of health monitoring algorithms; deployment, administration and maintenance of health monitoring software; engineering analysis by manufacturers of airspace vehicles and subsystems; and integration of health monitoring into operational and maintenance procedures by aircraft operators. Keywords: health management, rotorcraft health and usage monitoring system, autonomous logistics, automated maintenance, decision support system Introduction In recent years there has been a push toward sophisticated health and usage monitoring algorithms capable of producing accurate diagnostic and prognostic assessments for a variety of aircraft components and subsystems. This push is largely driven by the promise of greater reliability, increased mission readiness and decreased sustainability costs. Design, implementation and operation of such algorithms require collection and analysis of large volumes of data from diverse sources. Consequently, on-board systems and test beds are collecting larger volumes of more complex data for a greater variety of components. At the same time, as algorithms that rely on this data are becoming more sophisticated, they are produced by diverse suppliers who are specialized experts. This diversity of data producers and consumers makes common infrastructure for acquiring, processing and managing the health and usage data indispensable. The RHMS addresses the data management and utilization complexities by providing a common infrastructure for describing, storing and processing HUMS data. It contains a set of modules that abstract data management tasks to support generic data handling, but at the same time provide the capability to describe data items and algorithm input/output in detail sufficient to support human and machine understanding of HUMS processes and results. Data acquisition tools of the RHMS include the binary data format definition schema for specifying layout of binary data files, data mapping definition support for specifying properties of data sources and mapping data to a standard internal representation, and a generic data parser for converting data from diverse sources to the internal representation. Eleventh Australian International Aerospace Congress Sunday 13 Thursday 17 March 2005 Melbourne, Victoria, Australia Fourth DTSO International Conference on Health and Usage Monitoring

2 Data management tools include support for storing, retrieving and managing health data. Data interchange and data processing support tools include data presentation specification for defining data input and output of health monitoring modules, interface specification for data providers and consumers, and support for workflow definition for health monitoring processes. Architecture The RHMS is a web-based system supporting web browser clients and web service interfaces. Fig. 1 depicts a high-level functional representation of the system. Fig. 1: Architecture Diagram At the heart of the system is a database with a generic schema capable of storing simple and structured data items, algorithm input and output bindings, and time-varying configuration information. All database access is abstracted by the Data Access Layer, which supports both data input and output. Data is collected through the Data Collection Layer, which includes a generic binary data parser capable of processing any binary file described using the system s binary format definition language. Once the data is collected, besides being stored in the database, it is propagated through the aircraft type specific workflow. The workflow is defined using the workflow definition language and includes data input, data validation, module interface, and data output. Workflow tasks can be conditionally executed based on collected data and data processing module output. RHMS supports internal and external modules. Furthermore, it provides access to its data and modules by external systems through web service interfaces. Data Acquisition Fig. 2 depicts a typical flow of the binary data acquisition process within RHMS.

3 Fig. 2: Binary Data Acquisition Process HUMS data acquired from diverse sources, such as onboard and external systems come in a variety of formats. The collected data is usually in binary formats. Often these formats undergo changes as systems mature. XML Schema for Binary Format Definition RHMS addresses the problem of managing data formats by utilizing a binary format definition language. This language follows an XML schema and uses declarative semantics to describe a related group (e.g. a set of formats for different revisions of the same aircraft type) of binary formats. Declarative semantics simplify format definition and facilitate implementation of automated tools for format management. Coupled with the ability to describe multiple variations of the same format, they greatly simplify format management and reduce design, development, validation and sustainment costs. Fig. 3: Binary Format Example Format definition represents binary data as a set of files. Each file is divided into sections, which are divided into records. Records consist of simple data fields (integers, strings and floating-point numbers) and complex data fields (structures and arrays). Common properties of all format elements include byte ordering and character encoding. In addition, each type of format element has its own corresponding properties. For example, array elements have the length property, which may be an integer value or a reference to an integer field within the definition. See Fig. 3 for a conceptual representation of array definition. Similarly, section locations (byte offsets) within files can be specified by an integer or by a reference to an integer field. The latter approach supports tables of contents. The language supports conditional definitions based on field values. One example of the use of this feature is definition of a format in which records are determined by the value of a record header. For example, see the record identifier field in Fig. 3.

4 Fig. 4: Data Acquisition Example RHMS includes a generic data parser, which is capable of processing any binary data format given its definition. Therefore, adding a new version of an existing format or integrating a new format into the system only requires generation of an XML definition file and possible addition of configuration information. When binary files stored in this format are processed, the parser utilizes the format definition to read and validate the data. After the data is validated, it is stored in the database and processed by the Workflow Manager. A sequence diagram representing a simple data acquisition example is depicted in Fig. 4. Work Flow Manager The workflow manager utilizes XML workflow definition files, which define actions to be taken based on the source and contents of the data. Workflow actions may include event and alert generation, requests for additional data input and data validation, data file generation, and module execution. Workflow Manager facilitates data processing and integration of HUMS modules.

5 Fig. 5: Workflow Example A sequence diagram representing a simple workflow execution example is depicted in Fig. 5. The Workflow Manager uses the Module Interface Layer to execute a HUMS module to process acquired data. Then, the Workflow Manager uses the Data Presentation Layer to generate a file containing HUMS data and send this file to an external system. Data Management RHMS supports universal data management by storing acquired data in common data tables and utilizing definitions of data representation and data semantics to standardize handling of data items across multiple platforms. Database Table 1 lists different parts of the RHMS database. Each part contains multiple tables supporting its functionality. Besides storing acquired data, the database schema supports storing information describing manufacturers, deployment sites, external data references, software agents, human agents, software modules, algorithms, assets, source and properties of acquired and computed data, time-varying configuration data, system and asset events, access rights, action logs, and maps to data stored on external systems. The database enables efficient data queries supporting a variety of data views (see the User Interface section for details) and cross-fleet queries supporting engineering analysis.

6 Part Organizations External References Agents Software Assets Assets HUMS Data Configuration Data Events Security Logs External Maps Table 1: HUMS Database Parts Description Manufacturers and deployment sites References to externally stored data (e.g. binary files) Human and software agents Software products, modules and algorithms Monitored assets (e.g. test beds, aircraft and components) HUMS data, data definition and data sources Time-varying HUMS configuration data for software and hardware assets Events associated with assets and RHMS systems Users, roles and access rights Action logs Maps of data to external systems The acquired data is grouped by acquisition events (synchronized acquisitions of one or more data items) and is stored in a set of tables based on data type. Data item definition information is used for data interpretation (units, resolution, measured quantity, etc.) and grouping of simple data items into arrays and structures. Each data item is stored with data source information. Data sources include sensors, algorithms and human input. Every data item can be traced to the source that produced it, input data items (if any) used in its generation and configuration of the source. This approach ensures trace ability and reproducibility of data. Data Integrity RHMS supports error correction and detection codes on file, section and record level. Every data item has an associated validity code. In addition, the Security Manager of RHMS provides user-based and role-based security to prevent unauthorized access and minimize unintentional changes to the data. Data access rights may be defined in terms of properties associated with data items and their sources. These properties may be traced through foreign-key relationships defined in the database schema. This approach enables definition of complex data access rules, such as a particular user having access to all engine-related data generated by systems monitoring engines manufactured by a particular company. Data Processing RHMS exposes HUMS data to internal and external data processing modules. HUMS modules may be executed as part of the initial automated data workflow processing or as part of a separate data processing action, which is scheduled by the system or initiated by a user. Modules are accessed by RHMS through the Module Interface Layer. Currently the module interface layer supports legacy standalone executables and web service modules. The modular architecture of RHMS enables different communication protocols to be added as needed. Stand Alone Module Interface HUMS standalone executables are legacy applications that rely on the file system for input and output. In order to facilitate integration of such modules, the Workflow Manager

7 supports generation of their input and control files, as well as processing of and utilization of data from their output files. This process is shown in Fig. 6. Service Module Interface Fig. 6: Standalone Module Execution RHMS defines web service interfaces for HUMS data access. It implements web services that can be utilized to access HUMS data and consumes web services implemented by HUMS algorithm suppliers (see Fig. 7). Fig. 7: Web Service Module Execution Data Interchange RHMS is designed to facilitate integration with a variety of HUMS modules, external systems and clients. It supports interchange of data through several protocols and enables straightforward integration of additional communication protocols. Data Access Layer The Data Access Layer abstracts all access to RHMS data. It includes support for storing, finding and obtaining acquired and computed data. In addition, it contains the Configuration Manager, which is responsible for providing RHMS configuration information. This information includes configuration for HUMS modules, security and platform-specific definitions. RHMS stores historical configuration information in order to support full traceability.

8 Data Presentation Layer - Interface with External Systems RHMS exposes HUMS data through its Data Presentation Layer (see Fig. 8). The modular nature of the Data Presentation Layer facilitates integration of different communication protocols. Currently SOAP and HTML over HTTP, as well as XML and binary files are supported. Legacy systems that are not capable of obtaining HUMS data through RHMS web service interfaces are able to receive the data as binary and XML files. The binary format definition language defines binary formats required by external systems. XML files required by external systems can be generated using XSL transformations. Typical systems that utilize HUMS data include logistics systems, maintenance management systems, OEM data collection systems and data warehouses. Fig. 8: External Systems Interface User Interface RHMS supports web-based access to HUMS data. Its user interface consists of three areas: commands, view selection and data view. Commands include configuration, file upload, flight debrief and database management. View selection interface enables selection of aircraft and flights. Data view types include logbook, subsystem, flight data, data collection, work order and engineering analysis. In the data collection view, HUMS data is organized the same way as in the acquired files. In the subsystem view, HUMS data is organized by aircraft subsystem. Logbook view focuses on exceedances, usage, alerts and flight related information, as well as aircrew input of observables and verification of flight time and usage. In the work order view, items possibly requiring repair or maintenance are displayed including fault codes from aircraft technical data repository. In addition, the work order view supports initiation of work orders via an interface to a maintenance management system. Engineering analysis view supports data visualization and data mining, including cross-fleet queries. Since there are differences in data presentation and terminology among different platforms, RHMS supports definition of data view using XML. These definitions serve as templates for view layouts specifying what data to display and how to display it. Current Status The current version of RHMS includes the implementation of the HUMS database, as well as initial versions of the Data Collection Layer, the Data Access Layer, the Data Presentation Layer and the Workflow Manager. Fig. 9 depicts a data view screen showing

9 sample data for a V-22 flight. The user interface supports selection of different fleets, browsing through aircraft and flights, and selection of different data views. Fig. 10 shows the file upload screen. The user selects aircraft model and the file to upload. The system uses the aircraft model to determine the binary format definition and extracts the flight timestamp and aircraft tail number from the data file if available. Fig. 9: Data View Screen Fig. 10: File Upload Screen

10 Future Work Future work for RHMS includes maturation of all layers and user interface, as well as addition of support for real-time data collection, integration and demonstration of other platforms, addition of new protocols for HUMS module interface, integration of HUMS modules, and implementation of the Security Manager. In addition, future work includes development of an automated tool for integration of new platforms. This tool will include a graphical editor for defining platform-specific binary formats, workflow, data views, terminology, and HUMS module configuration. The tool will automatically generate all necessary configuration files and database reference data to support the new platform. Conclusion RHMS is a HUMS data management system that utilizes declarative semantics for binary format definition, workflow definition, data properties description and data presentation definition. This approach enables acquisition of data from diverse sources and exchange of data with diverse consumers without placing special requirements on external systems and without integration-related code development. All definition files are in XML format and are well suited to be generated by software tools. These features reduce costs of development, deployment, maturation and sustainment of HUMS systems. In addition, RHMS facilitates validation, certification and qualification of new HUMS modules and HUMS systems for additional platforms. References 1. World Wide Web Consortium. Extensible Markup Language (XML) World Wide Web Consortium. Simple Object Access Protocol (SOAP) World Wide Web Consortium. XSL Transformations (XSLT) Version