Patent Description:
Flight management systems are employed within an aircraft cockpit to perform complex operations and/or complex calculations that facilitate adherence to a flight plan and that increase the safety of air travel. Various tasks associated with the flight management system can include controlling and/or modifying a multitude of parameters related to navigation of the aircraft. Due to the critical control applications being managed, performance of the complex functions on the multitude of parameters should be performed by the flight management system in real-time with as few disruptions as possible.

A prior art display device is disclosed in <CIT>, wherein a flat screen device comprising a multi-channel graphic generation and a video data switch is disclosed. A method for managing a data network is also disclosed making it possible to improve the reliability of a network of several displays by improved management of all the graphic generations.

A prior art fault processing method is disclosed in <CIT>, wherein it is disclosed that upon receiving notice, a Logical Partition (LPAR) notifies a hypervisor that it has executed processing to cope with a fault. The hypervisor provides an interface for acquiring a situation of a notice situation. It is made possible to register and acquire a situation of coping with a hardware fault allowing continuation of execution through the interface, and it is made possible to make a decision as to the situation of coping with a fault in the computers as a whole.

The following presents a simplified summary of the disclosed subject matter in order to provide a basic understanding of some aspects of the disclosed subject matter. This summary is not an extensive overview of the various aspects. It is intended neither to identify key or critical elements of the various aspects nor to delineate the scope of the various aspects. Its sole purpose is to present some concepts of the disclosure in a streamlined form as a prelude to the more detailed description that is presented later.

One or more aspects provide a system that can comprise a memory that stores executable components and a processor, operatively coupled to the memory, that executes the executable components. The executable components can comprise a first controller that operates a first display unit and a second controller that operates a second display unit. The first display unit can render a first set of data and the second display unit can render a second set of data. The executable components can also comprise a failure indication component that provides a first notification to the first controller based on a first detection of a first failure at the second controller, and a second notification to the second controller based on a second detection of a second failure at the first controller. Further, the executable components can comprise a control transfer component that automatically transfers control of the second display unit from the second controller to the first controller based on the first notification, or automatically transfers control of the first display unit from the first controller to the second controller based on the second notification. The control transfer component can automatically transfer control without receiving a manual input requesting the transfer.

In an implementation, the second controller facilitates a rendering of the first set of data on the second display unit in response to automatic transfer of control of the first display unit from the first controller to the second controller. According to another implementation, the first controller facilitates a rendering of the second set of data on the first display unit in response to automatic transfer of control of the second display unit from the second controller to the first controller. In another implementation, the first controller can render the first set of data on the first display unit and the second controller can render the second data on the second display unit as respective software units. The respective software units can be defined by attributes.

Also, in one or more aspects, a method is provided. The method can comprise detecting, by a system comprising a processor, a failure of a first controller. The first controller can be operatively coupled to a first onside layer component and a first offside layer component. Further, the first onside layer component can operate a first display unit. The method can also comprise automatically transferring, by the system, a control of the first display unit to a second controller operatively coupled to a second onside layer component and a second offside layer component. The second onside layer component can operate a second display unit. Further, the transferring can comprise routing the control of the first display unit from the first onside layer component to the second offside layer component. Further, the method can comprise rendering, by the system, first data associated with the first display unit on the second display unit at substantially a same time as second data associated with the second display unit is displayed. The first display unit and the second display unit can be redundancy units of a flight management system. According to another implementation, transferring the control can be implemented in an absence of receipt of a manual input.

According to an implementation, rendering the first data and the second data can comprise allocating a portion of the first display unit for rendering the first data and a second portion of the first display unit for rendering the second data. In some implementations, the method can include monitoring, by the system, a first status of the first controller and transmitting, by the system, a first indication to the second controller to assume a primary display responsibility of the first display unit in response to a first detection of the failure based on the monitoring the first status.

In addition, according to one or more aspects, provided is method that can comprise facilitating, by a system comprising a processor, a first rendering of first data on a first display unit via a first controller. The method can also include facilitating, by the system, a second rendering of second data on a second display unit via a second controller. In addition, the method can comprise detecting, by the system, a failure of the first controller and the second controller. The method can also comprise transferring, by the system, control of the first display unit from the first controller to a device external to the system. Further, the method can comprise transferring by the system, control of the second display unit from the second controller to the device external to the system.

To the accomplishment of the foregoing and related ends, the disclosed subject matter comprises one or more of the features hereinafter more fully described. The following description and the annexed drawings set forth in detail certain illustrative aspects of the subject matter. However, these aspects are indicative of but a few of the various ways in which the principles of the subject matter can be employed. Other aspects, advantages, and novel features of the disclosed subject matter will become apparent from the following detailed description when considered in conjunction with the drawings. It will also be appreciated that the detailed description may include additional or alternative aspects beyond those described in this summary.

Various non-limiting embodiments are further described with reference to the accompanying drawings in which:.

One or more embodiments are now described more fully hereinafter with reference to the accompanying drawings in which example embodiments are shown. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the various embodiments. However, the various embodiments can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the various embodiments.

Various aspects provided herein relate to flight management systems. Within a cockpit of an aircraft are a set of interactive display devices (or display units) that are utilized to display various graphical representations associated with the control and/or modification of a multitude of parameters associated with navigation of the aircraft. In an example, a machine-human interface (HMI) employed by the flight management system is governed by a standard referred to as ARINC <NUM>, named for Aeronautical Radio, Incorporated (ARINC), which was charted by the Federal Communications Commission.

The ARINC <NUM> is an aeronautical standard that specifies a standardized framework for the definition of a Cockpit Display System (CDS) and an interface (e.g., communication) between the CDS, User Applications (UAs), and/or other avionic system equipment to manage various functions of the aircraft. For example, the ARINC <NUM> defines a Graphical User Interface (GUI) in binary Definition Files (DF).

The graphical portion of the embedded HMIs are described in the DFs. For example, the interface defined in the ARINC 661utilizes a basic set of graphic user interface objects, described in the DFs as "widgets. " Widgets are software units associated with a graphical representation and a behavior, which can facilitate receipt of the information by the flight crew and/or to provide instructions through the HMI.

Generally, widgets correspond to a displayable entity. Some of the widgets can be "interactive widgets," which support flight crewmember actions using various interface devices. Actions by crewmembers on interactive widgets can be associated with event reports sent to the UA (e.g., an indication of a failure). Non-interactive widgets do not have an associated event.

Discussed herein is the use of ARINC <NUM> widgets, which can facilitate automatic user application reversions upon system failures. Widgets utilized with the disclosed aspects can include a "No Service Monitor Widget," with a "Connector Widget" used under the "ShowNoServiceIdent" (or within a container). A similar mechanism can be accomplished with a Watchdog Container, by allowing a connector on the "ShowIfFailIdent" parameter. Either mechanism can allow for an automatic reversion on the displays from a primary subsystem to a secondary subsystem, as will now be described in further detail.

<FIG> illustrates an example, non-limiting, system <NUM> for facilitating automatic display unit backup during failures of one more display units in accordance with one or more embodiments described herein. When recovery of a failure has been accomplished, an automatic reversion to a primary display unit can be facilitated as discussed herein.

During use of a flight management system, if a failure occurs, an indication is provided through one or more display units and a pilot manually flips or selects a flight deck switch to cause the display to change from one flight management system to the other flight management system. However, with the various aspects disclosed herein, if a failure is detected in one or more flight management system controls, there can be automatic reversion to another system, without a requirement for receipt of a manual input.

For example, based on a failure of a primary system, a connector can be used to automatically revert to the display of data at a secondary system. If there is a subsequent failure of the secondary system, a tertiary system can be utilized to perform the display functions. The tertiary system can be located within the aircraft (e.g., a mobile device associated with a pilot or other person aboard the aircraft) or remote from the aircraft (e.g., a ground control station, a mobile device associated with an authorized user on the ground, and so on). Further, when the primary system (and/or the secondary system) is no longer experiencing a failure, the connector can automatically return the display of data to the primary system (and/or the secondary system).

The system <NUM> can include a monitor component <NUM>, a failure indication component <NUM>, a predictive component <NUM>, a control transfer component <NUM>, at least one memory <NUM>, and at least one processor <NUM>. The monitor component <NUM> can observe a status of one or more display units associated with various control systems. As illustrated, there can be a first display unit <NUM> through an Nth display unit <NUM>, where N is an integer. The display units can be operated through respective controllers comprising respective memories and processors. According to an implementation, a control system can be a flight management system and the display units can be included in an airplane cockpit display systems. The monitor component <NUM> can observe the status of hardware, software, and/or a communications network associated with the one or more display units.

Based on the observation of the monitor component <NUM>, a failure indication component <NUM> can determine if a failure of the observed hardware, software, and/or communications network is detected for one or more of the display units. The failure indication can be associated with a display, with software controlling the display, and so on.

According to some implementations, the predictive component <NUM> can predict whether a failure is likely to occur based on one or more indications. For example, failure information can be tracked over time and retained as historical information. Various attributes associated with the display units can be compared to the historical information and, if there is a match, it can indicate that a similar failure might be experienced.

If a failure has occurred (as determined by the failure indication component <NUM>) and/or is expected to occur (as determined by the predictive component <NUM>), the control transfer component <NUM> can facilitate transfer of control of the display associated with the failure to another display control. For example, if a failure associated with the first display unit <NUM> is indicated, the control transfer component <NUM> can automatically switch control of the display to another controller for output at the Nth display unit <NUM>. Upon or after resolution of the failure associated with the first display unit <NUM>, the control transfer component <NUM> can automatically switch the return the control of the first display unit <NUM> to a controller responsible for operating the first display unit <NUM>. <FIG> below will provide further details related to the various aspects discussed herein.

<FIG> illustrates an example, non-limiting, schematic representation <NUM> of routing for redundant display systems in accordance with one or more embodiments described herein. Illustrated are a first flight management system <NUM> (FMS1) and a second flight management system <NUM> (FMS2). The first flight management system <NUM> can be operatively coupled to, and can control, a first onside layer component <NUM>, which can be (and can include the functionality of) a first flight management system (FMS1) onside flight status display (FSD) layer. The first flight management system <NUM> can also be operatively coupled to, and can control, a first offside layer component <NUM>, which can be (and can include the functionality of) a FMS1 offside FSD layer. The first onside layer component <NUM> can be operatively coupled to, and can control a first display <NUM> (e.g., a left-side display). The first offside layer component <NUM> can be utilized in the event of a failure associated with a second display <NUM> (e.g., a right-side display).

The second flight management system <NUM> can be coupled to, and can control a second onside layer component <NUM>, which can be (and can include the functionality of) a FMS2 onside FSD layer. Further the second flight management system <NUM> can be coupled to, and can control, a second offside layer component <NUM>, which can be (and can include the functionality of) a FMS2 offside FSD layer. The second onside layer component <NUM> can be coupled to, and can control, the second display <NUM>. The second offside layer component <NUM> can be utilized in the event of a failure associated with the first display <NUM>.

In an implementation when there is a failure associated with the first flight management system <NUM>, operation of the first display <NUM> can be automatically transferred from the first onside layer component <NUM> to the second offside layer component <NUM>, as indicated by line <NUM>. The second onside layer component <NUM> retains control of second display <NUM>. Thus during a failure of the first flight management system <NUM>, the second flight management system <NUM> can control output of the information intended for the first display <NUM> and the second display <NUM>. According to some implementations, the information can be displayed on a single display (e.g., the second display <NUM> in this example). However, according to some implementations, if the first display <NUM> is not experiencing a failure, the second offside layer component <NUM> can facilitate rendering of the respective information on the first display <NUM> and on the second display <NUM>. After resolution of the failure at the first flight management system <NUM>, control of the first display <NUM> can automatically be returned to the first onside layer component <NUM>, as indicated by line <NUM>.

In another implementation when there is failure associated with the second flight management system <NUM>, operation of the second display <NUM> can be automatically transferred from the second onside layer component <NUM> to the first offside layer component <NUM>, as indicated by line <NUM>. In this implementation, the first onside layer component <NUM> retains control of the first display <NUM> and the first offside layer component <NUM> assumes control of the second display <NUM>.

Thus during a failure of the second flight management system <NUM>, the first flight management system <NUM> can control output of the information intended for the first display <NUM> and the second display <NUM>. According to some implementations, the information can be displayed on a single display (e.g., the first display <NUM> in this implementation). However, according to some implementations, if the second display <NUM> is not experiencing a failure, the first offside layer component <NUM> can facilitate rendering of the respective information on the first display <NUM> and on the second display <NUM>. After resolution of the failure at the second flight management system <NUM>, control of the second display <NUM> can automatically be returned to the second onside layer component <NUM>, as indicated by line <NUM>.

In a further implementation, there might be a failure of both the first flight management system <NUM> and the second flight management system <NUM>. In this situation, for the first display <NUM>, the first onside layer component <NUM> would attempt to transfer control to the second offside layer component <NUM>. However, since the second flight management system <NUM> is experiencing a failure, the transfer does not occur (e.g., NoService: FMS Fail Flag) and the first display <NUM> is rendered inoperable. In a similar manner, for the second display <NUM>, the second onside layer component <NUM> would attempt to transfer control to the first offside layer component <NUM>. However, since the first flight management system <NUM> is also experiencing failure (e.g., NoService: FMS Fail Flag), the transfer does not occur and the second display <NUM> is rendered inoperable. According to an implementation, to address this issue, an infinite looping connection can be provided, as illustrated in <FIG> below. In accordance with another implementation, to address this issue, a backup system can be utilized as illustrated in <FIG> below.

In further detail, respective widgets can be associated with the first onside layer component <NUM>, the first offside layer component <NUM>, the second onside layer component <NUM>, and the second offside layer component <NUM>. For example, the widget can be a "NoServiceMonitor" widget, which can be utilized to display information with no communication between the UA and CDS is possible. For example, the first onside layer component <NUM> can include the following example, non-limiting, widget:
NoServiceMonitor.

Further, the first offside layer component <NUM> can include the following example, non-limiting, widget:
NoServiceMonitor.

The second onside layer component <NUM> can include the following example, non-limiting, widget:
NoServiceMonitor.

Additionally, the second offside layer component <NUM> can include the following example, non-limiting, widget:
NoServiceMonitor.

<FIG> illustrates an example, non-limiting, schematic representation <NUM> of routing for an infinite looping initialization system in accordance with one or more embodiments described herein. Repetitive description of like elements employed in other embodiments described herein is omitted for sake of brevity. In the implementation of <FIG>, the operation is similar to the operation of <FIG> in the situations where there is no failure and/or only one flight management system experiences a failure. Accordingly, the details related to these operations are omitted for sake of brevity.

However, in this case, when there is a failure of both the first flight management system <NUM> and the second flight management system <NUM>, an infinite looping can be created. The infinite looping can be utilized to avoid a situation where both displays are rendered inoperable due to failure of both the first flight management system <NUM> and the second flight management system <NUM>.

During failure of both the first flight management system <NUM> and the second flight management system <NUM>, operation for the first display <NUM> can be automatically transferred from the first onside layer component <NUM> to the second offside layer component <NUM>, as indicated by line <NUM>. However, since the second flight management system <NUM> is also experiencing a failure, a transfer back to the first onside layer component <NUM> is automatically implemented, as indicated by line <NUM>. If the first flight management system <NUM> is still experiencing a failure, transfer is attempted to the second offside layer component <NUM> (e.g., line <NUM>). This looping can continue until one of the flight management systems returns on line, or after a defined time out period.

In a similar manner, for operation of the second display <NUM>, an automatic transfer of control from the second onside layer component <NUM> to the first offside layer component <NUM> is attempted, as indicated by line <NUM>. Since the first flight management system <NUM> is experiencing a failure, a transfer back to the second onside layer component <NUM> is automatically performed, as indicated by line <NUM>. If the second flight management system <NUM> is still experiencing a failure, transfer is attempted to the first offside layer component <NUM> (e.g., line <NUM>). This looping can continue until one of the flight management systems returns on line, or after a defined time out period.

It is noted that the attempted transfers along line pairs <NUM>/<NUM> and <NUM>/<NUM> can be recursive until one or both flight management systems are no longer experiencing a failure. According to some implementations, a time limit can be associated with the infinite looping, wherein after expiration of the timer, attempted transfers are discontinued and both displays are rendered inoperable. In another attempt, a defined number of transfers can be attempted, after which the attempted transfers are discontinued.

<FIG> illustrates an example, non-limiting, schematic representation <NUM> for routing of a backup system in accordance with one or more embodiments described herein. Repetitive description of like elements employed in other embodiments described herein is omitted for sake of brevity. In the implementation of <FIG>, the operation is similar to the operation of <FIG> in the implementations where there is no failure and/or only one flight management system experiences a failure. Accordingly, the details related to these operations are omitted for sake of brevity.

A backup navigation application <NUM> can be operatively coupled to a backup navigation layer <NUM>. The following explains the routing when there is a failure of both the first flight management system <NUM> and the second flight management system <NUM>. Based on detection of failure at the first flight management system <NUM> control is automatically transferred from the first onside layer component <NUM> to the second offside layer component <NUM>, as indicated by line <NUM>. However, since the second flight management system <NUM> is also experiencing a failure, the second offside layer component <NUM> automatically transfers control to the backup navigation layer <NUM>, as indicated by line <NUM>.

In a similar manner, due to the failure of the second flight management system <NUM>, control of the second display <NUM> is automatically transferred from the second onside layer component <NUM> to the first offside layer component <NUM>, as indicated by line <NUM>. Since the first flight management system <NUM> is experiencing a failure, the first offside layer component <NUM> automatically transfers the control to the backup navigation layer <NUM>, as indicated by line <NUM>.

The backup navigation layer <NUM> can retain control for the first display <NUM> and the second display <NUM> until receipt of a first indication that the first flight management system <NUM> is no longer experiencing a failure and/or receipt of a second indication that the second flight management system <NUM> is no longer experiencing a failure.

If the first indication is received, the backup navigation layer <NUM> can automatically return control of the first display <NUM> to the first onside layer component <NUM> and can return control of the second display <NUM> to the first offside layer component <NUM>. If the second indication is received, the backup navigation layer <NUM> can automatically return control of the second display <NUM> to the second onside layer component <NUM> and control of the first display <NUM> to the second offside layer component <NUM>.

According to some implementations, the backup navigation application <NUM> and/or the backup navigation layer <NUM> can be included, at least partially, on a separate device. For example, the separate device can be a user equipment device, such as a device associated with a pilot, co-pilot, or another crewmember. In another example, the separate device can be a control tower device or other ground based device. In the case of a control tower or ground based device, the operation of the aircraft can be performed remotely (e.g., from the ground) in the case of personnel on the aircraft no longer being able to operate the aircraft.

<FIG> illustrates an example, non-limiting, alternative schematic representation <NUM> of routing for an implementation with multiple displays units in accordance with one or more embodiments described herein. Repetitive description of like elements employed in other embodiments described herein is omitted for sake of brevity.

In this implementation, there are five display units (DUs), illustrated as a first display unit <NUM>, a second display unit <NUM>, a third display unit <NUM>, a fourth display unit <NUM>, and a fifth display unit <NUM>. Also illustrated is an Input/Output (IO) routing table <NUM>.

As illustrated, the first onside layer component <NUM> can be operatively coupled to, and can control operation of, the first display unit <NUM>, the second display unit <NUM>, and the fifth display unit <NUM> (represented by solid lines). Further, the second onside layer component <NUM> can be operatively coupled to, and can control operation of, the third display unit <NUM>, the fourth display unit <NUM>, and the fifth display unit <NUM>.

If there is a failure of the first flight management system <NUM>, the operation of the first display unit <NUM>, the second display unit <NUM>, and the fifth display unit <NUM> can be seamlessly transferred to the second offside layer component <NUM>, as indicated by line <NUM>. Upon or after the automatic transfer of control to the second offside layer component <NUM>, a connection is established between the second offside layer component <NUM>, the first display unit <NUM>, the second display unit <NUM>, and the fifth display unit <NUM>, as indicated by the dashed lines. When the failure of the first flight management system <NUM> is resolved, control can be automatically transferred from the second offside layer component <NUM> to the first onside layer component <NUM>, as indicated by line <NUM>.

In a similar manner if there is a failure of the second flight management system <NUM>, the operation of the third display unit <NUM>, the fourth display unit <NUM>, and the fifth display unit <NUM> can be automatically transferred from the second onside layer component <NUM> to the first offside layer component, as indicated by line <NUM>. Upon or after the automatic transfer of control to the first offside layer component <NUM>, a connection is established between the third display unit <NUM>, the fourth display unit <NUM>, and the fifth display unit <NUM>, as indicated by the dashed lines. When the failure of the second flight management system <NUM> is resolved, control can be automatically returned to the second onside layer component <NUM>, as indicated by line <NUM>.

The schematic representation <NUM> of <FIG> blends together User Application Definition File (UADF) layer structures, internal FMS IO, and internal FMS HMI processing as the conceptual routing. <FIG> illustrates the IO runtime routing of traffic. Except for the fifth display unit <NUM>, only two connections are utilized to each display unit. The fifth display unit can utilize four connections. This is because the fifth display unit <NUM> could controlled by the first onside layer component <NUM> and the second onside layer component <NUM> in the absence of failures and by the first offside layer component <NUM> and/or the second offside layer component <NUM> when one or more failures of the flight management systems are experienced.

In accordance with various implementations, when there is a failure of both the first flight management system <NUM> and the second flight management system <NUM>, similar routing as discussed with <FIG> and/or <FIG> can be employed for the implementations that comprise more than two displays.

With reference again to <FIG>, the at least one memory <NUM> can be operatively coupled to the at least one processor <NUM>. The at least one memory <NUM> can store computer executable components and/or computer executable instructions. The at least one processor <NUM> can facilitate execution of the computer executable components and/or the computer executable instructions stored in the at least one memory <NUM>. The term "coupled" or variants thereof can include various communications including, but not limited to, direct communications, indirect communications, wired communications, and/or wireless communications.

Further, the at least one memory <NUM> can store protocols associated with facilitating management of user application failure modes and reversions as discussed herein. Further, the at least one memory <NUM> can facilitate action to control communication between the system <NUM>, other systems, and/or other devices, such that the system <NUM> can employ stored protocols and/or algorithms to achieve improved management and reversions determination as described herein.

It is noted that although the one or more computer executable components and/or computer executable instructions can be illustrated and described herein as components and/or instructions separate from the at least one memory <NUM> (e.g., operatively connected to at least one memory <NUM>), the various aspects are not limited to this implementation. Instead, in accordance with various implementations, the one or more computer executable components and/or the one or more computer executable instructions can be stored in (or integrated within) the at least one memory <NUM>. Further, while various components and/or instructions have been illustrated as separate components and/or as separate instructions, in some implementations, multiple components and/or multiple instructions can be implemented as a single component or as a single instruction. Further, a single component and/or a single instruction can be implemented as multiple components and/or as multiple instructions without departing from the example embodiments.

It should be appreciated that data store (e.g., memories) components described herein can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. By way of example and not limitation, nonvolatile memory can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM), which acts as external cache memory. By way of example and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM). Memory of the disclosed aspects are intended to comprise, without being limited to, these and other suitable types of memory.

The at least one processor <NUM> can facilitate respective analysis of information related to failure events. The at least one processor <NUM> can be a processor dedicated to analyzing and/or generating reversion actions based on data received, a processor that controls one or more components of the system <NUM>, and/or a processor that both analyzes and generates models based on data received and controls one or more components of the system <NUM>.

<FIG> illustrates an example, non-limiting, system <NUM> for employing machine learning to automate one or more aspects in accordance with one or more embodiments described herein. Repetitive description of like elements employed in other embodiments described herein is omitted for sake of brevity. The system <NUM> can comprise one or more of the components and/or functionality of the system <NUM> and/or the routing discussed with respects to <FIG>, and vice versa.

A first controller <NUM> can operate the first display unit <NUM>, which can render a first set of data. An Nth controller <NUM> can operate the Nth display unit <NUM>, which can render a second set of data. The monitor component <NUM> can observe operations of the first display unit <NUM>, the Nth display unit <NUM>, the first controller <NUM>, and/or the Nth controller <NUM>. The first display unit <NUM> and the Nth display unit <NUM> can be redundancy display units of a flight management system. In an example, the first controller <NUM> can render the first set of data on the first display unit <NUM> and the Nth controller <NUM> can render the Nth set of data on the Nth display unit <NUM> as respective software units, wherein the respective software units are defined by attributes.

The failure indication component <NUM> can provide a first notification to the first controller <NUM> based on a first detection of a first failure at the Nth controller <NUM>. Further, the failure indication component <NUM> can provide a second notification to the Nth controller <NUM> based on a second detection of a second failure at the first controller <NUM>. According to some implementations, the controllers can fail at substantially the same time and/or a failure of the controllers can overlap for at least a portion of time. However, the disclosed aspects are not limited to this implementation. Instead, the controllers of can independently fail while other controllers do not experience a failure.

Based on the one or more failures, the control transfer component <NUM> can automatically transfer control of the first display unit <NUM> from the first controller <NUM> to the Nth controller <NUM> based on the first notification. Alternatively or additionally, the control transfer component <NUM> can automatically transfer control of the Nth display unit <NUM> from the Nth controller <NUM> to the first controller <NUM> based on the second notification. The control transfer component <NUM> can automatically perform the control transfer without receiving a manual input requesting the transfer (e.g., an action by the pilot is not necessary).

In an example, the Nth controller <NUM> can facilitate a rendering of the first data on the Nth display unit <NUM> in response to automatic transfer of control of the first display unit <NUM> from the first controller <NUM> to the Nth controller <NUM>. In another example, the first controller <NUM> can facilitate a rendering of the second data on the first display unit <NUM> in response to automatic transfer of control of the Nth display unit <NUM> from the Nth controller <NUM> to the first controller <NUM>.

The control transfer component <NUM> can automatically return the control of the first display unit <NUM> to the first controller <NUM> based on a determination that the failure of the first controller <NUM> is resolved. Additionally or alternatively, the control transfer component <NUM> can automatically return the control of the Nth display unit <NUM> to the Nth controller <NUM> based on a determination that the failure of the Nth controller <NUM> is resolved.

In accordance with an implementation, the system <NUM> can be implemented for onboard avionics of an aircraft. Further to this implementation, the first display unit <NUM> and the Nth display unit <NUM> can be cockpit display units. In addition, the system <NUM> can operate in accordance with an ARINC <NUM> aeronautical standard.

The system <NUM> can also include a machine learning and reasoning component <NUM>, which can employ automated learning and reasoning procedures (e.g., the use of explicitly and/or implicitly trained statistical classifiers) in connection with performing inference and/or probabilistic determinations and/or statistical-based determinations in accordance with one or more aspects described herein.

For example, the machine learning and reasoning component <NUM> can employ principles of probabilistic and decision theoretic inference. Additionally or alternatively, the machine learning and reasoning component <NUM> can rely on predictive models constructed using machine learning and/or automated learning procedures. Logic-centric inference can also be employed separately or in conjunction with probabilistic methods.

The machine learning and reasoning component <NUM> can infer a failure of one or more display units and/or associated controllers by obtaining knowledge about the respective hardware, software, and other parameters of the display units. According to a specific implementation, the system <NUM> can be implemented for onboard avionics of an aircraft. The one or more display units can be cockpit display units. Further to this implementation, the system <NUM> can operate in accordance with an ARINC <NUM> aeronautical standard.

Based on the knowledge, the machine learning and reasoning component <NUM> can make an inference based on whether one or more display units has failed, or is predicted to fail, and one or more actions to take based on the failure determination.

As used herein, the term "inference" refers generally to the process of reasoning about or inferring states of the system, a component, a module, the environment, and/or assets from a set of observations as captured through events, reports, data and/or through other forms of communication. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic. For example, computation of a probability distribution over states of interest based on a consideration of data and/or events. The inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference can result in the construction of new events and/or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and/or data come from one or several events and/or data sources. Various classification schemes and/or systems (e.g., support vector machines, neural networks, logic-centric production systems, Bayesian belief networks, fuzzy logic, data fusion engines, and so on) can be employed in connection with performing automatic and/or inferred action in connection with the disclosed aspects.

The various aspects (e.g., in connection with automatic display unit backup during failures of one more display units through the utilization of structure functional description language defined for control transfer and reversion after resolution of the failures) can employ various artificial intelligence-based schemes for carrying out various aspects thereof. For example, a process for evaluating one or more parameters of a display unit can be utilized to predict a failure of the display unit, which can be enabled through an automatic classifier system and process.

A classifier is a function that maps an input attribute vector, x = (xl, x2, x3, x4, xn), to a confidence that the input belongs to a class. In other words, f(x) = confidence(class). Such classification can employ a probabilistic and/or statistical-based analysis (e.g., factoring into the analysis utilities and costs) to prognose or infer an action that should be employed to determine whether to transfer control of a display from a controller, which controller the control of the display should be transferred to, and so on. In the case of display units, for example, attributes can be identification of a known failure pattern based on historical information and the classes are criteria of how to mitigate effects of the failure by offloading the control to another system component.

A support vector machine (SVM) is an example of a classifier that can be employed. The SVM operates by finding a hypersurface in the space of possible inputs, which hypersurface attempts to split the triggering criteria from the non-triggering events. Intuitively, this makes the classification correct for testing data that can be similar, but not necessarily identical to training data. Other directed and undirected model classification approaches (e.g., naive Bayes, Bayesian networks, decision trees, neural networks, fuzzy logic models, and probabilistic classification models) providing different patterns of independence can be employed. Classification as used herein, can be inclusive of statistical regression that is utilized to develop models of priority.

One or more aspects can employ classifiers that are explicitly trained (e.g., through a generic training data) as well as classifiers that are implicitly trained (e.g., by observing and recording asset behavior, by receiving extrinsic information, and so on). For example, SVM's can be configured through a learning or training phase within a classifier constructor and feature selection module. Thus, a classifier(s) can be used to automatically learn and perform a number of functions, including but not limited to determining according to a predetermined criteria how to transfer control, the capabilities of other devices to handle control for a failed unit, and so forth. The criteria can include, but is not limited to, similar events, historical information, and so forth.

Additionally or alternatively, an implementation scheme (e.g., a rule, a policy, and so on) can be applied to control and/or regulate implementation of automatic display unit backup during failures of one more display units through the utilization of structure functional description language defined for control transfer and reversion after resolution of the failures, and so forth. In some implementations, based upon a predefined criterion, the rules-based implementation can automatically and/or dynamically interpret how to respond to a particular unit failure. In response thereto, the rule-based implementation can automatically interpret and carry out functions associated with transfer of control based on the graphic user interface objects by employing a predefined and/or programmed rule(s) based upon any desired criteria.

According to some implementations, the various systems can include respective interface components or display units that can facilitate the input and/or output of information to the one or more display units. For example, a graphical user interface can be output on one or more display units and/or mobile devices as discussed herein, which can be facilitated by the interface component. A mobile device can also be called, and can contain some or all of the functionality of a system, subscriber unit, subscriber station, mobile station, mobile, mobile device, device, wireless terminal, remote station, remote terminal, access terminal, user terminal, terminal, wireless communication device, wireless communication apparatus, user agent, user device, or user equipment (UE). A mobile device can be a cellular telephone, a cordless telephone, a Session Initiation Protocol (SIP) phone, a smart phone, a feature phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a laptop, a handheld communication device, a handheld computing device, a netbook, a tablet, a satellite radio, a data card, a wireless modem card, and/or another processing device for communicating over a wireless system. Further, although discussed with respect to wireless devices, the disclosed aspects can also be implemented with wired devices, or with both wired and wireless devices.

The display units (as well as other interface components discussed herein) can provide, a command line interface, a speech interface, Natural Language text interface, and the like. For example, a Graphical User Interface (GUI) can be rendered that provides a user with a region or means to load, import, select, read, and so forth, various requests and can include a region to present the results of the various requests. These regions can include known text and/or graphic regions that include dialogue boxes, static controls, drop-down-menus, list boxes, pop-up menus, as edit controls, combo boxes, radio buttons, check boxes, push buttons, graphic boxes, and so on. In addition, utilities to facilitate the information conveyance, such as vertical and/or horizontal scroll bars for navigation and toolbar buttons to determine whether a region will be viewable, can be employed. Thus, it might be inferred that the user did want the action performed.

The user can also interact with the regions to select and provide information through various devices such as a mouse, a roller ball, a keypad, a keyboard, a pen, gestures captured with a camera, a touch screen, and/or voice activation, for example. According to an aspect, a mechanism, such as a push button or the enter key on the keyboard, can be employed subsequent to entering the information in order to initiate information conveyance. However, it is to be appreciated that the disclosed aspects are not so limited. For example, merely highlighting a check box can initiate information conveyance. In another example, a command line interface can be employed. For example, the command line interface can prompt the user for information by providing a text message, producing an audio tone, or the like. The user can then provide suitable information, such as alphanumeric input corresponding to an option provided in the interface prompt or an answer to a question posed in the prompt. It is to be appreciated that the command line interface can be employed in connection with a GUI and/or Application Program Interface (API). In addition, the command line interface can be employed in connection with hardware (e.g., video cards) and/or displays (e.g., black and white, and Video Graphics Array (EGA)) with limited graphic support, and/or low bandwidth communication channels.

Methods that can be implemented in accordance with the disclosed subject matter, will be better appreciated with reference to the following flow charts and/or the above routing diagrams. While, for purposes of simplicity of explanation, the methods are shown and described as a series of blocks, it is to be understood and appreciated that the disclosed aspects are not limited by the number or order of blocks, as some blocks can occur in different orders and/or at substantially the same time with other blocks from what is depicted and described herein. Moreover, not all illustrated blocks can be required to implement the disclosed methods. It is to be appreciated that the functionality associated with the blocks can be implemented by software, hardware, a combination thereof, or any other suitable means (e.g. device, system, process, component, and so forth). Additionally, it should be further appreciated that the disclosed methods are capable of being stored on an article of manufacture to facilitate transporting and transferring such methods to various devices. Those skilled in the art will understand and appreciate that the methods could alternatively be represented as a series of interrelated states or events, such as in a state diagram. According to some implementations, the methods can be performed by a system comprising a processor. Additionally or alternatively, the method can be performed by a machine-readable storage medium and/or a non-transitory computer-readable medium, comprising executable instructions that, when executed by a processor, facilitate performance of the methods.

<FIG> illustrates an example, non-limiting, method <NUM> for facilitating the implementation of software units to manage user application failure modes and reversions in accordance with one or more embodiments described herein.

The method <NUM> starts, at <NUM>, with a determination whether a failure of a first controller has been detected. The failure can be determined based on receipt of a failure indication from the first controller or another component. In another example, the failure can be determined based on one or more precursors that indicate a failure is likely to occur (e.g., based on analysis of historical information).

If a failure of the first controller is detected ("YES"), at <NUM>, a control of a first display unit is transferred from the first controller to a second controller. At <NUM>, a determination is made whether the failure of the first controller has been resolved. If the failure has not been resolved ("NO"), at <NUM>, the control of the first display unit can be retained with the second controller. The method <NUM> can return to the determination at <NUM>. It is to be understood that the determination of whether the failure has been resolved and retaining the control at the second controller can be recursive. For example, operation of the first controller can be reviewed continuously, periodically, randomly, at various intervals, and so on.

If the determination at <NUM>, is that the failure of the first controller has been resolved ("YES)", at <NUM>, the control of the first display unit is transferred back to the first controller. The method <NUM> can return to <NUM> to monitor the first controller for another failure.

Alternatively or additionally, if the determination at <NUM> is that the first controller has not failed ("NO"), at <NUM> a determination is made whether the second controller has failed. If there is no failure of the second controller, the method <NUM> can return to <NUM> with an evaluation of the first controller.

However, if the determination at <NUM> is that the second controller has failed ("YES"), at <NUM>, a control of the second display unit is transferred form the second controller to the first controller. A determination is made, at <NUM>, whether the failure of the second controller has been resolved. If not ("NO"), at <NUM>, the control of the second display unit is retained at the first controller. The method <NUM> can return to <NUM> in a recursive manner to determine if the failure associated with the second controller has been resolved.

If, at <NUM>, it is determined that the failure of the second controller has been resolved ("YES"), the control of the second display unit is returned to the second controller, at <NUM>. The method <NUM> can return to <NUM> to determine if the second controller experiences another failure.

<FIG> illustrates a method <NUM> for detecting a failure at one or more controllers and automatically transferring a rendering of the data from the failed controllers to a remote device in accordance with one or more embodiments described herein.

At <NUM>, a first controller comprising a processor facilitates a rendering of first data on a first display unit. The first data can be rendered based on one or more software units (e.g., widgets). A second controller comprising a processor can facilitate a rendering of second data on a second display unit, at <NUM>. The second data can be rendered based various software units (e.g., widgets).

At <NUM>, a failure of the first controller of the second controller can be detected. Based on the failure, at <NUM>, control of the first display unit is transferred from the first controller and/or control of the second display unit is transferred from the second controller to a device external to the system (e.g., a remote device). For example, the device external to the system can be user equipment device authorized for use during a failure. In another example, the device external to the system can be a device associated with ground control.

According to an implementation, transferring the control can comprise facilitating, by the system, the rendering of the first data on the device in response to the failure of the first controller and/or the rendering of the second data on the device in response to the failure of the second controller.

In some implementations, there might be a failure of both the first controller and the second controller. Further to these implementations, in response to the failure of the first controller and the second controller, a rendering of the first data and the second data is facilitated by the device external to the system.

According to an implementation, the first display unit and the second display unit are located in an airplane cockpit and the device external to the system is a ground-based device. In accordance with some implementations, the device external to the system can be a user equipment device.

As discussed herein, provided is the use of an ARINC <NUM> No Service Monitor Widget, with a Connector Widget used under the ShowNoServiceIdent (or within a container), which can allow for automatic User Application Reversions upon system failures. A similar mechanism can be accomplished with a Watchdog Container, by allowing a connector on the ShowIfFailIdent parameter. Either mechanism can allow for an automatic reversion on the displays from a primary subsystem to a secondary subsystem.

Further, including an ARINC <NUM> Connector widget under the ShowNoServiceIdent branch (directly or within a container) of a NoServiceMonitor widget can allow for automatic reversion to secondary systems upon failure of a primary system. For example, a primary system can include a NoServiceMonitor widget at the top level of its ARINC <NUM> User Application Layer Definition. Upon failure of the primary system, a connector can be used to automatically revert to displaying data from a secondary system. By also including a NoServiceMonitor widget on the secondary system, with a similar connection, a tertiary system could also be introduced.

Flight Management Systems (FMS) are an example of where this system could be utilized. Typically, the pilot must flip a flight deck switch to revert their displays from one FMS to another FMS. If both FMSes have failed, a Backup Navigation (aka Alternate Navigation) system is provided that can take over the navigation function, as discussed herein. By the automatic reversion capabilities discussed herein, completely automatic failure reversion is possible without intervention by the flight crew.

In addition, by allowing for automatic display reversion, the flight deck does not need to install a separate switch to allow the flight crew to select reversion to secondary systems. Also, since the display system should be the same, or a higher level DO-178B certification (typically the display system would be a Level A certification), it can act as an independent monitor for subsystems connecting to it (for example a flight management system). This mechanism can also provide for backup navigation (also referred to as alternate navigation) systems to replace flight management system data directly on primary displays, rather than requiring an alternate display area.

According to some implementations, a similar mechanism can be designed using custom widgets or by adding new widgets not yet included in the ARINC <NUM> standard, as discussed herein.

Previous to an automatic reversion mechanism as discussed herein, the flight deck would have required a separate switch to select a secondary system. Alternatively, a separate application would be needed to monitor the health of the primary system to allow reversion to the secondary system upon a failure in the primary system. Since the display is a DO-<NUM> DAL Level A system, it suffices as a secondary system to perform the reversion.

In order to provide a context for the various aspects of the disclosed subject matter, <FIG> and <FIG> as well as the following discussion are intended to provide a brief, general description of a suitable environment in which the various aspects of the disclosed subject matter can be implemented.

With reference to <FIG>, an example environment <NUM> for implementing various aspects of the aforementioned subject matter includes a computer <NUM>. The computer <NUM> includes a processing unit <NUM>, a system memory <NUM>, and a system bus <NUM>. The system bus <NUM> couples system components including, but not limited to, the system memory <NUM> to the processing unit <NUM>. The processing unit <NUM> can be any of various available processors. Multi-core microprocessors and other multiprocessor architectures also can be employed as the processing unit <NUM>.

The system bus <NUM> can be any of several types of bus structure(s) including the memory bus or memory controller, a peripheral bus or external bus, and/or a local bus using any variety of available bus architectures including, but not limited to, <NUM>-bit bus, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Association bus (PCMCIA), and Small Computer Systems Interface (SCSI).

The system memory <NUM> includes volatile memory <NUM> and nonvolatile memory <NUM>. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer <NUM>, such as during start-up, is stored in nonvolatile memory <NUM>. By way of illustration, and not limitation, nonvolatile memory <NUM> can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable PROM (EEPROM), or flash memory. Volatile memory <NUM> includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM).

Computer <NUM> also includes removable/non-removable, volatile/non-volatile computer storage media. <FIG> illustrates, for example a disk storage <NUM>. Disk storage <NUM> includes, but is not limited to, devices like a magnetic disk drive, floppy disk drive, tape drive, Jaz drive, Zip drive, LS-<NUM> drive, flash memory card, or memory stick. In addition, disk storage <NUM> can include storage media separately or in combination with other storage media including, but not limited to, an optical disk drive such as a compact disk ROM device (CD-ROM), CD recordable drive (CD-R Drive), CD rewritable drive (CD-RW Drive) or a digital versatile disk ROM drive (DVD-ROM). To facilitate connection of the disk storage <NUM> to the system bus <NUM>, a removable or non-removable interface is typically used such as interface <NUM>.

It is to be appreciated that <FIG> describes software that acts as an intermediary between users and the basic computer resources described in suitable operating environment <NUM>. Such software includes an operating system <NUM>. Operating system <NUM>, which can be stored on disk storage <NUM>, acts to control and allocate resources of the computer <NUM>. System applications <NUM> take advantage of the management of resources by operating system <NUM> through program modules <NUM> and program data <NUM> stored either in system memory <NUM> or on disk storage <NUM>. It is to be appreciated that one or more embodiments of the subject disclosure can be implemented with various operating systems or combinations of operating systems.

A user enters commands or information into the computer <NUM> through input device(s) <NUM>. Input devices <NUM> include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit <NUM> through the system bus <NUM> via interface port(s) <NUM>. Interface port(s) <NUM> include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s) <NUM> use some of the same type of ports as input device(s) <NUM>. Thus, for example, a USB port can be used to provide input to computer <NUM>, and to output information from computer <NUM> to an output device <NUM>. Output adapters <NUM> are provided to illustrate that there are some output devices <NUM> like monitors, speakers, and printers, among other output devices <NUM>, which require special adapters. The output adapters <NUM> include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device <NUM> and the system bus <NUM>. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s) <NUM>.

Computer <NUM> can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) <NUM>. The remote computer(s) <NUM> can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer <NUM>. For purposes of brevity, only a memory storage device <NUM> is illustrated with remote computer(s) <NUM>. Remote computer(s) <NUM> is logically connected to computer <NUM> through a network interface <NUM> and then physically connected via communication connection <NUM>. Network interface <NUM> encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet/IEEE <NUM>, Token Ring/IEEE <NUM> and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL).

Communication connection(s) <NUM> refers to the hardware/software employed to connect the network interface <NUM> to the system bus <NUM>. While communication connection <NUM> is shown for illustrative clarity inside computer <NUM>, it can also be external to computer <NUM>. The hardware/software necessary for connection to the network interface <NUM> includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.

<FIG> is a schematic block diagram of a sample computing environment <NUM> with which the disclosed subject matter can interact. The sample computing environment <NUM> includes one or more client(s) <NUM>. The client(s) <NUM> can be hardware and/or software (e.g., threads, processes, computing devices). The sample computing environment <NUM> also includes one or more server(s) <NUM>. The server(s) <NUM> can also be hardware and/or software (e.g., threads, processes, computing devices). The servers <NUM> can house threads to perform transformations by employing one or more embodiments as described herein, for example. One possible communication between a client <NUM> and servers <NUM> can be in the form of a data packet adapted to be transmitted between two or more computer processes. The sample computing environment <NUM> includes a communication framework <NUM> that can be employed to facilitate communications between the client(s) <NUM> and the server(s) <NUM>. The client(s) <NUM> are operably connected to one or more client data store(s) <NUM> that can be employed to store information local to the client(s) <NUM>. Similarly, the server(s) <NUM> are operably connected to one or more server data store(s) <NUM> that can be employed to store information local to the servers <NUM>.

Reference throughout this specification to "one embodiment," or "an embodiment," means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of the phrase "in one embodiment," "in one aspect," or "in an embodiment," in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

As used in this disclosure, in some embodiments, the terms "component," "system," "interface," "manager," and the like are intended to refer to, or comprise, a computer-related entity or an entity related to an operational apparatus with one or more specific functionalities, wherein the entity can be either hardware, a combination of hardware and software, software, or software in execution, and/or firmware. As an example, a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, computer-executable instructions, a program, and/or a computer. By way of illustration and not limitation, both an application running on a server and the server can be a component.

One or more components can reside within a process and/or thread of execution and a component can be localized on one computer and/or distributed between two or more computers. In addition, these components can execute from various computer readable media having various data structures stored thereon. The components can communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal). As another example, a component can be an apparatus with specific functionality provided by mechanical parts operated by electric or electronic circuitry, which is operated by a software application or firmware application executed by one or more processors, wherein the processor can be internal or external to the apparatus and can execute at least a part of the software or firmware application. As yet another example, a component can be an apparatus that provides specific functionality through electronic components without mechanical parts, the electronic components can comprise a processor therein to execute software or firmware that confer(s) at least in part the functionality of the electronic components. In an aspect, a component can emulate an electronic component via a virtual machine, e.g., within a cloud computing system. While various components have been illustrated as separate components, it will be appreciated that multiple components can be implemented as a single component, or a single component can be implemented as multiple components, without departing from example embodiments.

In addition, the words "example" and "exemplary" are used herein to mean serving as an instance or illustration. Any embodiment or design described herein as "example" or "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, use of the word example or exemplary is intended to present concepts in a concrete fashion. As used in this application, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or. " That is, unless specified otherwise or clear from context, "X employs A or B" is intended to mean any of the natural inclusive permutations. In addition, the articles "a" and "an" as used in this application and the appended claims should generally be construed to mean "one or more" unless specified otherwise or clear from context to be directed to a singular form.

Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources. Various classification schemes and/or systems (e.g., support vector machines, neural networks, expert systems, Bayesian belief networks, fuzzy logic, and data fusion engines) can be employed in connection with performing automatic and/or inferred action in connection with the disclosed subject matter.

Claim 1:
A method, comprising:
predicting, by a system comprising a processor (<NUM>), a first failure of a first controller (<NUM>) using a predictive failure model and based on a parameter of the first controller (<NUM>), wherein the predictive failure model has been generated using machine learning employing probabilistic classification, wherein the first controller (<NUM>) is operatively coupled to a first onside layer component (<NUM>) and a first offside layer component (<NUM>), and wherein the first onside layer component (<NUM>) operates a first display unit (<NUM>);
automatically transferring, by the system, a first control of the first display unit (<NUM>) to a second controller operatively coupled to a second onside layer component (<NUM>) and a second offside layer component (<NUM>), the second onside layer component (<NUM>) operates a second display unit (<NUM>), and wherein the transferring comprises routing the first control of the first display unit (<NUM>) from the first onside layer component (<NUM>)to the second offside layer component (<NUM>);
rendering, by the system, first data associated with the first display unit (<NUM>) on the second display unit (<NUM>) concurrently with displaying second data associated with the second display unit (<NUM>), wherein the first display unit (<NUM>) and the second display unit (<NUM>) are redundancy units of a flight management system;
predicting, by the system and using the predictive failure model, a second failure of the second controller;
automatically transferring, by the system, the first control of the first display unit (<NUM>) and a second control of the second display unit (<NUM>) to a third controller that performs respective display functions of the first display unit (<NUM>) and the second display unit (<NUM>), wherein the third controller is associated with a user equipment device;
determining, by the system, that the second failure is resolved; and
automatically returning, by the system, the second control of the second display unit (<NUM>), wherein the third controller continues to perform a respective display function of the first display unit (<NUM>).