RTCA DO-278A (also known as EUROCAE ED-109A) “Guidelines for Communication, Navigation, Surveillance, and Air Traffic Management (CNS/ATM) Systems Software Integrity Assurance” is used in developing software associated with ground-based systems that are involved with aircraft operations.
RTCA DO-278A is a document that provides guidance for the development of software for communication, navigation, surveillance, and air traffic management (CNS/ATM) systems. Its full title is “DO-278A, Software Integrity Assurance Considerations for Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM) Systems.”
EUROCAE ED-109A is the same document as DO-278A. The alternative nomenclature is used to align with EUROCAE naming conventions.
DO-278 was written as a supplemental document to modify the guidance of DO-178B for CNS/ATM software. Hence, both DO-178B and DO-278 together were to be referenced for the ground side.
DO-178C and DO-278A were developed in tandem, and for the most part are remarkably similar.
For airborne systems, DO-178C is the key document and it is a direct derivative of DO-178B. On the ground side, DO-278A is the key document, but it is not a direct derivative of DO-278. Rather, DO-278A combines the guidance of DO-178C and DO-278 to produce a stand-alone reference for ground-based software verification.
The lengthy name attributed to DO-278A, “Guidelines for Communication, Navigation, Surveillance, and Air Traffic Management (CNS/ATM) systems software integrity assurance”, hints at the relationship it has with DO-178C. DO-278A was deliberately designed to be analogous to DO-178C and was developed in tandem with it. For the most part, developers who are familiar with DO-178C terminology, practices, and processes will be similarly comfortable with the DO-278A guidelines & objectives. There are differences only where necessary.
Despite the similarity between DO-178C and DO-278A, there are some differences to be aware of.
Many of these differences simply concern differing terminology reflecting the differing circumstances. For example:
DO-178C DALs map directly to DO-278A ALs with one exception. There is no equivalent to DO-278A’s AL4, which was included to account for certain CNS/ATM systems where AL-3 was too stringent, and AL-5 was too lenient.
DAL C and AL3 are each concerned with how software is designed and implemented. On the other hand, DAL D and AL5 are concerned only that software fulfils its intended function within a system-level engineering process. AL4 represents a “halfway house” in that it retains some design-level verification (unlike AL5) but it does not require any code-level analysis (unlike AL3).
This is pertinent to DO-278A but not DO-178C because ground-based systems often make far more extensive use of both COTS and legacy technologies.
CNS/ATM system developers and certification authorities are generally more accepting of reused proven technology, even if not developed in accordance with DO-278A. As a result, DO-278A provides explicit provisions for potentially utilizing “alternate methods” which become Alternate Means of Compliance (AMC). Software that has been verified as compliant using an alternative method is assured to AL4.
There are several standards and other documents that are intended to be used as a collective in the development of software systems that are applicable to civil avionics systems.
DO-330 “Software tool qualifications considerations.”
The term “tool qualification” is a broad description of a process aimed at guaranteeing that the risk of a tool error affecting the safety of a system is sufficiently low—either due to a low occurrence of errors or because such errors cannot compromise safety. DO-330 outlines the tool qualification process for tools employed in meeting the objectives outlined in DO-178C and
DO-278A, incorporating provisions for the addition of AL4 in the latter case. Unlike other supplementary documents like DO-332 and DO-333, DO-330 is also intended for use in various domains beyond aviation.
DO-332 “Object Oriented Technology and related technologies supplement to DO-178C and DO-278A”.
DO-332 complements DO-178C and DO-278A by introducing extra objectives relevant to the use of object-oriented programming and associated practices. It also offers guidance on how to approach the objectives outlined in DO-278A within an Object-Oriented (OO) environment.
DO-333 “Formal Methods Supplement to DO-178C and DO-278A”.
DO-333 serves as a supplement to DO-178C and DO-278A, introducing additional objectives relevant when incorporating formal methods into a software life cycle. Furthermore, it offers guidance on how to approach the objectives outlined in DO-278A when formal methods are used.
CAST-32A, authored by the Certification Authorities Software Team (CAST), was a Position Paper addressing the challenges posed by multicore processors (MCPs) in civil aviation. This document outlines a set of objectives to adhere to when incorporating such processors into projects compliant with DO-178C or DO-278A. Despite not constituting official guidance, CAST papers carry authority, and their recommendations are often embraced even before formal integration into subsequent published standards.
For projects falling under EASA’s jurisdiction, CAST-32A has been deprecated, and a similar phase-out is anticipated for FAA-overseen projects. Its directives concerning multicore processors have been assimilated into the harmonized standards EASA AMC 20-193 and FAA AC 20-193, collectively known as A(M)C 20-193. The guidance provided in these documents is intended to complement DO-178C and other related standards like DO-278A.
The LDRA tool suite supports the use of MCPs, which brings a host of challenges associated with interference paths and their potential impact on worst-case execution timing (WCET).
DO-278A encompasses the entire software lifecycle, including planning, development, and integral processes aimed at guaranteeing correctness and robustness in the software. These integral processes encompass software verification, software quality assurance, configuration management assurance, and certification liaison with regulatory authorities.
While developers are not compelled to use analysis, test, and traceability tools, their adoption enhances efficiency in all but the most straightforward projects. The level of effort is commensurate with the risk associated with potential software failures, thus directly proportionate to the Assurance Level (AL) assigned to it.
The DO-278A standard calls for phased development with the application of verification and validation techniques along the way to confirm compliance with the standard. LDRA verification tools lend themselves to that approach.
The LDRA tools conduct static analysis on the code, aligning with the recommended practices of DO-278A. Static analysis can be likened to an automated “inspection” of the source code, where the code under review is compared to the selected software coding standard. Any non-conformances, as mandated by DO-278A, are identified, along with other undesirable characteristics like elevated complexity.
Dynamic analysis involves executing a portion or the entirety of the code during low-level (unit) tests, integration tests, and system tests. The primary objectives are to demonstrate that the code has been sufficiently exercised and aligns with the specified requirements. The dynamic test capabilities, specifically conducted on the target system, play a vital role in confirming the suitability of the code for its intended environment.
Structural coverage is employed to pinpoint which code structures and component interfaces are activated during the execution of requirements-based test procedures, providing an empirical measurement of the effectiveness of these tests. The results of this structural coverage analysis are scrutinized to identify any parts of the code that haven’t been adequately exercised, and the reasons behind it. The required coverage level corresponds to the Assurance Level (AL) assigned to the software being developed.
DO-278A mandates that systems requirements must be traceable throughout every development stage, and conversely, to ensure the full traceability of the code base back to requirements. LDRA employs a comprehensive, role-based approach to traceability.
Team members can be assigned systems requirements and verification tasks, and all resulting artefacts can be consolidated and interconnected. This results in a thorough bidirectional process throughout the life cycle, guaranteeing that any modifications to requirements, design, or source code are easily comprehensible, verified, and traceable.
LDRA tools assist in identifying changes in requirements or the developed software and facilitate the seamless organization and rerunning of appropriate tests for any affected components. They create an optimal environment for conducting impact analysis, whether upstream to requirements or design, or downstream to implementation and testing.
DO-278A places considerable importance on test coverage, including this data and control coupling emphasis in §6.4.4:
“The objectives for test coverage analysis are…
LDRA verification tools offer the capability to meet the coupling metrics requirements outlined in DO-278A, as exemplified by this data coupling reporting.
The objective is to demonstrate that software modules influence each other as intended by the software design, preventing unintended, anomalous, or erroneous behaviours. Documenting data and control coupling during the design phase establishes a set of requirements to be tested during the software integration process. Similarly, validating that the data and control coupling between modules are exercised and exhibit no faults during software testing serves as evidence that the software’s integration and architecture are thoroughly verified.
In addition to statement and branch coverage, for level 1 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 verification tools provide a mechanism to automate that process.
For Level 1 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-278A 6.4.4.2.b states:
“if the assurance level is A1 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”
Automating the verification process can significantly enhance efficiency in providing evidence for that verification. Given the direct one-to-one correlation between object code and assembly code, this relationship can be established by comparing a graphical representation of the source code with that of the equivalent assembly code. Object Code Verification (OCV) assesses code coverage at both the source and assembly levels by sequentially instrumenting each.
The LDRA Tool Qualification Support Packs (TQSPs) contain the test cases to establish both the tool suite’s structural coverage analysis and programming rules checking capabilities, aligning with the DO-330 Software Tool Qualification. Additionally, they provide related documentation for product development and verification, encompassing plans, procedures, and anticipated outcomes.
Technical note: LDRA tool suite and DO 278A
Technical Briefing: DO-178C: Get on a High with your software development
Technical White Paper: Verification of Airborne Software in Compliance with DO-178C
LDRA Tool Qualification Support Packs
Technical white paper: Developing compliant critical software systems with multicore processors
Technical briefing: Getting to grips with A(M)C 20-193
Technical white paper: Following the recommendations of A(M)C 20-193
On Demand DO-178C “First Flight” Self-paced online training course
Ensuring the compliance of avionics software with DO-178C
Richland technologies case study
DO-330 Test tool qualification for aerospace applications
Technical white paper: Developing compliant critical software systems with multicore processors
LDRA Productivity Package – Aerospace and Defense Data Sheet
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707