Method and system for configuring data in an avionics system

Abstract

An avionics system can provide data to first receiving components associated with a proprietary first protocol and second receiving components associated with a non-proprietary second protocol. A configuration tool generates a first configuration file including instructions for a data access component to provide a first data output to the first receiving components and a second data output to the second receiving components. The configuration tool can generate a second configuration file including instructions to translate the second data output. The data access component can receive a definition database defining the first protocol to translate data according to the non-proprietary second protocol. The data access component can provide requested data to the first and second receiving components according to the non-proprietary second protocol. The second receiving components are configured to translate data received based on the second configuration file.

Description

BACKGROUND

[0001] Modern aircraft employ sophisticated flight management systems (FMS) to process and control a large amount of important data for the aircraft. Currently, to access internal data from a traditional FMS, the access interface must be defined at software compile time. However, due to certification requirements and security concerns, changing or altering the access interface or adding a new access interface requires additional testing and re-certification. Due to the additional testing and re-certification requirements, changes to the access interface can be difficult and costly. Typically, these interfaces undergo multiple changes throughout the development of a program, but once the system is in service, the cost of change is too high. BRIEF DESCRIPTION OF DRAWINGS

[0002] In the drawings:

[0003] Figure 1 depicts a top view schematic of an example aircraft in accordance with various aspects described herein;

[0004] Figure 2 depicts a block diagram of an example system to provide data from an avionics system in accordance with various aspects described herein;

[0005] Figure 3 depicts a block diagram of an example data access framework in accordance with various aspects described herein; and

[0006] Figure 4 depicts a flow diagram of a method to provide data from an avionics system in accordance with various aspects described herein. DETAILED DESCRIPTION

[0007] Aspects of the disclosure can be implemented in any environment, device, or method for providing data from an avionics device, regardless of the specific functions performed by the avionics device.

[0008] As used herein, the term "set" or a "set" of elements can be any non-zero number of elements, including only one. The example figures are for illustrative purposes only, and the dimensions, positions, order, and relative sizes reflected in the accompanying figures can vary.

[0009] Further, as used herein, a "processor" or "controller module" can include components structured or adapted to provide instructions, control, operation, or any form of communication to an operable component to affect its operation. A processor or controller module can include any known processor, microcontroller, or logic device, including but not limited to: a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a full authority digital engine control (FADEC), a proportional controller (P), a proportional-integral controller (PI), a proportional-integral-derivative controller (PID controller), a hardware-accelerated logic controller (e.g., for encoding, decoding, transcoding, etc.), or the like, or combinations thereof. Non-limiting examples of controller modules can be structured or adapted to run, operate, or otherwise execute program code to achieve operational or functional results, including executing various methods, functions, processing tasks, calculations, comparisons, sensing or measuring values, etc., to enable or implement the technical operations or operations described herein. Operational or functional results can be based on one or more inputs, stored data values, sensed or measured values, true or false indications, etc. While "program code" is described, non-limiting examples of sets of operable or executable instructions can include routines, programs, objects, components, data structures, algorithms, etc., having technical effects that perform particular tasks, or implement particular abstract data types. In another non-limiting example, a processor or controller module can also include data storage components accessible by the processor, including memory, whether transitory, volatile, or non-transitory, or non-volatile memory.

[0010] Additional non-limiting examples of memory can include random access memory (RAM), read only memory (ROM), flash memory, or one or more different types of portable electronic memory, such as a disk, DVD, CD-ROM, flash drive, universal serial bus (USB) drive, or the like, or any suitable combination of these types of memory. In one example, program code can be stored in the memory in a machine readable format accessible by the processor. Further, the memory can store various data, data types, sensed or measured data values, inputs, generated or processed data, and the like, that can be accessed by the processor in providing instructions, control, or operations to affect functionality or operable results, as described herein. In another non-limiting example, a control module can include comparing a first value to a second value, and operating or controlling operation of an additional component based on satisfaction of the comparison. For example, when a sensed, measured, or provided value is compared to another value, including a stored or predetermined value, satisfaction of the comparison can result in an action, functionality, or operation being controllable by the controller module. As used, the term “satisfaction” of a comparison is used herein to mean that a first value satisfies a second value, such as being equal to or less than the second value, or being within a range of values of the second value. It will be appreciated that such determinations can be readily altered to be satisfied by positive / negative comparisons or true / false comparisons. Example comparisons can include comparing a sensed or measured value to a threshold value or threshold range.

[0011] Aspects of the present disclosure can be implemented in any environment, device, system, or method having a restricted, limited, authorized, or otherwise limited “write access” privilege to a memory or data storage component. As used herein, “write access” refers to the availability or authorization to commit a change to a memory, the change being storing or overwriting data, values, commands, instructions, or any other data, element, or identifier to a memory location, regardless of the functionality by the data, element, or identifier, or regardless of the functionality or implementation of the environment, device, system, or method. Generally, “accessing” or “access” or “retrieving” data can refer to reading, viewing, or otherwise receiving data from a data store, or combinations thereof. As used herein, a “restricted” system is a system having limitations on access, such as write access to data or values of the system, such that only approved or authorized entities, parties, functions, and the like are able or otherwise permitted to access the restricted or limited elements. In one non-limiting example, only a single authorized function can have write access to a particular data element.

[0012] Data transmission from the FMS to the access interface can utilize a dedicated data network (e.g., conforming to the Airline Radio Inc. (ARINC) data network), and open source or non-proprietary standards or specifications can be defined for network operation, including data storage and data transmission. However, some avionics platforms and access interface devices can further utilize different dedicated or proprietary data formats, and protocols defined, for example, by the device manufacturer.

[0013] Aspects of the disclosure described herein are provided with respect to a dedicated avionics data protocol, but it should be appreciated that aspects described herein can be implemented in any environment utilizing a data communication network interconnecting avionics systems with one or more data receiving components or avionics systems, etc. Aspects of the disclosure can include avionics systems configured to operate in accordance with defined system characteristics or specifications. For example, modern aircraft operations interconnect a set of components through data networks defined by network standards, such as ARINC-based standards, e.g., ARINC 429 (A429) specification, ARINC 664 (A664), Ethernet, etc., the entirety of which are incorporated herein. Further, while the above examples can include network topology examples, application layer protocol standards can be included in their entirety, including but not limited to ARINC 702A (A702A), ARINC 834 (A834), etc.

[0014] Example aspects of the present disclosure relate to systems and methods capable of flexibly providing internal data of an avionics system (e.g., FMS, Airport Surface Movement System (ASMS), etc.) to avionics devices or applications. In particular, an interface, such as an avionics device, is typically required to access internal data from an FMS. As used herein, the term “avionics device” is not intended to be limiting and can be any desired avionics device requiring access to data from an avionics system (e.g., FMS, ASMS, etc.) without departing from the scope disclosed herein. In this sense, an avionics device requiring data from an avionics system can be defined as a data receiving component. In various non-limiting aspects, for example, the avionics device or data receiving component can include, but is not limited to, one or more of an Electronic Flight Bag (EFB), Flight Data Recorder (FDR), Automatic Dependent Surveillance Broadcast system (ADS-B), Aircraft Interface Device (AID), Communications Management Unit (CMU), In-Flight Entertainment System (IES), or Onboard Maintenance System. However, other aspects are not so limited, and as used herein, the term “data receiving component” can refer to any avionics device requiring operational access to data from an avionics system (e.g., FMS). It should be appreciated that in some cases, a particular data receiving component can be configured to operate based in part on receiving data according to a proprietary protocol (e.g., serial byte stream) associated with the particular receiving component. For example, many avionics devices are manufactured and configured to operate based on a protocol developed or licensed by the device manufacturer. Such protocols can be proprietary to the manufacturer and thus can not be open source, or can not be otherwise readily accessible by others without permission from the manufacturer. For authentication requirements and security considerations, adding an avionics device or data receiving component that employs a proprietary network communication protocol to an existing avionics system can require additional testing and re-certification. For example, additional testing and re-certification can be required to verify that the data receiving component can reliably translate a standard data stream provided by the FMS according to a particular non-proprietary protocol (e.g., ARINC 664 protocol) available to the second access interface. Due to such additional testing and re-certification requirements, the addition or modification of interface devices, applications, and software can be difficult and costly. Accordingly, one advantage of the disclosed subject matter is to provide a method and system capable of flexibly accessing and configuring internal data of an avionics system (e.g., FMS) to provide data from the avionics system according to a selectable protocol without requiring the data receiving component to translate or decode the data, or re-certification when the data receiving component is altered or modified.

[0015] For example, a particular aircraft can be operated via an avionics system that includes an onboard FMS that is communicatively coupled with a set of avionics devices (data receiving components), such as an EFB, over an avionics data network. The EFB can be configured to host an application (e.g., a specially built software application) to automatically perform functions that are typically performed manually, such as takeoff performance calculations. The EFB can be configured to communicate with the FMS over the data network in compliance with a non-proprietary communication protocol, such as ARINC 334. The data network can be configured to operate in accordance with a non-proprietary network standard, such as ARINC 664. Avionics systems and their components are typically required to be tested and / or certified prior to implementation to ensure airworthiness or compliance with operational regulations to obtain authorization for use by aviation authorities.

[0016] It is sometimes necessary to replace or upgrade one or more existing avionics devices (e.g., EFBs) in a legacy avionics system. For example, it can be desirable to add a new application to an EFB to provide additional functionality. However, in some cases, the new EFB or application can be configured to operate (e.g., read or write data) in accordance with a non-standard or proprietary protocol. In some cases, the FMS can be configured to subscribe to a new proprietary data set that can be stored in memory. However, in typical cases, the FMS has a practical limit on the available internal memory required for such an approach, which makes implementation of the new device or application more costly and less practical. Moreover, in such cases, where data structured in accordance with a proprietary protocol can be communicated over a legacy non-proprietary data network, existing aviation regulations typically require additional testing and / or certification of the avionics system and / or EFB. As will be described in greater detail herein, aspects of the present disclosure enable flexible access and configuration of data in the FMS to provide data from the FMS to an EFB in a legacy data network in accordance with a standard non-proprietary protocol. For example, the new EFB can provide a definition database that is accessible by the FMS. The definition database can define the proprietary protocol associated with the new EFB and specify predetermined information (e.g., data offsets, sizes, types, parameters, etc.) for data storage or transmission. In the event that data is requested or selected to be sent from the FMS to the new EFB, a configuration file can be generated by a configuration tool portion based on the definition database and provided to the new EFB. The configuration file can also include instructions for the FMS to convert the data from the proprietary protocol to the non-proprietary protocol and output the data to the new EFB in compliance with the non-proprietary protocol over the data network. In this way, the new EFB or application that would otherwise be incompatible with the non-proprietary communication protocol of the legacy avionics system can be implemented without re-certification of the avionics system.

[0017] Aspects of the present disclosure provide a technique to select, customize, or otherwise flexibly define data output or provided by an avionics system during runtime and provide the data to at least one of a selected first interface or a second interface according to a corresponding predetermined first protocol or second protocol associated with the selected receiving component. For example, in non-limiting aspects, a data access component of the avionics system can be provided with a definition database defining a predetermined first protocol for storing or transmitting data, the predetermined first protocol being associated with a particular first data receiving component. For example, the predetermined first protocol can be a proprietary protocol associated with the first receiving component. Additionally or alternatively, in non-limiting aspects, the system of the present disclosure can include a configuration tool that can define a second protocol for storing or transmitting data, the second protocol being associated with a particular second interface or receiving component. For example, the second protocol can be a standard or non-proprietary protocol (e.g., an ARINC-based protocol). The configuration tool can also enable a system operator to make selections of which data to output thereafter (e.g., via a user interface) and select at least one of the receiving components to receive the data. The selected data can be output to the selected receiving component according to the corresponding second protocol.

[0018] As one non-limiting example, in some embodiments, application source code of the avionics system can be parsed to create a parsed available data file listing data stores available for subscription or access. The parsed available data file can also include information about one or more parameters associated with the data stores, size of the data stores, one or more offsets associated with the data stores, endianness of the data stores, byte alignment, or other information about available data and expected storage structure. For example, the parsed available data file can also include information indicating a first protocol or a second protocol, or both. In other non-limiting aspects, the parsed available data file can include any desired information about any desired parameters associated with the data stores without departing from the scope disclosed herein. In some non-limiting aspects, the data stores can include a set of data topics or mail slots.

[0019] In non-limiting aspects, the configuration tool can use the parsed available data file to provide an interactive graphical user interface that allows a user to select data in a set of data stores to be output or otherwise retrieved from the avionics system. The user interface can also enable the user to select various preferences for other data settings or parameters. For example, the user interface can enable the user to select, without limitation, an output frequency for each data store, selected parameters for each data store, data or data parameter groups and subgroups, etc., and combinations thereof.

[0020] Based at least in part on such user selections, the configuration tool can generate a loadable first configuration file that indicates or otherwise informs a data access component of the avionics system about the identity of the user-selected data or data stores. Moreover, in some non-limiting aspects, in addition to identifying the user-selected data or data stores, the loadable first configuration can include additional information for each identified data store, such as an offset, size, parameters, and / or the like. In non-limiting aspects, the configuration tool can additionally or alternatively generate the loadable first configuration file based at least in part on a definition database that defines the first protocol. In some implementations, the loadable first configuration file can specify certain data groups that can be switched during run-time of the avionics system.

[0021] In non-limiting aspects, in addition to the user selections, the configuration tool can generate the loadable first configuration file based at least in part on other information, such as but not limited to the first protocol, the second protocol, data structures in one or more data stores of the avionics system, platform information, processor information, and / or one or more requirements associated with a receiving component that receives the selected data output by the avionics system.

[0022] Moreover, the configuration tool can also generate a second configuration file that can be used to transform certain data output by the data access component, which is discussed further below. In some non-limiting aspects, the configuration tool can generate the first configuration file or the second configuration file, or both, based on information received from an electronic flight bag (EFB). In some other non-limiting aspects, the configuration tool can generate the first configuration file or the second configuration file, or both, based on information received from the data receiving component itself.

[0023] The data access component can subscribe to data (e.g., particular data topics) in the data stores based on the loadable first configuration file. In particular, the data access component can output data from the subscribed data stores during run-time of the avionics system. In some aspects, the data access component can output the data as stream output to one or more receiving components that can be configured to receive the stream output data. The one or more receiving components can receive the stream output data and transform the stream output data based at least in part on the second configuration file received from the configuration tool. Additionally or alternatively, the data access component can output the data as stream output to the one or more receiving components without the need for transformation by the respective one or more receiving components.

[0024] Each receiving component can be any device, program, application, or other system component for which a system operator desires to provide selected data from the avionics system. For example, the receiving component can be a simulation system, a data recorder (e.g., a "black box"), an onboard maintenance system, an over-the-air data transmission system, or any other device, system, or component for which a particular user-selected avionics data is desired to be received, including components internal to the avionics system.

[0025] Examples will be provided by providing a clearer understanding of the operation of various non-limiting aspects. It should be understood that the non-limiting examples provided are merely one such possible instance of the many non-limiting aspects as disclosed herein, and other aspects are not limited thereto.

[0026] For example, a particular aircraft can include an FMS communicatively coupled to an EFB over a data network. The data network can be configured to operate according to a non-proprietary network standard (e.g., ARINC 664). The EFB can include a device such as an auxiliary performance computer (APC). The EFB can also host a suite of software applications and databases that provide known functionality and services. For example, the EFB can host a particular software application that provides navigation chart information to an operator (e.g., a pilot) in the cockpit of the aircraft. The EFB and its software applications can be configured to operate according to a non-proprietary communication protocol (e.g., ARINC 334). Prior to initial operation of the aircraft, the aircraft and its components (i.e., at least including the FMS and the EFB) are required to be tested and certified to prove compliance with operational and airworthiness regulations established by aviation authorities. For example, in certain situations, such as when the operator's sole source of navigation chart information is contained in the EFB, the operator must prove that the EFB will continue to operate normally throughout a depressurization event, and thereafter, regardless of altitude. In this particular example, the EFB can include legacy software applications that operate according to a non-proprietary communication protocol to provide navigation chart information to the operator in the cockpit. In the event that it is later desired to upgrade the EFB to host a new or higher version of the navigation software, but the new EFB application operates according to a proprietary communication protocol, the FMS and EFB with the upgraded navigation application can need to be "re-certified" to comply with aviation regulations prior to implementation, as the new proprietary protocol used by the new EFB application can be incompatible with the legacy non-proprietary protocol of the data network.

[0027] However, in this non-limiting example, a data access component of the FMS can be provided with a definition database that defines the proprietary protocol associated with the EFB application for storing or transmitting data. For example, the definition database can be uploaded to the FMS by the operator. In other non-limiting aspects, the definition database can be provided to the FMS by the EFB.

[0028] Regardless of how the definition database is provided to the FMS, the FMS can further include a configuration tool to define non-proprietary protocols (e.g., ARINC-based protocols) used by other avionics devices or applications on the data network to store or transmit data. The configuration tool can further enable an operator to select (e.g., via a user interface) particular data to be output from the FMS and select one or more avionics devices to receive the data (e.g., such as an EFB). The selected data can be output to the selected devices, including the EFB, according to the corresponding non-proprietary protocol.

[0029] For example, the application source code of the FMS can be parsed to create a parsed available data file listing data stores available for subscription or access. The parsed available data file can include information about predetermined parameters associated with the data stores, sizes of the data stores, one or more offsets associated with the data stores, byte orders of the data stores, byte alignment, or other information about available data and expected storage structures. The parsed available data file can further include information indicating a proprietary protocol, a non-proprietary protocol, or both. The configuration tool can use the parsed available data file to provide an interactive graphical user interface that allows an operator to select data in a set of data stores to be output or otherwise retrieved from the FMS.

[0030] Based on the operator’s selections, the configuration tool can further generate a loadable first configuration file for data access components of the FMS indicating the selected data or data stores. The loadable first configuration can further include additional information for each identified data store, such as offsets, sizes, parameters, and the like. The configuration tool can further generate the loadable first configuration file based in part on information in the definition database defining the proprietary protocol. In this non-limiting example, the configuration tool can generate the loadable first configuration file based on various predetermined information, such as but not limited to the proprietary protocol, the non-proprietary protocol, data structures of the data stores of the FMS, and any predetermined requirements associated with the EFB. Further, the configuration tool can further generate a second configuration file that can be used by other selected legacy devices or applications on the data network to convert data output by the data access components according to the non-proprietary protocol.

[0031] The data access components can subscribe to data (e.g., particular data topics) in the data stores based on the loadable first configuration file. In particular, the data access components can output data from the subscribed data stores during runtime of the FMS. The data access components can output the data as a stream output to other selected legacy avionics devices or applications connected with the data network and configured to receive the stream output data. The other selected legacy avionics devices or applications can receive the stream output data and convert the stream output data based at least in part on the second configuration file received from the configuration tool.

[0032] Further, based on the first configuration file, the data access component can configure the accessed data according to the non-proprietary protocol and output the data according to the non-proprietary protocol to the EFB. In this way, a new or upgraded EFB application can receive data from the FMS according to the same conventional non-proprietary protocol used by the data network and previously certified to comply with the operating regulations established by the aviation authority, thereby avoiding the need for re-certification due to other incompatible protocols.

[0033] Accordingly, aspects of the present disclosure provide a technique to customize or otherwise define data output by an avionics system during runtime. Further, aspects of the present disclosure enable enhanced, flexible, and robust logging of flight test data, troubleshooting, and analysis of issues in service. Moreover, aspects of the present disclosure provide a method and system to provide data from an avionics system to a data receiving component according to a predetermined protocol without requiring the data receiving component to convert or decode the data according to another predetermined protocol.

[0034] While example aspects of the present disclosure are discussed with reference to avionics systems, the subject matter described herein can be used or applied to provide flexible access to internal data of other systems, vehicles, machines, industrial or mechanical assets, or components without departing from the scope of the present disclosure.

[0035] Example aspects of the present disclosure will now be discussed in greater detail.

[0036] Figure 1 A non-limiting aspect of an aircraft 8 is depicted having a fuselage 10 and at least one turbine engine, shown as a left engine system 12 and a right engine system 14. The left engine system 12 and the right engine system 14 can be substantially identical. While the left engine system 12 and the right engine system 14 are described by way of example as turbine engines, the aircraft 8 can include fewer or additional engine systems, or alternative propulsion engine systems, such as propeller-based engines. While the left engine system 12 and the right engine system 14 are shown as being mounted to the fuselage 10, the left engine system 12 and the right engine system 14 can be mounted to other portions of the aircraft 8, such as the wings, tail, or other portions of the aircraft 8. Figure 1 The aircraft 8 is depicted as a fixed-wing type aircraft, but other non-limiting aspects of the aircraft 8 can include a rotary-wing type aircraft without departing from the scope disclosed herein.

[0037] The aircraft 8 is shown as further including a plurality of sensors, systems, and components (collectively, line replaceable units (LRUs) 18), and at least one server 20 or computing unit positioned proximate to one another near a nose of the aircraft 8, shown as two flight management systems or flight control computers. At least one of the servers 20 can also include a memory 22.

[0038] The LRUs 18 and the server 20 can be communicatively interconnected by transmission or communication lines of a data communication network 24 that traverses at least a portion of the aircraft 8. Additional LRUs 18 can be included. While a server 20 is described, other non-limiting aspects can include any computing system, flight computer, or display system that displays data from multiple systems.

[0039] The memory 22 can include random access memory (RAM), flash memory, or one or more different types of portable electronic memory, etc., or any suitable combination of these types of memory. The LRU 18 and / or the server 20 can be operatively coupled with the memory 22 such that the LRU 18 and / or the server 20, or any computer programs or processes thereon, can access at least a portion of the memory 22 (e.g., a“shared memory” 22).

[0040] Figure 1 The aircraft 8 shown in FIG. 1 is a schematic representation to aid in the understanding of one non-limiting aspect of the present disclosure, and to illustrate that multiple LRUs 18 and servers 20 can be positioned throughout the aircraft 8. The exact location of the LRUs 18 and servers 20 is not relevant to the aspects described herein. Moreover, more or fewer LRUs 18 or servers 20 can be included in other non-limiting aspects.

[0041] The data communication network 24 is shown as a bus, but can include multiple data communication connectors and interfaces (e.g., Ethernet or fiber optic cables), as well as routing and / or switching components to facilitate communicative interconnection between the LRUs and the server 20. Moreover, the configuration and operation of the data communication network 24 can be defined by a set of general standards or rules suitable for the particular aircraft environment. For example, the data communication network 24 on the aircraft 8 can be defined and / or configured in accordance with the ARINC 664 standard or the ARINC 653 standard.

[0042] Figure 2 A block diagram depicting an example system 100 for flexible access to internal data of an avionics system 102 in accordance with non-limiting aspects is depicted. The data can be saved in a memory, such as a set of data stores 110. In non-limiting aspects, the avionics system 102 can include, but is not limited to, a flight management system (FMS). In other non-limiting aspects, the avionics system 102 can be communicatively coupled to the FMS. In other non-limiting aspects, the avionics system 102 can be a standalone system that does not require the FMS without departing from the scope disclosed herein.

[0043] The avionics system 102 can be communicatively coupled with a first receiving component 117 and a second receiving component 116. In non-limiting aspects, the first receiving component 117 and the second receiving component 116 can include, but are not limited to, one or more of an electronic flight bag (EFB), a flight data recorder (FDR), an automatic dependent surveillance broadcast system (ADS-B), an aircraft interface device (AID), a communication management unit (CMU), an in-flight entertainment system (IES), or an onboard maintenance system. However, other aspects are not so limited, and as used herein, the terms“first data receiving component” and“second data receiving component” can refer to any avionics device that requires operational access to data from an avionics system (e.g., FMS). In non-limiting aspects, the first receiving component 117 or the second receiving component 116, or both, can be internal or external to the avionics system 102. In one non-limiting aspect, the first receiving component 117 or the second receiving component 116, or both, can be a data communication / data downlink application. In another non-limiting aspect, the first receiving component 117 or the second receiving component 116, or both, can be a data link application. In yet another non-limiting aspect, the first receiving component 117 or the second receiving component 116, or both, can include or form a part of the FMS.

[0044] In some embodiments, the avionics system 102 executes, operates, or otherwise runs on a framework that provides data and time management (e.g., scheduling). For example, the framework can manage data (e.g., topics), as well as threads or timing, referred to as processing functions.

[0045] The processing functions can communicate with each other via the data store. In some embodiments, the framework enables access to the data store in a thread-safe manner. In some non-limiting aspects, the framework can provide data management on a publish / subscribe basis. To help with understanding, one example visualization of the framework in a non-limiting aspect is depicted in Figure 3

[0046] Again referring to Figure 2 ​, the avionics system 102 can include a data access component 104. As described in greater detail herein, data saved in the data store 110 can be provided by the data access component 104 to the first receiving component 117 as a first data output 119a, or to the second receiving component 116 as a second data output 119b, or both. The data access component 104 is executed, operated, or otherwise run based on a loadable first configuration file 106 (e.g., a loadable configuration file). For example, in one non-limiting aspect, the loadable first configuration file 106 can include instructions for the data access component 104 to output the first data output 119a or the second data output 119b, or both, every 2 seconds.

[0047] The data access component 104 can include a definition database 107. For example, the definition database 107 can be provided to the data access component 104 via an automatic upload or file transfer from the first receiving component 117. In other non-limiting aspects, the definition database 107 can be manually entered or otherwise provided to the data access component 104 by the user 121. In other non-limiting aspects, the definition database 107 can be provided to the data access component 104 using any desired technique, method, or system without departing from the scope disclosed herein. The definition database 107 can include or define a predetermined proprietary first protocol 109 associated with the first receiving component 117. The proprietary first protocol 109 can specify predetermined information for data storage or transmission (e.g., data offsets, sizes, types, parameters, etc.). In some non-limiting aspects, the data can be output as non-human readable data.

[0048] The system 100 can also include a configuration tool 108. In non-limiting aspects, the configuration tool 108 can enable the user 121 to select data to be output from the data access component 104, and the frequency of said output. For example, the configuration tool 108 can include a program or graphical user interface 123 through which the user 121 selects data from a predetermined set of data (e.g., a subject or certain parameters of a subject), and the output frequency of the selected data from the data store 110. In other non-limiting aspects, the configuration tool 108 can be communicatively coupled to the EFB or other avionics 125 to additionally or alternatively receive a selection of data output from one or more data stores 110 from the EFB or other avionics 125.

[0049] In some aspects, the configuration tool 108 can have a priori knowledge about how to maintain data in the data store 110, the platform environment, the processor, etc. For example, based at least in part on user 121 input via the user interface 123, the configuration tool 108 can generate a loadable first configuration file 106 that instructs the data access component 104 to access the data store and output data based on selections made by the user 121 or the definition database 107 or both (as shown in Figure 2 For example, in some non-limiting aspects, the loadable first configuration file 106 can include instructions to configure or convert data stored according to a proprietary first protocol 109 to a standard or non-proprietary second protocol 111 before providing the data as the first data output 119a. In non-limiting aspects, the loadable first configuration file 106 can be provided to the data access component 104 via the EFB or other avionics 125. In other non-limiting aspects, the loadable first configuration file 106 can be loaded directly by the user 121, e.g., via the user interface 123. In non-limiting aspects, the configuration tool 108 can also generate a second configuration file 120 that can be used by the second receiving component 116 to convert the second data output 119b received from the data access component 104. In some non-limiting aspects, the configuration tool 108 can generate the first configuration file 106 or the second configuration file 120 or both based on information received from the EFB or other avionics 125.

[0050] In some aspects, the data access component 104 can resolve the loadable first configuration file 106 at startup and subscribe to a set of data or data stores based on the list or instructions contained in the loadable first configuration file 106. In some non-limiting aspects, the data access component 104 can subscribe to data or data stores by using string literals and generic data types, such that no data specification is needed at runtime, making the interface more flexible.

[0051] In non-limiting aspects, in addition to specifying data or data stores, the loadable first configuration file 106 (loadable configuration file) can also specify a particular data entry (e.g., parameter) within the data store. The loadable first configuration file 106 can provide instructions about how many bytes to read (e.g., offset, type, size, etc.). For example, the offset can describe the number of bytes from the beginning of the data store to start at a particular data item; the size can describe the number of bytes occupied by a particular data item; and the type can define how to interpret the bytes.

[0052] The requested data specified by the loadable first configuration file 106 can be grouped, and thus a sub-group of the data can be requested. Each group can output data at a defined rate and the data access component 104 can manage the rate of operation. This allows for limiting the amount of data output at one time by splitting the data into multiple groups. The consumer or recipient of the data can then send requests to the data access component 104 to switch the output as needed. As one example, at each cycle, the data access component 104 can read data from the data store through a pointer provided by the framework, and can extract individual data items based on the offset and size (or type) defined in the loadable first configuration file 106.

[0053] The loadable first configuration file 106 can include instructions for translating or converting the specified data to a non-proprietary second protocol 111 when the specified data is stored in the data store 110 according to a proprietary first protocol 109. The converted data can be transmitted as first data output 119a to the first receiving component 117 according to the non-proprietary second protocol 111. For example, in non-limiting aspects, the non-proprietary second protocol 111 can specify that the output data is serialized as a byte stream and output as a standard stream output (e.g., ARINC 429 or ARINC 664).

[0054] Further, the loadable first configuration file 106 can include instructions for outputting the extracted data as second data output 119b according to the non-proprietary second protocol 111 associated with the second receiving component 116. In some non-limiting aspects, the data can be output as non-human readable data. In some non-limiting aspects, the second data output 119b according to the non-proprietary second protocol 111 can be in a standard or non-proprietary format. For example, in non-limiting aspects, the non-proprietary second protocol 111 can specify that the output data is serialized as a byte stream and output as a standard stream output 114. For example, the stream output 114 can include ARINC 429 or ARINC 664, for example, where the data output 119b is preferably limited to a maximum payload. Additionally or alternatively, pagination can be employed, for example, where multiple transmissions obtain an index and a maximum number of transmissions expected by the recipient. A grouping option can also be provided in cases where not all of the data is needed continuously.

[0055] Additionally, the data access component 104 can also provide protection mechanisms to avoid "exhausting" the system by requesting too much data. For example, cyclic redundancy checks (CRCs), public and private keys, or other encryption or security techniques can be used, as further described below. These protection mechanisms can be in addition to the mechanisms in the configuration tool 108. The data access component 104 can also check the input file and ensure that it meets a set of predetermined criteria (e.g., does not make invalid requests). For example, the data access component 104 can ensure that the number of bytes requested per output group does not exceed a threshold value.

[0056] In non-limiting aspects, the first receiving component 117 or the second receiving component 116 or both can request or trigger actions from the data access component 104. For example, the first receiving component 117 or the second receiving component 116 or both can trigger respective first or second data outputs 119a, 119b from the data access component 104 via a request queue 118 serviced by the data access component 104. In some implementations, the request queue 118 can be used to send specific requests to enable and / or disable the respective first or second data outputs 119a, 119b or both based on different groups or subgroups defined in the loadable first configuration file 106. Additionally or alternatively, the data access component 104 can provide the first data output 119a to the first receiving component 117 according to the non-proprietary second protocol 111 and the proprietary first protocol 109 specified by the definition database 107, and further provide the second data output 119b (e.g., the stream output 114) to the second receiving component 116 according to the non-proprietary second protocol 111. It should be appreciated that while a single first receiving component 117 is depicted in association with the proprietary first protocol 109 defined in the definition database 107, other aspects are not limited to this and can include any desired number of first receiving components 117 in association with any number of different proprietary first protocols 109 defined in any number of definition databases 107 without departing from the scope disclosed herein. Figure 2 A single first receiving component 117 is depicted in association with the proprietary first protocol 109 defined in the definition database 107, although other aspects are not limited to this and can include any desired number of first receiving components 117 in association with any number of different proprietary first protocols 109 defined in any number of definition databases 107 without departing from the scope disclosed herein.

[0057] The first receiving component 117 or the second receiving component 116, or both, can trigger the respective first or second data output 119a, 119b from the data access component 104 or contract the data access component 104 in a variety of ways, including but not limited to periodically (e.g., outputting data at a specified rate), on demand (e.g., a one-time request), or based on an event. For example, the first receiving component 117 or the second receiving component 116, or both, can trigger the data output when the aircraft reaches a cruising altitude. The event used as a trigger can be predefined, and the data to be output can be configurable. For example, in other non-limiting aspects, the triggering event can be a determination that the aircraft in flight has reached a waypoint. In other non-limiting aspects, the data output can be manually triggered by a user, such as a flight crew or maintenance personnel. In non-limiting aspects, the data can indicate any desired number of parameters related to the aircraft, including detected, measured, sensed, computed, derived, or otherwise determined data. For example, in non-limiting aspects, the first or second receiving component 116, 117 can be a flight recorder (e.g., FDR) that can receive and record data related to the history of a recent flight, including many parameters collected from the data access component 104 several times per second. For example, during normal flight operations, the FDR can capture specific aircraft performance parameters such as airspeed, altitude, vertical acceleration, time, heading, rudder pedal position, aileron position, elevator position, and fuel flow.

[0058] In non-limiting aspects, the second receiving component 116 can transform the received data before or after recording. For example, the second receiving component 116 can transform the received data in flight or during post-processing. Further, the second receiving component 116 can ensure that it has the most up-to-date second configuration file 120 to transform the data stream based on version information contained in or associated with the second configuration file 120.

[0059] In particular, in non-limiting aspects, the configuration tool 108 can further provide the second receiving component 116 with the second configuration file 120 to enable the second receiving component 116 to transform data obtained, acquired, or otherwise received from the data access component 104. For example, the data received from the data access component 104 can be a set of serialized data (e.g., serialized bytes). The second receiving component 116 can transform the serialized data based on information contained in the second configuration file 120.

[0060] In some implementations, the configuration tool 108 can generate the second configuration file 120 based at least in part on a priori knowledge of the platform environment, the data store 110, the processor, the avionics system software version, the proprietary first protocol 109, the non-proprietary second protocol 111, and the like, and can cause the configuration tool 108 to instruct the second receiving component 116 how to translate data received from the data accessing component 104.

[0061] The first receiving component 117 or the second receiving component 116 or both can enable robust and flexible access to aircraft data during testing (e.g., testing of the FMS). For example, partition level testing (e.g., equivalence partitioning or boundary value analysis) can require access to data or data stores. For example, hard coded buses (e.g., airfield device buses) were previously required to access the desired information / data. However, given the disclosure herein, the first receiving component 117 or the second receiving component 116 or both can trigger the corresponding first or second data output 119a, 119b from the data accessing component 104 and receive the data according to their predetermined corresponding protocol. The data received by the first receiving component 117 or the second receiving component 116 or both from the data accessing component 104 can be aggregated and compared to calculated or expected values to verify performance of the FMS.

[0062] The configuration tool 108 therefore does not need to provide the second configuration file 120 to the first receiving component 117 to enable the first receiving component 117 to translate data obtained, acquired, or otherwise received from the data accessing component 104 as compared to conventional systems.

[0063] In some non-limiting aspects, the configuration tool 108 can generate the second configuration file 120 based at least in part on, but not limited to, a priori knowledge of the platform environment, the data store 110, the processor, the avionics system software version, the non-proprietary second protocol 111, the definition database 107, the proprietary first protocol 109, and combinations thereof.

[0064] The configuration tool 108 can provide an easy to use interface (e.g., user interface 123) that enables the user 121 to set, pick, or otherwise select criteria (e.g., data, timing, etc.) for a particular second configuration file 120. The configuration tool 108 generates the second configuration file 120 based on knowledge of data structures (e.g., topics) in the data store 110 and protocol requirements of the second receiving component 116. The configuration tool 108 can generate a loadable first configuration file 106 (loadable configuration file) for the data accessing component 104 and a second configuration file 120 (configuration file) for the second receiving component 116.

[0065] In some non-limiting aspects, the configuration tool 108 or other system component can parse a set of application source code 122 to provide a list of all available data stores 110. In some aspects, the application source code 122 can be source code for the avionics system 102. In particular, the application source code 122 can describe or otherwise contain the structure of the data stores 110, or other information about the structure and / or operation of the avionics system 102 and / or framework. Parsing the application source code 122 can result in a parsed available data file 124 that contains a list of all available data stores 110 and / or other information (e.g., subject parameters, size, offsets, etc.).

[0066] In some implementations, in addition to the application source code 122, the configuration tool 108 can analyze or otherwise use one or more binary object files of the avionics system 102 to determine the memory layout of the avionics system 102. For example, a compiler can optionally create a context clause (which can also be referred to as a representation specification). The context clause can contain a table describing the memory layout. The configuration tool 108 can use the context clause as an input in addition to the source code 122 (which can still be used to determine dependencies of nested data structures).

[0067] Based on the target processor architecture (e.g., the processor that implements the data access component 104), the configuration tool 108 can also know the bit and byte alignment and endianness to adjust the offsets in the loadable first configuration file 106. The second receiving component 116 can also use the endianness information to convert data streams. The configuration tool 108 can also specify the units of each data item through metadata in the application source code 122 or through type definition names (e.g., Feet_Type). Additionally or alternatively, the configuration tool 108 can enable a user 121 to update, change, or otherwise add metadata. For example, in cases where the configuration tool 108 is unable to infer metadata, the user 121 can add metadata that will be maintained for future use.

[0068] Accordingly, the parsed available data file 124 can be a representation of the application source code 122 that the configuration tool 108 can use to generate the loadable first configuration file 106 and the second configuration file 120 for the first receiving component 117, the second receiving component 116, or both. This intermediate parsed available data file 124 can be used to provide the configuration tool 108 to third parties (e.g., customers) and allow them to create their own loadable first configuration file 106 while limiting the scope and visibility of the application source code 122.

[0069] In non-limiting aspects, data integrity can be ensured. For example, by applying a CRC to the loadable first configuration file 106 or second configuration file 120 (e.g., only the data access component 104 knows how to compute the CRC) or using any other form of hash or electronic signature, trial and error testing to extract undesirable data or attempts to crash the software can be prevented.

[0070] In some embodiments, the loadable first configuration file 106 and second configuration file 120 can have a maximum size limit. Also, the contents of the file can have a group number limit. This can affect the memory and request interface size inside the data access component 104.

[0071] Each of the configuration tool 108, data access component 104, first receiving component 117, and second receiving component 116 can be implemented by one or more computing devices that can include one or more processors and memory. The one or more processors can be any suitable processing device (e.g., a processor core, a microprocessor, an ASIC, a FPGA, a controller, a microcontroller, etc.) and can be one processor or more than one processor that are operatively connected. The memory can include one or more non-transitory computer-readable storage media, such as RAM, ROM, EEPROM, EPROM, flash memory devices, magnetic disks, etc. and combinations thereof. The memory can store instructions for execution by the processor that, when executed by the processor, perform operations.

[0072] In one particular non-limiting example, the configuration tool 108 can be implemented by a computing device located in a ground station; the avionics system 102 (including the data access component 104) can be implemented by another computing device on the aircraft; and the receiving components can be implemented by yet another computing device located on the aircraft. However, the previous distribution is provided as one example only. Many other and different distributions of computing functionality can be used.

[0073] In some implementations, each of the configuration tool 108, the data access component 104, the first receiving component 117, the second receiving component 116, or a combination thereof can correspond to or otherwise include computer logic for providing desired functionality. Thus, each of the configuration tool 108, the data access component 104, the first receiving component 117, or the second receiving component 116 can be implemented in hardware, special-purpose circuitry, firmware and / or software that is loaded onto a general purpose processor, or a combination thereof. In one non-limiting aspect, each of the configuration tool 108, the data access component 104, the first receiving component 117, and the second receiving component 116 can correspond to program code files stored on a storage device, loaded into a memory, and executed by a processor, or can be provided from a computer program product, such as a computer executable instructions stored in a tangible computer readable storage medium, such as a RAM, a hard disk, or an optical / magnetic medium. In some implementations, each of the data stores 110 can include some form of non-transitory computer readable storage medium, including, for example, volatile and / or non-volatile memory, databases, etc.

[0074] Turning now to Figure 3 FIG. 3 shows an example framework 300 for data communication in an avionics system, in accordance with various aspects described herein. As discussed, the framework 300 provides data and time management. For example, the framework 300 can manage data (e.g., topics) and can manage threads or timing referred to as processing functions or components. For example, the framework 300 can manage a first processing function that runs every 200 milliseconds and performs a first task, and concurrently manages a second processing function that runs every 1 second and performs a second task. The framework 300 can include a set of data stores or topics and a set of mail slots. The framework 300 enables access to data from the data stores and mail slots.

[0075] A set of processing functions (e.g., processing functions 302) communicate with, link to, or are otherwise connected to the framework 300. The processing functions can execute, operate, or otherwise run at flexible or strict times. The processing functions 302 can access data from a set of data stores (e.g., data stores 304 and 306) included in a data store repository 308 maintained by the framework 300. For example, the processing functions 302 are shown accessing or otherwise interacting with the data stores 304 and 306 of the data store repository 308.

[0076] The framework 300 enables access to data items (e.g., topics) by name (e.g., via string literals). By knowing the names to be used in a configuration file, a configuration tool can specify the names of data of interest to a user. A data access component can parse the configuration file to subscribe to the appropriate data stores.

[0077] In a non-restrictive aspect, whenever the system restarts, the data access component can load the configuration file and subscribe to / resubscribe to the desired data or data store. Additionally or alternatively, data groups can be specified to switch the data output at runtime, and the data access component 104 can parse and subscribe to all possible groups.

[0078] Figure 4 It shows, for example, the use of Figure 2 This is a non-limiting example of a method 400 for a system 100 to provide data from an avionics system 102 (e.g., an FMS). Method 400 can be performed when the aircraft 8 is in flight or on the ground. Although the avionics system 102 is described herein according to an FMS 102, it should be understood that method 400 can be applied to any suitable avionics device or system. While references will be made to... Figure 3 The method 400 is described for the avionics system 102, but is not limited thereto, and the method 400 may be implemented on any other avionics system 102 without departing from the scope of the disclosure herein.

[0079] In a non-limiting aspect, method 400 may begin at 410, where configuration tool 108 receives selection of data storage 110 of avionics system 102, and selection of at least one of first receiving component 117 and second receiving component 116. In a non-limiting aspect, the first receiving component may be associated with proprietary first protocol 109, and the second receiving component 116 may be associated with non-proprietary second protocol 111.

[0080] Configuration tool 108 may be implemented by one or more processors. The one or more processors may be any suitable processing device (e.g., processor core, microprocessor, ASIC, FPGA, controller, microcontroller, etc.) and may be a single processor or multiple processors operatively connected. The one or more processors may include or be operatively coupled to memory. Memory may include one or more non-transitory computer-readable storage media, such as RAM, ROM, EEPROM, EPROM, flash memory devices, disks, etc., and combinations thereof. For example, in a non-limiting aspect, configuration tool 108 may receive selection of one or more data stores 110 via user interface 123. User interface 123 enables user 121 to select one or more data stores 110 from the set of available data stores 110 and to select at least one of a first receiving component 117 and a second receiving component 116 to receive the selected data. It should be understood that, in other non-limiting aspects, configuration tool 108 may receive selection of one or more data stores 110 via electronic flight bag (EFB) or other avionics device 125.

[0081] The method 400 can further include generating, by the configuration tool 108, at 420, a first configuration file 106 including instructions for at least one of a first data output 119a from the selected data store 110 to the first receiving component 117 and a second data output 119b from the selected data store 110 to the second receiving component 117. The first configuration file 106 can be based at least in part on the received selection of one or more data stores 110, and the selected receiving components 116, 117. In some aspects, the configuration tool 108 can generate a loadable first configuration file 106 that provides instructions to the data access component 104 to access the data store 110, retrieve data therefrom, and output the retrieved data based on the selections made by the user 121. In other non-limiting aspects, the loadable first configuration file 106 can be loaded directly by the user 121, e.g., via the user interface 123.

[0082] In response to the received selection of the second receiving component, the method 400 can include generating, by the configuration tool 108, at 430, a second configuration file 120. The second configuration file 120 can include instructions that can be used by the second receiving component 116 to convert the second data output 119b. For example, the data second output 119b according to the non-proprietary second protocol 111 can be in a standard or non-proprietary format (e.g., a serialized byte stream), and output as a standard stream output 114. For example, the stream output 114 can conform to the ARINC 429 or ARINC 664 standards. In non-limiting aspects, the non-proprietary second protocol 111 can include portions of any one or more of the data store 110, hard-coded values, or other data or data abstractions expected. In non-limiting aspects, the configuration tool 108 can further specify one or more of an offset and a size associated with each data store 110 based at least in part on the received selection of one or more data stores 110. Further in response to the received selection of the second receiving component, the method 400 can further include providing, by the configuration tool 108, at 440, the second configuration file 120 to the second receiving component 117.

[0083] At 450, the method 400 can include receiving, by the data access component 104, the first configuration file 106. For example, the first configuration file 106 can be provided to the data access component 104 via the EFB or another avionics device 125. In other non-limiting aspects, the first configuration file 106 can be provided to the data access component 104 by the configuration tool 108.

[0084] The method 400 can further include accessing, by the data access component 104, at 460, one or more data stores 110 containing internal data of the avionics system 102 based on the first configuration file 106.

[0085] In response to the instructions for the first data output 119 to the first receiving component 117, the method 400 can further include accessing, by the data access component 104, a definition database 107 defining the proprietary first protocol 109 at 470. In non-limiting aspects, the first configuration file 106 can include instructions for at least one of the first data output 119a from the selected data store 110 to the first receiving component 117. For example, in non-limiting aspects, the proprietary first protocol 109 can be a dedicated or proprietary protocol associated with the first receiving component 117. In some aspects, the proprietary first protocol 109 can be defined by a manufacturer of the first receiving component 117. In non-limiting aspects, the definition database 107 can be provided to the data access component 104 via an automatic upload or file transfer from the first receiving component 117. In other non-limiting aspects, the definition database 107 can be manually entered or otherwise provided to the data access component 104 by the user 121. In some non-limiting aspects, the first configuration file 106 can further include the definition database 107. In other non-limiting aspects, the definition database 107 can be provided to the data access component 104 using any desired technique, method, or system without departing from the scope disclosed herein. The definition database 107 can include or define the proprietary first protocol 109. The proprietary first protocol 109 can be a proprietary protocol associated with the first receiving component 117.

[0086] The method 400 can further include retrieving, by the data access component 104, data from the selected data store 110 stored according to the proprietary first protocol 109 based on the first configuration file 106 at 475. With the first receiving component 117 selected, the method can include configuring or converting the retrieved data from the selected data store 110 based on the first configuration file 106 according to the non-proprietary second protocol 111 at 477. In non-limiting aspects, the retrieved data from the selected data store 110 can be converted from the proprietary first protocol 109 to the non-proprietary second protocol 111. For example, in non-limiting aspects, the retrieved data from the selected data store 110 can be converted by the data access component 104.

[0087] The method 400 can include providing, by the data access component 104, the retrieved data from the selected data store 110 to at least one of the first receiving component 117 (as the first data output 119a) and the second receiving component 116 (as the second data output 119b) based on the non-proprietary second protocol 111 at 480.

[0088] The method 400 can also include, at 490, converting or decoding, by the second receiving component 116, the second data output 119b by the data accessing component 104 based on the second configuration file 120. For example, the data received from the data accessing component 104 can be a set of serialized data (e.g., serialized bytes), and the second receiving component 116 can convert the serialized data based on information contained in the second configuration file 120.

[0089] In non-limiting aspects, the method 400 can include, at 495, operating at least one of the first receiving component 117 based on the first data output 119a and the second receiving component 116 based on the second data output 119b.

[0090] The order depicted is for illustrative purposes only and is not meant to limit the method 400 in any way, as it is understood that portions of the method can be performed in a different logical order, can include additional or intermediate stages, or can divide the described stages of the method into multiple stages, or can omit described stages of the method without detracting from the described method.

[0091] To the extent not already described, the different features and structures of the various aspects can be used in combination with each other, as desired. That one feature not shown in all aspects is not meant to be a limitation unless described as such. Therefore, features from different aspects can be mixed and matched as desired to form new aspects of the present disclosure, whether or not the new aspects are expressly described. The disclosure is intended to encompass all combinations or permutations of the various features described herein.

[0092] This written description uses examples to disclose aspects of the disclosure, including the best mode, and also to enable any person skilled in the art to practice aspects of the disclosure, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the disclosure is defined by the claims, and can include other examples that occur to those skilled in the art. Such other examples are intended to fall within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent

[0093] It will be appreciated that aspects disclosed herein enable flexible access and configuration of internal data of an avionics system (e.g., an FMS) to provide data from the avionics system to a first data receiving component according to a first proprietary protocol associated with the first data receiving component. The FMS can convert the data to a non-proprietary second protocol prior to providing to the first data receiving component without requiring re-certification upon addition, alteration, or modification of the first data receiving component. Aspects as disclosed herein also enable flexible access and configuration of internal data of an avionics system to provide data from the avionics system to a second data receiving component according to a second standard or non-proprietary protocol. In this manner, avionics devices that would otherwise be incompatible with a non-proprietary communication protocol of a traditional aviation system can be implemented as part of the aviation system without requiring re-certification of the system. For example, as disclosed in greater detail above, non-limiting aspects can enable a first avionics device configured to operate based on data received according to a proprietary protocol associated with the first avionics device to be communicatively coupled (e.g., retrofitted) to a traditional communication system in an aircraft adapted for communication according to a non-proprietary protocol. Further, the aviation systems and methods disclosed herein can provide data to a second avionics device according to a non-proprietary second protocol along with a second configuration file including instructions that enable the second avionics device to translate or otherwise convert the data to a format usable by the second avionics device. For example, aspects as described herein can additionally or alternatively enable translation or conversion of data to an industry standard (i.e., non-proprietary) format for use in another avionics device compatible with a traditional system.

[0094] Various features, aspects and advantages of the present disclosure can also be realized in any arrangement of aspects of the present disclosure, including but not limited to the technical solutions defined in the aspects listed below:

[0095] An avionics system comprising: a configuration tool arranged to receive a selection of a data store of the avionics system and a selection of at least one of a first receiving component associated with a proprietary first protocol and a second receiving component associated with a non-proprietary second protocol; generate a first configuration file that can be provided to at least one of the first receiving component and the second receiving component, the first configuration file comprising instructions for at least one of a first data output from the selected data store to the first receiving component and a second data output from the selected data store to the second receiving component; based on receipt of the selection of the second receiving component, generate a second configuration file that can be provided to the second receiving component, the second configuration file comprising instructions that can be used by the second receiving component to transform the second data output by the second receiving component; a data access component arranged to access data in the data store based on the first configuration file and access a definition database defining the proprietary first protocol based on the selection of the first receiving component and configure the accessed data according to the non-proprietary second protocol based on the definition database, the data access component further configured to output the data to the at least one of the first receiving component and the second receiving component according to the non-proprietary second protocol based on the first configuration file; wherein the first receiving component is configured to receive data output from the data access component according to the non-proprietary second protocol; and wherein the second receiving component is configured to receive data output from the data access component according to the non-proprietary second protocol and transform the data received from the data access component based on the second configuration file.

[0096] The avionics system of any preceding clause, further comprising a user interface, wherein the configuration tool is configured to receive the selection of the data store via the user interface.

[0097] The avionics system of any preceding clause, wherein the user interface enables a user to select the data store from a set of available data stores and select the at least one of the first receiving component and the second receiving component to receive the selected data store.

[0098] The avionics system of any preceding clause, wherein the configuration tool is configured to generate the first configuration file based at least in part on the selection of the data store.

[0099] The avionics system of any preceding clause, wherein the second configuration file defines the non-proprietary second protocol.

[0100] The avionics system of any preceding clause, wherein the first configuration file comprises the definition database.

[0101] The avionics system of any preceding clause, wherein the definition database is provided to the avionics system by one of the first receiving component and an EFB.

[0102] The avionics system of any preceding clause, wherein the first receiving component is configured to operate based on the data received from the data access component.

[0103] The avionics system of any preceding clause, wherein the data access component is configured to provide the second configuration file to the second receiving component.

[0104] The avionics system of any preceding clause, wherein the second receiving component is configured to operate based on the received data.

[0105] A method of configuring data in an avionics system, the method comprising:

[0106] receiving, by a configuration tool, a selection of a data store of the avionics system and a selection of at least one of a first receiving component associated with a proprietary first protocol and a second receiving component associated with a non-proprietary second protocol; generating, by the configuration tool, a first configuration file comprising instructions for at least one of a first data output from the selected data store to the first receiving component and a second data output from the selected data store to the second receiving component; in response to receiving the selection of the second receiving component: generating, by the configuration tool, a second configuration file comprising instructions that can be used by the second receiving component to translate the second data output; providing, by the configuration tool, the second configuration file to the second receiving component; receiving, by a data access component of the avionics system, the first configuration file; accessing, by the data access component, the selected data store based on the first configuration file; retrieving, by the data access component, data from the selected data store based on the first configuration file; in response to the instructions for the first data output to the first receiving component: accessing, by the data access component, a definition database that defines the proprietary first protocol; configuring the data retrieved by the data access component in accordance with the non-proprietary second protocol;

[0107] providing, by the data access component, the retrieved data to at least one of the first receiving component and the second receiving component based on the non-proprietary second protocol; and operating the at least one of the first receiving component and the second receiving component based on the provided data.

[0108] The method of any preceding clause, wherein the configuration tool receives the selection of the data store via one of a user interface and an avionics device.

[0109] The method of any preceding clause, wherein the user interface enables a user to select the data store from a set of data stores and to select the at least one of the first receiving component and the second receiving component.

[0110] The method of any preceding clause, wherein the first configuration file further comprises the definition database.

[0111] The method of any preceding clause, wherein the first configuration file is provided to the data access component via one of an EFB and the first receiving component.

[0112] The method of any preceding clause, further comprising converting, by the second receiving component, data output by the data access component based on the second configuration file.

[0113] A non-transitory computer-readable medium comprising instructions that, when executed, cause a processor to at least: receive a selection of a data store of an avionics system and a selection of at least one of a first receiving component associated with a proprietary first protocol and a second receiving component associated with a non-proprietary second protocol; generate a first configuration file comprising instructions for at least one of a first data output from the selected data store to the first receiving component and a second data output from the selected data store to the second receiving component; in response to receiving the selection of the second receiving component: generate a second configuration file comprising instructions that can be used by the second receiving component to convert the second data output; provide the second configuration file to the second receiving component; access the selected data store based on the first configuration file; in response to the instructions for the first data output to the first receiving component, access a definition database that defines the proprietary first protocol; retrieve data from the selected data store based on the first configuration file; convert the retrieved data from the proprietary first protocol to the non-proprietary second protocol; and provide the retrieved data to at least one of the first receiving component and the second receiving component according to the non-proprietary second protocol.

[0114] The non-transitory computer-readable medium of any preceding clause, wherein the selection of the data store is received via one of a user interface and an avionics device.

[0115] The non-transitory computer-readable medium of any preceding clause, wherein the user interface enables a user to select the data store from a set of available data stores and select the at least one of the first receiving component and the second receiving component.

[0116] The non-transitory computer-readable medium of any preceding clause, wherein the definition database is provided to the non-transitory computer-readable medium by one of the first receiving component and an EFB.

Claims

1. An avionics system, characterized in that, include: Configuration tool, the configuration tool being arranged as follows: The system receives selections for data storage of the avionics system, and selections for at least one of a first receiving component associated with a proprietary first protocol and a second receiving component associated with a non-proprietary second protocol. Generate a first configuration file that can be provided to at least one of the selected first receiving component and the second receiving component, the first configuration file including instructions for at least one of a first data output from the selected data storage to the first receiving component and a second data output from the selected data storage to the second receiving component; Based on the received selection of the second receiving component, a second configuration file is generated that can be provided to the second receiving component. The second configuration file includes instructions that can be used by the second receiving component to transform the second data output through the second receiving component. A data access component is configured to access data in the data storage based on a first configuration file, and to access a definition database defining the proprietary first protocol based on a selection of a first receiving component, and to configure the accessed data based on the definition database according to the non-proprietary second protocol. The data access component is further configured to output the data to at least one of the first receiving component and the second receiving component according to the non-proprietary second protocol based on the first configuration file. The first receiving component is configured to receive data output from the data access component according to the non-proprietary second protocol; and The second receiving component is configured to receive data output from the data access component according to the non-proprietary second protocol, and to transform the data received from the data access component based on the second configuration file.

2. The avionics system according to claim 1, characterized in that, It further includes a user interface, wherein the configuration tool is configured to receive selections for the data storage via the user interface.

3. The avionics system according to claim 2, characterized in that, in, The user interface enables a user to select the data storage from a set of available data storages, and to select at least one of the first receiving component and the second receiving component to receive the selected data storage.

4. The avionics system according to claim 1, characterized in that, in, The configuration tool is configured to generate the first configuration file based at least in part on the selection of the data storage.

5. The avionics system according to claim 1, characterized in that, in, The second configuration file defines the non-proprietary second protocol.

6. The avionics system according to claim 1, characterized in that, in, The first configuration file includes the definition database.

7. The avionics system according to claim 1, characterized in that, in, The definition database is provided to the avionics system by one of the first receiving component and the EFB.

8. The avionics system according to claim 1, characterized in that, in, The first receiving component is configured to operate based on the data received from the data access component.

9. The avionics system according to claim 1, characterized in that, in, The data access component is configured to provide the second configuration file to the second receiving component.

10. The avionics system according to claim 9, characterized in that, in, The second receiving unit is configured to operate based on the received data.

11. A method for configuring data in an avionics system, characterized in that, The method includes: The configuration tool receives selections for data storage of the avionics system, as well as selections for at least one of a first receiving component associated with a proprietary first protocol and a second receiving component associated with a non-proprietary second protocol; The configuration tool generates a first configuration file, which includes instructions for at least one of storing selected data from the data source to the first receiving component and storing selected data from the data source to the second receiving component. In response to the received selection of the second receiving component: The configuration tool generates a second configuration file, which includes instructions that can be used by the second receiving component to transform the second data output; The configuration tool provides the second configuration file to the second receiving component; The first configuration file is received by the data access component of the avionics system; The data access component accesses the selected data storage based on the first configuration file; The data access component retrieves data from the selected data storage based on the first configuration file; In response to the instruction for the first data output to the first receiving component: The data access component accesses the definition database that defines the proprietary first protocol; The data retrieved by the data access component is configured according to the non-proprietary second protocol. The data access component provides the retrieved data to at least one of the first receiving component and the second receiving component based on the non-proprietary second protocol; and Based on the provided data, operate at least one of the first receiving component and the second receiving component.

12. The method according to claim 11, characterized in that, in, The configuration tool receives a selection of the data storage via either a user interface or an avionics device.

13. The method according to claim 12, characterized in that, in, The user interface enables a user to select the data storage from a set of data storages and to select at least one of the first receiving component and the second receiving component.

14. The method according to claim 11, characterized in that, in, The first configuration file further includes the definition database.

15. The method according to claim 12, characterized in that, in, The first configuration file is provided to the data access component via either the EFB or the first receiving component.

16. The method according to claim 11, characterized in that, It further includes data output by the data access component being converted by the second receiving component based on the second configuration file.

17. A non-transitory computer-readable medium including instructions, characterized in that, When the instruction is executed, it causes the processor to at least: The option to receive data storage for the avionics system, and the option to receive at least one of a first receiving component associated with a proprietary first protocol and a second receiving component associated with a non-proprietary second protocol; Generate a first configuration file, the first configuration file including instructions for at least one of a first data output from a selected data storage to a first data output from a first receiving component and a second data output from a selected data storage to a second receiving component; In response to the received selection of the second receiving component: Generate a second configuration file, the second configuration file including instructions that can be used by the second receiving component to transform the second data output; The second configuration file is provided to the second receiving component; Access the selected data storage based on the first configuration file; In response to an instruction for the first data output to the first receiving component, access the definition database defining the proprietary first protocol; Data is retrieved from the selected data storage based on the first configuration file; The retrieved data is converted from the proprietary first protocol to the non-proprietary second protocol; and The retrieved data is provided to at least one of the first receiving component and the second receiving component according to the non-proprietary second protocol.

18. The non-transitory computer-readable medium according to claim 17, characterized in that, in, The user interface and avionics device receive the option to store data.

19. The non-transitory computer-readable medium according to claim 18, characterized in that, in, The user interface enables a user to select the data storage from a set of available data storages and to select at least one of the first receiving component and the second receiving component.

20. The non-transitory computer-readable medium according to claim 17, characterized in that, in, The definition database is provided to the non-transitory computer-readable medium by one of the first receiving component and the EFB.

Images