DO-278A objectives: 6.4.a, 6.4.b, 6.4.c, 6.4.d

DO-278A objectives §6.4.a-d require testing of the code to ensure that it complies with and is robust with respect to high and low-level requirements.

DO-278A keeps the development and verification processes separate and requires levels of independence between them. Test environments often present tests as code, which can be challenging for test engineers to create and review while remaining independent from the development process.

RapiTest supports test authoring without requiring engineers to write any additional code. Its test steps and expressions reference the software's interface, not its implementation. The underlying integration is flexible and can provide test evidence on any embedded target. Rapita works with your organization to ensure a robust, qualifiable integration with which results can be collected from both on-host and on-target tests. Learn how RapiTest helped Kappa optronics produce DO-178C requirements-based test evidence in our case study.

DO-278A objective: 6.4.e

“...execute the software to confirm that... the Executable Object Code is compatible with the target computer.”

RTCA DO-278A §6.4.e

This objective requires that selected tests, especially Hardware-Software Integration tests, are executed in the target computer environment. Challenges include harnessing low-level (component) tests in the target environment and retrieving outputs (test results) from that environment.

RapiTest lets you specify your test harness as stubs, runs, and checks, and executes the harness in a host, target, or simulated computer environment. Performing checks in that environment minimizes the required data transfer and helps to automate test evaluation and discrepancy analysis. All RVS tools are designed from the ground up to support on-target testing. Learn how RapiTest helped Kappa optronics produce DO-278A requirements-based test evidence on-target in our case study.

Rapita’s Target Integration Service and Qualified Target Integration Service ensure that a robust integration of RVS with the embedded target hardware is deployed and qualified. See how we delivered target and qualified target integrations services to Collins Aerospace in our case study.

DO-278A objective: 6.4.5c

“...ensure that the test results are correct and that discrepancies between actual and expected results are explained.”

RTCA DO-278A §6.4.5.c (Table A-7 2)

This review shows that all tests either pass or fail with a well-understood and agreed justification. The challenge here is to efficiently gather the expected and actual results and check for discrepancies.

RapiTest allows you to define both the set-up actions and the correctness checks for each test. It executes those in the target computer. When a check fails, it provides the expected and actual results to show you the discrepancy. Learn how RapiTest helped Kappa optronics produce DO-278A requirements-based test evidence on-target in our case study.

DO-278A objectives: 6.4.4.a, 6.4.4.b

Traceability is crucial in DO-278A. It links corresponding items in different outputs such as requirements and tests. Challenges include ensuring that engineers can keep traceability information up to date when they make changes and consolidating the traceability information into a single view for presentation and review. Traceability is typically managed by dedicated requirements traceability tools.

RVS tools integrate with commonly used requirements traceability tools such as DOORS, Jama, Polarion and Visure, allowing traceability links to be maintained in a project throughout the project life cycle. Within RVS, traceability is maintained between, for example, test cases and associated structural coverage at the code level, and requirements coverage can be viewed when requirements have been imported from a requirements traceability tool.

DO-278A objectives: 6.4.4.c

Structural coverage analysis (SCA) demonstrates that the code has been sufficiently tested, with the associated coverage criteria dependent on the software DAL. Structural coverage has to be obtained through requirements-based testing and can be obtained by analysis of either source code or object code coverage. The main challenges of SCA include instrumentation overheads for on-target testing, effort required to merge coverage from different test builds, and resolving incomplete structural coverage.

Rapita provides support for both source code and object code based structural coverage analysis through RapiCover and RapiCover ^Zero , respectively. RapiCover’s instrumentation overheads are significantly lower than competitor solutions, allowing coverage to be collected in fewer test builds, therefore reducing test overheads. Where different builds are still needed, results can be merged, and this feature is qualified. RapiCover justifications make it easy to mark code as covered by analysis to resolve coverage gaps, and support is available to migrate justifications when code changes. RapiCover’s instrumentation is qualified, so manual review of applied instrumentation is not required. See how we supported organizations such as Collins Aerospace and Cobham Aerospace Connectivity in their DO-278A structural coverage analysis in our case studies.

DO-278A objectives: 6.4.4.d

Data coupling and control coupling (DCCC) analysis allows integration errors to be identified earlier during the verification life cycle, which can increase software quality and reduce overall verification costs. There is no accepted industry-wide definition of the detailed analyses that are required to meet the objective, and until now, commercial automation tools have lacked the capability and flexibility to support the varying interpretations of DCCC analysis across the safety-critical avionics industry.

Rapita's upcoming RapiCoupling tool will provide flexible, configurable support for DO-278A data and control coupling analysis, including guidance on selecting criteria for the analysis. A case study including use of the tool in collaboration with Collins Aerospace was presented at DASC 2024. Public release of the tool is expected in 2027.

DO-278A objectives: 6.4.4.c

“…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.”

RTCA DO-278A §6.4.4.2.b

The correctness of additional code introduced by a compiler should be verified for DO-278A DAL software. Correctness cannot be demonstrated through coverage alone. DO-248C provides clarifications on expectations for meeting the objective, suggesting some approaches for meeting the objective and stating that it isn’t a trivial task “ the work involved in the process of demonstrating traceability from object code to Source Code may not be trivial”, “ This process is intensive and should be thorough”.

Rapita supports meeting the objective through RapiCover and RapiCover ^Zero to support coverage analysis and traceability, and V&V services to support compiler verification, one of the approaches suggested by DO-248C to meet the DO-278A §6.4.4.c objective. See how we supported the verification of a compiler for an organization developing safety-critical applications in our case study.

More detailed information on this topic is available on the Rapita Systems website.

DO-278A objectives: 6.3.1.f, 6.3.2.f

Traceability is crucial in DO-278A. It links corresponding items in different outputs such as requirements and tests. Challenges include ensuring that engineers can keep traceability information up to date when they make changes and consolidating the traceability information into a single view for presentation and review. Traceability is typically managed by dedicated requirements traceability tools.

RVS tools integrate with commonly used requirements traceability tools such as DOORS, Jama, Polarion and Visure, allowing traceability links to be maintained in a project throughout the project life cycle. Within RVS, traceability is maintained between, for example, test cases and associated structural coverage at the code level, and requirements coverage can be viewed when requirements have been imported from a requirements traceability tool.

DO-278A objectives: 6.3.4.f

“...determine the correctness and consistency of the Source Code … stack usage … worst-case execution time ...”

RTCA DO-278A §6.3.4.f (Table A-5 6)

This review and analysis objective is typically met through additional testing (RTCA DO-278A §6.3, para 2). This testing reveals the dynamics of the source code. The challenge is finding a test environment that can run tests early, and provide that insight, without being significantly different from the environment used for later testing.

RapiTime provides flexible instrumentation and powerful visualization to identify and explore the worst-case behavior of your software. The same interface and workflow can be re-targeted between analysis testing, test case development, and formal on-target testing.

DO-278A objectives: 6.4.3.a

“...This testing method should concentrate on error sources associated with the software operation within the target computer environment … Failure to satisfy execution time requirements ...”

RTCA DO-278A §6.4.3.a (Table A-6 5)

This testing objective executes a range of test suites that are designed to examine interfaces, resource usage, and specific hardware events that cannot be replicated through other testing methods. For execution time analysis, RapiTime presents detailed timing data and associated performance metrics to help validate the effectiveness of the tests.

DO-278A objectives: 6.3.3.f

“The objective is to ensure that partitioning breaches are prevented”

RTCA DO-278A §6.3.3.f

Once you have designed the software architecture, this objective asks for analysis to show that partitions cannot interfere with one another. As well as relying on the RTOS vendor assurance case and reviewing that tasks are configured correctly, the challenge can be to obtain direct evidence of prevention of partitioning breaches on your target configuration.

The RapiTime workflow supports the measurement of tasks that are interrupted, abandoned, or which cause the computer to reset. By inserting deliberate attempts to breach partitioning, you can confirm that your integrity mechanisms are configured and operating correctly. The ability to integrate with multiple environments lets you execute such tests from prototype environments through to the final target.