DO-178C: DO-178C – Tutorial (about 60 minutes)

DO-178C is the document that aviation authorities and the aerospace industry use to decide whether the software inside an aircraft, engine or piece of airborne equipment has been developed with enough care to be trusted in flight. It is used by avionics software engineers, testers, quality engineers, certification specialists, project managers and the designees who sign off software on behalf of aviation authorities. After this tutorial you will be able to explain how DO-178C links software rigour to aircraft safety, read its structure, plan a compliant project and recognise what an authority expects to see before software is approved.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current edition is RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification, issued by RTCA on 13 December 2011 (prepared by RTCA Special Committee SC-205 jointly with EUROCAE Working Group WG-71). The technically equivalent European document is EUROCAE ED-12C, dated January 2012. Both are still the latest editions; RTCA has published errata against DO-178C and EUROCAE lists ED-12C as its latest version. There is no DO-178D. The joint committee that now looks after the aviation software documents (RTCA SC-240 with EUROCAE WG-117) is drafting an additional supplement on commercial off-the-shelf and open-source software, which is work in progress, not a revision of DO-178C. The US Federal Aviation Administration (FAA) recognises DO-178C through Advisory Circular AC 20-115D (21 July 2017), and the European Union Aviation Safety Agency (EASA) does the same through the harmonised AMC 20-115D. Verified 2026-10-29 against the RTCA store entry, the EUROCAE product page, the SC-240 terms of reference (revision 5, 2024) and an RTCA committee summary from March 2026, and the text of AC 20-115D.

Who it is for: software engineers, testers, team leads, quality and configuration managers, systems and safety engineers, project managers and buyers who are new to airborne software, including people moving into aerospace from automotive, rail, medical devices, defence or ordinary commercial software. It also suits people in drone and advanced air mobility start-ups.

Prerequisites: none. A basic idea of how software is specified, coded and tested helps. Every aviation and certification term is explained the first time it appears.

By the end of this tutorial:

You will be able to explain why airborne software needs development assurance and what DO-178C does and does not cover.
You will be able to define the core vocabulary: software level, objective, high-level and low-level requirements, derived requirements, traceability, structural coverage, independence, tool qualification and the main life cycle documents.
You will be able to describe how DO-178C is organised, from its process sections to the Annex A objective tables and its companion documents.
You will be able to walk through the life cycle a DO-178C project follows, from planning to the final accomplishment summary.
You will be able to explain how software is approved as part of an aircraft or equipment certification, who reviews it and what "compliance" really means.
You will be able to apply DO-178C to a realistic avionics product and spot the decisions that drive cost and risk.
You will be able to place DO-178C next to ARP4754B, ARP4761A, DO-254, DO-278A, DO-330, ISO 26262 and IEC 61508.

Lesson 1 – Origins, purpose and scope

Why aircraft software needs a special approach

A modern airliner carries millions of lines of software. It flies the aircraft through autopilot and fly-by-wire computers, controls the engines, manages fuel, displays flight data and controls brakes, doors and cabin pressure. When this software behaves wrongly at the wrong moment, the result can range from a small inconvenience to the loss of the aircraft.

Engineers have good tools for hardware reliability. A pump or a resistor fails at a rate that can be estimated from test data and field experience, and designers can add redundancy until the probability of a dangerous failure is acceptably low. Software does not fail that way. It does not wear out; it fails because of mistakes made when the requirements were written, when the design was chosen or when the code was typed. Those mistakes are present in every copy of the software from the first day and wait for a particular combination of inputs to reveal themselves. Testing alone cannot show that such mistakes are absent, because the number of possible input combinations in real software is far too large to try them all.

The aviation answer to this problem is development assurance: since you cannot measure the probability of a software error, you control how the software is built and checked, and you make the depth of that control proportional to how bad the consequences of an error could be. DO-178C is the document that describes this approach for airborne software. It does not tell you which programming language to use or which design to choose. It tells you which objectives your processes must achieve and what evidence you must produce to show that you achieved them.

A short history

RTCA, a US not-for-profit organisation that develops consensus standards for aviation, published the first DO-178 in 1982, followed by DO-178A in 1985 and DO-178B in 1992. DO-178B became the de facto worldwide basis for approving avionics software for almost twenty years. Over time, new techniques arrived that DO-178B did not address well: model-based development with tools such as Simulink and SCADE, object-oriented languages such as C++, formal mathematical proof and the qualification of complex tools. A joint RTCA and EUROCAE committee worked from 2005 to 2011 to update the guidance. The result was DO-178C, published together with a set of companion documents: a separate document for tool qualification and three technology supplements.

DO-178C deliberately kept the core philosophy of DO-178B. The main changes were clarifications, more consistent terminology, explicit treatment of parameter data (configuration tables loaded separately from the program), a few additional objectives and clearer links between objectives and activities. A team that understands DO-178B will recognise almost everything in DO-178C.

What DO-178C covers

DO-178C applies to software in airborne systems and equipment: software installed on aircraft, engines and propellers, or software in equipment approved under a Technical Standard Order (TSO), the FAA mechanism for approving standard articles such as radios or flight data recorders. It covers the software life cycle from planning to delivery, including the integration of the software with its target hardware, and it covers changes to software that is already in service.

It does not cover the safety assessment of the aircraft, the design of the system architecture, the design assurance of complex electronic hardware, ground systems such as air traffic management software, or cybersecurity. Those topics belong to neighbouring documents that you will meet in Lesson 7. DO-178C takes its most important input, the software level, from the system safety process and returns information to it, but it does not perform that safety analysis itself.

Guidance, not law

Another key point for beginners is the legal status. DO-178C is not a regulation. Aviation regulations (for example the airworthiness rules for large aeroplanes) require that systems perform their intended function and that failures are acceptably unlikely given their severity. Authorities then publish advisory material stating that DO-178C is an acceptable means of compliance for the software aspects of certification. The FAA does this in AC 20-115D and EASA in AMC 20-115D. An applicant may in principle propose another method, but in practice DO-178C is so widely accepted that almost every civil avionics programme uses it, and many military and space programmes reuse it too.

Figure 1 – Where DO-178C sits: the system safety process sets the software level, DO-178C and its companions shape the life cycle, and the resulting evidence supports certification of the aircraft or equipment.

Lesson 2 – Key concepts and vocabulary

DO-178C has its own vocabulary, and reviewers use the terms precisely.

Software level – the rigour category (A, B, C, D or E) assigned to a piece of software according to the worst effect its anomalous behaviour could have on the aircraft. People often call it the DAL (development assurance level).
Failure condition – an effect on the aircraft and its occupants caused by one or more failures or errors, classified by severity: catastrophic, hazardous (also called severe-major), major, minor or no safety effect.
Objective – a result that a process must achieve, such as "the code complies with the low-level requirements". DO-178C lists its objectives in the Annex A tables, and the software level decides which apply.
Activity – a task that is one way to meet an objective. Activities are described in the body of the document; the applicant may use other means if they meet the objective.
High-level requirements (HLR) – software requirements developed from the system requirements allocated to software. They describe what the software must do in terms the system engineer can check.
Low-level requirements (LLR) – requirements developed from the high-level requirements during design, detailed enough that source code can be written directly from them.
Software architecture – the structure chosen to implement the requirements: components, interfaces, data flow, control flow, partitioning and scheduling.
Derived requirement – a requirement produced during development that does not trace directly to a higher-level requirement, for example a rule about how a sensor value is filtered that the system specification never mentioned. Derived requirements must be passed back to the system safety process, because they may create behaviour nobody assessed.
Traceability – the documented links between system requirements, high-level requirements, low-level requirements, source code and tests, in both directions. DO-178C expects trace data as a life cycle output.
Verification – the technical evaluation of the outputs of each process, through reviews, analyses and tests. Verification asks "did we build it right, and does each output correctly reflect its input?".
Structural coverage analysis – an analysis that checks which parts of the code were exercised by requirements-based tests. The required depth depends on the level: statement coverage, decision coverage, or modified condition/decision coverage (MC/DC).
Independence – separation of responsibilities so that an activity is checked by a person (or tool) other than the one who produced the item. Some objectives must be met "with independence" at higher software levels.
Tool qualification – the process of gaining confidence in a tool whose output is not otherwise verified, when that tool eliminates, reduces or automates a DO-178C process. It is governed by DO-330.
Executable Object Code (EOC) – the binary form of the software that actually runs on the target computer. DO-178C cares about the EOC, not only the source code.
Parameter data item – a set of data, such as a configuration table, that influences the behaviour of the software without changing the executable object code and is managed as a separate configuration item.
Dead code and deactivated code – dead code is code that cannot be executed and does not trace to any requirement; it should be removed. Deactivated code is intentionally present (for example a function used only in another aircraft variant) and must be shown to be safely disabled where it is not used.
Software life cycle data – the plans, standards, requirements, design, code, verification records, configuration records and summaries that a project produces. This data is the evidence an authority reviews.

Software levels and failure conditions

The software level is the single most important number in a DO-178C project, because it decides how much work is required. The level comes from the system safety assessment, not from the software team. The safety engineers ask: if this software behaved anomalously, including in ways that contribute to a failure condition, what is the worst credible effect on the aircraft? The answer maps onto five levels:

Level A – anomalous behaviour could cause or contribute to a catastrophic failure condition, typically one that prevents continued safe flight and landing.
Level B – hazardous (severe-major) failure condition: a large reduction in safety margins, physical distress or excessive workload for the crew, or serious or fatal injuries to a small number of occupants.
Level C – major failure condition: a significant reduction in safety margins or functional capability, or a significant increase in crew workload.
Level D – minor failure condition: a slight reduction in safety margins or a slight increase in crew workload.
Level E – no effect on safety or crew workload. DO-178C objectives do not apply once Level E has been confirmed by the authority.

The number of applicable objectives grows with the level. Commonly quoted counts from the Annex A tables are 71 objectives for Level A, 69 for Level B, 62 for Level C and 26 for Level D, with a growing share to be met with independence (30, 18, 5 and 2 respectively). The numbers matter less than the pattern: Level A and B add deeper structural coverage, more independence, stricter checks of the low-level design and, for Level A, verification of any object code that does not trace directly to the source code.

Figure 2 – From severity to rigour: the system safety assessment classifies the worst effect, which fixes the software level; each step down means fewer objectives, less independence and lighter structural coverage.

A system can contain software at several levels. If a design can show that lower-level software cannot interfere with higher-level software, for example through partitioning provided by a certified real-time operating system that separates memory and processor time, each partition can be developed at its own level. Without such protection, all software that can affect a Level A function must be treated as Level A.

Lesson 3 – Structure of the standard

The main sections

DO-178C is organised by process. Paraphrased, its sections are:

Section 1 – Introduction: purpose, scope, how to read the document and the difference between objectives, activities and guidance.
Section 2 – System aspects relating to software development: how information flows between the system processes and the software processes, how the software level is determined, and architectural considerations such as partitioning, multiple-version dissimilar software and safety monitoring, plus topics such as user-modifiable and field-loadable software.
Section 3 – Software life cycle: the processes, how they can be arranged into a life cycle model (waterfall, incremental, iterative) and the transition criteria that decide when a process may start.
Section 4 – Software planning process: the plans and standards a project must produce before serious development begins.
Section 5 – Software development processes: requirements, design, coding and integration.
Section 6 – Software verification process: reviews, analyses, testing, structural coverage and the verification of the verification itself.
Section 7 – Software configuration management process: identification, baselines, change control, problem reporting, archiving and the control categories for data.
Section 8 – Software quality assurance process: independent assurance that the plans and standards are followed and that the product conforms.
Section 9 – Certification liaison process: communication with the authority, the data submitted, and the type design data.
Section 10 – Overview of certification: a short description of how aircraft and engine certification works and where software fits.
Section 11 – Software life cycle data: the content expected in each plan, standard, specification, record and summary.
Section 12 – Additional considerations: previously developed software, tool qualification, and alternative methods such as product service history, exhaustive input testing and dissimilar software.

After the sections come Annex A, the objective tables; Annex B, the glossary; and appendices with background and committee information.

The Annex A tables

Practitioners spend most of their time with Annex A. Each table lists objectives for one process, with columns showing for each software level whether the objective applies, whether it must be met with independence, which section describes it and which life cycle data provides the evidence. The ten tables cover:

A-1: software planning process.
A-2: software development processes.
A-3: verification of the outputs of the software requirements process (the high-level requirements).
A-4: verification of the outputs of the design process (low-level requirements and architecture).
A-5: verification of the outputs of the coding and integration processes.
A-6: testing of the outputs of the integration process (the executable object code).
A-7: verification of the verification process results (test coverage of requirements, structural coverage and related analyses).
A-8: software configuration management process.
A-9: software quality assurance process.
A-10: certification liaison process.

Annex A also records, for configuration management purposes, whether each item of data must be controlled under the stricter control category (CC1, which requires full problem reporting and change control) or the lighter one (CC2, which requires identification, protection and retrieval but not the full change process).

The companion documents

DO-178C is never read alone on a modern project. The "DO-178C family" published in December 2011 includes:

DO-330 (ED-215) – Software Tool Qualification Considerations. A standalone document that describes how to qualify tools at five tool qualification levels (TQL-1 to TQL-5). It can also be used outside aviation.
DO-331 (ED-218) – the Model-Based Development and Verification supplement, for projects that use models as requirements or design and possibly generate code from them.
DO-332 (ED-217) – the Object-Oriented Technology and Related Techniques supplement, covering inheritance, polymorphism, dynamic memory, exceptions and similar features.
DO-333 (ED-216) – the Formal Methods supplement, explaining when mathematical proof can replace some reviews, analyses and tests.
DO-248C (ED-94C) – Supporting Information: frequently asked questions and discussion papers that explain the rationale behind the guidance. It is informative, not a source of extra objectives.

A supplement is not a standalone document: it adds, modifies or replaces specific objectives and activities of DO-178C for the technique it covers. A project that uses Simulink models with object-oriented generated code would apply DO-178C plus both DO-331 and DO-332, and its planning documents must explain which objectives come from which document.

Lesson 4 – How it works in practice

Processes and life cycle

DO-178C describes three groups of processes. The planning process defines and coordinates the work. The development processes produce the software: requirements, design, coding and integration. The integral processes run throughout and check, control and communicate: verification, configuration management, quality assurance and certification liaison. DO-178C does not impose a waterfall. Teams may use iterative or incremental models, including agile sprints, provided that each process has defined transition criteria and the final evidence is complete and consistent for the released configuration.

Figure 3 – The DO-178C life cycle: planning first, four development processes in sequence or iteration, and four integral processes that check, control and communicate throughout.

Step 1 – Planning

Planning comes first because reviewers judge a project against its own plans. DO-178C expects five plans:

Plan for Software Aspects of Certification (PSAC) – the primary agreement with the authority. It summarises the system, the software, its level, the life cycle, the data to be produced, the tools to be qualified, any supplements used, any previously developed software and any alternative methods.
Software Development Plan (SDP) – how requirements, design, code and integration will be produced, with which methods, languages and environments.
Software Verification Plan (SVP) – how reviews, analyses and tests will meet the verification objectives, including independence and coverage.
Software Configuration Management Plan (SCMP) – how items are identified, baselined, changed, archived and released.
Software Quality Assurance Plan (SQAP) – how the quality assurance function audits processes and products and takes part in conformity reviews.

Alongside the plans, the project writes three standards: software requirements standards (how to write and structure requirements), software design standards (design rules, complexity limits, permitted constructs) and software code standards (language subset, naming, prohibited features).

Step 2 – Requirements, design and code

The requirements process turns system requirements allocated to software into high-level requirements. Each must be accurate, unambiguous, verifiable, consistent and traceable. Derived high-level requirements are flagged and sent to the safety assessment. The design process produces the architecture and the low-level requirements, again flagging derived requirements. The coding process implements the low-level requirements in source code according to the code standards. The integration process compiles, links and loads the code onto the target computer to create the executable object code, along with any parameter data item files.

Throughout, the team keeps trace data. A typical tool chain links each requirement to its parent, each code unit to the low-level requirements it implements, and each test case to the requirements it verifies. Trace data allows two important checks: that every requirement is implemented and tested, and that no code exists without a requirement.

Step 3 – Verification

Verification is the largest part of a DO-178C budget, often more than half of the effort. It combines three methods:

Reviews – qualitative assessments using checklists, for example checking that each low-level requirement is consistent with its high-level parent and complies with the design standards.
Analyses – detailed, repeatable examinations, such as worst-case execution time analysis, stack usage analysis, data coupling and control coupling analysis, or structural coverage analysis.
Testing – executing the software to show it meets its requirements and does not do anything it should not.

Testing in DO-178C is requirements-based. You do not write tests to exercise code; you write tests to show that requirements are met, under normal-range inputs and under abnormal inputs (robustness tests). Tests are run at three levels: hardware/software integration testing on the real target, software integration testing of components working together, and low-level testing of individual units against their low-level requirements. Where possible, testing on the target computer is preferred, because the compiler, processor and memory can all introduce behaviour that host-based testing hides.

Once tests have run, the team checks whether testing was thorough enough. Requirements coverage analysis confirms that every requirement has tests. Structural coverage analysis then measures which code the requirements-based tests actually executed. At Level C, every statement must be executed. At Level B, every decision must also take both its true and false outcomes. At Level A, MC/DC is required: each condition within a decision must be shown to affect the decision's outcome independently. Coverage gaps are not fixed by writing extra tests aimed at the uncovered lines. Instead, each gap is analysed: it may reveal a missing requirement, an inadequate test, dead code to be removed, or deactivated code to be justified.

Figure 4 – Traceability and verification: requirements flow down to executable code, requirements-based tests trace back to them, and coverage analysis exposes gaps that must be resolved.

Step 4 – Configuration management and quality assurance

Configuration management makes the evidence trustworthy. Every item of life cycle data is identified and versioned; baselines are established; every change goes through problem reporting and change control; and the exact configuration of the released software, its source and its build environment can be reproduced years later. Two indexes record this: the Software Configuration Index (SCI) lists the product's components and data, and the Software Life Cycle Environment Configuration Index (SLECI) lists the compilers, tools and test environments used.

Quality assurance provides an independent view. QA engineers audit whether the team actually follows its plans and standards, check that transition criteria are met, take part in the software conformity review at the end of the project and record their findings. QA in DO-178C is about process assurance, not testing.

Step 5 – Certification liaison and closing out

The certification liaison process keeps the authority informed. The PSAC is submitted early and should be agreed before significant work proceeds. During the project the authority, or a designee acting for it, reviews the work. At the end, the project submits the Software Accomplishment Summary (SAS), which states compliance with the PSAC, records any deviations, lists the open problem reports with an assessment of their safety impact, and refers to the SCI. Together with the PSAC and the SCI, the SAS forms the core of what the authority receives.

Tool qualification

Tools are everywhere in a modern project: code generators, compilers, static analysers, coverage tools, test frameworks, requirements management tools. DO-178C only requires qualification when a tool's output is used to eliminate, reduce or automate a DO-178C process and that output is not itself verified. A compiler, for example, usually needs no qualification because its output (the executable object code) is fully verified by testing. A coverage tool whose report is accepted without manual checking does need qualification.

The required tool qualification level depends on two things. First, the tool's potential impact, expressed as three criteria: Criterion 1 tools could insert an error into the airborne software (such as an automatic code generator); Criterion 2 tools could fail to detect an error and are also used to justify reducing other development or verification activities; Criterion 3 tools could fail to detect an error. Second, the software level. A Criterion 1 tool used on Level A software needs TQL-1, the most demanding level, while a Criterion 3 tool needs TQL-5 at every software level. DO-330 then defines objectives for each TQL, much as DO-178C does for each software level.

Figure 5 – Deciding whether a tool needs qualification and at which level: impact on the software and the software level together set the tool qualification level.

Previously developed and commercial software

Few projects start from nothing. They reuse code from older programmes, buy a real-time operating system, or use libraries. DO-178C calls such code previously developed software. The project must decide what evidence exists and what gaps remain: software developed to an earlier DO-178 version may be acceptable, depending on its level and the change; commercial software usually needs supplier data packages or additional verification by the integrator. For operating systems and libraries, many suppliers sell "certification kits" containing DO-178C data, but the applicant remains responsible for showing that the component meets the objectives in its own installation.

Lesson 5 – Assessment, certification and compliance

Software is approved, not certified on its own

A common beginner's question is "how do I get my software DO-178C certified?". The honest answer is that there is no such thing as a standalone DO-178C software certificate. Authorities approve aircraft, engines, propellers and TSO articles. The software is approved as part of that product, through a type certificate (TC), a supplemental type certificate (STC) for a modification, an amended type certificate, or a TSO authorisation for equipment. DO-178C compliance is the evidence that the software aspects of that product meet the regulations.

Likewise, there is no DO-178C certification for companies or for individual engineers. Training providers offer courses and personal certificates, but they are private attestations of training, not authority approvals. Tool vendors may say a tool is "qualifiable" or provide a qualification kit; the qualification itself happens within a specific project, under that project's PSAC.

Who reviews and how

In the United States the FAA's Aircraft Certification Service reviews software, often through delegated individuals called Designated Engineering Representatives (DERs) or through units within an Organization Designation Authorization (ODA) at the manufacturer. In Europe EASA works with approved design organisations, which have their own internal compliance verification. Other authorities, such as Transport Canada, apply the same documents within their own processes.

FAA Order 8110.49A describes the software review process: the authority may review life cycle processes and data, on site or as desk reviews, and decides its level of involvement based on the software level, the product's complexity and novelty, the applicant's experience and the availability of designees. In practice, most projects organise these reviews around four milestones, often called stages of involvement (SOIs), a pattern inherited from earlier FAA guidance and still widely used:

Stage	Typical timing	What the reviewer looks at
SOI 1 – Planning	Plans and standards complete	PSAC, other plans, standards, tool qualification approach, supplements used
SOI 2 – Development	A meaningful part of requirements, design and code exists	Requirements, design, code, trace data, adherence to standards
SOI 3 – Verification	A meaningful part of verification is done	Test cases, procedures, results, coverage analysis, review records
SOI 4 – Final	Software ready for approval	SAS, SCI, open problem reports, conformity review, final baseline

A review results in findings (non-compliances that must be corrected), observations and actions. Reviewers sample: they pick a function, follow its trace from system requirement to test result, and check that every link holds. One broken chain can lead to a request to re-examine much more.

What "compliant" means

Compliance means that every objective applicable to the software level is satisfied, with independence where required, that the life cycle data exists and is consistent with the released software, and that the authority has accepted the plans and the summary. AC 20-115D adds a few points in its own words: you must satisfy all objectives for the assigned level (including those of any supplement you use), submit the PSAC, SCI and SAS, and make other life cycle data available on request. It also says that for Level D, design description and source code are not part of the type design data.

Other related guidance applies to specific topics. FAA AC 20-193 and EASA AMC 20-193 cover multi-core processors; AC 00-69 shares best practices that complement DO-178C. Authorities can also raise project-specific issue papers (FAA) or certification review items (EASA) when a project uses novel technology, such as machine learning, that the published guidance does not yet address well.

Changes after approval

Software in service changes for bug fixes, new features and hardware obsolescence. A change goes through change impact analysis, re-verification of affected items and regression testing, an updated SCI and SAS, and approval as part of the modified product. AC 20-115D also explains how to handle changes to legacy software that was approved under DO-178, DO-178A or DO-178B, and when existing DO-178B processes may still be used for new work.

Lesson 6 – Worked example: an engine vibration monitoring unit

This example is fictional. Kestrel Avionics, a mid-sized supplier, wins a contract to develop the software for an engine vibration monitoring unit (EVMU) on a new business jet. The unit reads accelerometers on each engine, computes vibration levels, displays them to the crew and raises an alert when vibration exceeds limits.

Step 1 – Getting the level

Kestrel's software team does not choose the level. The aircraft manufacturer's safety assessment considers the failure conditions. Loss of vibration indication is judged minor, because crews have other cues. Misleading high vibration that could cause a crew to shut down a healthy engine on a twin-engine aircraft is judged major. The manufacturer allocates Level C to the EVMU software and records this in the system requirements. Kestrel notes that if the function were later used to command automatic engine actions, the level could rise.

Step 2 – Planning

Kestrel writes its PSAC, SDP, SVP, SCMP and SQAP, plus requirements, design and code standards. The code standard adopts a C language subset based on MISRA C with project additions such as a ban on dynamic memory after start-up. The PSAC explains that a commercial real-time operating system with a vendor data package will be used, that a static analysis tool will be used for information only (not for certification credit, so no qualification), and that a structural coverage tool will be used for credit. The coverage tool could fail to detect a gap but does not insert code, so Kestrel classifies it as Criterion 3 and plans TQL-5 qualification under DO-330. The plans go through Kestrel's internal reviews and then to the manufacturer and the authority's designee for SOI 1, which raises two findings: the PSAC does not explain how the operating system's parameter tables will be verified, and the transition criteria between design and coding are vague. Kestrel fixes both before proceeding.

Step 3 – Requirements and design

The engineers write 180 high-level requirements from the system specification. One system requirement says the unit must alert the crew when vibration exceeds a defined limit; the engineers add a derived requirement that the alert must persist for at least two seconds to avoid nuisance alerts caused by turbulence. Because this persistence filter is a derived requirement, it goes back to the manufacturer's safety team, who confirm that a two-second delay is acceptable. Without that feedback loop, the filter could have hidden a real event no one had assessed.

The design produces an architecture with input sampling, digital filtering, threshold logic and display output, plus around 600 low-level requirements. Trace data links each low-level requirement to its parent. At Level C, the verification of low-level requirements must check, among other things, that they comply with the high-level requirements and are traceable to them; Kestrel uses review checklists derived from Annex A tables A-3 and A-4.

Step 4 – Code, integration and verification

Developers write the code against the low-level requirements and run the static analyser nightly in their continuous integration pipeline. Code reviews check compliance with low-level requirements and the code standard. The build produces the executable object code and a separate parameter data item file with engine-specific vibration limits, so that the same binary can serve two engine variants.

The test team, separate from the developers, writes requirements-based test cases. For the threshold logic they test normal values below, at and above the limit, plus robustness cases: a disconnected sensor, an out-of-range reading, a value that oscillates around the limit. Hardware/software integration tests run on the real EVMU hardware in a test rig; low-level tests run on a target-representative board.

The coverage tool shows 96 % statement coverage after the first full test run. The team analyses each uncovered statement. Some lines belong to an error handler for a sensor fault that no requirement mentions; the team adds a missing low-level requirement and its test. A block of diagnostic code used only in the factory is deactivated in flight; the team documents how it is disabled and verifies that mechanism. Two lines turn out to be dead code left from a prototype and are removed. Statement coverage then reaches 100 %, and the analysis records how each gap was resolved.

Step 5 – Control, assurance and liaison

Every test run is tied to a baseline in the configuration management system. Problem reports are raised for each defect found by testing and reviews, and each is classified for safety impact. QA audits a sample of reviews and finds that two reviews were signed off without the required checklist; the team repeats them. The designee holds SOI 2 and SOI 3 reviews, sampling five requirements end to end. A finding at SOI 3 reveals that the parameter data item had been tested only with one engine variant's values; Kestrel adds tests for the second variant.

Step 6 – Approval and a later change

At the end, Kestrel produces the SCI, the SLECI and the SAS. The SAS lists three open problem reports, all cosmetic display issues judged to have no safety impact, with justification. After SOI 4, the software is approved as part of the aircraft's type certification.

Two years later, the manufacturer wants the EVMU to automatically reduce the engine's power if vibration becomes extreme. This new function changes the failure conditions: an incorrect automatic action could be hazardous. The safety assessment raises part of the software to Level B. Kestrel's change impact analysis shows that the affected components need decision coverage and more objectives met with independence, and that the coverage tool's qualification must now cover decision coverage measurement (a Criterion 3 tool stays at TQL-5 at Level B). The team can either partition the new function from the existing Level C code or raise all of it to Level B; it chooses partitioning, because that limits the re-verification effort. The software level is a consequence of how the software is used, not a label applied once.

Lesson 7 – Relationship to other standards and frameworks

DO-178C is one piece of a family of aviation documents and has cousins in other industries. Knowing the neighbours helps you understand what DO-178C deliberately leaves out.

Document	Scope	Relationship to DO-178C
SAE ARP4754B (2023)	Development of civil aircraft and systems	Sets system development assurance and allocates assurance levels to items, including software; DO-178C takes over at the software level. FAA AC 20-174 recognises the earlier revision A.
SAE ARP4761A (2023)	Safety assessment methods (functional hazard assessment, fault trees, and so on)	Classifies failure conditions that drive the software level; receives derived requirements back from DO-178C projects.
RTCA DO-254 / EUROCAE ED-80	Design assurance for complex airborne electronic hardware (FPGAs, ASICs)	The hardware counterpart, with the same A–E levels; programmable logic is handled here, not in DO-178C.
RTCA DO-278A / EUROCAE ED-109A	Software in ground-based communication, navigation, surveillance and air traffic management systems	A sister document derived from DO-178C, using six assurance levels (AL1 to AL6) instead of A–E.
RTCA DO-330 / EUROCAE ED-215	Tool qualification	Companion document used whenever a tool needs qualification under DO-178C or DO-278A.
RTCA DO-326A / EUROCAE ED-202A	Airworthiness security process	Addresses intentional unauthorised electronic interaction; DO-178C does not cover cybersecurity.
ISO 26262	Functional safety of road vehicles	Similar ideas (integrity levels ASIL A–D, requirements traceability, tool confidence) but a different structure, terminology and certification model.
IEC 61508	Generic functional safety of electrical, electronic and programmable systems	Uses probabilistic safety integrity levels (SIL 1–4) and technique tables; parent of many sector standards, but not used for civil aircraft approval.

How the aviation documents fit together

Think of three layers. At the aircraft and system layer, ARP4754B describes how the aircraft functions are developed and allocated to systems and items, and ARP4761A describes how safety is assessed. At the item layer, DO-178C handles software and DO-254 handles complex hardware. Across both, DO-330 governs tools, and DO-326A covers security. When multiple processors or integrated modular avionics are involved, further guidance (such as A(M)C 20-193 for multi-core processors, or DO-297 for integrated modular avionics) adds requirements on top of DO-178C.

Comparison with automotive and rail

Engineers moving between industries notice familiar ideas: integrity levels decided by risk, traceability, independent verification, controlled tools. The differences are in emphasis. ISO 26262 allows the supplier and car maker to assess conformity largely through their own functional safety assessment, while DO-178C evidence is reviewed by or on behalf of an aviation authority before a product enters service. DO-178C is very specific about structural coverage criteria and the requirements-based nature of testing, while IEC 61508 and its derivatives use tables of recommended techniques that a project selects and justifies.

DO-178C in other domains

Because it is mature and well understood, DO-178C is often reused outside civil aviation: in military aircraft programmes, in some space programmes, and increasingly in drones and electric vertical take-off and landing aircraft. In those settings it may be tailored by contract. EASA and industry working groups are also developing guidance on machine learning in airborne systems; this is an evolving topic, and current DO-178C does not provide a complete answer for software whose behaviour is learned from data rather than specified by requirements.

Common pitfalls and best practices

Common pitfalls:

Treating DO-178C as a documentation exercise. Teams write the code first and produce requirements and tests later to "fill in" the paperwork. Reviewers notice reverse-engineered requirements immediately, and the result is costly rework.
Writing tests to cover code rather than requirements. Tests designed only to raise coverage hide missing requirements and give false confidence.
Ignoring derived requirements. Failing to feed them back to the safety assessment leaves behaviour unassessed and can invalidate the software level.
Late planning or late contact with the authority. Starting development before the PSAC is agreed often means rework when the authority disagrees with the approach.
Forgetting tools. Using a tool's output for credit without qualifying it, or assuming that a vendor's "certified" label removes the need for project qualification.
Weak configuration management. Evidence that cannot be tied to the exact released baseline is not evidence.
Underestimating the level's cost. Level A requires MC/DC, more independence and object-code analysis; budgets based on Level C experience fail.

Best practices:

Plan early and agree the PSAC with the authority or designee before significant development, including supplements, tools and any reuse.
Invest in good requirements. Clear, verifiable, atomic requirements make testing, tracing and review far cheaper.
Automate traceability, testing and coverage in a continuous integration pipeline, and qualify the tools whose output you rely on.
Design for partitioning to keep high-level software small, so that the most expensive objectives apply to as little code as possible.
Analyse every coverage gap instead of patching it with tests; each gap is information about requirements, tests or code.
Keep QA independent and active throughout the project, not only at the final conformity review.
Build a reusable process: approved plans, standards, checklists and tool qualification packages that carry from project to project.

Summary and key takeaways

DO-178C (with its European twin ED-12C) is the guidance that aviation authorities accept for showing that airborne software was developed with assurance appropriate to its safety impact; it is published by RTCA and was issued in December 2011, and it remains current.
Because software errors cannot be quantified like hardware failures, DO-178C controls the development process through objectives and evidence, scaled by software level.
The software level (A to E) comes from the system safety assessment and drives the number of objectives, the independence and the structural coverage required.
The life cycle consists of planning, four development processes and four integral processes, with traceability tying requirements to code and tests.
Testing is requirements-based, and coverage analysis checks the thoroughness of testing rather than replacing it.
DO-330 and the three technology supplements extend DO-178C for tools, models, object-oriented techniques and formal methods.
Software is approved as part of an aircraft, engine or TSO article; there is no standalone DO-178C certificate for software, companies or people.
DO-178C sits in a family of documents alongside ARP4754B, ARP4761A, DO-254, DO-278A and DO-326A, each covering what the others leave out.

Reflection questions

Think of a software function you know well (in any industry). If it were airborne software, what failure conditions could it contribute to, and which software level would you expect? What would change if it were used differently?
Your team uses two-week sprints. How would you organise planning, transition criteria, verification and configuration management so that the DO-178C evidence is complete for each release?
List the tools in a project you have worked on. Which of them would need qualification under DO-178C, which criterion would apply, and why?
A coverage report shows uncovered code in an error-handling function. Describe how you would analyse the gap and what different outcomes the analysis could have.
Compare DO-178C with a standard from your own industry. Which concepts map closely, which differ, and what would surprise an engineer moving between the two?