DO-178C in one minute
DO-178C (ED-12C in Europe) does not describe a development method. It sets objectives a piece of airborne software must meet to be accepted by the authority, the activities that achieve them and the data that prove it. The number of applicable objectives and the independence required depend on the software level, set by the system safety assessment.
| Level | Most severe failure condition the software can contribute to | Expected structural coverage |
|---|---|---|
| A | catastrophic | MC/DC, decision, statement |
| B | hazardous | decision, statement |
| C | major | statement |
| D | minor | none |
| E | no safety effect | DO-178C does not apply beyond identifying the level |
The objectives are grouped in the ten Annex A tables (A-1 to A-10). For each objective and each level, they say whether it applies, whether it must be met with independence, and the control category (CC1 or CC2) of the data produced. Keep these tables open next to your plans.
The documents, grouped by stage
Plans: what the team will do
| Document | Role | DO-178C section |
|---|---|---|
| PSAC · Plan for Software Aspects of Certification | The agreement with the authority: which software, which level, which processes, which data, which additional considerations | §11.1 |
| SDP · Software Development Plan | Requirements, design, coding and integration processes, environment, transition criteria | §11.2 |
| SVP · Software Verification Plan | Reviews, analyses, tests, coverage, independence, verification environment, regression | §11.3 |
| SCMP · Software Configuration Management Plan | Identification, baselines, problem reports, archiving, rebuild | §11.4 |
| SQAP · Software Quality Assurance Plan | Audits, QA authority, conformity review | §11.5 |
Standards: numbered, checkable rules
| Document | Role | Section |
|---|---|---|
| Requirements standard | How to write a verifiable high-level requirement | §11.6 |
| Design standard | Architecture and low-level requirement rules | §11.7 |
| Code standard | Language subset, complexity rules, prohibitions | §11.8 |
A good standard lets a reviewer write "deviation from RQ-04" rather than "vague requirement".
Development and verification data
| Document | Role | Section |
|---|---|---|
| SRD · Software Requirements Data | High-level requirements, including derived requirements | §11.9 |
| SDD · Design Description | Architecture and low-level requirements | §11.10 |
| Source code and executable object code | With their configuration identification | §11.11, §11.12 |
| SVCP · Verification Cases and Procedures | Test, review and analysis cases and procedures | §11.13 |
| SVR · Verification Results | Results, coverage, gap analyses | §11.14 |
| Problem reports | Form, workflow, safety impact analysis | §11.17 |
| Quality assurance records | Audits, conformity review | §11.19 |
If requirements and tests live in a tool (Jira, Polarion, DOORS…), these documents become the dated export of the tool, with the baseline reference.
Closing
| Document | Role | Section |
|---|---|---|
| SCI · Software Configuration Index | Everything needed to rebuild, reload and re-verify the software | §11.16 |
| SECI · Life Cycle Environment Configuration Index | The environment: compilers, options, tools, host machines | §11.15 |
| SAS · Software Accomplishment Summary | The point-by-point answer to the PSAC: what was done, deviations, open problem reports | §11.20 |
If tools eliminate, reduce or automate an activity without their output being verified otherwise, they must also be qualified (§12.2). Qualification follows DO-330, which has its own plans and data.
The writing order that avoids rework
- Confirm the level with the systems team. It comes from the safety assessment, not from a software decision.
- Write the PSAC, at least in outline. It sets what the other plans will detail.
- Inventory the tools and decide on qualification. This is often where a project discovers a hidden cost.
- Write the SDP, SVP, SCMP, SQAP and the three standards.
- Review the plans internally, then submit the PSAC to the authority.
- Develop while keeping the traceability matrix up to date: system requirement, high-level, low-level, code, test.
- Verify: every test traces to a requirement; structural coverage is measured on requirements-based tests, not on tests written for coverage.
- Close: SCI, SECI, QA conformity review, SAS.
Reviews with the authority (SOI)
In practice the authority, or the organisation acting for it, steps in at four points, the "stages of involvement". They are defined not by DO-178C itself but by authority documents (FAA Order 8110.49A and, on the EASA side, the applicable AMC 20-115).
| Review | What you will be asked |
|---|---|
| SOI 1 · planning | Consistent, approved plans and standards under configuration; additional considerations justified |
| SOI 2 · development | A sample of requirements, design and code, reviewed, traced, under configuration |
| SOI 3 · verification | A sample of cases, procedures, results, coverage, problem reports |
| SOI 4 · final | SCI, SECI, SAS, conformity review |
The best rehearsal: pick a system requirement yourself and follow it down to the test and its result. That is exactly what the authority will do.
The ten most common mistakes
- Plans written for the authority, not the team, then not followed.
- PSAC submitted too late, after development has started.
- Independence claimed but not held (review closed by the author).
- High-level requirements that describe the design.
- Unverifiable requirements: "quickly", "sufficient".
- Derived requirements not fed back to the system process.
- Traceability rebuilt at the end of the project.
- Tests written from the code to reach coverage.
- Verification tools used to remove an activity without qualification.
- Quality assurance reporting to the project manager, with no power to stop.
What really changes with the level
A good level D plan looks like a good level A plan, with fewer objectives and less independence. The differences that weigh most:
| Point | A | B | C | D |
|---|---|---|---|---|
| Structural coverage | MC/DC, decision, statement | decision, statement | statement | none |
| Data and control coupling analysis | yes | yes | yes | no |
| Object code not traceable to source | to be analysed | no | no | no |
| Verification independence | strong | strong | per Annex A | per Annex A |
Start from a structured file
The DO-178C template kit provides these 17 documents as Word templates, set for levels A to D, with writing guidance, examples, review checklists in Excel and a preconfigured traceability matrix. It refers to the sections of the standard without reproducing its text, and replaces neither the authority nor experience. The plan review checklist (level C) is free on the same page. For rail software, see the EN 50128 template kit.
Sources
- RTCA DO-178C / EUROCAE ED-12C, Software Considerations in Airborne Systems and Equipment Certification, 2011 (sections cited by number, text not reproduced)
- RTCA DO-330 / EUROCAE ED-215, Software Tool Qualification Considerations
- FAA Order 8110.49A, Software Approval Guidelines
- EASA AMC 20-115D, Airborne software development assurance using EUROCAE ED-12 and RTCA DO-178