Patent Description:
An aircraft data gateway enables two-way communication between external applications and on-board cockpit avionics. In the connected environment, the aircraft data gateway is used for real-time updates to mission parameters from external applications and/or services such as Electronic Flight Bag (EFB), Open World Computer (OWC), a Cloud application, and Airline Operational Control (AOC), for example, to improve the operational efficiency and safety of routine flight operations. The mission parameters may include information such as flight plan modifications, speed and/or altitude profile changes, wind and/or temperature information, cost index, or time constraints, for example. With an increase in data being sent to avionics from non-certified applications from EFB, OWC, and Cloud, there is a risk of data causing an inadvertent effect to the flight mission.

The present disclosure is directed to overcoming one or more of these above-referenced challenges.

<CIT> relates generally to cyber-security, and, more specifically, to methods and systems for use in identifying cyber-security threats to aviation platforms and infrastructures.

<CIT> relates to aircraft systems, and specifically to automated communication with air traffic control operators (e.g. an air traffic controller) in an air traffic control system.

In some aspects, the techniques described herein relate to a system to filter a data transfer between an external application and a component of a vehicle, as defined in claim <NUM>.

In some aspects, the techniques described herein relate to a controller-implemented method to filter a data transfer between an external application and a component of a vehicle, as defined in claim <NUM>.

In some aspects, the techniques described herein relate to a non-transitory computer readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform the method according to claim <NUM>.

The objects and advantages of the disclosed embodiments will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.

Various embodiments of the present disclosure relate generally to a system to filter a data transfer between an external application and a component of a vehicle.

The terminology used below may be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific examples of the present disclosure. Indeed, certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such in this Detailed Description section.

A vehicle as described below is an aircraft, and a component of the vehicle is an avionics component.

An aircraft data gateway enables two-way communication between an external application and on-board cockpit avionics. In the connected environment, the aircraft data gateway is used for real-time updates to mission parameters from external applications and/or services such as Electronic Flight Bag (EFB), Open World Computer (OWC), a Cloud application, Aeronautical Radio Facilities and Parts Provisioning System (APPS), and Airline Operational Control (AOC), for example, to improve the operational efficiency and safety of routine flight operations. The mission parameters may include information such as flight plan modifications, speed and/or altitude profile changes, wind and/or temperature information, cost index, or time constraints, for example.

With an increase in data being sent to avionics from non-certified applications from EFB, OWC, and Cloud, there is a risk of data causing an inadvertent effect to the flight mission. Although cybersecurity algorithms in gateways may protect the avionics from malicious and unauthorized data, the algorithms do not perform a contextual integrity check to prevent data that may appear valid from causing harm to the avionics.

The disclosed systems and methods may provide a high integrity domain-specific data broker engine to filter requests from external applications based on the mission or context of the flight. This engine acts as a fail-safe mechanism for avionics to pre-process the data received from the external applications. Data requests not intended for the flight in the current context are eliminated at the gateway level and are not passed to the avionics. The disclosed systems and methods may ensure that only relevant data is sent to avionics. The disclosed systems and methods may be implemented in a gateway and enable high integrity data transfers between external applications and avionics.

The disclosed systems and methods may be a failsafe validation engine that is hosted in a gateway. The failsafe validation engine may include a rule base and domain-specific computational logic for validating all data uploads to a line-replaceable unit (LRU) in the avionics. The failsafe validation engine acts as a filter mechanism to eliminate unintended or inconsequential data uploads from external applications and/or services to the avionics. For example, for a flight level change request from an Electronic Flight Bag, the failsafe validation engine may validate the requested flight level against the maximum altitude that the aircraft can fly based on the current configuration. The maximum altitude may be obtained from the avionics, and when the requested flight level from the Electronic Flight Bag is greater than the obtained maximum altitude, the request may be rejected by the failsafe validation engine. When the requested flight level is less than the maximum altitude, the requested flight level may be uploaded to the avionics. Additionally, the failsafe validation engine may check the fuel or time saved due to the requested flight level. If the savings is not significant, such as below a threshold savings value, the failsafe validation engine may reject the requested flight level.

The failsafe validation engine includes a rule engine, a schematic parser, and a context analyzer.

The rule engine receives updated rules from the context analyzer. For example, when the context analyzer determines that the current flight phase is cruise, the updated rules may be to reject an incoming takeoff performance message, and accept an incoming landing performance message. Based on the updated rules, the rule engine processes input data, such as a takeoff performance message or a landing performance message, for example. Upon successful processing, the processed data is
sent to the schematic parser. For example, processed data in may be the landing performance message after the message has been successfully validated by the rule engine, and successful processing may be for any landing performance message when the flight phase is cruise. Only after each of the rules applicable for the landing performance message are satisfied will the processing become successful. Upon unsuccessful processing, the rule engine may send an error message in a notification. For example, unsuccessful processing may be the rule engine rejecting a takeoff performance message during cruise. As an Example, the error message may be "takeoff performance cannot be modified during the flight.

The schematic parser receives the processed data from the rule engine upon successful processing by the rule engine. The schematic parser processes and parses parse the data based on one or more schematics defined for the avionics. For example, a schematic may refer to an object model. For a landing performance message, for example, the message may be parsed to obtain approach speed, flap speed, and descent speed, and successful processing may refer to all the required landing performance data and format being obtained after parsing. Upon successful processing, the schematic parser may send the parsed data to an output process to encode the parsed data to send to respective LRUs. For example, encoding may refer to formatting the input data as prescribed by the respective LRU. For example, an LRU may have following format: "word1: msg id / word2: flap1 speed / word3: flap2 speed / word4: approach speed". Upon unsuccessful processing, the schematic parser may send an error message in a notification.

The context analyzer may receive mission and external context data from an LRU Broadcaster and an external data database, respectively. For example, the mission and external context data may be flight phase and flight level directly obtained from an LRU. For example, the external data may include flight information region, weather, and traffic. For example, the external database may be a repository of all the external context data received from multiple sources. For example, weather information may be received from multiple weather sources globally and stored in the external database. The context analyzer may process the mission data and external context data, and send updated rules to the rule engine based on the processed mission data and external context data.

As an example, a takeoff performance message may be sent to the aircraft during a climbing phase of a flight. Here, the EFB may send the takeoff performance message to the gateway with a request to update the avionics. The input processor may receive the message and decode the data into a data model to process the data. The input processor may send the data model to the failsafe validation engine. The context analyzer may update the mission data (the phase of the flight) rule engine of the failsafe validation engine. When the rule engine processes the data model from the input processor, the failsafe validation engine may reject the request from the EFB, and provide a notification that the takeoff performance message is out of context.

As another example, a route modification flight plan may be sent to the aircraft during a cruise phase of a flight. Here, the EFB may send the route modification flight plan message to gateway with a request to update the avionics. The input processor may receive the message and decode the data into a data model to process the data. The input processor may send the data model to the failsafe validation engine. The context analyzer may update the mission data (such as origin/destination, phase of flight, flight level, for example) of the failsafe validation engine. When the rule engine processes the data model from the input processor, the failsafe validation engine may process the request successfully and send the processed request to the schematic parser. The schematic parser may parse the processed data based on one or more schematics for the avionics, and upon successful parsing, may send the parsed data to the output processor. The output processor may encode the parsed data into a suitable format for the avionics and send to a respective LRU for processing.

<FIG> depicts an exemplary system infrastructure for a data adapter in a gateway to transfer data between an external application and a component of a vehicle, according to one or more embodiments.

As shown in <FIG>, vehicle <NUM> may include gateway <NUM> and components <NUM>. When vehicle <NUM> is an aircraft, for example, components <NUM> may be avionics of the aircraft. Gateway <NUM> may provide bidirectional data transfer between external application <NUM> and components <NUM>. The vehicle <NUM> is an aircraft, and the external application <NUM> is an Electronic Flight Bag (EFB). For example, gateway <NUM> may transfer a flight plan from external application <NUM> to first LRU <NUM> in components <NUM>, and gateway <NUM> may transfer LRU data from first LRU <NUM> in components <NUM> to external application <NUM>. Gateway <NUM> may enable high integrity data transfers between external application <NUM> and components <NUM>.

Components <NUM> may include first LRU <NUM>, second LRU <NUM>, and component broadcaster <NUM>. Component broadcaster <NUM> may be an LRU broadcaster. Components <NUM> may be equipment such as control, monitoring, communication, navigation, weather, and anti-collision systems, for example, for vehicle <NUM>. First LRU <NUM> and second LRU <NUM> may be modular components of vehicle <NUM>.

Gateway <NUM> may include controller <NUM>, first slot <NUM>, second slot <NUM>, Universal Serial Bus port <NUM>, and external data database <NUM>. Controller <NUM> may control the operations of gateway <NUM>, and is further described below. Gateway <NUM> may communicate with first LRU <NUM>, second LRU <NUM>, and component broadcaster <NUM> via one or more of first slot <NUM>, second slot <NUM>, or Universal Serial Bus port <NUM>.

Data adapter <NUM> may include input processor <NUM>, failsafe validation engine <NUM>, and output processor <NUM>. As shown in <FIG>, data may be transferred between external application <NUM> and gateway <NUM> of vehicle <NUM> in a bidirectional manner, and data may be transferred between gateway <NUM> and components <NUM> in a bidirectional manner.

Input processor <NUM> may include interface handler <NUM>, data decoder <NUM>, and file handler <NUM>. Interface handler <NUM> may coordinate communication between data adapter <NUM> and external application <NUM>. For example, interface handler <NUM> may coordinate a transmission of a flight plan in a. sfp format from external application <NUM>. Data decoder <NUM> may format data for processing between input processor <NUM> and failsafe validation engine <NUM>. For example, data decoder <NUM> may format the data received by input processor <NUM> in the. sfp format from external application <NUM> into an. xml file for processing by failsafe validation engine <NUM>. File handler <NUM> may store one or more input files from external application <NUM> for processing.

Failsafe validation engine <NUM> includes rules engine <NUM>, schematic parser <NUM>, and context analyzer <NUM>. Rules engine <NUM> receives updated rules from context analyzer <NUM>. Based on the updated rules, rules engine <NUM> processes input data. Upon successful processing, the processed data is sent to schematic parser <NUM>. Upon unsuccessful processing, rules engine <NUM> may send an error message in a notification. Schematic parser <NUM> receives processed data from rules engine <NUM> upon successful processing by rules engine <NUM>. Schematic parser <NUM> processes and parses the data based on one or more schematics defined for components <NUM>. Upon successful processing, schematic parser <NUM> may send the parsed data to output processor <NUM>. Upon unsuccessful processing, schematic parser <NUM> may send an error message in a notification. Context analyzer <NUM> may receive mission data from component broadcaster <NUM>, and may receive external context data from external data database <NUM>. Context analyzer <NUM> may process the mission data and external context data, and send updated rules to rules engine <NUM> based on the processed mission data and external context data.

Output processor <NUM> may include common object model <NUM> and data encoder <NUM>. Common object model <NUM> may store one or more object models for communicating with components <NUM>. Data encoder <NUM> may encode, using an object model in common object model <NUM>, data in output processor <NUM> into a suitable format for components <NUM>. The encoded data may be sent from data encoder <NUM> using interface handler <NUM>, for example.

As shown in <FIG>, failsafe validation engine <NUM> includes rules engine <NUM>, schematic parser <NUM>, and context analyzer <NUM>.

Rules engine <NUM> receives updated rules from context analyzer <NUM>. Based on the updated rules, rules engine <NUM> processes input model data received from input processor <NUM>. Upon successful processing, the processed data is sent to schematic parser <NUM>. Upon unsuccessful processing, rules engine <NUM> may send an error message in a notification.

Schematic parser <NUM> receives the processed data from rules engine <NUM> upon successful processing by the rule engine. Schematic parser <NUM> processes and parses the data based on one or more schematics defined for components <NUM>. Upon successful processing, schematic parser <NUM> may send the parsed data to output processor <NUM> to encode the parsed data to send to components <NUM>, such as to first LRU <NUM> and/or second LRU <NUM>. Upon unsuccessful processing, schematic parser <NUM> may send an error message in a notification.

Context analyzer <NUM> may receive mission data and external context data from component broadcaster <NUM> and external data database <NUM>, respectively. Context analyzer <NUM> may process the mission data and external context data, and send updated rules to rules engine <NUM> based on the processed mission data and external context data.

<FIG> depicts an implementation of a controller <NUM> that may execute techniques presented herein, according to one or more embodiments.

The controller <NUM> may include a set of instructions that can be executed to cause the controller <NUM> to perform any one or more of the methods or computer based functions disclosed herein. The controller <NUM> may operate as a standalone device or may be connected, e.g., using a network, to other computer systems or peripheral devices.

In a networked deployment, the controller <NUM> may operate in the capacity of a server or as a client in a server-client user network environment, or as a peer computer system in a peer-to-peer (or distributed) network environment. The controller <NUM> can also be implemented as or incorporated into various devices, such as a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile device, a palmtop computer, a laptop computer, a desktop computer, a communications device, a wireless telephone, a land-line telephone, a control system, a camera, a scanner, a facsimile machine, a printer, a pager, a personal trusted device, a web appliance, a network router, switch or bridge, or any other machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. In a particular implementation, the controller <NUM> can be implemented using electronic devices that provide voice, video, or data communication. Further, while the controller <NUM> is illustrated as a single system, the term "system" shall also be taken to include any collection of systems or sub-systems that individually or jointly execute a set, or multiple sets, of instructions to perform one or more computer functions.

As illustrated in <FIG>, the controller <NUM> may include a processor <NUM>, e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both. The processor <NUM> may be a component in a variety of systems. For example, the processor <NUM> may be part of a standard computer. The processor <NUM> may be one or more general processors, digital signal processors, application specific integrated circuits, field programmable gate arrays, servers, networks, digital circuits, analog circuits, combinations thereof, or other now known or later developed devices for analyzing and processing data. The processor <NUM> may implement a software program, such as code generated manually (i.e., programmed).

The controller <NUM> may include a memory <NUM> that can communicate via a bus <NUM>. The memory <NUM> may be a main memory, a static memory, or a dynamic memory. The memory <NUM> may include, but is not limited to computer readable storage media such as various types of volatile and non-volatile storage media, including but not limited to random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, magnetic tape or disk, optical media and the like. In one implementation, the memory <NUM> includes a cache or random-access memory for the processor <NUM>. In alternative implementations, the memory <NUM> is separate from the processor <NUM>, such as a cache memory of a processor, the system memory, or other memory. The memory <NUM> may be an external storage device or database for storing data. Examples include a hard drive, compact disc ("CD"), digital video disc ("DVD"), memory card, memory stick, floppy disc, universal serial bus ("USB") memory device, or any other device operative to store data. The memory <NUM> is operable to store instructions executable by the processor <NUM>. The functions, acts or tasks illustrated in the figures or described herein may be performed by the processor <NUM> executing the instructions stored in the memory <NUM>. The functions, acts or tasks are independent of the particular type of instructions set, storage media, processor or processing strategy and may be performed by software, hardware, integrated circuits, firm-ware, microcode and the like, operating alone or in combination. Likewise, processing strategies may include multiprocessing, multitasking, parallel processing and the like.

As shown, the controller <NUM> may further include a display <NUM>, such as a liquid crystal display (LCD), an organic light emitting diode (OLED), a flat panel display, a solid-state display, a cathode ray tube (CRT), a projector, a printer or other now known or later developed display device for outputting determined information. The display <NUM> may act as an interface for the user to see the functioning of the processor <NUM>, or specifically as an interface with the software stored in the memory <NUM> or in the drive unit <NUM>.

Additionally or alternatively, the controller <NUM> may include an input device <NUM> configured to allow a user to interact with any of the components of controller <NUM>. The input device <NUM> may be a number pad, a keyboard, or a cursor control device, such as a mouse, or a joystick, touch screen display, remote control, or any other device operative to interact with the controller <NUM>.

The controller <NUM> may also or alternatively include drive unit <NUM> implemented as a disk or optical drive. The drive unit <NUM> may include a computer-readable medium <NUM> in which one or more sets of instructions <NUM>, e.g. software, can be embedded. Further, the instructions <NUM> may embody one or more of the methods or logic as described herein. The instructions <NUM> may reside completely or partially within the memory <NUM> and/or within the processor <NUM> during execution by the controller <NUM>. The memory <NUM> and the processor <NUM> also may include computer-readable media as discussed above.

In some systems, a computer-readable medium <NUM> includes instructions <NUM> or receives and executes instructions <NUM> responsive to a propagated signal so that a device connected to a network <NUM> can communicate voice, video, audio, images, or any other data over the network <NUM>. Further, the instructions <NUM> may be transmitted or received over the network <NUM> via a communication port or interface <NUM>, and/or using a bus <NUM>. The communication port or interface <NUM> may be a part of the processor <NUM> or may be a separate component. The communication port or interface <NUM> may be created in software or may be a physical connection in hardware. The communication port or interface <NUM> may be configured to connect with a network <NUM>, external media, the display <NUM>, or any other components in controller <NUM>, or combinations thereof. The connection with the network <NUM> may be a physical connection, such as a wired Ethernet connection or may be established wirelessly as discussed below. Likewise, the additional connections with other components of the controller <NUM> may be physical connections or may be established wirelessly. The network <NUM> may alternatively be directly connected to a bus <NUM>.

While the computer-readable medium <NUM> is shown to be a single medium, the term "computer-readable medium" may include a single medium or multiple media, such as a centralized or distributed database, and/or associated caches and servers that store one or more sets of instructions. The term "computer-readable medium" may also include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by a processor or that cause a computer system to perform any one or more of the methods or operations disclosed herein. The computer-readable medium <NUM> may be non-transitory, and may be tangible.

The computer-readable medium <NUM> can include a solid-state memory such as a memory card or other package that houses one or more non-volatile read-only memories. The computer-readable medium <NUM> can be a random-access memory or other volatile rewritable memory. Additionally or alternatively, the computer-readable medium <NUM> can include a magneto-optical or optical medium, such as a disk or tapes or other storage device to capture carrier wave signals such as a signal communicated over a transmission medium. A digital file attachment to an e-mail or other self-contained information archive or set of archives may be considered a distribution medium that is a tangible storage medium. Accordingly, the disclosure is considered to include any one or more of a computer-readable medium or a distribution medium and other equivalents and successor media, in which data or instructions may be stored.

In an alternative implementation, dedicated hardware implementations, such as application specific integrated circuits, programmable logic arrays and other hardware devices, can be constructed to implement one or more of the methods described herein. Applications that may include the apparatus and systems of various implementations can broadly include a variety of electronic and computer systems. One or more implementations described herein may implement functions using two or more specific interconnected hardware modules or devices with related control and data signals that can be communicated between and through the modules, or as portions of an application-specific integrated circuit.

The controller <NUM> may be connected to a network <NUM>. The network <NUM> may define one or more networks including wired or wireless networks. The wireless network may be a cellular telephone network, an <NUM>, <NUM>, <NUM>, or WiMAX network. Further, such networks may include a public network, such as the Internet, a private network, such as an intranet, or combinations thereof, and may utilize a variety of networking protocols now available or later developed including, but not limited to TCP/IP based networking protocols. The network <NUM> may include wide area networks (WAN), such as the Internet, local area networks (LAN), campus area networks, metropolitan area networks, a direct connection such as through a Universal Serial Bus (USB) port, or any other networks that may allow for data communication. The network <NUM> may be configured to couple one computing device to another computing device to enable communication of data between the devices. The network <NUM> may generally be enabled to employ any form of machine-readable media for communicating information from one device to another. The network <NUM> may include communication methods by which information may travel between computing devices. The network <NUM> may be divided into sub-networks. The sub-networks may allow access to all of the other components connected thereto or the sub-networks may restrict access between the components. The network <NUM> may be regarded as a public or private network connection and may include, for example, a virtual private network or an encryption or other security mechanism employed over the public Internet, or the like.

In accordance with various implementations of the present disclosure, the methods described herein may be implemented by software programs executable by a computer system. Further, in an exemplary, non-limited implementation, implementations can include distributed processing, component/object distributed processing, and parallel processing.

Although the present specification describes components and functions that may be implemented in particular implementations with reference to particular standards and protocols, the disclosure is not limited to such standards and protocols. For example, standards for Internet and other packet switched network transmission (e.g., TCP/IP, UDP/IP, HTML, HTTP) represent examples of the state of the art.

It will be understood that the steps of methods discussed are performed in one embodiment by an appropriate processor (or processors) of a processing (i.e., computer) system executing instructions (computer-readable code) stored in storage. It will also be understood that the disclosure is not limited to any particular implementation or programming technique and that the disclosure may be implemented using any appropriate techniques for implementing the functionality described herein. The disclosure is not limited to any particular programming language or operating system.

<FIG> depict a flowchart of a method <NUM> implemented by controller <NUM> to filter a data transfer between an external application <NUM> and components <NUM> of a vehicle <NUM>. Method <NUM> includes receiving, by a context analyzer <NUM>, context data associated with the vehicle <NUM> (operation <NUM>). The context data may be received from external data database <NUM> or component broadcaster <NUM>. The context data is a flight phase of an aircraft, such as a climbing phase of a flight of the aircraft. Method <NUM> inlcudes processing, by the context analyzer <NUM>, the context data to configure one or more rules (operation <NUM>). For example, the external context data may provide the flight information region the aircraft is flying. Based on the prescribed speed limits of the flight information region, a rule may be configured that the maximum speed should not exceed <NUM> mach. This rule may then be used when any speed recommendation is provided by an Electronic Flight Bag. Method <NUM> includes sending, by the context analyzer <NUM>, the one or more rules to a rules engine <NUM> (operation <NUM>). Method <NUM> includes processing, by the rules engine <NUM>, a data model from the external application <NUM> based on the one or more rules (operation <NUM>). For example, the data model may include a takeoff performance message including takeoff speeds such as V1, V2, and VR, for example. Method <NUM> may include determining, by the rules engine <NUM>, whether to send the processed data model to the components <NUM> of the vehicle <NUM> based on the one or more rules (operation <NUM>). For example, the rules engine <NUM> may determine the takeoff performance message is out of context of the climbing phase of the flight. The applicable rule in this case may be that the takeoff performance data can only be sent from an external device in a pre-flight phase. When the current aircraft flight phase is cruise, the rule will reject the request to accept the takeoff performance message.

Method <NUM> includes additional operations, represented here as method <NUM>. Method <NUM> includes, based on determining to send the processed data model to the components <NUM> of the vehicle <NUM>, receiving, by a schematic parser <NUM>, the data model from the rules engine <NUM> (operation <NUM>), and parsing the data model based on one or more object models defined for the components <NUM> of the vehicle <NUM> (operation <NUM>). For example, the data model may include data such as a landing performance message with "Approach speed: <NUM> / Flap1 speed: <NUM> / Flap <NUM> speed: <NUM>" and the parsed data may include data such as "EFBID <NUM><NUM><NUM>".

Method <NUM> may include coordinating, by an interface handler <NUM>, communication between the interface handler <NUM> and one or more of an external application <NUM> or the components <NUM> of the vehicle <NUM> (operation <NUM>). For example, interface handler <NUM> may coordinate a transmission of a flight plan in a. sfp format from external application <NUM>. Method <NUM> may include formatting, by a data decoder <NUM>, data received by the interface handler <NUM> into a suitable form for processing by the rules engine <NUM> (operation <NUM>). For example, data decoder <NUM> may format the data received by input processor <NUM> in the. sfp format from external application <NUM> into an. xml file for processing by failsafe validation engine <NUM>. Method <NUM> may include storing, by a file handler <NUM>, one or more of data received by the interface handler <NUM> or data formatted by the data decoder <NUM> (operation <NUM>). Method <NUM> may include storing, in an external data database <NUM>, external context data (operation <NUM>). For example, the external context data may include current geographical region, flight information region, current weather and traffic conditions, and traffic controller tuning information. Method <NUM> may include receiving, by the context analyzer <NUM>, the external context data from the external data database <NUM> as the context data (operation <NUM>). Method <NUM> may include receiving, by the context analyzer <NUM>, component context data from a component broadcaster <NUM> as the context data (operation <NUM>).

The vehicle <NUM> is an aircraft, the controller <NUM> may be provided in the aircraft, the components <NUM> may be one or more avionics components, the external application <NUM> is an Electronic Flight Bag, the context data is a flight phase of the aircraft, and the data model includes new data and a request from the Electronic Flight Bag to update the avionics component with the new data.

Claim 1:
A system to filter a data transfer between an external application and a component of a vehicle, wherein the vehicle is an aircraft, the system is provided in the aircraft, the component is an avionics component, the external application is an Electronic Flight Bag, the system comprising:
a failsafe validation engine, wherein the failsafe validation engine is configured to act as a filter mechanism to eliminate unintended or inconsequential data uploads from the external application to the avionics component, and includes:
a rules engine to process a data model from the external application based on one or more rules, wherein the rules engine is configured to determine whether to send the processed data model to the component of the vehicle based on the one or more rules,
a context analyzer to receive context data associated with the vehicle, process the context data to configure the one or more rules, and send the one or more rules to the rules engine, and
a schematic parser to receive the data model from the rules engine and parse the data model based on one or more schematics defined for the avionics component, wherein the context data is a flight phase of the aircraft, and the data model includes new data and a request from the Electronic Flight Bag to update the avionics component with the new data; and
a controller to control the failsafe validation engine.