eVTOL Multi-Core Computing and Airworthiness Certification
🚁 Why Multi-Core Computing Makes eVTOL Certification Harder #
As electric vertical takeoff and landing (eVTOL) aircraft move from prototypes toward engineering validation and commercial deployment, onboard computing architectures are becoming increasingly sophisticated.
During a typical flight, flight-control, navigation, cockpit, communication, monitoring, and mission applications must operate continuously and predictably. Multi-core processors make it possible to consolidate many of these functions onto fewer computing platforms, reducing hardware weight, power consumption, and system complexity.
However, higher computing density introduces a fundamental certification challenge: when multiple applications share processor resources, how can developers prove that safety-critical flight-control software will always execute within its required deadline?
This question is particularly important for eVTOL aircraft, where limited battery capacity makes efficient computing essential while airworthiness regulations demand predictable and verifiable system behavior.
The challenge is therefore no longer simply achieving more computational performance. Engineers must demonstrate that the additional performance can be used without compromising determinism, fault containment, or certification evidence.
📈 eVTOL Growth Is Increasing Airworthiness Demands #
China’s low-altitude aviation sector is rapidly moving from technology exploration toward engineering and certification.
According to data from the Civil Aviation Administration of China (CAAC), Chinese unmanned aerial vehicles accumulated approximately 45.3 million flight hours in 2025, representing year-over-year growth of nearly 70%. China has also completed type certification for 19 unmanned aircraft models, while more than 70 emerging aircraft models are undergoing certification review.
The CAAC has emphasized that new technologies used in low-altitude aircraft are creating additional airworthiness challenges. As a result, certification standards and professional review capabilities must continue to evolve.
Government policy is also accelerating the development of the sector. The Implementation Plan for Innovative Application of General Aviation Equipment (2024–2030) calls for the development of a passenger transportation network combining short-haul transportation with electric vertical takeoff and landing aircraft by 2030. The plan also identifies eVTOL airworthiness certification as an important foundation for future urban air mobility.
These developments mean that software architecture can no longer be treated as an implementation detail. It increasingly determines how efficiently an aircraft can progress through verification and certification.
🧠 Multi-Core Processors Create New Certification Questions #
Multi-core processors provide an obvious advantage for eVTOL platforms.
By consolidating multiple functions onto a shared computing system, developers can reduce the number of processors, circuit boards, power supplies, and associated hardware. This can translate directly into lower aircraft weight and power consumption.
For electric aircraft, those benefits are particularly valuable because every reduction in onboard power consumption can potentially contribute to improved efficiency or flight endurance.
But software consolidation creates new interactions between applications.
For example, flight-control software may execute on the same processor as cockpit displays, navigation services, mission applications, or communications software. Even if these applications have different safety classifications, they may compete for shared processor resources.
A non-critical application consuming excessive CPU time cannot be allowed to delay a flight-control task.
Certification therefore requires developers to answer questions such as:
- What is the worst-case execution time of each safety-critical task?
- Can lower-criticality applications interfere with flight-control execution?
- What happens when multiple applications simultaneously demand memory bandwidth?
- How does shared-cache contention affect deterministic execution?
- Can a software fault escape its designated execution environment?
- What evidence demonstrates that critical tasks always meet their deadlines?
These questions become considerably more difficult on multi-core systems because processors share resources such as caches, memory controllers, and interconnects.
⚙️ Multi-Core Interference Complicates WCET Analysis #
Worst-case execution time (WCET) analysis is central to deterministic real-time systems.
On a relatively isolated single-core processor, developers can often establish predictable execution boundaries by analyzing the processor, operating system, application code, and scheduling behavior.
Multi-core processors introduce additional variables.
Two applications executing on different cores may compete for shared memory bandwidth or cache resources. One workload can therefore influence the execution time of another even when the applications themselves are logically independent.
This creates multi-core interference, which complicates the determination of reliable WCET values.
For safety-critical flight-control software, however, it is not sufficient to demonstrate good average performance. Certification requires convincing evidence that the system remains within acceptable timing boundaries under appropriately defined worst-case conditions.
Consequently, an eVTOL’s computing architecture must provide not only high performance but also predictable resource allocation and measurable isolation.
🧩 Partitioning Turns Software Boundaries Into Certification Boundaries #
One of the most effective approaches is to establish strong software partitions early in the system architecture.
A partitioned architecture allocates defined processor time and memory space to individual applications or groups of applications. Each partition can operate within an explicitly controlled execution environment.
This approach provides two important benefits.
First, critical applications can receive guaranteed computing resources. Flight-control software can operate according to fixed timing requirements rather than competing unpredictably with lower-priority workloads.
Second, faults can be contained. If an application crashes or behaves abnormally, the failure can remain inside its designated partition rather than propagating across the entire computing platform.
For certification, this separation is particularly valuable because it creates clearer relationships between:
application → partition → operating-system services → hardware resources
When software changes later in development, these boundaries can also help engineers identify which components require renewed verification.
This makes architecture an important bridge between rapid product development and manageable certification processes.
🛡️ ARINC 653 Provides a Foundation for Safety Partitioning #
The ARINC 653 standard provides a well-established framework for partitioned avionics software.
A partitioned RTOS separates applications through both time partitioning and space partitioning.
Time partitioning controls when an application is permitted to execute. Space partitioning controls which memory resources it can access.
Together, these mechanisms create controlled execution environments in which applications with different safety requirements can coexist on shared hardware.
For eVTOL developers, this approach is especially attractive because it enables hardware consolidation without requiring every application to have the same criticality level.
A safety-critical flight-control application can receive tightly controlled execution resources, while less-critical applications can operate within their own boundaries.
The result is a computing architecture that is easier to analyze and defend during certification.
🏗️ Safety-Critical Infrastructure Software Matters Early #
Operating-system selection has consequences far beyond the software layer.
The RTOS determines how processor time is scheduled, how memory is protected, how applications communicate, and how faults are isolated. These mechanisms directly affect system architecture and therefore influence verification and certification effort.
Choosing a safety-certified infrastructure platform early can provide development teams with established certification evidence and architectural mechanisms instead of requiring every capability to be developed and justified independently.
This allows engineering teams to concentrate certification activities around the application-specific components that actually change.
The principle is straightforward:
The earlier software boundaries are established, the easier it becomes to control the scope of later verification and recertification.
For rapidly evolving eVTOL programs, this can have a significant effect on development schedules.
🔒 Wind River 653 RTOS and Partitioned Avionics #
Wind River’s 653 RTOS is designed around the partitioning principles defined by ARINC 653.
Applications receive defined temporal and spatial resources, allowing critical flight-control tasks to operate within predictable execution windows. A fault occurring inside one partition can also be contained within that partition rather than automatically affecting unrelated applications.
The platform is intended to support safety-critical development and provides certification-related evidence associated with DO-178C Design Assurance Level A requirements.
Its modular architecture can also help suppliers develop and deliver applications independently. When one software component changes, teams can focus verification activities on the affected boundaries instead of automatically repeating the entire system-level process.
For eVTOL developers, this type of architecture can therefore contribute not only to runtime safety but also to certification efficiency.
🔄 Hypervisors Enable Mixed-Criticality Computing #
Another approach to hardware consolidation is virtualization.
A hypervisor can allow different operating environments to execute on the same multi-core processor while maintaining isolation between them.
For example, a safety-critical RTOS can execute alongside Linux-based applications on shared hardware. The RTOS can host flight-control functions, while Linux handles less-critical workloads such as advanced user interfaces, connectivity, data processing, or other general-purpose services.
Wind River’s Kaiwu Hypervisor follows this type of approach by supporting isolated RTOS and Linux environments on multi-core hardware.
This architecture can be particularly useful for eVTOL platforms because aircraft increasingly need both:
- highly deterministic safety-critical control; and
- flexible general-purpose computing.
Instead of forcing all applications into a single operating environment, virtualization allows each software category to use the environment best suited to its requirements.
✈️ Lessons From Commercial Aviation #
The challenges facing eVTOL developers are not entirely new.
Traditional commercial aviation has already spent decades addressing the problems of software isolation, resource sharing, certification evidence, and multi-core computing.
Collins Aerospace, for example, adopted Wind River 653 RTOS for a multi-core avionics platform that received the U.S. Federal Aviation Administration’s first Technical Standard Order authorization for a platform fully utilizing multi-core processors.
According to information published by RTX, the platform also enables new mission-system capabilities to be integrated in significantly shorter timeframes than traditional avionics development processes.
Such experience demonstrates why eVTOL companies can benefit from established partitioning and multi-core certification methodologies rather than developing entirely new approaches from scratch.
The underlying principle is transferable: hardware consolidation only becomes useful for safety-critical aircraft when resource sharing can be demonstrated to remain predictable and controllable.
🔍 What eVTOL Developers Should Consider #
As multi-core computing becomes standard across low-altitude aircraft, several questions should be addressed during the earliest stages of system architecture.
Processor Selection #
The fastest processor is not necessarily the best processor for a safety-critical aircraft.
Engineering teams must consider:
- deterministic execution;
- cache and memory interference;
- multi-core resource sharing;
- hardware safety features;
- power consumption;
- supported operating systems;
- certification evidence;
- long-term availability.
Operating-System Selection #
The RTOS should be evaluated as part of the overall certification strategy rather than merely as a software platform.
Important considerations include:
- ARINC 653 support;
- time and space partitioning;
- memory protection;
- scheduling determinism;
- fault isolation;
- multi-core interference mitigation;
- certification artifacts;
- development and debugging tools.
Architecture and Change Management #
A modular architecture should clearly identify which applications, partitions, interfaces, and infrastructure components are affected when software changes.
This can prevent relatively small application modifications from unnecessarily expanding the scope of verification.
Certification Evidence #
Certification should be considered continuously throughout development.
Using infrastructure software with established safety evidence can reduce the amount of foundational evidence that developers must create themselves and allow engineering resources to focus on application-specific requirements.
📅 Wind River’s eVTOL Airworthiness Webinar #
Wind River is also addressing these issues through an online technical webinar scheduled for September 8, 2026, from 14:00 to 15:30.
The session, titled “Safety-Critical Infrastructure Software and Airworthiness Certification: The Optimal Path to Accelerating eVTOL R&D and Certification,” focuses on the relationship between infrastructure software, system architecture, and airworthiness certification.
Topics include:
- The role of operating systems in avionics airworthiness.
- Common problems encountered when selecting an OS.
- Questions typically raised during airworthiness reviews.
- How safety partitioning can be incorporated into system architecture.
- Practical examples of partitioned flight-control and display systems.
- The relationship between OS architecture, development schedules, and certification effort.
For organizations developing eVTOL aircraft, these topics highlight an increasingly important reality: certification strategy needs to begin at the software architecture level, not after the aircraft has already been designed.
🚀 Building eVTOLs on Verifiable Software Foundations #
eVTOL aircraft are pushing aviation toward increasingly integrated computing architectures.
Multi-core processors can reduce hardware count, weight, and power consumption while providing enough computational capacity to support increasingly sophisticated aircraft functions. But those benefits come with a corresponding increase in software-analysis complexity.
Shared caches, memory systems, processors, and interconnects make it more difficult to prove deterministic behavior unless the architecture explicitly controls resource access.
This is why partitioned, safety-critical infrastructure software is becoming increasingly important.
An architecture based on time partitioning, space partitioning, fault containment, virtualization, and certification-ready infrastructure can allow critical and non-critical applications to share hardware without sacrificing the evidence required for airworthiness.
For eVTOL developers, the goal is therefore not simply to obtain more computing power. It is to build a computing platform whose behavior can be measured, isolated, verified, and ultimately certified.
As the low-altitude aviation industry moves toward commercial-scale deployment, those characteristics may become just as important as raw processor performance.
The path to faster eVTOL development is not to treat certification as the final stage of engineering. It is to make certification considerations part of the architecture from the beginning.