Integrated system for improved vehicle maintenance and safety

Abstract

A system and method involve analyzing data indicative of system performance of a vehicle transportation system. More specifically, the present invention relates to the integration of an aircraft management, monitoring and maintenance system (such as health amp; a monitoring / management system (HUMS), an airborne maintenance system (OMS) and a cockpit voice amp are used; flight data recorders (CVFDRs, and / or fast access recorders (QARs) previously distributed over multiple systems) are integrated into a single circuit card assembly (CCA). A single circuit card may include electronics required for data acquisition, processing, storage, and transmission to support all of the above systems and the like. The systems and methods of the present invention further involve running software to perform aircraft management, monitoring, and maintenance functions on a single common CCA.

Description

[0001] This application is a divisional application of the patent application with the application number 202011073386.0 and the invention title "Integrated System for Improved Vehicle Maintenance and Safety" filed on October 9, 2020. I. Technical Field

[0002] The present invention relates to evaluating the system performance of a vehicle transportation system. More specifically, the present invention relates to integrating aircraft management, monitoring, and maintenance systems that were previously distributed across multiple systems into a single circuit card assembly (CCA). The present invention further relates to running the software to perform aircraft management, monitoring, and maintenance functions on a single common CCA. II. Background Art

[0003] Modern transportation vehicles (hereinafter referred to as "vehicles") include helicopters, airplanes, automobiles, trucks, ships, and trains. Vehicles typically include electronic sensors for monitoring both vehicle performance and the environment. The sensors can record data indicating information such as: factors affecting the vehicle or the environment around the vehicle; the internal operation of the parts of the vehicle; or data affected by both the external environment and the internal operation. Common sensors can monitor the movement, vibration, speed, temperature, torque, liquid or gas pressure, liquid or gas volume, concentration of gas or liquid, electrical performance and parameters, etc. of the vehicle and / or vehicle components.

[0004] The data obtained via sensors of specific parameters can be used for various purposes. For example, sensors can monitor the performance of vehicle components in real time to ensure that the components operate within safe or appropriate parameters (such as for heat, pressure, electrical performance, and the like). In the case where a change in the expected performance range is detected by the sensors, a hardware processor with appropriate code can be used to adjust the operation of the vehicle to correct the problem. In the simplest case, monitoring (with an appropriate display) can simply alert the vehicle operator of a change in the vehicle's condition, such as a change in vehicle speed or fuel level, while leaving an appropriate response to the vehicle operator's judgment.

[0005] Another use of the collected sensor data is for post - mortem analysis of vehicle performance. Post - mortem analysis can be used to assist in the development of vehicle prototypes during the vehicle design process. In other cases, such data may provide early warning alerts for potential or outstanding problems with the vehicle after being analyzed over a period of time.

[0006] Another application of sensor data is when a vehicle encounters an unexpected problem or environment, or when the vehicle exhibits unexpected behavior or performance. The sensor data can then be used for post - event analysis and evaluation of vehicle performance. Such post - problem analysis is typically performed by researchers and / or computers some time after the event, and helps to determine the nature of the unexpected stresses to which the vehicle was subjected; the vehicle's unexpected responses to various environmental factors / stresses; or both.

[0007] A well - known application of vehicle sensor data in aircraft is in the flight recorder (the so - called "black box", which is actually usually painted orange to aid in its recovery after an accident). A flight recorder is a data - processing and storage device that collects and can partially process data from many sensors on the aircraft. Flight recorders are typically designed with a rugged mechanical structure and have a high survival capability even under catastrophic aircraft crashes or other severe events.

[0008] More generally, a vehicle's sensing / monitoring system (VSMS) is formed by two or more unique maintenance and / or safety systems that have been installed on many vehicles (including in particular but not limited to aircraft, such as airplanes and helicopters). These maintenance and / or safety systems typically require the use of multiple data acquisition and processing units (DAPU), each of which collects and processes data from various sensors. Exemplary DAPU can include, for example but not limited to:

[0009] (1) Crash - survivable cockpit voice & flight data recorder (CVFDR)

[0010] (2) On - board maintenance system (OMS)

[0011] (3) Quick access recorder (QAR)

[0012] (4) Health & usage monitoring / management system (HUMS).

[0013] These will be discussed further below.

[0014] For example, health and usage monitoring systems (HUMS) are installed on machines mainly to give early warnings of impending failures. In the helicopter applications of HUMS, these systems use dedicated sensors (such as accelerometers) added to the aircraft and from the existing infrastructure / avionics on the aircraft (such as the ARINC 429 digital data bus) for data acquisition, processing, storage, and transmission. Typical HUMS functions include: vibration health monitoring (VHM) for the helicopter HUMS part, parameter limit over - run detection, flight state identification, and data recording and display.

[0015] As another example of a DAPU, a QAR is typically a device that receives data through digital interfaces (e.g., RS-422, ARINC 429, Ethernet) and records it in a removable media device (e.g., an SD card) in an industry-standard format (e.g., ARINC 717 or 767 for aviation).

[0016] As another example of a DAPU, an on-board maintenance system (OMS) is installed to assist in the maintenance of a vehicle, with the primary purpose of reducing the maintenance burden of maintaining an aircraft. In fixed-wing aircraft applications, the OMS typically interfaces with other member systems (aviation LRUs) via a digital data bus to record maintenance data, upload software and data, and perform fault tree reduction / failure root cause analysis based on fault information returned from the member systems. ARINC Standard 624 defines the typical functions of an OMS.

[0017] As another example of a DAPU, a CVFDR is installed in an aircraft (fixed-wing and rotary-wing) to record critical data in a crash-survivable medium to assist in crash investigations. The performance of a CVFDR can be defined by the Minimum Operational Performance Specification (MOPS) ED-112.

[0018] These exemplary DAPU systems and similar systems have many proven and documented benefits for vehicle safety and maintenance. However, to date, these systems are provided as multiple separate systems on a vehicle (e.g., four separate DAPU systems). In many cases, these separate systems require redundant hardware and processing. III. SUMMARY OF THE INVENTION

[0019] In view of the above deficiencies, there is a need for a system that combines these DAPU functions into an integrated sensing system (ISS), and in an embodiment, into a circuit card assembly (CCA) (except for the crash-protected memory (CPM) device for the CVFDR that is separate from but physically connected to the CCA). Such an ISS provides many benefits to vehicle operators and / or manufacturers.

[0020] Most DAPUs (HUMS, OMS, CVFDR, QAR, and possibly others) have certain functional elements that are the same or substantially similar. These can include, for example but not limited to, a power supply, a processor, an interface to aircraft sensors, an interface to aircraft control and display panels, and an interface to an off-craft communication network. Since each vehicle typically employs multiple DAPUs, each with its own hardware elements, some hardware elements may be unnecessarily duplicated. Some software processing functions may also be unnecessarily duplicated.

[0021] In some cases, embodiments of the present invention require combining elements that are typically repeated between separate circuit cards of separate DAPUs into a single element, such as a single circuit card. Similarly, software processes that are redundantly repeated in existing configurations can alternatively be integrated into a single process on a single circuit card, or fewer processes.

[0022] Additional features, modes of operation, advantages, and other aspects of various embodiments are described below with reference to the accompanying drawings. It should be noted that the present disclosure is not limited to the specific embodiments described herein. These embodiments are for illustrative purposes only. Based on the teachings provided, additional embodiments or variations of the disclosed embodiments will be apparent to those skilled in the relevant art. IV. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Advantageous designs of embodiments of the present invention are derived from the independent and dependent claims, the specification, and the drawings. Hereinafter, preferred examples of embodiments of the present invention are described in detail with the aid of the drawings. The drawings incorporated herein and constituting a part of the specification illustrate the present invention and, together with the description, further serve to explain the principles of the present invention and enable those skilled in the relevant art to implement and use the present invention.

[0024] Figure 1 An exemplary transportation system (“vehicle”) having an exemplary sensor is shown.

[0025] Figure 2 An exemplary internal system of a vehicle having an exemplary arrangement of sensors for monitoring an internal system is shown.

[0026] Figure 3 An exemplary air and ground architecture of an exemplary vehicle sensing / monitoring system (VSMS) is shown.

[0027] Figure 4 A block diagram of four separate data acquisition and processing units (DAPUs) implemented as four separate line replaceable units (LRUs) as part of a VSMS according to an exemplary legacy system and method is provided.

[0028] Figure 5 Typical vehicle health management functions supported by the DAPU are shown.

[0029] Figure 6 A block diagram of an exemplary integrated data acquisition and processing unit according to the present system and method is provided.

[0030] Figure 7 Several categories of system operations, application operations, software and hardware operations, and interfaces that can support or be associated with implementing vehicle health management functions in embodiments of the present system and method are shown.

[0031] Figure 8 Shows an exemplary partitioning of vehicle monitoring, analysis, reporting, and support functions that can be integrated according to the present system and method.

[0032] Figure 9 Provides a block diagram of four different exemplary circuit card assembly (CCA) hardware configurations for a unique master CCA to implement the integrated DAPU system and method disclosed herein. V. DETAILED DESCRIPTION

[0033] Although the present invention has been described herein by way of illustrative embodiments for a particular application, it should be understood that the invention is not limited thereto.

[0034] The following detailed description is merely exemplary in nature and is not intended to limit the systems and methods, elements or steps of the systems and methods, their applications, and their uses disclosed herein. Further, it is not intended to be bound by or limited to any theory presented in the foregoing background or overview or in the following detailed description. Those skilled in the art who have access to the teachings provided herein will recognize other variations, applications, and embodiments within its scope and other fields in which the present invention will have significant utility.

[0035] Throughout the application, the description of various embodiments may use the language "comprising," indicating that the systems and methods may include certain elements or steps described; however, the systems and methods may also include other elements or steps that are not described, or may be described in combination with other embodiments, or may be shown only in the drawings, or are other elements or steps necessary for the functions of the processing systems known in the art. However, those skilled in the art will understand that in some specific cases, the language "consisting essentially of" or "consisting of" may alternatively be used to describe the embodiments.

[0036] For a better understanding of the current teachings and in no way limiting the scope of the teachings, those skilled in the art will appreciate that, unless otherwise specifically stated, the use of the singular includes the plural. Thus, the terms "a," "an," and "at least one" are used interchangeably herein.

[0037] The headings used in this detailed description are only for helping to make this document easy to read and browse, and should not be construed as limiting or restrictive.

[0038] The systems and methods are not limited to the embodiments described below, which are merely exemplary. Rather, the full scope of the systems and methods is recited in the claims that follow. It will be further understood that the appended claims themselves are disclosures, and the full scope of the systems and methods may include only the elements recited in the claims.

[0039] VI. Vehicles and Sensors

[0040] Figure 1 An exemplary vehicle transportation system (“vehicle”) 100 is shown, in this example an exemplary helicopter 100. The use of the helicopter is for illustrative purposes only and should not be considered limiting. Many elements of a general transportation vehicle, and in particular many elements of a helicopter, are well known in the art and will not be described herein.

[0041] Vehicle 100 may include one sensor or typically multiple sensors 105 of different types. Sensors 105 may have electrical, mechanical, optical, and / or chemical elements and may sense various environmental or vehicle phenomena or energies. Sensors 105 operate in real time to provide a time series view of the magnitude or intensity of the phenomena they sense, and the real-time data is provided as an output of raw electrical signals with varying voltage and current or as digital / digitized sampled data. Multiple exemplary sensors 105 are shown within or along the exemplary vehicle 100 Figure 1 as, for example, sensors for altitude, vehicle speed, vehicle direction and orientation, temperature, pressure, position, vehicle acceleration, and others. Included within sensors 105 may be vibration sensors 110, also referred to as accelerometers 110. (Those skilled in the art will understand that, as used herein, the term “accelerometer” is used equivalently with “vibration sensor” as opposed to the type of acceleration detector that may be used to detect the total acceleration of the entire vehicle 100.)

[0042] Various internal sensors 105 may be employed to monitor the operation of specific internal components of vehicle 100. Figure 2 An exemplary complex internal mechanical element 200 of vehicle 100 is shown, in this case an exemplary helicopter drive chain 200 or gear system 200. The gear system 200 is within the helicopter 100 (and thus not shown in Figure 1 the view) and includes gears, drive shafts, and other elements that may be used to transfer power from a helicopter engine (not shown) to a helicopter rotor (not shown) and other elements within the helicopter (such as a generator). The gears are typically enclosed within a gearbox 210. The drive shafts may also have shaft housings 220. Vibration sensors 105 associated with the drive chain 200 are typically located inside the gearbox 210 and shaft housings 220 and thus cannot be directly seen in Figure 2 ; however, the vibration sensors 105 are thus positioned appropriately to detect vibrations at multiple points along the drive chain 200.

[0043] As will be understood by those skilled in the relevant art, various sensors 105 (e.g., along or within the engine, not shown in the figures) may be placed at multiple points between and along the numerous components of the vehicle 100.

[0044] VII. EXEMPLARY VEHICLE SENSING / MONITORING SYSTEMS IN ACCORDANCE WITH THE PRIOR ART

[0045] Figure 3 An exemplary airborne and ground architecture of an exemplary vehicle sensing / monitoring system (VSMS) 300 known in the art is shown, which system may be associated with a transport vehicle 100 such as the exemplary helicopter 100. The terms "vehicle monitoring system", "vehicle sensing system", "vehicle sensing / monitoring system (VSMS)", and "VSMS" may be used interchangeably and have the same meaning herein. VSMS 300 may include, for example but not limited to:

[0046] (1) A plurality of data acquisition and processing units (DAPU) 307, which may include, for example but not limited to: a crash survivable cockpit voice & flight data recorder (CVFDR) 307.1, an on-board maintenance system (OMS) 307.2, a quick access recorder (QAR) 307.3, and a health & usage monitoring / management system (HUMS) 307.4. The DAPU 307 serves as the real-time processing and data storage core of VSMS 300;

[0047] (2) One or more vehicle distributed VSMS elements 350, which may include various sensors 105 / 350.1 and other elements 350.n distributed on the vehicle 100; and

[0048] (3) One or more off-vehicle analysis or response units (OVARU) 380, which may operate in real-time (receiving real-time flight / transmission data from the vehicle 100), or may be used post-flight / post-operation / post-event for analysis of the vehicle 100 performance.

[0049] Some of these OVARU 380 may include an aircraft health monitoring / management system (AHMS). The aircraft health monitoring / management system provides analysis for improving the maintenance and management of the entire fleet of vehicles, including, for example but not limited to: improving aircraft utilization, improving aircraft reliability, improving flight on-time service, cost optimization, fleet utilization trend analysis, optimizing aircraft maintenance scheduling (e.g., predicting the optimal time / extent of aircraft repair to maximize safety and minimize downtime), cruise and landing analysis (fuel consumption, flight profile), and other analysis for improving the safety, reliability, and profitability of the vehicle fleet.

[0050] Some further details of the above-mentioned components (1), (2), and (3) are provided immediately below.

[0051] Data Acquisition and Processing Unit (DAPU): As schematically shown in the annotations in Figure 3 and, in an exemplary embodiment, DAPU 307 may include, for example but not limited to:

[0052] (a) A circuit card assembly (CCA) 310, which may also be known in the art as a motherboard 310, which typically holds and interconnects various microchips 315 / 320 / 325;

[0053] (b) Volatile and non-volatile memories or storage 320.2 / 320.3, which together enable the operation of DAPU 307 at the hardware level and also enable the operation of the present system and method. In particular, CVFDR 307.1 may include a crash-protected memory (CPM) 338, which may be integrated into unit 307.1 or may be separate from but attached to unit 307.1.

[0054] (c) A power supply 318, which may be mounted on the CCA 310 or may be a separate component within DAPU 307;

[0055] (d) A hardware processor 315, also known as a central processing unit (CPU) 315 or a microcontroller unit (MCU) 315, which provides overall operation control of DAPU 307. This includes but is not limited to receiving data from sensor 105 and possibly modifying some operations of sensor 105 via various application-specific integrated circuits (ASICs) 325;

[0056] (e) Static memory or firmware 320.1.1, which is used to store non-volatile operation code, including but not limited to operating system code, computer code for local processing and analysis of data from sensor 105, and computer code that may be specifically used to enable DAPU 307 to implement the methods described in this document and other methods within the scope and spirit of the appended claims. The CPU 315 may implement the methods described in this document and other methods within the scope of the appended claims using the code stored in the static memory 320.1.1;

[0057] (f) An interface circuit 325, which may perform various tasks, including data and control exchange with sensor 105, as well as input / output (I / O) tasks, network connection operations, control of bus 303, and other tasks commonly known in a processing system. The interface circuit 325 may also control or be connected to the non-volatile data storage 320.3.

[0058] The interface circuit 325 can also support these functions, such as external input / output (e.g., via a USB port, an Ethernet port, or wireless communication, not shown in the figure); a control interface for the cockpit interface panel 350 and / or the cockpit control unit (CCU); addressing and receiving data from various aircraft and engine data buses 350; and storing data in the memory card socket (MCR) 350.

[0059] (g) Volatile memory 320.2, such as dynamic RAM (DRAM), which can be used to temporarily store data received from the sensor 105. The volatile memory 320.2 can also be used to temporarily store some or all of the code from the static memory 320.1, and is also used to temporarily store the processed sensor data generated by the hardware processor 315 based on the data received from the sensor 105.

[0060] (h) Non-volatile data storage 320.3, which provides long-term storage for the sensor data, which may include some raw sensor data recorded over time; but typically includes processed (and thus compressed) sensor data. The non-volatile storage can take the form of a hard disk drive, a solid-state drive (including flash drives and memory cards), recording on magnetic tape, storing on a DVD or similar optical disc, or other known or upcoming non-volatile storage forms;

[0061] (i) System bus 303, which can be used to transfer data and messages between the components of the motherboard 310, and between the motherboard 310 and various other sensors, microchips, and controllers of the DAPU 307;

[0062] (j) The above indicates that the DAPU 307 includes internal memories 320.1 / 320.2. In some embodiments, the DAPU may have or be connected to and coupled with one or more memory sockets or storage sockets (MCR) 350.5, which are configured to contain memories 320.1 / 320.2 or storage 320.3, or in some embodiments contain supplementary, backup, or additional memories 320.1 / 320.2 or storage 320.3, which can be inserted and removed via the external access ports of the MCR 350.5.

[0063] Ports and connectors: Figure 3 Not shown in the figure, but present somewhere on the surface of the DAPU 307, can be ports and connectors, such as USB ports, Ethernet ports, and various dedicated connectors and ports for connecting the distributed HUMS components 350 to the DAPU 307.

[0064] In some embodiments of the present system and method, some vehicle sensing / monitoring system (VSMS) elements 350 may communicate with the DAPU 307 via wireless communication (such as on-board WiFi or Bluetooth connection or other wireless connections). The DAPU 307 may have an antenna and / or internal wireless circuitry (not shown in the figure) to enable such wireless data communication.

[0065] Vehicle Sensing / Monitoring System (VSMS) Elements: Figure 3 Also shown are various exemplary VSMS elements 350, which are typically part of or integrated in the vehicle 100 and are connected to the DAPU 307 via wires, cables, optical fibers, or possibly wireless devices. These may include, for example but not limited to, one or more sensors 350.1 / 105; an aircraft and engine data bus 350.2 for transferring data to the DAPU 307 and transmitting the results of the analyzed sensor data from the DAPU 307; one or more blade trackers (or, for example, aircraft wing operation sensors) 350.3; a cockpit control unit 350.3 and a cockpit interface panel 350.6.

[0066] Details of these and other possible vehicle distributed HUMS elements 350 are beyond the scope of this document and are not provided here.

[0067] Out-of-Vehicle Processing System: The VSMS 300 may include one or more out-of-vehicle analysis or response units (OVARU) 380. Once the vehicle 100 is on the ground (e.g., in a hangar) after transportation, they may communicate with the DAPU 307 via a wireless connection or via a wired data connection or a cloud data connection. Figure 3 Several exemplary out-of-vehicle processing systems 380 are shown, but many other systems are also conceivable. Such OVARU 300 may operate in real-time (receiving real-time flight / transmission data from the vehicle 100), or may be used post-flight / post-operation / post-event for analysis of the vehicle 100's performance.

[0068] Details of such OVARU 380 are beyond the scope of this document, but it should be noted that in a typical embodiment, the OVARU 380 may:

[0069] (i) Be used post-flight / post-operation / post-event for analysis of the vehicle 100's performance; or for real-time (receiving real-time flight / transmission data) support of flight operations or large-scale fleet operations;

[0070] (ii) Although a dedicated computer may be employed, it may be implemented as software on a general-purpose computer; and

[0071] (iii) Its analysis is supported by sensor data obtained from the vehicle via one or more flight recorders 307. VIII. Legacy DAPU as a separately line-replaceable unit

[0072] The DAPU 307 may include, for example but not limited to:

[0073] On-board Maintenance System (OMS) 307.2 - The OMS provides centralized vehicle maintenance; reports faults, isolates and diagnoses complex system faults; provides asset management and software loading; provides configured / timing of wing reports; supports general aircraft status monitoring; and provides complete flight data recording, configurable analysis and automatic data offload (wired / wireless).

[0074] Health and Usage Monitoring System (HUMS) 307.4 - Provides on-board status monitoring for the airframe, engines, drive trains, rotor systems and avionics to enable early detection of faults.

[0075] Quick Access Recorder (QAR) 307.3 - Provides recording of flight data for routine download to removable media (e.g., flash drive) or wireless download. They do not provide analysis or limited analysis of aircraft data. (For Flight Operations Quality Assurance (FOQA) and other purposes, data analysis is performed on the ground.)

[0076] Cockpit Voice and Flight Data Recorder (CVFDR) 307.1 - Provides flight data and cockpit audio recording for crash / event investigation and records to crash-protected memory (CPM). Has high mechanical / thermal survivability requirements and is typically a "fit and forget" component. Although data is sometimes downloaded for analysis, it is usually only downloaded in the event of an incident. In legacy systems, the DAPU 307 is typically implemented as different line-replaceable units (LRUs) 407 - one for the OMS 307.2, one for the HUMS 307.4, etc.

[0077] Those skilled in the relevant art will recognize that any single Line Replaceable Unit (LRU) 407 can be understood as an integrated multi-component electronic system that performs a specific function or group of functions; within the LRU 407, parts or components are structurally arranged or connected such that a single LRU 407 can be removed and replaced at the field level in a single slot or socket, or can be attached to and removed from a single slot or connector of a larger electronic system such as a cabinet or backplane (not shown in the figure). The cabinet or backplane typically provides mechanical attachment and electrical (or optical) communication coupling for multiple LRUs into the larger system in turn. The cabinet or backplane can provide their own communication and electrical buses to serve multiple LRUs and connect the multiple LRUs to other parts of the entire system (such as a vehicle).

[0078] In some cases, the backplane or cabinet can be configured to accept only a single LRU 407, but the single LRU 407 is still operable to facilitate installation and replacement. In some cases, the LRU includes an external cover or enclosure (e.g., made of metal, plastic, polycarbonate, etc.) as a component to house and mount internal electronics, as well as suitable mechanical attachments and external electrical / communication connectors mounted on the external cover or enclosure. The external cover can include display elements or other user interface elements for the internal electronics. Details of the LRU cover, if any, are generally not further discussed herein.

[0079] Vehicles such as helicopters and other aircraft use LRUs 407 to provide on-demand upgrades or maintenance (when necessary through complete LRU replacement) for specific electronic and processing functions (such as different types of functions of the DAPU 307). Figure 4 A block diagram of four separate Data Acquisition and Processing Units (DAPUs) 307, implemented as four separate Line Replaceable Units (LRUs) 407 as part of the VSMS 300, is provided in accordance with an exemplary legacy system and method for aircraft monitoring and maintenance.

[0080] It is obvious that each LRU 407 requires its own Circuit Card Assembly (CCA) 310, its own power supply 318, and its own interface 410 (which can include interface circuitry 325). Since traditionally, the VSMS system 300 consists of four separate LRUs 407 on a vehicle, this causes hardware redundancy. In addition, in order to perform its functions, wiring must be established between each of the four LRUs 407 and other vehicle distributed VSMS elements 350 (including sensors 105 / 351.1 on the vehicle 100) that each LRU 407 needs to interface with; this results in additional wiring and cabling.

[0081] In fact, in vehicle 100 having four separate LRUs 407, the separate LRUs 407 can be provided from four different suppliers / manufacturing companies, which results in the vehicle operator / maintenance personnel having to learn how to use and maintain four different sets of support software and hardware.

[0082] IX. Integrated DAPU for Integrated Vehicle Health Management (IVHM)

[0083] Health management functions: Now refer to Figure 5 , the exemplary DAPU 307 described in that document has common or typical health management functions 507. Figure 5 Some exemplary health management functions 507 (HMF) are listed in, and various functions are also allocated within the circle according to the various associated but separate DAPUs 307 on the separate LRUs 407 where those functions are typically performed.

[0084] For example, the CVFDR 307.1 can perform the CVFDR function 507.1, such as data recording, voice recording, and (in some CVFDRs) some limited data analysis functions. The exemplary OMS 307.2 can support the OMS function 507.2, such as central maintenance, asset management, event detection, data analysis, and data recording. The exemplary HUMS 307.4 can support the HUMS function 507.4, such as usage monitoring, event detection, data analysis, data recording, RTB (return to base), and powertrain health. The QAR 307.3 generally provides little data analysis and mainly supports the QAR function of data recording 507.3.

[0085] Embodiments of the present system and method can also identify and support a general health management function 507.9, which can include, for example but not limited to, configurable health analysis, usage monitoring, event detection, data recording, and virtual QAR functions. These general health management functions 507.9 can be partially implemented as elements of the vehicle external analysis or response unit (OVARU) 380 discussed above, including, for example, the aircraft health monitoring / management system (AHMS), for improving the maintenance, usage scheduling, and management of the entire fleet of vehicles (also discussed above).

[0086] In embodiments of the present system and method, the OMS function 507.2, the HUMS function 507.4, and other DAPU functions 507 as described above are executed on a single-line replaceable unit (LRU) 609. In embodiments of the present system and method, the OMS function 507.2, the HUMS function 507.4, and other DAPU functions 507 as described above are performed only by or substantially only by the electronics of a single circuit card assembly (CCA) 610, which may consist of the electronics required for data acquisition, processing, storage, and transmission. Further discussion follows. Figure 6 .

[0087] In embodiments, the present system and method are implemented not only via the physical / structural integration and consolidation of DAPU elements in a single LRU 609 and / or on a single main circuit card assembly 610. The present system and method can also integrate previously distributed and potentially redundant software modules (per legacy systems) into a single or fewer software modules that support multiple combined functions 507.

[0088] From Figure 5 the example functions 507 listed, it can be seen that two or more DAPUs 307 share many functions. For example, event detection, data analysis, and data recording can be performed by both HUMS 307.4 and OMS 307.2. Thus, in conventional systems, these methods are redundantly performed in both HUMS 307.4 and OMS 307.2. Similarly, in legacy systems, separate HUMS 307.4, OMS 307.2, and CVFDR 307.1 can each support the recording and analysis of various data, where each DAPU 307 requires its own software. In embodiments of the present system and method, integrated software on a single CCA 610 can support data recording and analysis to support the HUMS function 507.4, the OMS function 507.2, and the CVFDR function 507.1

[0089] In alternative embodiments of the present system and method, some functions 507, such as data acquisition that includes a minimal amount of initial data processing (herein referred to as preprocessing), can occur remotely (e.g., at sensor 105); then the digitized data from the remote preprocessing can be sent to the common CCA 610 for further processing, storage, and transmission.

[0090] In this document, for brevity, the combined function 507 may equivalently be referred to as the "Comprehensive Health Management Function 507" (CHMF 507), the "Integrated Function 507", the "HUMS / OMS Function 507"; it should be understood that it may also include the CVFDR function 507.1, the QAR function 507.3, and other configurable health management functions 507.9.

[0091] Integrated Health Management Hardware and Software: In various embodiments, the present system and method integrate the health management function 507 in a single integrated DAPU 607 via integrated hardware.

[0092] In an embodiment of the present system and method, the software for performing the comprehensive health management function 507 runs on a single common CCA 610 in a single integrated DAPU 607. In an embodiment, the present system and method may use a shared memory region 620 and mailboxes for internal communication between software modules. In an alternative embodiment, separate memory regions / mailboxes may be employed for separate functions. In various embodiments, a single CCA 610 may consist of one hardware processor 615 to perform the comprehensive health management function 507, or it may consist of two or more hardware microprocessors 315 that distribute functions among them. The single CCA 610 may have a system bus (not shown in the figure) to communicatively couple the processor 615, the memory 620, and other ASICs (not shown) required for operation.

[0093] Those skilled in the relevant art will understand that the hardware processor 615 has different levels of processing capabilities (e.g., measured by parameters such as clock speed, number of operations per second, and specific types and ranges of supported microinstructions); and similarly, a varying amount of memory 620 may be provided (e.g., measured in megabytes, gigabytes, or terabytes). The present system and method are implemented with a main CCA 610 having a hardware microprocessor with sufficient processing capabilities and a memory with sufficient storage capacity to reliably implement the comprehensive set of VHM functions 507.

[0094] In an embodiment, the present system and method may also have a data source (e.g., an ARINC 429 digital data bus), which is used by both the integrated comprehensive health management functions 507. In an embodiment, the present system and method have a data transfer mechanism (e.g., a removable memory card such as an SD card or an external wireless (Wi-Fi) router) used and shared by the integrated comprehensive health management functions 507.

[0095] The QAR 307.3 is typically a device that receives data through a digital interface (e.g., RS-422, ARINC 429, Ethernet) and records it in an industry-standard format (e.g., ARINC 717 or 767 for aviation) onto a removable media device (e.g., an SD card). Since the integrated comprehensive health management function 507 already requires means for uploading data and downloading data from the system, the addition of the QAR function 507.3 in the present system and method only requires a removable storage medium such that some of the recorded data to be removed is in an industry format.

[0096] The present system and method can also be built on the system defined above by further integrating the crash survivable cockpit voice and flight data recorder (CVFDR) function 507.1. The function 507.1 of the CVFDR typically includes data acquisition, storage, processing, and particularly recording to a crash survivable memory device (which is typically armored and contains thermal management compounds for survival under potentially extreme environmental conditions). In an embodiment of the present system and method, the data processing function 507.1 of the CVFDR is performed at least on the same common CCA 610 as the HUMS function 507.4 and the OMS function 507.2.

[0097] The OMS, HUMS, and CVFDR software or software modules 700.n can be run on a single hardware processor 615 or on multiple processors on a single CCA 610 (see Figure 7 below), and the functions of a single CCA 610 are integrated and / or coordinated via a shared memory 620 and a suitable operating system.

[0098] In an embodiment, the present system and method can employ a single data source (e.g., an ARINC 429 digital data bus) used by the CVFDR, HUMS, and OMS functions.

[0099] In an embodiment, the present system and method can also include a version in which a common ground software suite is utilized to manage the HUMS, OMS, CVFDR, and QAR systems.

[0100] The present system and method provide a means to improve safety and reduce maintenance burdens by integrating the HUMS, OMS, and optionally the CVFDR and QAR systems. Traditionally, and as described above, these HUMS / OMS / CVFDR / QAR systems consist of two to four separate LRUs (line replaceable units), and vehicle wiring is established between each of the two to four LRUs and other systems and / or sensors 105 on the vehicle. However, each of the HUMS / OMS / CVFDR / QAR systems needs to have a common or substantially similar interface; thus, combining them into a single LRU can eliminate one to three sets of wiring for each common interface.

[0101] Since legacy systems utilize four separate DAPUs 307 on separate LRUs 407, the separate devices typically come from four different suppliers; this results in operators / maintenance personnel having to learn how to use and maintain four different sets of support software and hardware. In an embodiment of the present system and method, an integrated DAPU 607 for integrated vehicle health management (IVHM) is provided by a single supplier (e.g., General Electric Aviation Systems), thus enabling simplified software and hardware support.

[0102] In an embodiment, the present system and method benefit from having a number of HUMS functions 507.4 receive the output from one or more OMS functions 507.2 as input. For example, if the HUMS software receives the output from an OMS software fault reduction rule as input (which can identify the root cause of a problem rather than reporting each (individual) separate fault), then the time and system resources dedicated to fault finding can be reduced.

[0103] Combining four or possibly more vehicle health maintenance functions 507 and associated hardware into a single DAPU 607 can reduce the support software and hardware, thus providing significant cost and scheduling savings in terms of training and support for the end user. Having the functional equivalents of two, three, or four DAPU systems 307 on a common hardware platform as an integrated subsystem also enables closer sharing of knowledge between the subsystems; this can enhance fault detection and can prevent the occurrence of undetected critical faults.

[0104] Figure 6 Provided is a block diagram of an exemplary integrated DAPU 607 having a single LRU 609 and a QAR interface 612. The "integrated DAPU 607" may be equivalently referred to in this document as a "single DAPU 607", an "integrated DAPU 607", or a "multi-service DAPU 607".

[0105] In an embodiment of the present system and method, the physical structure of the QAR 612 may be physically separated from the LRU 609 of the DAPU, with the two communicatively connected via a suitable cable or wireless connection (as shown in the figure). In an alternative embodiment, the QAR 612 (having, for example, a suitable USB interface, Ethernet interface, SD card, or flash drive interface) may be integrated into a single LRU 609.

[0106] In an embodiment of the present system and method, the crash protected memory (CPM) 683 associated with the CVFDR function 507.1 may be physically integrated into the single LRU 609 of the DAPU (as shown in the figure). In such an embodiment, the entire single DAPU 607 having its single LRU 609 may have a housing or enclosure (not shown) designed for extreme heat and crash protection. In an alternative embodiment, the CPM 638 may have its own crash protected housing or enclosure and may be physically separated from the single LRU 609; in such an embodiment, the single LRU 609 and the CPM 638 will be communicatively linked via a suitable wire, cable, or wireless connection.

[0107] In an embodiment of the present system and method, a single LRU 609 has a single master integrated circuit card assembly 610 to support the HUMS / OMS / CVFDR / QAR functions 507. In turn, the single CCA 610 can have:

[0108] (1) A single CPU 615 that supports all processing operations, or can have multiple CPUs 615 or a single CPU 615 with multiple cores, or both, which can share the support of software modules that support the health management function 507. This integrated DAPU hardware processor 615 can perform functions and has operations similar to those listed above for the (see Figure 3 ) hardware processor / CPU 415 discussed above.

[0109] (2) A memory 620, which can include static memory / firmware, dynamic / non-volatile memory, and non-volatile data storage. These integrated DAPU memory elements 620 can perform functions and have operations similar to those listed above for the (see Figure 3 ) memories 320.1, 320.2, 320.3 discussed above, which would exist as multiple memory chips on two or more separate CCAs 310 of multiple separate line units 407.

[0110] (3) Interface circuits (not shown in the figure), which can be located on the main CCA 610 of the single LRU 609 or on the interface CCA 614.1 and / or the backplane CCA 614.2. These interface circuits can perform functions and have operations similar to those listed above for the (see Figure 3 ) interface circuit 325 discussed above. The integrated interface CCA 614.1 of the integrated DAPU 617 provides a common connection point for interfacing with other elements 350 of the entire vehicle sensing / monitoring system (VSMS), such as the HUMS unique interface 650.1, the CVFDR interface 650.2, the common interface 650.3, and other miscellaneous analog and discrete components 650.4. The backplane CCA 614.2 provides a common connection for integrating the LRU 609 into the appropriate socket or connection to the backplane or electrical cabinet of the vehicle 100.

[0111] The single LRU 609 of the integrated / single DAPU 607 can also benefit from a common single power CCA 618.

[0112] Figure 9A block diagram is provided of four different (i.e., alternative) exemplary CCA hardware configurations 610 for a unique Main Circuit Card Assembly (CCA) 610 sufficient to implement the integrated DAPU system and method disclosed herein, with the integrated DAPU 607 being implemented via a single LRU 609. Some example supplemental CCAs or other components are also shown appropriately in the figure, which may be used as part of the integrated DAPU 607 or be associated with the integrated DAPU 607. The four embodiments shown are merely exemplary and not restrictive, and those skilled in the art will understand that variations can be envisioned within the scope of this disclosure and the appended claims.

[0113] According to the system and method, CCA 610.1 is a single circuit card assembly, such as a Printed Circuit Board (PDB). The components shown can be mounted on CCA 610.1 according to methods and processes known in the art or other methods to be developed in the future. CCA 610.1 has electronic components, which may include, for example but not limited to:

[0114] (1) A data processing component 915, which in an embodiment includes a single CPU 615 with sufficient processing power to support all data processing requirements of the integrated DAPU 607 for the Comprehensive Health Management Function 507CHMF 507. In one embodiment, this may require supporting the OMS function 507.2 and the HUMS function 507.4; and in some embodiments, it may be required to support some or all of the HUMS function 507.4, the QAR function 507.3, and / or the General Health Management Function 507.9. The CPU 615 can have one processing core or multiple processing cores.

[0115] The data processing component 915 may also include associated support chips (not shown in the figure), such as an FPGA to support in - field customization, a memory interface chip, additional cache memories, a bus management / arbitration chip, a process scheduling or process prioritization chip, and possibly one or both of a static memory / firmware 320.1 and a dynamic / volatile memory 320.2.

[0116] (2) Memory / storage, which may include a non - volatile data storage (320.3), such as a hard disk drive or an SSD; and may also include either a static memory / firmware 320.1 or a dynamic / volatile memory 320.2.

[0117] (3) Data I / O elements or ASICs 914, such as a data acquisition chip 914.1 and a data transmission 914.2.

[0118] (4) One or more physically and / or communicatively coupled connectors 905 for connecting the CCA 610.1 to the remainder of a single LRU 609, including for receiving power and for data communication purposes.

[0119] The main CCA 610.2 is a single circuit card assembly that is similar to CCA 610. (Repeated elements are not described again.) The CCA 610.2 has a data processing unit 915, and the data processing unit 915 has two or more CPUs 615.n or hardware microprocessors 615.N (such as CPUs 615.1 and 615.2). The use of other CPUs is also contemplated. In an embodiment of the present system and method, the two CPUs 615 can be the same or similar general-purpose processors 615, both of which are used to run software modules to support the integrated health management function 507. In an alternative embodiment, the first CPU 615.1 can be a general-purpose hardware microprocessor, while the second CPU 615.2 can be a dedicated processing ASIC, such as a digital signal processing (DSP) chip or other ASIC, which is customized for and / or dedicated to processing tasks associated with processing data from the sensors 105 of the vehicle 100.

[0120] The main CCA 610.3 is a single circuit card assembly that is similar to CCA 610. (Repeated elements are not described again.) The CCA 610.3 includes a CPM interface 940 that is configured to be communicatively coupled to a CCA-off crash-protected memory CPM 638. This enables one or more CPMs 638 (only one is shown in the figure) to be placed at different locations on the vehicle 100. Thus, one or more CPMs 638 are configured to maintain non-volatile storage of selected DAPU data or integrated DAPU data in the event that the vehicle 100 is damaged or destroyed; or in the event that the integrated DAPU 607 is damaged or the on-board DAPU memory / storage 320 is damaged or erased.

[0121] The main CCA 610.3 is a single circuit card assembly that is similar to CCA 610. (Repeated elements are not described again.) The CCA 610.3 includes a CPM interface 940 that is configured to be communicatively coupled to an off-CCA crash-protected memory CPM 638. This enables one or more CPMs 638 (only one is shown in the figure) to be placed at different locations on the vehicle 100. Thus, one or more CPMs 638 are configured to maintain non-volatile storage of selected DAPU data or integrated DAPU data in the event that the vehicle 100 is damaged or destroyed; or in the event that the integrated DAPU 607 is damaged or the on-board DAPU memory / storage 320 is damaged or erased.

[0122] The main CCA 610.4 is a single circuit card assembly that is similar to CCA 610. (The repeated elements are not described again.) However, CCA 610.4 None The data I / O components 914 of the CCA 610 are not included in the data acquisition components 914.1 / 914.2. Instead, the data acquisition components 914.1 / 914.2 are mounted on a separate circuit card assembly 614, which is a separate component of the single LRU 609. The separate interface CCA 614 can be connected to the above Figure 6 The interface and / or backplane CCA 614.2 / 614.2 shown are the same or similar. The master CCA 610.4 is coupled to the data acquisition CCA 614 via a suitable connector 905. The master CCA 610.4 may have two hardware processors 615, as shown, or only one processor 615, or more processors.

[0123] Combinations of the different elements of the above-described main circuit card assembly 610.n are contemplated within the scope of the present disclosure and appended claims.

[0124] Integrated card-level system operation on integrated DAPU

[0125] Discussed above are vehicle health management functions 507 associated with different types of CPUs. According to the present systems and methods, health management functions 507 may be integrated into software and hardware via an integrated DAPU 607.

[0126] Figure 7 Several broad categories of basic system operations 700, application operations 700, software and hardware operations 700, and interfaces 700 are shown, which in various embodiments of the present systems and methods may support or be associated with implementing health management functions 507. These may also be collectively referred to herein as "monitoring system operations 700" or "DAPU system operations 700."

[0127] DAPU system operations 700 may include, for example, but not limited to, data collection 700.1, where data may be collected directly from sensors or as a result of intermediate sensor data analysis; data offloading 700.2; data storage 700.3; sensor and software configuration 700.4; data analysis 7005; and user interface control 700.6. In various embodiments of the present systems and methods, system operations 700 may be implemented via ASIC-level hardware, firmware, operating system modules, and software applications or software application modules, or via a combination of two or more of the above. Specific categories of system operations may also be envisioned as application-specific software or software modules 700.n.

[0128] Those skilled in the relevant art will understand that in legacy systems that employ separate DAPUs 307 (e.g., separate OMS 307.2 and separate HUMS 307.4 on separate line cards 407.2 / 407.4), each separate line card 407 will have its own separate hardware 310 / 315 / 320 / 325 / 303 / 318 to support DAPU monitoring system operations 700. Similarly, in legacy systems that employ separate DAPUs 307 (e.g., separate OMS 307.2 and separate HUMS 307.4 on separate line cards 407.2 / 407.4), an operating system and application software or software modules must be provided for each line card 407. For example, each of OMS 307.2, QAR 307.3, HUMS 307.4, and CVFRD 307.1 must have its own operating system. Similarly, each of OMS 307.2, QAR 307.3, HUMS 307.4, and CVFRD 307.1 must have its own hardware and software support for data acquisition 700.1 or data analysis 700.5.

[0129] For purposes of understanding in Figure 7 the context of several virtual DAPUs 715, the same monitoring system operations 700.n (e.g., data acquisition 700.1, data analysis 700.5, etc.) are repeated several times. According to the present system and method, it is contemplated that each virtual DAPU 715 operates in conjunction with a framework of integrated LRU / CCA 609 / 610. In an embodiment of the present system and method, monitoring system operations 700 such as, for example, data acquisition 700.1, data storage 700.3, and data analysis 700.5 can be implemented via common hardware and common corresponding software modules 700.n within a single integrated LRU 609 having a single master CCA 610. Benefits can include a reduction in the number of chip components, a reduction in memory requirements, a reduction in energy consumption, and a more integrated software design.

[0130] For example, for the purpose of data storage 700.3, the integrated LRU according to the present system and method may employ a common memory chip and shared memory allocation to save sensor data that can be adopted by multiple virtual DAPUs 715. For a more specific example without limitation, the vehicle sensor data for speed, position, engine performance, and fuel consumption information recorded / analyzed by the virtual OMS and virtual HUM of the integrated LRU 609 may be stored in the common memory area of the memory chip 620 on the main CCA 610. For the same sensor data (speed, position, engine performance data, fuel consumption), an optimized integrated database structure (e.g., appropriate tables, data fields, and data retrieval operations) can be shared and adopted by both the OMS health management function 507.2 and the HUM health management function 507.4.

[0131] For another example, for the purpose of data analysis 700.5, the integrated LRU according to the present system and method may adopt a common algorithm in an integrated software data analysis module 700.5 running on a single CPU 615 to analyze the sensor data of both the OMS health management function 507.2 and the HUMS health management function 507.4. For a non - limiting example, the OMS - specific health management function 507.2 and the HUMS - specific health management function 507.4 may require some common statistical analysis of sensor data (e.g., but not limited to determination of average sensor value, maximum value, minimum value, and rate of change of value), which can be processed by a common low - level software module, and the results are input into the OMS - or HUMS - specific software module for more specific analysis.

[0132] Those skilled in the relevant art will understand that, as known in software engineering, in some embodiments, the "single software data analysis module" may include sub - modules and / or multiple software processes that may be loaded from separate application files or operating system files, and they run together to form a modular system with coordinated and relevant data - processing functions.

[0133] Similarly, compared with legacy systems, according to the present system and method, operations such as data filtering or user interface / GUI tools for data presentation or for tuning sensor operations can be provided via more integrated and consistent software coding (and integrated GUI).

[0134] Those skilled in the relevant art will understand that, according to the present system and method, for a separate virtual DAPU 715 Figure 7 the multiple data acquisition functions 700.1 shown can actually be integrated into a common software module for the integrated DAPU 607 or implemented via a common software library.

[0135] Similarly, legacy systems may require separate data analysis modules / programs 700.5.n for different DAPUs 307, resulting in redundant coding (possibly from multiple different suppliers of DAPUs), and there may be a possibility of coding inconsistencies. Various embodiments of the present system and method employ a single data analysis module 700.5 running on the hardware processor / CPU 615 of the main CCA 610.

[0136] In an embodiment, the present system and method can provide a minimal integration library of a single software module or related software functions (e.g., a single data acquisition module 700.1, a single configuration module 700.4, a single data analysis module 700.5), which together implement the operation of a virtual OMS, virtual HUMS, and virtual CVFDR 715 in a single integrated LRU 609.

[0137] Another advantage of the present system and method can be the support for some functions that may not typically be supported by legacy stand-alone DAPUs 307. For example, a legacy stand-alone CVFDR 307.1 may support very little or no data analysis, but only store or mainly store raw sensor data. In contrast, in embodiments of the present system and method, the integrated DAPU 307 already supports extensive airborne data analysis; thus, in some embodiments of the present system and method, it is easy to transfer selected, processed sensor data and selected advanced analyses (e.g., real-time analysis of airframe stress or engine performance) to a physically crash-protected memory 638 associated with the virtual CVFDR 715.1.

[0138] Those skilled in the art will understand that the functional / module partitioning shown in the figures is merely exemplary, and some functional / module elements may have some overlap in function or be integrated into a single module. In other embodiments of the present system and method, alternative or modified functional / module partitioning may be employed. For example, data acquisition 700.1 and data storage 700.3 may be combined into a single software module, or may be distributed over more than two software modules.

[0139] For another example, data analysis 700.5 may be divided into multiple modules or multiple processing layers, such as a first software layer for real-time summarization or statistical compression of real-time data from a single class of sensors 105; a second software layer for extracting or identifying patterns or anomalies in the first-layer data; and a third software layer for identifying system or environmental patterns, problems that can be identified based on data from multiple different types of sensors 105. Thus, additional and alternative module functional partitioning for processing vehicle sensor data can be envisioned within the scope of the present system and method.

[0140] Figure 8 Shows another exemplary view of vehicle monitoring, analysis, reporting, and support functions, such as the OMS function 507.2 and the HUMS function 507.4, which can be provided in legacy systems via a separate OMS DAPU 307.2 and a separate HUMS DAPU 307.4 with their respective hardware and software. Thus, two or more legacy systems are required to support, for example, an AHMS system outside the vehicle (as described above). In a manner consistent with the foregoing disclosure, an exemplary embodiment of the present system and method can implement and integrate the shown exemplary OMS and HMS functions into a single integrated DAPU 607 running on a single LRU 609 and / or a single main CCA 610.

[0141] X. Overview and Advantages

[0142] The HUS 307.4, OMS 307.2, CVFDR 307.1, and QAR 307.3 have been installed as separate systems on many vehicles 100. The present system and method combine these functions into an integrated DAPU 607, and mainly a circuit card assembly (CCA) 610 (except for the crash-protected memory (CPM) 638 device of the CVFDR that is separated from the CCA but physically connected). The technical advantages for vehicle operators and / or manufacturers include significant reduction in LRU, weight, and power. The present system and method also reduce the system integration activities of customers (such as manufacturers of aircraft and other vehicles). The ability to more easily utilize the cross-functional capabilities of the modules enhances fault detection and reduces the aircraft maintenance burden. Compared with legacy systems, the reduced hardware footprint reduces recurring costs and also increases the ability of the present system and method to capture more aircraft functions / data streams.

[0143] XI. Conclusion

[0144] Those skilled in the art, particularly in light of the foregoing teachings, can make alternative embodiments, examples, and variations that the present disclosure will still encompass. Additionally, it should be understood that the terms used to describe the present disclosure are intended to be of a descriptive nature rather than restrictive.

[0145] Those skilled in the art will also understand that various adaptations and variations of the above-described preferred and alternative embodiments can be configured without departing from the scope of the present disclosure. Thus, it should be understood that the present disclosure can be practiced in a manner different from that specifically described herein within the scope of the appended claims.

[0146] The present invention has been described above by means of functional building blocks that describe the implementation of specific functions and their relationships. For ease of description, the boundaries of these functional building blocks have been arbitrarily defined here. Alternative boundaries can be defined as long as the specified functions and their relationships are appropriately performed.

[0147] For example, various aspects of the present invention can be implemented by software, firmware, hardware (or hardware represented by software, such as Verilog or hardware description language instructions), or combinations thereof. After reading this description, it will become apparent to those skilled in the relevant art how to implement the present invention using other computer systems and / or computer architectures.

[0148] It should be noted that the simulation, synthesis, and / or fabrication of various embodiments of the present invention can be accomplished in part by using computer-readable code, which includes general-purpose programming languages (such as C or C++), hardware description languages (HDLs) including Verilog HDL, VHDL, Altera HDL (AHDL), etc., or other available programming and / or schematic capture tools (such as circuit capture tools).

[0149] This computer-readable code can be provided on any known computer-usable medium including semiconductors, magnetic disks, optical disks (such as CD-ROMs, DVD-ROMs), and can be provided as a computer data signal embodied in a computer-usable (e.g., readable) transmission medium (such as a carrier wave or any other medium including digital, optical, or analog-based media). In this way, the code can be transmitted over communication networks including the Internet and intranets. It should be understood that the functions and / or structures accomplished by the above systems and techniques can be represented in a core (such as a GPU core), which is embodied in program code and can be converted to hardware as part of the production of an integrated circuit.

[0150] It should be understood that the detailed description section (rather than the overview and abstract sections) is intended to interpret the claims. As the inventors envision, the overview and abstract sections may set forth one or more but not all of the exemplary embodiments of the present invention, and thus are not intended to limit the present invention and the appended claims in any way.

[0151] Further aspects of the present invention are provided by the subject matter of the following clauses:

[0152] 1. A data acquisition and processing unit (DAPU) used in a transportation vehicle, the DAPU consisting of a single line replaceable unit (LRU) that includes only a single main circuit card assembly (CCA), wherein: the single LRU is configured to receive sensor data from a plurality of sensors of the transportation vehicle, and the single main circuit card assembly is electronically configured to provide integrated processing to implement a set of comprehensive vehicle health management (VHM) functions, the set of comprehensive VHM functions including: (i) on-board maintenance system (OMS) functions and (ii) health and usage monitoring / management system (HUMS) functions.

[0153] 2. The DAPU according to any preceding item, wherein the single main CCA includes a hardware microprocessor and a memory, and the hardware microprocessor and the memory have corresponding processing capabilities and corresponding memory capacities sufficient to implement the set of comprehensive VHM functions.

[0154] 3. The DAPU according to any preceding item, wherein the set of comprehensive DAPU functions further includes at least one of the following: crash-survivable cockpit voice and flight data recorder (CVFDR) function; and quick access recorder (QAR) function.

[0155] 4. The DAPU according to any preceding item, wherein: the set of comprehensive DAPU functions further includes a crash-survivable cockpit voice and flight data recorder (CVFDR) function, and the DAPU includes at least one of the following: (a) an integrated crash-protected memory (CPM) and (b) an interface connected to the CPM, the CPM being separated from the DAPU and configured to retain data storage when the DAPU is lost.

[0156] 5. The DAPU according to any preceding item, wherein: the set of comprehensive DAPU functions further includes a quick access recorder (QAR) function, and the DAPU includes at least one of the following: (a) an integrated crash-protected memory (CPM) and (b) an interface connected to the CPM, the CPM being separated from the DAPU and configured to retain data on a removable storage.

[0157] 6. The DAPU according to any preceding item, wherein the DAPU is configured to have a plurality of modules to support data acquisition, data storage, data analysis, and data offloading for all functions of the set of comprehensive DAPU functions.

[0158] 7. According to any of the preceding items of the DAPU, wherein the DAPU is further configured to have modules to support at least one of user interface control, sensor configuration, and processing configuration for all functions of the set of integrated DAPU functions.

[0159] 8. According to any of the preceding items of the DAPU, wherein the on-board maintenance system (OMS) function includes at least two of the following: fault handling function, test and manipulation function, data loading function, software loading function, vehicle configuration reporting function, data recording, and event overrun detection.

[0160] 9. According to any of the preceding items of the DAPU, wherein the health and usage monitoring / management system (HUMS) function includes at least two of the following: vibration analysis, vehicle component usage monitoring, rotor orbit and balance monitoring, data recording, and event overrun detection.

[0161] 10. An electronic monitoring system (EMS) includes: a single line replaceable unit (LRU), the single line replaceable unit (LRU) having a single main circuit card assembly (CCA), the single main CCA including a hardware processor and a memory, wherein the single LRU is configured to: be integrated in an air transportation vehicle; perform multiple sensing, monitoring, and reporting (SMR) functions, the multiple SMR functions including two or more of a health and usage monitoring system (HUMS) function, a cockpit voice and flight data recorder (CVFDR) function, an on-board maintenance system (OMS) function, and a quick access recorder (QAR) function; and the single main CCA includes a data interface configured to interface with all sensing systems of the transportation vehicle that are required to support the multiple SMR functions.

[0162] 11. According to any of the preceding items of the EMS, wherein the LRU includes at least one of the following: (a) an integrated crash-protected memory (CPM) and (b) an interface connected to the CPM, the CPM being separated from the DAPU.

[0163] 12. According to any of the preceding items of the EMS, wherein the LRU includes at least one of the following: (a) an integrated quick access recorder (QAR) and (b) an interface connected to the QAR, the QAR being separated from the LRU.

[0164] 13. According to any of the preceding items of the EMS, wherein the EMS is further configured to have modules to support at least one of user interface control, sensor configuration, and processing configuration for all functions of the multiple sensing, monitoring, and reporting (SMR) functions.

[0165] 14. According to any of the foregoing items of EMS, wherein the SMR function includes at least two of the following: fault handling function, test and manipulation function, data loading function, software loading function, vehicle configuration reporting function, data recording and event overrun detection.

[0166] 15. According to any of the foregoing items of EMS, wherein the on-board maintenance system (OMS) function includes at least two of the following: fault handling function, test and manipulation function, data loading function, software loading function, vehicle configuration reporting function, data recording and event overrun detection.

[0167] 16. According to any of the foregoing items of EMS, wherein the health and usage monitoring / management system (HUMS) function includes at least two of the following: vibration analysis, vehicle component usage monitoring, rotor orbit and balance monitoring, data recording and event overrun detection.

Claims

1. A data acquisition and processing unit (DAPU) used in a transportation vehicle, characterized in that, Comprising: A single Line Replaceable Unit (LRU), wherein the single LRU is configured to receive sensor data from a plurality of sensors of the transportation vehicle; And A single Main Circuit Card Assembly (CCA), the single main CCA being disposed within the MU, wherein the single main CCA is electronically configured to provide integrated processing to implement a set of comprehensive Vehicle Health Management (VHM) functions, the set of comprehensive VHM functions including: (i) On-board Maintenance System (OMS) functions and (ii) Health and Usage Monitoring / Management System (HUMS) functions, Wherein the OMS function is configured to receive and analyze the output of the HUMS function as input, and wherein the OMS function includes fault handling functions, test and manipulation functions, data loading functions, software loading functions, vehicle configuration reporting functions, data recording and event overrun detection, Wherein the VHM functions further include non-redundant common event detection, data analysis and data recording for the OMS function and the HUMS function, and Wherein the single main circuit card assembly is further configured to include at least one module to support user interface control, sensor configuration and processing configuration for the OMS function and the HUMS function, and Generate visual alerts for the operator based on the OMS function and the HUMS function.

2. The DAPU according to claim 1, characterized in that, Wherein, The single main CCA includes a hardware microprocessor and a memory, the hardware microprocessor and the memory having corresponding processing capabilities and corresponding memory capacities sufficient to implement the set of comprehensive VHM functions.

3. The DAPU according to claim 1, characterized in that, Wherein, The set of comprehensive VHM functions further includes at least one of the following: Crash-Survivable Cockpit Voice and Flight Data Recorder (CVFDR) function; and Quick Access Recorder (OAR) function.

4. The DAPU according to claim 1, characterized in that, Wherein: The set of comprehensive OHM functions further includes a crash-survivable cockpit voice and flight data recorder (CVFDR) function, and the DAPU further includes at least one of the following: (a) Integrated Crash-Protected Memory (CPM) and (b) An interface connected to the CPM, the CPM being separated from the DAPU and configured to maintain data storage when the DAPU is lost.

5. The DAPU according to claim 1, characterized in that, Wherein: The set of comprehensive VHM functions further includes a quick access recorder (OAR) function, and the DAPU further includes at least one of the following: (a) Integrated Crash-Protected Memory (CPM) and (b) An interface connected to the CPM, the CPM being separated from the DAPU and configured to maintain data on a removable storage device.

6. The DAPU according to claim 1, characterized in that, Wherein, The DAPU is further configured to have a plurality of modules to support data acquisition, data storage, data analysis and data offloading for all functions of the set of comprehensive VHM functions.

7. The DAPU according to claim 1, characterized in that, Wherein, The On-board Maintenance System (OMS) function further includes fault handling functions, data analysis and data recording.

8. The DAPU according to claim 1, characterized in that, Wherein, The health and usage monitoring / management system (HUMS) function further includes at least two of the following: vibration analysis, vehicle component usage monitoring, rotor orbit and balance monitoring, data logging, and event limit detection.

9. The DAPU according to claim 1, characterized in that, Wherein, the OMS function further includes one or more software fault detection rules configured to identify root causes based on multiple HUMS output data.

10. An electronic monitoring system (EMS), characterized in that, Comprising: a single line replaceable unit (LRU); and a single main circuit card assembly (CCA) disposed within the LRU, the single main CCA including a hardware processor and a memory, wherein the single LRU is configured to: be integrated into a post-transport vehicle; perform multiple sensing, monitoring, and reporting (SMR) functions, the multiple SMR functions including two or more of a health and usage monitoring system (HUMS) function, a cockpit voice and flight data recorder (CVFDR) function, an on-board maintenance system (OMS) function, and a quick access recorder (QAR) function, wherein the OMS function is configured to receive and analyze the output of the HUMS function as input, wherein the SMR functions include a fault handling function, a test and manipulation function, a data loading function, a software loading function, a vehicle configuration reporting function, data logging, and event limit detection; include at least one module to support user interface control, sensor configuration, and processing configuration for the multiple sensing, monitoring, and reporting (SMR) functions; and the single main CCA includes a data interface configured to interface with all sensing systems of the transport vehicle that are required to support the multiple SMR functions, wherein the SMR functions further include non-redundant common event detection, data analysis, and data logging for the two or more functions, and wherein the I.RU k is further configured to generate an alert to an operator based on the two or more functions.

Images