Configurable Avionic UI Architecture Using Protocol-Agnostic Layers
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional user interface designs for safety-critical applications, such as avionics systems, face high costs and inefficiencies due to the need for frequent changes and lack of predictive strategies, which are not well-suited for real-time embedded systems, and current application development kits do not provide adequate documentation for certification.
Innovation Solution
A user interface architecture with a protocol-agnostic layer that connects user interface behaviors to protocol-specific messages using configuration tables, allowing for rapid adaptation and reusability without modifying existing entry or display behaviors, and ensuring independent verification and certification of components.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If traditional user interface designs are used for safety-critical applications, then each new product requires starting the design process over, but this leads to high cost of change and extended development time
Solution Approach 1:
The user interface is segmented into reusable components organized in a component library. Each component is independently designed, documented, and can be selectively assembled for different products. This segmentation allows the design process to be reused across products without starting over, reducing development time while maintaining adaptability.
Solution Approach 2:
A universal component library is created that contains user interface components designed to work across multiple safety-critical applications. These universal components can be configured and adapted for different products through documentation and assembly, eliminating the need to redesign from scratch for each new product.
2Adaptability or versatility
If application development kits use run-time dynamically allocated memory paradigms to configure user interfaces, then interface configuration flexibility is improved, but this approach does not work with safety critical real-time embedded applications
Solution Approach 1:
User interface configurations are predetermined and documented before runtime. Configuration data is prepared in advance as static information that can be verified for safety, eliminating the need for runtime memory allocation while maintaining configuration flexibility through pre-validated design choices.
Solution Approach 2:
The dynamic runtime configuration mechanism is replaced with a static documentation-based configuration system. Instead of using runtime memory allocation and dynamic binding, the system uses pre-documented configuration specifications that are verified during development, ensuring safety while maintaining configurability.
3Ease of manufacture
If traditional user interface designs are used, then implementation is straightforward, but certification effort for safety critical airborne software becomes expensive
Solution Approach 1:
The user interface implementation is segmented into standardized, reusable components with complete documentation. Each component can be independently verified and certified, reducing overall certification effort through component reuse. The segmentation allows verification at component level rather than requiring full system recertification for each product.
Solution Approach 2:
The approach changes from dynamic runtime configuration to static predetermined configuration parameters. This parameter change enables complete documentation of interface behavior, which is essential for safety certification. The static nature of the parameters allows for exhaustive verification and reduces certification complexity.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A configurable user interface architecture (10) to be used in high integrity safety critical avionic systems and is adaptable to multiple cockpit displays has a protocol-agnostic layer (22) that handles entry and display update behaviors (16, 20), and a protocol-specific layer (18) that connects the entry and display behaviors to protocol-specific input/output messages using configuration tables (14). The configuration tables (14) are built using a specially designed configuration tool and the configuration table built by the tool can be embedded in the target user interface software or loaded externally into a pre-compiled application.