Field-Loadable I/O Tables for Avionics Hardware Units

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current avionics software certification processes are resource-intensive and time-consuming due to the need for re-certification whenever input/output (I/O) information changes, as even minor alterations require significant computing resources and effort to conform to mandated standards.

Innovation Solution

Implementing field-loadable I/O tables that segregate I/O information from the operational software, allowing changes to I/O tables without affecting the core software, thereby avoiding re-certification by loading selected I/O tables that conform to a predefined schema, enabling flexible configuration of rules for data processing and routing.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If I/O information is integrated into the operational software, then the software can process data correctly according to specific aircraft configurations, but any change in I/O information requires re-certification of the entire software

Engineering Contradiction:
ImproveI/O configuration flexibilityVSAvoidre-certification time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent segments the software system into two independent parts: certified operational software and loadable I/O tables. The I/O tables are separated from the core software and stored as independent configurable data structures. This segmentation allows the I/O information to be modified without affecting the certified software, thereby eliminating re-certification requirements while maintaining adaptability to different aircraft configurations.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent extracts the I/O information from the operational software and places it into separate loadable tables. These tables contain I/O descriptors, data structures, and processing rules that can be independently configured and loaded at runtime. By taking out the I/O configuration data, the system enables flexible adaptation without compromising the integrity or certification status of the core operational software.

Inventive Principle:
Principle #2Taking out (Extraction)

2Reliability

If I/O information is integrated into the operational software, then the software maintains data integrity and safety standards, but changes in I/O information consume significant computing resources for re-certification

Engineering Contradiction:
Improvedata integrityVSAvoidcomputing resources for re-certification
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The patent divides the system into a certified operational software component and a configurable I/O tables component. The I/O tables are structured with predefined schemas that ensure data integrity without requiring re-certification of the core software. This segmentation maintains reliability through schema validation while avoiding the energy-intensive re-certification process.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent enables parameter changes in the I/O configuration by allowing dynamic loading of different I/O tables with varying parameters such as data structures, processing rules, and I/O descriptors. These parameter changes are achieved through configuration modifications rather than software changes, thereby maintaining data integrity through schema constraints while eliminating the need for resource-intensive re-certification.

Inventive Principle:
Principle #35Parameter changes

3Adaptability or versatility

If the operational software is modified to accommodate different I/O configurations, then the software can support various aircraft models and operators, but the core software requires re-certification

Engineering Contradiction:
Improveaircraft model compatibilityVSAvoidsoftware complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the software architecture into a fixed certified operational software layer and a flexible configurable I/O tables layer. The I/O tables contain aircraft-specific parameters, data structures, and processing rules that can be customized for different aircraft models and operators. This segmentation allows the system to support multiple aircraft configurations without modifying or re-certifying the core operational software, thereby reducing software complexity while maintaining high adaptability.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent creates a universal operational software platform that can handle multiple aircraft configurations through a standardized interface with loadable I/O tables. The I/O tables serve as a universal configuration mechanism that adapts the software to different aircraft models, operators, and registration numbers without requiring separate software versions or re-certification. This multi-functionality approach simplifies the core software while enabling broad compatibility.

Inventive Principle:
Principle #6Universality (Multi-functionality)

4Ease of operation

If I/O tables are made field-loadable, then changes can be made without re-certification, but validation and schema conformity must be ensured

Engineering Contradiction:
ImproveI/O table modification easeVSAvoidschema conformity validation
Core Design Contradiction:
Ease of operationVSManufacturing precision

Solution Approach 1:

The patent implements preliminary validation mechanisms where I/O tables are defined with predefined schemas that specify required data structures, processing rules, and format constraints. Before the I/O tables are loaded into the operational software, they undergo automatic validation against these schemas to ensure conformity. This preliminary action ensures manufacturing precision and data integrity while maintaining ease of operation, as operators can modify I/O tables without needing to understand the complex validation rules.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent incorporates feedback mechanisms through automatic schema validation that provides immediate information about whether a loaded I/O table conforms to the required specifications. The system validates the I/O tables against predefined schemas and provides feedback on any conformities or errors, allowing operators to correct issues without manual review. This feedback loop ensures manufacturing precision while maintaining ease of operation by automating the validation process.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS10949536B1Field-loadable input/output tables for avionics hardware units
Publication Date: 2021.03.16 ROCKWELL COLLINS INC
  • US10949536B1 patent drawing
  • US10949536B1 patent drawing
  • US10949536B1 patent drawing

AI summary

Embodiments of the inventive concepts disclosed herein are directed to systems and methods for using field-loadable input/output (I/O) tables. An avionics hardware unit may include one or more processors. An operational software of the avionics hardware unit may perform a plurality of operations for processing avionics data in safety or data-integrity driven applications. An I/O table may be loaded onto the avionics hardware. The I/O table may be selected from a plurality of I/O tables loadable onto the avionics hardware for operation with the operational software. The selected I/O table may include a configuration of rules. The rules may be assigned according to the configuration to each of the plurality of operations to configure the behavior of the respective operations for processing the avionics data. The configuration may be different from that of others of the plurality of I/O tables in configuring the plurality of operations of the operational software.