The present disclosure is related to electronic systems, and more particularly to electronic systems for tracking distress events on an aircraft.
A conventional method of determining an emergency or distress condition of an aircraft involves evaluating a plurality of sensor measurements using fixed thresholds to determine a Boolean true/false value to represent if the aircraft is in distress. Unfortunately, this conventional method has issues with both false detection (i.e. giving a distress indication when none exist) and failure of detection (i.e. no indication that a distress condition is occurring). Both of these issues reduce a confidence in any distress annunciation, and thus may impact an effectiveness in any response to the distress annunciation. It is, therefore, desirable to provide a method and system that addresses the shortcomings of the conventional method.
Disclosed is a method for autonomously tracking distress events on an aircraft in real-time while in flight. The method involves maintaining a multi-logic logic classifier configured for identifying distress events, receiving aircraft state data from at least one MAU (main avionics unit), transforming the aircraft state data using the multi-logic classifier to produce transformed state data, producing a trigger event if the transformed state data indicates a distress event, and generating an alert of the trigger event.
In accordance with an embodiment of the disclosure, the multi-logic logic classifier is configured for identifying distress events using more than two possible truth values, for example by implementing a fuzzy logic algorithm or an artificial neural network. This is an improvement over the conventional method in which fixed thresholds are used to determine a Boolean true/false value to represent if an aircraft is in distress. In particular, by using the multi-valued logic classifier, it is possible to mitigate or avoid issues of false detection and failure of detection. As such, when the alert of the trigger event is generated, there can be a relatively high level of confidence in the alert, and thus it may be possible for an effective response to be actioned.
Also disclosed is a non-transitory computer readable medium having recorded thereon statements and instructions that, when executed by a processor of a system, implement the method as summarized above.
Also disclosed is a system that generally corresponds to the method summarized above.
Other aspects and features of the present disclosure will become apparent, to those ordinarily skilled in the art, upon review of the following description of the various embodiments of the disclosure.
Embodiments will now be described with reference to the attached drawings in which:
It should be understood at the outset that although illustrative implementations of one or more embodiments of the present disclosure are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.
Referring first to
When deployed, the system 100 can be disposed within the aircraft and is coupled to at least one MAU of the aircraft. By way of overview, the system 100 is configured to receive aircraft state data 110 from the at least one MAU, process the aircraft state data 110, and to generate an alert of a trigger event 120 when the system 100 determines that the aircraft may be in distress. The trigger event 120 can be advisory of pre-distress event (i.e. distress event may occur unless corrective action is taken), or advisory of an actual distress event (i.e. distress event is occurring or may occur imminently).
Operation of the system 100 of
At step 2-1, the system 100 maintains the multi-logic classifier 101, which is configured for identifying distress events. In some implementations, the multi-logic classifier 101 is software-based and executed on the processor 103, in which case maintaining the multi-logic classifier 101 can involve storing software and any associated configurations of the multi-logic classifier 101 in the memory 105. However, other implementations are possible, including hardware-based implementations, for example by using an FPGA (field programmable gate array) or a microcontroller to implement the multi-logic classifier 101.
At step 2-2, the system 100 receives aircraft state data 110 from the at least one MAU. In some implementations, the system 100 receives the aircraft state data 110 via the avionics interface 102. The aircraft state data 110 includes various data such as altitude, airspeed, pitch, roll, heading, engine, spoiler position, etc. The aircraft state data 110 includes real-time data that is dependent on the aircraft and its state. Prior to the aircraft entering a state of distress, there can be clues within the aircraft state data 110.
At step 2-3, the system 100 transforms the aircraft state data using the multi-valued logic classifier 101 to produce transformed state data. If at step 2-4 the transformed state data indicate a distress event, then at step 2-5 the system 100 produces a trigger event. In some implementations, the system 100 transforms the aircraft state data via the processor 103 implementing the multi-valued logic classifier 101, and produces the trigger event via the processor 103 as well. However, as noted above, other implementations are possible, including hardware-based implementations.
In accordance with an embodiment of the disclosure, the multi-valued logic classifier 101 is configured for identifying distress events using more than two possible truth values, for example by implementing a fuzzy logic algorithm or an artificial neural network. This is an improvement over the conventional method in which fixed thresholds are used to determine a Boolean true/false value to represent if an aircraft is in distress. In particular, by using the multi-valued logic classifier 101, it is possible to mitigate or avoid issues of false detection and failure of detection. Example details of how to identify distress events using more than two possible truth values are provided later.
Finally, at step 2-6, the system 100 generates an alert of the trigger event 120. In some implementations, the system 100 produces the alert of the trigger event 120 via the alert interface 104. In some implementations, the alert interface 104 generates the alert of the trigger event 120 to inform aircraft flight crew, including those that may be on the aircraft. In some implementations, the alert interface 104 generates the alert of the trigger event 120 to inform personnel outside of the aircraft (e.g. air traffic controllers), and hence some form of transmission is performed. When the alert of the trigger event 120 is generated, there can be a relatively high level of confidence in the alert, and thus it may be possible for an effective response to be actioned. In this way, it may be possible to achieve a successful resolution.
In some implementations, the system 100 stores distress event data and the aircraft state data relating to the distress event, for example in the memory 105. In some implementations, the distress event data and the aircraft state data relating to the distress event are subjected to analysis and learning 130, with a view to updating the multi-valued logic classifier 101 as appropriate. This provides a form of feedback for the multi-valued logic classifier 101, whereby adjustment can be made based on the feedback to tweak performance. For example, if the trigger event is advisory of an actual distress event, the multi-valued logic classifier 101 can be adjusted if possible to increase sensitivity to detect the distress event earlier, such that the trigger event that is generated is advisory of pre-distress event, thereby providing time for corrective action to avoid or mitigate the distress event. In some implementations, the adjusting of the multi-valued logic classifier 101 is performed based on airframe knowledge and limit conditions 140. This can involve some input by a user, with use of inference for expert refining of distress calculations. However, other implementations are possible in which adjustments can be performed via intelligent learning algorithms.
The way in which the adjustment is performed can vary based on the multi-valued logic classifier 101. For instance, in the case of a fuzzy logic algorithm incorporating fuzzy rules that apply membership functions to the aircraft state data to produce the transformed state data, there can be an adjustment of the membership functions, in accordance with the distress event data and the aircraft state data. Also, in the case of an artificial neural network algorithm incorporating functions based on weighted combinations of the aircraft state data, the there can be an adjustment of the weighted combinations, in accordance with the distress event data and the aircraft state data.
Some implementations improve on detection by identifying and eliminating false-positives and returning a decimal number that represents an inference level of state of distress instead of a Boolean value. This real-time recorded value can be used for both a more robust in-flight triggering method for distress conditions as well as the post flight review of distress progression. This can increase confidence in the reliable measurement, detection and reporting of aircraft distress conditions and thus is an improvement over the conventional method.
The Boolean approach of the conventional method does not allow an assessment of the degree of distress, i.e.: the aircraft is either in distress or it is not. Using a fuzzy logic approach to characterize a degree of distress provides additional granularity with respect to the severity of a potential distress condition and can facilitate more event mitigation options.
Some implementations reliably determines the inferences of aircraft state of distress in real-time based on the capture of a redundant plurality of aircraft state parameters and the application of optimized fuzzy logic mathematics to compare said aircraft operating states against known aircraft system and airframe operating knowledge and conditions.
Some implementations can determine the distress inference of an aircraft as a function of both the immediate aircraft operating parameters and the airframe and system envelope parameters. Some implementations map aircraft operating parameters and expert knowledge provided by airframe experts thought the use of intelligent rules-based algorithms to derive aircraft distress interferences. These algorithms can include, but are not limited to, the use of fuzzy logic/artificial intelligence.
The use of a single source of sensor input has shown to be problematic in distress determination should said sensor input fail to provide reliable measurements. The use of redundant distress processing of the same aircraft data derived from different sources and subsequently compared in a voting scheme can increase confidence in the distress inference. Corroborating data obtained by a GNSS (global navigation satellite system) and IMU (inertial measurement unit) data sources that are independent of, and uninfluenced by, the aircraft provided data can further improve distress inference processing.
Some implementations provide subsequent recording of said calculated aircraft state of distress for later review and further detection optimization. This stored prior distressed inferences can be used for intelligent feedback to optimize both the fuzzy logic membership functions and analysis so as to further improve future distress conditions inference.
Some implementations use the real-time available distress inference for the trigger of distress notification in accordance with GADSS (Regulated Global Aeronautical Distress and Safety System) by the ICAO (International Civil Aviation Organization). Some implementations improve distress inference calculation by reducing false and nuisance reporting of distress conditions.
Some implementations reliably determine of aircraft state of distress in real-time based on the capture of redundant plurality of aircraft state parameters and application of expert knowledge algorithms that can compare said aircraft operating states against known airframe safe operating knowledge.
Some implementations provide for system operation validation through self testing of the hardware circuits and a validation of processing against inputs with a-prior known analysis output.
Further example details are provided in the sections that follow below. Although many of the examples generally focus on implementations with a fuzzy logic algorithm, it is to be understood that other algorithms such as an artificial neural network algorithm are possible and are within the scope of the disclosure. More generally, any suitable algorithm that provides for a multi-logic logic classifier for identifying distress events using more than two possible truth values can be implemented.
Referring now to
Referring now to
In some implementations, the membership functions and input signal conditioning can be modified by configuration data 430 provided by expert knowledge 450 of the parameter and airframe to which the processing is applied. In some implementations, the membership functions and input signal conditioning can be modified based on the outputs of the membership functions 440. This provides a form of feedback in which adjustment can be made to tweak performance as similarly described earlier with reference to
In some implementations, the fuzzy logic algorithm can use multiple membership functions, each of which can be tailored to provide a specific transformation of one of the real-world parameter values as appropriate with respect to the distress scenario being assessed. The transformation of each set can be a result of expert knowledge data that has been calculated for the specific airframe to which the system is applied. Again, the membership sets can include continuous values ranging from 0 to 1.
Referring now to
In some implementations, potential aircraft distress scenarios can be predetermined, and rules-based set operations can be applied to the natural language state parameter values to determine the inference of each distress scenario being tested. These rules can be assigned depending on the condition to be tested, the type of aircraft, the nominal operating parameters and its flight mission. The set operators can be natural language terms expressed as IF-THEN, OR, AND, NOT Rules and operate according to conditional membership statements that include fuzzy logic.
In some implementations, expert knowledge can be applied to the assessment of each parameter's excessive, normal or marginal membership value and its comparison to other values to determine the contribution to each distress scenario.
In some implementations, each distress processing module can independently operate on three sources of data: two from the aircraft MAUs; and one from internal sensors. For a distress inference to be valid, all valid (meaning non-faulted) sources must satisfy the scenario criteria. Determining fault status can be multifaceted:
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Each DT module 1010,1020 has an avionics interface 1011,1021 configured to communicate with MAUs (not shown) disposed in the aircraft and to receive data 1015,1025 generated by the MAUs relating to operational parameters of the aircraft. Each DT module 1010,1020 also has a processor 1012,1022 having safety critical processor event detection logic for processing the data 1015,1025 received from the MAUs using in-flight event detection and triggering criteria to produce scenario data and trigger data. Each DT module 1010,1020 also has a configuration interface 1013,1023 and a trigger logic and state information interface 1014,1024 for interfacing with the back plane board 1030.
The modem board 1040 has a scenario state storage 1045 for receiving scenario data and trigger data generated by the DT modules 1010,1020, a configuration interface 1046, and a trigger logic interface 1047 for interfacing with the back plane board 1030. The modem board 1040 also has a distress transmission processor 1044, a GPS receiver 1042, and a Satcom (satellite communications) modem 1043, which connect to RF (radio frequency) antennas 1048 for wireless communication. The modem board 1040 also has a maintenance interface 1041, which can connect to USB and/or Ethernet cables 1049 for maintenance purposes.
The back plane board 1030 provides protection circuitry, power regulation and distribution, and data communication. In some implementations, back plane board 1030 has connections 1031 for receiving 28V DC power from the aircraft, and aircraft emergency power as well. In some implementations, the system 1000 also has a battery 1050 for delivering power to the system 1000 via the back plane board 1030. The battery 1050 can be used in addition to, or instead of, the connections 1031.
Referring now to
The first DT module 1110 has fault detection logic 1112 that processes the data in stages: a first stage 1111A,1111B for sampling aircraft state data, a second stage 1112A,1112B for applying weights for distress event detection, and a third stage 1113A,1113B for triggering a distress event. The second DT module 1120 likewise has fault detection logic 1122 that processes the data in stages: a first stage 1121C,1121D for sampling aircraft state data, a second stage 1122C,1122D for applying weights for distress event detection, and a third stage 1123C,1123D for triggering a distress event.
Data generated by paths A, B, C and D are received by triggering logic 1114, which conducts a DT event vote on that data. If the event vote results in a passing vote, meaning a distress event has been detected, then a trigger event is generated by the triggering logic 1114. If the event vote results in a failed vote, then no trigger event is generated by the triggering logic 1114.
When a trigger event is generated by the triggering logic 1114, an alert of the trigger event is generated. There are many possibilities for the alert of the trigger event. In some implementations, the ADT module 1130 provides the trigger event to an ELT (emergency locator transmitter) 1161 for transmission. In some implementations, the ADT module 1130 provides the trigger event to ADT transmitter 1140, which includes a Satcom transmission system 1143, for transmitting the trigger event in a distress report 1162. The ADT transmitter 1140 also has power management systems 1150 and a service and memory storage system 1145. In some implementations, the ADT module 1130 provides the trigger event to a flight crew interface 1163 to inform the flight crew. In some implementations, the ADT module 1130 provides the trigger event to an ADS-B (automatic dependent surveillance-broadcast) transmission system for transmitting the trigger event (not shown). Other implementations are possible and are within the scope of the disclosure. For example, in another implementation, a cellular transmission system (not shown) is used to transmit the trigger event.
The systems 1000,1100 depicted in
Upon initial power up, the system 1100 can determine whether it was initiated with normal aircraft power or from emergency aircraft power. If the system has powered up with a power state fault, that is, powered up with emergency aircraft power, then the distress state is asserted and the triggers are sent. If the system has powered up without a power state fault, it can proceed to check Aircraft State interfaces and Logic circuits.
In some embodiments, hardware interface tests can be conducted both as loop-backs and cross-feeds for all signalling technologies. If the processing modules detect fault, the system can update logs and alert maintenance crew in addition to alerting the flight crew of the fault. The system can operate with one processing path in fault condition. Having both processing modules in fault is a system fail.
If the startup hardware system checks are successful, then the next stage is to validate whether the stored program logic for determining distress is valid (for example, whether the code matches checksum tests). In some embodiments, the system 1100 can have a database of predetermined parameters that can pertain to both distress and non-distress conditions. The system 1100 with a priori knowledge of the expected distress inferences can apply the database files to the redundant processing paths. In some implementations, a fault detection subsystem can compare calculated inferences, and can further assess the health of the system based on the expected known values. Processing paths not achieving the expected values can be placed in fault condition.
Any path found to be in fault, for either deficient hardware or software reasons, can be demerited from participating in the aircraft state of distress inference calculations.
To ensure the sampled aircraft state data is available and coming from reliable sources, the redundant processing paths can apply ‘marked data’ to the avionics data sources being monitored. Failure to detect the marked frames can result in a fault condition. The system can assess this condition as a disconnect or avionics bus failure.
Similar to power up testing described earlier, the system 1100 can continuously check each processing path for its ability to calculate a correct distress inference from a known database of aircraft parameters. The continuous version of the test can proceed with the (marked) parameters being injected into the processing path under evaluation. As the data can provide or create an inference known a priori, the processing path under test can be assessed for its ability to achieve the expected inference value. Processing Paths not achieving said inference can be marked as being in fault. In a fault condition, the processing path is excluded from the inference calculations. In other words, the injected parameters are known ahead of time to be expected to result in a distress state, therefore, the distress state triggering is ignored by the system, or causes a fault state for the processing path if it is not observed as expected.
Referring now to
The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the embodiments described herein.
Embodiments implemented in computer software can be implemented in software, firmware, middleware, microcode, hardware description languages, or any combination thereof. A code segment or machine-executable instructions can represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment can be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. can be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
The actual software code or specialized control hardware used to implement these systems and methods is not limiting of the embodiments described herein. Thus, the operation and behavior of the systems and methods were described without reference to the specific software code being understood that software and control hardware can be designed to implement the systems and methods based on the description herein.
When implemented in software, the functions can be stored as one or more instructions or code on a non-transitory computer-readable or processor-readable storage medium. The steps of a method or algorithm disclosed herein can be embodied in a processor-executable software module, which can reside on a computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable media includes both computer storage media and tangible storage media that facilitate transfer of a computer program from one place to another. A non-transitory processor-readable storage media can be any available media that can be accessed by a computer. By way of example, and not limitation, such non-transitory processor-readable media can include RAM (random access memory), ROM (read only memory), EEPROM (electrically erasable programmable read-only memory), CD-ROM (compact disc read-only memory) or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other tangible storage medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer or processor. Disk and disc, as used herein, include CD (compact disc), laser disc, optical disc, DVD (digital versatile disc), floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of a method or algorithm can reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable medium and/or computer-readable medium, which can be incorporated into a computer program product.
Numerous modifications and variations of the present disclosure are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the disclosure may be practised otherwise than as specifically described herein.
This patent application claims priority to U.S. Provisional Patent Application No. 62/881,873 filed on Aug. 1, 2019, the entire disclosure of which is incorporated by reference.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/CA2020/051058 | 7/31/2020 | WO | 00 |
Number | Date | Country | |
---|---|---|---|
62881873 | Aug 2019 | US |