Any team developing custom airborne software (SW) for commercial aviation programs (and in some cases military programs) that may have a safety impact on system operation must comply with DO-178C. Note that ground-based software utilized in air traffic control must comply with a similar standard called DO-278A.

DO-178C is a recognized means to show compliance with the applicable airworthiness regulations for the software aspects of airborne systems and equipment in product certification or TSO/ETSO authorization. Specifically DO-178C supports US CFR Title 14: Aeronautics and Space (Title 14 → Chapter I → Subchapter C → Part XX), where Part XX is Part 23 (commuter aircraft), Part 25 (transport aircraft), Part 27 (normal rotorcraft), Part 29 (transport rotorcraft), or Part 33 (engines). These correspond to equivalent rules of the EU Certification Specifications (CS).

DO-178C is a development assurance program. Complying with DO-178C requires performing thorough planning, complying with all the objectives of the DO-178C Life Cycle (i.e., Planning), having strict oversite of all processes i.e. Quality Assurance), controlling all data items (i.e. Configuration Management), clear identification and validation of hardware requirements (i.e., Requirements), a clearly documented design concept (i.e., Design), code that meets the requirements (Code), integration with hardware (Integration) that is thoroughly and possibly independently verified (i.e., Verification) to ensure meets all the requirements (and only the requirements) with no anomalous behavior. The objectives of DO-178C are modulated depending on the Design Assurance Level (DAL) of the design. For more information, view this free DO-178C mini-module.

This refers to the software development process that must comply with the objectives of DO-178C. The main life cycle phases are Planning, Requirements, Design, Coding, and Integration. The “Integral Processes” that operate alongside the development flow are Verification & Validation, Quality Assurance, Configuration management, and Certification Liaison.

DAL stands for Design Assurance Level, which is a measure of the criticality of a design. A hardware or software item is assigned an Item DAL (IDAL) during the system level Preliminary System Safety Assessment (PSSA). The assigned IDAL dictates the rigor of the objectives required to comply with the DO-254/DO-178C process.

There are numerous differences between these standards. For a free training on this topic click here.

See our Glossary here.

See our Glossary here.

DO-178C is a top-down process. Its starts with an extensive planning process to define how the software item will be developed to be compliant with all the objectives of DO-178C. These plans once approved by the regulatory authority are to be followed at every step of development. Many development teams make the common mistake of treating it like a bottom-up process, meaning they do the development first and then think they can just create the compliance documentation. But this is an expensive mistake. See more at our Blog here.

A DER stands for Designated Engineering Representative. This is a person who has, through rigorous education and experience, been authorized by the FAA to audit programs on their behalf. DERs, unlike FAA employees, can also perform training, offer advice, and do work on behalf of applicants for DO-178C compliance. To learn more, view our Blog on this topic.

While you do not technically need to hire a DER to audit your DO-178C, there are many benefits to doing so, including avoiding long wait times for FAA auditing and getting valuable advice throughout on your program. To learn more, view our Blog on this topic.

Be aware that not all DO-178C “consultants” or “certification experts” are DERs. Its best to screen folks closely, check multiple references, and verify their credentials by checking the FAA consulting directory, which identifies all the DERs authorized in various categories of expertise:

http://www.faa.gov/other_visit/aviation_industry/designees_delegations/designee_types/media/derdirectory.pdf

Yes, while DO-178C is a Top-Down process, you can still utilize an Agile development process to validate requirements. For more on this topic, refer to our Blog.

Some of the top mistakes are: 1) Not taking planning seriously, 2) doing traceability after-the-fact (as opposed to throughout development), 3) not hiring a properly authorized DER, 4) not holding internal reviews before certification audits, 5) not baselining/controlling data items properly.

DO-178C does not technically mandate specific documents, however it does mandate specific types of documentation and content that is usually found in the following Planning Documents:

  • Plan for Software Aspects of Certification (PSAC),
  • Software Development Plan (SDP),
  • Software Verification and Validation Plan (SVVP),
  • Software Quality Assurance Plan (SQAP),
  • Software Configuration Management Plan (SCMP)
  • Software Requirements Standards (SRS)
  • Software Design Standards (SDS)
  • Software Coding Standards (SCS)

For a complete set of DO-178C documentation templates, click here.

DO-178C plans guide everything you do in a DO-178C program, must be approved by the certification authorities, and is in essence a contract with the certification authorities regarding how you will meet compliance.

SOI stands for Stage of Involvement, referring to the involvement of the FAA when auditing a DO-178C compliance program. While not strictly required, there are typically 4 types of SOI audits held for a program: SOI-1 (Planning), SOI-2 (Requirements and Design), SOI-3 (Verification) and SOI-4 (Final Compliance Review). The number and depth of reviews depends upon a lot of factors. See Appendix A of FAA Order 8110.49A to understand how much involvement, and therefore the number and types of audits, your program may have.

The word traceability means linking one thing to another. For DO-178C, this is usually referring to the Requirements Traceability Matrix (RTM), which links requirements to the code, tests, and results. The reason for this traceability is to ensure that the design only includes the defined requirements (and nothing else) and that it has been demonstrated that the software code performs those requirements with no anomalous behavior. Sometimes the word traceability in a DO-178C context may mean the ability to trace design changes back to a known baseline, i.e., tracing one version of a design to a known version.

The latest policy documents affecting DO-178C compliance are as follows (Click here to see all the latest policy documents on our website):

  • FAA AC 20-115D: Airborne Software Development Assurance Using EUROCAE ED-12() and RTCA DO-178( )
  • AC 00-69: Best Practices for Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( )
  • AMC 20-189: The Management of Open Problem Reports (OPRs)
  • AC 00-71: Best Practices for Open Problem Report Management
  • AMC 20-193: Use of multi-core processors
  • AC_00-66 Selection of Cyclic Redundancy Code and Checksum Algorithms to Ensure Critical Data Integrity

You can find latest policy documents regarding DO-178C and DO-254 by searching the FAA and EASA websites. We’ve made it easy for you by putting all the latest pertinent documents (that are free and publicly available) on our website in one place here.

Note that DO-178C and DO-254 and the other RTCA documents (such as the DO-178C supplements) are available for purchase on the site www.rtca.org.

The answer can vary, but more and more military programs (i.e., jets, helicopters, UAVs/drones and other VTOL aircraft) are having to comply with DO-178C. Its usually a requirement when then aircraft could cause a safety concern in a civilian area.

The short answer is yes, probably. For the long answer, see our Blog.

We are happy to answer it. Just submit it to us: info@airworthinesscert.com