4.3: DO-178C Integration

Introduction

DO-178C "Software Considerations in Airborne Systems and Equipment Certification" is the aviation industry's software development standard. While ASPICE is automotive-focused, this section shows how ASPICE processes can be adapted for DO-178C compliance in avionics systems.

DO-178C Overview

Design Assurance Levels (DAL)

Example DAL Classifications:

• DAL A: Flight control system (fly-by-wire)
• DAL B: Engine control (FADEC - Full Authority Digital Engine Control)
• DAL C: Weather radar
• DAL D: Cabin entertainment system
• DAL E: Non-safety passenger Wi-Fi

DO-178C vs ASPICE: Process Comparison

DO-178C Software Lifecycle Processes

Key Insight: ASPICE maps well to DO-178C, but DO-178C demands extensive documentation and independence.

DO-178C Objectives by DAL

Verification Objectives Table (DO-178C Table A-1 to A-10)

Sample: Software Verification Objectives

Coverage Requirements by DAL (DO-178C Section 6.4.4):

• DAL A: Statement + Decision + MC/DC (Modified Condition/Decision Coverage) - 100% each
• DAL B: Statement + Decision + MC/DC - 100% each
• DAL C: Statement + Decision Coverage - 100% each; MC/DC not required
• DAL D: No structural coverage required
• DAL E: No structural coverage required

Comparison to ISO 26262:

• DAL A/B (MC/DC) = ASIL-C/D (MC/DC)
• DAL C (Statement + Decision) ≈ ASIL-B (Branch coverage)
• DAL D (no coverage) ≈ ASIL-A (Statement coverage)

DO-178C Key Planning Documents

1. Plan for Software Aspects of Certification (PSAC)

Purpose: Defines how software will achieve certification.

ASPICE Integration: MAN.3 BP2 (Define lifecycle model)

PSAC Template (Simplified):

# Plan for Software Aspects of Certification (PSAC)
## Flight Control System - DAL A

### 1. System Overview

**Aircraft**: Regional Jet X200
**Software Item**: Primary Flight Control Computer (PFCC)
**DAL**: Level A (Catastrophic failure condition)
**Certification Basis**: DO-178C, EASA CS-25

### 2. Software Lifecycle

**Lifecycle Model**: V-Model with incremental integration

Requirements → Design → Code → Unit Test ↓ ↓ ↓ ↑ System Requirements Analysis → System Verification

### 3. Software Development Standards

| Standard Type | Document | Version |
|---------------|----------|---------|
| Coding Standard | MISRA C:2012 + DO-178C Supplement | v2.0 |
| Design Standard | DO-331 (Model-Based Dev) | 2011 |
| Tool Qualification | DO-330 | 2011 |

### 4. Verification Activities

| Activity | Responsibility | Schedule |
|----------|----------------|----------|
| Requirements Review | Independent V&V Team | Monthly |
| Design Review | System Safety + IV&V | After each release |
| Code Review | Peer + IV&V | Continuous (every PR) |
| Testing (MC/DC) | Test Team + IV&V | Per build (weekly) |

### 5. Configuration Management

**Tool**: Git + Jira
**Baseline Control**: All releases tagged and archived
**Change Control**: CCB (Change Control Board) approval for DAL A changes

### 6. Quality Assurance

**Independence**: IV&V team reports to Chief Engineer (separate from development)
**Audits**: Quarterly process audits, final certification audit

### 7. Certification Milestones

| Milestone | Date | Deliverables to Authority |
|-----------|------|---------------------------|
| Software Plans Review | 2025-06-01 | PSAC, SDP, SVP, SCMP, SQAP |
| Software Accomplishment Summary | 2026-12-01 | SAS, all verification data |
| Type Certification | 2027-03-01 | Final approval from EASA |

### 8. Approval

**Applicant**: Aircraft Manufacturer Inc.
**Certification Authority**: EASA
**Approved by**: [Chief Engineer], [Certification Manager]
**Date**: 2025-12-17

2. Software Development Plan (SDP)

Purpose: Describes software development process, standards, tools.

ASPICE Integration: MAN.3 BP1 (Define project scope) + all SWE processes

Key Sections:

• Development environment (compilers, IDEs, tools)
• Coding standards (MISRA C compliance)
• Peer review process
• Development milestones

3. Software Verification Plan (SVP)

Purpose: Defines verification strategy (reviews, analysis, testing).

ASPICE Integration: SWE.4 BP1 (Develop unit verification strategy)

Verification Methods by DAL:

DO-178C Verification Independence

Independence Requirements

ASPICE Alignment:

• SUP.1 BP1: Establish quality assurance strategy
• SUP.1 BP4: Perform quality assurance reviews (independent for DAL A/B)

Traceability Requirements (DO-178C Section 6.3)

DO-178C Traceability Data

Required Traces:

System Requirements
    ↓ (derives)
High-Level Software Requirements (HLSR)
    ↓ (derives)
Low-Level Software Requirements (LLSR)
    ↓ (implements)
Source Code
    ↓ (verifies)
Test Cases

Traceability Matrix Example (DAL B):

ASPICE Integration:

• SWE.1 BP5: Establish bidirectional traceability (SWE requirements ↔ System requirements)
• SWE.2 BP7: Establish traceability (Architecture ↔ Requirements)
• SWE.4 BP5: Establish traceability (Tests ↔ Requirements)

Structural Coverage Analysis (DO-178C Section 6.4.4)

MC/DC Coverage (DAL A)

Modified Condition/Decision Coverage: Every condition in a decision independently affects the outcome.

Example (DAL A Flight Control):

// Decision: (altitudeValid && speedValid) || emergencyMode
bool isFlightControlActive(bool altitudeValid, bool speedValid, bool emergencyMode) {
    return (altitudeValid && speedValid) || emergencyMode;
}

// MC/DC Test Cases (6 tests required for 100% MC/DC)
TC-001: altitudeValid=T, speedValid=T, emergencyMode=F → Result=T  (baseline)
TC-002: altitudeValid=F, speedValid=T, emergencyMode=F → Result=F  (toggle altitudeValid)
TC-003: altitudeValid=T, speedValid=F, emergencyMode=F → Result=F  (toggle speedValid)
TC-004: altitudeValid=T, speedValid=T, emergencyMode=T → Result=T  (toggle emergencyMode)
TC-005: altitudeValid=F, speedValid=F, emergencyMode=T → Result=T  (baseline for emergencyMode)
TC-006: altitudeValid=F, speedValid=F, emergencyMode=F → Result=F  (toggle emergencyMode from TC-005)

// Coverage Tool Output:
// MC/DC Coverage: 100% (all conditions independently affect decision)

Tools for MC/DC:

• LDRA TBvision: DO-178C qualified MC/DC tool
• VectorCAST: Qualified for aviation use
• Gcov: NOT qualified for DAL A (requires qualification per DO-330)

Tool Qualification (DO-330: Software Tool Qualification Considerations)

Tool Qualification Levels (DO-330 Section 2.3)

DO-330 defines TQL based on the software level (DAL) and whether the tool is a development tool (Criteria 1: output becomes part of airborne software without verification) or a verification tool (Criteria 2: may fail to detect an error; Criteria 3: output is used to reduce, eliminate, or automate verification activities).

Key Principle: Every TQL level requires qualification — DO-330 does not define a "no qualification required" level equivalent to ISO 26262 TCL 1.

Qualification Artifacts Required (all TQL levels require Tool Qualification Data):

ASPICE Integration (SUP.8):

• SUP.8 BP1: Develop configuration management strategy (includes tool qualification tracking)
• SUP.8 BP2: Identify configuration items (qualified tools are CIs)

Comparison to ISO 26262 TCL:

• DO-330 TQL-1 ≈ ISO 26262 TCL 3 (development tool, highest rigor)
• DO-330 TQL-4/5 ≈ ISO 26262 TCL 2/3 (verification tools)
• DO-330 is MORE stringent overall: no equivalent to TCL 1 (no qualification required); all tools affecting certification must be qualified

Software Accomplishment Summary (SAS)

Final Certification Document

Purpose: Summarize all development and verification activities for certification authority.

ASPICE Integration: Consolidation of all ASPICE work products as evidence.

SAS Template (Simplified):

# Software Accomplishment Summary (SAS)
## Primary Flight Control Computer (PFCC) - Software v3.5.0

**Aircraft**: Regional Jet X200
**Software Item**: PFCC
**DAL**: Level A
**Certification Basis**: DO-178C, EASA CS-25
**Certification Authority**: EASA

### 1. Software Identification

| Attribute | Value |
|-----------|-------|
| Software Part Number | PFCC-SW-v3.5.0 |
| Configuration Index | CI-2027-001 |
| Development Standard | DO-178C + DO-331 (Model-Based) |
| Language | C (ISO C11) + Simulink models |

### 2. Software Life Cycle Environment

**Development Tools (Qualified per DO-330)**:
- Compiler: IAR EWARM v9.30.1 (TQL-1 qualified)
- Static Analyzer: Polyspace Bug Finder R2024a (TQL-2 qualified)
- Coverage Tool: LDRA TBvision 10.5.2 (TQL-3 qualified)
- Code Generator: Simulink Embedded Coder R2024a (TQL-1 qualified)

**Configuration Management**: Git + Jira (controlled environment)

### 3. Software Conformity

| Criteria | Conformance Status | Evidence |
|----------|-------------------|----------|
| Software plans conform to DO-178C | [PASS] Compliant | PSAC, SDP, SVP approved by EASA (2025-06-15) |
| Software development performed per SDP | [PASS] Compliant | QA audit reports (quarterly, all passed) |
| Software verification performed per SVP | [PASS] Compliant | Verification results summary (below) |
| Traceability complete | [PASS] Compliant | Traceability matrices (HLSR→LLSR→Code→Tests) |
| Configuration management complete | [PASS] Compliant | All baselines controlled, change history documented |

### 4. Verification Results Summary

| Verification Activity | Objective | Completed | Pass Rate | Status |
|-----------------------|-----------|-----------|-----------|--------|
| HLSR Review | 100% | 100% | 100% | [PASS] Pass |
| LLSR Review | 100% | 100% | 98% | [WARN] 2 findings resolved |
| Code Review | 100% | 100% | 100% | [PASS] Pass |
| Requirements-Based Testing | 100% coverage | 100% | 100% | [PASS] Pass |
| MC/DC Structural Coverage | 100% MC/DC | 100% | 100% | [PASS] Pass |

### 5. Problem Reports

| PR ID | Description | Severity | Status |
|-------|-------------|----------|--------|
| PR-089 | HLSR-142 ambiguous wording | Minor | Closed (clarified in LLSR) |
| PR-102 | MC/DC gap in function calculateAltitude() | Major | Closed (additional test added) |
| PR-115 | Code review finding: magic number | Minor | Closed (replaced with #define) |

**Open PRs**: 0 (all closed)

### 6. Software Verification Data

**Deliverables**:
- Software Requirements Design Report (SRDR)
- Software Verification Report (SVR)
- Traceability Matrices (4 documents)
- Code Review Reports (150 reviews)
- Test Case Reports (500+ test cases, all passed)
- MC/DC Coverage Report (100% achieved)

### 7. Software Life Cycle Environment Configuration Index (SECI)

All tools and their qualification data are cataloged in SECI document (DO-330 compliance).

### 8. Compliance Statement

**We certify that**:
1. Software development was conducted per approved PSAC, SDP
2. Software verification was conducted per approved SVP
3. All DO-178C objectives for DAL A software have been satisfied
4. Software configuration is under controlled baseline CI-2027-001
5. Software is ready for installation in Type Certified aircraft

**Approved by**:
- **Applicant** (Aircraft Manufacturer): [Name], [Date]
- **IV&V Lead**: [Name], [Date]
- **Certification Authority** (EASA): [Name], [Date]

---

**Conclusion**: Software PFCC v3.5.0 is **CERTIFIED** for installation in Regional Jet X200.

DO-178C vs ASPICE: Key Differences

Integration Strategy: Use ASPICE as process foundation, enhance with DO-178C documentation and independence requirements.

Summary

DO-178C Integration with ASPICE:

• DAL Levels: DAL A-E (Catastrophic to No Effect) similar to ASIL-D to QM
• Process Alignment: DO-178C lifecycle maps to ASPICE SWE.1-6
• Verification Rigor: DAL A requires MC/DC, independent IV&V, extensive documentation
• Tool Qualification: DO-330 mandates qualification of all tools that eliminate, reduce, or automate verification activities; no "no qualification required" category exists (stricter overall than ISO 26262)
• Certification Documents: PSAC, SDP, SVP, SAS required for aviation authority approval
• Independence: DAL A/B require independent verification (external IV&V for DAL A)

Key Takeaway: ASPICE provides process structure; DO-178C provides aviation-specific rigor and certification pathway.