DO-178C

Last updated

Software Considerations in Airborne Systems and Equipment Certification
Latest version5 January 2012 (2012-01-05)
Organization
DomainAviation
Abbreviation
  • DO-178C
  • ED-12C

DO-178C, Software Considerations in Airborne Systems and Equipment Certification is the primary document by which the certification authorities such as FAA, EASA and Transport Canada approve all commercial software-based aerospace systems. The document is published by RTCA, Incorporated, in a joint effort with EUROCAE, and replaces DO-178B. The new document is called DO-178C/ED-12C and was completed in November 2011 and approved by the RTCA in December 2011. It became available for sale and use in January 2012. [1] [2] [3]

Contents

The FAA approved AC 20-115C [4] on 19 Jul 2013, making DO-178C a recognized "acceptable means, but not the only means, for showing compliance with the applicable airworthiness regulations for the software aspects of airborne systems and equipment certification."

Background

Since the release of DO-178B, there had been strong calls by DERs (FAA Designated Engineering Representatives) for clarification/refinement of the definitions and boundaries between the key DO-178B concepts of high-level requirements, low-level requirements, and derived requirements and a better definition of the exit/entry criteria between systems requirements and system design (see ARP4754) and that of software requirements and software design (which is the domain of DO-178B). Other concerns included the meaning of verification in a model-based development paradigm and considerations for replacing some or all software testing activities with model simulation or formal methods. The release of DO-178C and the companion documents DO-278A (Ground Systems), DO-248C (Additional information with rationale for each DO-178C objective), DO-330 (Tool Qualification), DO-331 (Modeling), DO-332 (Object Oriented), and DO-333 (Formal Methods) were created to address the issues noted. The SC-205 members worked with the SAE S-18 committee to ensure that ARP4754A and the above noted DO-xxx documents provide a unified and linked process with complementary criteria.

Overall, DO-178C keeps most of the DO-178B text, which has raised concerns that issues with DO-178B, such as the ambiguity about the concept of low-level requirements, may not be fully resolved. [5]

Committee organization

The RTCA/EUROCAE joint committee work was divided into seven Subgroups:

The Model Based Development and Verification subgroup (SG4), was the largest of the working groups. All work is collected and coordinated via a web-site that is a collaborative work management mechanism. [6] Working artifacts and draft documents were held in a restricted area available to group members only.

The work was focused on bringing DO-178B/ED-12B up to date with respect to current software development practices, tools, and technologies. [7] [8]

Software level

The Software Level, also known as the Design Assurance Level (DAL) or Item Development Assurance Level (IDAL) as defined in ARP4754 (DO-178C only mentions IDAL as synonymous with Software Level [9] ), is determined from the safety assessment process and hazard analysis by examining the effects of a failure condition in the system. The failure conditions are categorized by their effects on the aircraft, crew, and passengers.

DO-178C alone is not intended to guarantee software safety aspects. Safety attributes in the design and as implemented as functionality must receive additional mandatory system safety tasks to drive and show objective evidence of meeting explicit safety requirements. The certification authorities require and DO-178C specifies the correct DAL be established using these comprehensive analyses methods to establish the software level A-E. "The software level establishes the rigor necessary to demonstrate compliance" with DO-178C. [9] Any software that commands, controls, and monitors safety-critical functions should receive the highest DAL - Level A.

The number of objectives to be satisfied (some with independence) is determined by the software level A-E. The phrase "with independence" refers to a separation of responsibilities where the objectivity of the verification and validation processes is ensured by virtue of their "independence" from the software development team. For objectives that must be satisfied with independence, the person verifying the item (such as a requirement or source code) may not be the person who authored the item and this separation must be clearly documented. [10]

LevelFailure conditionObjectives [11] With independence
ACatastrophic7130
BHazardous6918
CMajor625
DMinor262
ENo Safety Effect00

Traceability

Diagram illustrating the required tracing between certification artifacts, as required by the RTCA DO-178C standard. Red-colored traces are required only for Level A. Purple-colored traces are required for Levels A, B, and C. Green-colored traces are for Levels A, B, C, and D. Level E does not require any tracing. The references on each trace arrow represent references to the standard for the objective, the activity, and the review/verification, respectively. DO-178C Traceability.png
Diagram illustrating the required tracing between certification artifacts, as required by the RTCA DO-178C standard. Red-colored traces are required only for Level A. Purple-colored traces are required for Levels A, B, and C. Green-colored traces are for Levels A, B, C, and D. Level E does not require any tracing. The references on each trace arrow represent references to the standard for the objective, the activity, and the review/verification, respectively.

DO-178 requires a documented connection (called a trace) between the certification artifacts. For example, a Low Level Requirement (LLR) traces up to a High Level Requirement (HLR). A traceability analysis is then used to ensure that each requirement is fulfilled by the source code, that each requirement is tested, that each line of source code has a purpose (is connected to a requirement), and so forth. Traceability ensures the system is complete. The rigor and detail of the certification artifacts is related to the software level.

Differences with DO-178B

SC-205/WG-12 was responsible for revising DO-178B/ED-12B to bring it up to date with respect to current software development and verification technologies. The structure of the document remains largely the same from B to C. Example changes include: [12]

Guidelines vs. Guidance

DO-178B was not completely consistent in the use of the terms Guidelines and Guidance within the text. "Guidance" conveys a slightly stronger sense of obligation than "guidelines". As such, with the DO-178C, the SCWG has settled on the use of "guidance" for all the statements that are considered as "recommendations", replacing the remaining instances of "guidelines" with "supporting information" and using that phrase wherever the text is more "information" oriented than "recommendation" oriented.

The entire DO-248C/ED-94C document, Supporting Information for DO-178C and DO-278A, falls into the "supporting information" category, not guidance. [17]

Sample difference between DO-178B and DO-178C

Chapter 6.1 defines the purpose for the software verification process. DO-178C adds the following statement about the Executable Object Code:

As a comparison, DO-178B states the following with regard to the Executable Object Code:

The additional clarification fills a gap that a software developer may encounter when interpreting the document. [18]

See also

Related Research Articles

In computer science, test coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs. A program with high test coverage, measured as a percentage, has had more of its source code executed during testing, which suggests it has a lower chance of containing undetected software bugs compared to a program with low test coverage. Many different metrics can be used to calculate test coverage; some of the most basic are the percentage of program subroutines and the percentage of program statements called during execution of the test suite.

In computer science, specifically software engineering and hardware engineering, formal methods are a particular kind of mathematically rigorous techniques for the specification, development and verification of software and hardware systems. The use of formal methods for software and hardware design is motivated by the expectation that, as in other engineering disciplines, performing appropriate mathematical analysis can contribute to the reliability and robustness of a design.

Avionics software is embedded software with legally mandated safety and reliability concerns used in avionics. The main difference between avionic software and conventional embedded software is that the development process is required by law and is optimized for safety. It is claimed that the process described below is only slightly slower and more costly than the normal ad hoc processes used for commercial software. Since most software fails because of mistakes, eliminating the mistakes at the earliest possible step is also a relatively inexpensive and reliable way to produce software. In some projects however, mistakes in the specifications may not be detected until deployment. At that point, they can be very expensive to fix.

DO-178B, Software Considerations in Airborne Systems and Equipment Certification is a guideline dealing with the safety of safety-critical software used in certain airborne systems. It was jointly developed by the safety-critical working group RTCA SC-167 of the Radio Technical Commission for Aeronautics (RTCA) and WG-12 of the European Organisation for Civil Aviation Equipment (EUROCAE). RTCA published the document as RTCA/DO-178B, while EUROCAE published the document as ED-12B. Although technically a guideline, it was a de facto standard for developing avionics software systems until it was replaced in 2012 by DO-178C.

A hazard analysis is used as the first step in a process used to assess risk. The result of a hazard analysis is the identification of different type of hazards. A hazard is a potential condition and exists or not. It may in single existence or in combination with other hazards and conditions become an actual Functional Failure or Accident (Mishap). The way this exactly happens in one particular sequence is called a scenario. This scenario has a probability of occurrence. Often a system has many potential failure scenarios. It also is assigned a classification, based on the worst case severity of the end condition. Risk is the combination of probability and severity. Preliminary risk levels can be provided in the hazard analysis. The validation, more precise prediction (verification) and acceptance of risk is determined in the Risk assessment (analysis). The main goal of both is to provide the best selection of means of controlling or eliminating the risk. The term is used in several engineering specialties, including avionics, chemical process safety, safety engineering, reliability engineering and food safety.

ARP4761, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment is an Aerospace Recommended Practice from SAE International. In conjunction with ARP4754, ARP4761 is used to demonstrate compliance with 14 CFR 25.1309 in the U.S. Federal Aviation Administration (FAA) airworthiness regulations for transport category aircraft, and also harmonized international airworthiness regulations such as European Aviation Safety Agency (EASA) CS–25.1309.

ARP4754, Aerospace Recommended Practice (ARP) ARP4754A, is a guideline from SAE International, dealing with the development processes which support certification of Aircraft systems, addressing "the complete aircraft development cycle, from systems requirements through systems verification." Revision A was released in December 2010. It was recognized by the FAA in AC 20-174 published November 2011. EUROCAE jointly issues the document as ED–79.

RTCA DO-254 / EUROCAE ED-80, Design Assurance Guidance for Airborne Electronic Hardware is a document providing guidance for the development of airborne electronic hardware, published by RTCA, Incorporated and EUROCAE. The DO-254/ED-80 standard was formally recognized by the FAA in 2005 via AC 20-152 as a means of compliance for the design assurance of electronic hardware in airborne systems. The guidance in this document is applicable, but not limited, to such electronic hardware items as

Integrated modular avionics (IMA) are real-time computer network airborne systems. This network consists of a number of computing modules capable of supporting numerous applications of differing criticality levels.

Functional safety is the part of the overall safety of a system or piece of equipment that depends on automatic protection operating correctly in response to its inputs or failure in a predictable manner (fail-safe). The automatic protection system should be designed to properly handle likely human errors, hardware failures and operational/environmental stress.

Liverpool Data Research Associates Software companies of the United Kingdom

Liverpool Data Research Associates (LDRA) is a provider of software analysis, and test and requirements traceability tools for the Public and Private sectors and a pioneer in static and dynamic software analysis.

The Open Group Future Airborne Capability Environment was formed in 2010 to define an open avionics environment for all military airborne platform types. Today, it is a real-time software-focused professional group made up of industry suppliers, customers, academia, and users. The FACE approach is a government-industry software standard and business strategy for acquisition of affordable software systems that promotes innovation and rapid integration of portable capabilities across programs. The FACE Consortium provides a vendor-neutral forum for industry and government to work together to develop and consolidate the open standards, best practices, guidance documents, and business strategy necessary to result in:

AC 25.1309–1 is an FAA Advisory Circular (AC) that describes acceptable means for showing compliance with the airworthiness requirements of § 25.1309 of the Federal Aviation Regulations. The present unreleased but working draft of AC 25.1309–1 is the Aviation Rulemaking Advisory Committee recommended revision B-Arsenal Draft (2002); the present released version is A (1988). The FAA and EASA have accepted proposals by type certificate applicants to use the Arsenal Draft on recent development programs.

Cantata++, or simply Cantata in newer versions, is a commercial computer program for dynamic testing, specifically unit testing and integration testing, and code coverage at run time of C and C++ programs. It is developed and sold by QA Systems, and was formerly a product of IPL Information Processing Ltd.

The Advisory Circular AC 20-115, Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( ), identifies the RTCA published standard DO-178 as defining a suitable means for demonstrating compliance for the use of software within aircraft systems. The present revision D of the circular identifies ED-12/DO-178 Revision C as the active revision of that standard and particularly acknowledges the synchronization of ED-12 and DO-178 at that revision.

The Advisory Circular AC 20-152, Design Assurance Guidance for Airborne Electronic Hardware, identifies the RTCA-published standard DO-254 as defining "an acceptable means, but not the only means" to secure FAA approval of complex custom micro-coded components within aircraft systems with Item Design Assurance Levels (IDAL) of A, B, or C. Specifically excluding COTS microcontrollers, complex custom micro-coded components include field programmable gate arrays (FPGA), programmable logic devices (PLD), and application-specific integrated circuits (ASIC), particularly in cases where correctness and safety can not be verified with testing alone, necessitating methodical design assurance. Application of DO-254 to IDAL D components is optional.

DO-248C, Supporting Information for DO-178C and DO-278A, published by RTCA, Incorporated, is a collection of Frequently Asked Questions and Discussion Papers addressing applications of DO-178C and DO-278A in the safety assurance of software for aircraft and software for CNS/ATM systems, respectively. Like DO-178C and DO-278A, it is a joint RTCA undertaking with EUROCAE and the document is also published as ED-94C, Supporting Information for ED-12C and ED-109A. The publication does not provide any guidance additional to DO-178C or DO-278A; rather, it only provides clarification for the guidance established in those standards. The present revision is also expanded to include the "Rationale for DO-178C/DO-278A" section to document items that were considered when developing DO-178B and then DO-178C, DO-278A, DO-330, and the supplements.

CAST-32A, Multi-core Processors is a position paper, by a Certification Authorities Software Team (CAST). It is not official guidance, but considered informational by certification authorities such as the FAA and EASA. A key point is that multicore "interference can affect execution timing behavior, including worst case execution time (WCET)."

DO-297, Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations is one of the primary document by which certification authorities such as the FAA and EASA approve IMA systems for flight. The FAA Advisory Circular (AC) 20-170 refers to DO-297.

The Advisory Circular AC 00-69, Best Practices for Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( ), initially issued in 2017, supports application of the active revisions of ED-12C/DO-178C and AC 20-115. The AC does not state FAA guidance, but rather provides information in the form of complementary "best practices".

References

  1. Timberlake Membership Software, 703-591-4232. "Rtca, Inc". Rtca.org. Retrieved 7 August 2016.
  2. Charlotte Adams (1 September 2010). "DO-178C nears finish line, with credit for modern tools and technologies". Avionics Intelligence. Retrieved 23 October 2010. The industry expects the final package DO-178C to be released in the first quarter of 2011 and be mandated six to nine months after ratification.
  3. "Summary of Difference Between DO-178B and DO-178C". FAA Consultants.com. Qualtech Consulting, Inc. Retrieved 23 October 2010. The release of these long anticipated standards will occur in mid 2011 and be recognized by the Certification Authorities in 2012.
  4. "Archived copy" (PDF). Archived from the original (PDF) on 3 September 2014. Retrieved 2013-08-08.CS1 maint: archived copy as title (link)
  5. Dale, Chris; Anderson, Tom, eds. (2010). Advances in systems safety : proceedings of the Nineteenth Safety-Critical Systems Symposium, Southampton, UK, 8-10th February 2011. London: Springer. pp. 298–299. ISBN   9780857291325.
  6. "Archived copy". Archived from the original on 19 July 2011. Retrieved 2010-09-18.CS1 maint: archived copy as title (link)
  7. Bill StClair & Tim King (7 March 2012). "DO-178C brings modern technology to safety-critical software development". Military Embedded Systems. Retrieved 17 April 2012.
  8. "DO-178C Enhances Safety-Critical Avionics Software Development". Electronic Design. Electronic Design. Retrieved 17 April 2012.
  9. 1 2 RTCA/DO-178C "Software Considerations in Airborne Systems and Equipment Certification", p. 116. "One example is the term “item development assurance level” (IDAL), which for software is synonymous with the term “software level."
  10. RTCA/DO-178C "Software Considerations in Airborne Systems and Equipment Certification", p. 41
  11. RTCA/DO-178C "Software Considerations in Airborne Systems and Equipment Certification", Annex A
  12. "HighRely Synopsis of National FAA Software and Hardware Meeting Includes DO-178C Status". 2006. Retrieved 30 September 2009. DO-178C will contain more details on software modeling and the potential ability to use modeling to supplant some of the verification techniques normally required in DO-178B. DO-178C will also more fully address OO (Object Oriented) software and the conditions under which it can be used and the certification ramifications of OO in DO-178C.
  13. RTCA/DO-178C Software Considerations in Airborne Systems and Equipment Certification. RTCA, Inc. 2011.
  14. Pothon, Frédéric. "Principles and benefits of using DO-330/ED-215" (PDF). validas. Retrieved 3 October 2019.
  15. Pothon, Frédéric; et al. (2012). DO-178C/ED-12C versus DO-178B/ED-12B Changes and Improvements (PDF). p. 49. Retrieved 5 January 2015.
  16. Pothon, pp. 43-46
  17. Pothon, p. 14
  18. "Archived copy". Archived from the original on 11 September 2014. Retrieved 2013-03-07.CS1 maint: archived copy as title (link)