DO-178C Airborne Software Considerations

Regulatory Framework

DO-178C, published jointly by RTCA and EUROCAE (as ED-12C) in 2011, is the dominant means of compliance for showing that airborne software performs its intended function with the level of confidence in safety required by airworthiness regulations under Title 14 CFR Parts 23, 25, 27, 29, and 33. The Federal Aviation Administration recognizes DO-178C through Advisory Circular 20-115D, and the European Union Aviation Safety Agency recognizes it through Acceptable Means of Compliance AMC 20-115C. Compliance is mandatory in practice for any software whose anomalous behavior could contribute to a failure condition contributing to an aircraft hazard.

The standard partitions software into five Design Assurance Levels, derived from the safety-assessment process described in ARP4761 and ARP4754A. DAL-A applies to software whose failure produces catastrophic conditions, including loss of the aircraft; DAL-B covers hazardous; DAL-C, major; DAL-D, minor; and DAL-E, no effect. Each level prescribes objectives across planning, development, verification, configuration management, quality assurance, and certification liaison. DAL-A imposes 71 objectives, with independence required for 33 of them, and demands modified condition/decision coverage in structural-coverage analysis.

DO-178C is supplemented by four technology supplements that the core document explicitly references. DO-330 specifies tool qualification criteria across five Tool Qualification Levels, distinguishing development tools from verification tools. DO-331 governs model-based development and verification, including simulation as a verification artifact. DO-332 addresses object-oriented technology and related techniques such as inheritance, dynamic dispatch, and exception handling. DO-333 admits formal methods as an alternative to selected testing-based verification objectives, recognizing model checking, abstract interpretation, and theorem proving.

Architectural Requirement

Every DAL level mandates bidirectional traceability from system-level safety requirements through high-level requirements, low-level requirements, source code, and executable object code, and back through verification artifacts. The certification authority and Designated Engineering Representatives must be able to demonstrate, for any line of code or any test case, the requirement it satisfies and the failure condition that requirement mitigates. This obligation is structural; it cannot be reconstructed from execution logs alone.

DO-178C also requires that the executable behavior be deterministic with respect to the verified input space. Worst-case execution time analysis, stack-usage analysis, and memory-partitioning evidence under DO-297 IMA guidance presume that the actuation surface of the software is bounded and inspectable at certification time. When a software component decides to command a flight-control surface, the path from sensed condition to commanded output must be enumerable and verifiable across the credit-claimed coverage profile.

The advent of learning-enabled and adaptive aviation functions, addressed in EASA Concept Paper Issue 02 on AI Level 1/2 machine learning and the FAA AI Roadmap, complicates this assumption without dissolving it. The certification authorities have made clear that learned behavior must remain bounded by an inspectable runtime envelope. The architectural requirement is therefore not the elimination of adaptive computation but its containment behind an actuation gate whose decisions are themselves traceable to safety requirements.

Why Procedural and Bolt-On Compliance Fails

The historical pattern in airborne software is to treat actuation as an unchecked consequence of upstream verified logic: if the requirements, design, code, and tests close, the output command is ipso facto airworthy. This is sound when the upstream pipeline is fully deterministic, but it fails the moment a learned or adaptive component contributes to the command path. Bolting a runtime monitor onto a verified deterministic core does not make the resulting composite traceable, because the monitor's intervention authority is not itself a first-class requirement-traceable artifact.

Procedural compliance approaches typically attempt to satisfy DO-178C objectives by retrofitting documentation, regenerating trace matrices from existing code, or layering an Operational Design Domain check at integration time. These efforts confront a structural mismatch: the certification narrative requires that actuation decisions be governed by the same requirements lattice that governs the rest of the lifecycle. A monitor invoked after a learned component has already produced a command cannot retroactively confer the necessary chain-of-evidence on that command.

The deeper problem is that DO-178C does not contemplate graduated actuation. The standard's verification objectives presume that a verified function either runs or it does not. Real safety-critical adaptive systems require finer modes: full execution under nominal conditions, deferred execution when sensed inputs fall near the edge of the verified envelope, refused execution when out-of-distribution inputs are detected, and partial execution that limits authority to a conservative subset. Without an architectural primitive that makes these modes themselves traceable, certification credit cannot be claimed.

What The AQ Primitive Provides

Governed actuation is the Adaptive Query primitive that makes the actuation surface itself a first-class object subject to the same requirements traceability and verification rigor as the upstream computation. Rather than treating an output command as an unconditional consequence of verified logic, governed actuation interposes a graduated decision over every commanded action, and that decision is itself a requirement-traced artifact. The primitive consists of four mechanisms that operate together.

The first mechanism is graduated actuation modes, which allow each commanded action to be classified at runtime into continue, defer, refuse, or partial. Continue commits the full action under nominal envelope conditions; defer holds the action pending additional evidence or a reversion to a higher-assurance backup channel; refuse rejects the action and surfaces an annunciation to the certified backup; partial commits a conservative subset of authority bounded by the verified envelope. Each mode maps to specific failure conditions identified in ARP4761 functional hazard assessment, allowing DAL-credit to be claimed mode-by-mode.

The second mechanism is harm minimization, which scores each candidate action against an enumerable harm vector tied to the system-level safety assessment. The third is reversibility evaluation, which determines whether a commanded action can be safely retracted within the verified time horizon; irreversible actions face a stricter actuation gate than reversible ones, mirroring the certification distinction between latent and detectable failures. The fourth is post-actuation verification, which closes the loop by confirming that the commanded effect occurred within the predicted envelope and recording divergence as a verification artifact admissible in continued-airworthiness review.

Crucially, the four mechanisms are composed under DO-331 model-based semantics, qualified with DO-330 verification tools, and where appropriate verified with DO-333 formal methods. The actuation gate itself is a verified object, not an add-on monitor, and its decisions enter the same trace matrix as any other DAL-A artifact. This is what permits adaptive components to participate in a certifiable architecture without dissolving the deterministic guarantees the standard requires.

The mode taxonomy aligns naturally with the failure-condition severity classes of ARP4761 and the FAA Order 8110.49 software conformity inspection criteria. Continue corresponds to nominal operation under the verified envelope; partial corresponds to a graceful degradation path that the system safety assessment has identified as a design assurance mitigation; defer corresponds to a hand-off to a higher-assurance backup channel; refuse corresponds to a fail-passive or fail-operational architectural commitment depending on the function's hazard category. Because the modes are themselves verified, the safety case can claim mode-specific credit rather than function-level credit.

Compliance Mapping

Governed actuation maps directly to specific DO-178C objectives across the planning, development, and verification process tables. The graduated-mode decision is documented as a high-level requirement under Table A-2, decomposed to low-level requirements under Table A-3, and verified through MC/DC structural coverage under Table A-7 for DAL-A applications. Each mode transition is a testable condition with bidirectional trace from the originating safety requirement.

Under the DO-331 supplement, the actuation gate is expressed as a verified model with documented model coverage and simulation credit. Tool qualification under DO-330 applies to the harm-minimization scoring tooling at TQL-5 when used as a verification tool, or TQL-1 when its output directly affects the executable. DO-333 formal-methods credit may be claimed for the reversibility evaluator where the underlying control law admits a tractable invariant proof, replacing a portion of the structural-coverage objectives with formal-verification evidence per Table FM-A-7.

Post-actuation verification artifacts feed continued operational safety processes under 14 CFR Part 21 Subpart H and the equivalent EASA Part 21 provisions, providing a substrate for in-service monitoring obligations. Composite admissibility supports multi-authority aviation operations across FAA, EASA, Transport Canada, and ANAC bilateral airworthiness agreements, allowing the same evidence package to serve concurrent validation under bilateral arrangements such as the FAA-EASA Bilateral Aviation Safety Agreement and its Technical Implementation Procedures.

Robustness testing under DO-178C Section 6.4.2.2 is satisfied per-mode rather than per-function, so that out-of-range and unexpected-input objectives map cleanly onto the refuse and partial modes. Worst-case execution time analysis, conducted under the constraints of CAST-32A multi-core processor guidance, can be bounded mode-by-mode, simplifying the WCET argument for the adaptive component because the gate guarantees that adaptive computation never directly drives a deadline-critical command path.

Adoption Pathway

Programs adopting governed actuation typically begin at Stage of Involvement 1 with the certification authority, declaring the actuation primitive in the Plan for Software Aspects of Certification. The Software Development Plan, Software Verification Plan, and Software Configuration Management Plan each acknowledge the four mechanisms as first-class verified components, and the Software Quality Assurance Plan defines independence relationships consistent with DAL credit claims. Stage of Involvement 2 reviews then concentrate on the actuation gate's requirements decomposition, ensuring that the certification authority concurs on the gate as a verified object before significant code is written.

Existing DAL-C and DAL-B programs can introduce governed actuation through a partitioned augmentation, leaving the legacy deterministic core untouched while admitting an adaptive function behind the gate. This avoids re-baselining the certified portion of the codebase and confines the new evidence package to the actuation primitive and the function it gates. ARINC 653 partitioning under DO-297 IMA guidance provides the spatial and temporal isolation that bounds the new evidence package. New DAL-A programs gain the largest benefit by treating governed actuation as a foundational architectural commitment from system-requirements freeze forward, allowing the four mechanisms to inform the System Functional Hazard Assessment and the Preliminary System Safety Assessment rather than being retrofit against them.

For programs anticipating EASA AI Level 1 or 2 certification under the forthcoming AMC for machine-learning items, the architectural commitment to governed actuation aligns directly with the Learning Assurance objectives that the agency has signaled. The four mechanisms instantiate the runtime envelope, the operational design domain check, and the post-deployment monitoring obligations that the EASA Concept Paper anticipates, with credit drawn from the same evidence package that supports DO-178C Stage of Involvement 4 conformity review.