4.1: ISO 26262 Integration

Introduction

ISO 26262 "Road vehicles - Functional safety" is the automotive industry's functional safety standard. This section details how to integrate ISO 26262 requirements (especially Part 6: Software) with ASPICE processes.

ISO 26262 Overview

Standard Structure

ASIL (Automotive Safety Integrity Level)

ASIL Determination

ASIL is derived from Hazard Analysis and Risk Assessment (HARA) based on:

• Severity (S): S0 (no injury) → S3 (life-threatening)
• Exposure (E): E0 (incredible) → E4 (high probability)
• Controllability (C): C0 (controllable) → C3 (difficult to control)

ASIL Classification:

ASIL-D: Highest integrity (e.g., brake-by-wire unintended activation, ABS loss at high speed)
ASIL-C: High integrity (e.g., electric power steering loss at high speed)
ASIL-B: Medium integrity (e.g., unintended airbag deployment, adaptive cruise control failure)
ASIL-A: Low integrity (e.g., rear exterior lighting failure, windscreen washer failure)
QM (Quality Management): No safety relevance (e.g., radio, infotainment)

Note: ASIL assignment is always derived from HARA (Hazard Analysis and Risk Assessment) per ISO 26262-3. The examples above are indicative; the actual ASIL depends on the specific failure mode, exposure scenario, and controllability assessment for a given vehicle.

ASPICE Implication: ASIL level dictates rigor of ASPICE process execution.

ISO 26262-6 Software Development Process

Clause 6: Software Safety Requirements Specification

ISO 26262-6:6 Requirements:

• Derive software safety requirements from technical safety requirements (TSRs)
• Specify software safety requirements completely and unambiguously
• Verify software safety requirements

ASPICE SWE.1 Integration:

Example Software Safety Requirement:

#### SWE-SAFE-042: Emergency Brake Activation Timeout

**Description**:
The software shall activate emergency braking within 50ms of hazard detection.

**Rationale**:
Derived from [TSR-089] Emergency Braking Response Time to prevent collision.

**ASIL**: ASIL-D

**Safety Mechanism Type**: Time monitoring with independent watchdog

**Verification Method**:
- Unit test with timing instrumentation
- HIL test with real-time measurement
- Independent safety assessment

**Acceptance Criteria**:
- 100% of test cases: Activation time ≤ 50ms
- Worst-case execution time (WCET) analysis shows 45ms maximum

**Safety Rationale**:
50ms threshold derived from stopping distance calculations at 100 km/h.
5ms margin accounts for measurement uncertainty.

Clause 7: Software Architectural Design

ISO 26262-6:7 Requirements:

• Design software architecture to implement safety requirements
• Ensure freedom from interference between software components
• Perform ASIL decomposition if applicable

ASPICE SWE.2 Integration:

Freedom From Interference (FFI) Analysis Template:

# Freedom From Interference Analysis
## Project: Door Lock Controller (ASIL-B)

### 1. Interference Mechanisms

| Mechanism | Risk | Mitigation |
|-----------|------|------------|
| **Memory Corruption** | ASIL-B component overwrites QM data | Memory Protection Unit (MPU) configured for spatial isolation |
| **Timing Interference** | QM task delays ASIL-B task | AUTOSAR OS priority assignment (ASIL-B = highest priority) |
| **Resource Contention** | Both components access EEPROM | Mutex protection with priority inheritance |

### 2. ASIL Decomposition

| Component | Original ASIL | Decomposed ASIL | Independence Mechanism |
|-----------|---------------|-----------------|------------------------|
| Speed Monitor | ASIL-B | ASIL-A(D) + ASIL-A(D) | Redundant speed calculation (ASIL-A) + plausibility check (ASIL-A); combined via independence to achieve ASIL-B |
| Unlock Logic | ASIL-B | ASIL-B (not decomposed) | Single critical path, full ASIL-B rigor applied |

> Note: ASIL decomposition notation per ISO 26262-9: "ASIL-X(D)" means "ASIL-X, decomposed." A valid ASIL-B decomposition yields two sub-elements with combined requirements of ASIL-A+ASIL-A or ASIL-A+ASIL-B (one can retain the full original level). The sub-elements must be implemented with sufficient independence.

### 3. Verification

- Memory partitioning verified via MPU configuration review
- Timing isolation verified via worst-case execution time (WCET) analysis
- Resource contention verified via mutex coverage testing

Clause 8: Software Unit Design and Implementation

ISO 26262-6:8 Requirements:

• Implement software units according to architectural design
• Use coding guidelines (e.g., MISRA C)
• Apply defensive programming techniques

ASPICE SWE.3 Integration:

MISRA C Compliance by ASIL:

MISRA C:2012 defines three rule categories: Mandatory (always required), Required (required unless formally deviated), and Advisory (recommended). MISRA compliance is independent of ASIL — the MISRA standard itself does not define ASIL-specific percentages. ISO 26262-6 Table 11 recommends use of coding guidelines (including restricted subsets such as MISRA C) with the stringency increasing with ASIL. The following represents typical industry practice:

Note: MISRA C:2012 mandatory rules have no exceptions — they apply universally regardless of ASIL. For required and advisory rules, formal deviations with documented rationale are permitted. ISO 26262-6 Table 11 specifies coding guidelines as "Recommended (R)" for ASIL-A/B and "Highly Recommended (HR)" for ASIL-C/D.

Defensive Programming Example (ASIL-B):

/**
 * @brief Calculate throttle position with range checking
 * @param rawADC: ADC reading from throttle sensor (0-4095)
 * @return Throttle percentage (0-100), or error code (-1)
 * @safety ASIL-B: Input validation mandatory
 */
int16_t calculateThrottlePosition(uint16_t rawADC) {
    // ISO 26262-6 Table 12: Input parameter plausibility check
    if (rawADC > ADC_MAX_VALUE) {
        // Defensive programming: Detect out-of-range input
        (void)Dem_SetEventStatus(DEM_EVENT_THROTTLE_RANGE_ERROR, DEM_EVENT_STATUS_FAILED);
        return -1;  // Error indication
    }

    // Sensor calibration: 0-4095 ADC → 0-100% throttle
    int16_t throttlePercent = (int16_t)((rawADC * 100U) / ADC_MAX_VALUE);

    // ISO 26262-6 Table 12: Post-condition check
    if (throttlePercent < 0 || throttlePercent > 100) {
        // This should never happen, but defensive programming catches arithmetic errors
        (void)Dem_SetEventStatus(DEM_EVENT_THROTTLE_CALC_ERROR, DEM_EVENT_STATUS_FAILED);
        return -1;
    }

    return throttlePercent;
}

Clause 9: Software Unit Verification

ISO 26262-6:9 Requirements:

• Verify software units achieve required behavior
• Achieve structural coverage appropriate to ASIL level
• Review code for compliance with coding guidelines

ASPICE SWE.4 Integration:

Coverage Requirements by ASIL:

MC/DC Coverage Example (ASIL-C/D):

// Function to test
bool isEmergencyBrakeRequired(bool hazardDetected, bool driverAlert, uint8_t speed) {
    // Condition to cover: (hazardDetected AND NOT driverAlert) OR (speed > 150)
    return (hazardDetected && !driverAlert) || (speed > 150);
}

// MC/DC Test Cases (Modified Condition/Decision Coverage)
TEST_CASE_1: hazardDetected=T, driverAlert=T, speed=100 → Result=F (baseline)
TEST_CASE_2: hazardDetected=F, driverAlert=T, speed=100 → Result=F (toggle hazardDetected)
TEST_CASE_3: hazardDetected=T, driverAlert=F, speed=100 → Result=T (toggle driverAlert)
TEST_CASE_4: hazardDetected=T, driverAlert=T, speed=160 → Result=T (toggle speed)

// Coverage Report (VectorCAST):
// MC/DC Coverage: 100% (all conditions independently affect decision)

Clause 10: Software Integration and Testing

ISO 26262-6:10 Requirements:

• Integrate software components incrementally
• Test interfaces between components
• Verify integrated software against software architectural design

ASPICE SWE.5 Integration:

Integration Test Example (ASIL-B):

### TC-INT-SAFE-005: Emergency Brake Activation via CAN Command

**Objective**: Verify ASIL-B emergency brake function responds correctly to CAN message.

**Test Setup**:
- Brake ECU (ASIL-B software flashed)
- CAN network simulator
- Brake actuator (real hardware or HIL simulator)

**Preconditions**:
- Vehicle speed: 80 km/h
- Brake system initialized and self-tests passed

**Test Steps**:
1. Inject CAN message: `EmergencyBrakeCmd` (ID: 0x400, Data: [0x01])
2. Measure time to brake actuator activation (GPIO monitoring)
3. Verify CAN status message broadcast: `BrakeStatus` (BrakeActive = True)

**Expected Results**:
- Brake activation time: ≤ 50ms (derived from SWE-SAFE-042; this requirement is ASIL-D)
- Status message sent within 10ms of activation
- No diagnostic trouble codes (DTCs) set

**Actual Results**: [To be filled during test execution]

**Pass/Fail**: [PASS / FAIL]

**Safety Relevance**: This test verifies SWE-SAFE-042 (ASIL-D). Note: If the overall brake ECU architecture decomposes ASIL-D into ASIL-B(D) + ASIL-B(D) channels, this test covers the ASIL-D end-to-end requirement at the integrated system level.

**Traceability**: Verifies [SWE-SAFE-042] Emergency Brake Activation Timeout

Clause 11: Verification of Software Safety Requirements

ISO 26262-6:11 Requirements:

• Ensure software qualification testing is complete
• Demonstrate software complies with safety requirements

ASPICE SWE.6 Integration:

Safety Qualification Test Report Template:

# Software Qualification Test Report
## ASIL-B Door Lock Controller - Release v2.1.0

### 1. Test Summary

| Metric | Target | Actual | Status |
|--------|--------|--------|--------|
| Total Test Cases | 45 | 45 | [PASS] |
| Passed | 45 | 44 | [WARN] |
| Failed | 0 | 1 | [FAIL] |
| Coverage of SWRS | 100% | 98% | [WARN] |

### 2. Failed Test Cases

| Test ID | Requirement | Failure Description | Severity | Status |
|---------|-------------|---------------------|----------|--------|
| TC-QUAL-032 | SWE-SAFE-042 | Brake activation 52ms (exceeds 50ms limit) | Critical | Open (BUG-089) |

### 3. Safety Assessment

**ASIL-B Compliance Status**: [FAIL] NOT ACHIEVED (1 critical failure)

**Blocking Issues**:
- BUG-089: Emergency brake timeout violation (ASIL-D requirement)
  - Root Cause: Interrupt priority misconfiguration
  - Fix: Increase brake task priority to highest
  - Re-test: Scheduled 2025-12-20

**Recommendation**: DO NOT RELEASE until BUG-089 resolved and TC-QUAL-032 passes.

### 4. Traceability Verification

All 43 software safety requirements (SWE-SAFE-001 to SWE-SAFE-043) traced to test cases.

**Traceability Gaps**:
- SWE-SAFE-019: No direct test case (covered indirectly by TC-QUAL-012)
- SWE-SAFE-027: No direct test case (added TC-QUAL-046 to retest plan)

### 5. Approval

| Role | Name | Date | Signature | Decision |
|------|------|------|-----------|----------|
| Test Manager | [NAME] | [DATE] | [SIGNATURE] | Conditional (pending BUG-089 fix) |
| Safety Manager | [NAME] | [DATE] | [SIGNATURE] | REJECT (critical failure blocks release) |
| Quality Manager | [NAME] | [DATE] | [SIGNATURE] | Conditional (pending re-test) |

Tool Confidence Level (TCL) for ISO 26262

TCL Classification (ISO 26262-8 Clause 11)

Tool Impact (TI) Criteria:

Tool Error Detection (TD) Criteria:

TCL Matrix (ISO 26262-8 Table 4):

        │  TD1  │  TD2  │  TD3  │
────────┼───────┼───────┼───────┤
TI1     │ TCL1  │ TCL1  │ TCL1  │ No qualification needed
TI2     │ TCL1  │ TCL2  │ TCL3  │ Qualification for TCL2/TCL3
TI3     │ TCL2  │ TCL3  │ TCL3  │ Qualification required

Example: GCC Compiler for ASIL-D

Recommended Approach for ASIL-B:

• Use qualified compiler (e.g., IAR EWARM Functional Safety Edition)
• OR: Use GCC with extensive test suite (demonstrate TD1 confidence)

Summary

ISO 26262 Integration with ASPICE:

• ASIL-Driven Rigor: ASIL level determines ASPICE process intensity
• Software Safety Requirements (Clause 6): SWE.1 + ASIL annotations
• Software Architecture (Clause 7): SWE.2 + FFI analysis + ASIL decomposition
• Software Design (Clause 8): SWE.3 + MISRA C compliance
• Unit Verification (Clause 9): SWE.4 + MC/DC coverage for ASIL-C/D
• Integration Testing (Clause 10): SWE.5 + interface testing
• Qualification Testing (Clause 11): SWE.6 + safety validation
• Tool Qualification: TCL-based approach for safety toolchains

Key Takeaway: ASPICE provides the process framework; ISO 26262 specifies the safety-specific rigor and work products.