Patent Description:
To select a desired access subnetwork, vehicular communication systems may use policy-based rules to identify desired access subnetwork when the vehicle is traveling. For example, a communication system may use programmed logic to apply selection rules while using real-time inputs such as the vehicle state, geographical position, communication application needs, and access subnetwork conditions and availability. Also, the programmed logic may control the operation of devices on the vehicle for communicating through the different access subnetworks.

Typically, the rules may be programmed into the executing software but parameter values for the rules may be configured via a data loading mechanism. Accordingly, the rules and parameter types may be fixed according to a software version but the parameter values may be updatable. For example, the parameter values may be updated by loading configuration data and installing parameter values for operational use while the vehicle is not in operation. In some implementations the parameter values may be sent to the vehicle through a access subnetwork for future installation or activation when the vehicle is no longer operating. US Patent no. <CIT> relates to systems and methods for using machine learning to dynamically modify rules for selecting suitable mobile networks. US Patent no. <CIT> relates to systems and methods for enhanced subnetwork preference logic. US Patent no. <CIT> relates to the implementation of enterprise driven policies for network access in an enterprise network.

Understanding that the drawings depict only some embodiments and are not therefore to be considered limiting in scope, the exemplary embodiments will be described with additional specificity and detail using the accompanying drawings, in which:.

In accordance with common practice, the various described features are not drawn to scale but are drawn to emphasize specific features relevant to the example embodiments.

In the following detailed description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific illustrative embodiments. However, it is to be understood that other embodiments may be utilized and that logical, mechanical, and electrical changes may be made.

Systems and methods for providing communication management using rules-based decision systems and artificial intelligence are described herein. In some embodiments, methods discussed herein may flexibly create and update both rules and parameters, chain the rules in a desired order of the decision process and in combinations to create more complex rules, and bind the configurable parameters to the rules, without updating or upgrading the installed software.

In some embodiments, the software executes the chaining of the rules during operation. When chaining the rules, the software may utilize information about the vehicle and communication networks as real-time inputs for the constructed rules-based logic. For example, the software may use input such as vehicle state, vehicle geographical position, vehicle data communication needs, access subnetwork conditions, and access subnetwork status to select the access subnetwork to use for communications for various applications executing on the vehicle and to connect application data flows to the interfaces for the selected access subnetworks. The logic may also control operation of the radios that communicate through particular access subnetworks depending on the management control functions exposed by the radios.

In certain embodiments, where a vehicle is part of a fleet of vehicles and associated with the operations center for the fleet tools may be provided to allow the operations center to build and update the rule set and update the parameter values. The rules and parameter updates may be sent to the vehicle, using one of the selected access subnetworks, directly into a managing device on the vehicle or for staging in a server device such as a data loader device for later installation when the vehicle is not in operation. Additionally, the rules and parameter updates may be modified by the managing device through machine learning algorithms. The rules may be installed, and the rules and parameters may be updated at times that are convenient for the operation of the vehicle such that the installation and updating processes do not interfere with the operation of the vehicle.

Accordingly, embodiments described herein provide for rules where the chaining of rules, the ordering of rules, and the binding of parameters to each rule are flexibly created using centrally managed tools that create an update rule sets. Additionally, policy decision engine software may be installed in a one time installation, where the software can use the rule sets without the need for new software versions when new and updated rules are made. Further, new and updated rule sets may be automatically uplinked, loaded, and installed on the vehicle without the need for manual administrative configurations. Moreover, new and updated rule sets may be uplinked to the vehicle using any access subnetwork without affecting the operation of the vehicle and without the use of manual data loading using physical media. Also, the rule base may be improved through machine learning without needing to maintain and update the rules base through centrally managed tools.

<FIG> is a block diagram illustrating a vehicle <NUM> that is capable of communicating through multiple communication channels, referred to herein as access subnetworks <NUM>. A vehicle <NUM> may refer to any machine or device that is capable of movement. For example, the vehicle <NUM> may be an aircraft, a spacecraft, a sea craft, an automobile, or other mechanical device capable of movement. In some embodiments, a communication system or device may reside on the vehicle <NUM>, where the communication system is capable of communicating through multiple access subnetworks <NUM> (where the access subnetworks are referred to generally as access subnetworks <NUM> and individually as access subnetwork <NUM>-<NUM> - <NUM>-N). To communicate through the access subnetworks <NUM>, the vehicle <NUM> may include one or more radios <NUM> (where the radios are referred to generally as radios <NUM> and individually as radio <NUM>-<NUM> - <NUM>-N). The access subnetworks may allow the vehicle <NUM> to communicate with one or more destinations <NUM>, where a destination <NUM> is a communication system remotely located in relation to the vehicle <NUM> that may receive communications from the vehicle <NUM>. Additionally, the access subnetworks <NUM> may allow the vehicle <NUM> to communicate with an operations center <NUM>, where the operations center <NUM> is a managing organization that controls some aspect of the operation of the vehicle <NUM>. As illustrated, the access subnetworks <NUM> may be connected to the destination <NUM> and the operations center115 through the respective Communications Provider Network <NUM> using wired or fiber-optic connections. The state information <NUM> provides information about vehicle state for purposes of communications management, and may include geographic position, speed and direction vector, three-dimensional attitude of the vehicle, phase of mission, etc..

In certain embodiments, the vehicle <NUM> may include one or more processing units <NUM> that execute computer executable instructions, where the instructions direct the processing unit to manage communications with the one or more access subnetworks <NUM>. In some embodiments, the computer executable instructions may be stored on a memory unit <NUM> for execution, another memory storage device within the vehicle <NUM>, received through one or more of the access subnetworks <NUM> and executed as instructions are received by the processing unit <NUM>, and the like.

The processing unit <NUM> or other computational devices found within the vehicle <NUM> may be implemented using software, firmware, hardware, or other appropriate combination thereof. The processing unit <NUM> and other computational devices may be supplemented by, or incorporated in, specially-designed application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). The processing unit <NUM> and other computational devices may also include or function with software programs, firmware, or other computer readable instructions for carrying out various process tasks, calculations, and control functions used in the present methods and systems.

Further, the methods described herein may be implemented by computer executable instructions such as program modules or components, which are executed by at least one processing unit, such as the processing unit <NUM>. Generally, program modules include routines, programs, objects, data components, data structures, algorithms, and the like, which perform particular tasks or implement particular abstract data types. Instructions for carrying out the various process tasks, calculations, and generation of other data used in the operations of the methods described herein may be implemented in software, firmware, or other computer readable instructions. These instructions are typically stored on any appropriate computer program product that includes a computer-readable medium used for storage of computer-readable instructions or data structures. The computer-readable medium may be any available media that can be accessed by a general purpose or special purpose computer or processor, or any programmable logic device. In certain implementations, the computer readable medium may be stored on the memory unit <NUM>.

Suitable computer-readable storage media, such as that found as part of the memory unit <NUM>, may include, for example, non-volatile memory devices including semi-conductor memory devices such as random access memory (RAM), read only memory (ROM), electrically erasable programmable ROM (EEPROM), or flash memory devices; magnetic disks such as internal hard disks or removable disks; optical storage devices such as compact discs (CDs), digital versatile discs (DVDs), Blu-ray discs; or any other media that can be used to carry or store desired program code in the form of computer executable instructions or data structures.

In certain embodiments, the memory unit <NUM> may store user applications software <NUM>. Other user applications may be hosted on other devices on the vehicle, such that the other devices are connected to the processing unit <NUM> via onboard interfaces. As described herein, user applications software <NUM> refers to groups of executable instructions that, when executed together, cause the processing unit <NUM> to perform particular tasks related to the vehicle's missions. User applications software <NUM> are user applications. The communications management software stored in the memory unit <NUM> may include the following components: learning engine software <NUM>, decision engine software <NUM>, data acquisition software <NUM>, and enforcement mechanism software <NUM>. The communications management software performs the work to select the access subnetworks and manage connectivity for the applications <NUM> to communicate with destinations <NUM> for the purpose of executing the vehicle missions. Likewise, the communications management software communicates with the operation center <NUM> for purposes described above.

In certain embodiments, the communications that result from the execution of the user applications software <NUM> for transmission through one of the radios <NUM> may be better suited for transmission through a particular access subnetwork <NUM> in the available access subnetworks <NUM>. To determine which access subnetwork to use for the transmission of data, the memory unit <NUM> may store knowledge base <NUM>, which is the on-vehicle repository of the knowledge information, policy and rules-based logic to make and enforce communications management decisions. The knowledge base <NUM> may include facts for decision making and may be initialized prior to vehicle deployment and then managed and enhanced from knowledge gained through vehicle missions and machine learning. The policy consists of mission goals for data communications needed by the applications, and user policy based on regulatory rules and service level agreements with communication providers. The goals for data communications are specified as needed quality of service. The rules-based logic is constructed based on the knowledge and policy, and modified through the machine learning process. When executed by the processing unit <NUM>, rules-based logic may direct the processing unit <NUM> to select a access subnetwork <NUM> for transmission of information, and manage the on-vehicle routing of information data flows through the selected access subnetwork <NUM>. Also, the rules-based logic <NUM> may provide instructions for controlling the radios <NUM>. For example, communication management software may direct the processing unit <NUM> to transmit data through one of the access subnetworks <NUM>. The processing unit <NUM> may execute the rules-based logic <NUM> to determine that the access subnetwork <NUM>-<NUM> is best suited for the transmission of information to a particular destination <NUM>. Accordingly, the processing unit <NUM> may transmit information through the radio <NUM>-<NUM> that is associated with the access subnetwork <NUM>-<NUM>. To properly effect transmission through the radio, the communication management software may control the radio, for example power up the radio, change the transmission power level, initiate link establishment, etc. In addition, the communication management software may power down another radio that is not needed, or initiate link connection termination in one or more radios.

The data acquisition software <NUM> acquires information from other vehicle system components and provides the information to the learning engine software <NUM> to effectively form a feedback loop. The feedback information may include connectivity status, network performance, and actual QoS experienced by user applications <NUM>. The learning engine software <NUM> may use this feedback information in addition to inputs consisting of radio availability, state and status, vehicle state, and user application demand. It applies the feedback and inputs to a learning algorithm, which updates the decision logic for selecting and controlling radios and configuring connectivity onboard the vehicle via the enforcement mechanism software <NUM>.

<FIG> is a block diagram illustrating an exemplary embodiment of a pre-configured, rules-based decision system <NUM> without machine learning. As used herein, the rules-based decision system <NUM> may be a system that manages communications through various access subnetworks. In particular, the rules-based decision system <NUM> applies rules to acquired data to determine which access subnetwork to use for communications for a particular application, such as the applications associated with the user applications software <NUM> that is executed by the processing unit <NUM>. As described herein, the Rules Base <NUM> may be similar to the rules-based logic in the Knowledge Base <NUM>.

In some embodiments, the rules-based decision system <NUM> may be associated with a communication management system <NUM>. For example, a communications management system <NUM> may be a device that acquires information regarding multiple communication links available to a vehicle and manages the transmission and reception of information that is transmitted through the communication links. For example, the communication management system <NUM> may be on an aircraft. During operation of the aircraft, various software applications may be executed by one or more processing units on the aircraft, where the executing applications may generate messages for transmission to one or more remote destinations. The aircraft may have multiple radios for communicating through multiple access subnetworks in a manner similar to the system described above in <FIG>.

In certain embodiments, the communication management system <NUM> includes a decision engine <NUM>. As described herein, the decision engine <NUM> may refer to computer executable instructions, that when executed, cause a processing unit (such as processing unit <NUM>) to determine which access subnetwork, of various access subnetworks, to use for communications created by the various applications executed by processing units on a vehicle. In some embodiments, the decision engine <NUM> uses information acquired from a data acquisition <NUM> and a rules base <NUM> to determine which access subnetwork to use for communications. As used herein, the data acquisition <NUM> may be a data structure into which information is stored or the data acquisition <NUM> may be computer readable instructions that direct a processing unit, such as the decision engine <NUM>, to acquire information, where the information is pertinent to determining which access subnetwork to use for transmissions. Also, the decision engine <NUM> may use information acquired from a rules base <NUM>. As used herein, the rules base <NUM> may refer to a series of rules and policies that are applicable by the decision engine <NUM> when deciding which access subnetwork to use for communications.

In some embodiments, the information acquired by the data acquisition <NUM> represents the state of the vehicle and access subnetworks through which the vehicle may communicate. As illustrated, the rules-based decision system <NUM> may include state information <NUM>. As used herein, the state information <NUM> may represent data associated with the present state of the vehicle. For example, the state information <NUM> may represent the position, velocity, time, trajectory, available communication options, flight phase, attitude of the vehicle, operating environment, and the like. The data acquisition <NUM> may receive information from the state information <NUM>.

Additionally, the data acquisition <NUM> may receive information from a communication network stack <NUM>. As shown, the rules-based decision system <NUM> may include a communication network stack <NUM>. The communication network stack <NUM> may provide an interface between user applications and the various radios on the vehicle. For example, the rules-based decision system <NUM> may include user applications <NUM>, where the user applications <NUM> function similarly to the user applications software <NUM> described above in <FIG>. During the operation of the vehicle, a user application <NUM> may request communication usage changes, which requests may be communicated by the communication network stack to the data acquisition <NUM>. Additionally, the communication network stack <NUM> may communicate network statistics to the data acquisition <NUM>.

As illustrated, the communication network stack <NUM> is in communication with a access subnetwork radio <NUM>. In particular, the user application <NUM> provides and receives messages through the communication network stack <NUM> to the access subnetwork radios <NUM>, where the access subnetwork radio <NUM> transmits information received from the communication network stack <NUM> and provides information received through a access subnetwork to the communication network stack <NUM>, where the information is then provided for processing by a processing unit in association with the correct user application <NUM>.

In some embodiments, the access subnetwork radio <NUM> may include a management function <NUM> and a modem function <NUM>. As used herein, the management function <NUM> may provide an interface, where an external device can send messages through the interface to manage the operation of the access subnetwork radios <NUM>. Additionally, the management function <NUM> may send messages to the data acquisition <NUM> representing the status and control of the various access subnetwork radios, channel access, and other information related to the operation of the access subnetworks. As used herein, the modem function <NUM> receives data from the communication network stack <NUM> and prepares it for transmission through a access subnetwork. Also, the modem function <NUM> receives a signal through the access subnetwork and demodulates it for subsequent processing by an associated user application <NUM>.

In certain embodiments, when the data acquisition <NUM> has acquired the requisite data from the various data sources, the decision engine <NUM> accesses the data and applies the rules specified in the rules base <NUM> to identify a particular access subnetwork for transmitting a particular message and changes to the communication network stack <NUM> and access subnetwork radios <NUM>. When the decision engine <NUM> makes a decision, the decision engine <NUM> communicates the decision to an enforcement mechanism <NUM>. The enforcement mechanism <NUM> may be software or hardware that transmits messages to the communication network stack <NUM> and the access subnetwork radios <NUM> to carry out the decision received from the decision engine <NUM>. For example, the enforcement mechanism <NUM> may send changes to configuration of interfaces between data flows between the user applications <NUM> and the access subnetwork radios <NUM> along with other connectivity configurations. Additionally, the enforcement mechanism <NUM> may send messages to the management function <NUM> that direct the operation of the management function <NUM> within the access subnetwork radios <NUM>.

As illustrated in <FIG>, the rules base <NUM> is programmed as part of the communications management system <NUM>. The rules base <NUM> can receive new parameter values through a policy update <NUM>, that is typically loaded via a data loading mechanism. Accordingly, the programmed rules base <NUM> is fixed by the software version of the communications management system <NUM>. Also, the parameter types are similarly fixed by the software version of the communications management system <NUM>, while the parameter values may be loaded as configuration data by a data loader service or through an uplinked through one of the access subnetwork radios <NUM>. When the communications management system <NUM> receives the policy update <NUM>, the communications management system <NUM> may wait until the vehicle is in a safe state for installation of the policy update <NUM>. For example, when the vehicle is an aircraft, the communications management system <NUM> may wait until the aircraft is on the ground before installation of the policy update <NUM>.

<FIG> is a block diagram illustrating a system <NUM> for initializing rules for use by a decision engine <NUM>. As illustrated, the system <NUM> includes a policy update <NUM>, a rules base <NUM>, a decision engine <NUM>, a data acquisition <NUM>, and an enforcement mechanism <NUM>. The policy update <NUM>, rules base <NUM>, decision engine <NUM>, data acquisition <NUM>, and enforcement mechanism <NUM> function in a similar manner to the policy update <NUM>, rules base <NUM>, decision engine <NUM>, data acquisition <NUM>, and enforcement mechanism <NUM> described above in relation to <FIG>.

In certain embodiments, the rules base <NUM> may store a set of rules <NUM>. As used herein, the rules may refer to information that dictates to the decision engine how to select a access subnetwork and/or manage characteristics of a access subnetwork for communications from a user application on a vehicle. In some embodiments, a rule set may be created by a fleet manager that controls multiple vehicles. The fleet manager may install the same set of rules for one or more vehicles in the fleet. For example, a vehicle may be part of a fleet of aircraft, where the aircraft within the fleet had the same set of rules stored thereon. Typically, the rules may be installed as part of the software that executes on a vehicle.

Additionally, the rules base <NUM> may store a set of parameters <NUM>. As used herein, the parameters may refer to configurable information that can be used by the decision engine <NUM> in conjunction with the rules <NUM> to select a access subnetwork and/or manage characteristics of a access subnetwork for communication from a user application on a vehicle. For example, whereas rules are common across a fleet of vehicles, parameters can be configured for specific regions of travel, for specific customers, for specific times of travel, or other factors related to the travel of the vehicle and/or user applications executing on the vehicle.

When the decision engine <NUM> begins operation, the decision engine <NUM> may perform an initialization process. In certain embodiments, the decision engine <NUM> may include a rules processor <NUM>. The rules processor <NUM> may be an embedded processor, or other processing unit such as those described above in connection with the processing unit <NUM> that executes computer readable instructions to select a access subnetwork and/or manage characteristics of a access subnetwork for communications from a user application on a vehicle.

In certain embodiments, when the decision engine <NUM> performs the initialization process, the rules processor <NUM> may chain the rules <NUM> in a desired order as dictated by the policy update <NUM>. When the rules <NUM> are chained, the rules processor <NUM> may bind parameters <NUM> to the rules chain. Rules processor <NUM> may then map and bind data received from the data acquisition <NUM> to variables in the rules <NUM>. When the decision engine <NUM> is actively making a decision associated with the operation of the access subnetworks, the rules processor <NUM> may process the rules chain and call appropriate rule primitive functions in a library of rule primitive functions <NUM>, where a function is associated with one or more rules and the bound parameters and acquired data are used as arguments for the called functions. Upon completion of the processing of the rules chain, the rules processor <NUM> may provide a final decision to the enforcement mechanism <NUM>, where the enforcement mechanism <NUM> enforces the final decision on the access subnetworks and components associated with communication through the access subnetworks.

<FIG> is a flowchart diagram illustrating an exemplary method <NUM> for updating rules on a vehicle. For example, a tool may be provided that allows a fleet manager to update a rule set and set and update parameter values. For example, a ground-based tool may be provided to an airline, where the airline uses the ground-based tool to update a rule set and update parameter values for aircraft in a fleet of aircraft. Accordingly, the method <NUM> proceeds at <NUM>, where a configuration file is created or updated. For example, a fleet manager may use a provided tool to create or update a configuration file with rules and parameters. The configuration file may be created for loading into a communication management system on a vehicle managed by the fleet manager. When the configuration file is created or updated, the method <NUM> may optionally proceed at <NUM> where the settings in the configuration file are optimized. For example, the fleet manager may use the tool to optimize the settings in the configuration file using simulation and performance prediction algorithms.

In further embodiments, when the configuration file is created and/or updated and optionally optimized, the method <NUM> may proceed at <NUM>, where the configuration file is loaded onto the vehicle. For example, the configuration file may be loaded through a local access point or uplinked via an access access subnetwork. When the configuration file is loaded to the vehicle, it may be stored on a data loading device for subsequent installation when convenient for the operation of the vehicle. When installation is convenient for the vehicle, the method <NUM> may proceed at <NUM> where the configuration file is transferred and installed in the communications management system. For example, when the vehicle is an aircraft and aircraft is not in-flight, the configuration file may be transferred to the communications management system using a data loading device or service. The configuration file may then be installed where it may be ready then for operational use.

In certain embodiments, when the configuration files are installed, the configuration file may be used by installed software when selecting a access subnetwork for communication or managing characteristics of communications through a access subnetwork. <FIG> is a flowchart diagram of a method <NUM> for using the information in the configuration file to select and/or manage a access subnetwork for communications from a vehicle. Method <NUM> proceeds at <NUM>, where the software begins operation. Upon the beginning of operation, the method <NUM> proceeds of <NUM>, where the software is initialized. During the initialization of the executing software, the method <NUM> may proceed at <NUM>, where a rules base is constructed. For example, the rules base may be constructed as a chain of rules as instructed by the installed configuration file. When the rules base is constructed, the method <NUM> may proceed at <NUM>, where parameters are bound to variables in the rules.

In further embodiments, when the execution of the software completes the initialization process, the method <NUM> may proceed at <NUM> where the acquisition of real-time input is initiated. For example, the executing software, such as the software executed by the decision engine <NUM>, may acquire inputs that may include vehicle state information, status information from datalink systems via onboard radio systems, dynamic requests of data communication usage, demands and changes for user applications, network statistics from onboard network stacks, and additional information that may be useful. In some embodiments, the real-time inputs may be acquired periodically, continuously, or requested in response to events.

In some embodiments, when the real-time inputs have been acquired, the method <NUM> proceeds at <NUM>, where a policy-based decision on selection of a access subnetwork is made. For example, the real-time inputs may be mapped to variables in the rules and parameters. Based on the rules and information, a decision engine may select a access subnetwork. In some embodiments, the policy-based decision is made periodically or may be event driven. When the access subnetwork is selected, the method <NUM> proceeds at <NUM> where radio control and management is output to radios based on the policy-based decision. For example, information provided to the radios may include instructions to power up or down, instructions to link to a desired class of service, instructions to start or stop service, and the like. Additionally, the method <NUM> proceeds at <NUM> where interfaces between data flows and radios are configured based on the policy-based decision. Also, connectivity between various components in the dataflow and the radios may be configured.

In additional embodiments, when the radios and communication devices are configured, the method <NUM> may proceed at <NUM>, where it is determined whether the software is at an end of an operational mode. If the software is not at an end of an operational mode, the method <NUM> returns to <NUM> to repeat the process of making and enforcing a policy-based decision. In contrast, if the software is at the end of an operational mode, the method <NUM> may proceed at <NUM>, where operation of the software is ended.

As described above, the rule set is typically programmed as part of a vehicle's communication management software. As such, the program rules and parameter types may be fixed by the software version. Thus, to change the rules and parameter types, new software is created and installed on the vehicle when convenient for the operation of the vehicle. For example, to change the rules on aircraft, new software is created and then provided to the dated voter device. When the aircraft is on the ground, between flights, the software may be installed. However, having to upgrade the software to change parameter values and rule configurations is an expensive and inefficient use of resources and time.

Systems and methods described below provide fleet managers full flexibility for provisioning and maintaining policy-based rules without requiring software changes. Additionally, the rules, parameter types, and parameter values may be updated using one of the selected access subnetworks to stage the updates in a data loader device where later installation may be performed when convenient to the vehicle. Accordingly, the updating of rules, parameter types, and parameter values does not rely on manual data loading using physical, portable storage media. Further, a decision engine may use machine learning to upgrade decision logic and parameters by itself without having to receive updated values from a fleet manager.

<FIG> is a block diagram illustrating an exemplary embodiment of a rules-based decision system <NUM> using machine learning. As illustrated, the system <NUM> includes a knowledge base <NUM> (consisting of configured policy <NUM>, which can be updated via policy update <NUM>, information base <NUM>, and Rules Base <NUM>), a data acquisition <NUM>, a decision engine <NUM>, an enforcement mechanism <NUM>, state information <NUM>, user applications <NUM>, a communication network stack <NUM>, access subnetwork radios <NUM>, each radio with a management function <NUM>, and a modem function <NUM>.

The system shown in <FIG> is a feedback control system. The data acquisition <NUM> acquires information from other vehicle system components and provides the information to the learning engine <NUM> to effectively form a feedback loop. The feedback information is connectivity status, network performance and actual QoS experienced by user applications. The learning engine <NUM> uses this feedback information in addition to inputs consisting of policy, radio availability, state and status, vehicle state, and user application demand. It applies the feedback and inputs to a learning algorithm, which updates the decision logic for selecting and controlling radios and configuring connectivity onboard the vehicle via the enforcement mechanism <NUM>.

In certain embodiments, the system <NUM> may receive a policy update <NUM>. In contrast to the policy update <NUM> described above, the policy update <NUM> may describe two types of possible policy updates. In a first type, the policy update <NUM> may contain an initial configured policy <NUM>. In some implementations, an initial configured policy <NUM> may include information related to performance goals of the communication system in addition to the rules described above. For example, performance goals may be related to the speed of communication, the cost of communication, mission objectives, among other desirable performance goals. In some implementations, a mission objective may describe a characteristic that a chosen access subnetwork may satisfy. Exemplary mission objectives may include a least cost communication channel, a least delay communication channel, a secure communication channel, a high integrity communication channel, a low loss communication channel, dynamic changes in application needs, and the like.

Additionally, the initial configured policy <NUM> may include an indication that the provided rules base is an initial rules base. An initial rules base may be provided upon the initial installation of software or whenever a configured policy <NUM> is updated and installed. A operations center may also provide the initial configured policy <NUM> after performing post-processing of data received from the vehicle. In a second type, the policy update <NUM> may contain an updated rule set that is sent to the vehicle. The communication management systems <NUM> may update the rules base in the configured policy <NUM> without having to install the software. Accordingly, new and updated rule sets may be automatically uplinked, loaded and installed in the configured policy <NUM> without the need for manual administrative configuration. Additionally, new and updated rule sets may be uplinked to a vehicle using any access subnetwork without the need of additional downtime of the vehicle or the use of manual data loading using physical media.

In some embodiments, the communications management system <NUM> may include a learning engine <NUM>. The learning engine <NUM> may acquire information from the configured policy <NUM>, the data acquisition <NUM>, and an information base <NUM>. The learning engine may process the acquired information using machine learning techniques to improve the rules base 6nn. Examples of possible machine learning techniques may include neural networks, deep learning, among other possible machine learning techniques. The improved rules base <NUM> stored therein, having updated rules based on machine learning techniques and performance goals, is provided to the decision engine <NUM>. Using the improved rules base <NUM> and data from the data acquisition <NUM>, the decision engine <NUM> may provide decisions to an enforcement mechanism <NUM> associated with the configuration of interfaces between data flows and access subnetwork radios along with control and management commands for controlling the access subnetwork radios. Upon reception of the decision from the decision engine <NUM>, the enforcement mechanism <NUM> may enforce the received decision.

<FIG> is a flowchart diagram of a method <NUM> for configuring interfaces and managing radios using machine learning. Method <NUM> proceeds at <NUM>, where the executing software begins operation. During the beginning of operation, the method <NUM> proceeds of <NUM>, where the software is initialized. During the initialization of the executing software, the method <NUM> may proceed at <NUM>, where an initial rules base is constructed. For example, the rules base may be constructed as a chain of rules as instructed by an installed configuration file that is received from a configuration file received from a fleet manager, or other system that manages the vehicle. When the initial rules base is constructed, the method <NUM> may proceed at <NUM>, where parameters are bound to variables in rules in the initial rules base.

In further embodiments, when the execution of the software completes the initialization process, the method <NUM> may proceed at <NUM> where the acquisition of real-time input is initiated. For example, the executing software, such as the software executed by the data acquisition <NUM>, may acquire inputs that may include vehicle state information, status information from datalink systems via onboard radio systems, dynamic requests of data communication usage demands and changes for user applications, network statistics from onboard network stacks, and additional information that may be useful. In some embodiments, the real-time inputs may be acquired periodically, continuously, or requested in response to events.

When the acquisition of real-time inputs has been initiated, the method <NUM> proceeds at <NUM>, where an ordered sequence of acquired data is stored. For example, the acquired data streams received by the data acquisition <NUM> may be stored as sliding windows of records. When the acquired data streams are stored in sliding windows, the width of a window may be set based on the inputs used for the implemented machine learning algorithms and the onboard storage capacity of the communication management system. In some implementations, the data may be compacted by keeping recent and discarding old values of data types. In additional embodiment, the communication management system may provide the acquired data and/or the filtered records to a fleet manager or other operations center for post-processing and status reporting.

In some embodiments, when the real-time inputs have been acquired and ordered, the method <NUM> proceeds at <NUM>, where a policy-based decision on a selection of a access subnetwork is made. For example, the real-time inputs may be mapped to variables in the rules and parameters. Based on the rules and information, a decision engine <NUM> may select a access subnetwork. In some embodiments, the policy-based decision is made periodically or may be event driven. In addition to selecting a access subnetwork, the decision engine <NUM> may determine configuration changes to be made to the radios. When the access subnetwork is selected, the method <NUM> proceeds at <NUM> where radio control and management is output to radios based on the decision. For example, information provided to the radios may include instructions to power up or down, instructions to link to a desired class of service, instructions to start or stop service, and the like. In some embodiments, the management is output in response to the enforcement mechanism <NUM> receiving the decision from the decision engine <NUM>. Additionally, the method <NUM> proceeds at <NUM> where interfaces between data flows and radios are configured based on the decision. Also, connectivity between various components in the dataflow and the radios may be configured.

In certain embodiments, the method <NUM> proceeds at <NUM>, where performance metrics are computed based on input data. For example, as data is streamed into any combination of the decision engine <NUM>, the data acquisition <NUM>, or the information base <NUM>, the communications management system <NUM> may compute performance metrics based on the received data, where the received data includes acquired data streams and the configuration of the access subnetwork radios and network configurations.

In additional embodiments, the method <NUM> proceeds at <NUM>, where an ordered sequence of computed performance metric records is stored. Example of performance metric records or data may include communication link connectivity status, quality of connection, and the like. For example, in a similar manner to the stored ordered sequence of acquired data records, the metrics data streams could be stored as sliding windows of performance metric records. In some implementations, the width of the window may be set based on the needs of executing algorithms and/or on board storage capacity. Additionally, data may be compacted by keeping only recent values of data types. In some embodiments, the performance metric records may be transmitted by the communications management system <NUM> to a server controlled by a fleet manager at the operations center for post-processing and status reporting.

In certain embodiments, the method <NUM> proceeds at <NUM>, where the performance metric records may be applied to a learning algorithm. For example, the performance metric records and acquired data may be provided to the learning engine <NUM>. The learning engine <NUM> may execute a machine learning algorithm on the received data and performance metrics. The method <NUM> may then proceed at <NUM>, where the learning engine <NUM> determines whether to change parameter values. If the learning engine <NUM> determines that parameter values should be changed, the method <NUM> proceeds at <NUM>, where parameter values are updated in the rules base. For example, the learning engine <NUM> may update the parameter values stored in the rules base <NUM> maintained in the knowledge base <NUM>. In some implementations, a history of parameter values may be maintained, and the history may be sent to an operations center for additional post-processing.

When the parameter values have been updated or otherwise been determined that no parameters are to be changed, the method <NUM> proceeds at <NUM>, where the learning engine <NUM> determines whether to alter the rules chain. If the learning engine <NUM> determines that the rules chain should be altered, the method <NUM> proceeds at <NUM>, where changed rules in the rules base are updated. For example, the learning engine <NUM> may update the changed rules in the rules base by adding, removing, or reordering rules in the rules base <NUM> maintained in the knowledge base <NUM>. In some implementations, a history of the changed rules base may be downlinked to an operations center for additional post-processing. When the rules base has been updated or otherwise been determined that the rules base does not need updating, the method <NUM> proceeds at <NUM>, where the communications management system determines whether an operational mode has ended.

In some embodiments, if the operational mode has ended, the method <NUM> proceeds at <NUM>, the operation of the communications management system <NUM> ends. Alternatively, if the operational mode has not ended, the method <NUM> returns to <NUM>, where the communications management system <NUM> stores an ordered sequence of acquired data and performs the algorithm again with the potentially updated rules and parameter values.

By using machine learning to update the parameter values and rules base, the chaining and ordering of the rules and the binding of parameters to each rule are flexible using a centralized tool located at the operations center <NUM> in <FIG>, to create and update rule sets. For the aviation domain, the centralized tool is a ground-based tool. Additionally, the decision engine <NUM> may be installed in a one-time implementation and installation and the vehicle may use the rule sets without having to install the decision engine <NUM> software to include new and updated rules. Further, new and updated rule sets may be automatically uplinked, loaded, and installed on the vehicle without the need for manual administrative configurations and the rule sets may be transmitted to the vehicle using available access subnetworks during operational intervals. Moreover, the use of machine learning may improve the rule base without the need to maintain and update the rule base using tools controlled by an operations center.

<FIG> is a flowchart diagram of a method <NUM> for updating the rules base in a rules-based decision system with machine learning. The method <NUM> p proceeds at <NUM> where state information associated with the operation of a vehicle is acquired. Additionally, the method <NUM> proceeds at <NUM> where performance metric data based on the operation of one or more communication channels is acquired. Further, the method <NUM> proceeds at <NUM>, where machine learning is used to identify one or more changes to parameter values and rules. Also, the method <NUM> proceeds at <NUM>, where the rules base is updated with the changes to the parameter values.

Claim 1:
A vehicle comprising:
one or more access subnetwork radios (<NUM>) configured to communicate through one or more access subnetworks (<NUM>);
one or more interfaces configured such that an external device can transmit data through the interfaces to manage the operation of the access subnetwork radios;
a memory unit (<NUM>) that stores:
a knowledge base (<NUM>), wherein the knowledge base (<NUM>) stores parametric rules associated with the selection of a communication channel in one or more communication channels associated with the plurality of access subnetworks, status, performance and usage metrics for communications through the one or more communication channels, vehicle state information, and pre-configured policy on use of communication channels, wherein the parametric rules comprise rules including information that dictates how to select an access subnetwork and/or manage characteristics of an access subnetwork, the rules storing parameters relating to specific regions of travel, specific customers, specific times of travel, factors related to the travel of the vehicle and/or user applications executing on the vehicle; and a processing unit (<NUM>) configured to:
acquire state information associated with the operation of the vehicle and performance metric data based on the operation of the one or more communication channels associated with the plurality of subnetworks;
identifying one or more changes to parameter values and rules in the knowledge base; and
update the knowledge base (<NUM>) with updated parametric rules comprising updated rules and updated parameter values without stopping execution of software (<NUM>), wherein the updated parametric rules are created using machine learning performed on the acquired data and the information associated with the performance goals;
configure the interfaces based on a policy-based decision on a selection of an access subnetwork based on the updated rules and parameter values.