In-Field Software Update Method for Electronic Systems

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing methods for updating critical software on electronic hardware, such as gas turbine engine components, are cumbersome and often require hardware to be returned to the manufacturer, and risk non-recoverable system failures due to power failures during updates, especially in field deployments.

Innovation Solution

A method involving a processor switchable between maintenance and application modes, using non-volatile memory sectors with a key sector to prioritize initialization from cloned boot and test link software, allowing updates to be performed in the field without hardware removal, and providing a temporary key for protection against power failures.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If existing methods for updating critical software are used, then software updates can be performed, but hardware must be returned to the manufacturer and special tools are required, increasing downtime and cost

Engineering Contradiction:
Improvesoftware update capabilityVSAvoiddowntime
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs software updates autonomously using its own existing boot and management software, without requiring external specialized tools or manufacturer facilities. The electronics hardware updates its critical software in-place, allowing field updates without hardware removal or return to manufacturer, thereby eliminating downtime and reducing costs

Inventive Principle:
Principle #25Self-service

2Ease of manufacture

If volatile memory is used for software updates, then updates can be performed, but power failure during updating causes non-recoverable system failure

Engineering Contradiction:
Improveupdate process simplicityVSAvoidsystem recovery capability
Core Design Contradiction:
Ease of manufactureVSReliability

Solution Approach 1:

The system prepares a complete, validated software image in advance and stores it in non-volatile memory before any update operation begins. This pre-prepared image serves as a safety cushion that ensures the system can recover from power failures during the update process, as the complete software image is already safely stored and can be restored if needed

Inventive Principle:
Principle #11Beforehand cushioning (Prior cushioning)

3Adaptability or versatility

If boot and management software is updated, then software functionality is improved, but the software that governs updating procedures cannot effectively update itself

Engineering Contradiction:
Improvesoftware functionalityVSAvoidself-update capability
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The system performs preliminary actions by preparing and validating the complete software image in advance, storing it in non-volatile memory before the update process begins. This preliminary preparation ensures that when the update executes, the governing software is already ready and validated, allowing the system to successfully update its own boot and management software without external intervention

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentEP2500821B1Method for downloading software to an electronics product
Publication Date: 2017.06.21 HAMILTON SUNDSTRAND CORP
  • EP2500821B1 patent drawingFigure 1
  • EP2500821B1 patent drawingFigure 2A~2D

AI summary

A method for updating software on an electronics system that includes a processor switchable between modes and non-volatile memory includes over-writing original application software stored in an application sector of the memory to store cloned boot software such that original boot software remains in the memory, switching the system to a mode that accesses the cloned boot software, storing a temporary key in a key sector of the non-volatile memory that overrides an original key and is configured to instruct the processor to boot the cloned boot software upon initialization, over-writing the original boot software in the boot sector to store new boot software after storing the temporary key, storing a new key in the memory that is configured to instruct the processor to boot the new boot software upon initialization, erasing the temporary key, and switching the system to a mode that accesses the new boot software.