DO-178C Standard

已剪辑自: https://ldra.com/do-178/

DO-178C/ED-12C (henceforth DO-178C) is the primary document referenced by certification authorities including the FAA, EASA and Transport Canada to approve all commercial software-based civil aviation systems. The document is jointly published by RTCA (formerly the Radio Technical Committee for Aeronautics) and EUROCAE.

DO-178C Software considerations in airborne systems and equipment certification: What it is, where it came from, and how it is applied

What is DO-178C?

DO-178C is a formal process standard that covers the complete software lifecycle – planning, development and integral processes – to ensure correctness and robustness in software systems for civil airborne applications. The integral processes include software verification, software quality assurance, configuration management assurance and certification liaison with the regulatory authorities. Increasingly, standards developed for the commercial aviation including DO-178C have also become recognised as best practice in the defence sector.

What is the difference between DO-178C and DO-178B?

In January 2012 DO-178C replaced the long-standing DO-178B standard as the de facto reference for the development of embedded software in the civil aviation sector. Its introduction improved safety requirements and the accommodation of new technologies for development and verification in civil aviation.

LDRA has participated extensively on both the DO-178B and DO-178C committees over nearly two decades. Mike Hennell, LDRA’s CEO, was instrumental in the inclusion of several test measurement objectives in the standard, including those relating to structural coverage analysis. The LDRA tool suite*®* was itself a forerunner in automated verification for certification to DO-178B.

What other standards are related to DO-178C?

There are several standards and other documents that are intended to be use as a collective in the development of software systems that are applicable to civil aviation.

DO-178C and DO-278A/ED-109

DO-278A is entitled “Guidelines for communication, navigation, surveillance and air traffic management (CNS/ATM) system software integrity assurance.” It serves a similar purpose for ground based systems as DO-178C does for airborne systems, and was developed in parallel to it. As a result, around 75% of it is similar.

DO-178C and DO-330/ED-215

DO-330 is called “Software tool qualifications considerations”. “Tool qualification” is a generic term to describe a process designed to ensure that the risk of a tool error impacting the safety of a system is acceptably low – either because the errors are few, or because they cannot impact safety. DO-330 provides tool qualification for tools to be used in achieving the objectives described in DO-178C and DO-278A. It is also designed for use in other domains unlike the other supplementary documents DO-332 and DO-333.

DO-178C and DO-332/ED-217

DO-332 is entitled “Object Oriented Technology and related technologies supplement to DO-178C and DO-278A”. It is supplementary to DO-178C and DO-278A and includes additional objectives that apply when using object-oriented programming and complementary practices. It also provides advice on how the objectives in DO-178C should be approached in the Object Oriented (OO) environment.

DO-178C and DO-333/ED-218

DO-333 is called “Formal Methods Supplement to DO-178C and DO-278A”. It is supplementary to DO-178C and DO-278A, and identifies additional objectives that apply when using formal methods as part of a software life cycle. It also provides advice on how the objectives in DO-178C should be approached when formal methods are being applied.

DO-178C and CAST-32A

CAST-32A is a Position Paper relating to multicore processors, written by the Certification Authorities Software Team (CAST). Multicore processors are a relatively new challenge in the world of civil aviation, and this paper describes a set of objectives to be fulfilled when such devices are selected for use in a DO-178C compliant project. Although CAST papers do not represent official guidance, they are authoritative and their advice is often adopted even before it is formally integrated into subsequent published standards.

DO-178C and AC 20-193/AMC 20-193

CAST-32A will be deprecated when its recommendations relating to multicore processors are incorporated in both the harmonized standards EASA AMC 20-193 and FAA AC 20-193 known collectively as A(M)C 20-193. The advice and guidance in these documents is designed to be supplemental to DO-178C and other avionics related standards such as DO‑278A.

What does DAL mean in the context of DO-178C?

DAL is an abbreviation for Development Assurance Level, sometimes referred to a simply a Level. The ARP 4754A standard dictates that functional hazard analyses and system safety assessments are completed prior to a system’s development. A Development Assurance Level (DAL) is assigned accordingly for that system, and for the subsystems that implement its hardware and software requirements. The DO-178C standard then provides detailed guidance for the development and verification of safety critical airborne software systems in accordance with the assigned DAL, such that the effort and expense of producing such as a flight control system is necessarily higher than that required to produce (say) a bathroom smoke detector.

What is involved with DO-178C compliance?

DO-178C covers the complete software lifecycle: planning, development and integral processes to ensure correctness and robustness in the software. The integral processes include software verification, software quality assurance, configuration management assurance and certification liaison with the regulatory authorities and although they do not oblige developers to use analysis, test, and traceability tools in their work, such tools improve efficiency in all but the most trivial projects to the extent that they have a significant part to play. The extent of the work is proportionate to the risk involved should the software fail, and hence is proportionate to that DAL applied to it.

How does LDRA help with DO-178C compliance?

The DO-178C standard calls for phased development approach, with the application of verification and validation techniques along the way to confirm compliance with the standard.

Static analysis

LDRA tools perform static analysis on the code in accordance with DO-178C’s recommended practices. Static analysis can be likened to an automated “inspection” of the source code, comparing the code under review with the chosen software coding standard. Non-conformances are highlighted as required by DO-178C, along with other undesirable characteristics such as high complexity.

Dynamic analysis

The use of LDRA tools’ dynamic analysis capabilities involve the execution of some or all of the code as part of low-level (unit) test, integration test, and system test. The objective here is to show that it has been exercised sufficiently and that it behaves in accordance with requirements. The on-target, dynamic test capabilities are particularly important in demonstrating that the code is appropriate for its target environment.

Structural coverage is used to identify which code structures and component interfaces have been exercised during the execution of requirements-based test procedures, facilitating the empirical measurement of requirements-based test effectiveness. As the name implies, structural coverage analysis involves the scrutiny of the structural coverage to determine if there are any parts of the code which have not been sufficiently exercised, and if not, why. The level of coverage require is proportionate to the DAL of the software under development.

Bidirectional requirements traceability

DO-178C insists that requirements should be traceable through to every stage of development, and vice versa to ensure that the whole code base is traceable to requirements. LDRA provides a comprehensive, role-based approach to traceability.

Requirements and verification tasks can be assigned to team members, and all resulting artefacts can be aggregated and linked. The result is a complete bidirectional process across the life cycle, ensuring that any changes to requirements, design, or source code are easily understood, verified, and traced.

LDRA tools help to detect changes in requirements or the developed software and easily organise and re-run appropriate tests against any affected components. They provide an optimal environment for determining impact analysis either upstream to requirements or design or downsteam to implementation and test.

Data Coupling and Control Coupling

LDRA tools provide the facility to fulfil DO-178C’s requirements for coupling metrics to be used to improve software quality throughout the software design and verification process. The intent is to show that the software modules affect one another only in the ways intended by the software design, ensuring that there are no unplanned, anomalous, or erroneous behaviours. Documenting data and control coupling during design provides a set of requirements to test during the software integration process. Similarly, ensuring that the data and control coupling between modules are exercised and exhibit no faults during software test demonstrates that the integration and architecture of the software is fully verified.

Modified Condition / Decision Coverage (MC/DC)

In addition to statement and branch coverage, for level A software MC/DC coverage is obligatory. MC/DC requires that ‘Each condition in a decision has been shown to independently affect that decision’s outcome’. LDRA tools provide a mechanism to automate that process.

Object Code Verification (OCV)

For Level A systems, structural coverage at the source level isn’t enough. Compilers often add additional code or alter control flow, and often their behaviour is not deterministic. To ensure that functionality is not compromised, DO-178C 6.4.4.2.b states:

“if the software level is A and a compiler, linker, or other means generates additional code that is not directly traceable to Source Code statements, then additional verification should be performed to establish the correctness of such generated code sequences”

An automated mechanism to provide evidence of that verification can make that process much more efficient. Because there is a direct one-to-one relationship between object code and assembly code, one way for a tool to represent this is to display a graphical representation of the source code alongside the equivalent representation of the assembly code. Object Code Verification (OCV) measures code coverage at both the source and the assembly level by instrumenting each in turn

Tool Qualification

The LDRA Tool Qualification Support Packs (TQSPs) contain the test cases to demonstrate both the structural coverage analysis and programming rules checking capabilities of the tool suite itself in accordance with DO-330. In addition, associated documentation for the development and verification of the product is provided, including plans, procedures, and expected results.

Additional information

DO-178C pdf free downloads

DO-178C further information