Platform-Agnostic FMS Data Access via Configurable Rule Parsing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing flight management systems lack a standardized mechanism for platform-agnostic data access, requiring specialized solutions for each user and compromising security and data control.

Innovation Solution

A system and method utilizing a standardized architecture with configuration files and rule-based engines to handle data format variations, moderated by context processing engines, ensuring secure and licensed access to flight management data.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a standardized architecture with configuration files and rule-based engines is implemented, then platform agnostic data access is enabled, but system complexity increases

Engineering Contradiction:
Improveplatform agnostic data accessVSAvoidsystem architecture complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces an FMS data formatter as an intermediary component between external data sources and the flight management system. This formatter includes a rule-based engine that processes data according to configuration files, acting as a mediator that handles platform-specific variations without requiring changes to the core FMS architecture. The context processing engine further mediates by moderating I/O task flows based on the present state of the FMS, enabling standardized access while managing complexity through layered abstraction.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system uses configuration files that contain parseable rules defining data formats, field mappings, and processing parameters for different external sources. By changing parameters in these configuration files rather than modifying the system code, the platform agnostic capability is achieved. The rule-based engine dynamically adjusts its behavior based on these parameter changes, allowing the same system architecture to handle multiple platforms through parameter variation alone.

Inventive Principle:
Principle #35Parameter changes

2Reliability

If controlled data flow and access management are implemented, then data security and ownership are maintained, but data access ease is reduced

Engineering Contradiction:
Improvedata securityVSAvoiddata access ease
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The system performs preliminary actions by pre-defining access rules, data validation criteria, and security parameters in configuration files before actual data access occurs. The context processing engine pre-evaluates the present state of the FMS to determine appropriate access permissions and data flow paths. This preliminary setup enables automated security checks and access control without requiring manual intervention during data access operations, maintaining security while preserving ease of use.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The rule-based engine and context processing engine automatically manage data access control, validation, and security enforcement without requiring manual security management. The system self-regulates data flows by evaluating configured rules and current FMS state, automatically permitting or blocking access based on pre-established criteria. This self-service approach maintains high security standards while keeping the access process transparent and simple for users.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS12387611B2System and method for platform agonistic flight management data access
Publication Date: 2025.08.12 HONEYWELL INTERNATIONAL INC
  • US12387611B2 patent drawing
  • US12387611B2 patent drawing
  • US12387611B2 patent drawing

AI summary

Methods and systems for providing platform agnostic flight management data access for a flight management system (FMS) of an aircraft have been developed. First, a configuration file is loaded to a configuration database. The configuration file is for a data format of an external data source from the aircraft. Upon receiving a data access request from a user for external data from the external data source, downloading the configuration file is downloaded to an FMS data formatter. The configuration file is parsed with a data processor component of the FMS data formatter to update a rule set. The FMS data formatter receives an external data file from an application programing interface (API) of the external data source. The external data file is parsed with a rule engine of the FMS data formatter using the updated rule set. A flight plan file is generated with the FMS data formatter using the parsed external data file and sent to the FMS on the aircraft.