What Counts as Software Under DO-178C? Understanding the True Scope of Airborne Software Certification

When developing airborne systems, one of the most critical aspects of certification is understanding what the term “software” actually means under DO-178C — the Software Considerations in Airborne Systems and Equipment Certification standard.

This definition has far-reaching implications: it determines what components must follow the DO-178C software life cycle, what artifacts must be produced, and how verification and certification evidence are generated. Misinterpreting it can lead to costly rework, compliance gaps, or unnecessary certification effort.

Let’s explore how DO-178C defines software, what’s included within its scope, and how this understanding shapes the certification process.

The DO-178C Definition of Software

The RTCA DO-178C (and its European counterpart EUROCAE ED-12C) defines software as:

Software: Computer programs and, possibly, associated documentation and data pertaining to the operation of a computer system.

Software product: The set of computer programs, and associated documentation and data, designated for delivery to a user. This term refers to software intended for use in airborne applications and the associated software life cycle data.

In simpler terms, under DO-178C, software includes everything executed, used, or required by an airborne computer to perform its intended function. This definition goes beyond just source code — it covers all digital elements that influence how the software behaves, executes, or interacts with other system components.

System Requirement Allocation and Software Scope

According to ARP 4754A, system-level requirements are allocated to either hardware or software, depending on which element implements them.

This allocation process is fundamental: it defines the boundary between hardware and software responsibilities, ensuring each is developed and verified under the correct assurance standard.

Figure: Overall system development process taken from ARP 4754A

In practice:

• Any system requirement that does not rely on physical hardware behavior is considered a software requirement.

• Functions implemented through code, algorithms, or digital processing fall under DO-178C.

• Requirements tied to electrical characteristics, timing signals, or physical components are allocated to hardware and governed by DO-254, the hardware counterpart to DO-178C.

For example, data processing, control laws, and fault detection logic realized through code are classified as software functions, while signal conditioning circuits or sensor interfaces fall under hardware.

FPGA Logic: Hardware, Not Software

In airborne systems, Field Programmable Gate Array (FPGA) logic is classified as hardware, even though it is “programmed” using code-like languages such as VHDL or Verilog.

Under DO-254 (Design Assurance Guidance for Airborne Electronic Hardware), FPGA designs are treated as electronic hardware because they define physical signal paths, timing relationships, and logic gates. The FPGA bitstream determines hardware behavior—it does not execute instructions like a processor running software.

Thus, FPGA design and verification are performed under DO-254, while the software that interacts with the FPGA follows DO-178C.

What Is Considered Software Under DO-178C

DO-178C and its companion document DO-248C clarify that software includes any computer-executed logic that contributes to an airborne function. This includes:

1. Executable Code

All compiled, assembled, or interpreted code executed on the target hardware is software. Whether written in C, Ada, or assembly, it falls under DO-178C once it becomes part of the airborne executable image. Automatically generated code from tools (e.g., model-based design) is also covered, with tool qualification managed under DO-330.

This category includes bootloaders, Board Support Packages (BSPs), and firmware when they execute on a processor and directly influence the software’s operational behavior. Bootloaders and BSPs are responsible for initializing hardware components, setting up memory maps, and preparing the environment for higher-level applications. As such, they form part of the airborne software configuration and must be developed, verified, and managed in accordance with DO-178C objectives.

However, it is important to distinguish between processor-executed firmware and programmable logic firmware, such as FPGA or ASIC configurations. While the former is considered software under DO-178C, the latter defines hardware behavior and is governed by DO-254 (Design Assurance Guidance for Airborne Electronic Hardware).

2. Configuration and Parameter Data

Software behavior often depends on data, not just code. Configuration files, lookup tables, and parameter sets that influence system logic or thresholds — such as control gains or flight limits — are treated as software. For example: An autopilot’s altitude-hold gains or flight envelope limits stored in parameter tables are software-controlled data and must be verified accordingly.

3. Embedded Scripts and Logic

Any embedded scripts or interpreters (e.g., Python, Lua, or proprietary logic) executed onboard and influencing system behavior are considered software. By contrast, scripts used only for ground testing or automation are not airborne software but must be configuration-controlled if they influence certification artifacts.

4. Software Libraries and Operating Systems

Reusable components such as real-time operating systems (RTOS), communication stacks, or math libraries are software under DO-178C. If reused across programs, these may be certified as Reusable Software Components (RSCs), provided their intended use and environment are clearly defined.

5. Initialization and Calibration Data

Any data influencing how the software initializes or operates — such as boot tables, calibration constants, or hardware setup scripts — are considered software-controlled items. They must be verified and managed as part of the software configuration.

These elements collectively form what DO-178C refers to as a Software Configuration Item (SCI) — the fundamental unit of airborne software subject to development, verification, and configuration management.

Figure: What is included in software as per DO-178C taken from AFuzion

What Is Not Considered Software

Certain items fall outside the DO-178C scope:

• FPGA/ASIC logic (covered under DO-254)

• Development tools and scripts not used in airborne execution

• Verification test data and reports, which are certification artifacts, not software

• Configuration management metadata, such as build logs or repository labels

However, when system boundaries blur — such as parameterized control laws or firmware-based logic — the system safety assessment determines whether DO-178C or DO-254 applies.

Why This Definition Matters

Understanding what qualifies as software under DO-178C directly affects certification planning, resource allocation, and compliance evidence. It defines:

• Which components require Software Requirements Data (SRD), Software Design Descriptions (SDD), and Verification Test Results.

• Which items must undergo traceability, configuration control, and independent verification according to their software level (A through E).

• Where to apply DO-330 tool qualification or DO-200B data assurance.

A clear boundary prevents both over-certification (wasting effort on non-airborne items) and under-certification (missing items that affect behavior).

Conclusion: Defining Software for Safety and Compliance

Under DO-178C, software is not just source code — it includes everything that determines what an airborne system does and how it behaves in flight. Executable logic, configuration data, initialization scripts, and parameter files all fall under this scope when they influence airborne performance.

Accurately defining software early in the lifecycle ensures proper traceability, verification, and certification — the cornerstones of aviation safety.

Ultimately, DO-178C’s definition ensures that no element influencing aircraft behavior is left unexamined, reinforcing the industry’s commitment to reliability, accountability, and airworthiness.