4.0: Safety Standards Integration

Introduction

Safety-critical systems require compliance with both ASPICE (process capability) and functional safety standards (hazard prevention). This chapter explains how ASPICE processes integrate with ISO 26262 (automotive), IEC 61508 (industrial), DO-178C (aviation), and tool qualification requirements.

The Dual Compliance Challenge

ASPICE + Safety Standards: Complementary Frameworks

This diagram illustrates how ASPICE process requirements and safety standard requirements (ISO 26262, IEC 61508) complement each other, with ASPICE defining the process framework and safety standards defining the required rigor.

Key Insight: ASPICE defines the PROCESS, Safety defines the RIGOR.

Safety Standard Landscape

Comparison Matrix

This Chapter Focus: ISO 26262, IEC 61508, DO-178C, and tool qualification (applicable to all).

Integration Principles

1. Process Reuse with Safety Add-Ons

Core Concept: Use ASPICE processes as the foundation, augment with safety-specific work products and reviews.

Example: SWE.1 Software Requirements Analysis

# ASPICE SWE.1 Base Practices:
BP1: Specify software requirements
BP2: Structure software requirements
BP5: Establish bidirectional traceability
BP6: Ensure consistency
BP7: Communicate requirements

# + ISO 26262-6 Clause 6 Add-Ons:
Table 2: Safety requirements specification
Table 3: Safety requirements notation (formal/semi-formal for ASIL-C/D)
Table 4: Verification of software safety requirements

Work Product Merge:

• ASPICE: Software Requirements Specification (SWRS)
• ISO 26262: Software Safety Requirements Specification (SSRS)
• Integrated: Single SWRS with safety annotations (ASIL levels, safety relevance, etc.)

2. Traceability Extensions

ASPICE requires traceability. Safety standards demand granular, auditable traces.

ASPICE Traceability (SWE.1 BP5):

• Software requirements ↔ System requirements

ISO 26262 Traceability (ISO 26262-6 Clause 6, Table 4 — Verification of software safety requirements):

• Stakeholder needs → Safety goals → Technical safety requirements → System requirements → Software requirements → Software units → Test cases

Integration Strategy:

• Extend ASPICE traceability matrices with safety columns
• Add safety-specific trace types: hazard analysis, safety mechanisms

Example Traceability Matrix:

Hazard_ID,Safety_Goal,TSR_ID,SYS_REQ_ID,SW_REQ_ID,SW_Unit,Test_Case,ASIL
HAZ-001,Prevent unintended acceleration,TSR-042,SYS-012,SWE-089,throttle_ctrl.c,TC-089,ASIL-D

3. Verification Intensity Scaling

Principle: Higher ASIL = More rigorous ASPICE process execution

4. Safety-Specific Work Products

Beyond ASPICE, safety standards require additional deliverables:

ASPICE Capability Level Impact on Safety

Mapping CL to ASIL Suitability

Rationale:

• CL1 (Performed): Processes exist but lack rigor for safety argumentation
• CL2 (Managed): Sufficient for ASIL-A/B with well-defined work products
• CL3 (Established): Required for ASIL-C/D due to need for predictable, repeatable processes

Safety Lifecycle Phases

V-Model with Safety Gates

The following diagram extends the standard V-Model with safety gates at each phase transition, showing where safety reviews, hazard analyses, and ASIL-dependent verification activities must occur.

Tool Confidence Level (TCL) and ASPICE

Tool Qualification Requirements

ISO 26262-8 Clause 11: Software tools used in safety development must be qualified based on Tool Confidence Level (TCL).

ASPICE Alignment:

• SUP.8 (Config Management): Track tool versions and qualifications
• SWE.3 BP5: Use qualified tools for code generation
• SWE.4 BP4: Use qualified tools for coverage measurement

Example Tool Classifications:

Tool Qualification Artifacts (see 21.04):

• Tool Validation Report
• Tool Operational Requirements
• Tool Classification Analysis

AI Tools in Safety-Critical Development

AI Toolchain Safety Considerations

Emerging Challenge: GitHub Copilot, ChatGPT, Claude for code generation

Recommendation for ASIL-B Projects:

1. Use AI assistively (suggestions reviewed by human) - No qualification required
2. All AI-generated code must pass:
   • Manual code review (SUP.1 BP4)
   • Unit testing with human-designed test cases (SWE.4)
   • Static analysis (SWE.3 BP7)
3. Document AI usage in Safety Plan:
   • Which tools used (name, version)
   • Human oversight measures
   • Verification strategy

Safety Case and ASPICE Evidence

Safety Argumentation Structure

Safety Claim: "Software is sufficiently safe for ASIL-B operation"
│
├── Argument: Requirements are complete and correct
│   ├── Evidence: [SWE.1] SWRS with 100% traceability to TSRs
│   ├── Evidence: [SUP.1] Requirements review records
│   └── Evidence: [SWE.1 BP6] Consistency check report
│
├── Argument: Architecture prevents systematic failures
│   ├── Evidence: [SWE.2] Software architecture document with FFI analysis
│   ├── Evidence: [SYS.3] ASIL decomposition justification
│   └── Evidence: [SUP.1] Architecture review records
│
├── Argument: Implementation is free from defects
│   ├── Evidence: [SWE.3] Code complies with MISRA C:2012 (static analysis)
│   ├── Evidence: [SWE.3 BP7] Code review records (100% coverage)
│   └── Evidence: [SWE.4] Unit test reports (100% MC/DC coverage)
│
├── Argument: Verification is adequate
│   ├── Evidence: [SWE.4-6] Test specifications and reports
│   ├── Evidence: [SWE.6] Qualification test report (ASIL-B test methods applied)
│   └── Evidence: [SUP.1] Independent verification report
│
└── Argument: Configuration is controlled
    ├── Evidence: [SUP.8] Configuration management records (Git history)
    ├── Evidence: [SUP.9] Problem reports and resolutions
    └── Evidence: [SUP.10] Change control board meeting minutes

Key Insight: ASPICE work products directly feed into the safety case as evidence.

Common Integration Challenges

Challenge 1: Terminology Mismatch

Solution: Create a terminology mapping document in project glossary.

Challenge 2: Overlapping Reviews

Problem: ASPICE and safety standards both require reviews, leading to duplication.

Example:

• ASPICE SWE.2 BP8: Review architectural design
• ISO 26262-6 Table 8: Verification of software architectural design

Solution: Merged Review Strategy

# Combined Architecture Review Checklist

## ASPICE SWE.2 Checks:
- ☐ BP1: Architectural design developed
- ☐ BP2: Requirements allocated to components
- ☐ BP3: Interfaces defined
- ☐ BP7: Traceability established

## ISO 26262-6 Table 8 Checks:
- ☐ 1a: Hierarchical structure of software components
- ☐ 1b: Software components implement safety requirements
- ☐ 1c: Restricted size and complexity
- ☐ 1d: Restricted use of interrupts (ASIL-C/D)
- ☐ 1e: Freedom from interference between components

Efficiency Gain: Single review covers both ASPICE and ISO 26262 requirements.

Challenge 3: Tool Qualification Burden

Problem: Qualifying every tool is expensive and time-consuming.

Solutions:

1. Use Pre-Qualified Tools: Many vendors provide ISO 26262-certified toolchains

   • Example: IAR EWARM Functional Safety Edition (pre-qualified for ASIL-D)
   • Example: VectorCAST (pre-qualified coverage tool)

2. Tool Qualification Sharing: Reuse qualifications across projects

   • Maintain company-wide tool qualification database

3. Increased Confidence from Use: Tool widely used in industry = higher confidence

   • GCC with extensive test history may require less qualification effort

Summary

Safety Standards Integration with ASPICE:

• Complementary Frameworks: ASPICE = process capability, Safety = risk mitigation
• Process Reuse: Use ASPICE as foundation, add safety-specific work products
• Traceability Extensions: Hazards → Requirements → Code → Tests
• Verification Scaling: Higher ASIL = More rigorous ASPICE execution
• Tool Qualification: TCL-based approach for safety-critical toolchains
• AI Considerations: Human oversight mandatory for AI-generated safety code

Chapter Structure:

1. 21.01 ISO 26262 Integration - Automotive functional safety (ASIL-B/C/D)
2. 21.02 IEC 61508 Integration - General industrial safety (SIL 1-4)
3. 21.03 DO-178C Integration - Aviation software (DAL A-E)
4. 21.04 Tool Qualification - TCL analysis and qualification processes