DO-178B, Software Considerations in Airborne Systems and Equipment Certification is a document dealing with the safety of software used in airborne systems.
The
FAAThe Federal Aviation Administration is the national aviation authority of the United States. An agency of the United States Department of Transportation, it has authority to regulate and oversee all aspects of civil aviation in the U.S...
applies DO-178B as the document it uses for guidance to determine if the software will perform reliably in an airborne environment, when specified by the Technical Standard Order (TSO) for which certification is sought.
It was published by RTCA, Incorporated, and development was a joint effort with EUROCAE who publish the document as ED-12B.
Software level
The
Design Assurance Level (DAL) is determined from the
safety assessment processARP4761, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment is a standard from the Society of Automotive Engineers . In conjunction with SAE ARP4754, ARP4761 is used to demonstrate compliance with 14 CFR 25.1309 in the U.S...
and
hazard analysisA 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 risks. Preliminary risk levels can be provided in the hazard analysis. The validation, more precise prediction and acceptance of risk is determined in the Risk...
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.
- Catastrophic - Failure may cause a crash. Error or loss of critical function required to safely fly and land aircraft.
- Hazardous - Failure has a large negative impact on safety or performance, or reduces the ability of the crew to operate the aircraft due to physical distress or a higher workload, or causes serious or fatal injuries among the passengers. (Safety-significant)
- Major - Failure is significant, but has a lesser impact than a Hazardous failure (for example, leads to passenger discomfort rather than injuries)or significantly increases crew workload (safety related)
- Minor - Failure is noticeable, but has a lesser impact than a Major failure (for example, causing passenger inconvenience or a routine flight plan change)
- No Effect - Failure has no impact on safety, aircraft operation, or crew workload.
DO-178B 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. 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. In some cases, an automated tool may be equivalent to independence.
| Level |
Failure condition |
Objectives |
With independence |
| A |
Catastrophic |
66 |
25 |
| B |
Hazardous |
65 |
14 |
| C |
Major |
57 |
2 |
| D |
Minor |
28 |
2 |
| E |
No effect |
0 |
0 |
Processes and documents
Processes are intended to support the objectives, according to the software level (A through D - Level E is 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.
The processes, activities and documents described here reflect naming and structure from DO-178B. This can be different in a real-life project.
Planning
Output documents from this process:
- Plan for software aspects of certification (PSAC)
- Software development plan (SDP)
- Software verification plan (SVP)
- Software configuration management plan (SCMP)
- Software quality assurance plan (SQAP)
- System requirements
- Software requirements standards
- Software design standards (SDS)
- Software code standards (SCS)
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:
- Software requirements data (SRD)
- Software design description (SDD)
- Source code
- Executable object code
Traceability from system requirements to all source code or executable object code is typically required (depending on software level).
Typically used
software development processA software development process, also known as a software development life cycle , is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. It is often considered a subset of systems development life cycle...
:
- Waterfall model
The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance.The waterfall...
- Spiral model
The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Also known as the spiral lifecycle model , it is a systems development method used in information technology...
- V model
Verification
Document outputs made by this process:
- Software verification cases and procedures (SVCP)
- Software verification results (SVR):
- Review of all requirements, design and code
- Testing of executable object code
- Code coverage
Code coverage is a measure used in software testing. It describes the degree to which the source code of a program has been tested. It is a form of testing that inspects the code directly and is therefore a form of white box testing....
analysis
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:
- Requirements based test tools
- Code coverage analyzer tools
Other names for tests performed in this process can be:
- Unit testing
- Integration testing
- Black-box and acceptance testing
Configuration management
Documents maintained by the
configuration managementConfiguration management is a field of management that focuses on establishing and maintaining consistency of a system or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life.For information assurance, CM...
process:
- Software configuration index (SCI)
- Software life cycle environment configuration index (SECI)
This process handles problem reports, changes and related activities. The configuration management process typically provides archive and revision identification of:
- Source code development environment
- Other development environments (for e.g. test/analysis tools)
- Software integration tool
- All other documents, software and hardware
Quality assurance
Output documents from the quality assurance process:
- Software quality assurance records (SQAR)
- Software conformity review (SCR)
- Software accomplishment summary (SAS)
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) working for e.g.
FAAThe Federal Aviation Administration is the national aviation authority of the United States. An agency of the United States Department of Transportation, it has authority to regulate and oversee all aspects of civil aviation in the U.S...
in an airplane manufacturing company.
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 testingBlack-box testing is a method of software testing that tests the functionality of an application as opposed to its internal structures or workings . Specific knowledge of the application's code/internal structure and programming knowledge in general is not required...
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 this kind of tools as
COTSIn the United States, Commercially available Off-The-Shelf is a Federal Acquisition Regulation term defining a nondevelopmental item of supply that is both commercial and sold in substantial quantities in the commercial marketplace, and that can be procured or utilized under government contract...
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.
- A problem management tool can provide traceability for changes.
- SCI and SECI can be created from logs in a revision control
Revision control, also known as version control and source control , is the management of changes to documents, programs, and other information stored as computer files. It is most commonly used in software development, where a team of people may change the same files...
tool.
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.
Resources
- FAR
The Federal Aviation Regulations, or FARs, are rules prescribed by the Federal Aviation Administration governing all aviation activities in the United States. The FARs are part of Title 14 of the Code of Federal Regulations...
Part 23/25 §1301/§1309
- FAR
The Federal Aviation Regulations, or FARs, are rules prescribed by the Federal Aviation Administration governing all aviation activities in the United States. The FARs are part of Title 14 of the Code of Federal Regulations...
Part 27/29
- AC
The Federal Aviation Administration is the national aviation authority of the United States. An agency of the United States Department of Transportation, it has authority to regulate and oversee all aspects of civil aviation in the U.S...
23/25.1309
- AC
The Federal Aviation Administration is the national aviation authority of the United States. An agency of the United States Department of Transportation, it has authority to regulate and oversee all aspects of civil aviation in the U.S...
20-115B
- RTCA/DO-178B
- FAA Order 8110.49 Software Approval Guidelines
See also
- DO-178C
DO-178C, Software Considerations in Airborne Systems and Equipment Certification is the title of an upcoming document published by RTCA, Incorporated, in a joint effort with EUROCAE...
- Avionics software
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...
- ARP4761
ARP4761, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment is a standard from the Society of Automotive Engineers . In conjunction with SAE ARP4754, ARP4761 is used to demonstrate compliance with 14 CFR 25.1309 in the U.S...
(Safety assessment process)
- ARP4754
ARP4754 is a standard from SAE, dealing with the development processes and certification of Aircraft systems. EUROCAE jointly issues the document as ED–79...
(System development process)
- DO-248B
DO-248B is a document published by RTCA, Incorporated. It provides clarification of the guidance material in DO-178B. Like DO-178B, it is a joint undertaking with EUROCAE and the document is also published as ED-94B "Final annual report for clarification of ED-12B"The clarification may accomplish...
(Final Report for clarification of DO-178B)
- DO-254
RTCA/DO-254, DESIGN ASSURANCE GUIDANCE FOR AIRBORNE ELECTRONIC HARDWARE is a document providing guidance for the development of airborne electronic hardware, published by RTCA, Incorporated.-Outline of contents:1...
(similar to DO-178B, but for hardware)
- Requirements management
Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project...
(too general to be "directly applied" to DO-178B)
- IEC 61508
IEC 61508 is an international standard of rules applied in industry. It is titled "Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems"....
- ISO 12207
ISO/IEC 12207 Systems and software engineering — Software life cycle processes is an international standard for software lifecycle processes...
(software life cycle process development standard)
External links