Cutting deployment method of Euler system in aircraft embedded software

Abstract

The invention discloses a cutting deployment method of an Euler system in aircraft embedded software, and relates to the field of aircraft embedded software, and the method comprises the following steps: E1, installing a necessary host package on a construction host, and initializing a construction environment; an Euler system mirror image of the ARM64 architecture is constructed; starting the QEMU and loading an Euler system mirror image file; e2, cutting an Euler system kernel to adapt to a specific hardware function; e3, cutting a root file system of the Euler system to remove unnecessary software packages and files; cutting an Euler system starting script and closing an unnecessary Euler system module; and E4, aiming at the highly customized hardware of the aircraft, carrying out special hardware driving adaptation optimization on the Euler system. And E5, deploying middleware in the simplified Euler system mirror image operating system, and deploying an iSulad container at the same time. According to the invention, on the basis of construction of a hardware drive special adaptation system, a standardized cutting process is established, a hybrid deployment architecture of OpenEuler and UniProton is designed, and the system has the functions of real-time control and intelligent task calculation.

Description

Technical Field

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

[0002] With the rapid development of aerospace technology, aircraft embedded software plays a more important role in aircraft. Complex aircraft represented by space stations and deep space exploration are intelligent and networked, and more functions need to be realized through software. The ability to develop aircraft embedded software directly reflects the core competitiveness of aircraft.

[0003] However, my country's aircraft embedded software currently faces many challenges. First, aircraft embedded software is closely related to hardware. The high degree of customization and diversity of aircraft hardware significantly affects and restricts the development of software. It is also difficult to solidify and continuously improve the maturity of specific codes such as underlying drivers, interface protocols, and soft and hard timing. Second, aircraft embedded software is deployed in different hardware products as a configuration item and is developed by different design teams. It belongs to a high real-time distributed topology architecture. Therefore, the design of aircraft embedded software not only needs to carry out interrupt allocation and processing, interface protocol design, timing design and other work of a single configuration item task, 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 continued to increase, and the trend of task diversification has become increasingly prominent. Task diversification has put forward higher requirements for 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 autonomy and controllability of information technology has become a key issue in national development. Aircraft embedded software is widely used, covering both military and civilian applications. Its autonomy, safety and reliability are factors that must be considered in the development process of aircraft embedded software.

[0004] Therefore, in order to solve the current problems faced by aircraft embedded software, meet the needs of localization of 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 tailoring and deployment method for domestic operating systems in aircraft embedded software.

[0005] In addition, traditional aircraft mostly use centralized architecture, which 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. Distributed architecture allows some computing tasks to be completed through cloud computing and edge computing, thereby alleviating the limitation of insufficient computing power of airborne equipment. However, it is difficult to meet the complex application scenarios of aircraft due to the influence of communication delays and data synchronization uncertainty.

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

[0007] The rapid development of intelligent applications has gradually expanded the mission execution mode of aircraft from a single real-time control mode to a hybrid mode where real-time and non-real-time systems coexist. However, this has brought new challenges to the software deployment architecture of aircraft. For example, the design of the hybrid deployment architecture of aircraft embedded real-time systems and non-real-time systems needs to take into account the complex task processing capabilities of non-real-time systems while meeting real-time requirements, and solve key issues such as system scheduling and resource balancing, system communication and data synchronization, and intelligent deployment and verification.

[0008] The prior art, such as the invention patent with announcement number: CN109063339B, is a digital spacecraft component-level embedded simulation system, including a host computer, and a management box and several equipment boxes connected to the host computer in sequence; the host computer is equipped with an embedded simulation platform, a flight environment simulation module, a synchronization management module, and an automatic deployment module; the management box includes a communication module, and a host computer command response module and a synchronization module connected to the communication module; the equipment box is plugged with a synchronization board and several simulation boards; the simulation board is used to receive and run the simulation program.

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

[0010] Based on the above scheme, it can be seen that in the prior art, the host computer integrates multiple modules such as embedded simulation platform, environmental simulation, synchronization management, automatic deployment, etc. The dependencies between modules are complex, which can easily cause chain problems during debugging and upgrading. The physical layered design of the management box and the equipment box increases the complexity of hardware connection. The simulation board uses a customized hardware interface, which is difficult to adapt to new spacecraft components. Secondly, the use of a dual-core architecture will increase the complexity of the system and bring higher power consumption. Therefore, a method is needed to meet 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 shortcomings of the prior art, the present invention provides a method for cutting and deploying an Euler system in aircraft embedded software. To achieve the above purpose, the present invention is implemented through the following technical solutions: The method for cutting and deploying an Euler system in aircraft embedded software includes: 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.

[0012] 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.

[0013] E3. Accurately define package dependencies by editing local configuration files, remove redundant features and ensure the integrity of the build layer, recompile and generate a streamlined Euler system image based on the 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.

[0014] 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.

[0015] 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.

[0016] Compared with the prior art, the embodiments of the present invention have at least the following beneficial effects: (1) The present invention provides a method for tailoring and deploying the Euler system in aircraft embedded software. Relying on the versatility and extensibility of the Euler operating system itself, the present invention can perform special hardware driver adaptation for highly customized aircraft hardware based on the Euler system, which makes the aircraft embedded software with the Euler system as the operating system more adaptable 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.

[0017] (2) The present invention designs a universal and standardized domestic Euler operating system cutting and processing flow, so that the Euler system can be deployed on a large scale on a variety of aircraft embedded software, forming a set of aircraft embedded software system with the Euler system as the operating system. During the aircraft development process, the 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 development efficiency of the aircraft, and reduce the cost of aircraft development; during the aircraft's mission execution, the unified aircraft embedded software operating system can reduce the waste of aircraft software system resources, achieve efficient use of aircraft software system resources, and improve the performance of the aircraft.

[0018] (3) The present invention meets the needs of localization of current aircraft embedded software by tailoring and deploying the domestic Euler operating system in aircraft embedded software, and can improve the autonomy, security, reliability and stability of my country's aircraft embedded software.

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

[0020] Of course, any product implementing the present invention does not necessarily need to achieve all of the above advantages at the same time. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0024] 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.

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

[0026] Figure 6 Representation graph for resource requirements based on hypergraph.

[0027] Figure 7 Design diagram for aircraft hybrid critical system architecture.

[0028] Figure 8 Design diagram for hybrid deployment scenarios based on autonomous systems.

[0029] Fig. 9 Validation diagram for hybrid deployment of autonomous systems.

[0030] Fig.10 This is a middleware performance test chart. DETAILED DESCRIPTION

[0031] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0032] In the description of the present invention, it should be understood that the terms "opening", "upper", "lower", "thickness", "top", "middle", "length", "inside", "all around" and the like indicating 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 understood as limiting the present invention.

[0033] See also Figure 1 As shown, an embodiment of the present invention provides a method for tailoring and deploying an Euler system in aircraft embedded software, which specifically includes: 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.

[0034] 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, make sure the user is added to the Docker user group, log in again, and configure the Docker environment. The installation code is as follows: sudo yum install docker sudo systemctl enable docker sudo systemctl start docker Make sure the user is added to the Docker user group and log in again. The code is as follows: sudo yum install python3 python3-pip docker$ pip install oebuild Configure the Docker environment; the code is as follows: sudo usermod -a -G docker$(whoami) sudo systemctl daemon-reload && sudo systemctl restart docker$ sudochmod o+rw / var / run / docker.sock It should be noted that the build host refers to the system environment used to compile, build and package software. It is usually a server or a developer's personal computer with all the necessary tools and dependent libraries installed on it to be able to build and test the software.

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

[0036] Docker is an open source application container engine that allows developers to package their applications and their dependencies 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. Docker requires administrator privileges to run by default. Adding a user to the Docker user group avoids requiring sudo (superuser execution) privileges every time you run a Docker command. After adding a user to the Docker user group, you need to log in again for the changes to take effect.

[0037] The sudo (Substitute User and Do) permission is a command used in Unix-like operating systems, which allows an authorized user to execute commands as a super user or other users.

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

[0039] The execution environment initialization operation specifically includes: After creating the working directory, switch to the working directory; pull the build container and yocto-meta-openeuler project code to complete the build directory creation and code repository synchronization.

[0040] The code for creating a working directory is as follows: oebuild init<work_dir> in,<work_dir> The working directory to be created.

[0041] The code for switching to the working directory is as follows: cd<work_dir> The code for pulling the build container and yocto-meta-openeuler project is as follows: oebuild update It should be noted that performing environment initialization operations refers to the steps to set up and prepare the environment before software development or building. These operations ensure that the development or building process has a clean, consistent, and correctly configured starting point.

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

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

[0044] A build container is a Docker container created specifically for the build process. This container contains all the tools and environment dependencies required to build the software.

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

[0046] 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 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, the configuration result is determined to be successful; the preset files include zImage, openeuler-image-qemu-xxx.cpio.gz, openeuler-image-qemu-aarch64-xxx.iso, and vmlinux.

[0047] zImage is a kernel image built based on the openEuler community Linux 5.10 kernel.

[0048] openeuler-image-qemu-xxx.cpio.gz is a standard root file system image with necessary security reinforcement.

[0049] openeuler-image-qemu-aarch64-xxx.iso is an ISO image used to create a USB boot disk.

[0050] vmlinux is the corresponding vmlinux image, which is used for kernel debugging.

[0051] 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 compile.yaml.

[0052] Step 2. Enter the build_arm64 build directory as prompted and start building the Euler system image.

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

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

[0055] In the oebuild working directory, use the command to create a configuration file compile.yaml for the Euler system image of the ARM64 architecture. The code is as follows: oebuild generate -p qemu-aarch64 -d build_arm64 According to the prompt, enter the build_arm64 build directory and start building the Euler system image. The code is as follows: oebuild bitbake openeuler-image The menu selection interface is used to fill in and select the corresponding configuration, and the code is as follows: oebuild generate The QEMU full system simulator is built on the host side, and the pre-built image is loaded for functional verification, which specifically includes: Install QEMU on the host: openEuler 24.03, Ubuntu 22.04, SUSE Leap 15.4 The code is as follows: sudo yum install qemu-system-aarch64 Use the command to start the Euler system image file. The code is as follows: qemu-system-aarch64 -M virt-4.0 -m 1G -cpu cortex-a57 -nographic \ -kernel zImage \ -initrd openeuler-image-qemu-aarch64-*.rootfs.cpio.gz To close the current mirror, you can use <ctrl-a>+X to exit directly, or after the initial user login is completed, close it through the command. The code is as follows: Poweroff 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 of operating system images. oebuild contains a series of scripts to handle these tasks, as well as a configuration file system to define the specific details of the build process.

[0056] ARM64 architecture refers to the 64-bit ARM architecture, also known as AArch64 (ARM Architecture 64-bit), which is a widely used processor architecture suitable for a variety of devices, including smartphones, tablets, servers, and embedded systems.

[0057] 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 operating system's file system and pre-installed software, and can be deployed on a physical server or virtual machine.

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

[0059] 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.

[0060] The process of tailoring the Euler system kernel to suit specific aircraft hardware functions is as follows: Figure 2 As shown: 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.

[0061] 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.

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

[0063] In the configuration interface, perform the following operations: Select the option that is compatible with your target hardware.

[0064] Enable or disable kernel modules and features.

[0065] Save the configuration and exit.

[0066] 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.

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

[0068] Step 6. Deploy the kernel image: Find the compiled kernel image file (usually arch / arm64 / boot / Image) and copy the kernel image file to the build directory or target storage location.

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

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

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

[0072] The cloning kernel source code clones the kernel source code of the Euler system into the construction environment. The code is as follows: git clone https: / / gitee.com / openeuler / kernel.git Use commands 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. The code is as follows: cd kernel make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-menuconfig After the configuration is complete, compile the Euler system kernel, the code is as follows: make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc) Copy the compiled Euler system kernel image and modules to the build directory. The code is as follows: cp arch / arm64 / boot / Image .. / <work_dir> / build_arm64 / tmp / deploy / images / qemu-aarch64 / It should be noted that Git is a distributed version control system used to track 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 Euler system kernel source code repository refers to the Git repository that stores the openEuler operating system kernel source code.

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

[0074] Environment variables refer to variables in the operating system, which are used to store system-wide information, such as paths, configuration options, etc. ARCH is an environment variable used to specify the target architecture type. Here it is set to arm64, indicating that the target system is based on the ARM64 architecture.

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

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

[0077] Make is a tool used to automate the build process, usually for compiling software.

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

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

[0080] INSTALLMODPATH is an environment variable used to specify the target path for kernel module installation.

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

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

[0083] makeheaders_install is a command used to install kernel header files, which are usually used to develop kernel modules or other software that needs to interact directly with the kernel.

[0084] INSTALLHDRPATH is an environment variable used to specify the target path for kernel header file installation.

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

[0086] E3. Accurately define package dependencies by editing local configuration files, remove redundant features and ensure the integrity of the build layer, recompile and generate a streamlined Euler system image based on the 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.

[0087] 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: The process of recompiling and generating a streamlined Euler system image based on a custom software package list is as follows Figure 3 Shown Edit local.conf, in<work_dir> The packages that need to be included or excluded are specified in the / build_arm64 / conf / local.conf file. The code is as follows: vi<work_dir> / build_arm64 / conf / local.conf Remove unnecessary features in EXTRA_IMAGE_FEATURES.

[0088] Edit the bblayers.conf file and make sure that the project's bblayers.conf file contains all the necessary layers.

[0089] Create custom package lists.

[0090] After completing the above configuration, re-run the bitbake command to build the Euler system image.

[0091] The steps to create a custom package list are as follows: Step 1:<work_dir> Create a file named image-config.bbappend in the / build_arm64 / conf / directory. The code is as follows: vi<work_dir> / build_arm64 / conf / image-config.bbappend Step 2. Add the following content to the image-config.bbappend file: IMAGE_INSTALL_append = " package1 package2" specifies the software packages that need to be included.

[0092] Add the following content in the image-config.bbappend file: IMAGE_INSTALL_remove = " package-to-remove" excludes unnecessary packages.

[0093] After completing the above configuration, re-run the bitbake command to build the Euler system image. The code is as follows: cd<work_dir> / build_arm64 / oebuild bitbake openeuler-image 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: The process of optimizing the startup time of the Euler system based on the characteristics of the aircraft embedded software is as follows: Figure 4 shown.

[0094] Get the startup log and analyze the time taken to start the system. Based on the analysis results, list non-essential services and stop and disable them through systemd.

[0095] Use systemd-analyze and systemd-analyze blame tools to analyze system startup time.

[0096] The systemd-analyze can output total boot time and kernel time.

[0097] The systemd-analyze blame command can list the startup time of all services to find the service that takes the longest time.

[0098] Stop and disable unnecessary services through systemd. The code is as follows: Code 1: Stop unnecessary services immediately: sudo systemctl stop<service_name> Code 2: Prevent the service from starting automatically when the system reboots: sudo systemctl disable<service_name> Code 3: For multiple services, you can use the following command: for service in bluetooth.service cups.service gdm.service; do sudo systemctl disable $service sudo systemctl stop $service done For the aircraft embedded scenario, set the system's default startup target to multi-user mode to avoid loading the GUI (graphical user interface) and other unnecessary functions. The code is as follows: Code 1: View the current default startup target systemctl get-default Code 2: Switch to multi-user mode sudo systemctl set-default multi-user.target Tailor and optimize custom startup scripts to avoid executing unnecessary module functions.

[0099] Remove unnecessary services and tools from the file system, modify the image building configuration file, and remove unnecessary packages. The code is as follows: IMAGE_INSTALL_remove = "package-to-remove" 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 / etc / systemd / system / , comment or delete the function modules that do not need to be loaded.

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

[0101] Step 3: After saving, update initramfs. The code is as follows: sudo dracut -f 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, such as package selection, feature enablement / disability, etc.

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

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

[0104] bblayers.conf refers to another configuration file of the Yocto Project that is used to specify the layers included in the build process.

[0105] Layer is a concept in the Yocto Project that represents a set of related recipes and configuration files used to extend the functionality of the build system.

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

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

[0108] IMAGE_INSTALL_remove refers to a configuration item in image-config.bbappend, which is used to specify the packages that need to be excluded from the image.

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

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

[0111] systemd-analyze is a tool for analyzing systemd startup performance.

[0112] systemd-analyze blame is a subcommand of systemd-analyze that lists the startup time of services in order to identify bottlenecks.

[0113] <service_name> A name that represents a specific service and is used to reference it in systemd commands.

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

[0115] initramfs is an initialization memory file system used to provide necessary drivers and tools during system startup.

[0116] Dracut is a tool for creating initramfs images.

[0117] / etc / modprobe.d / blacklist.conf is a configuration file that specifies kernel modules that should not be loaded at boot time.

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

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

[0120] 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.

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

[0122] 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.

[0123] Accurately configure the device tree (Device Tree) and add or modify the device tree.

[0124] For some aircraft hardware that does not have ready-made drivers, manually write or port drivers.

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

[0126] 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 the aircraft hardware documentation and refer to the Linux kernel driver model. If porting drivers, port drivers from other platforms and confirm the changes required to adapt to the aircraft hardware platform.

[0127] After obtaining the new driver, modify the register map and update the device tree compatibility information to test and debug the aircraft hardware driver. Specifically, 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.

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

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

[0130] 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 enables the necessary drivers, check the newly added driver module in the device tree.

[0131] 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.

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

[0133] Driver requirements refer to the specific drivers needed in order for the operating system to correctly identify and use the hardware components in the aircraft.

[0134] Device Tree is a data structure used to describe the properties of hardware devices and is used to pass hardware information to the operating system when the system starts.

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

[0136] Driver binding refers to associating hardware devices with corresponding drivers to ensure that the operating system can communicate with the hardware devices through the driver.

[0137] 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.

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

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

[0140] Manually writing or porting drivers means writing driver code from scratch according to hardware specification documents when there is no ready-made driver, or migrating driver code from other systems or platforms to the current system.

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

[0142] Kernel modules are loadable parts of the Linux kernel, usually used to implement specific hardware drivers or other functions.

[0143] The register map is the mapping relationship between the registers of the hardware device and the memory addresses. The driver controls the hardware by reading and writing these addresses.

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

[0145] i2cdetect is a tool for detecting devices on the I2C bus, often used to debug and verify the connection of I2C devices.

[0146] Compiling the kernel is the process of generating a kernel image using kernel source code and configuration files.

[0147] Packaging a kernel image means packaging the compiled kernel and related files into a bootable image file.

[0148] The device boot directory refers to the directory stored on the device and used to boot the operating system. It usually contains kernel images and device tree files.

[0149] 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.

[0150] 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 association matrix of the hypergraph is obtained. 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 aircraft systems, iSulad is used to carry intelligent applications, including machine learning models, data processing algorithms, etc.

[0151] Aircraft software requirements analysis 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 operational requirements of the aircraft.

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

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

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

[0155] The incidence matrix is ​​a mathematical matrix used to represent the relationship between nodes and hyperedges in a 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 system architecture.

[0156] The aircraft performs a software requirements analysis, specifically including: Describe the requirements of aircraft software functions for architectural resources and describe the functional tasks as: ; in is a collection of functional tasks. The real-time computing resource requirements for functional tasks, For non-real-time computing resource requirements, For communication resource requirements, For storage resource requirements.

[0157] Aircraft software features There are different requirements, involving mission-critical requirements such as 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 demand for resources is mainly and Mission planning, status maintenance, and data analysis can be performed during or after flight, so the resource requirements are mainly , and .

[0158] The requirements of aircraft functional tasks for architecture are described as a hypernetwork model based on a hypergraph, which specifically includes: resources as hyperedges, functional tasks as nodes, such as Figure 6 The following shows the demand for resources, which results in the association matrix of the hypergraph: ; Based on the association matrix, the node degree, node hyperdegree, hyperedge degree, hyperedge hyperdegree and their distribution are calculated, and then the demand for real-time resources and non-real-time resources in the software architecture is obtained. Therefore, when designing the software architecture, different systems are used to be responsible for their respective functions.

[0159] Based on the association matrix, the node degree, node hyperdegree, hyperedge degree, hyperedge hyperdegree and their distribution are calculated to obtain the aircraft's demand for real-time resources and non-real-time resources in the software architecture. In an embodiment of the present invention, the aircraft software architecture for intelligent applications requires a hybrid deployment architecture of real-time and non-real-time systems.

[0160] 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.

[0161] The scenario analysis of hybrid deployment includes: In order to meet the real-time and non-real-time system requirements of aircraft, the typical design of hybrid deployment is to use a high-performance processor running Linux for rich functions, and a real-time processor running a real-time operating system for real-time control or signal processing. The two communicate through I / O, network or off-chip bus. However, this method has problems such as requiring two systems in hardware and low integration. Deploying multiple OS in a system on chip (SoC) can effectively solve this problem. One of the future evolution directions of embedded systems is hybrid criticality systems. Figure 7 The figure shows the architecture design of the aircraft hybrid criticality system, in which the hybrid deployment framework solves the problems of efficient hybrid deployment and efficient communication and collaboration, 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 machine based on endpoint and channel abstraction, and the lifecycle management functions include initialization, start, pause, and end.

[0162] A hybrid deployment solution is designed based on an autonomous system, using OpenEuler plus UniProton as the basic system. Iceoryx is deployed in the openEuler operating system as middleware for communication between applications and systems, and iSulad containers are deployed in the openEuler operating system to carry intelligent applications.

[0163] 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, including: OpenEuler plus UniProton is used as the basic system, Iceoryx 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.

[0164] The design diagram of hybrid deployment solution based on autonomous system is as follows Figure 8 As shown in the figure, openEuler Embedded is an independent Linux-centric 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 designed to handle large-scale, real-time data exchange scenarios. iSulad is a lightweight container engine provided by openEuler.

[0165] In the hybrid deployment of OpenEuler and UniProton, OpenEuler is started and then UniProton 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, the sending and receiving of dedicated interrupts, and the management of reserved memory. MICA is a command line tool, and micad is the daemon process of MICA, which is responsible for managing and controlling the creation, operation, and destruction of RTOS instances.

[0166] Deploy the system according to the hybrid deployment solution design diagram based on the autonomous system: Hardware environment: development board (CPU quad-core 1.5GHz ARM A72 (AArch64) RAM 8GB) and necessary peripherals.

[0167] Software environment: OpenEuler+UniProton system The real-time system and OpenEuler are integrated and deployed successfully, and the system starts smoothly to the user login interface as shown Fig. 9 shown.

[0168] Test the deployment of the middleware, including: Two middlewares, Iceoryx and distributed soft bus, were deployed in the OpenEuler operating system for comparative testing.

[0169] The test method includes: sending packets of different sizes, from small to large (from 16 bytes to 4MB) data load, recording the delay time of each transmission, such as Fig.10 The test shows that Iceoryx has extremely low latency at all packet sizes, and the latency of message queues and Unix domain sockets increases significantly when the packet size increases, especially when the packet size exceeds 256kB. The results show that the hybrid deployment architecture of aircraft software can effectively adapt to the needs of intelligent applications.

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

[0171] The preferred embodiments of the present invention disclosed above are only used to help explain the present invention. The preferred embodiments do not describe all the details in detail, nor do they limit the invention to the specific implementation methods described. Obviously, many modifications and changes can be made according to the content of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the present invention, so that technicians in the relevant technical field can understand and use the present invention well. As long as they do not deviate from the structure of the present invention or exceed the scope defined by the present invention, they should all belong to 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