DO-178B

Last updated
Software Considerations in Airborne Systems and Equipment Certification
Abbreviation
  • DO-178B
  • ED-12B
Latest versionDecember 1, 1992;30 years ago (1992-12-01)
Organization
DomainAviation

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.

Contents

The Federal Aviation Administration (FAA) applies DO-178B as the document it uses for guidance to determine if the software will perform reliably in an airborne environment, [1] when specified by the Technical Standard Order (TSO) for which certification is sought. In the United States, the introduction of TSOs into the airworthiness certification process, and by extension DO-178B, is explicitly established in Title 14: Aeronautics and Space of the Code of Federal Regulations (CFR), also known as the Federal Aviation Regulations, Part 21, Subpart O.

Software level

The Software Level, also termed 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 [2] ), 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-178B alone is not intended to guarantee software safety aspects. Safety attributes in the design and implemented as functionality, must receive additional mandatory system safety tasks to drive and show objective evidence of meeting explicit safety requirements. Typically IEEE STD-1228-1994 Software Safety Plans are allocated and software safety analyses tasks are accomplished in sequential steps (requirements analysis, top level design analysis, detailed design analysis, code level analysis, test analysis and change analysis). These software safety tasks and artifacts are integral supporting parts of the process for hazard severity and DAL determination to be documented in system safety assessments (SSA). The certification authorities require and DO-178B specifies the correct DAL be established using these comprehensive analyses methods to establish the software level A-E. Any software that commands, controls, and monitors safety-critical functions should receive the highest DAL - Level A. It is the software safety analyses that drive the system safety assessments that determine the DAL that drives the appropriate level of rigor in DO-178B. The system safety assessments combined with methods such as SAE ARP 4754A determine the after mitigation DAL and may allow reduction of the DO-178B software level objectives to be satisfied if redundancy, design safety features and other architectural forms of hazard mitigation are in requirements driven by the safety analyses. Therefore, DO-178B central theme is design assurance and verification after the prerequisite safety requirements have been established.

The number of objectives to be satisfied (eventually 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. [3] In some cases, an automated tool may be equivalent to independence. [4] However, the tool itself must then be qualified if it substitutes for human review.

LevelFailure conditionObjectives [5] With independenceFailure Rate
ACatastrophic662510−9/h
BHazardous651410−7/h
CMajor57210−5/h
DMinor28210−3/h
ENo Effect00n/a

Processes and documents

Processes are intended to support the objectives, according to the software level (A through D—Level E was outside the purview of DO-178B). Processes are described as abstract areas of work in DO-178B, and it is up to the planners of a real project to define and document the specifics of how a process will be carried out. On a real project, the actual activities that will be done in the context of a process must be shown to support the objectives. These activities are defined by the project planners as part of the Planning process.

This objective-based nature of DO-178B allows a great deal of flexibility in regard to following different styles of software life cycle. Once an activity within a process has been defined, it is generally expected that the project respect that documented activity within its process. Furthermore, processes (and their concrete activities) must have well defined entry and exit criteria, according to DO-178B, and a project must show that it is respecting those criteria as it performs the activities in the process.

The flexible nature of DO-178B's processes and entry/exit criteria make it difficult to implement the first time, because these aspects are abstract and there is no "base set" of activities from which to work. The intention of DO-178B was not to be prescriptive. There are many possible and acceptable ways for a real project to define these aspects. This can be difficult the first time a company attempts to develop a civil avionics system under this standard, and has created a niche market for DO-178B training and consulting.

For a generic DO-178B based process, a visual summary is provided including the Stages of Involvement (SOIs) defined by FAA on the "Guidance and Job Aids for Software and Complex Electronic Hardware".

Planning

System requirements are typically input to the entire project.

The last 3 documents (standards) are not required for software level D..

Development

DO-178B is not intended as a software development standard; it is software assurance using a set of tasks to meet objectives and levels of rigor.

The development process output documents:

Traceability from system requirements to all source code or executable object code is typically required (depending on software level).

Typically used software development process:

Verification

Document outputs made by this process:

Analysis of all code and traceability from tests and results to all requirements is typically required (depending on software level).

This process typically also involves:

Other names for tests performed in this process can be:

Configuration management

Documents maintained by the configuration management process:

This process handles problem reports, changes and related activities. The configuration management process typically provides archive and revision identification of:

Quality assurance

Output documents from the quality assurance process:

This process performs reviews and audits to show compliance with DO-178B. The interface to the certification authority is also handled by the quality assurance process.

Certification liaison

Typically a Designated Engineering Representative (DER) reviews technical data as part of the submission to the FAA for approval.

Tools

Software can automate, assist or otherwise handle or help in the DO-178B processes. All tools used for DO-178B development must be part of the certification process. Tools generating embedded code are qualified as development tools, with the same constraints as the embedded code. Tools used to verify the code (simulators, test execution tool, coverage tools, reporting tools, etc.) must be qualified as verification tools, a much lighter process consisting in a comprehensive black box testing of the tool.

A third party tool can be qualified as a verification tool, but development tools must have been developed following the DO-178 process. Companies providing these kind of tools as COTS are subject to audits from the certification authorities, to which they give complete access to source code, specifications and all certification artifacts.

Outside of this scope, output of any used tool must be manually verified by humans.

Requirements management

Requirements traceability is concerned with documenting the life of a requirement. It should be possible to trace back to the origin of each requirement and every change made to the requirement should therefore be documented in order to achieve traceability. Even the use of the requirement after the implemented features have been deployed and used should be traceable.

Criticism

VDC Research notes that DO-178B has become "somewhat antiquated" in that it is not adapting well to the needs and preferences of today's engineers. In the same report, they also note that DO-178C seems well-poised to address this issue.[ citation needed ]

Resources

See also

Related Research Articles

In software engineering, code coverage is a percentage measure of the degree to which the source code of a program is executed when a particular test suite is run. A program with high test coverage has 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.

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.

Software assurance (SwA) is a critical process in software development that ensures the reliability, safety, and security of software products. It involves a variety of activities, including requirements analysis, design reviews, code inspections, testing, and formal verification. One crucial component of software assurance is secure coding practices, which follow industry-accepted standards and best practices, such as those outlined by the Software Engineering Institute (SEI) in their CERT Secure Coding Standards (SCS).

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 types 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, food safety, occupational safety and health, process safety, reliability engineering.

<span class="mw-page-title-main">ARP4761</span>

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.

<span class="mw-page-title-main">ARP4754</span>

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

In software engineering, software system safety optimizes system safety in the design, development, use, and maintenance of software systems and their integration with safety-critical hardware systems in an operational environment.

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, systematic errors, hardware failures and operational/environmental stress.

<span class="mw-page-title-main">LDRA</span> Software companies of the United Kingdom

LDRA is a provider of software analysis, and test and requirements traceability tools for the Public and Private sectors, and is a pioneer in static and dynamic software analysis.

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.

<span class="mw-page-title-main">AC 25.1309-1</span> American aviation regulatory document

AC 25.1309–1 is an FAA Advisory Circular (AC) that identifies acceptable means for showing compliance with the airworthiness requirements of § 25.1309 of the Federal Aviation Regulations. Revision A was releases in 1988. In 2002, work was done on Revision B, but it was not formally released; the result is the Rulemaking Advisory Committee-recommended revision B-Arsenal Draft (2002). The Arsenal Draft is "considered to exist as a relatively mature draft". The FAA and EASA have subsequently accepted proposals by type certificate applicants to use the Arsenal Draft on 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.

<span class="mw-page-title-main">AC 20-115</span>

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.

<span class="mw-page-title-main">FAA Order 8110.105</span> American regulatory order

FAA Order 8110.105A, Simple and Complex Electronic Hardware Approval Guidance, supplements RTCA DO-254 by explaining how FAA aircraft certification staff can use that document "when working on certification projects" and is recommended as a reference for developers applying for certification under DO-254. A particular focus is on clarification of the application of DO-254 guidance to "simple" custom micro-coded components as opposed to the more rigorous assurance expected of complex custom micro-coded components. Micro-coded devices are typically presumed to be complex components that cannot be verified through testing alone; however, some applicants have proposed their specific micro-coded device applications as simple components.

<span class="mw-page-title-main">AC 20-152</span>

The Advisory Circular AC 20-152A, Development Assurance 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, and DO-330, as well as the supplements that accompany those publications.

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 "best practices" complementary to the objectives of ED-12C/DO-178C.

The Certification Authorities Software Team (CAST) is an international group of aviation certification and regulatory authority representatives. The organization of has been a means of coordination among representatives from certification authorities in North and South America, Europe, and Asia, in particular, the FAA and EASA. The focus of the organization has been harmonization of Certification Authorities activities in part though clarification and improvement of the guidance provided by DO-178 and DO-254.

<span class="mw-page-title-main">CAST-15</span>

CAST-15, Merging High-Level and Low-Level Requirements is a Certification Authorities Software Team (CAST) Position Paper. It is an FAA publication that "does not constitute official policy or guidance from any of the authorities", but is provided to applicants for software and hardware certification for educational and informational purposes only.

References

  1. ↑ FAA Advisory Circular 20-115B
  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."
  3. ↑ RTCA/DO-178B "Software Considerations in Airborne Systems and Equipment Certification", p. 82
  4. ↑ RTCA/DO-178B "Software Considerations in Airborne Systems and Equipment Certification", p.82
  5. ↑ RTCA/DO-178B "Software Considerations in Airborne Systems and Equipment Certification", Annex A

Further reading

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.