Blockchain Validator Nodes for OTA Update Incompatibility

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The increasing complexity of vehicles with multiple electronic control units (ECUs) poses challenges in software and firmware updates due to inconsistencies and incompatibilities, as well as potential malware injection during over-the-air (OTA) downloads, which can compromise safety and security.

Innovation Solution

Implementing blockchain technology to validate and manage OTA updates by identifying adverse conditions between candidate update code and existing code across networked ECUs, preventing incompatible updates and ensuring consensus among validator nodes before installation, and recording update information in a blockchain for transparency and security.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If OTA updates are used to improve software and firmware across multiple ECUs, then system functionality and performance are enhanced, but incompatibilities and inconsistencies between updates arise

Engineering Contradiction:
Improvesystem functionalityVSAvoidupdate compatibility
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The system performs preliminary validation of update compatibility before applying OTA updates. Validator nodes check candidate updates against a database of known incompatibilities and verify consistency across all impacted ECUs before approval, preventing incompatible updates from being deployed.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

Validator nodes act as intermediary components between the OTA update delivery system and the ECUs. These intermediary nodes perform validation, consistency checking, and coordination to ensure that updates are compatible across the entire vehicle network before being applied to target ECUs.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If validation checks are performed for all impacted nodes, then update compatibility is ensured, but validation time and processing complexity increase

Engineering Contradiction:
Improveupdate compatibilityVSAvoidvalidation time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

Incompatibility information is pre-collected and stored in a database before updates are needed. The validation process queries this pre-prepared database rather than performing comprehensive analysis in real-time, significantly reducing validation time while maintaining thoroughness.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system creates a virtual copy of the validation process by querying pre-computed compatibility data from a database. This allows rapid validation without repeating the full analysis process, enabling quick decisions while maintaining accuracy.

Inventive Principle:
Principle #26Copying

3Reliability

If decentralized validation is implemented, then security and transparency are improved, but system complexity increases

Engineering Contradiction:
ImprovesecurityVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The validation system is segmented into multiple independent validator nodes distributed across the vehicle network. Each node performs identical validation functions independently, providing decentralized validation that enhances security and transparency while distributing computational complexity across multiple simple units rather than requiring a single complex centralized system.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS11204751B2Mitigating incompatibilities due to code updates in a system containing multiple networked electronic control units
Publication Date: 2021.12.21 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • US11204751B2 patent drawing
  • US11204751B2 patent drawing
  • US11204751B2 patent drawing

AI summary

An example operation may include one or more of receiving, by a validator node, candidate update code for installation on one of multiple networked ECUs of a vehicle as a target node, identifying one or more other ECUs on the network that communicate with the target node as impacted nodes, checking for known adverse conditions between the candidate update code and existing code of the impacted nodes, in the case an adverse condition is identified, preventing the update code from being installed on the target node, in the case no adverse condition is identified, and no adverse condition is identified by any peer validator node, allowing the update code to be installed on the target node, forming, by the validator node, a block containing information of the candidate update code and its installation disposition, and appending the block to a blockchain utilized by at least one of the peer validator nodes.