Software Safety Compliance Scoring with Objective RPN Evaluation

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Conventional methods for evaluating the functional safety of vehicle software rely on subjective interpretations, leading to inconsistent and non-homogeneous assessments, and do not account for the impact of redundant software elements on compliance with safety standards.

Innovation Solution

An objective and reproducible evaluation system that uses measurable criteria to calculate a risk priority number (RPN) based on occurrence, severity, and detectability, removing subjectivity and considering redundancy in software elements.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If subjective interpretations are used to evaluate functional safety of software, then flexibility in assessment is improved, but consistency and reliability of evaluation deteriorate

Engineering Contradiction:

Improveflexibility in assessmentVSAvoidconsistency of evaluation

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The patent transforms the evaluation from subjective to objective by changing the parameters used: instead of using subjective expert judgment, it uses automatically extracted software metrics (code complexity, coupling, cohesion, test coverage) as quantitative parameters. This allows flexibility to assess different software while maintaining consistency through objective measurement.

Inventive Principle:

Principle #35Parameter changes

Solution Approach 2:

The patent replaces the mechanical system of human expert judgment with an automated computational system that objectively measures software characteristics. This substitution eliminates human subjectivity while maintaining the ability to evaluate diverse software implementations consistently.

Inventive Principle:

Principle #28Mechanics substitution (Replace mechanical system)

2Reliability

If conventional functional safety evaluation methods are used, then assessment of software safety is improved, but account for redundancy in software elements deteriorates

Engineering Contradiction:

Improvesoftware safety assessmentVSAvoidconsideration of software redundancy

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments the software into modular components and evaluates each module's redundancy independently through objective metrics. This allows the system to account for redundancy at the module level while maintaining overall assessment simplicity, resolving the contradiction between comprehensive safety evaluation and complexity management.

Inventive Principle:

Principle #1Segmentation

3Adaptability or versatility

If subjective criteria are applied during functional safety evaluation, then customization of evaluation approach is improved, but homogeneity of evaluation results deteriorates

Engineering Contradiction:

Improvecustomization of evaluation approachVSAvoidhomogeneity of evaluation results

Core Design Contradiction:

Adaptability or versatilityVSManufacturing precision

Solution Approach 1:

The patent creates a universal evaluation framework that uses the same objective metrics and statistical methods for all software evaluations. This single system can evaluate different software types and safety standards (ISO 26262, IEC 61508) consistently, achieving both customization for different contexts and homogeneity in results through standardized measurement approaches.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentUS12536016B2Evaluation of software programs for compliance with functional safety

Publication Date: 2026.01.27 INTEL CORP

AI summary

Disclosed herein is a device, system, and/or method for evaluating functional safety compliance for a software program against a plurality of requirements. The device includes a processor that determines a plurality of implementation values for developing the software program. Each implementation value of the plurality of implementation values is associated with a corresponding requirement of the plurality of requirements, and each implementation value is determined based on a level of compliance of the software program to the corresponding requirement. The device also determines a risk priority number for the software program based on an aggregation of the plurality of implementation values. The risk priority number may also be based on a severity value and/or a detectability value. The device also determines a safety score for the software program based on whether the risk priority number satisfies a predefined threshold.