Enhanced anomaly prediction and management in real-time safety-critical embedded applications

Abstract

This invention, entitled "Enhanced Anomaly Prediction and Management in Real-Time Safety-Critical Embedded Applications," provides an intelligent anomaly handling system for safety-critical real-time systems. The system is configured to: receive multiple parameters at multiple nodes in a real-time execution path; analyze the received parameters using a trained anomaly handling model, wherein machine learning techniques are used to train the trained anomaly handling model to learn critical execution paths and / or critical parameter ranges at critical nodes, wherein the critical parameter ranges include learned thresholds at the nodes; calculate the failure probability at the critical nodes using the trained anomaly handling model; compare the failure probability at the critical nodes with the learned thresholds at the nodes; and take proactive actions in real-time to prevent failures when the failure probability at a node exceeds the learned thresholds at the node.

Description

Technical Field

[0001] This invention relates generally to embedded applications, and more specifically to systems and methods for real-time anomaly prediction and avoidance in embedded applications. Background Technology

[0002] Various applications, such as avionics systems with control applications, possess a wealth of characteristics and complex computational and timing requirements. Due to the complexity of their implementations and dependencies on multiple interconnected data, it is often difficult to predict every execution path that could lead to unstable behavior. During the development and testing phases, avionics control application implementations are exposed to extreme scenarios to reveal potential faults; however, due to the vast number of permutations and combinations that can lead to variations within the application, the dynamics and constraints of avionics control applications remain difficult to analyze when exposed to real-world environments.

[0003] For example, the Flight Management System (FMS) is a complex real-time airborne system within the aircraft cockpit that receives, computes, and transmits data to multiple computing systems and sensor sources. During the design or testing phases, it is difficult to identify all critical issues through modeling and simulation. Therefore, anomalies may occur during operational use, and when anomalies occur, anomaly handling recovery mechanisms can be used to help the FMS recover from them. Anomaly handling might involve causing the FMS to execute a predefined escape route, where the FMS shuts itself down and attempts to return to a previously defined, older state. This could result in the FMS being unavailable for a period of time.

[0004] Currently, recovery mechanisms are reactive. That is, after an error occurs and the application propagates to an execution branch (where the application cannot continue any further), the recovery mechanism begins to attempt to return the application to a reasonable operational state. Recovery mechanisms may involve suppressing application usage for an extended period during the recovery attempt and may fail to successfully return the application to a usable state. Recovery mechanisms may also not always be successful, as recovery can be initiated when the application is in an unstable state.

[0005] Therefore, it is desirable to provide a non-responsive or proactive exception handling and recovery system that can prevent applications from being unavailable for extended periods. Furthermore, other desirable features and characteristics of the invention will become apparent from the following detailed description and the appended claims, taking into account the accompanying drawings and the foregoing technical and background information. Summary of the Invention

[0006] This summary is provided to describe selected concepts in a simplified form, which are further described in the detailed embodiments. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to help determine the scope of the claimed subject matter.

[0007] An intelligent anomaly handling system for a safety-critical real-time embedded system is provided. The system is configured to: receive multiple parameters at multiple nodes in a real-time execution path; analyze the received parameters using a trained anomaly handling model, wherein machine learning techniques are used to train the trained anomaly handling model to learn critical execution paths and / or critical parameter ranges at critical nodes, wherein the critical parameter ranges include learned thresholds at the nodes; calculate the failure probability at the critical nodes using the trained anomaly handling model; compare the failure probability at the critical nodes with the learned thresholds at the nodes; and take proactive actions in real time to prevent failures from occurring when the failure probability at the nodes exceeds the learned thresholds at the nodes.

[0008] A method is provided for a processor implementation for handling anomalies in a safety-critical real-time system of an aircraft. The method includes: receiving multiple parameters at multiple nodes in a real-time execution path of the safety-critical aircraft system; analyzing the received parameters using a trained anomaly handling model for the safety-critical aircraft system, wherein machine learning techniques are used to train the trained anomaly handling model to learn critical execution paths and / or critical parameter ranges at critical nodes, wherein the critical parameter ranges include learned thresholds at the nodes; calculating a failure probability at the critical nodes using the trained anomaly handling model; comparing the failure probability at the critical nodes with the learned thresholds at the nodes; and taking proactive actions in real time to prevent a failure from occurring when the failure probability at the node exceeds the learned thresholds at the node.

[0009] Furthermore, other desirable features and characteristics will become apparent from the following detailed description and the appended claims, taking into account the accompanying drawings and the foregoing background art. Attached Figure Description

[0010] The invention will now be described with reference to the following figures, wherein similar numbers denote similar elements, and wherein:

[0011] Figure 1 These are schematic diagrams based on some implementation schemes, which provide an exemplary graphical representation of a multi-branch execution path in an exemplary software application;

[0012] Figure 2 This is a block diagram of an exemplary computing environment according to some implementation schemes. The exemplary computing environment includes an exemplary system for training and operating an anomaly handling model, which is configured to identify critical nodes in the software execution path, determine in real time the parameters at the critical nodes in the software execution path, whether the probability is high enough to cause the software to go to a default state, and take proactive corrective actions to prevent the occurrence of fault states.

[0013] Figure 3A This is a block diagram illustrating the functionality of an example avionics system according to some implementation schemes;

[0014] Figure 3B This is a block diagram illustrating the functionality of an exemplary avionics system 310 according to some embodiments, which has been modified to include an intelligent anomaly handling model; and

[0015] Figure 4 This is a process flowchart illustrating an exemplary process 400 for handling anomalies in a safety-critical real-time system according to some implementation schemes. Detailed Implementation

[0016] The following detailed descriptions are merely illustrative in nature and are not intended to limit applications and uses. Furthermore, they are not intended to be limited by any express or implied theory presented in the foregoing technical fields, background art, summary of the invention, or the following detailed descriptions. As used herein, the term "module" means any hardware, software, firmware, electronic control components, processing logic, and / or processor device, individually or in any combination, including but not limited to: application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), electronic circuits, processors (shared, dedicated, or grouped) and memories executing one or more software or firmware programs, combinational logic circuits, and / or other suitable components providing the aforementioned functionality.

[0017] This document describes embodiments of the present disclosure in terms of functional and / or logical block components and various processing steps. It should be understood that such block components can be implemented by any number of hardware, software, and / or firmware components configured to perform specified functions. For example, embodiments of the present disclosure can employ various integrated circuit components, such as memory elements, digital signal processing elements, logic elements, lookup tables, etc., which can perform multiple functions under the control of one or more microprocessors or other control devices. Furthermore, those skilled in the art will recognize that embodiments of the present disclosure can be implemented in conjunction with any number of systems, and the systems described herein are merely exemplary embodiments of the present disclosure.

[0018] For the sake of brevity, conventional techniques related to signal processing, data transmission, signaling transmission, control, and other functional aspects of the system (as well as the various operating components of the system) are not described in detail herein. Furthermore, the connecting lines shown in the various figures included herein are intended to illustrate exemplary functional relationships and / or physical couplings between various elements. It should be noted that many alternative or additional functional relationships or physical connections may exist in embodiments of this disclosure.

[0019] This document discloses devices, systems, technologies, and articles of manufacture for intelligent anomaly handling systems for highly complex, safety-critical real-time systems, such as Flight Management Systems (FMS). The devices, systems, technologies, and articles of manufacture disclosed herein describe an intelligent anomaly handling system capable of understanding critical segments in the execution path of a real-time system and the range of critical parameters at nodes (execution points) within that path that could lead to anomalies. The devices, systems, technologies, and articles of manufacture disclosed herein describe an intelligent anomaly handling system that can estimate, using known anomaly models, when a real-time system follows a path leading to an anomaly, based on path and parameter states recorded during a series of executions in an activity cycle. The devices, systems, technologies, and articles of manufacture disclosed herein describe an intelligent anomaly handling system that can take proactive action before an anomaly occurs to prevent the real-time system from experiencing anomalies and avoid the need for shutdown and restart to proactively recover from anomalies.

[0020] The devices, systems, technologies, and articles of art disclosed in this invention describe an intelligent anomaly handling system in which known anomalies or undesirable states expected in a task scenario can be considered at the design level by providing them with fault handling and recovery mechanisms. The disclosed devices, systems, technologies, and articles of art describe an intelligent anomaly handling system that can correct the execution state or branch of a known faulty path that leads to anomalies in response to unknown anomalies and runtime failures.

[0021] Figure 1 For illustrative purposes, this diagram provides a graphical representation of multiple execution paths in exemplary embedded software within an exemplary avionics system. These are described as multiple nodes labeled 0, 1, 2...74. Software execution will cause the system to be at one of these nodes at different times during the execution cycle. In normal execution, node 0 represents the start state, while node 74 represents the end state. In abnormal execution, execution will end at node 74 instead of at node 74 if an exception occurs (represented by star 102). Many execution paths may exist that end at node 74 or star 102. At various nodes, parameters and preconditions determine the process of the next execution path. For example, exemplary standard execution path 104 includes nodes 0-6, 13, 14, 15, 16, 73, and 74. Another standard execution path 106 includes nodes 0-6, 13, 14, 15, 16, 17-27, 35-38, 45, 52-60, 62, 63, 65-71, 72, 73, and 74. The moderately critical execution path 108 and the highly critical execution path 110 have a high probability of causing anomaly 102. The moderately critical execution path 108 includes nodes 27-34, and the highly critical execution path 110 includes nodes 34 and 72.

[0022] Different execution paths can branch out into nodes. For example, at node 15, branch 112 extends to node 16, while another branch 114 extends to node 17. The next node or branch generated depends on the software parameters and environmental parameters used in the calculation, such as altitude, speed, and temperature.

[0023] At the critical nodes in this example, the probability of a failure condition occurring has been determined based on historical calculated parameter values ​​and environmental parameter values ​​at these critical nodes. For example, at node 8, the probability of an anomaly is described as 20%; at node 27, the probability of failure is described as 72%; at node 36, the probability of failure is described as 36%; at node 34, the probability of failure is described as 90%; and at node 46, the probability of failure is described as 51%. Whether an anomaly occurs depends on the path followed. Subsequent changes in environmental conditions and / or system variables in the execution path can result in a path with a decreased probability of failure or a path with an increased probability of failure.

[0024] Intelligent anomaly handling systems can learn and store historical footprints in execution paths that may lead to anomalies. The system can learn this information over a period of time (e.g., using regression-based learning) and use it during runtime to determine the probability of failure at nodes (e.g., critical nodes).

[0025] Figure 2 This is a block diagram of an exemplary computing environment 200, which includes an exemplary intelligent anomaly handling system 202 for training and operating an anomaly handling model 204. The anomaly handling model is configured to identify critical nodes in a software execution path 206, determine in real-time at these critical nodes whether the software is highly likely to be heading towards a fault state, and take proactive corrective actions to prevent the fault state from occurring. The exemplary system 202 includes the anomaly handling model 204, a data acquisition module 208 for acquiring parameters from the normal execution flow path 206 at various nodes, a parameterization selection and extraction module 210 for selecting and extracting specific parameters at specific nodes in the execution path, a training module 212 for training the anomaly handling model 204, and a correction action module 214.

[0026] The exemplary system 202 includes a controller configured to implement an exception handling model 204, a data acquisition module 208, a parameter selection and extraction module 210, a training module 212, and a correction action module 214. The controller includes at least one processor and a computer-readable storage device or medium encoded with programming instructions for configuring the controller. The processor can be any custom or commercially available processor, a central processing unit (CPU), a graphics processing unit (GPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), an auxiliary processor among several processors associated with the controller, a semiconductor-based microprocessor (in the form of a microchip or chipset), any combination thereof, or any device typically used to execute instructions.

[0027] For example, a computer-readable storage device or medium may include volatile and non-volatile storage devices in read-only memory (ROM), random access memory (RAM), and wear-corrected factor memory (KAM). KAM is a persistent or non-volatile memory that can be used to store various operational variables when the processor is powered off. A computer-readable storage device or medium may be implemented using any of many known memory devices, such as PROM (programmable read-only memory), EPROM (electrical PROM), EEPROM (electrically erasable PROM), flash memory, or any other electrical, magnetic, optical, or combined memory device capable of storing data (some of which represent executable programmable instructions used by a controller).

[0028] Data acquisition module 208 is configured to select parameters for each node in the normal execution flow path 206 over time, and to provide parameters to exception handling model 204 and parameter selection and extraction module 210. Exception handling model 204 uses the provided parameters to determine whether corrective action should be taken to prevent software execution from reaching a fault state. Parameter selection and extraction module 210 is configured to select and extract certain parameters for each node, wherein the extracted parameters may vary depending on the node, and to provide the extracted parameters to training module 212.

[0029] Training module 212 is configured to train exception handling model 204, for example, using regression-based learning, to identify various execution paths, determine the probability of reaching a fault state based on the current node and parameter values, and determine whether corrective action should be taken to prevent software execution from reaching a fault state. Training module 212 is configured to acquire computed parameters 213 and environmental parameters 215 at the current node, sum the parameters (217), and input the summation result into training algorithm 219, which is configured to train exception handling model 204, for example, using regression-based learning. Environmental parameters are system parameters (e.g., ground speed or wind speed), while computed parameters are parameters computed at that node during software execution. Computed parameters 213 and environmental parameters 215 are fed into training algorithm 219, which trains and matches exception handling model 204. Training algorithm 219 also receives, for example, actual execution flow path data from corrective action module 214 to train exception handling model 204 to predict the probability of a later fault based on the computed parameters and environmental parameters at the current node. The data used in training module 212 can be calibrated (221) and can provide feedback (223) to train the dataset.

[0030] The exemplary exception handling model 204 is configured to identify critical nodes in the normal execution flow path. A critical node is a node at which the execution path can branch toward or away from the path where the failure occurred. At the critical node, the exception handling model 204 is configured to receive computational parameters and environmental parameters. The computational parameters and environmental parameters may be received from the data acquisition module and / or the parameterized selection and extraction module 210.

[0031] The exemplary anomaly handling model 204 includes a probability calculation module 224 configured to predict the probability of a later failure based on the parameter value at the node. The exemplary anomaly handling model 204 is further configured to compare the calculated probability at the node with a regional performance threshold 226, for example, via a comparison module 228. If it is determined that the calculated probability is not greater than the regional performance threshold, the anomaly handling model 204 has no further action to take and may discard (230) its current calculation. If it is determined that the calculated probability is greater than the regional performance threshold, the anomaly handling model 204 may decide on proactive actions to take to avoid a failure, for example, at the estimated result area 232.

[0032] In this example, proactive actions can take one or more forms to transfer the predicted results to the corrective action module 214, isolate error-prone paths and / or state data to induce controlled anomalies that guide the results to the desired state or mode and / or revert to default values ​​or states, or initiate cleanup of transient resources (e.g., stack / heap or process state or task control parameters or operating modes and secondary modes), isolate errors and activate regenerative paths, employ alternative execution in a slightly degraded mode until the system is fully operational, and announce the problem to a level sufficient for the flight crew to visually consume. For example, after certain data inputs and pilot actions under a specific combination of aircraft system parameters and internally computed state parameters, and as the system propagates toward an anomaly, the exemplary anomaly handling model 204 will proactively act to learn to discard all operations together, select a degraded operating mode to ensure that other critical computations and system data outputs are unaffected, and announce a message to the flight crew via a display system indicating that the system will operate in degraded mode due to an inherent system problem expected to be encountered.

[0033] Figure 3A This is a block diagram illustrating the functionality of an exemplary avionics system 300. The exemplary system 300 includes a user interface command generator 302, a command processor 304, and avionics functions 306. In the exemplary system 300, a request from an interactive navigation system is sampled in a graphical command processor that supports navigation functions. The system 300 generates a command 305 based on user interaction via the user interface command generator 302 and the command processor 304. Command 305 can enable avionics functions 306. Under certain non-nominal operations, when switching from one operating mode to another, multiple commands coupled with transitional and dynamic states that may exist within the system 300 can drive the system 300 to perform operations on intermediate / transient states / data regarding complementary functions that are not adequately considered in the design, potentially leading to runtime software anomalies.

[0034] Under normal conditions, command 305 is processed at command processor 304 based on the interface protocol between interface command generator 302 and command processor 304, and a command queue is constructed for command processing. Unchecked command processing and / or command operations on intermediate and transient data can corrupt the system, leading to inconsistencies in avionics function 306.

[0035] Figure 3BTo illustrate the functionality of the exemplary avionics system 310, the system has been modified to include an exception handling model 311. The exemplary system 310 includes a user interface command generator 312, a command processor 314, avionics functions 316, and an exception handling model 311. The exemplary exception handling model 311 is configured to check the system state at a predefined stage of the software execution path generated by command processing and eliminate commands that could potentially damage the system 310 or foreseeably cause anomalies in the downstream path of the software call chain. The exemplary exception handling model 311 is configured to check the number of commands, the type of commands, preconditions for the system state, and all critical parameters and variables, as well as the degree of internal modifications the system may undergo and is likely to experience with each command execution.

[0036] In this example, exception handling model 311 is configured to determine whether command 315 from the command processor exceeds the number of commands that should be executed (decision 318). If the number of commands has been exceeded (yes at decision 318), the current command is skipped. If the number of commands has not been exceeded (no at decision 318), it is determined whether the command is safe to execute (decision 320). If the command is safe to execute (yes at decision 320), the command is provided to avionics function 316. If the command is unsafe to execute (no at decision 320), the command is discarded and the user interface command generator 312 can provide more input when generating the next command. To determine whether a command is safe to execute, the exemplary exception handling model 311 is configured to obtain inferences based on the execution state and path (operation 322). This may involve considering the type of command, the preconditions of the system state and all key parameters and variables, and the degree of internal modification that the system may undergo and is likely to undergo each time a command is executed.

[0037] The exemplary exception handling model 311 is configured to learn from the preconditions of the system state and all key parameters and variables, as well as the extent of internal modifications that led to the exception, from the newly emerging exception and command 315 in order to predict the conditions that may lead to the exception.

[0038] Figure 4 This is a process flowchart describing an exemplary process 400 for handling anomalies in a safety-critical real-time system in an aircraft. The sequence of operations in process 400 is not limited to the order shown in the figure, but may be performed in one or more varied orders as applicable and in accordance with this disclosure.

[0039] The exemplary process 400 includes receiving multiple parameters at multiple nodes in the real-time execution path of a safety-critical aircraft system (operation 402). The parameters at each node include computational parameters at the node and environmental parameters at the node.

[0040] Exemplary process 400 includes analyzing the received parameters using a trained anomaly handling model for safety-critical aircraft systems (operation 404). The trained anomaly handling model has been trained using machine learning techniques to understand critical execution paths and / or critical parameter ranges at critical nodes, wherein the critical ranges of the parameters include learned thresholds at the nodes.

[0041] Exemplary process 400 includes calculating the failure probability at a critical node using a trained anomaly handling model (operation 406). The trained anomaly handling model may have been trained using regression-based learning. Exemplary process 400 includes comparing the failure probability at the critical node with a learned threshold at the node (operation 408).

[0042] Exemplary process 400 includes taking proactive actions in real time to prevent failure when the probability of failure at a node exceeds a learned threshold at that node (action 410). Taking proactive actions in real time to prevent failure may include visually informing the flight crew that, if the critical execution path of the safety-critical real-time system has not been altered, alternative executions are adopted in a slightly degraded mode until the safety-critical aircraft system is fully operational, and / or triggering an appropriate recovery path for the safety-critical real-time system that may have encountered a failure. Triggering an appropriate recovery path may include one or more of the following: shutting down the current execution, isolating error-prone paths and / or state data, inducing a controlled anomaly to clean up resources, or isolating faulty paths and activating regenerative paths.

[0043] This document describes devices, systems, technologies, and articles of art for predicting potential software failures or anomalies during real-time execution and suggests recovery paths to avoid failures / anomalies. The disclosed devices, systems, technologies, and articles of art provide systems that utilize machine learning to predict anomalies based on key software execution, paths, and key data parameters, as well as the range of nodes in the execution path. The disclosed devices, systems, technologies, and articles of art provide systems utilizing intelligent error / anomaly handling. The devices, systems, technologies, and articles of art disclosed in this invention provide resetless products that can leverage a built-in intelligent system to increase customer satisfaction with zero or near-zero product downtime, a system used to handle anomalies and provide more deterministic system behavior. The devices, systems, technologies, and articles of art disclosed in this invention can improve product performance, MTBF (Mean Time Between Failures), and customer satisfaction, and can reduce the cost of servicing field problems by eliminating the need for point software upgrades to correct software errors. The devices, systems, technologies, and articles of art disclosed in this invention provide intelligent models for robustly detecting causal factors leading to anomalies in real-time avionics systems. The disclosed devices, systems, technologies, and articles of art provide unique representations of causal factors, such as traversed paths and datasets leading to anomalies. The disclosed devices, systems, technologies, and artifacts can provide representations of execution nodes (e.g., node status, datasets leading to anomalies). The disclosed devices, systems, technologies, and artifacts can provide systems for determining the correlation between causal factors and anomaly types. The disclosed devices, systems, technologies, and artifacts can provide systems configured to learn from the correlation between causal factors and anomaly types to provide predictions about anomalies and / or critical execution paths. The disclosed devices, systems, technologies, and artifacts can suggest and switch to the best and most optimized possible recovery associated with the anomaly.

[0044] In one embodiment, an intelligent anomaly handling system implemented by a processor is provided for a safety-critical real-time system in an aircraft. The anomaly handling system includes one or more processors configured by programming instructions on a non-transitory computer-readable medium. The anomaly handling system is configured to: receive multiple parameters at multiple nodes in a real-time execution path of the safety-critical aircraft system; analyze the received parameters using a trained anomaly handling model for the safety-critical aircraft system, wherein machine learning techniques are used to train the trained anomaly handling model to learn critical execution paths and / or critical parameter ranges at critical nodes, wherein the critical parameter ranges include learned thresholds at the nodes; calculate the failure probability at the critical nodes using the trained anomaly handling model; compare the failure probability at the critical nodes with the learned thresholds at the nodes; and take proactive actions in real time to prevent failures when the failure probability at the nodes exceeds the learned thresholds at the nodes.

[0045] In one implementation, the parameters at the node include the computational parameters at the node and the environmental parameters at the node.

[0046] In one implementation, regression-based learning is used to train the trained anomaly handling model.

[0047] In one implementation, in order to take proactive action in real time to prevent failures, the system is configured to visually notify the flight crew that the safety-critical real-time system may encounter a failure if their critical execution path is not changed.

[0048] In one implementation, in order to take proactive action in real time to avoid failure, the system is configured to employ alternative execution in a slightly degraded mode until the safety-critical aircraft system is fully operational.

[0049] In one implementation, in order to take proactive action in real time to prevent failures, the system is configured to trigger an appropriate recovery path.

[0050] In one implementation, a suitable recovery path includes one or more of the following: shutting down current execution; isolating error-prone paths and / or state data; triggering a controlled exception to clean up resources; or isolating the error and activating a regeneration path.

[0051] In one embodiment, a method is provided for a processor implementation for handling anomalies in a safety-critical real-time system of an aircraft. The method includes: receiving multiple parameters at multiple nodes in a real-time execution path of the safety-critical aircraft system; analyzing the received parameters using a trained anomaly handling model for the safety-critical aircraft system, wherein machine learning techniques are used to train the trained anomaly handling model to learn critical execution paths and / or critical parameter ranges at critical nodes, wherein the critical parameter ranges include learned thresholds at the nodes; calculating a failure probability at the critical nodes using the trained anomaly handling model; comparing the failure probability at the critical nodes with the learned thresholds at the nodes; and taking proactive actions in real time to prevent a failure from occurring when the failure probability at the node exceeds the learned thresholds at the node.

[0052] In one implementation, the parameters at the node include the computational parameters at the node and the environmental parameters at the node.

[0053] In one implementation, regression-based learning is used to train the trained anomaly handling model.

[0054] In one implementation, proactive actions are taken in real time to prevent failures, including visually informing the flight crew that the safety-critical real-time system may experience a failure if their critical execution path is not altered.

[0055] In one implementation, proactive measures are taken in real time to prevent failures, including alternative execution in a slightly degraded mode until the safety-critical aircraft system is fully operational.

[0056] In one implementation, taking proactive action in real time to prevent failures includes triggering appropriate recovery paths.

[0057] In one implementation, triggering an appropriate recovery path includes one or more of the following: shutting down current execution; isolating error-prone paths and / or state data; triggering a controlled exception to clean up resources; or isolating the error and activating a regeneration path.

[0058] In another embodiment, a non-transitory computer-readable medium is provided encoded with programming instructions configurable to cause a processor on an aircraft to execute a method. The method includes: receiving multiple parameters at multiple nodes in a real-time execution path of a safety-critical aircraft system; analyzing the received parameters using a trained anomaly handling model for the safety-critical aircraft system, wherein machine learning techniques are used to train the trained anomaly handling model to learn critical execution paths and / or critical parameter ranges at critical nodes, wherein the critical parameter ranges include learned thresholds at the nodes; calculating a failure probability at the critical nodes using the trained anomaly handling model; comparing the failure probability at the critical nodes with the learned thresholds at the nodes; and taking proactive actions in real time to prevent a failure from occurring when the failure probability at the node exceeds the learned thresholds at the node.

[0059] In one implementation, the parameters at the node include the computational parameters at the node and the environmental parameters at the node.

[0060] In one implementation, regression-based learning is used to train the trained anomaly handling model.

[0061] In one implementation, proactive actions are taken in real time to prevent failures, including visually informing the flight crew that the safety-critical real-time system may experience a failure if their critical execution path is not altered.

[0062] In one implementation, proactive measures are taken in real time to prevent failures, including alternative execution in a slightly degraded mode until the safety-critical aircraft system is fully operational.

[0063] In one implementation, taking proactive action in real time to prevent failures includes triggering an appropriate recovery path, which includes one or more of the following: shutting down current execution; isolating error-prone paths and / or state data; triggering a controlled exception to clean up resources; or isolating the error and activating a regeneration path.

[0064] Those skilled in the art will understand that the various exemplary logic blocks, modules, circuits, and algorithm steps described in conjunction with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. Some embodiments and specific implementations have been described above according to function and / or logic block components (or modules) and various processing steps. However, it should be understood that such block components (or modules) can be implemented by any number of hardware, software, and / or firmware components configured to perform the specified functions. To clearly illustrate this interchangeability between hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally according to their functions. Whether such functions are implemented as hardware or software depends on the specific application and the design constraints imposed on the system as a whole. Those skilled in the art can implement the described functions in different ways for each specific application, but such implementation decisions should not be construed as causing a departure from the scope of the invention. For example, embodiments of the system or components may employ various integrated circuit components, such as memory elements, digital signal processing elements, logic elements, lookup tables, etc., which can perform multiple functions under the control of one or more microprocessors or other control devices. Furthermore, those skilled in the art will understand that the embodiments described herein are merely exemplary specific implementations.

[0065] The various exemplary logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein can be implemented or performed using a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination of the above designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but alternatively, it may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors incorporating a DSP core, or any other such configuration.

[0066] The steps of the methods and algorithms described in conjunction with the embodiments disclosed herein can be directly embodied in hardware, in a software module executed by a processor, or a combination of both. The software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor such that the processor can read information from and write information to the storage medium. Alternatively, the storage medium can be integrated into the processor. The processor and storage medium can reside in an ASIC. The ASIC can reside in a user terminal. Alternatively, the processor and storage medium can reside as discrete components in the user terminal.

[0067] In this document, relational terms such as "first" and "second" may be used only to distinguish one entity or action from another, and do not necessarily require or imply any actual such relationship or order between such entities or actions. Unless expressly defined by the language of the claims, numerical ordinal numbers such as "first," "second," "third," etc., merely indicate different individuals among a plurality and do not imply any order or sequence. Unless expressly defined by the language of the claims, any sequence of text in the claims does not imply that the processing steps must be performed in a chronological or logical order according to such a sequence. Without departing from the scope of the invention, the method steps may be interchanged in any order, provided that such interchange does not contradict the language of the claims and is not logically absurd.

[0068] Furthermore, depending on the context, the use of terms such as “connected” or “coupled to” when describing the relationship between different components does not imply that a direct physical connection must be made between these components. For example, two components can be physically, electronically, logically, or in any other way connected to each other by one or more additional components.

[0069] While at least one exemplary embodiment has been presented in the foregoing detailed description of the invention, it should be understood that numerous variations exist. It should also be understood that one or more exemplary embodiments are merely examples and are not intended to limit the scope, applicability, or configuration of the invention in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient roadmap for implementing exemplary embodiments of the invention. It should be understood that various changes can be made to the function and arrangement of the elements described in the exemplary embodiments without departing from the scope of the invention as set forth in the appended claims.

Claims

1. An intelligent anomaly handling system implemented by a processor for a safety-critical real-time avionics system in an aircraft, the safety-critical real-time avionics system comprising the intelligent anomaly handling system, a user interface command generator, a command processor, and avionics functions, the anomaly handling system comprising a controller configured to: To determine whether a command is safely executed from the user interface command generator to the avionics function, the controller is further configured to: Multiple parameters are received at the software node in the real-time execution path of the software unit of the safety-critical avionics system, including one or more computational software parameters of the software unit and one or more environmental parameters. The received parameters are analyzed using a trained anomaly handling model for safety-critical avionics systems, wherein machine learning techniques are used to train the trained anomaly handling model to learn the probability values ​​of fault conditions occurring in the software at multiple nodes based on historically calculated software parameter values ​​and environmental parameter values, and to learn learned thresholds at said multiple nodes. The trained anomaly handling model, the one or more computational software parameters, and the one or more environmental parameters are used to calculate the failure probability at critical nodes in the software unit. The failure probability at the critical node in the software unit is compared with the learned threshold at the critical node. as well as Active actions are taken in real time to prevent failures in the software unit when the probability of failure at the critical node is higher than the learned threshold at the critical node.

2. The system of claim 1, wherein regression-based learning is used to train the trained anomaly handling model.

3. The system of claim 1, wherein, in order to take proactive action in real time to avoid failure, the system is configured to visually notify the flight crew that the safety-critical real-time system may encounter a failure if their critical execution path is not changed.

4. The system of claim 1, wherein, in order to take proactive action in real time to avoid failure, the system is configured to employ alternative execution in a slightly degraded mode until the safety-critical aircraft system is fully operational.

5. The system of claim 1, wherein, in order to take proactive action in real time to avoid failure, the system is configured to trigger an appropriate recovery path, wherein the appropriate recovery path includes one or more of the following: Close the currently executing command; Isolate error-prone paths and / or status data; Raise a controlled exception to clear resources; or Isolate the error and activate the regeneration path.

6. A method for implementing a processor for handling anomalies in a safety-critical real-time avionics system in an aircraft, the safety-critical real-time avionics system including an intelligent anomaly handling system, a user interface command generator, a command processor, and avionics functions, the method comprising: For commands from the user interface command generator to the avionics function, determining whether the commands are safe to execute, wherein the determination includes: Multiple parameters are received at the software node in the real-time execution path of the software unit of the safety-critical avionics system, including one or more computational software parameters of the software unit and one or more environmental parameters. The received parameters are analyzed using a trained anomaly handling model for safety-critical avionics systems, wherein machine learning techniques are used to train the trained anomaly handling model to learn the probability values ​​of fault conditions occurring in the software at multiple nodes based on historically calculated software parameter values ​​and environmental parameter values, and to learn learned thresholds at said multiple nodes. The trained anomaly handling model, the one or more computational software parameters, and the one or more environmental parameters are used to calculate the failure probability at critical nodes in the software unit. The failure probability at the critical node in the software unit is compared with the learned threshold at the critical node; and Active actions are taken in real time to prevent failures in the software unit when the probability of failure at the critical node is higher than the learned threshold at the critical node.

7. The method of claim 6, wherein regression-based learning is used to train the trained anomaly handling model.

8. The method of claim 6, wherein in order to take proactive action in real time to avoid failure, it includes visually informing the flight crew that the safety-critical real-time system may encounter a failure if their critical execution path is not changed.

9. The method of claim 6, wherein proactive actions are taken in real time to avoid failure, including alternative execution in a slightly degraded mode until the safety-critical aircraft system is fully operational.

10. The method of claim 6, wherein taking proactive action in real time to avoid failure includes triggering an appropriate recovery path, wherein triggering an appropriate recovery path includes one or more of the following: Close the currently executing command; Isolate error-prone paths and / or status data; Raise a controlled exception to clear resources; or Isolate the error and activate the regeneration path.

Images