AC 20-193 / AMC 20-193: Certifying Multi-Core Processors in Avionics

What AC 20-193 is and what it replaced

AC 20-193, Use of Multi-Core Processors, is the FAA's guidance for airborne systems and equipment that contain a multi-core processor (MCP). It was issued in January 2024 as the FAA companion to EASA's AMC 20-193, which EASA adopted in 2022 through ED Decision 2022/001/R. The two documents were developed jointly and are nearly identical, so one compliance approach can usually satisfy both authorities.

Together they supersede CAST-32A, the Certification Authorities Software Team position paper that programs used as de facto multi-core guidance for years. If your plans still cite CAST-32A, update them to AC 20-193 / AMC 20-193 before SOI #1.

Like any advisory material, it describes an acceptable means of compliance, not the only one. An applicant can propose an alternative, but it has to show an equivalent level of safety and be accepted on the project, which is rarely the faster path.

Does it apply to your equipment?

The guidance applies when the MCP has two or more activated cores and at least one hosted software application, or the hardware item containing the MCP, is assigned IDAL A, B or C. If every item is Level D or E, it does not apply. Activating another core or adding Level A–C software later means reassessing applicability.

Two configurations are excluded from the interference objectives: cores running in lockstep (executing the same software in parallel for comparison), and cores that are linked only by conventional avionics databuses rather than by shared memory, shared cache or an internal interconnect. Deactivated cores are handled under the airborne electronic hardware guidance (AC 20-152A / AMC 20-152A).

The guidance also assumes software is statically allocated to cores at start-up. Dynamic reallocation by an operating system or hypervisor, and simultaneous multithreading, are outside its scope; if you use them, you have to explain in your plans how determinism is still preserved.

Why multi-core is different: interference

On a single-core processor, partitioning and timing analysis are mature problems. On an MCP, applications running on different cores compete for shared resources: memory, shared cache, the on-chip interconnect or coherency fabric, and shared peripherals. Even with no data or control flow between them, that contention couples the applications at the platform level.

The result is interference. Time interference can stretch an application's worst-case execution time (WCET) far beyond what it measures when running alone. Functional interference can create new data and control coupling paths. Either one can leave a safety-critical function non-deterministic or without enough time to finish. Almost every objective in the guidance exists to find, bound or contain that interference.

The 10 MCP objectives

• MCP_Planning_1: identify the exact MCP (manufacturer's unique identifier), the number of active cores, the software architecture (AMP, BMP, SMP), every hosted software component, any dynamic software features, whether it is an IMA platform, whether it provides robust partitioning, and the methods and tools used.
• MCP_Planning_2: describe how shared resources will be used, allocated and verified; the hardware resources used to meet the objectives; any hardware dynamic features (clock gating, frequency scaling, core deactivation); and where a safety net is needed.
• MCP_Resource_Usage_1: determine and document the MCP configuration settings that let hardware and software meet functional, performance and timing requirements.
• MCP_Resource_Usage_2: reserved; covered by the AEH guidance (AMC 20-152A, objective COTS-8).
• MCP_Resource_Usage_3: identify the interference channels that could affect hosted software and verify the chosen mitigations.
• MCP_Resource_Usage_4: identify available MCP and interconnect resources in the final configuration, allocate them, and verify worst-case demand does not exceed them with all software running.
• MCP_Software_1: verify all hosted software meets the software guidance and has enough time to complete with everything running in the intended final configuration.
• MCP_Software_2: verify data and control coupling between software components on the same and different cores, including shared-memory interfaces and their access controls.
• MCP_Error_Handling_1: identify MCP failure effects and design, implement and verify fail-safe detection and handling, which may include a safety net independent of the MCP.
• MCP_Accomplishment_Summary_1: summarize how each objective was met, alongside the normal software and hardware accomplishment summaries.

Which objectives apply at your DAL

When the highest IDAL of the MCP hardware or any hosted software is A or B, every objective applies. At IDAL C, MCP_Resource_Usage_4 and MCP_Error_Handling_1 drop out.

IDAL C also has an option on the interference analysis (MCP_Resource_Usage_3): if the safety analysis does not require the hosted applications to be robustly partitioned, you may skip it. The trade-off is significant. Without an interference analysis, no software component can be verified separately; everything must be tested on the target MCP with all software running in the final configuration. For most programs, doing the analysis is cheaper than giving up separate verification.

Robust partitioning changes the verification strategy

If your platform provides both robust resource partitioning and robust time partitioning, as the guidance defines them, applications can be verified and their WCETs determined separately on the MCP. Robust time partitioning on an MCP means no partition exceeds its execution-time budget regardless of what is running on the other cores, from none of them to all of them.

For every other platform, separate verification is allowed only for components whose interference is mitigated or precluded by design. Everything else must be tested on the target MCP in the intended final configuration, including robustness testing of the MCP interfaces, and WCET must be determined by analysis and confirmed by test on the target. Simulation of the processor's internal mechanisms is unlikely to be accepted as a substitute.

This is why the choice of RTOS or hypervisor matters so much. A partitioning platform with an existing multi-core certification argument can remove months of integration testing from your schedule.

Where multi-core programs get stuck

• Choosing the processor before the certification argument. Some COTS MCPs have little public documentation of their interconnect and cache behavior, which makes interference channel analysis slow and contested.
• Treating interference analysis as a test campaign. MCP_Resource_Usage_3 wants channels identified from the architecture first; tests then verify the mitigations. Measuring WCET without the analysis invites findings at SOI #3.
• Leaving power-management features enabled. Frequency scaling and dynamic core deactivation are hardware dynamic features that must be identified and justified, and are usually disabled for cores hosting critical software.
• Verifying in a configuration that is not the final one. Late changes to core allocation or cache settings can invalidate timing evidence.
• No plan for the safety net. At IDAL A and B, reviewers will ask how MCP failures are detected and contained within the equipment.

How to plan for SOI #1

1. 01Confirm applicability early: active cores, IDALs, lockstep or databus-only exceptions, and any dynamic features.
2. 02Address MCP_Planning_1 and _2 explicitly in the PSAC and PHAC (or a dedicated multi-core plan referenced from both), using the objective IDs so reviewers can find each one.
3. 03Document the MCP configuration settings and freeze them as part of the intended final configuration.
4. 04Produce an interference channel analysis from the processor's architecture and documentation before planning the timing tests.
5. 05Define the WCET strategy: separate determination where interference is mitigated, analysis confirmed by target testing elsewhere.
6. 06Build a compliance matrix mapping all 10 objectives to evidence, which becomes the basis for MCP_Accomplishment_Summary_1.

Working with a DER on multi-core

Multi-core findings cut across software and hardware, so they are easiest to close when the reviewer holds authority in both. Aries Aero Systems' principal holds FAA DER authority for software (DO-178C) and airborne electronic hardware (DO-254) through Level A, so the MCP objectives, the DO-178C software objectives and the AEH COTS objectives can be reviewed together rather than split across designees.

We can review your multi-core plans before SOI #1, assess an interference analysis, or run a gap assessment on a program that started under CAST-32A.