Avionics Software Service Orchestrator for Resource-Constrained Platforms

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current orchestrators are not suitable for managing software services on avionics platforms with limited resources, particularly in environments where hardware resources are constrained, such as on-board aircraft.

Innovation Solution

A method and electronic device for managing the execution of software services on avionics platforms, involving the acquisition of contextual data, computation of a context based on resource usage and breakdown resistance, and distribution of resources according to prioritization rules to ensure efficient execution with limited resources.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If current orchestrators are used to manage software services, then software services can be added on demand with updated resources, but the system becomes unsuitable for environments with limited hardware resources

Engineering Contradiction:
Improveability to add software services on demandVSAvoidsuitability for limited resource environments
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent changes the operational parameters of the orchestrator by introducing contextual data acquisition (resource availability, breakdown resistance requirements) and dynamic context computation. This transforms the orchestrator from a static resource allocation system to one that dynamically adapts its service execution decisions based on current resource constraints and service criticality levels, making it suitable for limited avionics environments while maintaining service addition capability

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

The patent introduces dynamic behavior through continuous contextual data acquisition and real-time context computation. The orchestrator dynamically adjusts which services to execute based on current resource availability and service requirements, rather than following fixed allocation rules. This dynamic adaptation enables reliable operation in resource-constrained avionics environments while preserving the flexibility to add services when resources permit

Inventive Principle:
Principle #15Dynamics

2Productivity

If more software services are executed on the platform, then functionality increases, but resource constraints prevent all services from being executed simultaneously

Engineering Contradiction:
Improvenumber of software services executedVSAvoidavailable hardware resources
Core Design Contradiction:
ProductivityVSQuantity of substance

Solution Approach 1:

The patent transforms the resource allocation approach by introducing contextual parameters including service breakdown resistance requirements and dynamic resource availability assessment. This enables the system to optimize the mix of executed services based on criticality rather than simply maximizing service count or uniformly distributing resources, achieving higher effective productivity within constrained resources

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

The patent applies different resource allocation strategies to different services based on their local characteristics, specifically their breakdown resistance requirements. Critical services with high breakdown resistance receive priority resource allocation and protection, while less critical services receive remaining resources. This localized quality approach ensures essential services maintain functionality even when total service count is limited by resource constraints

Inventive Principle:
Principle #3Local quality

3Loss of energy

If resources are allocated to services that do not require breakdown resistance, then resource utilization increases, but services requiring breakdown resistance may fail when resources are insufficient

Engineering Contradiction:
Improveresource utilization efficiencyVSAvoidbreakdown resistance of critical services
Core Design Contradiction:
Loss of energyVSReliability

Solution Approach 1:

The patent performs preliminary action by acquiring contextual data about service breakdown resistance requirements before making execution decisions. The system pre-identifies which services require protection against breakdown and incorporates this information into context computation, ensuring that resource allocation decisions are made with advance knowledge of service criticality, thereby preventing resource starvation of essential services

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent implements feedback mechanisms through continuous contextual data acquisition and dynamic context computation. The system monitors resource availability and service execution status, and uses this feedback to adjust resource allocation in real-time. This feedback loop ensures that critical services maintaining breakdown resistance are prioritized when resources become constrained, preventing their failure while still allowing efficient utilization of available resources for non-critical services

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS20250094216A1Method and electronic device for managing the execution of software application services on an avionics platform, related computer program and avionics system
Publication Date: 2025.03.20 THALES SA
  • US20250094216A1 patent drawing
  • US20250094216A1 patent drawing
  • US20250094216A1 patent drawing

AI summary

A method of managing the execution of software services on an avionics platform including resources for the execution of the services is implemented by an electronic device and includes acquisition of contextual data for a group of software services to be executed, the contextual data including, for each software service: a maximum number of resources used by the service, an operating requirement of the service equal to resistance to breakdown/s or non-resistance to breakdown/s, and, if the operating requirement of the service is equal to resistance to breakdown/s, a number of breakdown/s the service should withstand, computation, from the acquired contextual data, of a context for the group of software services, and launching of the execution of software service/s of the group according to a set of distribution rule/s of the services and depending upon the computed context.