Lightweight Software Test Library for Vehicle Hardware Coverage

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Autonomous vehicles face challenges in efficiently performing hardware coverage testing due to the impracticality and expense of full hardware resource consumption, especially when executing software tests that require significant resources, which is not feasible in real-world driving scenarios.

Innovation Solution

A lightweight software test library (STL) is generated specifically for vehicle compute software, reducing the number of instructions and resources needed for hardware coverage testing, allowing for time-sliced execution with the vehicle compute software, and designed to test only the resources used by the vehicle compute software, adhering to functional safety standards like ISO 26262.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If full hardware resource consumption is used for testing, then testing coverage is improved, but resource usage and cost increase

Engineering Contradiction:

Improvetesting coverageVSAvoidresource consumption

Core Design Contradiction:

ReliabilityVSUse of energy by moving object

Solution Approach 1:

The patent applies partial action by executing only a subset of hardware coverage tests during real-world driving operations. The system selectively runs tests based on current operational context, power availability, and priority levels, rather than executing all possible hardware tests continuously. This allows adequate testing coverage while conserving computational resources during actual vehicle operation.

Inventive Principle:

Principle #16Partial or excessive action

Solution Approach 2:

The patent segments hardware coverage testing into multiple categories and priorities. Tests are divided into critical safety-related tests that run during operation and less critical tests that run during idle periods or offline. This segmentation enables the system to maintain essential testing coverage while reducing overall resource consumption by not running all tests simultaneously or continuously.

Inventive Principle:

Principle #1Segmentation

2Reliability

If hardware coverage testing is executed during real-world driving, then safety monitoring is improved, but computational resources are consumed

Engineering Contradiction:

Improvesafety monitoringVSAvoidcomputational efficiency

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

The patent implements periodic action by scheduling hardware coverage tests at specific intervals and under specific conditions during real-world driving. Rather than continuous testing, the system periodically executes tests based on operational milestones, power state changes, or predefined time intervals. This periodic approach maintains safety monitoring while allowing computational resources to be used for primary vehicle functions between test executions.

Inventive Principle:

Principle #19Periodic action

Solution Approach 2:

The patent applies dynamics by making the testing strategy adaptive to real-time vehicle conditions. The system dynamically adjusts which tests run, when they run, and with what priority based on current operational context, power availability, and vehicle state. This dynamic approach optimizes the balance between safety monitoring and computational efficiency by allocating resources based on actual needs rather than fixed schedules.

Inventive Principle:

Principle #15Dynamics

3Measurement precision

If comprehensive hardware testing is performed, then fault detection capability is improved, but time consumption increases

Engineering Contradiction:

Improvefault detection capabilityVSAvoidtesting time

Core Design Contradiction:

Measurement precisionVSLoss of time

Solution Approach 1:

The patent applies partial action by performing only the most critical and high-value hardware tests during real-world driving operations. The system identifies and prioritizes tests that provide the greatest fault detection capability for safety-critical hardware, while deferring or omitting less critical tests. This selective approach maintains effective fault detection for essential components while reducing overall testing time during operation.

Inventive Principle:

Principle #16Partial or excessive action

Data Source

PatentUS12124356B2Lightweight software test library for vehicle compute hardware coverage testing

Publication Date: 2024.10.22 GM CRUISE HOLDINGS LLC

AI summary

Systems and methods for vehicle hardware coverage testing are provided. For instance, a vehicle includes a memory to store a vehicle compute software and a hardware coverage test software associated with the vehicle compute software. The vehicle includes a timer configured based on a timer period and one or more processing units to execute the vehicle compute software using hardware resources of the one or more processing units. Responsive to an expiration of the timer, the one or more processing units execute the hardware coverage test software to test only the hardware resources used by the vehicle compute software and determine whether there is a failure associated with the hardware resources used by the vehicle compute software.