In the 1970’s, the Federal Aviation Administration (FAA), the European Aviation Safety Agency (EASA), and other worldwide aviation safety agencies first invoked the RTCA/DO-178 document. The document’s title is “Software Considerations in Airborne Systems and Equipment Certification.” The document’s intent is to ensure safety of in-flight software, and it does this by imposing a structured development process. While the intent has never changed, the RTCA committee responsible for this document has substantively revised it every decade since the 1970’s to keep pace with technology. In July of 2013, the FAA invoked the fourth-generation standard, DO-178C (called ED-12C in Europe) via AC20-115C.
DO-178C and DO-178B summary of differences and for information on the Certification of Software training course (DO-178C).
DO-178C is a far more mature document than DO-254, but it still has its complexities. For example, RTCA SC-205 committee wrote DO-178C in the RTCA style, making it intentionally “non-prescriptive.” This means the document provides general objectives that describe “what” must be done, but no examples explaining “how.” While this approach provides a lot of flexibility, it also creates a lot of ambiguity — especially for those having to comply for the first time. Also, DO-178C added four new supplements (i.e. separate but related documents) that deal with technology-specific software topics: DO-330 for Tool Qualification; DO-331 for Model Based Development; DO-332 for Object Oriented Technologies; DO-333 for Formal methods. In additional to understanding the myriad of minor changes in the base document, the biggest DO-178C challenge, for those already familiar with DO-178B, is determining how to use one or more of these supplements alongside the requirements of DO178C within your project.
What follows is a short summary of the content of the DO-178C document. The DO-178C Software Life Cycle (i.e., the compliance process that you must follow) includes an extensive planning phase, which guides the four processes of software development and integral process. Each step includes its own plans to guide it, its own objectives and activities, its own reviews to verify everything, and its own artifacts to show evidence of compliance.
Software Development Phases
After the Planning phase is completed, the four processes of software development are:
- Software Requirements
The systems development process provides requirements that the SW design team breaks down into software requirements that they will implement in the program. - Software Design
This team develops the software architecture and lower-level requirements. - Software Coding
The team performs the actual software coding, turning the SW requirements into the design via the defined architecture. - Integration
The team compiles the source code, and then links and loads it onto the target computer system.
Integral Processes
The Integral Processes are:
- Software Verification
The team performs a combination of reviews, analyses, and tests to ensure the software design implements its requirements (and nothing more). - Configuration Management
These processes provide proper data control and replication. - Quality Assurance
The Quality Assurance representative on the team ensures that the project’s development processes meet the life cycle process objectives, as per plans (and documents and approves any deviations) - Certification Liaison
The certification authority reviews plans, processes, and artifacts periodically to ensure compliance.
While it seems simple and straight forward enough, the DO-178C process is strewn with many potential pitfalls, especially for the novice. If you do not address these issues, your project may suffer needless high cost and schedule delays.
So if you want to learn more, you will need to purchase the DO-178C document from RTCA (click to buy it here). Read it to familiarize yourself with the base document. Repeat for all the supplements (which can also be purchased from the RTCA store). Then acquire all other pertinent documents, such as AC20-115D and AC00-69 along with EASA AMC20-115D documents, which may affect how you apply DO-178C as an acceptable means of compliance to the CFR14 regulations. Also note that the “Overarching Properties” initiative could at some point influence the compliance requirements of DO-178C.
Training, along with some consulting support, are helpful to understand all the documents and how to apply them most efficiently to your own project given your own company’s processes and resources.
If you just want to know what’s changed in DO-178C from DO-178B, a “What’s Changed in DO-178C” short class is offered at Avionics Certification Academy. If you just want to understand how to apply the supplements, ask Tammy for her Supplement Tables, which provide a quick overview of how the DO-178C objectives need to be modified if you’re using any of the new supplements. Check back for more training related to the newly released AC20-115D/ AMC20-115D and AC00-69.