DO-178C/ED-12C (henceforth DO-178C) is the primary document referenced by certification authorities including the Federal Aviation Administration (FAA), European Union Aviation Safety Agency (EASA) and Transport Canada to approve all commercial software-based civil aviation avionics systems. The document is jointly published by RTCA (formerly the Radio Technical Committee for Aeronautics) and the European Organisation for Civil Aviation Equipment (EUROCAE).
The video below is an introduction to DO-178C “Software Considerations in Airborne Systems and Equipment Certification” – what it is, where it fits into the aviation certification framework, how to work with it, and when its supplementary documents are applied.
DO-178C recognizes that to ensure correctness, control and confidence in software, functional safety must be addressed systematically throughout the software development life cycle.
DO-178C is a formal process standard that covers the complete software lifecycle – the planning process, development process, and integral processes – to ensure correctness and robustness in software developed for civil avionics systems. The integral processes include software verification activities, software quality assurance, configuration management assurance and certification liaison with the regulatory authorities. Increasingly, standards developed for civil avionics systems including DO-178C have also become recognized as best practice in the defense sector.
In January 2012 DO-178C replaced the long-standing DO-178B standard as the de facto reference for the development of embedded software in the civil aviation sector. Its introduction improved safety requirements and the accommodation of new technologies for development and verification activities in civil avionics systems.
While DO-178B is still recognized and can be used for legacy projects, new projects are strongly encouraged to use DO-178C. The FAA recommends that new applicants or developers establish their software life cycle processes in accordance with DO-178C.
LDRA has participated extensively on both the DO-178B and DO-178C committees over nearly two decades. Mike Hennell, LDRA’s CEO, was instrumental in the inclusion of several test measurement objectives in the standard, including those relating to structural coverage analysis. The LDRA tool suite® was itself a forerunner in automated verification for certification to DO-178B.
There are several standards and other documents that are intended to be used as a collective in the development of software systems that are applicable to civil avionics systems.
DO-178C certification standards framework diagram for aerospace software systems Comprehensive DO-178C aviation certification standards hierarchy showing relationships between airborne software guidelines and related standards for aircraft systems development
SAE ARP4754 Guidelines for Development of Civil Aircraft and Systems.
ARP 4754 provides the overarching framework for system development, while DO-178C provides specific guidance for the development and certification of software within that system. Together, the two documents help ensure that the entire airborne system, including its software components, meets the necessary safety and reliability standards for certification in the aerospace industry.
SAE ARP4761 Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment.
ARP 4761 provides guidance on conducting safety assessments for the systems that are developed in accordance with ARP4754. In turn, ARP 4754 provides the overarching framework for system development, while DO-178C provides specific guidance for the development and certification of software within that system.
RTCA DO-278A Guidelines for communication, navigation, surveillance and air traffic management (CNS/ATM) system software integrity assurance.
DO-278A serves a similar purpose for ground-based systems to that served by DO-178C for airborne systems and was developed in parallel to it. As a result, around 75% of it is similar.
RTCA DO-330 Software tool qualifications considerations.
“Tool qualification” is a generic term to describe a process designed to ensure that the risk of a tool error impacting the safety of a system is acceptably low – either because the errors are few, or because they cannot impact safety. DO-330 provides guidance in the achievement of DO-178C tool qualification and DO-278C tool qualification for tools to be used in the pursuit of compliance with those documents. It is also designed for use in other domains unlike the other supplementary documents DO-332 and DO-333.
The LDRA tool suite can be qualified seamlessly through the application of Tool Qualification Support Packages (TQSPs). Each TQSP module provides artifacts and guidance to simplify the process of qualifying the LDRA tool suite for use as a verification tool in a project-specific environment.
RTCA DO-331 Model-Based Development and Verification Supplement to DO-178C and DO-278A.
DO-331 is supplementary to DO-178C and DO-278A. It provides guidance for integrating Model-Based Development (MBD) into the prescribed certification processes.
The LDRA tool suite supports the verification of both automatically generated code from models, and any supplementary hand-written code. It integrates with other model-based development tools from partner organisations to provide a seamless workflow for developing and verifying safety-critical software.
RTCA DO-332 “Object Oriented Technology and related technologies supplement to DO-178C and DO-278A”.
DO-332 is supplementary to DO-178C and DO-278A and includes additional objectives that apply when using object-oriented programming and complementary practices. It also provides advice on how the objectives in DO-178C should be approached in the Object Oriented (OO) environment.
The LDRA tool suite underpins DO-332 compliance both through its comprehensive support for C++ and through other tool attributes that are equally applicable to all languages.
RTCA DO-333 “Formal Methods Supplement to DO-178C and DO-278A”.
DO-333 is supplementary to DO-178C and DO-278A and identifies additional objectives that apply when using formal methods as part of a software life cycle. It also provides advice on how the objectives in DO-178C should be approached when formal methods are being applied.
RTCA DO-200 “Standards for Processing Aeronautical Data”.
DO-200 establishes the essential criteria and recommendations for handling aeronautical data applied in navigation, flight planning, terrain/obstacle awareness, flight deck displays, flight simulators, and various applications. It outlines the requirements for developing, evaluating changes, and supporting the implementation of data quality management. The standard covers aeronautical databases and the related data processing, which may interface directly with DO-178C compliant applications utilized in airborne aviation products.
A(M)C 20-193 “Use of Multi-Core Processors”.
CAST-32A was a position paper relating to multicore processors (MCPs), written by the Certification Authorities Software Team (CAST). Multicore processors are a relatively new challenge in the world of civil aviation, and this paper describes a set of objectives to be fulfilled when such devices are selected for use in a DO-178C compliant project. Although CAST papers do not represent official guidance, they are authoritative, and their advice is often adopted even before it is formally integrated into subsequent published standards.
CAST-32A has been deprecated for projects under the jurisdiction of EASA and the FAA. Its recommendations relating to multicore processors are incorporated in the harmonized standards EASA AMC 20-193 and FAA AC 20-193 known collectively as A(M)C 20-193. The advice and guidance in these documents are designed to be supplemental to DO-178C and other related standards such as DO‑278A.
The LDRA tool suite supports the use of MCPs which brings a host of challenges associated with interference paths and their potential impact on worst-case execution timing (WCET).
DAL is an abbreviation for Design Assurance Level, sometimes referred to a simply a Level. The ARP 4754A standard dictates that functional hazard analyses and system safety assessments are completed prior to a system’s development.
A Design Assurance Level (DAL) is assigned accordingly for that system, and for the subsystems that implement its hardware and software requirements. The DO-178C standard then provides detailed guidance for the development and verification of safety critical airborne software systems in accordance with the assigned DAL, such that the effort and expense of producing such as a flight control system is necessarily higher than that required to produce (say) a bathroom smoke detector.
DO-178C covers the complete software lifecycle: the planning process, development process and integral processes to ensure correctness and robustness in the software. The integral processes include software verification activities, software quality assurance, configuration management assurance and certification liaison with the regulatory authorities.
DO-178C recognizes that software safety must be addressed systematically throughout the software life cycle. This involves life cycle traceability, software design, coding, validation and verification processes used to ensure correctness, control and confidence in the software. Several mechanisms are defined to help ensure that the processes are adhered to, and to provide evidence of that adherence.
Collectively, the planning documents specified in DO-178C provide a comprehensive framework for the development and certification of airborne software. They are intended to ensure that all activities are planned, controlled, and verified according to requirements, as follows:
There are four Stage of Involvement (SOI) reviews specified by DO-178C. These are designed to ensure that software development processes and outputs adhere to the document’s stringent requirements. Certification authority representatives such as FAA Designated Engineering Representatives (DERs) and EASA Subject Matter Experts (SMEs) police the DO-178C process particularly through their involvement with SOI audits. The SOI reviews provide structured checkpoints at various phases of the software development life cycle, ensuring a disciplined and methodical approach to achieving compliance with DO‑178C.
The Software Accomplishment Summary is a comprehensive document that encapsulates all the steps taken during the DO‑178C software development and verification processes. It includes a recap of the software development activities, a summary of the verification results, and findings from the qualification of verification tools.
DO-178C Section 5.0 outlines the key processes involved in software development for airborne systems. It includes the Software Requirements Process (5.1), Software Design Process (5.2), Software Coding Process (5.3), Integration Process (5.4), and Software Development Process Traceability (5.5).
Tools used for requirements management (Section 5.1) vary from simple spreadsheets and Microsoft Word documents to Application Lifecycle Management (ALM) and Product Lifecycle Management (PLM) tools.
Section 5.3 specifies obligatory software coding process objectives, such as the implementation of low-level requirements and the conformance to a language subset (or “coding standard”). LDRA’s static analysis tools make compliance checking easier, less error prone and more cost effective than manual techniques by parsing the code under review with reference to the rules dictated by standard. Non-conformances are highlighted, the complexity of the code under review assessed, and data flow analysis completed to identify any uninitialized or unused variables and/or constants.
Section 5.5 mandates that artefacts are generated to show that each development phase is complete, coherent, and traceable to its predecessor. The use of the TBmanager component of the LDRA tool suite helps to address the inherent project management challenges.
DO-178C Section 6.0 focuses on the software verification processes. It outlines the objectives and methods for verifying that the software meets its requirements and functions correctly. This includes reviews, analyses, and testing at various levels, such as low-level testing, software integration testing, and hardware/software integration.
Dynamic analysis involves using “test cases and procedures” (DO-178C Section 6) to exercise Executable Object Code (EOC), on a target representative of that to be deployed in the field. It provides evidence of both correct functionality and of the parts of the code exercised to achieve it (“structural coverage”). The “test cases and procedures” can include any combination of low-level tests (sometimes referred to as unit tests), integration tests, and system tests.
Low-level tests verify the complete and exclusive implementation of the low-level requirements specified in the Software Verification Plan (SVP), whereas software integration testing verifies the relationships between software components with reference to the requirements and the software architecture. In practice, the mechanisms used for low-level testing often lend themselves to integration testing and hence verify behaviour in the context of a call tree.
Whenever changes are made, all impacted low-level and integration tests need to be re-run (“regression tested”). Regression tests can be re-applied as development progresses to ensure that existing functionality is not compromised by new development.
Structural coverage analysis provides evidence that requirements-based tests have thoroughly exercised the code. By measuring which parts of the software structure have been executed during testing, it supports both compliance and safety assurance. The level of coverage required varies by Design Assurance Level (DAL):
The blog post “DO-178C & Structural Coverage Analysis” explains the principles involved in more detail.
Collating structural coverage involves instrumenting the source code and executing it with tests derived from high-level and, where necessary, low-level requirements. This process helps identify untested code, incorrect requirements, or the presence of dead code. The visualization features offered by the LDRA tool suite assist in interpreting and acting on coverage data, making the verification process more efficient.
For DAL A software, the DO-178C requires the analysis of any additional object code that isn’t directly traceable to the original source to ensure that it provides a reliable interpretation of the programmers’ intentions. Object Code Verification (OCV) provides a systematic way to address this challenge by comparing source and assembly-level coverage. When supported by appropriate tooling, this multi-layered approach not only streamlines compliance but also enhances confidence in the reliability and determinism of the final software product.
Structural coverage is not just a metric—it is a process that reinforces the integrity of airborne software through disciplined testing, detailed traceability, and targeted verification activities aligned with the rigor expected of compliant systems.
Modularization—organizing software into well-defined functional units with clear interfaces—has long been a foundational software engineering principle. In the context DO-178C this principle is not only a design best practice but a regulatory expectation, and the interactions between software components—specifically data and control coupling—are subject to rigorous scrutiny.
DO-178C places a heightened emphasis on verifying these couplings compared to its predecessor, DO-178B. Section 6.4.4.2.c now stipulates the need for “analysis to confirm that the requirements-based testing has exercised the data and control coupling between code components”, marking a shift from a primarily design-level analysis to a focus on empirical evidence gathered from actual test execution.
Data Coupling & Control Coupling (DCCC) are different but related characteristics of software code.
Control coupling is defined by DO-178C as “The manner or degree by which one software component influences the execution of another software component”. Procedure/functional call coverage must be derived from the execution of requirements based tests to identify any gaps and guide targeted verification activities.
Structural coverage analysis supports these activities to help meet the associated objective A-7.8.
Data coupling is defined in the standard as “The dependence of a software component on data not exclusively under the control of that software component”. Objective A-7.8 requires that “Test coverage of software structure, both data and control coupling, is achieved”. Any dataflow measurements must be derived from requirements based tests.
The DO-178C standard (particularly sections 5.0 and 6.0) calls for phased development with the application of verification and validation techniques along the way to confirm compliance. LDRA validation and verification tools (exemplified by the LDRA tool suite) lend themselves to integration with third party development tools, providing a seamless platform for compliant application development.
LDRA tools perform static analysis on the code in accordance with DO-178C’s recommended practices. Static analysis can be likened to an automated “inspection” of the source code, comparing the code under review with the chosen software coding standard and deriving code quality metrics.- Non-conformances are highlighted as required by DO-178C, along with other undesirable characteristics such as high complexity.
The use of LDRA tools’ dynamic analysis capabilities involves the execution of some or all of the code as part of low-level (unit) test, integration test, and system test. The objective here is to show that it has been exercised sufficiently and that it behaves in accordance with requirements. The on-target, dynamic test capabilities are particularly important in demonstrating that the code is appropriate for its target environment.
Structural coverage is used to identify which code structures and component interfaces have been exercised during the execution of requirements-based test procedures, facilitating the empirical measurement of requirements-based test effectiveness. As the name implies, structural coverage analysis involves the scrutiny of the structural coverage to determine if there are any parts of the code which have not been sufficiently exercised, and if not, why. The level of coverage required is proportionate to the Design Assurance Level (DAL) of the software under development.
The optional TBjustify module can be specified to manage the documentation of justifications concerning coverage for certification and compliance purposes.
Real-time critical systems demand quick decision-making processes. They deploy closed-loop control, allowing only a tight time window to gather data, process that data, and update the system. As referenced by the CAST-32A & A(M)C 20-193 documents, Hardware Shared Resources (HARs) and associated interference channels make that a particularly thorny challenge when developing systems to run on multicore processors (MCPs).
LDRA offers a uniquely malleable tool set to meet the challenge of analysing execution times and hence demonstrating that Worst Case Execution Times (WCET) will not exceed their allotted windows.
DO-178C insists that systems requirements should be traceable through to every stage of development, and vice versa to ensure that the whole code base is traceable to requirements. LDRA provides a comprehensive, role-based approach to bidirectional traceability.
Systems requirements and verification tasks can be assigned to team members, and all resulting artifacts can be aggregated and linked. The result is a complete bidirectional process across the life cycle, ensuring that any changes to requirements, design, or source code are easily understood, verified, and traced.
LDRA tools help to detect changes in requirements or the developed software and easily organize and re-run appropriate tests against any affected components. They provide an optimal environment for determining impact analysis either upstream to requirements or design or downstream to implementation and test.
For DAL A software, the DO-178C requires the analysis of any additional object code that isn’t directly traceable to the original source to ensure that it provides a reliable interpretation of the programmers’ intentions. Object Code Verification (OCV) provides a systematic way to address this challenge by comparing source and assembly-level coverage. When supported by appropriate tooling, this multi-layered approach not only streamlines compliance but also enhances confidence in the reliability and determinism of the final software product.
Structural coverage is not just a metric—it is a process that reinforces the integrity of airborne software through disciplined testing, detailed traceability, and targeted verification activities aligned with the rigor expected of compliant systems.
LDRA verification tools provide the facility to fulfil DO-178C’s requirements for data and control coupling metrics. The intent is to show that the software modules affect one another only in the ways intended by the software design, ensuring that there are no unplanned, anomalous, or erroneous behaviours. Documenting data and control coupling during design provides a set of requirements to test during the software integration process.
Similarly, ensuring that the data and control coupling between modules are exercised and exhibit no faults during software test demonstrates that the integration and architecture of the software is fully verified.
In addition to statement and branch coverage, for level A software MC/DC coverage is obligatory.
MC/DC is a coverage metric for multiple condition decisions. It does not require every possible combination to be executed but instead requires only one more test than the number of conditions involved. In the example shown there are 6 conditions, and so a total of 64 possible combinations – and yet only 7 tests are needed to achieve MC/DC coverage.
However, those tests must show that each of the conditions independently affect the result, and it is not always obvious which input values might achieve that. LDRA verification tools provide a mechanism to automate that process.
For Level A systems, structural coverage at the source level isn’t enough. Compilers often add additional code or alter control flow, and often their behaviour is not deterministic. To ensure that functionality is not compromised, DO-178C 6.4.4.2.b demands source to object code traceability. It states:
“if the software level is A and a compiler, linker, or other means generates additional code that is not directly traceable to Source Code statements, then additional verification should be performed to establish the correctness of such generated code sequences”
An automated mechanism to provide evidence of that verification can make that process much more efficient. Because there is a direct one-to-one relationship between object code and assembly code, one way for a tool to represent this is to display a graphical representation of the source code alongside the equivalent representation of the assembly code. Object Code Verification (OCV) measures code coverage at both the source and the assembly level by instrumenting each in turn
DO-178C compliance requires that compliance demonstration data – a collection of documents, records, and evidence – are presented to regulatory authorities to demonstrate that the software development and verification processes adhere to DO-178C.
This data typically includes various reports and artifacts that showcase how the software was developed, tested, and verified, and the reports generated by the LDRA tool suite are designed to be appropriate for that purpose.
For example, key components of DO-178C compliance demonstration data
include:
This data is submitted to aviation authorities for review and approval before the software can be certified for use in aircraft. Achieving that by means of traditional, labour-intensive methods is both time consuming and costly.
The TBmanager component of the LDRA tool suite is a desktop traceability application, and is integrated with code review, data and control coupling analysis, low-level testing, and code coverage tools. It eases the project management challenges associated with such complexity by constantly maintaining a requirements traceability matrix down to the source code and test cases – even through disparate repositories.
LDRAvault is complementary to TBmanager. It is a web-based, enterprise level application that aggregates and manages certification artifacts across projects and programs providing transparency into the development and verification process. Data access can be easily controlled, and analysis and compliance results can be easily shared with pertinent parties including regulatory authorities. Examples include code reviews, code coverage analysis, and unit testing results.
DO-178C requires that development tools are qualified for use on a compliant system. The LDRA Tool Qualification Support Packs (TQSPs) contain the test cases to demonstrate both the structural coverage analysis and programming rules checking capabilities of the tool suite itself in accordance with DO-330 Software Tool Qualification. In addition, associated documentation for the development and verification of the product is provided, including plans, procedures, and expected results.
LDRA Certification Services (LCS) is a division of LDRA that offers the first comprehensive and fully compliant FAA and EASA certification solution. Proficient in both commercial and military airworthiness regimens, LCS can address all critical project requirements as they relate to certification, including systems and safety analyses, management and planning, staff training, development, and verification.
Technical white paper: Technical white paper: Following the recommendations of CAST-32A & A(M)C 20-193
Technical briefing: DO-178C demystified: Strategies for efficient certification
Technical briefing: Getting to grips with CAST-32A & A(M)C 20-193
Technical note: Achieve DO-178C compliance with LDRA tool suite
Data sheet: DO-178C with the LDRA tool suite
Data sheet: LDRA Productivity Package – Aerospace and Defense
Blog: DO-178C & Structural Coverage Analysis
Website: DO-330 Software tool qualification considerations: When, where, and how it applies
Technical briefing: Achieve DO-178C compliance with LDRA tool suite
Technical briefing: DO-330 Test tool qualification for aerospace applications
News article: Ensuring the compliance of avionics software with DO-178C
Training: On Demand DO-178C “First Flight” Self-paced online training course
Case study: Richland technologies case study
Technical briefing: Getting to grips with A(M)C 20-193
Technical white paper: Following the recommendations of A(M)C 20-193
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707