Your browser does not support JavaScript! Skip to main content
Free 30-day trial DO-178C Handbook RapiCoupling Preview DO-178C Multicore Training Multicore Resources
Rapita Systems
 

Industry leading verification tools & services

Rapita Verification Suite (RVS)

  RapiTest - Unit/system testing  RapiCover - Structural coverage analysis  RapiTime - Timing analysis (inc. WCET)  RapiTask - Scheduling visualization  RapiCoverZero - Zero footprint coverage analysis  RapiTimeZero - Zero footprint timing analysis  RapiTaskZero - Zero footprint scheduling analysis  RapiCouplingPreview - DCCC analysis

Multicore Verification

  MACH178  MACH178 Foundations  Multicore Timing Solution  RapiDaemons

Engineering Services

  V&V Services  Data Coupling & Control Coupling  Object code verification  Qualification  Training  Consultancy  Tool Integration  Support

Industries

  Civil Aviation (DO-178C)   Automotive (ISO 26262)   Military & Defense   Space

Other

RTBx Mx-Suite Software licensing Product life cycle policy RVS Assurance issue policy RVS development roadmap

Latest from Rapita HQ

Latest news

SAIF Autonomy to use RVS to verify their groundbreaking AI platform
RVS 3.22 Launched
Hybrid electric pioneers, Ascendance, join Rapita Systems Trailblazer Partnership Program
Magline joins Rapita Trailblazer Partnership Program to support DO-178 Certification
View News

Latest from the Rapita blog

How to certify multicore processors - what is everyone asking?
Data Coupling Basics in DO-178C
Control Coupling Basics in DO-178C
Components in Data Coupling and Control Coupling
View Blog

Latest discovery pages

control_tower DO-278A Guidance: Introduction to RTCA DO-278 approval
Picture of a car ISO 26262
DCCC Image Data Coupling & Control Coupling
Additional Coe verification thumb Verifying additional code for DO-178C
View Discovery pages

Upcoming events

XPONENTIAL 2025
2025-05-19
Avionics and Testing Innovations 2025
2025-05-20
DASC 2025
2025-09-14
DO-178C Multicore In-person Training (Fort Worth, TX)
2025-10-01
View Events

Technical resources for industry professionals

Latest White papers

Mitigation of interference in multicore processors for A(M)C 20-193
Sysgo WP
Developing DO-178C and ED-12C-certifiable multicore software
DO178C Handbook
Efficient Verification Through the DO-178C Life Cycle
View White papers

Latest Videos

Rapita Systems - Safety Through Quality
Simulation for the Motorola 68020 microprocessor with Sim68020
AI-driven Requirements Traceability for Faster Testing and Certification
Multicore software verification with RVS 3.22
View Videos

Latest Case studies

GMV case study front cover
GMV verify ISO26262 automotive software with RVS
Kappa: Verifying Airborne Video Systems for Air-to-Air Refueling using RVS
Supporting DanLaw with unit testing and code coverage analysis for automotive software
View Case studies

Other Resources

 Webinars

 Brochures

 Product briefs

 Technical notes

 Research projects

 Multicore resources

Discover Rapita

Who we are

The company menu

  • About us
  • Customers
  • Distributors
  • Locations
  • Partners
  • Research projects
  • Contact us

US office

+1 248-957-9801
info@rapitasystems.com
Rapita Systems, Inc.
41131 Vincenti Ct.
Novi
MI 48375
USA

UK office

+44 (0)1904 413945
info@rapitasystems.com
Rapita Systems Ltd.
Atlas House
Osbaldwick Link Road
York, YO10 3JB
UK

Spain office

+34 93 351 02 05
info@rapitasystems.com
Rapita Systems S.L.
Parc UPC, Edificio K2M
c/ Jordi Girona, 1-3
Barcelona 08034
Spain

Working at Rapita

Careers

Careers menu

  • Current opportunities & application process
  • Working at Rapita
Back to Top Contact Us

Breadcrumb

  1. Home

Discover Verifying additional code for DO-178C

  • Guidance
  • Coverage vs. Correctness
  • Traceability & Verification
  • Verifying Additional Code
  • Solutions

DO-178C objective 6.4.4.c includes a required activity to verify additional code introduced by the compiler for DAL A projects. Learn why this activity is different to other activities in 6.4.4.c and how to perform it.

What does the guidance say?

Table A-7 in DO-178C gives a summary of the activities that must be performed to meet objective 6.4.4.c.

The first three items in the table relate to structural coverage analysis, which involves analysis of which elements of the code have been exercised during requirements-based testing. DO-178C clarifies that this analysis may be performed on either the source code or object code.

The final item requires “Verification of additional code, that cannot be traced to Source Code”. The corresponding activity description clarifies that the purpose of this verification is to demonstrate the correctness of such additional code sequences:

Verification activities relating to DO-178C objective 6.4.4.c (Table A-7)
Verification activities relating to DO-178C objective 6.4.4.c
“Structural coverage analysis may be performed on the Source Code, object code, or Executable Object Code. Independent of the code form on which the structural coverage analysis is performed, 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.”
DO-178C §6.4.4.2.b

This activity, which we’ll herein refer to as “object code verification” is often called a “hidden” activity of DO-178C, perhaps because its placement within the 6.4.4.c objective can lead to confusion. At first glance, objective 6.4.4.c is about test coverage of software structure rather than verification, yet activity 6.4.4.2.b clearly requires demonstrating that the correctness of the object code has been verified. Demonstrating coverage and correctness are very different things, as we’ll see below.

Object code verification is an activity required to demonstrate the correctness of additional code introduced by a compiler for DAL A DO-178C projects.

Coverage vs. Correctness

Structural coverage analysis and object code verification are very different activities that demonstrate different things and for which different approaches are required.

Structural coverage analysis helps provide assurance that sufficient software testing has been performed. Its aim is to demonstrate that 100% of the code has been covered during requirements-based testing. The level of coverage achieved does not demonstrate the correctness of the code – this is demonstrated by the results of the requirements-based tests that are run, and during which structural coverage is observed. It would be possible for 100% coverage to be achieved even though some, or even all, requirements-based tests fail to yield their expected results.

The level of code coverage achieved does not demonstrate the correctness of the code

Object code verification, on the other hand, is an activity to demonstrate the correctness of additional code introduced by the compiler. The first step to being able to demonstrate this is understanding which structural elements in the object code map to which structural elements in the source code – this is known as object code to source code traceability.


Validation of Commercial-off-the-shelf Ada Compiler for Safety-Critical Applications case study front cover


Validation of COTS Ada Compiler for
Safety-Critical Applications

Compilers for the Ada programming language are already subject to a compiler conformity assessment, which shows that a given compiler correctly implements the Ada language specification. However, this assessment does not consider the suitability of the generated code for deployment to safety-related applications.

Learn how Rapita conducted a successful Ada compiler validation project.

Download


Object code to source code traceability and object code verification

DO-248C, sometimes referred to as the DO-178C “FAQ”, highlights object code to source code traceability as a necessity for object code verification.

“When performing structural coverage at the Source Code level for Level A software, it is necessary to establish whether or not the object code is directly traceable to the Source Code.”
DO-248C 4.12.1

To establish this traceability, you’ll need to analyze all source code elements and all corresponding object code elements. DO-248C clarifies that the analysis “may not be trivial”, should consider things including “the extent of code optimization, compiler switch options, and object code inserted by the compiler”, and that the process “is intensive and should be thorough”.

Some software automation tools may be helpful in supporting traceability analysis by providing side-by-side views of the source code and the corresponding object code instructions.

DO-248C presents two potential approaches to traceability analysis, which appear different at first glance, but somewhat similar on closer inspection: compiler verification, and target object build verification. A hybrid of the two approaches could also be taken.


Compiler verification

One approach to traceability analysis suggested by DO-248C is to analyze the behavior of the compiler based on the compiler options and programming language constructs used, determine traceability based on these, and identify all potential additional code that doesn’t map to source code. That additional code can then be verified.

“One approach to this analysis is to produce code with fully representative language constructs of the application (for example, case statements, if-then-else statements, loops, etc.) and to analyze the resultant object code. Also, it is important that the individual constructs are completely representative of the constructs used in the target object code build, including complex structures (for example, nested routines).”
DO-248C 4.12.2.2

This process should involve thorough identification of the compiler options and language constructs used to develop software. The compiler verification process may elicit modification of the compiler options or coding standard to minimize traceability discrepancies and reduce the burden on verification of additional code.

The Compiler verification process yields inputs to DO-178C development that can support additional code verification
The Compiler verification process yields inputs to DO-178C development that can support additional code verification

The aim of compiler verification is to identify the source code constructs that generate additional code structures. Starting with a set of compiler options and a coding standard, code constructs can be placed in the different contexts in which they can appear in a program.

After compiling such code, you can examine the resulting object code to identify what source code constructs, if any, will yield additional code constructs in the object code. You may also feed information back to adjust the coding standard and the chosen compiler options to eliminate the use of such source code constructs. Based on the additional code discovered in this way, you can create guidance on how to specify and verify this code through your normal software development life cycle.

While the process is effort-intensive, once it has been done for a specific compiler and coding standard, it doesn’t need to be repeated – you can continue to use the same compiler, compiler options, and language constructs (based on a curated coding standard) without additional verification in future projects.


Target object build verification

The second suggested approach suggested by DO-248C for traceability analysis is to “examine the target object code build” (DO-248C 4.12.2.2). Rather than verifying all potential behaviors of the compiler and code, this focuses analysis on the specific code used.

The target object build verification process can identify additional code in a specific object build to support its verification
The target object build verification process can identify additional code in a specific object build to support its verification

The aim here is to take the object code that results from the software development process and examine this directly to identify any additional code constructs in the object code. If such object code exists, then you go back to the software development process, update the requirements to specify the correct behavior of the additional code constructs, and then verify that the code meets those requirements. You may also update the compiler options and coding standard used to attempt to eliminate or mitigate additional code.

An advantage of this approach may be that it’s less involved than compiler verification for a single iteration of the process, but this is counterbalanced by a major disadvantage: the whole process would need to be repeated if any changes are made to the source code or compiler options.


Hybrid verification

The major cost with target object build verification is the unexpected discovery of object code introduced by the compiler late in the development life cycle, and the major cost associated with up-front compiler verification is the number of cases needed for a thorough analysis. An alternative approach here is to still rely on the target object build verification, but supplement this with up-front analysis. In the initial analysis, you could focus on verification cases that are likely to cause the introduction of additional code. This will help you choose a coding standard, compiler, and compiler settings that minimize the likelihood of ending up with unexpected additional object code that’s expensive to verify.

As the assurance case for this approach is based on target object build verification, this approach can increase flexibility. For example, you might deploy compiler verification across several projects using the same compiler. The first project would assess only the most common risk areas, while later projects would cover increasingly many cases to build up to a full compiler verification.

Verifying additional code

After selecting your compiler, compiler options, and coding standards, you may still have some additional compiler-introduced code. Examples of additional code introduced by the compiler can include things like virtual call dispatch code, compiler-inserted checks such as array index bound or type compatibility checks, and run-time library support code. No matter the type of additional object code, you’ll need to verify its correctness.

Neither DO-178C nor DO-248C provides specific guidance on how to verify the correctness of additional code introduced by the compiler.

As the purpose of object code verification is to verify the correctness of additional code, it stands to reason that the first step should be to introduce derived requirements for that additional code.

Then, you can either expand your requirements-based test suite to verify those requirements, verifying testing sufficiency using structural coverage analysis, or verify the requirements through analysis and resolve coverage gaps (features in your coverage analysis tool, such as RapiCover’s justifications mechanism may support this).

How we can help

Rapita Systems provides compiler verification services to support object code verification. Through this service, we identify compiler options and provide recommendations on modifications to compiler options and coding standards to reduce the amount of additional code and thus burden for verifying it. See our case study for more information. We can also support verification of additional code, identifying it, and verifying its correctness through requirements-based testing or analysis.

RapiCoverZero, our automated object code structural coverage analysis tool, supports viewing object code and source code side by side with highlighting of covered object code and traced source code, which can help during object code to source code traceability analysis. Both RapiCoverZero, and RapiCover, our automated source code structural coverage analysis tool, include a justifications feature that lets you mark additional code you have verified by manual analysis as having been verified, and includes this in results exports submissible for DO-178C.

Related product
RapiCover
RapiCoverZero
Verification and Validation Services logo

Proven testing solutions for critical software

Rapita Employees conducting RVS training
 
Choose your free resource:
When you contact us, we will process your personal data in accordance with our data protection policy, please see our Customer Privacy Information for more information.
  • Solutions
    • Rapita Verification Suite
    • RapiTest
    • RapiCover
    • RapiTime
    • RapiTask
    • MACH178

    • Verification and Validation Services
    • Qualification
    • Training
    • Integration
  • Latest
  • Latest menu

    • News
    • Blog
    • Events
    • Videos
  • Downloads
  • Downloads menu

    • Brochures
    • Webinars
    • White Papers
    • Case Studies
    • Product briefs
    • Technical notes
    • Software licensing
  • Company
  • Company menu

    • About Rapita
    • Careers
    • Customers
    • Distributors
    • Industries
    • Locations
    • Partners
    • Research projects
    • Contact
  • Discover
    • Multicore Timing Analysis
    • Embedded Software Testing Tools
    • Worst Case Execution Time
    • WCET Tools
    • Code coverage for Ada, C & C++
    • MC/DC Coverage
    • Verifying additional code for DO-178C
    • Timing analysis (WCET) & Code coverage for MATLAB® Simulink®
    • Data Coupling & Control Coupling
    • Aerospace Software Testing
    • Automotive Software Testing
    • Certifying eVTOL
    • DO-178C
    • AC 20-193 and AMC 20-193
    • ISO 26262
    • What is CAST-32A?

All materials © Rapita Systems Ltd. 2025 - All rights reserved | Privacy information | Trademark notice Subscribe to our newsletter