DO-178C Software Obsolescence: Why Processor Migration Is a Certification Challenge
Aircraft are designed to operate for decades. Electronic components, however, follow much shorter commercial lifecycles. As processors, microcontrollers and supporting toolchains reach end-of-life, aerospace manufacturers and suppliers face a recurring challenge: how can they modernize an airborne system without creating an unmanageable certification burden?
For DO-178B/C certified systems, processor obsolescence is not simply a supply-chain issue. It can affect software verification, structural coverage, timing performance, tool qualification, documentation and certification evidence.
A processor replacement may appear to be a hardware decision. In reality, it can become a major engineering, compliance and programme-management decision.
Why processor obsolescence affects DO-178C certification
Commercial and military aircraft can remain in service for 30 to 40 years, while semiconductor manufacturers often operate on significantly shorter product cycles. As a result, processor obsolescence is inevitable during the lifetime of many airborne platforms.
When a processor or microcontroller becomes unavailable, organizations can consider several options: lifetime buys, form-fit-function replacements or a full redesign based on a new processor family. Yet, when performance, memory, connectivity, cybersecurity or support constraints evolve, redesign is often unavoidable.
This is where the certification challenge begins.
Even when software requirements remain unchanged, a new execution platform can modify object code behaviour, timing characteristics, compiler outputs and hardware/software interface assumptions. Consequently, previously generated certification evidence may no longer be fully reusable.
The result is a potential increase in verification activities, certification documentation updates and programme costs.
Structural coverage: one of the biggest recertification drivers
For systems classified from Design Assurance Level A to C, DO-178C requires structural coverage evidence. Depending on the DAL, this may include statement coverage, decision coverage, Modified Condition/Decision Coverage (MC/DC), as well as data and control coupling analysis.
A processor migration often introduces changes such as:
- A new compiler version
- Different optimization strategies
- Modified instruction scheduling
- New object code structures
- Different execution paths
Therefore, unchanged source code does not automatically mean unchanged certification evidence.
For high-criticality systems, especially DAL A applications, repeating MC/DC campaigns and regenerating coverage analysis can represent a significant part of the recertification effort. Test cases may need to be adapted, re-executed and reassessed against the new target environment.
Before approving a processor replacement, engineering teams should evaluate the potential impact on structural coverage as early as possible.
Toolchain changes and DO-330 implications
Processor migration rarely affects the target hardware alone. It commonly requires changes to the development and verification toolchain.
A new compiler, debugger, analyser or build environment may alter generated object code behaviour, optimization strategies and analysis interfaces. Under DO-178C, tool qualification is governed by DO-330. Consequently, previously qualified tools cannot automatically be considered valid for a new execution platform.
This can create additional work related to:
- Tool Qualification Level assessments
- Tool operational requirements
- Tool verification activities
- Configuration management updates
- Certification authority discussions
For this reason, toolchain stability should be treated as a strategic asset. Long-term agreements with tool providers, controlled upgrade policies and robust configuration baselines can help reduce disruption when a processor change becomes necessary.
Timing, WCET and determinism must be revalidated
A new processor architecture can significantly affect timing behaviour. Cache performance, interrupt latency, memory access, CPU load and scheduling behaviour may all change, even when the functional logic remains identical.
During processor migration, teams typically need to reassess:
- Worst-Case Execution Time (WCET)
- Stack utilization
- CPU load margins
- Interrupt response time
- Deterministic behaviour
This becomes especially important for systems using partitioned architectures, including ARINC 653 environments. A processor change can challenge existing scheduling assumptions and require renewed validation of timing margins.
Timing evidence should therefore be integrated into the migration plan from the beginning. Delaying WCET and determinism assessments can create costly surprises late in the certification process.
Multicore processors introduce an additional certification challenge
Modern replacement processors increasingly rely on multicore architectures to provide higher performance. However, moving from a legacy single-core platform to a multicore environment can increase certification complexity.
Multicore architectures introduce potential concerns such as shared resource interference, cache contention, cross-core communication and additional determinism analysis. Certification teams may also need to consider guidance such as AC/AMC 20-193.
Selecting a multicore processor based only on performance criteria can therefore be risky. The processor selection process should also consider the certification effort associated with the target architecture.
A higher-performance platform may be technically attractive. Yet, without a clear certification strategy, it can multiply verification, analysis and documentation work.
From DO-178B to DO-178C: managing legacy programme evolution
Many legacy airborne systems were originally approved under DO-178B, while newer programmes operate under DO-178C.
When processor obsolescence affects a legacy platform, the migration may trigger discussions around updated DO-178C interpretations, tool qualification under DO-330 or more recent certification expectations. Even where a complete transition is not required, certification authorities may expect teams to address the implications of the new configuration baseline.
Processor obsolescence can therefore become a catalyst for partial modernization of the certification approach.
Engineering leaders should account for both the hardware change and the potential evolution of regulatory expectations. Treating them separately can lead to incomplete impact assessments and underestimated programme risks.
Reuse credit cannot be assumed
A frequent assumption is that unchanged software requirements guarantee full reuse of certification evidence. In practice, reuse credit must be justified.
An execution platform change can affect:
- Structural coverage evidence
- Timing analysis
- Hardware/software interface assumptions
- Integration test results
- Object code compatibility with the target
- Toolchain qualification evidence
The ability to reuse evidence depends heavily on architectural modularity and the separation between application software and processor-dependent layers.
Teams that invest in abstraction layers, interface discipline and modular architecture can reduce the scope of future migration work. This makes software reuse more achievable and helps protect certification investments over the system lifecycle.
Documentation is a cost driver, not an administrative task
Processor migration also affects the certification data package. Even when software modifications are limited, documentation must reflect the new configuration baseline.
Typical impacted artefacts include:
- Plan for Software Aspects of Certification (PSAC)
- Software development and verification plans
- Configuration management records
- Software Accomplishment Summary
- Traceability matrices
- Verification results and review records
Documentation re-baselining is often underestimated. However, it can represent a substantial share of the total migration effort.
To avoid delays, certification documentation should be managed as a formal work package with defined resources, ownership and milestones.
How to reduce the impact of future processor obsolescence
Obsolescence cannot always be avoided. Nevertheless, its consequences can be anticipated and controlled.
Engineering and programme teams should consider the following actions:
- Select mature and scalable processor families.
- Assess projected software growth, memory needs and future connectivity requirements.
- Define a long-term toolchain strategy.
- Build modular architectures that isolate processor-dependent components.
- Include certification impact analysis in obsolescence-management plans.
- Budget for structural coverage, timing and documentation updates.
- Evaluate multicore certification implications before selecting a target platform.
By treating processor obsolescence as a predictable lifecycle event, organizations can reduce unexpected recertification costs and better protect delivery schedules.
Download the White Paper
Processor migration in aerospace is not just a technical replacement activity. It is a certification, verification, toolchain and documentation challenge that requires early planning.
Our white paper, “Software Obsolescence in DO-178B/C Certified Systems: Guidance for Engineering Management in Aerospace,” explores the main risks, certification impacts and engineering-management considerations associated with processor obsolescence.
Pour plus d'information
CS Canada
Vincent Besselat, Responsable des ventes
3333 boul. de la Côte-Vertu, Bureau 800, Saint-Laurent, QC, H4R 2N1, Canada
+ 1 (514) 677-8462 – vbesselat@cscanada.ca – www.cscanada.ca
CS NEWS
Recent Posts
Categories
LIRE AUSSI
Brochure DO-178C
Brochure Aéronautique
