Tailoring and deployment method of Euler system in aircraft embedded software

Abstract

The present invention discloses a method for tailoring and deploying the Euler system in aircraft embedded software, which relates to the field of aircraft embedded software, including: E1. Install necessary host packages on the build host, initialize the build environment; build an Euler system image with the ARM64 architecture; start QEMU and load the Euler system image file; E2. Tailor the Euler system kernel to adapt to specific hardware functions; E3. Tailor the root file system of the Euler system to remove unnecessary software packages and files; tailor the Euler system startup script and shut down unnecessary Euler system modules; E4. For the highly customized hardware of the aircraft, perform specialized hardware driver adaptation and optimization on the Euler system; E5. Deploy middleware in the streamlined Euler system image operating system, and at the same time deploy the iSulad container. The present invention, by building a special adaptation system for hardware drivers, establishing a standardized tailoring process, and designing a hybrid deployment architecture of OpenEuler and UniProton, has the functions of both real-time control and intelligent computing tasks.

Description

Technical Field

[0001] The present invention relates to the field of aircraft embedded software, and specifically to a method for tailoring and deploying the Euler system in aircraft embedded software. Background Art

[0002] With the rapid development of aerospace technology, aircraft embedded software plays an increasingly important role in aircraft. Complex aircraft represented by space stations and deep space exploration present the characteristics of intelligence and networking, and more functions need to be realized through software. The development ability of aircraft embedded software directly reflects the core competitiveness of aircraft.

[0003] However, at present, aircraft embedded software in China faces many challenges. First, aircraft embedded software is closely related to hardware. The high customization and diversity of aircraft hardware significantly affect and restrict the development of software, and it is also difficult to solidify and continuously improve the maturity of specific codes such as underlying drivers, interface protocols, and software-hardware timing. Second, aircraft embedded software is deployed as configuration items in different hardware products and developed by different design teams, belonging to a high-real-time distributed topology architecture. Therefore, the design of aircraft embedded software not only needs to carry out work such as interrupt allocation and processing, interface protocol design, and timing design for individual configuration item tasks, but also needs to carry out top-level planning and design of the software system. Third, in recent years, the scale of aircraft embedded software has been increasing, and the trend of task diversification has become increasingly prominent. Task diversification places higher requirements on the development of aircraft embedded software, and aircraft embedded software must be adjusted according to the characteristics of different tasks. Fourth, with the development of the times, the independent control of information technology has become an increasingly key issue in national development. Aircraft embedded software is widely used, covering both military and civilian applications, and its autonomy, security, and reliability are factors that must be considered in the development process of aircraft embedded software.

[0004] Therefore, to solve the problems faced by current aircraft embedded software, meet the needs of domestic aircraft embedded software, standardize the development process, support process, management process, maintenance process, and improvement process of aircraft embedded software, it is necessary to design a general method for tailoring and deploying a domestic operating system in aircraft embedded software.

[0005] In addition, traditional aircraft mostly adopt a centralized architecture. The centralized architecture relies on the processing power of local hardware and is difficult to support the operation of complex intelligent algorithms while meeting the timeliness of real-time tasks. The distributed architecture enables some computing tasks to be completed through cloud computing and edge computing, thus alleviating the limitation of insufficient computing power of on-board equipment. However, affected by communication delay and data synchronization uncertainty, it is also difficult to meet the complex application scenarios of aircraft.

[0006] To address the conflict between real-time and intelligent task processing requirements, the hybrid deployment architecture has gradually become a research hotspot. By separating real-time tasks and non-real-time tasks onto different computing platforms, this architecture effectively reduces the risk of critical tasks being affected by non-critical tasks. The real-time system is used to handle critical tasks such as navigation and flight control. High reliability and low latency can ensure the stable operation of the aircraft in dynamic and complex environments. The non-real-time system, on the other hand, is responsible for intelligent tasks such as data analysis and mission planning, offering higher computational complexity and lower timeliness requirements. The design of the real-time system focuses on the schedulability of high-priority tasks and low latency. Research has proposed multi-core real-time operating systems and partition scheduling algorithms to ensure that the execution time of the aircraft's critical tasks meets strict requirements. At the same time, the intelligent capabilities of the non-real-time system are continuously enhanced, using multi-core processors and AI acceleration hardware to support complex data processing and inference tasks. In addition, the co-design technology of software and hardware in the hybrid architecture is also evolving, improving the overall performance of the system through task allocation optimization algorithms and resource scheduling strategies.

[0007] The rapid development of intelligent applications has gradually expanded the task execution mode of the aircraft from a single real-time control mode to a hybrid mode where both real-time and non-real-time systems coexist. However, this has brought new challenges to the software deployment architecture of the aircraft. For example, the design of the hybrid deployment architecture of the aircraft's embedded real-time system and non-real-time system requires considering the complex task processing capabilities of the non-real-time system while meeting real-time requirements, and solving key problems in system scheduling and resource balance, system communication and data synchronization, intelligent deployment and verification, etc.

[0008] Existing technologies such as the invention patent with the publication number: CN109063339B is a digital spacecraft component-level embedded simulation system, including a host computer, a management box, and several equipment boxes that are sequentially connected to the host computer; an embedded simulation platform, a flight environment simulation module, a synchronization management module, and an automatic deployment module are installed in the host computer; the management box includes a communication module, an upper computer instruction response module, and a synchronization module connected to the communication module; a synchronization board and several simulation board cards are plugged into the equipment box; the simulation board cards are used to receive and run simulation programs.

[0009] Existing technologies such as the invention patent with the publication number: CN106775659B is an embedded dual-core flight control software architecture method based on a high-speed Linkport interface. The method includes the following steps: Step 1, dual-core flight control software task division; Step 2, design of the dual-core communication mechanism of the flight control software; Step 3, dual-core data sharing mechanism of the flight control software; Step 4, dual-core reliability design of the flight control software.

[0010] Based on the above solution, it can be seen that in the prior art, the host computer integrates multiple modules such as an embedded simulation platform, environment simulation, synchronization management, and automatic deployment. The dependency relationships between the modules are complex, and chain problems are likely to occur during debugging and upgrading. Moreover, the physical hierarchical design of the management box and the device box increases the complexity of the hardware connection. The simulation board uses a customized hardware interface and it is difficult to adapt to new spacecraft components. Secondly, adopting a dual-core architecture will increase the system complexity and bring higher power consumption. Therefore, a method is needed that can meet the real-time requirements while taking into account the complex task processing capabilities of non-real-time systems. Summary of the Invention

[0011] In view of the deficiencies of the prior art, the present invention provides a method for trimming and deploying the Euler system in the embedded software of an aircraft. To achieve the above objectives, the present invention is realized through the following technical solutions: A method for trimming and deploying the Euler system in the embedded software of an aircraft, including:

[0012] E1. Install the toolchain and its running dependencies on the build host, then perform the environment initialization operation. Build an Euler embedded system image for the ARM64 architecture through the toolchain, generate standard distribution components, set up a QEMU full-system simulator on the host side, and load the pre-built image for functional verification.

[0013] E2. Trim the Euler system kernel to adapt to specific hardware functions. Clone the Euler system kernel source code to the build environment, accurately enable or disable kernel modules and features related to the target hardware through an interactive configuration interface. After completing the customized configuration, perform cross-compilation to generate a lightweight kernel image and module files, and deploy the compilation products to the build directory.

[0014] E3. Accurately define the software package dependency relationships by editing the local configuration file, remove redundant features and ensure the integrity of the build layer. Recompile based on the custom software package list to generate a trimmed Euler system image, and at the same time optimize the startup performance. Use system analysis tools to analyze the startup time consumption, identify and disable unnecessary services, switch the default startup target to the multi-user mode, and trim the startup script and system modules.

[0015] E4. Clarify the hardware specifications and driver requirements of the aircraft, realize the definition of the hardware interface and the binding of the driver through the device tree configuration, develop a dedicated driver module for the customized hardware, and complete the kernel recompilation and system deployment.

[0016] E5. Deploy Bingling as middleware in the trimmed Euler system image operating system for communication between applications and systems, and at the same time deploy the iSulad container to carry intelligent applications.

[0017] Compared with the prior art, the embodiments of the present invention have at least the following beneficial effects:

[0018] (1) The present invention provides a method for tailoring and deploying an Euler system in aircraft embedded software. Relying on the generality and extensibility of the Euler operating system itself, the present invention can perform special hardware driver adaptation for highly customized aircraft hardware on the basis of the Euler system, which enables the aircraft embedded software with the Euler system as the operating system to have better adaptability when facing diversified aircraft tasks. At the same time, the development and improvement of the Euler operating system will promote the iterative upgrade of aircraft embedded software.

[0019] (2) The present invention designs a general and standardized domestic Euler operating system tailoring process, enabling the Euler system to be widely deployed on various aircraft embedded software, forming a set of aircraft embedded software systems with the Euler system as the operating system. During the aircraft development process, a unified aircraft embedded software operating system can reduce the workload of the top-level planning and design of the aircraft software system, improve the overall aircraft development efficiency, and reduce the aircraft development cost; during the aircraft mission execution process, a unified aircraft embedded software operating system can reduce the waste of aircraft software system resources, achieve the efficient utilization of aircraft software system resources, and improve the performance of the aircraft.

[0020] (3) The method for tailoring and deploying the domestic Euler operating system in aircraft embedded software according to the present invention meets the current domesticization needs of aircraft embedded software and can improve the autonomy, security, reliability, and stability of our country's aircraft embedded software.

[0021] (4) Based on the analysis of the hybrid deployment scenario, the present invention designs a hybrid deployment framework based on an autonomous system, uses OpenEuler + UniProton as the basic system, deploys Iceoryx as a middleware in the OpenEuler operating system for inter-system and intra-system communication, and deploys iSulad containers in the OpenEuler operating system to run intelligent applications. Through deployment verification, it can be found that extremely low latency is shown during the transmission of different-sized data packets and does not increase with the increase of data packets, indicating that the aircraft software hybrid deployment architecture of the present invention can effectively meet the needs of intelligent applications.

[0022] Of course, it is not necessary for any product implementing the present invention to achieve all the above-mentioned advantages simultaneously. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 It is a schematic diagram of the method flow of the present invention.

[0024] Figure 2 It is a schematic diagram of the process of tailoring the Euler system kernel to adapt to the functions of specific aircraft hardware proposed by the present invention.

[0025] Figure 3 This is a schematic diagram of the process of trimming the Euler system root file system based on the performance requirements of the aircraft embedded software proposed by the present invention.

[0026] Figure 4 This is a schematic diagram of the process of optimizing the startup time of the Euler system based on the performance requirements of the aircraft embedded software proposed by the present invention.

[0027] Figure 5 This is a schematic diagram of the process of adapting the hardware driver for the highly customized hardware of the aircraft based on the Euler system proposed by the present invention.

[0028] Figure 6 This is a resource requirement representation diagram based on a hypergraph.

[0029] Figure 7 This is a design diagram of the aircraft hybrid critical system architecture.

[0030] Figure 8 This is a design diagram of the hybrid deployment scheme based on an autonomous system.

[0031] Figure 9 This is a verification diagram of the hybrid deployment of the autonomous system.

[0032] Figure 10 This is a middleware performance test diagram. Detailed implementation manners

[0033] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0034] In the description of the present invention, it should be understood that the terms "opening", "upper", "lower", "thickness", "top", "middle", "length", "inner", "periphery", etc. indicating the orientation or positional relationship are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the components or elements referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the present invention.

[0035] Please refer to Figure 1 As shown, the embodiments of the present invention provide a trimming and deployment method of the Euler system in the aircraft embedded software, which specifically includes:

[0036] E1. Install the toolchain and its running dependencies on the build host, then perform environment initialization operations. Use the toolchain to build an Euler embedded system image for the ARM64 architecture, generate standard distribution components, set up a QEMU full-system simulator on the host side, and load the pre-built image for functional verification.

[0037] The process of installing the toolchain and its running dependencies on the build host and then performing environment initialization operations is as follows:

[0038] Install Docker and at the same time install the necessary software packages. Ensure that the user logs in again after being added to the Docker user group and configure the Docker environment. The installation code is as follows:

[0039] sudo yum install docker

[0040] sudo systemctl enable docker

[0041] sudo systemctl start docker

[0042] Ensure that the user logs in again after being added to the Docker user group. The code is as follows:

[0043] sudo yum install python3 python3-pip docker$ pip install oebuild

[0044] Configure the Docker environment. The code is as follows:

[0045] sudo usermod -a -G docker$(whoami)

[0046] sudo systemctl daemon-reload && sudo systemctl restart docker$ sudochmod o+rw / var / run / docker.sock

[0047] It should be noted that the build host refers to the system environment used for compiling, building, and packaging software. It is usually a server or the developer's personal computer, on which all necessary tools and dependency libraries are installed to enable the building and testing of software.

[0048] Runtime dependencies refer to the libraries, services, or other software components that a software needs to use during runtime. These dependencies are essential for the software to work properly. Without these dependencies, the software may not be able to start or run properly. When installing and configuring the build environment, it is necessary to ensure that all runtime dependencies are correctly installed and configured.

[0049] Docker is an open-source application container engine that allows developers to package their applications and the application's dependency packages into a portable container. Installing Docker is the process of installing the Docker service on the build host. Docker allows developers to create containerized application environments, ensuring a consistent runtime environment on different machines. By default, Docker requires administrative privileges to run. Adding a user to the Docker user group can avoid the need for sudo (superuser execution) privileges every time a Docker command is run. After adding a user to the Docker user group, it is necessary to log in again for the changes to take effect.

[0050] The sudo (Substitute User and Do) privilege is a command used in Unix-like operating systems that allows authorized users to execute commands as the superuser or another user.

[0051] Configuring the Docker environment includes setting the startup options of the Docker daemon, configuring the network, storage, security, etc. Configuring the Docker environment ensures that the Docker service can run according to the developer's requirements and is compatible with other system services.

[0052] The execution environment initialization operation specifically includes:

[0053] After creating the working directory, switch to the working directory; pull the build container and the yocto-meta-openeuler project code to complete the creation of the build directory and the synchronization of the code repository.

[0054] The code for creating the working directory is as follows:

[0055] oebuild init <work_dir>

[0056] Among them, <work_dir> is the working directory to be created.

[0057] The code for switching to the working directory is as follows:

[0058] cd <work_dir>

[0059] The code for pulling the build container and the yocto-meta-openeuler project code is as follows:

[0060] oebuild update

[0061] It should be noted that the execution environment initialization operation refers to the steps of setting up and preparing the environment before software development or building. These operations ensure a clean, consistent, and correctly configured starting point for the development or building process.

[0062] The working directory is the directory where developers place the source code, configuration files, and execute the build process. The working directory is created to have an independent and dedicated space to manage the project's files and avoid confusion with other project or system files.

[0063] Switching to the working directory means changing the current working path to the newly created working directory so that all subsequent operations are carried out in this directory.

[0064] Building a container refers to a Docker container specifically created for the build process. This container contains all the tools and environmental dependencies required to build the software.

[0065] Yocto is an open-source collaborative project that provides a set of tools and components for creating custom Linux systems. yocto-meta-openeuler is a Yocto metadata layer for the OpenEuler operating system, which contains the configurations required to build the OpenEuler system.

[0066] Building the Euler embedded system image for the ARM64 architecture through the toolchain and generating standard distribution components specifically includes:

[0067] Use the command in the oebuild working directory to create a configuration file compile.yaml for the Euler system image of the ARM64 architecture. After the build is completed, check whether there are preset files in the output directory under the build directory. If so, determine that the configuration result is successful; the preset files include zImage, openeuler-image-qemu-xxx.cpio.gz, openeuler-image-qemu-aarch64-xxx.iso, vmlinux.

[0068] zImage is the kernel image, built based on the openEuler community Linux 5.10 kernel.

[0069] openeuler-image-qemu-xxx.cpio.gz is the standard root file system image and has been subject to necessary security enhancements.

[0070] The openeuler-image-qemu-aarch64-xxx.iso is an ISO image used to create a USB startup disk.

[0071] The vmlinux is the corresponding vmlinux image for kernel debugging.

[0072] The steps to create a configuration file for the Euler system image with the ARM64 architecture using the command in the oebuild working directory are as follows:

[0073] Step 1: Switch to the compilation space directory containing compile.yaml.

[0074] Step 2: Enter the build_arm64 build directory according to the prompt and start building the Euler system image.

[0075] Step 3: Use the menu selection interface to fill in and select the corresponding configurations.

[0076] Step 4: After saving the configuration, continue to execute bitbake and subsequent commands in the above command.

[0077] The compile.yaml for creating a configuration file for the Euler system image with the ARM64 architecture using the command in the oebuild working directory has the following code:

[0078] oebuild generate -p qemu-aarch64 -d build_arm64

[0079] The code for entering the build_arm64 build directory according to the prompt and starting to build the Euler system image is as follows:

[0080] oebuild bitbake openeuler-image

[0081] The code for using the menu selection interface to fill in and select the corresponding configurations is as follows:

[0082] oebuild generate

[0083] The steps to set up the QEMU full-system emulator on the host side and load the pre-built image for functional verification are as follows:

[0084] Install QEMU on the host: openEuler 24.03, Ubuntu 22.04, SUSE Leap 15.4

[0085] The code is as follows:

[0086] sudo yum install qemu-system-aarch64

[0087] Use the command to start the Euler system image file. The code is as follows:

[0088] qemu-system-aarch64 -M virt-4.0 -m 1G -cpu cortex-a57 -nographic \

[0089] -kernel zImage \

[0090] -initrd openeuler-image-qemu-aarch64-*.rootfs.cpio.gz

[0091] If you want to shut down the current image, you can use <ctrl-a>Exit directly with +X, or close it through a command after the initial user login is completed. The code is as follows:

[0092] Poweroff

[0093] It should be noted that oebuild refers to a tool or framework for building operating system images. It is a command-line tool used to automate the compilation, packaging, and deployment processes of operating system images. Oebuild contains a series of scripts to handle these tasks, as well as a configuration file system for defining the specific details of the build process.

[0094] The ARM64 architecture refers to the 64-bit ARM architecture, also known as AArch64 (ARM Architecture 64-bit). It is a widely used processor architecture applicable to various devices, including smartphones, tablets, servers, and embedded systems.

[0095] The Euler system image refers to a pre-configured disk image based on the openEuler operating system. openEuler is an open-source Linux distribution. The Euler system image contains the file system of the operating system and pre-installed software, and can be used for deployment on physical servers or virtual machines.

[0096] QEMU is a solution for hardware virtualization by simulating different types of processors. It is an open-source project that supports multiple operating system platforms.

[0097] E2. Trim the Euler system kernel to adapt to specific hardware functions. Clone the Euler system kernel source code to the build environment, and precisely enable or disable kernel modules and features related to the target hardware through an interactive configuration interface. After completing the customization configuration, perform cross-compilation to generate a lightweight kernel image and module files, and deploy the compilation products to the build directory.

[0098] The process of trimming the Euler system kernel to adapt to specific aircraft hardware functions is as Figure 2 shown:

[0099] The above-mentioned E2, the specific implementation process includes:

[0100] Step 1. Clone the kernel source code: Open the terminal, use the git command to clone the source code repository of the Euler system kernel to the local computer, and switch to the directory of the cloned kernel source code.

[0101] Step 2. Set the cross-compilation toolchain: Determine the path of the cross-compilation toolchain, set the environment variable to point to the cross-compilation toolchain, and set the environment variable ARCH to arm64, indicating the target architecture.

[0102] Step 3, Configure the kernel: Use the default configuration file as the starting point, run makedefconfig, and then run makemenuconfig to enter the interactive configuration interface for configuration.

[0103] In the configuration interface, perform the following operations:

[0104] Select the options compatible with the target hardware.

[0105] Enable or disable kernel modules and features.

[0106] Save the configuration and exit.

[0107] Step 4, Compile the kernel: Run the make command to start compiling the kernel, use the -j option to specify the number of threads for parallel compilation, and wait for the compilation process to complete.

[0108] Step 5, Install the kernel modules: Run the makemodules_install command to install the kernel modules, and specify the INSTALLMODPATH environment variable to set the target path for module installation.

[0109] Step 6, Deploy the kernel image: Locate the kernel image file generated by compilation (usually arch / arm64 / boot / Image), and copy the kernel image file to the build directory or the target storage location.

[0110] Step 7, Create kernel header files: Run the makeheaders_install command to install the kernel header files.

[0111] Specify the INSTALLHDRPATH environment variable to set the target path for header file installation.

[0112] Step 8, Clean up the build environment: Run the make clean command to clean up the temporary files generated during the compilation process.

[0113] The cloned kernel source code will clone the kernel source code of the Euler system into the build environment, and its code is as follows:

[0114] git clone https: / / gitee.com / openeuler / kernel.git

[0115] Use the command to configure the kernel of the Euler system, disable or enable specific kernel features in the configuration interface to adapt to the corresponding hardware requirements, and its code is as follows:

[0116] cd kernel

[0117] make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig

[0118] After the configuration is complete, compile the EulerOS kernel. The code is as follows:

[0119] make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc)

[0120] Copy the compiled EulerOS kernel image and modules to the build directory. The code is as follows:

[0121] cp arch / arm64 / boot / Image .. / <work_dir> / build_arm64 / tmp / deploy / images / qemu-aarch64 /

[0122] It should be noted that Git is a distributed version control system used to track the source code history and collaboration. In Git, cloning refers to the process of copying an entire project from a remote repository to a local computer. The EulerOS kernel source code repository refers to the Git repository that stores the source code of the openEuler operating system kernel.

[0123] A cross-compilation toolchain refers to a set of tools used to compile executable code for a different architecture on one architecture.

[0124] An environment variable refers to a variable in the operating system used to store system-wide information such as paths, configuration options, etc. ARCH is an environment variable used to specify the target architecture type, which is set to arm64 here, indicating that the target system is based on the ARM64 architecture.

[0125] Makedefconfig is a command used to generate a basic configuration based on the default configuration file.

[0126] Makemenuconfig is a command that provides an interactive menu interface allowing users to configure kernel options in detail.

[0127] Make refers to a tool used for automated build processes, usually for compiling software.

[0128] The -j option is used to specify the number of threads when the make command is executed in parallel to improve the compilation speed.

[0129] makemodules_install is a command used to install the compiled kernel modules to a specified directory.

[0130] INSTALLMODPATH is an environment variable used to specify the target path for installing kernel modules.

[0131] A kernel image file refers to the executable file of the compiled kernel, usually with file names such as Image or vmlinuz.

[0132] The build directory or target storage location refers to the directory where the kernel image file will be copied, usually the directory prepared for booting.

[0133] makeheaders_install is a command used to install kernel headers, which are usually used for developing kernel modules or other software that needs to directly interact with the kernel.

[0134] INSTALLHDRPATH is an environment variable used to specify the target path for installing kernel headers.

[0135] Makeclean is a command used to clean up the temporary files and target files generated during the compilation process to free up disk space and prepare for the next compilation.

[0136] E3. By precisely defining package dependencies through editing the local configuration file, removing redundant features, and ensuring the integrity of the build layer, recompiling based on a custom package list to generate a streamlined Euler system image, while optimizing the boot performance, using system analysis tools to analyze the boot time, identifying and disabling unnecessary services, switching the default boot target to the multi-user mode, and trimming the boot scripts and system modules.

[0137] The process of precisely defining package dependencies through editing the local configuration file, removing redundant features, and ensuring the integrity of the build layer, and recompiling based on a custom package list to generate a streamlined Euler system image specifically includes:

[0138] The process of recompiling based on a custom package list to generate a streamlined Euler system image is as Figure 3 shown

[0139] Edit local.conf to specify the packages to be included or excluded in the <work_dir> / build_arm64 / conf / local.conf file. The code is as follows:

[0140] vi <work_dir> / build_arm64 / conf / local.conf

[0141] Remove unnecessary features from EXTRA_IMAGE_FEATURES.

[0142] Edit the bblayers.conf file to ensure that the project's bblayers.conf file includes all necessary layers.

[0143] Create a custom package list.

[0144] After completing the above configurations, run the bitbake command again to build the Euler system image.

[0145] The steps to create a custom package list are as follows:

[0146] Step 1: Create a file named image-config.bbappend in the <work_dir> / build_arm64 / conf / directory, and its code is as follows:

[0147] vi <work_dir> / build_arm64 / conf / image-config.bbappend

[0148] Step 2: Add the following content to the image-config.bbappend file:

[0149] IMAGE_INSTALL_append = " package1 package2" specifies the packages that need to be included.

[0150] Add the following content to the image-config.bbappend file:

[0151] IMAGE_INSTALL_remove = " package-to-remove" excludes the packages that are not needed.

[0152] After completing the above configurations, run the bitbake command again to build the Euler system image, and its code is as follows:

[0153] cd <work_dir> / build_arm64 /

[0154] oebuild bitbake openeuler-image

[0155] For optimizing the startup performance, use system analysis tools to analyze the startup time consumption, identify and disable unnecessary services, switch the default startup target to the multi-user mode, and trim the startup scripts and system modules, specifically including:

[0156] The process of optimizing the Euler system startup time based on the characteristics of aircraft embedded software is as Figure 4 shown.

[0157] Obtain the startup log, analyze the system startup time consumption, and based on the analysis results, list the non-essential services and stop and disable the non-essential services through systemd.

[0158] Use the systemd-analyze and systemd-analyze blame tools to analyze the system startup time consumption.

[0159] The systemd-analyze can output the total startup time and kernel time.

[0160] The systemd-analyze blame can list the startup time consumption of all services to find out the service with the longest startup time.

[0161] Stop and disable the unnecessary services through systemd. The code is as follows:

[0162] Code 1: Immediately stop the unnecessary service:

[0163] sudo systemctl stop <service_name>

[0164] Code 2: Prevent the service from starting automatically when the system restarts:

[0165] sudo systemctl disable <service_name>

[0166] Code 3: For multiple services, the following command can be used:

[0167] for service in bluetooth.service cups.service gdm.service; do

[0168] sudo systemctl disable $service

[0169] sudo systemctl stop $service

[0170] done

[0171] For the aircraft embedded scenario, set the system's default startup target (target) to multi-user mode to avoid loading the GUI (Graphical User Interface) and other unnecessary functions. The code is as follows:

[0172] Code 1: View the current default startup target

[0173] systemctl get-default

[0174] Code 2: Switch to multi-user mode

[0175] sudo systemctl set-default multi-user.target

[0176] Tailor and optimize the custom startup script to avoid executing unnecessary module functions.

[0177] Remove unnecessary services and tools from the file system, modify the image build configuration file, and remove unnecessary packages. The code is as follows:

[0178] IMAGE_INSTALL_remove = "package-to-remove"

[0179] The steps to tailor and optimize the custom startup script are as follows:

[0180] Step 1: Modify the service configuration file; open the service configuration file / etc / systemd / system / , comment or delete the function modules that do not need to be loaded.

[0181] Step 2: Disable Kernel module loading. For some modules that are loaded by default in the kernel, disable them by modifying / etc / modprobe.d / blacklist.conf.

[0182] Step 3: Update initramfs after saving. The code is as follows:

[0183] sudo dracut -f

[0184] It should be noted that local.conf is one of the configuration files of the Yocto project, which is used to define various parameters during the build process, such as package selection, feature enable / disable, etc.

[0185] <work_dir> / build_arm64 / conf / local.conf refers to the file path of local.conf under the specified build directory, which is used to configure the build environment for the ARM64 architecture.

[0186] EXTRA_IMAGE_FEATURES refers to a configuration item in local.conf, which is used to specify additional features of the image.

[0187] bblayers.conf refers to another configuration file of the Yocto project, which is used to specify the layers included in the build process.

[0188] A layer is a concept in the Yocto project, representing a set of related recipes and configuration files used to extend the functionality of the build system.

[0189] image-config.bbappend refers to a custom configuration file used to append or modify the default configuration of the Yocto build system.

[0190] IMAGE_INSTALL_append refers to a configuration item in image-config.bbappend used to specify additional packages to be included in the image.

[0191] IMAGE_INSTALL_remove refers to a configuration item in image-config.bbappend used to specify packages to be excluded from the image.

[0192] bitbake is the build tool in the Yocto project used to perform build tasks such as compiling packages and generating images.

[0193] systemd is the Linux system and service manager responsible for starting daemons and services.

[0194] systemd-analyze is a tool used to analyze the startup performance of systemd.

[0195] systemd-analyze blame is a subcommand of systemd-analyze used to list the startup time of services to identify bottlenecks.

[0196] <service_name> represents the name of a specific service, used for reference in systemd commands.

[0197] multi-user.target is a startup target in systemd representing the multi-user text mode without a graphical interface.

[0198] initramfs is the initial ramdisk file system used to provide necessary drivers and tools during system startup.

[0199] Dracut is a tool used to create initramfs images.

[0200] / etc / modprobe.d / blacklist.conf is a configuration file used to specify kernel modules that should not be loaded at startup.

[0201] / etc / systemd / system / is the directory for systemd service configuration files, which is used to customize the startup behavior of services.

[0202] The Kernel is the core component of the operating system. It acts as a bridge between application programs (software) and computer hardware, managing processes, memory, device drivers, file systems, and security.

[0203] E4. Clearly define the hardware specifications and driver requirements of the aircraft. Through device tree configuration, implement the definition of hardware interfaces and the binding of drivers. Develop dedicated driver modules for customized hardware, and complete kernel recompilation and system deployment.

[0204] The process of hardware driver adaptation for highly customized hardware of the aircraft based on the Euler system is as Figure 5 shown.

[0205] The above-mentioned process of clearly defining the hardware specifications and driver requirements of the aircraft, implementing the definition of hardware interfaces and the binding of drivers through device tree configuration, developing dedicated driver modules for customized hardware, and completing kernel recompilation and system deployment specifically includes:

[0206] Clearly define the list of hardware, hardware specifications, and driver requirements supported by the aircraft, including the specification documents and driver programs provided by the hardware manufacturer and the driver support provided by the open source community.

[0207] Accurately configure the Device Tree, adding to or modifying the device tree.

[0208] For some aircraft hardware without ready-made drivers, manually write or transplant drivers.

[0209] After completing the device tree and driver development, recompile the kernel and deploy it to the target system.

[0210] The above-mentioned process of manually writing or transplanting drivers for some aircraft hardware without ready-made drivers specifically has the following processing conditions:

[0211] Write a new driver or transplant a driver. If writing a new driver, according to the aircraft hardware document, refer to the Linux kernel driver model to write a kernel module. If transplanting a driver, transplant the driver program from other platforms and confirm the modifications required to adapt to the aircraft hardware platform.

[0212] After obtaining the new driver, modify the register mapping, update the device tree compatibility information, and conduct aircraft hardware driver testing and debugging, which specifically includes: First, use dmesg to check the driver loading log, then use modprobe to load the driver test function, and finally use tools such as i2cdetect to check whether the device is working properly.

[0213] It should be noted that dmesg is used to view kernel logs, including driver loading information.

[0214] modprobe is used to load and unload kernel modules (drivers).

[0215] After completing the device tree and driver development, recompile the kernel and deploy it to the target system, specifically including:

[0216] After compiling the kernel to ensure that the necessary drivers are enabled in the kernel configuration, check the newly added driver module in the device tree.

[0217] Package the kernel image, deploy the generated kernel image to the device startup directory, update the device tree, and copy the new device tree file to the target device.

[0218] It should be noted that the aircraft hardware specifications refer to the technical parameters of the hardware components used in the aircraft, including the specific models and performance indicators of the processor, memory, storage, sensors, communication modules, etc.

[0219] Driver requirements refer to the specific driver programs required for the operating system to correctly identify and use the hardware components in the aircraft.

[0220] The Device Tree is a data structure used to describe the attributes of hardware devices and is used to pass hardware information to the operating system during system startup.

[0221] Hardware interface definition refers to the physical and electrical characteristics of hardware components, such as interface type, signal standard, pin function, etc.

[0222] Driver binding refers to associating a hardware device with the corresponding driver program to ensure that the operating system can communicate with the hardware device through the driver program.

[0223] A dedicated driver module is a software module customized for specific hardware. It is usually included in the operating system kernel and is used to manage the behavior of hardware devices.

[0224] Kernel recompilation refers to recompiling the kernel after modifying the kernel configuration or adding new drivers to generate a new kernel image containing these changes.

[0225] System deployment refers to transferring the compiled kernel image and related system files to the target device and ensuring that the system can start and be used normally.

[0226] Manually writing or porting a driver means writing driver code from scratch according to the hardware specification document in the absence of a ready-made driver, or migrating the driver code from other systems or platforms to the current system.

[0227] The Linux kernel driver model is a set of standard frameworks and interfaces provided by the Linux kernel for writing device drivers.

[0228] A kernel module is a loadable part of the Linux kernel, usually used to implement specific hardware drivers or other functions.

[0229] Register mapping is the mapping relationship between the registers of a hardware device and memory addresses. The driver controls the hardware by reading and writing these addresses.

[0230] Device tree compatibility information refers to specifying the compatibility of a hardware device in the device tree so that the kernel can find and use the correct driver.

[0231] i2cdetect is a tool for detecting devices on the I2C bus, often used for debugging and verifying the connection of I2C devices.

[0232] Compiling the kernel refers to the process of using the kernel source code and configuration files to generate a kernel image.

[0233] Packing the kernel image means packing the compiled kernel and related files into a bootable image file.

[0234] The device boot directory refers to the directory stored on the device for booting the operating system, usually containing the kernel image and device tree files, etc.

[0235] E5. Deploy IceAntelope as middleware for communication between applications and between systems in the streamlined Euler system image operating system, and at the same time deploy iSulad containers to carry intelligent applications.

[0236] The deployment of IceAntelope as middleware for communication between applications and between systems in the streamlined Euler system image operating system, and at the same time the deployment of iSulad containers to carry intelligent applications specifically includes:

[0237] The aircraft conducts a requirements analysis of the software, describes the requirements of the aircraft's functional tasks for the architecture as a hypernetwork model based on a hypergraph, where resources are hyperedges and functional tasks are nodes, and obtains the incidence matrix of the hypergraph.

[0238] It should be explained that iSulad is a lightweight container runtime engine, similar to Docker, which is used to create, run, and manage containers. In the aircraft system, iSulad is used to carry intelligent applications, including machine learning models, data processing algorithms, etc.

[0239] The aircraft's requirements analysis of the software refers to a detailed analysis and definition of the functions, performance, reliability, etc. of the software required by the aircraft to ensure that the software can meet the operating requirements of the aircraft.

[0240] A hypergraph is a graph theory concept where an edge (called a hyperedge) can connect multiple nodes, as opposed to just two nodes in a traditional graph. In an aircraft system, a hypernetwork model is used to represent a complex system architecture, where nodes and hyperedges represent different components and their interactions.

[0241] In the hypernetwork model, each functional task is represented as a node, which can be various functional units of the aircraft, such as navigation, sensing, control, etc.

[0242] In the hypernetwork model, hyperedges represent resources that connect different functional tasks, such as processor time, memory, communication bandwidth, etc. These resources are necessary for executing functional tasks.

[0243] The incidence matrix is a mathematical matrix used to represent the relationship between nodes and hyperedges in the hypernetwork model. In the incidence matrix, each element represents the connection relationship between a node and a hyperedge, which can be a weight, existence, or other attributes. The incidence matrix is used to analyze and optimize the system architecture.

[0244] The aircraft conducts a requirements analysis on the software, specifically including:

[0245] Describing the requirements of the aircraft software functions for the architecture resources, and describing the functional tasks as:

[0246] ;

[0247] where is the set of functional tasks, is the real-time computing resource requirement of the functional task, is the non-real-time computing resource requirement, is the communication resource requirement, is the storage resource requirement.

[0248] The software functions of the aircraft have different requirements, involving the requirements of critical tasks, such as tasks like navigation, flight control, and collision avoidance, which need to be completed within a specific time to cope with complex and rapidly changing environments. Therefore, the main requirements for resources are and . While functions such as mission planning, status maintenance, and data analysis can be carried out during flight gaps or after flight, so the main requirements for resources are , and .

[0249] Describing the requirements of the aircraft functional tasks for the architecture as a hypernetwork model based on a hypergraph, specifically including: resources are hyperedges, and functional tasks are nodes, such as Figure 6 The shown figure represents the demand for resources, from which the incidence matrix of the hypergraph is obtained:

[0250] ;

[0251] Based on the incidence matrix, calculate the degree of nodes, node hyperdegree, hyperedge degree, hyperedge hyperdegree and their distributions, and then obtain the demand for real-time and non-real-time resources in the software architecture, so that when designing the software architecture, different systems are used to be responsible for their respective proficient functions.

[0252] Based on the incidence matrix, calculate the degree of nodes, node hyperdegree, hyperedge degree, hyperedge hyperdegree and their distributions, and then obtain the demand of the aircraft for real-time and non-real-time resources in the software architecture. In the embodiment of the present invention, that is, the aircraft software architecture for intelligent applications requires a hybrid deployment architecture of real-time and non-real-time systems.

[0253] Based on the demand of the aircraft for real-time and non-real-time resources in the software architecture, the autonomous system designs a hybrid deployment scheme.

[0254] The scenario analysis of the hybrid deployment includes:

[0255] In order to meet the real-time and non-real-time system requirements of the aircraft, the typical design scheme of the hybrid deployment is to use a processor with relatively strong performance to run Linux to be responsible for rich functions, and a real-time processor to run a real-time operating system to be responsible for real-time control or signal processing. The two communicate through the form of I / O, network or off-chip bus. However, this method has problems such as the need for two sets of systems in hardware and low integration. Deploying multiple OSs in a system-on-chip (SoC) can effectively solve this problem. One of the future evolution directions of the embedded system is the hybrid criticality system. As Figure 7 Shown is the aircraft hybrid criticality system architecture design, in which the hybrid deployment framework solves the problems of efficient hybrid deployment and efficient communication and collaboration, the embedded virtualization solves the problems of efficient isolation and protection and efficient resource sharing and scheduling, the MAC layer provides an efficient underlying communication mechanism, the transport layer provides a communication mechanism based on the abstraction of endpoints and channels, and the life cycle management function includes initialization, start, pause, and end.

[0256] Based on the autonomous system design of the hybrid deployment scheme, use OpenEuler plus UniProton as the basic system, deploy Iceoryx as the middleware in the openEuler operating system for communication between applications and systems, and deploy iSulad containers in the openEuler operating system to carry intelligent applications.

[0257] Based on the requirements of the aircraft for real-time and non-real-time resources in the software architecture, the autonomous system designs a hybrid deployment solution, specifically including:

[0258] Use OpenEuler plus UniProton as the basic system. Deploy Iceoryx in the openEuler operating system as middleware for communication between applications and systems, and deploy iSulad containers in the openEuler operating system to carry intelligent applications.

[0259] The design diagram of the hybrid deployment solution based on the autonomous system is as Figure 8 shown, where openEuler Embedded is an autonomous Linux-centered integrated embedded software platform, and UniProton is a real-time operating system launched by the openEuler community. Iceoryx is a high-performance, real-time communication middleware specifically used for scenarios involving large-scale, real-time data exchange. iSulad is a lightweight container engine provided by openEuler.

[0260] In the hybrid deployment of OpenEuler and UniProton, UniProton is pulled up after OpenEuler is started, and the real-time system and the non-real-time system are bound to the CPU for operation. The kernel module provides functions such as the startup of the real-time operating system UniProton, dedicated interrupt transceiver, and reserved memory management. MICA is a command-line tool, and micad is the daemon process of MICA, responsible for managing and controlling the creation, operation, and destruction of RTOS instances.

[0261] Deploy the system according to the design diagram of the hybrid deployment solution based on the autonomous system:

[0262] Hardware environment: Development board (CPU quad-core 1.5GHz ARM A72 (AArch64) RAM 8GB), and necessary peripherals.

[0263] Software environment: OpenEuler+UniProton system

[0264] The real-time system and OpenEuler are successfully deployed in a fused manner, and the system starts up smoothly to the user login interface as Figure 9 shown.

[0265] Test the deployment of the middleware, specifically including:

[0266] Deploy two middleware, Iceoryx and distributed soft bus, in the OpenEuler operating system for comparative testing.

[0267] The test method includes: by sending data packets of different sizes, with data payloads ranging from small to large (from 16 bytes to 4MB), recording the latency time of each transmission, as Figure 10 shown. The test shows that Iceoryx exhibits extremely low latency at all packet sizes, while the latency of message queues and Unix domain sockets increases significantly as the packet size increases, especially when the packet size exceeds 256 kB. The results show that the hybrid deployment architecture of the aircraft software can effectively meet the requirements of intelligent applications.

[0268] It should be noted that in this document, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, such that a process, method, article or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device.

[0269] The preferred embodiments of the present invention disclosed above are only used to assist in the description of the present invention. The preferred embodiments do not describe all the details in detail, nor do they limit the invention to the specific embodiments described. Obviously, many modifications and variations can be made according to the content of this specification. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the present invention, so that those skilled in the relevant art can understand and utilize the present invention well. As long as it does not deviate from the structure of the present invention or exceed the scope defined by the present invention, it should fall within the protection scope of the present invention.

Claims

1. A method for tailoring and deploying the Euler system in aircraft embedded software, characterized in that: include: E1. Install the toolchain and its running dependencies on the build host, then perform environment initialization operations, build the Euler embedded system image for the ARM64 architecture through the toolchain, generate standard distribution components, build the QEMU full-system simulator on the host side, and load the pre-built image for functional verification; E2. Tailor the Euler system kernel to adapt to specific hardware functions, clone the Euler system kernel source code to the build environment, accurately enable or disable kernel modules and features related to the target hardware through the interactive configuration interface, perform cross-compilation to generate lightweight kernel images and module files after completing the customized configuration, and deploy the compiled products to the build directory; E3. Edit local configuration files to precisely define package dependencies, remove redundant features and ensure build layer integrity. Recompile and generate a streamlined Euler system image based on a custom package list. Optimize startup performance, use system analysis tools to analyze startup time, identify and disable non-essential services, switch the default startup target to multi-user mode, and trim startup scripts and system modules. E4. Clarify the aircraft hardware specifications and driver requirements, implement hardware interface definition and driver binding through device tree configuration, develop dedicated driver modules for customized hardware, and complete kernel recompilation and system deployment; E5. In the streamlined Euler system image operating system, Bingling is deployed as the middleware for communication between applications and systems, and iSulad containers are deployed to carry intelligent applications.

2. The method for cutting and deploying the Euler system in aircraft embedded software according to claim 1, characterized in that: The tool chain and its running dependencies are installed on the build host, and then the environment initialization operation is performed. The specific implementation process is as follows: Install Docker and necessary software packages, ensure that the user is added to the Docker user group, log in again, and configure the Docker environment; The execution environment initialization operation specifically includes: After creating the working directory, switch to the working directory, pull the build container and project code, and complete the creation of the build directory and synchronization of the code repository.

3. The method for tailoring and deploying the Euler system in aircraft embedded software according to claim 1, characterized in that: The Euler embedded system image for ARM64 architecture is built through the tool chain to generate standard distribution components, specifically including: In the oebuild working directory, use the command to create a configuration file for the Euler system image of the ARM64 architecture. After the build is completed, check whether there is a preset file in the output directory under the build directory. If so, the configuration result is determined to be successful. The steps to use the command in the oebuild working directory to create a configuration file for the Euler system image of the ARM64 architecture are as follows: Step 1. Switch to the compilation space directory containing the configuration file; Step 2: Enter according to the prompts Build the directory and start building the Euler system image; Step 3: Use the menu selection interface to fill in and select the corresponding configuration; Step 4. After saving the configuration, continue to execute the bitbake and subsequent commands in the above command.

4. The method for tailoring and deploying the Euler system in aircraft embedded software according to claim 1, characterized in that: The specific implementation process of E2 includes: Step 1. Clone the kernel source code: Open the terminal, use the git command to clone the source code repository of the Euler system kernel to the local computer, and switch to the cloned kernel source code directory; Step 2. Set up the cross-compilation toolchain: Determine the path of the cross-compilation toolchain, set the environment variable to point to the cross-compilation toolchain, and set the environment variable ARCH to arm64, indicating the target architecture; Step 3. Configure the kernel: Using the default configuration file as a starting point, run , then run Enter the interactive configuration interface for configuration; Step 4. Compile the kernel: Run the make command to start compiling the kernel, use the -j option to specify the number of threads for parallel compilation, and wait for the compilation process to complete; Step 5: Install kernel module: Install kernel module and specify environment variables to set the target path for module installation. Step 6. Deploy the kernel image: Find the compiled kernel image file and copy it to the build directory or target storage location; Step 7. Create kernel header files: Install kernel header files; Specify environment variables to set the target path for header file installation; Step 8. Clean up the build environment: clean up temporary files generated during the compilation process.

5. The method for tailoring and deploying the Euler system in aircraft embedded software according to claim 1, characterized in that: The method precisely defines the software package dependencies by editing the local configuration file, removes redundant features and ensures the integrity of the build layer, and recompiles and generates a streamlined Euler system image based on the custom software package list, including: Edit the local build configuration file and specify the packages to be included or excluded in the file; Remove unnecessary features in build system variables; Edit the layer configuration file to make sure the project's layer configuration file contains all necessary layers; Create custom package lists; After completing the above configuration, re-run the bitbake command to build the Euler system image; The steps to create a custom package list are as follows: Step 1. Create an extension file in the configuration directory of the build system; Step 2: Specify the packages to be included and exclude the unnecessary packages.

6. The method for tailoring and deploying the Euler system in aircraft embedded software according to claim 1, characterized in that: The optimization of startup performance includes analyzing startup time using system analysis tools, identifying and disabling non-essential services, switching the default startup target to multi-user mode, and trimming startup scripts and system modules, specifically including: Obtain the startup log, analyze the system startup time, and based on the analysis results, list non-essential services and stop and disable non-essential services through systemd; For aircraft embedded scenarios, set the system's default startup target to multi-user mode to avoid loading the GUI and other unnecessary functions; Tailor and optimize custom startup scripts to avoid executing unnecessary module functions; Remove unnecessary services and tools from the file system, modify the image build configuration file, and remove unnecessary packages; The steps for tailoring and optimizing the custom startup script are as follows: Step 1: Modify the service configuration file, open the service configuration file, and comment or delete the function modules that do not need to be loaded; Step 2: Disable kernel module loading. For some modules loaded by default in the kernel, disable them by modifying the blacklist configuration file; Step 3: Save and then update the initialized memory file system.

7. The method for tailoring and deploying the Euler system in aircraft embedded software according to claim 1, characterized in that: The above clarifies the aircraft hardware specifications and driver requirements, implements hardware interface definition and driver binding through device tree configuration, develops dedicated driver modules for customized hardware, and completes kernel recompilation and system deployment, specifically including: Clarify the hardware list, hardware specifications and driver requirements that the aircraft needs to support, including specification documents and drivers provided by hardware manufacturers and driver support provided by the open source community; Accurately configure the device tree, add or modify the device tree; Manually write or port drivers for some aircraft hardware that do not have ready-made drivers; After completing the device tree and driver development, recompile the kernel and deploy it to the target system.

8. The method for tailoring and deploying the Euler system in aircraft embedded software according to claim 7, characterized in that: For some aircraft hardware that does not have a ready-made driver, manually write or transplant the driver. The specific processing conditions are: Write new drivers or port drivers. If writing new drivers, write kernel modules according to aircraft hardware documentation and refer to Linux kernel driver model. If porting drivers, port drivers from other platforms and confirm the changes required to adapt to aircraft hardware platform. After obtaining the new driver, modify the register map and update the device tree compatibility information, and perform aircraft hardware driver testing and debugging, including: first checking the driver loading log, then loading the driver test function, and finally checking whether the device is working properly.

9. The method for tailoring and deploying the Euler system in aircraft embedded software according to claim 7, characterized in that: After the device tree and driver development are completed, the kernel is recompiled and deployed to the target system, specifically including: After compiling the kernel and ensuring that the kernel configuration has enabled the necessary drivers, check the newly added driver module in Device Drivers; Package the kernel image, deploy the generated kernel image to the device boot directory, update the device tree, and copy the new device tree file to the target device.

10. The method for tailoring and deploying the Euler system in aircraft embedded software according to claim 1, characterized in that: The deployment of Bingling as middleware in the streamlined Euler system image operating system for communication between applications and systems, and the deployment of iSulad containers to carry intelligent applications specifically include: The aircraft conducts software requirements analysis and describes the requirements of the aircraft's functional tasks for the architecture as a hypernetwork model based on a hypergraph, where resources are hyperedges and functional tasks are nodes, and the hypergraph's association matrix is ​​obtained; Based on the association matrix, the node degree, node superdegree, superedge degree, superedge superdegree and their distribution are calculated, and then the aircraft's demand for real-time resources and non-real-time resources in the software architecture is obtained; Based on the aircraft's requirements for real-time and non-real-time resources in the software architecture, the autonomous system designs a hybrid deployment solution; A hybrid deployment solution is designed based on an autonomous system, using OpenEuler plus UniProton as the basic system. Bingling is deployed in the openEuler operating system as the middleware for communication between applications and systems, and iSulad containers are deployed in the openEuler operating system to carry intelligent applications.

Images