Patent Description:
Embodiments of the subject matter described herein relate generally to aircraft avionics. More particularly, embodiments of the subject matter relate to communication between applications resident on a device and applications resident in aircraft avionics.

Off-board applications on mobile devices, such as an electronic flight bag (EFB) or personal electronic device (PED), or in the cloud infrastructure can provide value added features that can improve the overall safety and efficiency of a flight. Off-board applications may be able provide operational insights to a flight crew or operators by taking advantage of data and/or flight plan information on-board the aircraft as well as data from external sources, such as weather.

Hence, it is desirable to provide systems and methods for providing operational insights to a flight crew or operators by taking advantage of data and/or flight plan information on-board the aircraft as well as data from external sources. Furthermore, other desirable features and characteristics of the present invention will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and the foregoing technical field and background. Documents cited during prosecution include <CIT>.

Dependent claims define preferred embodiments.

For the sake of brevity, conventional techniques related to communications, signal processing, data transmission, networking, signaling, control, and other functional aspects of the systems (and the individual operating components of the systems) may not be described in detail herein.

The subject matter described herein discloses apparatus, systems, techniques, and articles for increasing the capabilities of a connected flight management system (cFMS) infrastructure that provides a platform to access Enhanced Flight Management Data via a Bidirectional secured channel. External applications hosted on an EFB/PED (electronic flight bag and/or personal electronic device) such as a tablet computer, laptop computer, smart phone, etc., can utilize a proposed cFMS SDK (software development kit) to build trajectory-based features that increase the overall situational awareness and improve the operational efficiency for aircraft operators. These off-board features integrate avionics data with external real-time data such as weather, traffic etc. to provide potential opportunities for a safer and optimum flight. The cFMS SDK can provide multiple different levels of services to which an operator can subscribe which provide different levels of capabilities. For example, the cFMS SDK can provide a first level of services that provides data that supports a minimum set of features (e.g., Basic Flight Planning, TOLD functions, trajectory generation), a second level of services the supports a moderate set of features (e.g., engine out diversion assistance, event monitoring and alerting), and a third level of services that supports more advanced features (e.g., energy management services, weather avoidance functions).

An operator may not know which level of services is most appropriate for use with its aircraft. The proposed cFMS SDK can monitor flights flown by an operator's aircraft and record data that will allow the cFMS SDK to compare the level of one or more KPIs (key performance indicators) obtained using a subscribed to service level with the level of KPIs that could be attained if a different service level were subscribed to. The KPIs may include one or more of the following: fuel usage, flight time, flight distance, passenger comfort, flight cost, maintenance cost, carbon emissions, and others. This can allow operators to better understand the service level that is more beneficial for the operator based on the type of flights flown by its aircraft.

<FIG> is a block diagram of an example avionics environment <NUM>. The example avionics environment <NUM> includes on-board avionics systems <NUM> and off-board systems <NUM>. The on-board systems include on-board avionics systems <NUM>, such as an on-board flight management system (FMS) <NUM>, that communicate via one or more internal cockpit networks and an aircraft gateway <NUM> that is configured to provide flight data from the on-board avionics systems <NUM> to one or more requesting applications <NUM> residing on off-board systems <NUM> without interrupting the operation of the on-board avionics systems <NUM>.

The example aircraft gateway <NUM> is a network node that serves as an access point between the on-board avionics systems <NUM> and one or more requesting applications <NUM> (residing on one or more off-board systems <NUM>). The aircraft gateway <NUM> provides a connectivity channel between the on-board avionics systems <NUM> and the requesting applications <NUM>. The aircraft gateway <NUM> comprises one or more processors that are configured by programming instructions on non-transitory computer readable media. The aircraft gateway <NUM> may communicate using more than one protocol to connect to a plurality of different networks such as internal cockpit networks, other internal aircraft networks, external cloud based networks, external ground based networks, and others.

The example aircraft gateway <NUM> may include a node server that is configured to respond to queries from a plurality of requesting applications <NUM> for flight data generated from on-board avionics system functions. The flight data may include discrete data (e.g., cruise altitude, fuel on-board at destination), aggregated data (e.g., active 4D trajectory, flight summary), computational services data (e.g., 4D trajectory for a given flight plan, trip fuel/time for a flight mod request), and others. The 4D trajectory of an aircraft consists of the three spatial dimensions plus time as a fourth dimension. The node server is configured to receive, via a connectivity channel, a request from a client application <NUM> for flight data elements from a specified input flight plan and set of constraints; retrieve the specified input flight plan and set of constraints from the avionics functions; extract the requested data elements; and output the requested flight data elements via the connectivity channel to the client application <NUM>. The node server can maintain communication with multiple requesting applications. Secure communication protocols may be incorporated for use with the example aircraft gateway <NUM> and node server.

The off-board systems <NUM> are processor implemented systems that are not integrated into internal cockpit networks. The off-board systems <NUM> may include portable devices such as an EFB (electronic flight bag), tablet computer, laptop computer, smart phone, and others, which may be transported onto the aircraft by flight crew. The off-board systems <NUM> may include computing systems that execute as part of a ground or cloud based computing system. The off-board systems <NUM> may include computing systems that execute as part of a line replaceable unit (LRU) (e.g., radar or other avionics systems) that are not integrated into internal cockpit networks. The example off-board systems <NUM> includes one or more applications <NUM> that use flight data from the on-board avionics systems <NUM> provided via the aircraft gateway <NUM> to provide enhanced services and capabilities to flight crew members, maintenance personnel, aircraft operators, and others.

The example application <NUM> may comprise hardware, software or both and includes a software development kit (SDK) engine <NUM> for requesting and receiving data for use by the application <NUM> to provide the enhanced services and capabilities. The example SDK engine <NUM> is configured to request and receive flight data from the on-board avionics systems <NUM> via the aircraft gateway <NUM>. The flight data may include discrete data (e.g., cruise altitude, fuel on-board at destination), aggregated data (e.g., active 4D trajectory, flight summary), computational services data (e.g., 4D trajectory for a given flight plan, trip fuel/time for a flight mod request), and others.

The example SDK engine <NUM> is also configured to request and receive external real-time data such as weather, traffic etc. from external systems, such as a cloud-based database <NUM>, for use by the application <NUM> to provide the enhanced services and capabilities. The example SDK engine <NUM> is configured to access an external server <NUM>, that is communicatively coupled to the off-board system <NUM> to request and receive the external real-time data. The example external server <NUM> has access to the cloud-based database <NUM> via wireless communication equipment <NUM>, and the cloud-based database <NUM> may receive the external real-time data from a data server <NUM>.

The example SDK engine <NUM> is implemented using a processing component such as a controller. The processing component includes at least one processor and a computer-readable storage device or media encoded with programming instructions for configuring the processing component. The processor may be any custom-made 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 processing component, a semiconductor-based microprocessor (in the form of a microchip or chip set), any combination thereof, or generally any device for executing instructions.

The computer readable storage device or media may include volatile and nonvolatile storage in read-only memory (ROM), random-access memory (RAM), and keep-alive memory (KAM), for example. KAM is a persistent or non-volatile memory that may be used to store various operating variables while the processor is powered down. The computer-readable storage device or media may be implemented using any of a number of known memory devices such as PROMs (programmable read-only memory), EPROMs (electrically PROM), EEPROMs (electrically erasable PROM), flash memory, or any other electric, magnetic, optical, or combination memory devices capable of storing data, some of which represent executable programming instructions, used by the processing component.

<FIG> is a block diagram of an example avionics environment <NUM> wherein an application provides enhanced services through providing an output that advises whether improved mission performance may be achieved if additional sources of external real-time data are used or subscribed to. The example avionics environment <NUM> includes on-board systems <NUM> and off-board systems <NUM>. The on-board systems include on-board avionics systems <NUM>, such as an on-board flight management system (FMS) <NUM>, that communicate via one or more internal cockpit networks and an aircraft gateway <NUM> that is configured to provide flight data from on-board avionics systems <NUM> to one or more requesting applications <NUM> residing on off-board systems <NUM> without interrupting the operation of the on-board avionics systems <NUM>.

The off-board systems <NUM> are processor implemented systems that are not integrated into internal cockpit networks. The off-board systems <NUM> may include portable devices such as an EFB (electronic flight bag), tablet computer, laptop computer, smart phone, and others, which may be transported onto the aircraft by flight crew. The off-board systems <NUM> may include computing systems that execute as part of a ground or cloud based computing system. The off-board systems <NUM> may include computing systems that execute as part of a line replaceable unit (LRU) (e.g., radar or other avionics systems) that are not integrated into internal cockpit networks. The example off-board system <NUM> includes one or more applications <NUM> that use flight data from the on-board avionics systems <NUM> provided via the aircraft gateway <NUM> and external real-time data to provide enhanced services and capabilities to flight crew members, maintenance personnel, aircraft operators, and others.

The example application <NUM> includes a key performance indicator (KPI) SDK engine <NUM> for requesting and receiving data for use by the application <NUM> to provide the enhanced services and capabilities. The example KPI SDK engine <NUM> is configured to request and receive flight data from the on-board avionics systems <NUM> via the aircraft gateway <NUM> and to request and receive external real-time data such as weather, traffic etc. from external systems, such as a cloud-based database <NUM>, for use by the application <NUM> to provide the enhanced services and capabilities. The example KPI SDK engine <NUM> is configured to access an external server <NUM>, that is communicatively coupled to the off-board system <NUM> to request and receive the external real-time data. The example external server <NUM> has access to the cloud-based database <NUM> via wireless communication equipment <NUM>, and the cloud-based database <NUM> may receive the external real-time data from a data server <NUM>.

The example KPI SDK engine <NUM> is configured to monitor flights flown by an operator's aircraft and record data that will allow the example KPI SDK engine <NUM> to compare the level of KPIs obtained using a subscribed to service level with the level of KPIs that could be obtained if a different service level were subscribed to. This can allow operators to better understand the service level that is more beneficial for the operator based on the type of flights flown by its aircraft. The example SDK engine <NUM> includes an SDK flight tracker <NUM>, an SDK processor <NUM>, an SDK API/KPI (application programming interface/key performance indicator) analyzer <NUM>, an SDK advisor <NUM>, and a database and rule set <NUM>. For features that have not been subscribed by the operator, the SDK flight tracker <NUM> retrieves relevant information from the on-board avionics <NUM> as well as external services that may be required for evaluation of the features. The SDK processor <NUM> is configured to perform processing functions for the SDK engine <NUM>. The SDK API/KPI analyzer <NUM> is configured to compare the level of KPIs obtained using a subscribed to service level with the level of KPIs that could be obtained if a different service level were subscribed to. The SDK API/KPI analyzer <NUM> computes the relevant business logic for implementation of the feature. For features that are applicable and are resulting in potential savings, SDK API/KPI analyzer <NUM> records the information for further analytics. The SDK advisor <NUM> is configured to report results from KPI analysis and provide recommendations based on the KPI analysis to aircraft operators. The SDK advisor <NUM> collates all the feature level savings and provides various filtering mechanisms (by subscription service, feature, phase of flight etc.) through which the analysis of the subscription services and features can be performed. The database and rule set <NUM> is configured to store data and rules used when performing KPI analysis.

<FIG> is a block diagram depicting an example KPI application <NUM> on an aircraft. The example KPI application <NUM> includes a KPI SDK engine <NUM> for providing enhanced services and capabilities to flight crew and/or aircraft operators. The KPI SDK engine <NUM> receives flight data from an avionics system <NUM> via an aircraft gateway <NUM> and may receive external real-time data such as weather, traffic etc. from cloud services <NUM> and/or external services <NUM>. The KPI SDK engine <NUM> may also exchange data with various connected equipment <NUM> comprising one or more of a take-off and landing engine (TOLDe) <NUM>, flight management equipment (FME) <NUM>, and/or a navigation database (NAVDB) <NUM>. The connected equipment <NUM> may be on-board the aircraft or accessible via the cloud.

The example KPI SDK engine <NUM> is implemented using a processing component such as a controller. The processing component includes at least one processor and a computer-readable storage device or media encoded with programming instructions for configuring the processing component. The example KPI SDK engine <NUM> is configured to periodically receive flight data during a flight along an active flight path from one or more avionics systems on the aircraft; periodically receive real-time data along the active flight path at different flight levels from available service providers, the real-time data including real-time data that is available for a plurality of different service levels; periodically compute 4D trajectory variations for a plurality of flight levels based on the flight data and the real-time data; determine whether any of the computed trajectory variations would be beneficial with respect to a key performance indicator (KPI); record a 4D trajectory variation when it is determined, based on real-time data, that the trajectory variation would be beneficial; and recommend a 4D trajectory variation for use by flight crew during flight when it is determined, based on real-time data that is available for a subscribed to service level, that the trajectory variation would be beneficial. The flight crew may operate the aircraft in accordance with the recommended 4D trajectory variation. The example KPI SDK engine <NUM> is further configured to provide, at the conclusion of the flight, a dashboard display that indicates a potential increase in benefit with respect to the KPI at the plurality of service levels.

The example KPI SDK engine <NUM> comprises an SDK monitoring engine <NUM> comprising an SDK flight tracker <NUM>, an SDK processor <NUM>, an SDK API/KPI analyzer <NUM>, an SDK advisor <NUM>, and a database and rule set <NUM>. The SDK flight tracker <NUM> is configured to keep track of aircraft flight status from aircraft flight data received via the avionics systems <NUM>. The SDK processor <NUM> is configured to perform processing functions for the SDK monitoring engine <NUM>. The SDK API/KPI analyzer <NUM> is configured to compare the level of KPIs obtained using a subscribed to service level with the level of KPIs that could be obtained if a different service level were subscribed to. Reports can be generated from the SDK advisory system listing out the missed opportunities and subscriptions/features that need to be enabled to avail the same. The SDK advisor <NUM> is configured to report results from KPI analysis and provide recommendations based on the KPI analysis to an airline center <NUM>. The database and rule set <NUM> is configured to store data and rules used for performing KPI analysis.

<FIG> is a process flow chart depicting an example process <NUM> in an example KPI SDK engine in an aircraft for recording flight data, comparing the level of KPIs obtained using a subscribed to service level with the level of KPIs that could be obtained if a different service level were subscribed to, and reporting the results of the comparison. The order of operation within the process <NUM> is not limited to the sequential execution as illustrated in the figure but may be performed in one or more varying orders as applicable and in accordance with the present disclosure.

The example process <NUM> includes periodically retrieving flight data from avionics systems (operation <NUM>). The flight data may include aircraft state parameters (e.g., active flight plan, fuel on-board, maximum altitude, and others) and may be retrieved using avionics system (e.g., FMS) APIs.

Example process <NUM> includes extracting external data such as weather information along the active flight path at different flight levels from available service providers (operation <NUM>). The weather information may include wind information, temperature information, or other weather information.

Example process <NUM> includes periodically computing 4D trajectory variations for a plurality of flight levels (operation <NUM>). Periodically computing 4D trajectory variations may involve periodically computes 4D trajectory variations for a plurality of flight levels up to a maximum altitude and/or periodically computing 4D trajectory variations with the most recent weather information, such as wind information. The 4D trajectory variations may include altitude variations or others.

Example process <NUM> includes determining whether any of the computed trajectory variations would be beneficial with respect to a key performance indicator (KPI) (decision <NUM>). The determination is made based on the external data (e.g., wind information). The KPI may be related to fuel savings, fuel usage, flight time, and others.

If a trajectory variation has not been identified that would be beneficial with respect to a KPI based on the external data (no at decision <NUM>), then the process continues with periodically retrieving flight data from avionics systems (operation <NUM>).

If a trajectory variation has been identified that would be beneficial with respect to a KPI based on the external data (yes at decision <NUM>), then the process includes recording the 4D trajectory variation (operation <NUM>). Recording the 4D trajectory variation may include logging the flight level along with other parameters such as the estimated fuel on board (FOB) at the destination, estimated time of arrival (ETA), and others.

Example process <NUM> includes determining if a logical state of flight to end logging operations has been reached (decision <NUM>). If the logical state of flight to end logging operations has not been reached (no at decision <NUM>), then the process continues with periodically retrieving flight data from avionics systems (operation <NUM>).

If the logical state of flight to end logging operations has been reached (yes at decision <NUM>), then the process <NUM> includes, providing at the conclusion of the flight a dashboard display that indicates a potential increase in benefit with respect to the KPI at the plurality of service levels (operation <NUM>). The dashboard display may provide, for example, the overall fuel savings along with the time and position along the flight path where it would have been applicable.

Example process <NUM> may further include recording flight specific service/feature based savings in an airline repository (operation <NUM>) and periodically generating a report for operator analysis of all SDK services (operation <NUM>). The operations <NUM> are performed during flight and operations <NUM>, <NUM>, and <NUM> may be performed after the flight.

<FIG> is diagram depicting an example KPI SDK service dashboard graphical user interface (GUI) <NUM> that an example KPI SDK engine may generate for transmission and display on a user device at an airline center. In this example, the example KPI SDK engine SDK engine provides three levels of service, a silver level, a gold level, and a platinum level as indicated by available service level indicators <NUM>. Also, in this example, the airline operator subscribes to a silver service level as indicated by the subscribed to service level indicator <NUM>. The example SDK service dashboard GUI provides a pie chart graphical element <NUM> that shows potential fuel savings that may be attained using the three provided service levels: <NUM> Kgs for the silver service level, <NUM> Kgs for the gold service level, and <NUM> Kgs for the platinum service level for a specific flight <NUM>. The example SDK service dashboard GUI additionally provides a graphical indication <NUM> that provides a feature-wise breakdown of how the potential fuel savings could be obtained for the non-subscribed service levels.

<FIG> is a process flow chart depicting another example process <NUM> for providing enhanced services for an aircraft operator through the use of an example KPI SDK engine. The example process <NUM> includes receiving, by the KPI SDK engine, an identification of a level of service (e.g., silver) to which an operator is subscribed for basic flight planning features (operation <NUM>).

During flight, the KPI SDK engine evaluates opportunities for flight enhancement and/or potential savings using the level of service (e.g., silver) to which the aircraft is subscribed plus opportunities for flight enhancement and/or potential savings using other levels of service (e.g., gold - a higher level or bronze a lower level) to which the aircraft is not subscribed (operation <NUM>). During flight, the KPI SDK engine periodically retrieves Aircraft state parameters (such as the Active Flight Plan, Fuel on-board, Maximum altitude, and other Aircraft state parameters) from on-board systems (e.g., the FMS using FMS APIs) (operation <NUM>). During flight, the KPI SDK engine also extracts external data such as Weather (Wind/Temp) information along the Active flight path at different flight levels from available service providers (operation <NUM>). During flight, the KPI SDK engine periodically computes 4D trajectory for various flight levels (e.g., from FL015 to the Maximum Altitude) with the latest external data (e.g., wind information) (operation <NUM>). During flight, if a flight level is identified that could provide flight enhancement and/or potential savings (e.g., fuel savings due the wind information), the KPI SDK engine logs the flight level along with other parameters like the estimated FOB, ETA etc. at destination (operation <NUM>). During flight, the KPI SDK engine continues to periodically evaluate various flight levels for flight enhancement and/or potential savings until a logical state of flight is reached (e.g., <NUM> before top of descent) (operation <NUM>).

After landing, the KPI SDK engine determines an overall potential flight enhancement and/or potential savings for various service levels if beneficial flight levels were used along with the time and position along the flight path where making use of the beneficial flight levels would have been applicable (operation <NUM>). After landing, the KPI SDK engine records the overall potential flight enhancement and/or potential savings that can be attained for various service levels if beneficial flight levels were used in an aircraft operator specific repository (operation <NUM>). Periodically, the KPI SDK engine generates a report for operator review regarding potential flight enhancement and/or potential savings that can be attained for various service levels (operation <NUM>).

<FIG> is a block diagram of another example avionics environment <NUM> wherein an application provides enhanced services during an aircraft flight. The example avionics environment <NUM> includes on-board systems <NUM>, on aircraft mobile (e.g., EFB or PED) applications <NUM>, and cloud-based applications <NUM>. The example on-board systems include one or more on-board avionics systems such as a TOLD (take-off and landing) system <NUM>, an FMS <NUM>, and/or others. An Aircraft Data Access Port/Partition (ADAP) <NUM> and a Gateway <NUM> are also provided to provide aircraft the mobile applications <NUM> and/or and the cloud-based applications <NUM> with access to the one or more avionics systems (e.g., the TOLD system <NUM> and/or the FMS <NUM>).

The apparatus, systems, techniques, and articles disclosed herein can facilitate continuously collecting the most recent data from on-board avionics systems (e.g., FMS <NUM>) and providing the same to off-board applications <NUM> embedded in the mobile applications <NUM> or off-board applications <NUM> hosted on a remote server (cloud) <NUM> via a connected FMS (cFMS) SDK <NUM>/<NUM> for application developers ease of use. Applications <NUM>/<NUM> requiring the most recent data may register for this function, select parameters from a list of parameters that can be synchronized from a super set of avionics systems (e.g., FMS <NUM>) data, and specify the duration of synchronization.

During flight, the cFMS SDK <NUM>, <NUM> continuously monitors the avionics systems (e.g., FMS <NUM>) for the parameters that have been registered for synchronization and based on the duration of synchronization retrieves the information from avionics systems (e.g., FMS <NUM>) and provides it to the clients (apps <NUM>, <NUM>) in a prescribed form/interface (e.g., json, Object etc.. The example cFMS SDK <NUM>, <NUM> has internal mechanisms (temporary storage of data, event trigger logic, data comparison for change detection etc.) to manage the synchronization across various apps (<NUM>, <NUM>) and reduce the data retrieval from the avionics systems (e.g., FMS <NUM>). The connectivity between the cFMS SDK (<NUM>, <NUM>) and the avionics systems (e.g., FMS <NUM>) is via an Aircraft Data Access Port/Partition (ADAP) <NUM> and Gateway Hardware <NUM> that connects the mobile applications <NUM> or Cloud based applications <NUM> with the on-board avionics systems (e.g., FMS <NUM>).

<FIG> is a block diagram depicting an example cFMS SDK <NUM> with internal mechanisms to manage the synchronization across various apps <NUM> and reduce the data retrieval from the on-board avionics systems <NUM>. The example cFMS SDK <NUM> is implemented using a processing component such as a controller. The processing component includes at least one processor and a computer-readable storage device or media encoded with programming instructions for configuring the processing component. The example cFMS SDK <NUM> is configured to set up triggering logic to identify a beginning point and ending point for collecting a set of avionics system data during a flight; systematically retrieve information for use by the triggering logic to identify the beginning point and the ending point; when the beginning point is reached, systematically repeat retrieving the set of avionics systems data and sending, to an off-board application, data from the set of avionics system data that has changed state from prior data sent to the off-board application; and when the ending point is reached, cease sending data from the set of avionics system data to the off-board application.

The example cFMS SDK <NUM> includes an FMS database <NUM>, a data synchronization processor <NUM>, an event monitor <NUM>, an application registry <NUM>, and a format processor <NUM>. The FMS database <NUM> is configured for the temporary storage of data. The data synchronization processor <NUM> and event monitor <NUM> are configured to implement the trigger logic to identify a beginning point and ending point for collecting a set of avionics system data during a flight, determine which of the set of avionics system data was not previously sent to the off-board application or changed state since previously being sent to the off-board application, and send to the off-board application data from the set of avionics system data that was not previously sent to the off-board application or changed state since previously being sent to the off-board application. The application registry <NUM> is configured for use by an application <NUM> to register for service, select parameters from a list of parameters that can be synchronized from a super set of avionics systems data (e.g., data from FMS <NUM>), and specify the duration of synchronization. The format processor <NUM> is configured for providing data to the applications <NUM> in a format that the applications can understand.

<FIG> is a process flow chart depicting an example process <NUM> in an aircraft for continuously collecting recent data from avionics systems and providing the data to off-board applications. The order of operation within the process <NUM> is not limited to the sequential execution as illustrated in the figure but may be performed in one or more varying orders as applicable and in accordance with the present disclosure.

The example process <NUM> may include receiving a request from the off-board application to receive a set of avionics system data beginning at a beginning point and ending at the ending point (operation <NUM>) and registering the off-board application to receive the set of avionics system data beginning at the beginning point and ending at the ending point during the flight (operation <NUM>). The data from the set of avionics systems data may include flight data computed from the avionics system data. Receiving the request may include receiving a request from the off-board application to receive the flight data beginning at the beginning point and ending at the ending point and registering the off-board application to receive the flight data beginning at the beginning point and ending at the ending point during the flight.

The example process <NUM> includes setting up triggering logic to identify the beginning point and ending point for collecting a set of avionics system data during a flight (operation <NUM>).

The example process <NUM> includes systematically retrieving information for use by the triggering logic to identify the beginning point and the ending point (operation <NUM>). Systematically retrieving information for use by the triggering logic to identify the beginning point and the ending point may include: systematically retrieving information for use by the triggering logic from aircraft systems, applying the retrieved information to the triggering logic, and determining from applying the retrieved information to the triggering logic when the beginning point is reached.

The example process <NUM> includes, when the beginning point is reached, systematically repeating: retrieving the set of avionics systems data and sending, to an off-board application, data from the set of avionics system data that has changed state from prior data sent to the off-board application (operation <NUM>). Sending data from the set of avionics system data that has changed state from prior data sent to the off-board application may include: determining which of the set of avionics system data was not previously sent to the off-board application or changed state since previously being sent to the off-board application and sending to the off-board application data from the set of avionics system data that was not previously sent to the off-board application or changed state since previously being sent to the off-board application.

The data from the set of avionics systems data may include flight data computed from the avionics system data. In this case, the sending data from the set of avionics system data that has changed state from prior data sent to the off-board application may include: computing the flight data from the avionics systems data; and sending the computed flight data to the off-board application. The sending the computed flight data to the off-board application may include: determining which of the flight data was not previously sent to the off-board application or changed state since previously being sent to the off-board application and sending to the flight data that was not previously sent to the off-board application or changed state since previously being sent to the off-board application.

The example process <NUM> includes, when the ending point is reached, cease sending data from the set of avionics system data to the off-board application (operation <NUM>).

The example process <NUM> includes a Weather Hazard Avoidance (WHA) application registering with a cFMS SDK (operation <NUM>). The WHA application may register for the active flight plan, aircraft state, active leg and may register via a callback function.

Example process <NUM> includes the WHA application registering with cFMS SDK for the Active Flight plan, Aircraft State, Active Leg for the cruise flight phase (operation <NUM>).

Example process <NUM> includes cFMS SDK setting up triggering logic to identify the Cruise Flight Phase (operation <NUM>).

Example process <NUM> includes cFMS continuously (pre-configured periodicity) retrieving the information required for the triggering logic (Flight phase) from FMS (operation <NUM>).

Example process <NUM> includes determining if the Cruise Flight phase event has been triggered (decision <NUM>).

Example process <NUM> includes determining if the Descent Flight phase event has been triggered (decision <NUM>).

Example process <NUM> includes exiting synchronization (operation <NUM>) if the Descent Flight phase event has been triggered.

Example process <NUM> includes cFMS SDK retrieving the Active Flight plan, Aircraft State and Active leg information from FMS (operation <NUM>) if the Cruise Flight phase event has been triggered.

Example process <NUM> includes determining if change in Active Flight plan from the previous sample of the Flight plan is detected (decision <NUM>).

Example process <NUM> includes Active Flight plan is provided to the application via call back function (operation <NUM>) if change in Active Flight plan from the previous sample of the Flight plan is detected.

Example process <NUM> includes Current Aircraft State is provided to the application via call back function (operation <NUM>).

Example process <NUM> includes determining if a change in Active leg from the previous sample of the Active leg is detected (decision <NUM>).

Example process <NUM> includes providing new active leg to the application via call back function (operation <NUM>) if a change in Active leg from the previous sample of the Active leg is detected.

Example process <NUM> includes providing Current Aircraft State to the application via call back function (decision <NUM>).

Example process <NUM> includes WHA application evaluating the weather along the Active flight plan from the Active leg to look for any weather hazard (operation <NUM>).

Example process <NUM> includes determining if weather hazard has been detected along the Active Flight plan (decision <NUM>).

Example process <NUM> includes WHA evaluating multiple routes and computing the trajectory for each route with the current aircraft state to decide upon the most optimum reroute option (operation <NUM>) if weather hazard has been detected along the Active Flight plan.

The example process <NUM> includes Flight Tracking System registering with cFMS SDK for the ETA at Destination data via a callback function (operation <NUM>).

The example process <NUM> includes Flight Tracking System registering with cFMS SDK for the ETA at Destination for the duration of flight between take-off to touchdown (operation <NUM>).

The example process <NUM> includes cFMS SDK setting up triggering logic to identify the Take-off and touchdown point (operation <NUM>).

The example process <NUM> includes cFMS continuously (pre-configured periodicity) retrieving the information required for the triggering logic (Flight phase, Weight on Wheels etc.) from FMS (operation <NUM>).

The example process <NUM> includes determining if take-off event has been triggered (decision <NUM>).

The example process <NUM> includes determining if touchdown event has been triggered (decision <NUM>).

The example process <NUM> includes exiting synchronization (operation <NUM>) if touchdown event has been triggered.

The example process <NUM> includes cFMS SDK retrieving the ETA at destination from FMS (operation <NUM>) if take-off event has been triggered.

The example process <NUM> includes determining if the difference in ETA from previous sample is outside a pre-set threshold (decision <NUM>).

The example process <NUM> includes ETA information being provided to the application via the call back function (operation <NUM>) if the difference in ETA from previous sample is outside a pre-set threshold.

The example process <NUM> includes Flight Tracking System retrieving the ETA at destination information and updates the website/portal with the latest info (operation <NUM>).

Claim 1:
A method in an aircraft for providing flight data to off-board applications, the method comprising:
receiving (<NUM>) a registration from an off-board application, the registration including a request to receive a set of avionics system data beginning at a beginning point and ending at an ending point;
registering (<NUM>) the off-board application to receive the set of avionics system data beginning at the beginning point and ending at the ending point during a flight;
setting (<NUM>) up triggering logic to identify the beginning point and the ending point for collecting the set of avionics system data during the flight;
systematically retrieving (<NUM>) information for use by the triggering logic to identify the beginning point and the ending point;
when the beginning point is reached, systematically repeating (<NUM>):
retrieving the set of avionics systems data, and
sending, to the off-board application, data from the set of avionics system data that has changed state from prior data sent to the off-board application; and
when the ending point is reached, cease (<NUM>) sending data from the set of avionics system data to the off-board application.