---
title: "Automotive Requirements Traceability"
description: "Complete guide to automotive traceability for ISO 26262, ASPICE, and safety-critical development."
---

## Overview

Automotive software development demands rigorous traceability to meet functional safety standards, process quality requirements, and regulatory compliance. TracerTM provides comprehensive traceability management aligned with ISO 26262, Automotive SPICE (ASPICE), and industry best practices for safety-critical systems.

### Why Traceability Matters in Automotive

In automotive development, traceability is not optional—it is a fundamental requirement for:

- **Safety Compliance**: ISO 26262 mandates bidirectional traceability across all safety lifecycle phases
- **Process Quality**: ASPICE requires demonstrable traceability for process capability levels
- **Risk Management**: Linking hazards to safety requirements to verification ensures complete safety coverage
- **Change Impact**: Understanding ripple effects of design changes on safety requirements and tests
- **Audit Evidence**: Providing objective proof of compliance to assessors and regulators
- **Product Liability**: Demonstrating due diligence in safety-critical development

### Automotive Traceability Challenges

Automotive projects face unique traceability challenges:

- **Complex Supply Chains**: Managing requirements across OEMs, Tier 1, Tier 2, and Tier 3 suppliers
- **Multi-Domain Systems**: Electrical, mechanical, software, and hardware components must trace together
- **Long Product Lifecycles**: Maintaining traceability over 10+ year product lifecycles
- **Variant Management**: Tracking requirements across multiple vehicle platforms and configurations
- **Tool Ecosystem**: Integrating traceability across CANoe, DOORS, PTC, Polarion, and other tools
- **Distributed Teams**: Coordinating traceability across global development sites

---

## ISO 26262 Functional Safety Compliance

ISO 26262 is the international standard for functional safety of electrical and electronic systems in road vehicles. TracerTM supports complete traceability across all ISO 26262 work products.

### ISO 26262 V-Model Traceability

The ISO 26262 V-model requires traceability at every level:

```
System Level                          Integration & Test Level
┌────────────────────┐               ┌────────────────────┐
│ Safety Goals       │◄─────────────►│ Vehicle Tests      │
└────────────────────┘               └────────────────────┘
         │                                      ▲
         ▼                                      │
┌────────────────────┐               ┌────────────────────┐
│ Functional Safety  │◄─────────────►│ System Tests       │
│ Requirements (FSR) │               │                    │
└────────────────────┘               └────────────────────┘
         │                                      ▲
         ▼                                      │
┌────────────────────┐               ┌────────────────────┐
│ Technical Safety   │◄─────────────►│ Integration Tests  │
│ Requirements (TSR) │               │                    │
└────────────────────┘               └────────────────────┘
         │                                      ▲
         ▼                                      │
┌────────────────────┐               ┌────────────────────┐
│ Software Safety    │◄─────────────►│ Software Unit      │
│ Requirements (SSR) │               │ Tests              │
└────────────────────┘               └────────────────────┘
```

### Traceability Structure for ISO 26262

**1. Hazard Analysis and Risk Assessment (HARA) Traceability**

Link hazardous events to safety goals and ASIL classifications:

```markdown
# Hazard: Unintended Acceleration
- Type: Hazard
- ASIL: D
- Severity: S3
- Exposure: E4
- Controllability: C3
- Linked Safety Goals:
  - SG-001: Prevent unintended acceleration
  - SG-002: Enable emergency braking override
```

**2. Safety Goals to FSR Traceability**

Decompose safety goals into functional safety requirements:

```markdown
# Safety Goal: SG-001 Prevent Unintended Acceleration
- ASIL: D
- Derived FSRs:
  - FSR-001: Throttle position shall be validated against pedal sensor (ASIL D)
  - FSR-002: Brake pedal override shall disable throttle control (ASIL D)
  - FSR-003: Redundant throttle position monitoring (ASIL D)
```

**3. FSR to TSR Allocation**

Allocate functional requirements to technical components:

```markdown
# FSR-001: Throttle Position Validation
- Allocated TSRs:
  - TSR-001: ECU shall read throttle sensor at 10Hz minimum
  - TSR-002: Plausibility check algorithm specification
  - TSR-003: Fault detection and handling specification
```

**4. TSR to Software Safety Requirements (SSR)**

Refine technical requirements into software requirements:

```markdown
# TSR-001: Throttle Sensor Reading
- Software Component: ThrottleController
- Derived SSRs:
  - SSR-001: ThrottleSensor.read() shall complete within 5ms
  - SSR-002: CRC validation on sensor data
  - SSR-003: Timeout detection for sensor communication
```

**5. SSR to Design and Implementation**

Link requirements to actual code modules:

```markdown
# SSR-001: ThrottleSensor Read Timing
- Design Document: DD-TC-001
- Source Files:
  - throttle_sensor.c (lines 45-120)
  - sensor_validation.c (lines 200-250)
- Unit Tests:
  - test_throttle_sensor_timing.c
  - test_throttle_sensor_crc.c
```

### ISO 26262 Work Product Mapping

Map TracerTM item types to ISO 26262 work products:

| ISO 26262 Work Product | TracerTM Item Type | Link Type |
|------------------------|-------------------|-----------|
| Hazardous Event | `hazard` | `derives-from` |
| Safety Goal | `safety-goal` | `mitigates` |
| Functional Safety Requirement | `fsr` | `refines` |
| Technical Safety Requirement | `tsr` | `allocates-to` |
| Software Safety Requirement | `ssr` | `implements` |
| Safety Mechanism | `safety-mechanism` | `protects` |
| FMEA/FMEDA | `failure-mode` | `analyzes` |
| Dependent Failure Analysis | `dfa-item` | `correlates` |
| Safety Validation | `safety-test` | `verifies` |

### ASIL Inheritance and Decomposition

Track ASIL levels and decomposition arguments:

```markdown
# FSR-001: Throttle Position Validation
- Original ASIL: D
- Decomposition Strategy: Redundant channels
- Decomposed Requirements:
  - FSR-001A: Primary throttle validation (ASIL B(D))
  - FSR-001B: Independent throttle validation (ASIL B(D))
  - Decomposition Rationale: Independent implementation and testing
```

---

## ASPICE Process Requirements

Automotive SPICE (ASPICE) defines process capability levels that require demonstrated traceability. TracerTM supports ASPICE Level 2 and Level 3 traceability requirements.

### ASPICE Traceability Requirements

**SYS.2: System Requirements Analysis**
- Bidirectional traceability between system requirements and stakeholder requirements
- Traceability to system architectural design

**SYS.3: System Architectural Design**
- Traceability from system requirements to system architecture elements
- Traceability to interface requirements

**SWE.1: Software Requirements Analysis**
- Bidirectional traceability between software requirements and system requirements
- Traceability to software architectural design

**SWE.5: Software Integration Test**
- Traceability from integration test cases to software requirements
- Traceability to software architectural design

**SWE.6: Software Qualification Test**
- Bidirectional traceability between test cases and software requirements

### ASPICE Capability Level 2 Evidence

For ASPICE CL2, demonstrate:

1. **Consistency of Traceability**: All requirements have corresponding design and test items
2. **Bidirectional Links**: Both parent and child relationships are maintained
3. **Traceability Reports**: Generate coverage reports showing requirement-to-test mapping

**Example Traceability Query**:

```bash
tracertm query --filter "type=software-requirement AND asil>=B" \
               --show-links "tests,design" \
               --output aspice-cl2-report.html
```

### ASPICE Capability Level 3 Evidence

For ASPICE CL3, additionally demonstrate:

1. **Process Tailoring**: Traceability approach adapted to project risk and complexity
2. **Metrics and Trends**: Track traceability coverage over project timeline
3. **Change Impact Analysis**: Document how requirement changes propagate through traceability

**Example Change Impact Report**:

```bash
tracertm impact --requirement REQ-SWE-001 \
                --depth 3 \
                --include-tests \
                --output change-impact-report.pdf
```

---

## Requirements to Design to Test Traceability

Complete vertical traceability ensures every requirement is designed, implemented, and verified.

### Traceability Chain Example

**Customer Requirement → System Requirement → Software Requirement → Design → Code → Test**

```markdown
# Customer Requirement: CR-001
Title: Cruise Control Speed Maintenance
Description: Vehicle shall maintain set speed within ±2 km/h on level roads

Links:
- Derived System Requirements:
  - SR-CC-001: Cruise control speed regulation
  - SR-CC-002: Speed sensor accuracy requirements

# System Requirement: SR-CC-001
Title: Cruise Control Speed Regulation
Description: System shall regulate throttle to maintain speed within tolerance
ASIL: B

Links:
- Derived Software Requirements:
  - SWR-CC-001: Speed error calculation
  - SWR-CC-002: PID controller implementation
- Verification:
  - Integration Test: INT-CC-001

# Software Requirement: SWR-CC-001
Title: Speed Error Calculation
Description: Calculate error = target_speed - actual_speed every 50ms
ASIL: B

Links:
- Design:
  - DD-CC-001: Speed Controller Design Document
- Implementation:
  - Module: cruise_control.c::calculate_speed_error()
- Unit Tests:
  - UT-CC-001: Test speed error calculation accuracy
- Integration Tests:
  - INT-CC-001: Test closed-loop speed regulation
```

### Test Coverage Matrix

Ensure complete test coverage across requirement levels:

| Requirement | Unit Test | Integration Test | System Test | Vehicle Test |
|-------------|-----------|------------------|-------------|--------------|
| SWR-CC-001 | UT-CC-001 | INT-CC-001 | SYS-CC-001 | VEH-CC-001 |
| SWR-CC-002 | UT-CC-002 | INT-CC-001 | SYS-CC-001 | VEH-CC-001 |
| SWR-CC-003 | UT-CC-003 | INT-CC-002 | SYS-CC-002 | VEH-CC-002 |

Generate coverage matrix:

```bash
tracertm matrix --source-type "software-requirement" \
                --target-type "test" \
                --group-by test-level \
                --output coverage-matrix.xlsx
```

---

## Hazard Analysis and Risk Assessment Integration

Integrate HARA results directly into traceability to ensure hazards are properly mitigated.

### Hazard Definition

```markdown
# Hazard: HAZ-001 Unintended Braking
Type: Hazard
System: Electronic Stability Control (ESC)

Hazardous Event: Unexpected brake application during normal driving

Operating Scenarios:
- Highway driving at 120 km/h
- Urban driving in traffic
- Wet road conditions

Severity: S3 (Life-threatening injuries)
Exposure: E4 (High probability - daily occurrence)
Controllability: C3 (Difficult to control)

ASIL: D

Derived Safety Goals:
- SG-ESC-001: Prevent uncommanded brake activation
- SG-ESC-002: Detect and disable faulty brake actuators
```

### Safety Goal Decomposition

```markdown
# Safety Goal: SG-ESC-001
Title: Prevent Uncommanded Brake Activation
ASIL: D
Mitigates: HAZ-001

Safe State: Brake system disabled with driver notification

Functional Safety Requirements:
- FSR-ESC-001: Brake command validation (ASIL D)
- FSR-ESC-002: Dual-channel brake control (ASIL B(D))
- FSR-ESC-003: Brake plausibility monitoring (ASIL B(D))

Safety Mechanisms:
- SM-ESC-001: Brake command cross-check
- SM-ESC-002: Watchdog monitoring
- SM-ESC-003: Diagnostic trouble code (DTC) generation
```

### FMEA/FMEDA Traceability

Link Failure Mode and Effects Analysis to safety requirements:

```markdown
# Failure Mode: FM-ESC-001
Component: Brake Pressure Sensor
Failure Mode: Sensor stuck at high value
Effect: System interprets as constant brake demand

Severity: High
Occurrence: Medium (10 FIT)
Detection: High (diagnostic coverage 95%)

Safety Requirements Affected:
- FSR-ESC-001: Brake command validation
- FSR-ESC-003: Brake plausibility monitoring

Mitigations:
- SM-ESC-001: Redundant sensor cross-check
- SM-ESC-004: Sensor drift detection algorithm

Verification:
- Test: FI-ESC-001 (Fault injection test)
```

---

## Software Component Traceability

Track traceability at the software architecture and component level.

### Software Architecture Mapping

```markdown
# Software Component: BrakeController
Type: Software Component
ASIL: D
ECU: Gateway ECU

Implements Requirements:
- FSR-ESC-001: Brake command validation
- FSR-ESC-002: Dual-channel brake control
- TSR-ESC-005: Brake actuator interface

Internal Modules:
- brake_command_validator.c
- brake_actuator_driver.c
- brake_diagnostics.c

Interfaces:
- Input: CAN message 0x123 (brake pedal position)
- Output: PWM signal to brake actuator
- Diagnostic: DTC reporting via UDS

Verification:
- Unit Tests: UT-BRAKE-001 to UT-BRAKE-045
- Integration Tests: INT-BRAKE-001 to INT-BRAKE-012
- Software Quality Metric: MISRA C compliance verified
```

### AUTOSAR Component Traceability

For AUTOSAR architectures, map software components to atomic software components (SWC):

```markdown
# AUTOSAR SWC: BrakeControl_SWC
Type: Application Software Component
Runnable: BrakeControl_10ms (triggered every 10ms)

Port Interfaces:
- Require Port: BrakePedalPosition (Sensor Interface)
- Provide Port: BrakeActuatorCommand (Actuator Interface)

Requirements Allocation:
- FSR-ESC-001: Implemented in BrakeValidation runnable
- FSR-ESC-002: Implemented in DualChannelControl runnable

BSW Dependencies:
- CAN Driver (ASIL D)
- Diagnostic Event Manager (ASIL D)
- NvM for calibration parameters (QM)
```

---

## Real-World Automotive Development Workflows

### Workflow 1: New Feature Development

**Scenario**: Adding Adaptive Cruise Control (ACC) feature

1. **Concept Phase**:
   - Create hazard analysis items for ACC scenarios
   - Define safety goals and ASIL classifications
   - Link hazards → safety goals

2. **System Design Phase**:
   - Define functional safety requirements from safety goals
   - Create system architecture elements
   - Link FSRs → technical safety requirements

3. **Software Development Phase**:
   - Derive software safety requirements from TSRs
   - Implement software components
   - Link SSRs → design → code modules

4. **Verification Phase**:
   - Create unit tests for each SSR
   - Create integration tests for FSRs
   - Create system tests for safety goals
   - Link tests → requirements bidirectionally

5. **Safety Assessment**:
   - Generate traceability reports for ISO 26262 compliance
   - Verify complete vertical traceability
   - Document ASIL decomposition arguments

**TracerTM Commands**:

```bash
# Create project structure
tracertm project create --name "ACC_Development" --standard ISO26262

# Import hazards from safety analysis
tracertm import --file hara_results.xlsx --type hazard

# Create requirement hierarchy
tracertm create-item --type safety-goal --title "SG-ACC-001" \
                     --link-to HAZ-ACC-001 --link-type mitigates

# Generate ISO 26262 compliance report
tracertm report --template iso26262 --asil D --output iso26262_report.pdf
```

### Workflow 2: Requirement Change Management

**Scenario**: Customer requests change to braking distance requirement

1. **Identify Affected Items**:
   - Run impact analysis on changed requirement
   - Identify all downstream design and test items

2. **Update Traceability**:
   - Update requirement text and attributes
   - Review and update linked design elements
   - Identify tests requiring modification

3. **Propagate Changes**:
   - Update affected software requirements
   - Modify design specifications
   - Update or create new test cases

4. **Verification**:
   - Re-run affected tests
   - Update traceability links
   - Generate change impact report for review

**TracerTM Commands**:

```bash
# Analyze impact of requirement change
tracertm impact --item FSR-BRAKE-001 --depth all --output impact_analysis.html

# Track requirement version history
tracertm history --item FSR-BRAKE-001 --show-links

# Generate change notification
tracertm report --template change-impact --items FSR-BRAKE-001 \
                --output change_notification.pdf
```

### Workflow 3: Supplier Integration

**Scenario**: Integrating Tier 2 supplier software component

1. **Receive Supplier Deliverables**:
   - Import supplier requirements and test reports
   - Map supplier IDs to internal traceability scheme

2. **Interface Mapping**:
   - Create interface requirements
   - Link internal requirements to supplier requirements
   - Verify interface compliance

3. **Integration Verification**:
   - Create integration test items
   - Link integration tests to interface requirements
   - Execute and track test results

4. **Compliance Documentation**:
   - Generate combined traceability report
   - Include supplier traceability evidence
   - Document supplier ASIL capability

**TracerTM Commands**:

```bash
# Import supplier requirements
tracertm import --file supplier_reqs.xml --type requirement \
                --prefix SUPP --namespace supplier_tier2

# Create interface links
tracertm link --from FSR-INT-001 --to SUPP-REQ-045 \
              --type implements --bidirectional

# Generate supplier integration report
tracertm report --template supplier-integration \
                --namespace supplier_tier2 --output supplier_report.pdf
```

---

## Best Practices for Automotive Safety-Critical Development

### 1. Establish Clear Traceability Policies

**Define naming conventions**:
- Hazards: `HAZ-<SYSTEM>-<###>`
- Safety Goals: `SG-<SYSTEM>-<###>`
- FSRs: `FSR-<SYSTEM>-<###>`
- TSRs: `TSR-<SYSTEM>-<###>`
- SSRs: `SSR-<MODULE>-<###>`

**Standardize link types**:
- `derives-from`: Parent-child requirement relationship
- `mitigates`: Safety goal mitigates hazard
- `refines`: More specific requirement from higher-level requirement
- `implements`: Design/code implements requirement
- `verifies`: Test verifies requirement

### 2. Maintain Bidirectional Traceability

Always create links in both directions:
- Forward: Requirements → Design → Tests
- Backward: Tests → Design → Requirements

Verify completeness with regular reports:

```bash
tracertm verify --check-bidirectional --check-orphans --output verification.html
```

### 3. Use Attributes for Safety Properties

Track safety-critical attributes on all items:

- **ASIL**: A, B, C, D, or QM
- **Safety Mechanism**: Yes/No
- **Verification Level**: Unit/Integration/System/Vehicle
- **Compliance Status**: Planned/Implemented/Verified/Approved

### 4. Automate Traceability Checks

Integrate traceability validation into CI/CD pipeline:

```yaml
# .github/workflows/traceability-check.yml
- name: Verify Traceability
  run: |
    tracertm verify --asil D --check-coverage --fail-on-gaps
    tracertm report --template iso26262 --output reports/iso26262.pdf
```

### 5. Regular Traceability Audits

Schedule periodic reviews:

- **Weekly**: Check for orphaned requirements and broken links
- **Monthly**: Review traceability coverage metrics
- **Per Milestone**: Generate compliance reports for management review
- **Pre-Release**: Complete traceability audit for safety assessment

### 6. Document Traceability Rationale

Add justification for critical traceability decisions:

```markdown
# Why FSR-001 links to both TSR-001 and TSR-002:
Rationale: FSR-001 requires redundant implementation per ASIL D decomposition
strategy. TSR-001 provides primary channel (ASIL B(D)) and TSR-002 provides
independent secondary channel (ASIL B(D)).
```

### 7. Manage Tool Qualification

For ISO 26262 compliance, qualify TracerTM as a Tool Confidence Level (TCL) tool:

- **TCL1 (no qualification needed)**: If traceability reports are manually reviewed
- **TCL2 (validation required)**: If automated checks generate safety evidence
- **TCL3 (qualification required)**: If tool failures could introduce safety issues

Document tool validation evidence:

```bash
tracertm validate --run-test-suite --generate-validation-report \
                  --output tool_validation_report.pdf
```

### 8. Version Control Integration

Store traceability data with source code:

```bash
# Commit traceability with code changes
git add src/brake_control.c
git add traceability/SSR-BRAKE-001.md
git commit -m "Implement brake validation per SSR-BRAKE-001"

# Tag releases with traceability snapshot
git tag -a v1.0.0-trace -m "Release 1.0.0 with complete traceability"
tracertm export --output release-1.0.0-traceability.json
```

### 9. Cross-Functional Review

Involve multiple roles in traceability review:

- **Safety Manager**: Verify hazards trace to mitigations
- **System Engineer**: Verify requirement decomposition
- **Software Developer**: Verify implementation traces to requirements
- **Test Engineer**: Verify test coverage completeness
- **Quality Manager**: Verify ASPICE process compliance

### 10. Continuous Improvement

Track and improve traceability metrics over time:

| Metric | Target | Current | Trend |
|--------|--------|---------|-------|
| Requirements without tests | 0% | 2% | ↓ Improving |
| Orphaned design items | 0% | 1% | ↓ Improving |
| Broken traceability links | 0% | 0% | ✓ Achieved |
| ASIL D coverage | 100% | 98% | ↑ Improving |
| Bidirectional link consistency | 100% | 100% | ✓ Achieved |

---

## Conclusion

Automotive traceability is a critical success factor for ISO 26262 compliance, ASPICE process capability, and overall safety-critical development quality. TracerTM provides the foundation for comprehensive, auditable, and maintainable traceability throughout the automotive development lifecycle.

By following these best practices and leveraging TracerTM's capabilities, automotive teams can:

- Demonstrate compliance to functional safety standards
- Achieve higher ASPICE capability levels
- Reduce rework through effective change impact analysis
- Improve collaboration across OEMs and suppliers
- Build safer, higher-quality automotive systems

For additional guidance, see:
- [ISO 26262 Traceability Templates](/docs/templates/iso26262)
- [ASPICE Process Implementation Guide](/docs/guides/aspice)
- [Automotive CLI Workflows](/docs/guides/automotive-cli)
- [Safety Case Generation](/docs/guides/safety-case)
