DO-178B

From Wikipedia, the free encyclopedia

You have new messages (last change).
DO-178B / ED-12B
Software Considerations in Airborne Systems and Equipment Certification
Latest Revision December 1, 1992
Prepared by RTCA SC-167
EUROCAE WG-12

DO-178B, Software Considerations in Airborne Systems and Equipment Certification is a standard for software development published by RTCA, Incorporated. The standard was developed by RTCA and EUROCAE. The FAA accepts use of DO-178B as a means of certifying software in avionics.

Contents

[edit] Software level

The required level 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.

  • Catastrophic - Failure may cause a crash.
  • Hazardous - Failure has a large negative impact on safety or performance, or reduces the ability of the crew to operate the plane due to physical distress or a higher workload, or causes serious or fatal injuries among the passengers.
  • Major - Failure is significant, but has a lesser impact that a Hazardous failure (for example, leads to passenger discomfort rather than injuries).
  • 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.

The number of objectives to be satisfied (with independence) is determined by the software level. In the standard, "with independence" refers to a separation of responsibilities where the person(s) who verify an objective must not be the developers of the item in question. In some cases, an automated tool may be equivalent to independence[1].

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

[edit] Processes and documents

Processes are intended to support the objectives, according to the software level (A through E). 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. Therefore, on a real project, the actual activities that will be done in the context of a process must be shown to support the objectives. In fact, 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 regards to following different styles of software life cycle. However, 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. Therefore, 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.

[edit] 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 standard (SRS)
  • Software design standard (SDS)
  • Software code standard (SCS)

System requirements are typically input to the entire project.

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

[edit] Development

This process can be divided into sub-processes: requirements, design, code and integration.

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 process:

[edit] 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 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 analyser tools

Other names for tests performed in this process can be:

  • Unit testing
  • Integration testing
  • Black box and acceptance testing

[edit] Configuration management

Documents maintained by the configuration management 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

[edit] 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.

[edit] Certification liaison

  • Typically a Designated Engineering Representative (DER) working for e.g. FAA in an airplane manufacturing company.

[edit] Certification in Europe

  • Replace FAA with EASA, JAA or CAA
  • Replace FAR with JAR or CS
  • Replace AC with AMJ

[edit] Tools

This part contains examples of software which can be used to automate, assist or otherwise handle or help in the DO-178B processes.

[edit] Requirements management

[edit] Development Environments

[edit] Real-time operating systems and other commercial off the shelf software

[edit] Test, verification and analysis tools

[edit] Configuration management

[edit] Traceability tools

[edit] Resources

  • FAR Part 23/25 §1301/§1309
  • FAR Part 27/29
  • AC 23/25.1309
  • AC 20-115B
  • RTCA DO-178B
  • FAA Order 8110.49 Software Approval Guidelines

[edit] See also

[edit] References

  1. ^ RTCA/DO-178B "Software Considerations in Airborne Systems and Equipment Certification", p.82

[edit] External links

Retrieved from "http://en.wikipedia.org../../../d/o/-/DO-178B_8687.html"
In other languages