The Software Boundary Is Not the End of the Assurance Argument
For decades, aerospace software assurance has relied on a fundamental principle: confidence must be supported by objective evidence. Requirements must be understood, implementations verified, and the conditions under which software operates clearly established. That principle has not changed, but the computing environment has.
Modern avionics increasingly consolidate safety-critical functions, mission applications, communications, and advanced processing on multicore platforms. This can reduce hardware duplication and support flexible architectures, but it also creates interactions that cannot be addressed solely by verifying software components in isolation.
A software component may be thoroughly verified, yet the behavior of the integrated system still depends on how it is configured, scheduled, isolated, and connected to other workloads. The challenge therefore extends beyond the software boundary.
A Verified Component Is Not an Assured System
Reusable operating environments and established verification artifacts can provide a valuable starting point. Their applicability, however, depends on explicit assumptions about target hardware, resource allocation, interfaces, and intended use.
Consider an application verified in a controlled execution environment. Once deployed alongside other workloads, its timing may be affected by shared caches, memory controllers, interconnects, or DMA activity. These effects do not invalidate its original evidence; they require the integrator to determine whether that evidence remains applicable to the assembled configuration.
This is the distinction between component assurance and system assurance. Both matter, but neither substitutes for the other. Architecture should make their relationship visible from the beginning.
Multicore Makes Configuration Part of the Argument
On a multicore processor, separate memory partitions do not necessarily imply freedom from timing interference. Software isolation can control address spaces and access rights while applications still compete for hardware resources. Assurance must therefore consider the actual processor and system configuration, not simply the intended software boundaries.
Mechanisms such as controlled resource ownership, scheduling, device assignment, and cache management can help constrain interactions. Their effectiveness must still be analyzed and verified in the relevant operating context. The architectural claim and the evidence supporting it are distinct.
Guidance such as FAA AC 20-193 and applicable military airworthiness criteria reinforces the need to address multicore interference. The practical implication is that configuration decisions should enter certification planning early, while they can still influence system design.
Evidence Reuse Must Be Configuration-Aware
Reusing software does not automatically mean reusing all its certification evidence. A test report is valuable because it supports a particular claim under specified assumptions. If the configuration, interfaces, hardware, or usage conditions change, the applicability of that claim must be reconsidered.
The objective is neither to repeat every verification activity nor to assume prior evidence always transfers. It is to distinguish what remains common from what has materially changed, and to document why particular evidence continues to apply.
That requires a connected evidence strategy. Requirements, configurations, interfaces, verification results, and change-impact decisions should describe the same system baseline. When those relationships are explicit, teams can make more disciplined decisions about reuse.
Bring Integration Assurance Forward
Late discovery of system-level dependencies can turn an otherwise mature software baseline into a difficult integration effort. An application may meet its allocated requirements while the integrated system reveals scheduling interactions, communication dependencies, or failure behaviors that were not sufficiently characterized.
Planning integration assurance from the outset allows engineers to identify the intended certification basis, allocate responsibilities, and define the analyses and tests that will ultimately be required. For programs using MIL-HDBK-516C, this may include applicable safety-critical function thread analysis, failure-mode analysis, and failure-mode effects testing.
Earlier planning does not remove system verification. It reduces the risk that critical evidence needs are discovered only after architecture and configuration have become difficult to change.
How LYNX MOSA.ic™ Certification Support Help
LYNX MOSA.ic Certification Support help teams connect architecture with the evidence planning needed for their actual systems. The 516C System Integration Supplement addresses system behavior involving scheduling, inter-partition communications, networking, and health management, with reference material and worked examples supporting relevant integration analyses.
The Multicore System Configuration Supplement focuses on hardware, hypervisor, and operating-environment settings that influence multicore behavior. It supports planning around shared-resource interference, partitioning, and data and control flow, together with the analyses needed to evaluate the selected configuration.
Supporting reference artifacts, including partitioning analyses, software test reports, and system safety assessment material, can help organize engineering work. They are not automatic certification approval or a replacement for customer-specific verification. Their value is to make required reasoning, assumptions, and evidence more explicit and repeatable.
From Certification by Design to Certification by Evidence
Certification by design is an important ambition. Isolation, deterministic execution, controlled interfaces, and deliberate resource allocation should be architectural considerations from the beginning. Yet a well-designed architecture still requires objective evidence showing that the implemented configuration meets applicable requirements.
Architecture establishes the mechanisms. Configuration-aware analysis establishes the relevant conditions. System-level verification supplies evidence that intended behavior has been demonstrated. These activities reinforce one another; none is sufficient alone.
That connection also matters after initial deployment. When an application changes or a processor is refreshed, teams must determine which assumptions remain valid and which verification activities need to be revisited. The better those dependencies are understood, the more manageable the next change becomes.
Sustaining Confidence as Systems Evolve
The next generation of avionics will be judged not only by what it can execute, but by how confidently it can evolve. Multicore processors, mixed-criticality consolidation, and increasingly sophisticated mission workloads make that challenge more visible, not less.
The right question is not whether a software component has evidence in isolation. It is whether the integrated system has a coherent assurance argument grounded in its actual configuration, and whether that argument can be maintained as the system changes.
Certification confidence does not come from the software alone. It comes from understanding how the entire system behaves.
Learn More by reading our MOSA.ic Certification Support Supplements datasheet.