Patent Description:
Engines may be controlled using logic-based computerized control systems, sometimes referred to as electronic engine controllers. These systems may receive inputs from operators and/or from sensors, in the form of analog or digital signals, and process the signals to interpret requests from the operators. However, in some cases these inputs can require correction before they are provided for use by the control system.

<CIT> discloses topology-inspired neural network autoencoding for electronic system fault detection.

In accordance with a first aspect, there is provided a method for sensor fault management as set forth in claim <NUM>.

In an embodiment of the above, the method further comprises providing the fault management tool to the controller.

In a further embodiment of any of the above, the fault management tool is applicable to a plurality of versions of an engine associated with the controller.

In a further embodiment of any of the above, the fault management tool is applicable to at least two engine types.

In a further embodiment of any of the above, obtaining the plurality of potential faults comprises obtaining, for at least some of the potential faults, more than one sensor state associated with different fault detection parameters.

In a further embodiment of any of the above, associating the severity levels to each of the plurality of potential faults comprises associating a null severity level with a no-fault state for the sensor.

In a further embodiment of any of the above, the method further comprises obtaining at least one additional potential fault, associating an additional severity level to each of the at least one additional potential fault, and updating the hierarchy with the at least one additional potential fault.

In a further embodiment of any of the above, the method further comprises obtaining an indication of at least one additional accommodation approach and updating the hierarchy to associate the at least one additional accommodation approach with at least one of the plurality of potential faults.

In a further embodiment of any of the above, associating the at least one accommodation approach with the plurality of potential faults comprises associating, with more than one of the potential faults, at least one common accommodation approach of the at least one accommodation approach.

In accordance with another aspect, there is provided a system for sensor fault management as set forth in claim <NUM>.

In an embodiment of the above, the program instructions are further executable for providing the fault management tool to the controller.

In a further embodiment of any of the above, the program instructions are further executable for obtaining at least one additional potential fault, associating an additional severity level to each of the at least one additional potential fault, and updating the hierarchy with the at least one additional potential fault.

In a further embodiment of any of the above, the program instructions are further executable for obtaining an indication of at least one additional accommodation approach and updating the hierarchy to associate the at least one additional accommodation approach with at least one of the plurality of potential faults.

Features of the systems, devices, and methods described herein may be used in various combinations, in accordance with the embodiments described herein.

When a sensor or other input device provides faulty information to a controller of an engine, various undesirable outcomes can occur. In some cases, the engine can be commanded by the controller to operate under non-optimal conditions, which can result in inefficient operation or increased wear-and-tear on engine components. In some other cases, the engine can suffer damage, or catastrophic failure can occur. As a result, various measures to detect and/or accommodate for faulty inputs to a controller can be implemented.

Fault management approaches (also sometimes termed "fault detection and accommodation" or "signal selection") involve two operations, which can be performed by a fault management tool. First, signals incoming to a controller are intercepted to perform fault detection; that is to say, to determine whether any signals are likely to be faulty. Second, when a faulty signal is detected, fault accommodation is performed; that is to say, one or more countermeasures are implemented to replace or correct the faulty signal with a corrected signal, which is then provided to the controller. When valid (i.e., non-faulty) signals are received at the fault management tool, they can simply be passed on to the controller absent any correction.

For ease of understanding, the present disclosure describes fault detection and accommodation approaches within the context of an engine, as illustrated in <FIG>. For the purposes of illustration, <FIG> depicts a gas turbine engine <NUM> of a type typically provided for use in subsonic flight. It should be noted, however, that the present disclosure could also be provided for other types of engines, as well as for any other type of device or system in which fault detection and/or accommodation could be used to mitigate the effects of faulty signals on control of the device or system.

With continued reference to <FIG>, the engine <NUM> comprises an inlet <NUM> through which ambient air is propelled, a compressor section <NUM> for pressurizing the air, a combustor <NUM> in which the compressed air is mixed with fuel and ignited for generating an annular stream of hot combustion gases, and a turbine section <NUM> for extracting energy from the combustion gases. The engine <NUM> can be controlled by way of a controller <NUM>, which can be communicatively coupled to the engine <NUM> using any suitable communication paths, and can control any suitable aspects of the operation of the engine <NUM>.

The turbine section <NUM> comprises a compressor turbine <NUM>, which drives the compressor assembly and accessories, and at least one power or free turbine <NUM>, which is independent from the compressor turbine <NUM> and rotatingly drives a rotor shaft (also referred to herein as a propeller shaft or an output shaft) <NUM> about a propeller shaft axis 'A' through a reduction gearbox (RGB) <NUM>. Rotation of the output shaft <NUM> is facilitated by one or more bearing assemblies, which can be disposed within the RGB <NUM> or at any other suitable location. Hot gases may then be evacuated through exhaust stubs <NUM>. The gas generator of the engine <NUM> comprises the compressor section <NUM>, the combustor <NUM>, and the turbine section <NUM>.

A rotor, in the form of a propeller <NUM> through which ambient air is propelled, is hosted in a propeller hub <NUM>. The rotor may, for example, comprise the propeller <NUM> of a fixed-wing aircraft, or a main (or tail) rotor of a rotary-wing aircraft such as a helicopter. The propeller <NUM> may comprise a plurality of circumferentially-arranged blades connected to a hub by any suitable means and extending radially therefrom. The blades are also each rotatable about their own radial axes through a plurality of blade angles, which can be changed to achieve modes of operation, such as feather, full reverse, and forward thrust.

The engine <NUM> can be provided with one or more sensors <NUM>, which can be disposed at various locations throughout the engine <NUM>, and can measure any suitable information about the engine <NUM>. For example, the sensors <NUM> can include one or more temperature sensors, one or more pressure sensors, one or more angular rotation sensors, one or more torque sensors, or the like. The controller <NUM> is coupled to the sensors <NUM>, which provide the controller <NUM> with various information about the operating conditions of the engine <NUM>. In addition, the controller <NUM> can be coupled to a variety of input device <NUM> via which an operator of the engine <NUM> can provide commands to the controller <NUM>. The input devices <NUM> can include levers, dials, switches, sticks, computing devices, keyboards, mice, touch interfaces, gamepads, or the like.

With reference to <FIG>, a state diagram <NUM> for a sensor, for instance one of the sensors <NUM>, is illustrated. The sensor <NUM> can operate in one of three states: a healthy state <NUM>, a "detected" state <NUM>, and a "latched" state <NUM> (collectively termed "the states"). In the healthy state <NUM>, the sensor <NUM> is functioning correctly and producing valid information. In the detected state <NUM>, information from the sensor <NUM> are found to include possible faults, but failure of the sensor <NUM> is not yet confirmed. In the latched state <NUM>, the sensor <NUM> is confirmed to have failed. In some cases, returning to the healthy state <NUM> from the latched state <NUM> requires a reset of the sensor <NUM>, for instance powercycling or the like.

Transition between the states <NUM>, <NUM>, <NUM> can occur according to the pathways illustrated in the state diagram <NUM>. Transition from the healthy state <NUM> to the detected state <NUM> occurs when the sensor <NUM> experiences a fault with a non-zero latch time. Transition from the detected state <NUM> to the healthy state <NUM> can occur if the sensor <NUM> is provided with self-resetting capabilities.

Transition from the detected state <NUM> to the latched state <NUM> occurs when the latch time for a particular fault is exceeded. For instance, a predetermined latch time can be set for a particular fault, and the fault is said to be latched once the latch time is exceeded. The sensor <NUM> cannot transition from the latched state <NUM> to the detected state <NUM>, as the latched state <NUM> is a confirmation of a fault detected at the detected state <NUM>.

In some embodiments, transition from the healthy state <NUM> to the latched state <NUM> occurs when a fault is specified with a zero-value latch time. A sensor <NUM> in the latched state <NUM> can transition back to the healthy state <NUM> if the sensor <NUM> is provided with self-healing capabilities, or following a reset of the sensor <NUM>.

It should be noted that the description of the state diagram <NUM> is provided in general terms, and other approaches for transitioning between the states <NUM>, <NUM>, <NUM> are also considered.

With reference to <FIG>, in order to track the state of the sensor <NUM>, and to properly mitigate faulty states for the sensors <NUM>, a fault management tool <NUM> can be provided. For example, the fault management tool <NUM> monitors the information provided by the sensors <NUM> to detect when the sensors <NUM> enter a faulty state. The fault management tool <NUM> can also implement countermeasures to correct for faulty information provided by the sensors <NUM>.

For the purposes of illustration, <FIG> illustrates the engine <NUM> including a number of sensors <NUM>: a temperature sensor <NUM>, measuring a temperature T°<NUM>, a temperature sensor <NUM> measuring a main oil temperature (MOT), and a pressure sensor <NUM> measuring an ambient pressure Pamb. It should be recognized that the engine <NUM> can include any number of other sensors, including speed sensors, torque sensors, blade angle sensors, position sensors, and the like. Each of the sensors <NUM> is associated with a respective input at the controller <NUM>: the temperature sensor <NUM> with the T°<NUM> input <NUM>, the temperature sensor <NUM> with the MOT input <NUM>, the pressure sensor <NUM> with the Pamb input <NUM>, and the like.

The fault management tool <NUM> can also be used to detect and accommodate faults from other types of signals, for example airframe signals <NUM> from an airframe <NUM> to which the engine <NUM> is coupled. The airframe signals <NUM> can include signals provided by an operator of the engine <NUM> and/or the airframe <NUM>, for instance a pilot, via various input devices, for instance the input devices <NUM> described with reference to <FIG>. In the embodiment illustrated in <FIG>, the signals <NUM> include a start request. The airframe signals <NUM> can also include additional sensors separate from those included within the engine <NUM>. Other types of signals are also considered. Similarly, the signals <NUM> are associated with respective inputs at the controller <NUM>: a start request signal <NUM> is associated with a start request input <NUM>, and a feedback signal <NUM> is associated with a feedback input <NUM>. It should be noted that the airframe signals <NUM> are still considered to be provided by sensors, as sensors are used to translate the commands provided via the input devices <NUM> into usable information.

The fault management tool <NUM> is coupled between the controller <NUM> and the inputs to the controller <NUM>: in the embodiment illustrated in <FIG>, the inputs to the controller <NUM> are the sensors <NUM> from the engine <NUM>, and the airframe signals <NUM> from the airframe <NUM>. The fault management tool <NUM> receives the information produced by the sensors <NUM> and the airframe signals <NUM> in order to perform fault detection and fault accommodation. The fault management tool <NUM> then passes on information to the controller <NUM>, which can be the originally-received information from the sensors <NUM> and the airframe signals <NUM>, or information which is the result of one or more accommodation approaches. It should be noted that in some embodiments, additional elements can be present between the between the controller <NUM> and the inputs thereto, including various signal processing and conversion tools, filters, and the like.

The fault management tool <NUM> is itself composed of a number of independent units (collectively termed "the units") associated with different types of information provided by the inputs <NUM>, <NUM>. In the embodiment illustrated in <FIG>, the fault management tool <NUM> includes a temperature unit <NUM>, associated with temperature sensors, for instance the temperature sensors <NUM>, <NUM>; a pressure unit <NUM>, associated with pressure sensors; for instance the pressure sensor <NUM>; and a speed/rotation unit <NUM>, associated with speed and rotation sensors, which can include torque sensors, position sensors, and the like. The fault management tool <NUM> also includes a toggle switch unit <NUM>, associated with toggle switches (i.e., switches having four states), and a momentary switch units <NUM>, associated with momentary switches (i.e., switches having two states). The toggle switch unit <NUM> and the momentary switch unit <NUM> can be used, for instance, with digital inputs. In some embodiments, separate fault management tools <NUM> can be provided for analog and digital inputs. Digital inputs can include various serial and parallel input streams, including ARINC, CANbus, UART, Ethernet, and the like, and can be used with wired or wireless communication paths.

In some embodiments, the fault management tool <NUM> may have fewer units, with one or more of the units being integrated to provide functions that may in other embodiments be provided by more than one unit. In some embodiments, the fault management tool <NUM> may be provided as a single unit configured to perform the functions of that fault management tool <NUM>, such as the functions of the present embodiment for example.

As illustrated in <FIG>, the temperature unit <NUM> is provided with two modules: a fault detection module <NUM>, and a fault accommodation module <NUM>. For simplicity, the remaining units <NUM>, <NUM>, <NUM>, and <NUM> are not shown in <FIG> as being provided with similar fault detection and fault accommodation modules, but it should be understood that they are similarly composed. In some embodiments, the units are composed of multiple pairs of fault detection and fault accommodation modules, for instance one pair for single-channel sensors, one pair for dual-channel sensors, one pair for quad-channel sensors, and the like.

In operation, information from the temperature sensors <NUM>, <NUM>, for example the temperature sensor <NUM>, is intercepted by the fault management tool <NUM>, and specifically by the fault detection module <NUM> of the temperature unit <NUM>. The fault detection module <NUM> uses various algorithms and the like to determine whether the information provided by the temperature sensor <NUM> is faulty. When the information provided by the temperature sensor <NUM> is found not to be faulty, the fault detection module <NUM> can pass the information to the fault accommodation module <NUM> for transmission to the controller <NUM>. Alternatively, the fault detection module <NUM> can pass the information directly to the controller <NUM>.

When the information provided by the temperature sensor <NUM>, is found to be faulty, the fault detection module <NUM> informs the fault accommodation module <NUM> that the temperature sensor <NUM> is faulty, and the fault accommodation module <NUM> implements one or more accommodation approaches to correct for the faulty temperature sensor <NUM>. The temperature unit <NUM> then, by way of the fault accommodation module <NUM>, provides corrected information to the controller <NUM>.

In some embodiments, different units are provided as part of the fault management tool <NUM> for different kinds of sensors. The different units can serve to perform fault detection and/or accommodation in different ways for the different kinds of sensors. For instance, a first temperature unit <NUM> is provided for single-channel temperature sensors, and a second temperature unit <NUM> is provided for dual-channel temperature sensors. In some other instances, a first pressure unit <NUM> is provided for analog pressure sensors, and a second pressure unit <NUM> is provided for digital pressure sensors.

In some embodiments, the fault management tool <NUM> provides other information to the controller <NUM> beyond the corrected information. For example, the fault management tool <NUM> provides a "signal status" indication, which indicates to the controller <NUM> whether a particular signal is provided by a sensor which is in the healthy state, the detected state, or the latched state of <FIG>. In another example, the fault management tool <NUM> provides an "accommodation source" indication, which indicates to the controller the origin of corrected information, when provided.

Fault detection and accommodation tools like the fault management tool <NUM> may, in some applications, require detailed instructions from specialized engineers to produce. In some cases, engineering teams prepare lengthy textual descriptions detailing different types of faults for various sensors, algorithms for fault detection, and different approaches for fault accommodation. Changes to fault management systems may require complete overhauls of an existing fault management system. In addition, a new textual description for fault management may need to be produced every time a new engine <NUM> or airframe <NUM> is designed, even if the same sensors are used for the same purpose. A more modular and portable approach for designing the fault management tool <NUM> could provide both reduced labour and design costs.

With reference to <FIG>, there is illustrated an architecture for fault management tools, such as the fault management tool <NUM>. The architecture illustrated in <FIG> provide a modular and reusable tool for implementing fault management, which can be designed once, implemented across a variety of systems, and readily modified when necessary.

In <FIG>, a table <NUM> for a fault detection tool is illustrated. The table <NUM> can be associated with a particular type of sensor or input type, for instance a single-channel temperature sensor. Other signals, for instance a dual-channel temperature sensor, or a pressure sensor, or a feedback signal, would be associated with a separate table <NUM>.

Each of the rows <NUM> in the table <NUM> represents a different type of potential fault for the sensor or input type associated with the table <NUM>. In the embodiment illustrated in <FIG>, the rows <NUM> include a first row for a "threshold" fault, and a second row for a "latch time" fault. Columns <NUM> of the table <NUM> represent different parameters for each of the potential faults. For example, a column specifies a range of acceptable values from a sensor, outside of which a "range fault" is detected. In another example, a column specifies a maximum rate of change per second for acceptable values from a sensor, outside of which a "rate fault" is detected. Other examples include an "interface fault" for faults flagged by the controller <NUM> and "validity faults" for when a value from one sensor or input type differs from values from other similar sensors or input types beyond a predetermined tolerance. Other faults are also considered, such as "cross-channel" or "cross-engine" faults when similar measurements are acquired on different channels, or across different engines, or "stuck input" faults if values from a momentary switch are maintained in a momentary state for longer than a predetermined time. The entries in the table <NUM> can be populated using information obtained from a database or other data store, using the output of an artificial intelligence or the like, or using input obtained from an operator or manufacturer of the engine <NUM>, or of the sensor or input device associated with the table <NUM>.

In <FIG>, a table <NUM> for a fault accommodation tool is illustrated. The table <NUM> can also be associated with a particular type of sensor or input type; for example, the table <NUM> can be used with analog signals. Each of the rows <NUM> in the table <NUM> represents a different type of potential fault for the sensor or input type associated with the table <NUM>. In the embodiment illustrated in <FIG>, the rows <NUM> a first pair of rows associated with a "signal loss" fault and a second pair of rows associated with a "cross-channel" fault, with separate rows for latched and detected sensor states, as per <FIG> hereinabove. The rows <NUM> also include a "no-fault" row, which is associated with a healthy operating state of the sensor or input type. In some embodiments, the "no-fault" row is associated with a null severity level.

Columns <NUM> represent different fault accommodation approaches which can be used to accommodate for the potential faults listed in the rows <NUM>. The entries in the table <NUM> are used to express whether a particular fault accommodation approach can be used for a particular potential fault. For instance, the first row of the rows <NUM>, which is the row associated with "Fault #<NUM>", indicates "N/A" for the column entries associated with "Option #<NUM>", "Option #<NUM>", "Option #<NUM>", and "Option #<NUM>". This indicates that these accommodation approaches are not applicable. The "Option #<NUM>" and "Option #<NUM>" column entries indicated with a checkmark symbol, signifying that the accommodation approaches of those columns can be used as valid accommodation approaches. The "Option #<NUM>" and "Option #<NUM>" column entries are left blank, indicating that these accommodation approaches are not valid accommodation approaches for the latched version of Fault #<NUM>.

The entries in the table <NUM> can be populated using information obtained from a database or other data store, using the output of an artificial intelligence or the like, or using input obtained from an operator or manufacturer of the engine <NUM>, or of the sensor or input device associated with the table <NUM>. It should be noted that the same accommodation approach can be used for multiple potential faults. Some example faults include "signal loss" and "cross channel" faults, and the like. Some example accommodation approaches include "default value", "local average", "local channel", "remote channel", "alternate value", "last good value", "high value", "low value", and the like.

In some embodiments, the potential faults listed in the rows <NUM> are ranked or otherwise disposed in a hierarchy based on a severity level of the potential faults. For instance, the most severe potential fault is listed in the top-most of the rows <NUM>. The severity levels can be obtained from a database or other data store, using the output of an artificial intelligence or the like, or using input obtained from an operator or manufacturer of the engine <NUM>, or of the sensor or input device associated with the table <NUM>. Similarly, the accommodation approaches listed in the columns <NUM> can be presented in a ranking indicative of which of the accommodation approaches to prioritize. In some embodiments, an accommodation approach using a sensor or input type which has been detected as faulty or latched can be prioritized over a sensor or input type which was previously detected as faulty or latched but since self-healed.

In some cases, the table <NUM> includes one or more rows <NUM> which are included by default in any embodiment of the table <NUM>. For instance, the table <NUM> is designed to always include a "no-fault" row, since the fault accommodation tool should always include the case where the sensor or input type is functioning correctly. Alternatively, or in addition, the table <NUM> includes one or more columns <NUM> which are included by default in any embodiment of the table <NUM>. For instance, the table <NUM> is designed to always include a "last good" column and/or a "default value" column, since the fault accommodation tool should always include at least one accommodation approach which can be used by default where none other is available to choose (the "last good" and "default value" columns can be, for example, Options #<NUM> and #<NUM>). Other rows and/or columns which are included by default are considered.

In <FIG>, a table <NUM> for a fault accommodation tool is illustrated. The table <NUM> can also be associated with a particular type of sensor or input type; for example, the table <NUM> can be used with digital signals. Rows <NUM> and columns <NUM> are similar to the rows <NUM> and columns <NUM> of table <NUM>.

With additional reference to <FIG>, once the tables <NUM>, <NUM>, and/or <NUM> are filled, they can be used as the basis for generating different units of the fault management tool <NUM> of <FIG>. For example, an embodiment of the table <NUM> associated with a single-channel temperature sensor can be used to generate the fault detection module <NUM>, and an embodiment of the table <NUM> associated with a single-channel temperature sensor can be used to generate the fault accommodation module <NUM>. The tables <NUM>, <NUM> can be provided to a software suite which can automatically generate the fault detection and accommodation modules <NUM>, <NUM> based thereon. In embodiments in which sensors <NUM> are used in a dual-channel configuration, the same embodiments of the tables <NUM>, <NUM>, can be used to generate the fault detection and accommodation modules <NUM>, <NUM> for both channels.

When changes to the fault management tool <NUM> are required, for instance due to regulatory changes or engineering improvements, the tables <NUM>, <NUM> can be updated to include additional rows and/or columns, or to vary the entries in the tables <NUM>, <NUM>, and the fault detection module and/or the fault accommodation module <NUM>, <NUM> can be regenerated. In addition, because the fault management tool <NUM> may be developed independently from the controller <NUM>, the engine <NUM>, and/or the airframe <NUM>, it may be applied to a plurality of versions of the controller <NUM>, to a plurality of versions of the engine <NUM> and/or the airframe <NUM>, and/or to a plurality of different types of engines <NUM> and/or airframes <NUM>.

With reference to <FIG>, there is illustrated a method <NUM> for generating a fault management tool for a sensor, for instance for one of the sensors <NUM>, or for any other suitable input type, associated with the engine <NUM> or the airframe <NUM>. At step <NUM>, a plurality of potential faults, associated with the sensor <NUM>, is obtained. The list of potential faults can be obtained from a database, as an output of an artificial intelligence, or based on inputs from a user.

Optionally, at step <NUM>, severity levels for the plurality of potential faults are obtained. The severity levels indicate which of the plurality of potential faults are more severe than others, and can be based on the likelihood of adverse outcomes for the engine <NUM> or the airframe <NUM>. In some embodiments, the severity levels are obtained substantially concurrently with the plurality of potential faults at step <NUM>.

At step <NUM>, accommodation approaches are associated with the plurality of potential faults. The accommodation approaches can be any suitable approaches, and can be obtained from a database, as an output of an artificial intelligence, or based on inputs from a user.

At step <NUM>, the severity levels are associated to the plurality of potential faults to produce a hierarchy of potential faults. The hierarchy of potential faults can be used to indicate an order in which faults should be accommodated when more than one fault occurs concurrently.

At step <NUM>, a fault management tool is generated based on the hierarchy, for instance the fault management tool <NUM>. The fault management tool <NUM> defines a framework implementable by a controller, for instance the controller <NUM>, for accommodating faulty behaviour of the sensor <NUM> by following the accommodation approaches of the hierarchy for the plurality of potential faults. The fault management tool <NUM> can then be used in conjunction with the controller <NUM> to perform fault management for the controller <NUM>.

Optionally, at step <NUM>, the fault management tool <NUM> is provided to the controller <NUM>, for example by downloading the fault management tool <NUM> into the controller <NUM>. The fault management tool <NUM> can be downloaded into the controller <NUM> over any suitable wired or wireless communication paths, as appropriate.

In some embodiments, the fault management tool <NUM> is embodied as a software module or other software tool, and be composed of computer-readable instructions which, when read by a processor or other processing unit, cause a computer to implement the fault detection and accommodation approaches detailed therein. In some other embodiments, the fault management tool <NUM> is embodied on a computer-readable medium storing the aforementioned computer-readable instructions. For example, the fault management tool <NUM> can be a memory card or other storage device which can be communicatively coupled to a larger computing system. In some further embodiments, the fault management tool <NUM> is composed of one or more physical computing devices, including ASICs, FPGAs, embedded computers, and the like, and can be communicatively coupled between the engine <NUM>, the airframe <NUM>, and/or the controller <NUM>. Other embodiments are also considered.

With reference to <FIG>, the method <NUM> may be implemented using a computing device <NUM> comprising a processing unit <NUM> and a memory <NUM> which has stored therein computer-executable instructions <NUM>. The processing unit <NUM> may comprise any suitable devices configured to implement the system such that instructions <NUM>, when executed by the computing device <NUM> or other programmable apparatus, may cause the functions/acts/steps of the method <NUM> as described herein to be executed.

The memory <NUM> may include a suitable combination of any type of computer memory that is located either internally or externally to device, for example random-access memory (RAM), read-only memory (ROM), compact disc read-only memory (CDROM), electro-optical memory, magneto-optical memory, erasable programmable read-only memory (EPROM), and electrically-erasable programmable read-only memory (EEPROM), Ferroelectric RAM (FRAM) or the like. In some embodiments, the computing device <NUM> can be implemented as part of a full-authority digital engine controls (FADEC) or other similar device, including electronic engine control (EEC), engine control unit (ECU), and the like.

With reference to <FIG>, there is illustrated a system <NUM> for generating a fault management tool, for instance the fault management tool <NUM>. The system <NUM> is composed of a hierarchy module <NUM>, and a tool generation module <NUM>.

The hierarchy module <NUM> is configured for obtaining a plurality of potential faults associated with a sensor or other input type, for instance the sensor <NUM>, in accordance with step <NUM> of the method <NUM>. The hierarchy module <NUM> is optionally configured for obtaining severity parameters associated with the plurality of potential faults, in accordance with step <NUM>. The plurality of potential faults and the severity parameters can be obtained via any suitable source, as described hereinabove.

The hierarchy module <NUM> is also configured for associating accommodation approaches with the plurality of potential faults, in accordance with step <NUM>, and for associating severity levels to the plurality of potential faults to produce a hierarchy of potential faults, in accordance with step <NUM>. Once the hierarchy of potential faults is produced, the hierarchy module <NUM> can provide the hierarchy to the tool generation module <NUM>.

The tool generation module <NUM> is configured for generating the fault management tool <NUM> based on the hierarchy for a controller associated with the sensor <NUM>, for instance the controller <NUM>. The fault management tool <NUM> defines a framework implementable by the controller <NUM> for accommodating faulty behaviour of the sensor <NUM> by following the accommodation approaches of the hierarchy for the plurality of potential faults. The tool generation module <NUM> can then provide the fault management tool <NUM> to the controller <NUM>. For example, the fault management tool <NUM> can be downloaded into the controller <NUM>.

The methods and systems described herein may be implemented in a high level procedural or object oriented programming or scripting language, or a combination thereof, to communicate with or assist in the operation of a computer system, for example the computing device <NUM>. Alternatively, the methods and systems may be implemented in assembly or machine language. The language may be a compiled or interpreted language. Program code for implementing the methods and systems for detection may be stored on a storage media or a device, for example a ROM, a magnetic disk, an optical disc, a flash drive, or any other suitable storage media or device. The program code may be readable by a general or special-purpose programmable computer for configuring and operating the computer when the storage media or device is read by the computer to perform the procedures described herein. Embodiments of the methods and systems may also be considered to be implemented by way of a non-transitory computer-readable storage medium having a computer program stored thereon. The computer program may comprise computer-readable instructions which cause a computer, or in some embodiments the processing unit <NUM> of the computing device <NUM>, to operate in a specific and predefined manner to perform the functions described herein.

Claim 1:
A method for sensor fault management, comprising:
obtaining a plurality of potential faults associated with a sensor (<NUM>);
associating accommodation approaches with the plurality of potential faults;
associating severity levels to the plurality of potential faults to produce a hierarchy of potential faults; and
generating a fault management tool (<NUM>) based on the hierarchy, the fault management tool (<NUM>) defining a framework implementable by a controller (<NUM>) associated with the sensor (<NUM>) for accommodating faulty behaviour of the sensor (<NUM>) by following the accommodation approaches of the hierarchy for the plurality of potential faults,
characterized in that
the method comprises providing a table (<NUM>, <NUM>) for the fault management tool (<NUM>), wherein each row (<NUM>, <NUM>) of the table (<NUM>, <NUM>) represents a different type of potential fault, columns (<NUM>, <NUM>) in the table (<NUM>, <NUM>) represent different fault accommodation approaches to accommodate the potential faults listed in the rows (<NUM>, <NUM>), the potential faults listed in the rows (<NUM>, <NUM>) being disposed in a hierarchy based on severity levels of the potential faults, the accommodation approaches listed in the columns (<NUM>, <NUM>) being presented in a ranking indicative of which of the accommodation approaches to prioritise.