FOR ENGINEERS AND MANAGERS
DO-178 has an innocuous title: ”Software Considerations in Airborne Systems and Equipment Certification.” But there’s a lot going on underneath that title. In reality, ‘178,’ as the document is known in the industry, is largely considered the bible of avionics software development.
Today, DO-178C (ED-12C in Europe) is a living document with continual changes including integration with the new ARP4761A and ARP4754B, plus new rules for multicore processing via AC 20-193.
The standard was originally developed in the ‘80s, despite the fact that there was relatively little software in safety-critical systems in those days. Today, DO-178C has become the de facto standard for software in those systems. What’s more, software safety standards that currently exist in the military, medical, transportation, and energy sectors bear many similarities to DO-178.
In fact, DO-178C comprises the basis for many other industry software safety standards including automotive’s ISO26262, Industry’s IEC61508, and Military’s MIL-STD-882E.
DO-178 then starts with the premise (and for commercial avionics, a certification authority mandate) that the user applies DO-178 as merely one link within the avionics certification chain. Avionics will be neither safe nor compliant without a safe foundation to precede DO-178. What then comes before the application of DO-178? Typically a Project Specific Certification Plan (PSCP) will be developed, which defines the avionics eco-system for the avionics system including the applicability of DO-178. That PSCP-cited eco-system normally includes the performance of a formal Functional Hazard Assessment (FHA) per ARP-4761 followed by definition of system level avionics requirements per ARP-4754A. What happens if you initiate DO-178 activities without considering the preceding? Generally you will have enjoyed some nice practice activities, so you’ll “get” to go back and do it all again … Truly, DO-178 requires a safe foundation with formally defined system requirements and any pretext to the contrary is foolhardy. In short, DO-178 does not verify that the system requirements are good or bad; DO-178 assumes the system requirements are good and ensures they get transposed and verified to software adequately commensurate with the design level.
DO-178C has evolved through three separate iterations, so it’s worthwhile to review the changes, the reasons for them, and how avionics engineers are applying the standard today.
DO-178 attempts to lay down a framework so that development personnel and certification authorities can work with full vision and leave residual blindness behind. However, the standard doesn’t guarantee clarity of vision and certainly not perfection. In fact, to paraphrase Winston Churchill’s famous quotation concerning democracy, “DO-178 is the worst standard in the world except tor all the others.” So let’s take a closer look at this important standard and how it governs the development process for avionics software.
Understanding
Design Assurance (Criticality)
Levels Per DO-178C
All You Need to Know About DO-178C Processes
How to Reduce
DO-178 Compliance Costs
DO-178C Compliance
Tools
DO-178C White
Paper Excerpt
Continued
First, you need to understand the Development Assurance Level (DAL) of the software you are developing for DO-178. The rigor applied to planning, development, testing, and correctness of your software is directly associated with the DAL of a particular system, often referred to as its criticality level. So, for instance, if the failure of a particular system has little effect on the overall functionality of the aircraft, it has a low criticality level. If the failure of a system could cause imminent danger to the aircraft or its occupants, the software has a high criticality level.
Key DO-178C Reliability & Independence for Part 25/29 Large Aircraft:
Required Independence versus DAL for DO-178 & DO-254
DO-178 has specific objectives based upon the criticality level of the software. Higher DALs must satisfy more DO-178 objectives than lower levels. After the software criticality level has been determined, you must examine DO-178 to determine exactly which objectives you need to satisfy for the software.
Once you’ve established the DAL of your software, you are ready for planning how you will comply with DO-178C. This is where DO-178 compliance is similar to building a house: you’ve performed geographic analysis to determine what type of foundation is required — that is your “safety assessment.” Then you need a Planning Process, followed by a Development Process. A concurrent Correctness Process is ongoing throughout both Planning and Development.
DO-178 and DO-254 have three integral processes – Planning, Development, and Correctness:
As you can see in the above figure, the DO-178 Planning process comes first, and when complete is followed by a larger DO-178 Development process. In the background the largest process, Correctness (which involves many different integral processes, including QA, CM, Verification, and the work of an FAA Certification Liaison), is performed continuously. Download the full DO-178C white paper for more information on Planning, Development, and Correctness.
AFuzion was the sole selection for training FAA, EASA, and 200+ other worldwide organizations on aviation certification. Our company continues to train more engineers annually than all competitors combined and we offer the world’s largest collection of technical aviation development and certification webinars.
Remember, each avionics system is assigned one or more levels of criticality, and each component within that system must meet or exceed its assigned criticality level. Since the amount of testing and verification rises along with the increasing DAL, the cost also increases.
The following graph, and associated table below, depict the actual cost deltas associated with each level of criticality: as a baseline, the additional costs of DO-178C are contrasted with medium-quality software development, e.g. high quality financial or consumer software (where the applicable true CMMI level of development was between Level 2 and 3).
Graph: Delta Cost and Schedule of DO-178 per Criticality Level, Above CMMI 3
The cost differential within DO-178C is the most significant between Level D and Level C. Why? Level C requires the following key objectives which Level D does not and which results in Level C requiring 35 percent more effort than Level D:
Level B requires additional structural coverage (decision-condition, e.g. all branches in the source code), additional independence in reviews, and tighter configuration management.
In Level B (and C) there must be detailed, low-level software requirements and they must be thoroughly tested. Remember, DO-178C requires detailed low level requirement verification beginning with Level C, and those low level requirements will cover the vast majority of software logic decisions.
During requirements-based testing, most (80 to 90 percent+) of the branches in the source code are already covered and hence require no additional structural coverage testing if test capture and coverage tools are appropriately used during that functional testing. Therefore, the seemingly significant cost increase associated with Level B versus C structural coverage is already mitigated by DO-178C’s greatly enhanced requirements-based testing.
The reader is well-advised to undergo upfront DO-178 Training and DO-178 Process Improvement to leverage these cost reduction techniques.
Where does the money go?
Level A is certainly the most critical software level and hence the most expensive. But there are also some myths surrounding Level A, one of which is that “Level A is extremely difficult to achieve and the software will cost at least 30 to 50 percent more than Level B,” which is simply not true. The most significant cost driver in Level A over Level B is the MCDC testing requirement. Level A imposes yet more structural coverage requirements (MCDC testing), source to binary correlation, and more independence within reviews.
However, with proper application of modern structural coverage tools, personnel training, and thorough requirements based testing, the added cost for Level A can be largely contained, thus Level A software is only slightly more expensive than Level B.
The following figure, DO-178C Cost Metrics, shows a typical breakdown of expenditures for a Level C project; Level A of course would have a greater percentage allocated to Verification.
Figure: DO-178C Cost Metrics
Our engineers identify gaps in your DO-254, DO-178C, DO-278A, DO-200B, DO-326A, and ARP4754A engineering processes and help you close those gaps. Reduce costs, streamline certification processes, and analyze your system, safety, software, hardware, and tools environment with input from AFuzion’s experts.
DO-178C requires five DO-178C Plans, three DO-178C Standards, and 20+ DO-178C checklists. Most companies (over 150 companies and 9,000 engineers worldwide) use AFuzion’s DO-178C Planning templates, DO-178C Standards templates, and DO-178C checklist templates described below. Once you’ve acquired these resources from AFuzion and customized them for the first project, your engineers will retain the expertise to create, customize and re-use as appropriate on future DO-178C projects.
DO-178C Plans and Checklist Templates cover all phases of the system’s software project lifecycle and are developed with DO-178C in mind. The users of these templates would need to have some basic understanding of DO-178C, such as attendance at AFuzion’s DO-178C training.
The regulatory agencies require that most airborne commercial systems operating within commercial airspace comply with DO-178C and DO-254. The planning and processes for the engineering lifecycle are required for any DO-178C and DO-254 project, and those processes must be defined before initiating a particular phase and followed during that phase.
Although checklists are not formally required by DO-178C and DO-254, your regulatory agencies will certainly require that you prove conformance to DO-178C and DO-254 according to your approved processes. Nearly all DO-178C and DO-254 projects use checklists for reviews and proof of conformance.
DO-178 checklists will be tailored to project specifics and standards; checklists also codify the success criteria applicable to DO-178 compliance. Checklists then satisfy the following attributes for each of your principal artifacts:
Copyright AFuzion
What gets reviewed via DO-178 checklists? Virtually everything, particularly items associated with required DO-178 objectives: Plans, Standards, Safety, Requirements, Design, Code, Tests & Results, Tool Qualification(s), Suppliers, etc.
The AFuzion process templates provide the basic elements of an avionics project compliant with DO-178C and DO-254. Further, AFuzion can customize and tailor these processes by the appropriate amount as an outflow of the gap analysis process, upon request as part of the optional first draft delivery.
If there are items in the checklists that are not applicable to your program they could simply be answered with “N/A.” It is also recommended that the checklists be placed under your project’s configuration management (CM) system to ensure checklist integrity.
And remember, under higher DALs, independent reviews are always preferable to reviews done by the developer.
These DO-178C templates and checklists also help in getting organizations to the goal of higher SEI CMM/CMMI ratings (preferably Level 3 through 4+). Using AFuzion’s process templates and checklists will maximize the probability of project success and quality. More DO-178C Template information is available on our plans and checklists page, or you can attend one of our webinars.
DO-178C PLANS
STANDARDS, AND
CHECKLISTS
DO-254 PLANS,
STANDARDS, AND
CHECKLISTS
ARP4754A PLANS,
STANDARDS, AND
CHECKLISTS
DO-178C is certainly neither free nor cheap. However, DO-178C can actually be cost-effective when implemented properly, particularly when evaluated over a product lifetime or subsequent product versions when DO-178C efficiency and benefits are most notable.
The following describes the most common benefits from DO-178C compliance based upon this author’s 25 years of experience consulting on over 250 avionics projects.
DO-178C mandates thorough and detailed software requirements. Such detail, and the necessary discipline, forces answers to be provided up-front instead of being deferred. This method minimizes assumptions in the development process and enhances consistency and testability of requirements. It also reduces fault and missing requirements and any relevant rework. It’s true that other standards and guidelines such as CMMI also mandate such upfront requirements; however, DO-178C is unique in its detailed enforcement of those requirements.
Code iterations, or churn, are the bane of software engineering. New products may require ten, twenty, or even thirty different versions or iterations over the course of development and the product lifetime. With strong engineering processes and discipline, code should be largely correct the first time it is written and should not require dozens of updates to get it right, particularly when using well-advised software modeling. Models and code should be reviewed by analyzing implementation versus documented requirements per DO-178C.
Since DO-178C mandates thorough and testable requirements, in addition to code reviews for Level C and above, far fewer bugs will be found in the later stages of module testing. The independent code reviews required for Level B and A also further that aim. This is especially true since DO-178C code reviews require the following completed and configured items prior to writing models or code:
Remember, DO-178C traceability should be as shown in the following DO-178C Traceability Figure:
Software is like a chain: it can only be as strong as its weakest link. Software that is 99 percent correct is 1 percent incorrect, which means it is unsafe. You can never prove particular software to be perfect, and DO-178C makes no claims that perfect adherence to its objectives yields perfect software. The weakest software module, or software engineer, can potentially threaten software safety. Thankfully, all software must be consistent according to its level of criticality, and DO-178 enforces this.
Integration can be a lengthy iterative process during which developers discover major defects and have to make full design changes to fix them. Not so with DO-178, in which integration is typically 50 to 75 percent faster than in non-DO-178 environments. Since all software the operation of which is potentially affected by hardware must be tested on actual target hardware, integration begins earlier and developers can verify the software sooner in the process. Also, the system upon which the software resides must comply with ARP4754A (or ARP4754B later this year), which mandates similarly strong system processes. Plus, DO-254 ensures that custom hardware logic components will be of similar high quality at integration. Thus, integration begins earlier with inherently fewer flaws than in non-DO-178C environments.
Download the rest of this paper for 15 additional DO-178C Cost Benefits.
Safety-Critical projects require provable requirements management and traceability. Our engineering experts work onsite or offsite to perform safety assessments and develop project-specific certification plans (PSCPs) for DO-178C compliance in 30+ countries worldwide.
Read More
Read More
Read More
Read More
Read More
By the early 2000s, U.S. military organizations realized that the commercial aerospace sector, particularly the part that is regulated by the FAA via DO-178, maintained certain advantages that were not inherent in the defense establishment. They were faced with a choice:
Ultimately, the military chose option three, although the choice was hardly a simple one. As with any established organization, there were myriad opinions, entrenched practices and opposition, added initial transition costs, and politics. Still, military aviation has been gradually adopting not only DO-178, but also DO-254, ARP4754A or the upcoming update ARP4754B, and ARP4761/A.
Further complicating the military adoption of civilian aviation guidelines were the following aspects:
DO-178C uses very specific objectives for four Stage Of Involvement meetings which include Quality Assurance, certification liaison, and typically the Certification Authority. :
SOI #1 – Is DO-178C Planning Complete?
(Includes Safety, System Rqmts, all development environment is in place and you know how to proceed.)
SOI #2: Does DO-178C Implementation conform to Plans, Standards, Requirements, and Design?
SOI #3: Are DO-178C Reviews, Tests, and Analysis complete per plans and implementation?
SOI #4: Are all DO-178C Changes, Processes, and Results known?
The following DO-178C SOI Job Aid Summary is extracted from AFuzion’s 2-hour DO-178C Training on SOI’s:
While the military has essentially adopted DO-178C for avionics software development, there are a few areas in which this adoption varies from the way civil aviation organizations apply the standard.
In addition, military entities traditionally use SSR, CDR, PDR, and TRR for aviation software and legacy DO-178C. However, DO-178C utilizes the Stage of Involvement (even if informally) instead. Download the full DO-178C Introduction paper via the link below for additional details on military compliance for DO-178C.
Note that the military increasingly adheres to Multi-Core Processing development and certification per AC 20-193 (AMC 20-193) in Europe with more stringent MCP requirements; AFuzion’s CAST-32A/MCP 20-193 Training is a popular option. You can view our DO-178C training for more details. The figure below shows the military DO-178C versus Civil DO-178C meetings and AFuzion’s recommended means of aggregating the two when applying DO-178C on military projects:
Figure: Military DO-178C Compliance Meetings versus DO-178C Civil Meetings/SOI’s
For the remaining 14 pages of this AFuzion DO-178 Introduction Technical Whitepaper, please download below.
Change within a major critical safety standard like DO-178C moves slowly. Nonetheless, there have been a couple significant developments in 2022 and early 2023 that will change the way aircraft manufacturers apply the standard going forward.
As of mid 2022, the SAE released a new ARP4754B draft to make some improvements over ARP4754A. Since ARP4754B is supplemental to DO-178C and will be mandatory for compliance as of this year, it’s important to understand some of those changes and how they affect aircraft developers.
The first change is that ARP4754B will better align with the avionics ecosystem per ARP4761A, which is a soon-to-come update to ARP4761. Right now, it can be hard to see how the different requirements of the various standards relate and connect, but ARP4754B will make it easier to understand how both standards fit together in avionics certification and safety.
There are also new updates to Development Assurance Level assignment per DO-178C, as well as updates to model-based systems engineering and modifications and reuse principles for avionics systems. Finally, and this one should make avionics developers happy, ARP4754B has been updated to include better examples for applying the standard, making it easier to ensure best practices in compliance. To learn more about these and other changes, you can see our ARP4754B white paper or attend our training.
The year 2023 will also bring new developments in the areas of unmanned aerial vehicles (UAVs) and electric vertical takeoff and landing (eVTOL) certification per DO-178C. The EASA has already developed additional airworthiness guidelines and regulations related to eVTOLs, though the regulations are far from finalized. The new regulations will likely be an example for any changes the FAA may make regarding eVTOL and UAV certification in the United States per DO-178C, DO-254, and related standards.
Finally, AI is big in every industry right now, and aviation is no exception. But there are regulatory challenges with AI in aviation that have yet to be solved, and DO-178C specifically requires determinism, whereas AI is far from deterministic. In other words, AI isn’t perfectly predictable. This is because true artificial intelligence comes from a machine’s ability to learn, with identical inputs yielding different outputs based on that learning process. AI means outputs will change all the time, making it hard to implement in a DO-178C-regulated environment that requires the highest level of predictability and determinism.
Still, various avionics engineers, including those at AFuzion, are developing deterministic, predictable AI frameworks that increase redundancy and safety in AI-powered systems. While we may not see all of the fruits of this labor in 2023, the next 10 years will likely show exciting growth in AI in avionics software systems.
DO-178C will continue to change going forward, and there may be additional iterations in the future. Regardless, it will continue to be an essential part of avionics safety for software systems.
To download the remaining 11+ pages of this technical DO-178C Introduction white paper, please download below: