An aircraft real-time control system based on openEuler and heterogeneous multi-core SoC

Abstract

The application discloses an aircraft real-time control system based on openEuler and a heterogeneous multi-core SoC, and solves key problems in the field of embedded real-time system technology through systematic architecture innovation. The method constructs a cooperative deployment model of task grading and hardware isolation in view of the severe real-time requirements of part of functions of the aircraft, and systematically integrates CPU core isolation, PCIe optimization and zero-copy technology. The high-performance CPU core is isolated from the openEuler operating system to form a special isolated core, a cooperative optimization mechanism of the maximum Payload and MSI-X interrupt of PCIe is configured, and a zero-copy unified access channel directly from a physical peripheral to a DDS application layer is established, so that the delay of the aircraft control system is significantly reduced. The core innovation of the application lies in the synergistic effect of the technology combination and the deep optimization for the specific scene of the aircraft, and a complete solution is provided for extreme real-time applications such as high-speed aircraft through system-level design.

Description

Technical Field

[0001] This invention relates to a real-time control system for aircraft based on openEuler and heterogeneous multi-core SoC, belonging to the fields of aerospace electronics and embedded real-time systems technology. Background Technology

[0002] High-speed aircraft, such as drones, loitering munitions, and hypersonic vehicles, face extremely harsh operating environments when performing missions. Their flight control systems must respond precisely to various dynamic events within extremely short time windows (usually on the order of milliseconds or even microseconds). This requires the control system to have extremely high real-time performance and determinism.

[0003] With the development of modern System-on-Chip (SoC) technology, heterogeneous multi-core processors, with their powerful computing capabilities and high integration, have become the preferred hardware platform for aircraft control systems. These SoCs typically integrate multiple types of processor cores (such as high-performance CPU cores, real-time cores, and DSP cores) as well as rich high-speed peripheral interfaces (such as PCIe). Meanwhile, to improve software reusability and maintainability, open-source operating systems (such as Linux) and their distributions (such as openEuler) are increasingly being introduced into the aerospace and defense fields.

[0004] However, when applying general-purpose multi-core SoCs and open-source operating systems to high real-time aircraft control systems, the following technical solutions are often adopted, which face numerous technical challenges: 1. Real-time control system based on general multi-core scheduling: In existing technologies, aircraft control systems typically employ multi-core SoCs running Linux / openEuler operating systems. All CPU cores are uniformly scheduled and managed by the operating system. The working principle is as follows: the operating system allocates CPU time slices to each task; high-priority tasks can preempt low-priority tasks, but all tasks share CPU cache and memory bus resources. This technology has the following drawbacks: when the system simultaneously runs high-load non-critical tasks (such as image processing and data compression) and critical control tasks (such as servo control and inertial navigation calculations), non-critical tasks will preempt CPU resources, pollute the shared cache, and compete for memory bandwidth, leading to unpredictable fluctuations in critical tasks, which may even cause the aircraft to lose control in severe cases. Traditional task-priority-based scheduling strategies struggle to fundamentally solve resource contention and cache pollution problems in a multi-core environment, failing to provide deterministic guarantees at the "hard real-time" level. 2. Peripheral access systems based on traditional data copying: In traditional peripheral access models, the system consists of physical peripherals, coprocessors, data buses, multi-core processor kernel space, user-space applications, and DDS middleware. Data travels from peripherals through coprocessors and data buses to the kernel buffer, then through the user buffer to the DDS buffer. In such systems, data needs to be copied multiple times between kernel space and user space. Applications read data from peripherals via drivers; the data is first copied to the kernel buffer, then from the kernel buffer to the application buffer in user space. If the data needs to be further distributed through middleware such as DDS (Data Distribution Service), it also needs to be copied from the application buffer to the DDS buffer. These multiple memory copies not only preempt cache and memory controller usage, consuming a significant number of CPU cycles, but also introduce significant data latency, failing to meet the low-latency requirements of aircraft control loops.

[0005] 3. Local improvement schemes based on a single optimization technique: While technologies such as CPU core isolation, PCIe optimization, and zero-copy have been applied in their respective fields, existing technologies lack systematic integration to meet the specific needs of aircraft control. Particularly on the openEuler open-source platform, there is still a lack of coordinated optimization of these technologies to form a complete solution suitable for microsecond-level extreme real-time scenarios. Specifically: CPU isolation technology achieves resource isolation at the task scheduling level by modifying kernel parameters, but in existing implementations, after peripheral interrupts are assigned to non-isolated cores for processing, data still needs to be copied multiple times to reach the task on the isolated core, significantly reducing the isolation effect; the payload size configured in PCIe optimization often does not match the size of the upper-layer data buffer in different applications, and interrupt handling and task scheduling are out of sync, failing to maximize hardware performance; traditional zero-copy technology generally skips intra-application copies, without considering multi-level copies and inter-application copies.

[0006] Therefore, there is an urgent need for a new system that can fully utilize the hardware characteristics of heterogeneous multi-core SoCs and the flexibility of modern operating systems such as openEuler to solve the above problems at the system architecture level and build a real-time control system for high-speed aircraft that meets their stringent requirements. Summary of the Invention

[0007] The technical problem solved by this invention is to overcome the shortcomings of the prior art and provide a real-time control system for aircraft based on openEuler and heterogeneous multi-core SoC, so as to achieve a balance between high bandwidth data throughput and low latency interrupt response.

[0008] The technical solution of this invention is: This invention discloses a real-time control system for aircraft based on openEuler and a heterogeneous multi-core SoC, characterized by comprising: a multi-core processor, an FPGA module, a DDR controller, LPDDR memory, and a kernel driver module; wherein, The multi-core processor includes multiple processing cores, each running the openEuler operating system and a kernel driver module. The multiple processing cores are grouped and isolated. The tiered flight missions are bound to the isolated processing cores. Data transmission between the multiple processing cores occurs through the kernel driver module. Navigation calculations and control algorithms are performed on the acquired data sent by the FPGA module, and control commands are sent to the FPGA module. Target recognition and tracking are performed on the images sent by the FPGA module, and seeker control parameters are sent to the FPGA module. GPS or BeiDou satellite navigation signals sent by the FPGA module provide a position reference for the aircraft's navigation and guidance. The FPGA module is connected to the multi-core processor via the PCIe bus and integrates a physical I / O memory area for connecting the aircraft's sensors and actuators. The DDR controller is integrated inside the multi-core processor and is used to manage read and write access to LPDDR memory. The LPDDR memory is connected to the DDR controller and is used to store programs and data during system operation.

[0009] Furthermore, in the above system, the multi-core processor integrates a PCIe controller to enable PCIe bus connection between the multi-core processor and the FPGA module.

[0010] Furthermore, in the above system, the FPGA module includes a PCIe IP core, an inertial measurement acquisition module, a data link RF control module, a seeker control and acquisition module, and a satellite navigation data processing module; wherein, The PCIe IP core is connected to the PCIe controller of the multi-core processor via the PCIe Gen2 x4 bus, enabling high-speed data communication between the FPGA module and the multi-core processor. The inertial measurement acquisition module is connected to the inertial measurement unit of the aircraft, acquires the aircraft's attitude data, and sends the acquired data to the PCIe IP core through the internal data bus, and then transmits it to the multi-core processor via the PCIe bus; at the same time, it receives control commands from the multi-core processor to drive the servo actuators to complete the flight attitude adjustment. The data link radio frequency control module is connected to the data link radio frequency equipment of the aircraft and is responsible for bidirectional data transmission and reception between the ground station and the aircraft; it interacts with the PCIe IP core through the internal data bus to realize bidirectional transmission of radio frequency data between the multi-core processor. The seeker control and acquisition module is connected to the infrared seeker of the aircraft and is responsible for the seeker's start-up control, working mode configuration and image data acquisition. It acquires target image information at a high frame rate and sends the image to the PCIe IP core through the internal data bus, and then transmits it to the multi-core processor via the PCIe bus. At the same time, it receives seeker control parameters sent by the multi-core processor and adjusts the seeker's orientation and working status. The satellite navigation data processing module is connected to the satellite navigation receiver of the aircraft, receives GPS or Beidou satellite navigation signals, analyzes and obtains the aircraft's position, speed and time, and sends the navigation information to the PCIe IP core through the internal data bus, and then transmits it to the multi-core processor via the PCIe bus.

[0011] Furthermore, in the above system, the processing core includes a high-performance CPU core and an energy-efficient CPU core; by modifying the kernel startup parameters, some high-performance CPU cores are isolated from the general scheduler to form isolated cores that specifically serve the critical control tasks of the aircraft, while the remaining processing cores run non-real-time or non-critical tasks as non-isolated cores.

[0012] Furthermore, in the above system, the task classification specifically involves dividing tasks into highest-critical-level tasks, medium-critical-level tasks, and low-critical-level tasks. The highest critical level of tasks includes tasks that require latency jitter of less than 25µs; Medium-critical tasks, including those requiring latency jitter of less than 200µs; Low-criticality tasks, including those requiring latency jitter of less than 2ms.

[0013] Furthermore, in the aforementioned system, The highest level of criticality tasks include servo control command generation and IMU data acquisition; Medium-criticality missions, including seeker data acquisition and satellite navigation data reading; Low-criticality tasks include logging, ground communication, and system monitoring.

[0014] Furthermore, in the above system, the grouping and isolation of multiple processing cores specifically involves: sorting the processing cores according to their performance through parameter configuration, physically isolating high-performance processors from the general scheduler, and obtaining isolated processing cores and non-isolated processing cores.

[0015] Furthermore, in the above system, the graded flight missions are bound to isolated processing cores, specifically: the highest critical level missions are bound to isolated processing cores; and the medium and low critical level missions are bound to non-isolated processing cores.

[0016] Furthermore, in the above system, the payload size is set to the maximum value supported by the FPGA module in the PCIe IP core.

[0017] Furthermore, in the above system, the kernel driver module includes a first module, a second module, and a third module; wherein, The first module maps the physical I / O addresses on the FPGA module to the kernel virtual address space, thus obtaining the FPGA physical addresses that have been mapped to the kernel virtual address space; The second module maps the FPGA physical address to the address space of the user process that calls the mmap system. The third module enables the loan mechanism, creates a custom memory pool that matches the size of the FPGA physical address, and registers the FPGA physical address mapped to the user process address space as a DDS available memory buffer.

[0018] Furthermore, in the above system, the multiple processing cores transmit data through a kernel driver module, specifically as follows: After the FPGA module writes sensor data to the physical I / O memory via DMA, the DDS message subscriber reads the data from the mapped FPGA physical address, realizing single-hop data access from the physical peripheral to the DDS application layer. The DDS message publisher writes control command data to the mapped FPGA physical address. The FPGA module reads the data from the FPGA physical address via DMA and sends it to the actuator of the aircraft, realizing single-hop output from the DDS application layer to the physical peripheral.

[0019] The advantages of this invention over the prior art are as follows: 1. This invention adopts a task classification and real-time scheduling strategy binding method. It establishes a three-level classification task system based on the severity of the real-time requirements of the aircraft control tasks, binds the highest critical level tasks to the isolated core and sets a real-time scheduling strategy, thereby decoupling the response time of the critical control loop from other high-load tasks in the system. This solves the technical problem that traditional priority-based scheduling strategies cannot fundamentally eliminate resource contention and cache pollution in a multi-core environment, and provides high-speed aircraft with an independent execution environment that is close to "bare-metal" operation.

[0020] 2. This invention employs a collaborative optimization approach between PCIe maximum payload size and MSI-X interrupts. The maximum payload size of the PCIe endpoint is configured to 4096 bytes to support high-bandwidth data transmission. Simultaneously, the MSI-X mechanism is used to distribute interrupts of different priority data streams to multiple CPU cores for processing and bind critical control data interrupts to isolated cores. This achieves a balance between high-bandwidth data throughput and low-latency interrupt response, resolving the contradiction that a single PCIe configuration cannot simultaneously meet the high-bandwidth and low-latency data requirements of an aircraft, and satisfying the data exchange needs of diverse peripherals in an aircraft.

[0021] 3. This invention adopts a deep integration method of kernel-driven memory mapping and DDS middleware "loan" mechanism. By using ioremap() and mmap to map FPGA physical I / O addresses to user space and associate them with DDS memory pool, a zero-copy unified access channel is constructed from physical peripherals directly to the DDS application layer. This enables end-to-end single-hop transmission of data from sensors to control algorithms and from control algorithms to actuators. It solves the problems of multiple memory copies consuming a large number of CPU cycles, occupying memory bandwidth, and introducing unpredictable delays in traditional layered copy architectures, reducing data transmission latency from tens to hundreds of microseconds to the level of several microseconds.

[0022] 4. This invention adopts a systematic integration of CPU isolation, PCIe optimization and zero-copy technology. Through the collaborative design of the task scheduling layer, peripheral access layer and data transmission layer, a synergistic effect of the technology combination is formed, which realizes a significant improvement in the overall real-time performance of the system. It solves the technical problem that the various optimization measures in the existing technology are independent of each other and cannot be superimposed to form a system-level performance breakthrough, and provides microsecond-level deterministic guarantee for the high-speed aircraft control system.

[0023] 5. This invention provides an architecture and collaborative optimization method for a real-time control system for aircraft based on the openEuler operating system and a heterogeneous multi-core SoC (System on Chip), which is particularly suitable for application scenarios with extreme real-time requirements, such as high-speed aircraft.

[0024] In summary, this invention, through its systematic and innovative design of task deployment, peripheral access, and data transmission, and by organically integrating CPU isolation, PCIe optimization, and zero-copy technology, forms a complete solution particularly suitable for extreme real-time application scenarios such as high-speed aircraft. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the hardware architecture of the aircraft real-time control system in an embodiment of the present invention; Figure 2This is a hybrid deployment diagram based on task criticality level and hardware isolation core in an embodiment of the present invention; Figure 3 This is a schematic diagram comparing the traditional data copy path and the zero-copy path of the present invention in an embodiment of the present invention. Detailed Implementation

[0026] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0027] like Figure 1 As shown, this invention discloses a real-time control system for aircraft based on openEuler and a heterogeneous multi-core SoC, characterized by comprising: a multi-core processor, a PCIe controller, an FPGA module, a DDR controller, LPDDR memory, and a kernel driver module; wherein, The multi-core processor includes multiple processing cores, each running the openEuler operating system and kernel driver module. These cores are grouped and isolated. The tiered flight missions are then bound to the isolated cores. Data transmission between the cores occurs through the kernel driver module. The processor performs navigation calculations and control algorithm processing on the acquired data sent by the FPGA module, sending control commands to the FPGA module. It also performs target recognition and tracking processing on the images sent by the FPGA module, sending seeker control parameters to the FPGA module. Finally, it provides a position reference for the aircraft's navigation and guidance based on the GPS or BeiDou satellite navigation signals sent by the FPGA module. The PCIe controller is integrated inside the multi-core processor and connects to the FPGA module via the PCIe bus; The FPGA module connects to the multi-core processor via the PCIe bus and integrates a physical I / O memory area for connecting the aircraft's sensors and actuators; The DDR controller, integrated within the multi-core processor, is used to manage read and write access to LPDDR memory. LPDDR memory, connected to the DDR controller, is used to store programs and data during system operation.

[0028] Preferably, the FPGA module includes a PCIe IP core, an inertial measurement acquisition module, a data link RF control module, a seeker control and acquisition module, and a satellite navigation data processing module; wherein, The PCIe IP core connects to the PCIe controller of the multi-core processor via the PCIe Gen2 x4 bus, enabling high-speed data communication between the FPGA module and the multi-core processor. The inertial measurement acquisition module is connected to the inertial measurement unit of the aircraft, collects the aircraft's attitude data, and sends the collected data to the PCIe IP core through the internal data bus, and then transmits it to the multi-core processor via the PCIe bus; at the same time, it receives control commands from the multi-core processor to drive the servo actuators to complete the flight attitude adjustment. The data link radio frequency control module connects to the aircraft's data link radio frequency equipment and is responsible for bidirectional data transmission and reception between the ground station and the aircraft. It interacts with the PCIe IP core through the internal data bus to realize bidirectional transmission of radio frequency data between the multi-core processor. The seeker control and acquisition module is connected to the infrared seeker of the aircraft. It is responsible for the seeker's start-up control, working mode configuration and image data acquisition. It acquires target image information at a high frame rate and sends the image to the PCIe IP core through the internal data bus. The image is then transmitted to the multi-core processor via the PCIe bus. At the same time, it receives seeker control parameters sent by the multi-core processor and adjusts the seeker's orientation and working status. The satellite navigation data processing module is connected to the satellite navigation receiver of the aircraft. It receives GPS or BeiDou satellite navigation signals, analyzes and obtains the aircraft's position, speed and time, and sends the navigation information to the PCIe IP core through the internal data bus, and then transmits it to the multi-core processor via the PCIe bus.

[0029] Preferably, the processing core includes a high-performance CPU core and an energy-efficient CPU core; by modifying the kernel startup parameters, some high-performance CPU cores are isolated from the general scheduler to form isolated cores that specifically serve the critical control tasks of the aircraft, while the remaining processing cores run non-real-time or non-critical tasks as non-isolated cores.

[0030] Preferably, the tasks are classified into three levels: highest critical level tasks, medium critical level tasks, and low critical level tasks. The highest critical level of tasks includes tasks that require latency jitter of less than 25µs; Medium-critical tasks, including those requiring latency jitter of less than 200µs; Low-criticality tasks, including those requiring latency jitter of less than 2ms.

[0031] Preferably, The highest level of criticality tasks include servo control command generation and IMU data acquisition; Medium-criticality missions, including seeker data acquisition and satellite navigation data reading; Low-criticality tasks include logging, ground communication, and system monitoring.

[0032] Preferably, multiple processing cores are grouped and isolated, specifically by: sorting the processing cores according to their performance through parameter configuration, physically isolating high-performance processors from the general scheduler, resulting in isolated processing cores and non-isolated processing cores.

[0033] Preferably, the graded flight missions are bound to isolated processing cores, specifically: the highest critical level missions are bound to isolated processing cores; and the medium and low critical level missions are bound to non-isolated processing cores.

[0034] Preferably, in the PCIe IP core, the payload size is set to the maximum value supported by the FPGA module.

[0035] Preferably, the kernel driver module includes a first module, a second module, and a third module; wherein, The first module maps the physical I / O addresses on the FPGA module to the kernel virtual address space, thus obtaining the FPGA physical addresses that have been mapped to the kernel virtual address space; The second module maps the FPGA physical address to the address space of the user process that calls the mmap system. The third module enables the loan mechanism, creates a custom memory pool that matches the size of the FPGA physical address, and registers the FPGA physical address mapped to the user process address space as a DDS available memory buffer.

[0036] Preferably, multiple processing cores transmit data through a kernel driver module, specifically as follows: After the FPGA module writes sensor data to the physical I / O memory via DMA, the DDS message subscriber reads the data from the mapped FPGA physical address, realizing single-hop data access from the physical peripheral to the DDS application layer. The DDS message publisher writes control command data to the mapped FPGA physical address. The FPGA module reads the data from the FPGA physical address via DMA and sends it to the actuator of the aircraft, realizing single-hop output from the DDS application layer to the physical peripheral.

[0037] Example The purpose of this invention is to provide a method for constructing a real-time control system for aircraft based on openEuler and heterogeneous multi-core SoCs. This systematic approach addresses the problems of ensuring real-time performance for critical tasks and high peripheral access latency in existing technologies using general-purpose multi-core hardware and open-source operating systems. Compared to existing technologies, the core innovation of this invention lies in the systematic integration of CPU core isolation, PCIe optimization, and zero-copy technology, and in-depth optimization tailored to the specific needs of aircraft control, creating a synergistic effect.

[0038] To achieve the above objectives, this invention provides a method for constructing a real-time control system for an aircraft, which is implemented through the following systematic and innovative steps: 1. Construction of a Hybrid Deployment Model for Aircraft Control Requirements: To address the stringent real-time requirements of certain functions in the aircraft control system, a collaborative deployment model based on task grading and hardware isolation is constructed. First, the real-time requirements of aircraft tasks are graded according to their severity. Specifically, considering the control characteristics of high-speed aircraft, tasks are divided into three levels: highest criticality (hard real-time, requiring latency jitter <25µs), medium criticality (soft real-time, requiring latency jitter <200µs), and low criticality (low real-time, requiring latency jitter <2ms). Then, on a heterogeneous multi-core SoC, by modifying the boot parameters of the openEuler operating system kernel, high-performance CPU cores are physically isolated from the general scheduler, forming "isolated cores" specifically serving the critical control tasks of the aircraft. This isolation strategy, tailored to the specific frequency requirements of the aircraft, ensures deterministic execution of critical control loops under extreme environments.

[0039] 2. Co-optimization of PCIe and Interrupts for Aircraft Peripherals: This paper proposes a co-optimization method for PCIe bus configuration and interrupt mechanisms to address the data transmission characteristics of aircraft peripherals (especially high-speed sensors and actuators accessed via FPGAs). Considering the mixed transmission requirements of high-bandwidth image data (such as high-definition camera data) and low-latency control data (such as inertial measurement and servo commands) on aircraft, this invention combines the maximum PCIe payload setting with the MSI-X (Message Signaled Interrupts eXtended) distribution mechanism. By setting the data packet payload to the maximum allowed hardware value (4096 bytes) to ensure high throughput of image data, and utilizing MSI-X to distribute data stream interrupts of different priorities to different CPU cores for processing, especially binding critical control data interrupts to isolated cores, a balance between high bandwidth and low latency is achieved.

[0040] 3. Zero-Copy Unified Access Channel from Physical Layer to Application Layer: Addressing the extreme sensitivity of aircraft control systems to end-to-end latency, a zero-copy data channel was designed and implemented, directly connecting physical peripherals to the DDS application layer. This innovation utilizes a customized kernel driver module and a memory mapping mechanism to directly map the physical I / O memory region on the FPGA to user space. It is deeply integrated with the DDS middleware's "loan" mechanism (a mechanism that borrows memory addresses and returns them after use), enabling DDS's DataReader (message subscriber) and DataWriter (message publisher) to directly use the mapped physical memory as a data buffer. This unified access channel from the hardware physical layer to the application communication layer eliminates multiple memory copies in traditional paths, significantly reducing data transmission latency in the aircraft control loop.

[0041] The technical solution of the present invention will be clearly and completely described below with reference to specific embodiments thereof.

[0042] like Figure 1 This invention provides a typical hardware architecture for a real-time control system of an aircraft. The system is based on the Rockchip RK3588 heterogeneous multi-core SoC. The RK3588 SoC integrates four high-performance Cortex-A76 cores and four high-efficiency Cortex-A55 cores, along with a DDR memory controller, PCIe controller, and other on-chip peripherals. A Xilinx Kintex-7 XC7K325T FPGA serves as a coprocessor and peripheral interface expander, connected to the RK3588 SoC via a PCIe Gen2 x4 bus. Various sensors and actuators of the aircraft, such as the inertial measurement unit (IMU), servo controllers, and infrared seekers, are connected to the FPGA. The entire system runs on the openEuler operating system based on the Linux kernel.

[0043] In this embodiment, the following steps will be used to construct the real-time control system for the aircraft: Step 1: Establish a task hierarchy and CPU core isolation collaborative architecture oriented towards aircraft control requirements.

[0044] This embodiment addresses the stringent real-time requirements of 4000Hz servo control and 400Hz inertial measurement acquisition by constructing a collaborative deployment model with task hierarchy and hardware isolation. The core innovation lies in the system-level collaborative design of task hierarchy, CPU isolation, and interrupt affinity.

[0045] 1. Mission classification based on specific aircraft frequencies A specialized mission classification system was established to address the control characteristics of high-speed aircraft. The highest critical level (hard real-time level, 4000Hz / 400Hz): includes 4000Hz servo control command generation and 400Hz IMU data acquisition, with a strictly fixed cycle and extremely high latency requirements.

[0046] Medium-critical level (soft real-time level, 100Hz level): includes seeker data acquisition, satellite navigation data reading, etc., and allows for occasional delays.

[0047] Low criticality level (low real-time level, below 10Hz): includes logging, ground communication, system monitoring, etc.

[0048] 2. CPU isolated core configuration for mission-critical aircraft Implement isolation strategies tailored to aircraft control requirements in the openEuler GRUB configuration: GRUB_CMDLINE_LINUX= "...isolcpus=6,7 nohz_full=6,7 rcu_nocbs=6,7 ..." Core 6 and Core 7 are specifically isolated to form an "isolated core" that serves the critical control loops of the aircraft.

[0049] 3. Collaborative task binding and interruption affinity settings To achieve coordinated optimization of task binding and interrupt handling, end-to-end determinism of critical control loops is ensured. Specifically, the servo control task with a 4000Hz cycle is bound to isolation core 6, and the inertial measurement acquisition task with a 400Hz cycle is bound to isolation core 7.

[0050] 4. Non-critical task deployment: Deploy medium- and low-critical tasks on non-isolated CPU energy-efficient cores (Cortex-A55 cores, CPUs 0-3 in this example) and non-isolated CPU high-performance cores (Cortex-A76 cores, CPUs 4 and 5 in this example), with medium-critical tasks preferentially using isolated CPU cores. These tasks will be managed by openEuler's default scheduler (such as CFS), and their relative priorities can be adjusted by setting their nice value or using the SCHED_OTHER policy.

[0051] Please see Figure 2 The diagram visually illustrates this hybrid deployment model. Through the steps described above, the highest-critical-level tasks (such as inertial navigation and steering) run deterministically on the isolated core, and their execution time is almost unaffected by high-load tasks (such as image processing) running on the non-isolated core, thus achieving a hard real-time guarantee.

[0052] The innovation of Step One lies in the system-level collaborative design of task classification, CPU isolation, and interrupt affinity, which fundamentally eliminates the risks of resource contention and cache pollution for high real-time tasks.

[0053] Step 2: Implement a joint optimization method for PCIe and interrupts to meet the high throughput and low latency requirements of aircraft peripherals.

[0054] This step aims to solve the problem of low-latency, high-volume communication between the FPGA and the SoC via the PCIe bus. The specific steps are as follows: 1. Maximizing Payload Settings: Data on the PCIe bus is transmitted in the form of Transaction Layer Packets (TLPs). The payload is the portion of the TLP that carries the valid data, and its size is configurable. To maximize data transmission bandwidth, this invention sets the "Maximum Payload Size" parameter to the maximum value supported by the hardware, typically 4096 bytes, when initializing the PCIe IP core inside the FPGA and in the PCIe rootport driver on the SoC side. This means that more data can be transmitted in a single DMA operation, reducing the overhead of DMA setup and teardown, thereby improving the effective data throughput. This is especially important for devices such as seekers or high-definition cameras that need to transmit continuous video streams.

[0055] 2. MSI-X Interrupt Configuration: Traditional pin-based INTx interrupts have poor scalability in multi-core systems and can easily become a performance bottleneck. To address this issue, this invention employs the MSI-X (Message Signaled Interrupts-eXtended) interrupt mechanism. MSI-X allows a physical device (such as an FPGA) to have multiple independent interrupt sources, each of which can be independently configured and sent to the system as a message (a write operation to a specific address). Each message can have a different interrupt vector and can be routed to different CPU cores. In this embodiment, in the FPGA's PCIe driver, different MSI-X interrupt vectors are assigned to different data streams or event sources (e.g., IMU data ready, a frame of camera data arriving, servo command transmission completed). Then, by configuring the / proc / irq / {IRQ_NUMBER} / smp_affinity file, the interrupt handlers (ISRs) for these interrupts can be bound to different CPU cores. For example, interrupts related to IMU data can be bound to isolated cores running inertial navigation tasks to achieve minimal response latency; while interrupts related to camera data can be bound to non-isolated cores processing images. This approach distributes the interrupt load, avoiding multiple interrupt requests queuing on a single core and significantly reducing average interrupt latency.

[0056] The innovation of step two lies in the fact that by organically combining the maximum payload setting with the MSI-X interrupt mechanism, this invention achieves high-bandwidth data transmission of the PCIe channel without sacrificing real-time performance, achieving a balance between high throughput and low latency response, and meeting the data exchange needs of diverse peripherals on the aircraft.

[0057] Step 3: Establish a zero-copy peripheral unified access channel from the physical layer to the DDS.

[0058] This step aims to completely eliminate unnecessary copying of data within the system. Please refer to [link / reference]. Figure 3 The figure compares the traditional data path with the zero-copy path of the present invention.

[0059] In the traditional approach, after the FPGA receives data from the IMU, it writes the data to the SoC's kernel memory buffer via DMA. A dedicated management application reads the data from the driver via a system call (such as `read()`), resulting in a copy from kernel space to user space. Then, the application calls the DDS API (such as `write()`) to publish the data, resulting in another copy from the application buffer to the DDS's internal buffer. The entire process involves at least two memory copies.

[0060] The zero-copy path of this invention is different, and its construction steps are as follows: 1. Physical Memory Mapping: First, a custom kernel driver module is written. The core function of this module is to map the physical I / O memory region on the FPGA used for peripheral data exchange (this memory is visible to the SoC's CPU) to the kernel's virtual address space using the `ioremap()` function. Then, by implementing the driver's `mmap` file operation, this kernel virtual address space is mapped again to the address space of the user process that calls the `mmap` system call. In this way, the user-space application obtains a direct pointer to the physical I / O memory.

[0061] 2. DDS Customization and Integration: Next, the DDS middleware used (taking Fast DDS as an example) will be configured or extended. The DDS standard allows data copying to be avoided through a "loan" mechanism. Applications can "borrow" a block of memory from the DDS for data writing and then "return" it. This invention utilizes this mechanism but makes a creative change: instead of borrowing memory from the DDS memory pool, it "provides" the user-space address pointing to physical I / O memory obtained through mmap in the previous step to the DDS. Specifically, a custom DataWriter can be created that, when publishing data, directly reads data from this mapped memory address and encapsulates it into a DDS sample without copying. A similar configuration can be used for the DataReader, allowing it to directly write data to the mapped memory area upon receiving data, so that it can be directly read by the FPGA or used for DMA transfer.

[0062] The innovation of step three lies in establishing a direct path for data between the FPGA's I / O memory and the DDS application. When IMU data arrives at the FPGA memory via DMA, it instantly appears in the readable area of ​​the DDS application, and vice versa. The entire process requires no CPU involvement in any memory copy operations, achieving true "zero copy," significantly reducing data transfer latency and saving valuable CPU resources, allowing it to focus on more important computational tasks.

[0063] As can be seen from the above embodiments and implementation steps, the key to the present invention lies in the "hierarchical-isolation" deployment concept, the "maximum payload + MSI-X" joint optimization strategy, and the "zero-copy" data channel design that runs through the hardware and application layers. These together constitute a complete method for building a high-performance real-time control system for aircraft.

[0064] This invention uses memory barrier instructions and hardware semaphore mechanisms to ensure the consistency of concurrent access to the FPGA physical address by multiple CPU cores of a multi-core processor, preventing data races and read / write conflicts.

[0065] Although the present invention has been described in detail through the preferred embodiments above, it should be understood that the above description should not be considered as a limitation of the present invention. Various modifications and substitutions to the present invention will be apparent to those skilled in the art after reading the above description. Therefore, the scope of protection of the present invention should be defined by the appended claims.

[0066] The contents not described in detail in this specification are common knowledge to those skilled in the art.

Claims

1. A real-time control system for aircraft based on openEuler and heterogeneous multi-core SoC, characterized in that, include: Multi-core processor, FPGA module, DDR controller, LPDDR memory, and kernel driver module; among them, The multi-core processor includes multiple processing cores, each running the openEuler operating system and a kernel driver module. The multiple processing cores are grouped and isolated. The tiered flight missions are bound to the isolated processing cores. Data transmission between the multiple processing cores occurs through the kernel driver module. Navigation calculations and control algorithms are performed on the acquired data sent by the FPGA module, and control commands are sent to the FPGA module. Target recognition and tracking are performed on the images sent by the FPGA module, and seeker control parameters are sent to the FPGA module. GPS or BeiDou satellite navigation signals sent by the FPGA module provide a position reference for the aircraft's navigation and guidance. The FPGA module is connected to the multi-core processor via the PCIe bus and integrates a physical I / O memory area for connecting the aircraft's sensors and actuators. The DDR controller is integrated inside the multi-core processor and is used to manage read and write access to LPDDR memory. The LPDDR memory is connected to the DDR controller and is used to store programs and data during system operation.

2. The system according to claim 1, characterized in that, The multi-core processor integrates a PCIe controller to enable PCIe bus connection between the multi-core processor and the FPGA module.

3. The system according to claim 2, characterized in that, The FPGA module includes a PCIe IP core, an inertial measurement acquisition module, a data link RF control module, a seeker control and acquisition module, and a satellite navigation data processing module; wherein, The PCIe IP core is connected to the PCIe controller of the multi-core processor via the PCIe Gen2 x4 bus, enabling high-speed data communication between the FPGA module and the multi-core processor. The inertial measurement acquisition module is connected to the inertial measurement unit of the aircraft, acquires the aircraft's attitude data, and sends the acquired data to the PCIe IP core through the internal data bus, and then transmits it to the multi-core processor via the PCIe bus; at the same time, it receives control commands from the multi-core processor to drive the servo actuators to complete the flight attitude adjustment. The data link radio frequency control module is connected to the data link radio frequency equipment of the aircraft and is responsible for bidirectional data transmission and reception between the ground station and the aircraft; it interacts with the PCIe IP core through the internal data bus to realize bidirectional transmission of radio frequency data between the multi-core processor. The seeker control and acquisition module is connected to the infrared seeker of the aircraft and is responsible for the seeker's start-up control, working mode configuration and image data acquisition. It acquires target image information at a high frame rate and sends the image to the PCIe IP core through the internal data bus, and then transmits it to the multi-core processor via the PCIe bus. At the same time, it receives seeker control parameters sent by the multi-core processor and adjusts the seeker's orientation and working status. The satellite navigation data processing module is connected to the satellite navigation receiver of the aircraft, receives GPS or Beidou satellite navigation signals, parses and obtains the aircraft's position, speed and time, and sends the navigation information to the PCIe IP core through the internal data bus, and then transmits it to the multi-core processor via the PCIe bus.

4. The system according to claim 1, characterized in that, The processing core includes a high-performance CPU core and an energy-efficient CPU core. By modifying the kernel startup parameters, some high-performance CPU cores are isolated from the general scheduler to form isolated cores that specifically serve the critical control tasks of the aircraft. The remaining processing cores run non-real-time or non-critical tasks as non-isolated cores.

5. The system according to claim 4, characterized in that, The task classification is specifically divided into three levels: highest criticality tasks, medium criticality tasks, and low criticality tasks. The highest critical level of tasks includes tasks that require latency jitter of less than 25µs; Medium-critical tasks, including those requiring latency jitter of less than 200µs; Low-criticality tasks, including those requiring latency jitter of less than 2ms.

6. The system according to claim 5, characterized in that, The highest level of criticality tasks include servo control command generation and IMU data acquisition; Medium-criticality missions, including seeker data acquisition and satellite navigation data reading; Low-criticality tasks include logging, ground communication, and system monitoring.

7. The system according to claim 6, characterized in that, The process of grouping and isolating multiple processing cores specifically involves: sorting the processing cores according to their performance through parameter configuration, physically isolating high-performance processors from the general scheduler, and obtaining isolated processing cores and non-isolated processing cores.

8. The system according to claim 7, characterized in that, The tiered flight missions are then bound to isolated processing cores. Specifically, the highest-critical-level missions are bound to isolated processing cores, while medium-critical-level and low-critical-level missions are bound to non-isolated processing cores.

9. The system according to claim 3, characterized in that, The kernel driver module includes a first module, a second module, and a third module; wherein, The first module maps the physical I / O addresses on the FPGA module to the kernel virtual address space, thus obtaining the FPGA physical addresses that have been mapped to the kernel virtual address space; The second module maps the FPGA physical address to the address space of the user process that calls the mmap system. The third module enables the loan mechanism, creates a custom memory pool that matches the size of the FPGA physical address, and registers the FPGA physical address mapped to the user process address space as a DDS available memory buffer.

10. The system according to claim 9, characterized in that, The multiple processing cores transmit data through the kernel driver module, specifically as follows: After the FPGA module writes sensor data to the physical I / O memory via DMA, the DDS message subscriber reads the data from the mapped FPGA physical address, realizing single-hop data access from the physical peripheral to the DDS application layer. The DDS message publisher writes control command data to the mapped FPGA physical address. The FPGA module reads the data from the FPGA physical address via DMA and sends it to the actuator of the aircraft, realizing single-hop output from the DDS application layer to the physical peripheral.

Images