1.0: Multi-Standard Compliance Roadmap

Overview: This chapter guides practitioners through implementing systems that simultaneously comply with multiple safety and quality standards. Rather than treating standards as separate silos, we provide a unified framework showing which standards apply, how they interact, and how to consolidate requirements and processes.

Executive Summary

The Multi-Standard Challenge

Modern safety-critical systems often must satisfy multiple standards simultaneously:

  • Automotive: ASPICE 4.0 + ISO 26262 + ISO/SAE 21434 (cybersecurity)
  • Medical Devices: ASPICE 4.0 + IEC 62304 + ISO 14971 (risk management)
  • Industrial/Safety-Critical: ASPICE 4.0 + IEC 61508 + ISO/SAE 21434
  • Aerospace/DO-178C Systems: DO-178C + FAA guidance + ASPICE mappings

Key Insight

80% of requirements overlap across standards. Rather than multiplying effort by the number of standards, consolidate common processes and add standard-specific supplements.

Standard Selection Decision Tree

START: You're developing a safety-critical system. Which standards apply?

START: What is your product domain?
  │
  ├─→ AUTOMOTIVE (vehicle, ECU, ADAS, infotainment)
  │   ├─ Base: ASPICE 4.0 (required for suppliers)
  │   ├─ Safety: ISO 26262 (if safety function exists)
  │   └─ Cyber: ISO/SAE 21434 (if connected vehicle)
  │   └─ DECISION: ASPICE + ISO 26262 [+ ISO/SAE 21434]
  │
  ├─→ MEDICAL DEVICE (infusion pump, monitor, ventilator)
  │   ├─ Base: IEC 62304 (regulatory requirement)
  │   ├─ Risk: ISO 14971 (required for all medical devices)
  │   ├─ Quality: ISO 13485 (if selling in EU/US)
  │   └─ Optional: ASPICE 4.0 (if supplier to larger OEM)
  │   └─ DECISION: IEC 62304 + ISO 14971 [+ ISO 13485] [+ ASPICE]
  │
  ├─→ INDUSTRIAL/MACHINERY (PLC, safety controller, machine)
  │   ├─ Safety: IEC 61508 (if E/E/PE safety system)
  │   ├─ Machine: ISO 12100 (if machinery)
  │   ├─ Cyber: ISO/SAE 21434 (if connected)
  │   └─ Optional: ASPICE 4.0 (if software component significant)
  │   └─ DECISION: IEC 61508 [+ ISO 12100] [+ ASPICE]
  │
  ├─→ AEROSPACE/AVIATION (aircraft, avionics, autopilot)
  │   ├─ Base: DO-178C (FAA certification requirement)
  │   ├─ Hardware: DO-254 (if hardware involved)
  │   ├─ Tools: DO-330 (tool qualification)
  │   └─ Optional: ASPICE references (not required but helpful)
  │   └─ DECISION: DO-178C [+ DO-254] + DO-330
  │
  └─→ RAIL/RAILWAY (signaling, control, brake systems)
      ├─ Safety: EN 50128 (safety-related software)
      ├─ System: EN 50126 (RAMS - reliability/availability)
      └─ Optional: ASPICE 4.0 (for mature development)
      └─ DECISION: EN 50128 [+ EN 50126] [+ ASPICE]

Multi-Standard Compliance Matrix

Requirements Overlap Analysis

Core Requirements Present in ALL Standards:

Requirement Category ASPICE ISO 26262 IEC 61508 IEC 62304 DO-178C
Requirements specification SWE.1 [PASS] [PASS] [PASS] [PASS]
Design documentation SWE.2 [PASS] [PASS] [PASS] [PASS]
Code/implementation SWE.3 [PASS] [PASS] [PASS] [PASS]
Unit/module testing SWE.4 [PASS] [PASS] [PASS] [PASS]
Integration testing SWE.5 [PASS] [PASS] [PASS] [PASS]
System/acceptance testing SWE.6 [PASS] [PASS] [PASS] [PASS]
Configuration management SUP.1 [PASS] [PASS] [PASS] [PASS]
Traceability SWE req→code→test [PASS] [PASS] [PASS] [PASS]
Risk management MAN.3 ISO 26262-9 IEC 61508-5 ISO 14971 MIL-STD analogy
Quality assurance QUA.1 [PASS] [PASS] [PASS] [PASS]
Problem resolution SUP.9 [PASS] [PASS] [PASS] [PASS]

Overlap Percentage: ~80% of base practices are equivalent

Consolidation Strategy

Rather than implementing 5 separate processes, implement ONE unified process with standard-specific supplements:

Example: Requirements Specification

UNIFIED APPROACH:
├─ Core Process (covers all standards):
│  ├─ Stakeholder requirements → System requirements → Software requirements
│  ├─ Traceability matrix (requirements → design → code → test)
│  ├─ Requirements review checklist (completeness, testability, feasibility)
│  └─ Requirements management tool (Jama, DOORS, SpiraTest)
│
├─ ISO 26262 Supplement:
│  ├─ Mark safety-related requirements [ISO-26262-SAFETY]
│  ├─ Include ASIL allocation (A/B/C/D)
│  └─ Cross-reference to hazard analysis (HARA)
│
├─ IEC 61508 Supplement:
│  ├─ Mark safety-critical requirements [IEC-61508-SAFETY]
│  ├─ Include SIL allocation (1/2/3/4)
│  └─ Link to SIL determination (fault tree analysis)
│
├─ IEC 62304 Supplement:
│  ├─ Mark safety-critical requirements [IEC-62304-SAFETY]
│  ├─ Include safety class allocation (A/B/C)
│  └─ Link to risk management file (ISO 14971)
│
└─ DO-178C Supplement:
   ├─ Mark aviation-critical requirements [DO-178C-CRITICAL]
   ├─ Include DAL allocation (A/B/C/D/E)
   └─ Link to certification artifacts

Effort Comparison:

  • Siloed approach: 5 requirements databases = 5× effort
  • Unified approach: 1 requirements database + supplements = 1.3× effort (30% overhead for standards-specific fields)

Savings: 70% reduction vs. separate processes

Multi-Standard Case Study: Autonomous Vehicle Brake System

System Definition

Product: Level 2+ Autonomous Vehicle Brake Control System Functions:

  • Anti-lock braking (ABS)
  • Electronic stability control (ESC)
  • Automated emergency braking (AEB)

Standards Applicable:

  1. ASPICE 4.0 - Supplier maturity requirement
  2. ISO 26262 - Automotive functional safety (ASIL C for brake control)
  3. ISO/SAE 21434 - Cybersecurity (vehicle attack surface)
  4. ISO 13485 potential - If medical monitoring features

Requirements Consolidation Example

Requirement: "System shall apply maximum braking force within 100ms of emergency condition"

How it Maps:

UNIFIED REQUIREMENT SPEC:
[BR-001] Emergency Braking Response Time
  Description: System shall apply maximum braking force within 100ms
  Domain: Brake control
  Safety Class: SAFETY-CRITICAL

ASPICE Mapping:
  ├─ SWE.1: Functional requirement [SWE-FUNC-001]
  └─ Verification: SWE.4/5/6 with timing tests

ISO 26262 Mapping:
  ├─ ASIL: C (loss of brake → crash)
  ├─ Hazard: [HAZ-015] "Brake system unresponsive"
  ├─ Risk Control: Software emergency braking logic
  └─ Verification: Response time test (SWE.4, unit test)

ISO/SAE 21434 Mapping:
  ├─ Threat: [THR-008] "Brake command injection attack"
  ├─ Risk: Medium (vehicle crash if brake disabled)
  ├─ Mitigation: Message authentication code (MAC)
  └─ Verification: Cryptographic validation test

CONSOLIDATED VERIFICATION PLAN:
├─ Unit Test: Emergency braking function response time (SWE.4)
├─ ISO 26262: ASIL C proof (FMEA, FTA verification)
├─ ISO/SAE 21434: Encryption validation (MAC attack resistance)
└─ System Test: End-to-end braking under attack conditions (SWE.6)

Tool & Process Consolidation

Single Toolchain Supporting All Standards

Example: Automotive Brake Control

REQUIREMENTS LAYER (Jama Connect):
  ├─ Base: ISO/IEC 29148 requirement format
  ├─ Fields: Requirement ID, Title, Description, Rationale,
  │          Verification Method, Traceability
  └─ Custom Fields: [ASPICE-BP], [ISO26262-ASIL], [ISO21434-THREAT]

DESIGN LAYER (Enterprise Architect):
  ├─ Architecture diagrams (ASPICE SWE.2)
  ├─ Safety decomposition (ISO 26262 ASIL allocation)
  ├─ Attack surface mapping (ISO/SAE 21434 threats)
  └─ Traceability: Requirement → Architecture element

CODE LAYER (Git + Gerrit):
  ├─ Version control (ASPICE SUP.1)
  ├─ Code review checklist:
  │  ├─ MISRA C:2012 (ISO 26262 compliance)
  │  ├─ Secure coding (ISO/SAE 21434 mitigation)
  │  └─ Safety patterns (IEC 61508 defensive programming)
  └─ Traceability: Architecture → Code module

TEST LAYER (Robot Framework + JUnit):
  ├─ Unit tests (SWE.4)
  ├─ Integration tests (SWE.5)
  ├─ System tests (SWE.6)
  └─ Test coverage:
     ├─ ISO 26262: 100% statement, 80% MC/DC (ASIL C)
     ├─ ISO/SAE 21434: Attack scenario tests
     └─ ASPICE: Traceability matrix (req→test)

METRICS LAYER (SonarQube + Custom):
  ├─ Code coverage (SWE.4 evidence)
  ├─ MISRA violations (ISO 26262 compliance)
  ├─ Security issues (ISO/SAE 21434 vulnerabilities)
  └─ Traceability: % requirements verified

DOCUMENTATION LAYER (Markdown + Pandoc):
  ├─ Technical specification (SYS/SWE/HWE processes)
  ├─ Safety case document (ISO 26262, ISO/SAE 21434)
  ├─ Risk management file (ISO 14971)
  └─ Certification artifacts (OEM approval)

Conflict Resolution: When Standards Disagree

Example Conflict: Code Coverage Requirements

ISO 26262-6 (ASIL C):
  "Statement coverage: 100%"
  "Branch coverage: 100% (or justified gaps)"

IEC 61508-3 (SIL 3):
  "Statement coverage: 90%+"
  "Branch coverage: 70%+"

DO-178C (DAL B):
  "Statement coverage: 100%"
  "MC/DC coverage: RECOMMENDED for DAL B+"

RESOLUTION:
├─ Select STRICTEST requirement: ISO 26262 (100% statement, 100% branch)
├─ Rationale: "Implementing strictest standard satisfies all others"
├─ Document: "Coverage achieved per ISO 26262-6:2018 Clause 6.2.4"
└─ Verification: Report shows 100% statement, 100% branch
   └─ NOTE: "Exceeds IEC 61508 (90%/70%) and DO-178C requirements"

Conflict Resolution Process

  1. Identify Conflict: Which requirement differs across standards?
  2. Understand Rationale: Why does each standard require different approaches?
  3. Select Strictest: Implementing the strictest satisfies all
  4. Document Decision: Record the conflict and resolution
  5. Verify All Met: Confirm solution meets ALL standards

Implementation Roadmap

Month 1: Setup (ASPICE + ISO 26262)

Week 1-2: Establish toolchain

  • Jama Connect (requirements)
  • Git repository (code)
  • Robot Framework (tests)
  • SonarQube (metrics)

Week 3-4: Define consolidated processes

  • Single SRS template (with ISO 26262 ASIL fields)
  • Code review checklist (includes MISRA C:2012)
  • Test plan (includes ISO 26262 coverage targets)

Month 2: Add Cybersecurity (ISO/SAE 21434)

Week 5-6: Threat modeling

  • Identify attack surfaces (ISO/SAE 21434 Clause 8)
  • Define threat scenarios (brake command injection)

Week 7-8: Implement mitigations

  • Code: Add message authentication (MAC)
  • Tests: Verify attack resistance
  • Documentation: Threat analysis report

Month 3: Refine & Optimize

Week 9-10: Compliance verification

  • Traceability audit (requirements → code → tests)
  • Coverage analysis (ISO 26262, ISO/SAE 21434 requirements met)

Week 11-12: Certification preparation

  • Compile safety case (ASIL C evidence)
  • OEM review and approval

Key Metrics

Consolidation Effectiveness

Before Consolidation (5 separate processes):

  • Requirements databases: 5
  • Design tools: 3 different formats
  • Test frameworks: 4
  • Documentation: 5 separate documents
  • Total effort: 1,000 hours

After Consolidation (1 unified + supplements):

  • Requirements databases: 1 (with 5 standard-specific fields)
  • Design tools: 1 (with safety/cyber overlays)
  • Test frameworks: 1 (with standard-specific assertions)
  • Documentation: 1 master + 5 standard-specific annexes
  • Total effort: 1,300 hours (30% overhead for standards, 70% efficiency gain)

ROI: 300 hours saved (30% reduction vs. siloed approach)

Compliance Verification Checklist

ASPICE 4.0 Compliance

  • [PASS] SWE.1-6 processes implemented
  • [PASS] Process outcomes achieved (O1-O6 per process)
  • [PASS] Configuration management (SUP.1)
  • [PASS] Quality assurance (QUA.1)

ISO 26262 Compliance (ASIL C)

  • [PASS] Hazard analysis (HARA) completed
  • [PASS] ASIL allocation documented
  • [PASS] Risk control measures traced to requirements
  • [PASS] Code coverage: 100% statement, 100% branch
  • [PASS] MISRA C:2012 violations: ZERO

ISO/SAE 21434 Compliance

  • [PASS] Threat modeling completed
  • [PASS] Attack scenarios documented
  • [PASS] Mitigations implemented and tested
  • [PASS] Cybersecurity evidence compiled

Common Pitfalls & Avoidance

Pitfall Impact Avoidance
Creating separate processes per standard 5× effort, inconsistency Unified framework with supplements
Ignoring standard overlaps Redundant work, confusion Build consolidation matrix first
Selecting weakest standard Compliance failures Select STRICTEST requirement
Poor traceability across standards Incomplete evidence Maintain single RTM with all links
Incomplete threat modeling Cybersecurity vulnerabilities Explicit threat-to-mitigation mapping
Version control chaos Certification delays One Git repo, branching per standard

Summary

Multi-Standard Compliance Framework:

  1. Identify standards using decision tree
  2. Map requirements to consolidated specification
  3. Consolidate processes (1 unified + supplements)
  4. Resolve conflicts (select strictest)
  5. Verify compliance with checklist

Expected Outcome:

  • [PASS] 30% effort savings vs. siloed approach
  • [PASS] Consistent quality across all standards
  • [PASS] Single source of truth (unified processes)
  • [PASS] Faster certification (all evidence in one place)

Next Steps:

  • Use decision tree to identify your standards
  • Adapt examples to your system
  • Implement consolidated toolchain
  • Begin Phase 1: Requirements specification
Previous
Tool Qualification Across Standards - Unified Framework
Next
Legacy System ASPICE Retrofit