DO-178C

From Wikipedia, the free encyclopedia
Jump to: navigation, search
DO-178C / ED-12C
Software Considerations in Airborne Systems and Equipment Certification
Latest revision 01/05/2012
Prepared by RTCA SC-205
EUROCAE WG-12

DO-178C, Software Considerations in Airborne Systems and Equipment Certification is the title of the recently published document from RTCA, Incorporated, in a joint effort with EUROCAE. This replaces DO-178B as the primary document by which the certification authorities such as FAA, EASA and Transport Canada will approve all commercial software-based aerospace systems. 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]

The FAA approved AC 20-115C[4] on 19 Jul 2013, making DO-178C a recognized "compliance with the applicable airworthiness regulations for the software aspects of airborne systems".

Background[edit]

Since the release of DO-178B, there have 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 topics such as what does verification mean in a model-based development paradigm and can model simulation or formal methods replace some or all software testing activities. The release of DO-178C and the companion documents DO-278A (Ground Systems), DO-248C (Additional information), DO-330 (Tools), DO-331 (Modeling), DO-332 (Object Oriented), and DO-333 (Formal Methods) were created to address the criticisms noted. The SC-205 members worked with the SAE S-18 committee to assure that APR4754A and the above noted DO-xxx documents provide a unified and linked process with complimentary 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[edit]

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

  • SG1: SCWG Document Integration
  • SG2: Issues and Rationale
  • SG3: Tool Qualification
  • SG4: Model Based Development and Verification
  • SG5: Object-Oriented Technology
  • SG6: Formal Methods
  • SG7: Safety Related Considerations

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

The Software Level, also known as the Design Assurance Level (DAL) or also '"Item Development Assurance Level"' (IDAL),[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.

  • Catastrophic - Failure may cause multiple fatalities, usually with loss of the airplane.
  • 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.
  • Major - Failure significantly reduces the safety margin or significantly increases crew workload. May result in passenger discomfort (or even minor injuries).
  • Minor - Failure slightly reduces the safety margin or slightly increases crew workload. Examples might include causing passenger inconvenience or a routine flight plan change.
  • No Effect - Failure has no impact on safety, aircraft operation, or crew workload.

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]

Level Failure condition Objectives[11] With independence
A Catastrophic 71 33
B Hazardous 69 21
C Major 62 8
D Minor 26 5
E No Safety Effect 0 0

Traceability[edit]

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.

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.

Differences with DO-178B[edit]

SC-205 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]

  • Provide clearer language and terminology, provide more consistency
  • More objectives (for Levels A, B, and C)
  • Clarified the "hidden objective", applicable to Level A, which was implied by DO-178B in section 6.4.4.2b but not listed in the Annex A tables. This objective is now explicitly listed in DO-178C, Annex A, Table A-7, Objective 9: "Verification of additional code, that cannot be traced to Source Code, is achieved."[13]
  • Parameter Data Item Files - Provides separate information that influences the behavior of an executable object code (without changing it). An example would be a configuration file that sets up the schedule and major time frames of a partitioned operating system. The parameter data item file must be verified together with the executable object code, or else it must be tested for all possible ranges of the parameter data items.
  • Technology supplements were added (as separate documents associated with DO-178C):
    • DO-330 "Software Tool Qualification Considerations" - clarifying software tools and avionics tool qualification
    • DO-331 "Model-Based Development and Verification Supplement to DO-178C and DO-278" - addressing Model-Based Development (MBD) and verification and the ability to use modeling techniques to improve development and verification while avoiding pitfalls inherent in some modeling methods
    • DO-332 "Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A" - addressing object-oriented software and the conditions under which it can be used
    • DO-333 "Formal Methods Supplement to DO-178C and DO-278A" - addressing formal methods to complement (but not replace) testing

Sample difference between DO-178B and DO-178C[edit]

Chapter 6.1 defines the purpose for the software verification process. DO-178C adds the following statement about the Executable Object Code: "The Executable Object Code is robust with respect to the software requirements that it can respond correctly to abnormal inputs and conditions." As a comparison, DO-178B states the following with regard to the Executable Object Code: "The Executable Object Code satisfies the software requirements(that is, intended function) and provides confidence in the absence of intended functionality." The additional clarification fills a gap that a software developer may encounter when interpreting the document.[14]

See also[edit]

References[edit]

  1. ^ http://www.rtca.org/store_list.asp
  2. ^ Charlotte Adams (2010-09-01). "DO-178C nears finish line, with credit for modern tools and technologies". Avionics Intelligence. Retrieved 2010-10-23. 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 2010-10-23. The release of these long anticipated standards will occur in mid 2011 and be recognized by the Certification Authorities in 2012. 
  4. ^ http://www.faa.gov/documentLibrary/media/Advisory_Circular/AC_20-115C.pdf
  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. ^ http://forum.pr.erau.edu/SCAS/
  7. ^ Bill StClair & Tim King (2012-03-07). "DO-178C brings modern technology to safety-critical software development". Military Embedded Systems. Retrieved 2012-04-17. 
  8. ^ "DO-178C Enhances Safety-Critical Avionics Software Development". Electronic Design. Electronic Design. Retrieved 2012-04-17. 
  9. ^ a b RTCA/DO-178C "Software Considerations in Airborne Systems and Equipment Certification", p. 116
  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 2009-09-31. D0-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.  Check date values in: |accessdate= (help)
  13. ^ RTCA/DO-178C Software Considerations in Airborne Systems and Equipment Certification. RTCA, Inc. 2011. 
  14. ^ http://alm.parasoft.com/achieving-do178c-compliance/

External links[edit]