How Do Aerospace and Defense Teams Build Certification Evidence From Day One?

By Rafael Taubinger, Industry Insight Lead & Technical Advisor, and Shawn Prestridge, Senior Field Application Engineer & US FAE Manager

Sooner or later in every certification review, an assessor asks a simple question: how do you know? How do you know the code follows the standard, the tests covered it, and the tool that said so was right?

In aerospace and defense, software is now safety- and mission-critical infrastructure. Flight control computers, avionics displays, mission systems, radar platforms, and uncrewed vehicles run code whose correctness and compliance must be demonstrated through testing, verification, and traceable evidence, often for 20 years or more. RTCA DO-178C governs airborne software, DO-278A covers ground-based systems, and DO-330 covers tool qualification. Many other defense products, such as sonar, soldier-worn systems, and missile electronics, fall under program-specific assurance requirements. The evidence question stays the same.

The hard part is not only writing high-quality software. It is showing, with evidence, that the software came out of a rigorous process and that every tool in that process can be trusted. In most programs, the difficulty starts with how the toolchain was put together.

Aerospace and defense software certification involves much more than software development alone. Requirements management, planning, reviews, configuration management, verification, and tool qualification all play important roles. This article focuses specifically on the development and verification toolchain and the evidence it produces to support certification activities.

Where Does All the Aerospace Software Certification Effort Go?

A significant part of the development and verification effort lies in demonstrating that tools operate as intended within the project's environment and processes. Many programs still run on toolchains assembled over years. The compiler comes from one vendor, static analysis from another, coverage  analysis from a third, and qualification evidence may sit in a separate repository managed by a different team.

That approach can work, but maintaining traceability, consistency, and confidence in the generated evidence often requires considerable effort during verification and certification activities.

Typical challenges:

• Evidence is hard to trace from requirement to result
• Tool outputs need validation before they can be trusted
• Defects surface late, when fixing them means re-verification and schedule risk
• Architectural problems stay hidden until integration
• Build environments are very difficult to reproduce years later

The result is that teams spend significant effort managing certification evidence instead of focusing on product development and verification. For program managers, that shows up as schedule slips, rework, and recertification cost that was not in the plan. Adding one more tool at the end does not fix that. What helps is picturing the whole software stack first, then deciding what each layer needs to prove.

What Does a DO-178C Certifiable Software Stack Look Like for Avionics and Defense?

It helps to picture the software as layers, with quality running up the side of every one:

• Foundation: the hardware and the toolchain that builds for it
• Application: your control, signal-processing, or mission code, with an RTOS or middleware underneath and, where operators interact with the system, application frameworks and user interfaces running on top
• Quality: analysis, coverage, and test across every layer

Figure 1. A layered view of a certifiable software stack. The IAR Platform provides the foundation, the operating system and Qt technologies support application and UI development, and Axivion, Coco, and Squish provide quality, testing, coverage, and verification across every layer.

Certification evidence has to exist at each layer, and it has to connect from one layer to the next. If the foundation is doubtful, everything above it inherits the doubt. So the order of decisions matters. Start at the bottom.

What Does a Certifiable Build Toolchain for Avionics and Defense Software Look Like?

It starts at the layer closest to the hardware, because the compiler turns your source into the binary that actually flies.  Certification activities extend throughout the development lifecycle, not just the final stages of a project. The development toolchain therefore becomes a critical part of the overall software assurance strategy, providing predictable and qualified code generation, reproducible builds, and the documentation needed to support certification activities.

IAR Embedded Workbench, part of the IAR Platform, is TÜV SÜD-certified for Arm, RISC-V, Renesas RX, RL78, RH850, and STM8. It ships with a certificate for IEC 61508, ISO 26262, EN 50128, and more, plus a TÜV SÜD safety report and a safety manual. That certification does not replace DO-178C. It gives you an independently assessed process foundation on which to build your own certification argument.

What the foundation provides:

• Reproducible builds: with controlled build settings, the same sources and the same toolchain version produce the same binary
• Air-gapped operation: offline license activation and on-premises IAR Build Tools keep work moving in restricted defense environments
• Silicon flexibility: one toolchain across Renesas RH850, Arm Cortex-M/R/A microcontrollers and processors from multiple vendors, heterogeneous systems combining application and real-time processing, radiation-tolerant Arm devices for space, and RISC-V for future platforms.

A common development platform across device families helps teams maintain consistent processes, documentation, and certification artifacts instead of recreating them for every new target.

While these capabilities primarily support day-to-day development, they also help establish the traceability and documentation needed throughout verification and certification activities. With the foundation settled, attention turns to the code that runs on it, and to the quality layer that runs up the side of every layer.

How Do You Verify Avionics Software Across Every Layer for DO-178C?

You verify it with tools that cover the code and its testing, up the side of the stack. Axivion, Coco, and Squish cover the foundation and the application, whether the code is a control loop or a display. Each contributes a different type of evidence within a certification-oriented development and verification workflow. One of the earliest verification activities is ensuring compliance with established coding standards through continuous analysis of the source code.

How Does Static Analysis with MISRA and CERT Support DO-178C Verification?

Static analysis finds defects early, allowing reviews and testing activities to focus on verification rather than finding basic code-quality issues later in the process. Axivion Static Code Analysis checks C and C++ continuously against MISRA C, MISRA C++, CERT C/C++, and CWE rules, long before formal verification begins.

Early defect detection is one benefit. The less obvious one is evidence: a continuous record of coding-standard compliance helps demonstrate that coding requirements were applied throughout the project, not checked only before a review. But clean code can still sit inside a flawed design, so verification must also extend beyond individual source files to the software architecture.

How Do You Verify Software Architecture in Safety-Critical Aerospace Systems?

You compare the implementation with the intended design, continuously. Some of the most serious risks never show up as coding errors. Weak subsystem separation, unintended dependencies, and security-relevant design decisions can pass code-level checks and still undermine safety objectives.

Axivion Architecture Verification flags unwanted dependencies, separation violations, and architectural drift. In a radar or sensor platform that has grown through a decade of upgrades, drift is often where the real risk hides. With the code and the design verified, the next step is demonstrating how thoroughly testing exercised the implemented software.

How Does MC/DC Code Coverage Support DO-178C Verification?

It gives assessors objective proof that verification was complete. Testing is essential, but testing alone is not evidence. DO-178C ties the structural coverage you must show to the software level:

Coco Code Coverage Testing measures coverage up to and including Modified Condition/Decision Coverage (MC/DC), so you can determine what the tests exercised and what they missed. Two planning notes for engineers: coverage is measured at source level, and at Level A you may need additional verification where object code is not directly traceable to source. Instrumentation also adds code size and execution overhead, which matters on small microcontrollers.  For many aerospace and defense systems, software verification extends beyond embedded code. Cockpit displays, mission systems, operator consoles, ground-control stations, and handheld devices all introduce a user-interface layer that must be verified alongside the underlying application logic.

How Do You Automate GUI Testing for Avionics and Cockpit Displays?

User interfaces are increasingly important in aerospace and defense systems, from cockpit and mission displays to operator consoles, ground-control stations, handheld devices, and soldier-worn equipment. These interfaces must be verified with the same rigor as the underlying application logic. For systems with advanced graphical user interfaces, many aerospace and defense teams use the Qt Framework to build cockpit displays, mission systems, ground-control stations, operator consoles, and other safety- and mission-critical user interfaces. For microcontroller-based systems, Qt for MCUs brings modern graphics to constrained hardware and integrates with IAR, allowing interface and control code to share one compiler and one build.

Squish automates GUI testing across the interface layer, so regressions in cockpit, console, and handheld displays are caught as the software changes, not after integration. Interface code is still code, and it goes through the same analysis and testing as everything else. Every tool along the way, from compiler to analyzer to coverage to test, produces results someone will rely on. That brings back the last part of the assessor’s question: was the tool right?

What Is DO-330 Tool Qualification, and Why Does It Matter for DO-178C and DO-278A?

DO-330 is how you show that a tool’s results can be trusted. If certification evidence relies on a tool's output, teams must be able to demonstrate that those results can be trusted. Building that qualification evidence yourself is slow and costly.

While development tools such as compilers are often supported by supplier documentation, safety evidence, and established project processes, verification tools frequently require additional qualification activities when their outputs are relied upon for certification evidence. Qualification kits for Axivion, Coco, and Squish support DO-330 tool qualification in DO-178C and DO-278A programs. Your team starts with established materials instead of a blank page and spends less time proving its tools work. Each kit is scoped per project, so qualification still belongs in your certification plan. Qualified tools and clean evidence answer today’s review. Some programs also have to answer the same questions many years from now.

How Do You Keep a Certified Build Toolchain Reproducible for Decades of Aerospace and Defense Service?

You hold tool versions stable and keep the ability to rebuild the same binary in the same validated environment. Software released today may still be maintained and recertified in 20 years, so that takes controlled updates across every layer of the stack.

This is not theoretical. Many fielded systems still run on 8-bit and 16-bit microcontrollers in acoustic sensors, signal-processing modules, and small-arms electronics that have been in service for years. Aerospace teams ask for older compiler versions because the only way to prove a fielded unit is unchanged is to recreate its exact binary. If the toolchain was not preserved, that proof is impossible.

IAR Long-Term Support (LTS) Services hold a certified toolchain version stable under a multi-year agreement of up to 20 years, with Validated Service Packs and regular Known Problem Reports. Combined with Qt Long-Term Support (LTS) Releases for the application framework, organizations can maintain a stable, supported software stack from compiler through user interface while minimizing change-related risks.

Together with reproducible builds, they preserve the traceability that certification depends on. That is what long-term predictability looks like in practice. These layers cover a lot of ground, but not all of it, and it is worth being clear about where the edges are.

Key Areas to Review in a DO-178C Development and Verification Environment

When assessing a certification-oriented development workflow, organizations typically examine questions such as:

• Can we rebuild this exact binary in five or ten years?
• Can we show our coding standard was enforced throughout the project?
• Does our coverage evidence match the software level we claimed?
• Do we know which of our tools need qualification, and who owns that evidence?
• Does our architecture match our design, or has it drifted?

These questions do not cover every aspect of a DO-178C program, but they highlight the areas where development and verification tools can have the greatest impact on quality, traceability, and certification effort.

From Code to Flight, a Simpler Path to Aerospace and Defense Software Certification

Back to the question every review starts with: how do you know? Modern aerospace and defense development needs a connected stack where the foundation, the application, and the quality layer support each other, and where evidence builds up as a byproduct of the work.

With the IAR Platform as the foundation, Qt framework powering application and user-interface development, and Axivion, Coco, and Squish covering analysis, coverage, and testing, teams gain an integrated workflow that improves quality, strengthens traceability, and simplifies verification for certification-focused projects. From code to flight, confidence starts with the foundation.