Airborne display portable system based on virtual machine and construction method

Abstract

The present invention discloses an airborne display portable system based on a virtual machine and a construction method, and develops an ARINC 653 system. When changing the underlying OS, most of the upper-layer codes can be reused, thereby reducing the development cost of the entire system, and the system can be run across different hardware. Applications of the airborne system can be developed and debugged in an open source system, thereby reducing the trial and error cost, and the system can be directly deployed on non-critical avionics equipment.

Description

Technical Field

[0001] The present invention relates to the field of electromechanical equipment, and in particular to an onboard display transplantable system based on a virtual machine and a construction method thereof. Background Art

[0002] The ARINC 653 standard is a set of real-time operating system (RTOS) architecture standards for avionics systems developed by Aeronautical Radio, Inc. (ARINC). The standard aims to define a common architecture and interface for avionics equipment to support partitioned real-time system design. Its core goal is to provide deterministic behavior between multiple partitions, ensuring that each partition has independent resources and deterministic execution time, thereby improving the safety and reliability of the entire system.

[0003] Existing ARINC 653 operating systems are all commercial operating systems, which are generally costly and have potential maintenance and support risks. For avionics system developers, they are a development environment that lacks community support and is restricted, which often affects the delivery cycle of the final product and increases development costs and risks.

[0004] In summary, a virtual machine-based onboard display portable system and construction method are needed to address the deficiencies in the prior art. Summary of the invention

[0005] In view of the deficiencies in the prior art, the present invention provides an onboard display portable system based on a virtual machine and a construction method thereof, aiming to solve the above problems.

[0006] To achieve the above object, the present invention provides the following technical solution: an onboard display portable system based on a virtual machine, comprising an application layer, a virtual machine monitoring layer and an operating system abstraction layer,

[0007] The application layer runs onboard applications based on the APEX API.

[0008] The virtual machine monitoring layer provides soft bus services for communication between partitions of virtual machines.

[0009] The operating system abstraction layer is used to schedule CPU time for each partition at the kernel level;

[0010] The operation of the application layer depends on the services provided by the operating system abstraction layer.

[0011] Optionally, the application layer sets an APEX interface, which is suitable for developing underlying services for ARINC 653 applications, and provides underlying services and resource management strategies for processes in partitions on different operating systems through the APEX interface and using the operating system abstraction layer.

[0012] Optionally, the tasks of the virtual machine monitoring layer include:

[0013] Make the upper ARINC 653 partitions secure and the application binary interface compatible through virtualization;

[0014] Through the soft bus service, ARINC 653 partitions between virtual machines can communicate with each other, which is simulated through virtual I / O and the inter-process communication mechanism on the host machine.

[0015] Optionally, the core of the operating system layer is to schedule ARINC 653 partitions running in virtual machines by scheduling different Hypervisors.

[0016] A method for constructing an onboard display portable system based on a virtual machine comprises the following steps:

[0017] Step S1: Select a host machine, determine the hardware platform according to the top-level requirements of the avionics system, and run the Linux operating system on the selected hardware platform;

[0018] Step S2: Partition scheduling, using eBPF to schedule ARINC 653 partitions on the Linux operating system;

[0019] Step S3: soft bus configuration communication, providing soft bus services based on Linux IPC mechanism, and configuring communication between ARINC 653 partitions;

[0020] Step S4: software source code module is established, according to the functional requirements of the avionics software, the software source code module is established based on the partition design and ARINC653;

[0021] Step S5: compiling an executable file. If the operating system provides an ARINC 653 interface, only the avionics software source code is compiled into an executable file. Otherwise, the avionics software source code and the ARINC 653 service layer / OS abstraction layer are compiled into an executable file together.

[0022] Step S6: software packaging, packaging the operating system and avionics software executable files into an executable software package, which will run in the virtual machine;

[0023] Step S7: packaging the entire system including the host operating system, partition scheduler / soft bus, virtual machine and avionics software based on the virtual machine;

[0024] Step S8: Deployment, operation and testing: deploy, run and test the above packaged software in the host machine.

[0025] Optionally, the host machine is selected in step S1 by specifically performing the following steps:

[0026] Step S11: clarify the requirements of the avionics system, including the CPU computing power, storage requirements and interface type, as well as real-time requirements;

[0027] Step S12: selecting a hardware platform according to the requirements of the avionics system, the hardware platform including but not limited to an embedded processor, a single board computer or an industrial-grade computer;

[0028] Step S13: Configure the Linux operating system, select the Linux operating system version according to the requirements, customize the Linux operating system kernel according to the hardware characteristics and application requirements, install the necessary tool chain, configure the file system, select the appropriate file system format and start the loader;

[0029] Step S14: Development and testing: building a development environment on the host machine, developing software, writing applications, and conducting comprehensive testing.

[0030] Optionally, the partition scheduling in step S2 is performed in the following manner:

[0031] Step S21: Use cgroups to create different partitions, and configure independent file system mount points and other namespaces for each partition;

[0032] Step S22: Write an eBPF program to intercept specific system calls to control task scheduling. The BPF program determines which partition's tasks should be executed according to a predefined schedule.

[0033] Step S23: define a task list and execution schedule for each partition, and trigger execution of each task at a predetermined time in the eBPF program;

[0034] Step S24: communication between tasks, setting a shared memory area or IPC mechanism for tasks within a partition to enable mutual communication between partitions;

[0035] Step S25: Perform testing and verification to ensure that the scheduling behavior complies with the requirements of the ARINC 653 standard.

[0036] Optionally, configuring the communication between ARINC 653 partitions in step S3 includes the following contents:

[0037] Define the communication protocol: determine the message format, transmission method and error handling mechanism;

[0038] Create partitions: Use cgroups to create different partitions and allocate independent resources to each partition;

[0039] Set up the IPC mechanism: select shared memory or sockets as the communication mechanism, create the necessary shared memory segments or sockets so that each partition can use them correctly;

[0040] Programming implementation: write appropriate code in each partition to implement the functions of sending and receiving messages. If shared memory is used, the data remains consistent.

[0041] Optionally, the software source code in step S4 is established in the following manner:

[0042] Step S41: clarify the functional requirements, identify the security critical areas and determine the security level according to the corresponding time, throughput and resource occupancy performance indicators;

[0043] Step S42: Divide the entire system into multiple logical partitions according to functional requirements, define communication interfaces between the partitions, and make data exchange comply with ARINC 653 requirements;

[0044] Step S43: further subdividing each partition into manageable modules, defining input and output interfaces for each module, and enabling modules to communicate through ARINC 653 API;

[0045] Step S44: Select a suitable programming language and write the code according to the modular principle so that each file is responsible for one function point;

[0046] Step S45: Perform individual tests and combined tests on each module to ensure that the modules work together normally;

[0047] Step S46: Verify the correctness of the code in the safety-critical area to meet the requirements of the ARINC 653 standard.

[0048] Beneficial effects of the present invention:

[0049] 1. In the present invention, when developing an ARINC 653 system, most of the upper-layer codes can be reused by changing the underlying OS, thereby reducing the development cost of the entire system;

[0050] 2. The present invention can run across different hardware, can develop and debug applications of airborne systems in open source systems, reduce trial and error costs, and can be directly deployed on non-critical avionics equipment. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 A schematic diagram of an architecture structure of the present invention.

[0052] Figure 2 A schematic diagram of the architecture of alternative solution one.

[0053] Figure 3The following is a schematic diagram of the architecture of alternative solution 2.

[0054] Figure 4 The present invention is a flow chart of a construction method. DETAILED DESCRIPTION

[0055] In order to more clearly illustrate the embodiments of the invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0056] like Figure 1 As shown, a virtual machine-based airborne display portable system adopts a three-layer structure, including an ARINC 653 application layer, a virtual machine monitoring layer, and an operating system abstraction layer.

[0057] The top layer is the ARINC 653 application layer, which runs various airborne applications based on the ARINC 653 APEX API in partitions. This layer runs in a virtual machine. For operating systems that do not provide ARINC 653 interfaces (Linux, VxWorks, ...), an ARINC 653 service layer is also required to provide the APEX API interface required by ARINC 653. This ensures that the application is supported at the API level. The ARINC 653 layer is based on the services provided by the OS abstraction layer.

[0058] The middle layer is the virtual machine monitoring layer (Hypervisor), which is based on virtual machine technology to ensure the security of the upper-layer ARINC 653 partitions. In addition, this layer needs to provide soft bus services to ensure that the ARINC653 partitions in each virtual machine can communicate with each other.

[0059] The lower layer is the operating system abstraction layer, which is based on the Linux operating system and uses eBPF to schedule the CPU time of each partition at the Linux kernel level.

[0060] In the ARINC application layer, the ARINC 653 service layer is required to implement the APEX interface to provide the underlying services for the ARINC 653 partition application for the development of ARINC 653 applications. Since all processes in the partition share the same address space, the ARINC653 process should correspond to the thread / task of the underlying operating system. For non-ARINC653 operating systems, the technical solution runs in user mode, so the scheduling of the process must also be implemented in the ARINC 653 service layer using a user mode daemon.

[0061] In addition, the ARINC 653 service layer needs to implement the APEX interface to provide low-level services for ARINC 653 partition applications for developing ARINC 653 applications. This work can be done based on the OS abstraction layer. The OS abstraction layer defines basic operating system-level features, such as process management, memory management, timing management, and interrupt handling, which are the basis for ARINC-653 implementation. This layer also provides operating system-independent interfaces that can be directly used by the upper layer. These interfaces actually implement the ARINC-653 standard. The operating system abstraction layer makes it easy to port ARINC-653 implementations to different operating systems. In addition, we also support different resource management strategies, such as CPU scheduling and dynamic memory allocation. Specific ARINC 653 applications have the need to configure different strategies for resource management, such as dynamic memory allocation and CPU scheduling strategies; we meet such requirements by pointing function pointers to different implementations.

[0062] The OS abstraction layer achieves portability by encapsulating the underlying OS services into OS-independent primitives. Taking ARINC653's process creation, suspension, and resumption functions, the implementation scheme in Linux / VxWorks / RT-Thread is as follows:

[0063] On Linux, each partition corresponds to an OS process, and each ARINC Process corresponds to an OS thread. Correspondingly, on VxWorks, we can represent a partition with an RTP (Real Time Process). On other RTOS that do not support concepts like OS processes or RTP, the mapping relationship between partitions and ARINC 653 Processes needs to be maintained in the OS abstraction layer.

[0064] The above design can abstract such primitives to support the API CREATE_PROCESS in APEX: CREATE_PROCESS calls the primitive OS_create_process of the ARINC 653 service layer. OS_create_process adopts different implementations depending on the underlying operating system:

[0065] Call pthread_create in the corresponding OS thread on Linux to create an OS thread

[0066] Call taskOpen in the corresponding RTP on VxWorks to create a VxWorks task. Note that this type of task needs to be created in a private namespace.

[0067] On RT-Thread, it is necessary to establish and maintain the direct mapping relationship between partition and ARINC Process in the OS abstraction layer, and call rt_thread_create to create the task.

[0068] Furthermore, in the three underlying operating systems, we implemented CREATE_PROCESS and completed the establishment of ARINC 653Process.

[0069] In addition, for the APEX Process suspend API SUSPEND / SUSPEND_SELF, and the Process resume API RESUME, we can support the corresponding primitives OS_process_suspend and OS_process_resume in the OS abstraction layer.

[0070] On Linux systems, there is no corresponding primitive in user mode, but you can use pthread_kill to send a signal and let the corresponding thread call pthread_cond_wait to suspend itself; similarly, OS_process_resume can also be implemented using pthread_kill and pthread_signal.

[0071] On the VxWorks system, directly call the corresponding taskSuspend / taskResume to achieve it.

[0072] On RT-Thread, call the corresponding rt_thread_suspend / rt_thread_resume to implement it.

[0073] Therefore, we implemented the three ARINC 653 APIs SUSPEND / SUSPEND_SELF and RESUME in the three operating systems.

[0074] The virtual machine monitoring layer has two tasks:

[0075] Based on virtual machine technology, the security of the upper ARINC 653 partition is ensured, and the ABI (Application Binary Interface) compatibility of the previous application is maintained. In this technical implementation, each ARINC 653 partition runs in a different virtual machine. They are not only isolated from each other in time, but also ensure the isolation of memory, file resources, and external devices from the perspective of the virtual machine. Different ARINC 653 configurations can be easily changed through virtual machine configuration. During this modification process, there is no need to recompile the application. In addition, virtual machine management software similar to qemu can allow codes based on different CPU architectures and ISAs of the host economy to run in a simulated manner, further improving portability.

[0076] In addition, this layer needs to provide a soft bus service to ensure that the ARINC 653 partitions in each virtual machine can communicate with each other. This service simulates the function of the onboard bus through virtual IO and IPC on the host machine.

[0077] The core function of the operating system layer is to schedule ARINC 653 partitions running in virtual machines by scheduling each hypervisor from the Linux operating system kernel. The scheduling information of the partitions comes from the partition definition file based on the XML file format required by ARINC653. In order to minimize the changes to the kernel, the scheduling of ARINC653 partitions can be implemented through eBPF (extended Berkeley Packet Filter) to implement kernel state functions in user state, thereby meeting the ARINC 653 requirements for partition scheduling.

[0078] like Figure 2 As shown in the figure, it is alternative solution 1. Each ARINC 653 partition also runs in the virtual machine. This solution can be called a user layer solution. Each partition runs in an independent process in the user state. The scheduling of the partition and the scheduling of the ARINC 653Process need to be completed in the ARINC 653 Service Layer in the client operating system, that is, they are all implemented in the user state.

[0079] There is no need to modify the system kernel scheduling. The client needs to implement the ARINC 653 service layer and the OS abstraction layer. Other hardware architectures cannot be supported in the virtual machine, which is easy to implement.

[0080] like Figure 3 As shown in the figure, for alternative 2, POSIX (Portable Operating System Interface) is a set of standards that define the interfaces and services that the operating system should provide so that applications can run on multiple operating systems without modification. Most operating systems have a certain degree of POSIX support, so we can implement the ARINC 653 service layer completely on POSIX and ensure that ARINC 653 applications only use APEX and POSIX.

[0081] The program has the following features:

[0082] There needs to be some restrictions on the implementation of the application, but this is often unrealistic for previous projects and software. Various operating systems have different support for POSIX, which often limits portability.

[0083] It does not require an OS abstraction layer and cannot be applied to systems without POSIX support. It is necessary to implement partitioning and ARINC Process scheduling based on the POSIX interface.

[0084] When the present invention develops an ARINC 653 system, even if the underlying OS is changed, most of the upper-layer codes can still be reused, thereby reducing the development cost of the entire system, being able to run across different hardware, being able to develop and debug applications of the airborne system in an open source system, reducing the cost of trial and error, and being able to be directly deployed in non-critical avionics equipment, such as unmanned aerial vehicle avionics systems.

[0085] like Figure 4 As shown, a method for constructing an onboard display portable system based on a virtual machine includes the following steps:

[0086] Step S1: Selecting a host: The host should determine the hardware platform based on the top-level requirements of the avionics system, on which the Linux operating system needs to run;

[0087] Select the host machine by following the steps below:

[0088] Step S11: clarify the requirements of the avionics system, including the CPU computing power, storage requirements and interface type, as well as real-time requirements;

[0089] Step S12: selecting a hardware platform according to the requirements of the avionics system, the hardware platform including but not limited to an embedded processor, a single board computer or an industrial-grade computer;

[0090] Step S13: Configure the Linux operating system, select the Linux operating system version according to the requirements, customize the Linux operating system kernel according to the hardware characteristics and application requirements, install the necessary tool chain, configure the file system, select the appropriate file system format and start the loader;

[0091] Step S14: Development and testing: building a development environment on the host machine, developing software, writing applications, and conducting comprehensive testing.

[0092] Step S2: Implement the partition scheduler based on eBPF and complete the ARINC 653 partition scheduling function on the Linux operating system.

[0093] Partition scheduling is done in the following ways:

[0094] Step S21: Use cgroups to create different partitions, and configure independent file system mount points and other namespaces for each partition;

[0095] Step S22: Write an eBPF program to intercept specific system calls to control task scheduling. The BPF program determines which partition's tasks should be executed according to a predefined schedule.

[0096] Step S23: define a task list and execution schedule for each partition, and trigger execution of each task at a predetermined time in the eBPF program;

[0097] Step S24: communication between tasks, setting a shared memory area or IPC mechanism for tasks within a partition to enable mutual communication between partitions;

[0098] Step S25: Perform testing and verification to ensure that the scheduling behavior complies with the requirements of the ARINC 653 standard.

[0099] Step S3: Based on the Linux IPC mechanism, the soft bus function is implemented on the Linux operating system, and the communication function between ARINC 653 partitions is completed through configuration;

[0100] Configuring ARINC 653 inter-partition communications involves the following:

[0101] Define the communication protocol: determine the message format, transmission method and error handling mechanism;

[0102] Create partitions: Use cgroups to create different partitions and allocate independent resources to each partition;

[0103] Set up the IPC mechanism: select shared memory or sockets as the communication mechanism, create the necessary shared memory segments or sockets so that each partition can use them correctly;

[0104] Programming implementation: write appropriate code in each partition to implement the functions of sending and receiving messages. If shared memory is used, the data remains consistent.

[0105] Step S4: According to the functional requirements of the avionics software, based on the partition design, complete the software source code module based on ARINC 653,

[0106] The software source code is established in the following ways:

[0107] Step S41: clarify the functional requirements, identify the security critical areas and determine the security level according to the corresponding time, throughput and resource occupancy performance indicators;

[0108] Step S42: Divide the entire system into multiple logical partitions according to functional requirements, define communication interfaces between the partitions, and make data exchange comply with ARINC 653 requirements;

[0109] Step S43: further subdividing each partition into manageable modules, defining input and output interfaces for each module, and enabling modules to communicate through ARINC 653 API;

[0110] Step S44: Select a suitable programming language and write the code according to the modular principle so that each file is responsible for one function point;

[0111] Step S45: Perform individual tests and combined tests on each module to ensure that the modules work together normally;

[0112] Step S46: Verify the correctness of the code in the safety-critical area to meet the requirements of the ARINC 653 standard.

[0113] Step S5: If the operating system does not provide an ARINC 653 interface, the avionics software source code is compiled together with the ARINC 653 service layer / OS abstraction layer into an executable file based on the guest operating system.

[0114] If the operating system provides an ARINC 653 system interface, compile the avionics software source code into an executable file based on the operating system.

[0115] Step S6: Package the guest operating system and avionics software executable files. This executable software package will run in the virtual machine.

[0116] Step S7: Package the entire system, including the host operating system, the partition scheduler / soft bus, the virtual machine, and the avionics software based on the virtual machine.

[0117] Step S8: deploy, run and test the software package generated in step S7 in the host machine.

[0118] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modification, equivalent substitution or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for constructing an onboard display portable system based on a virtual machine, characterized in that: The following steps are involved: Step S1: Select a host machine, determine the hardware platform according to the top-level requirements of the avionics system, and run the Linux operating system on the selected hardware platform; Step S2: Partition scheduling, using eBPF technology to schedule ARINC 653 partitions on the Linux operating system; Partition scheduling is done in the following ways: Step S21: Use cgroups to create different partitions, and configure independent file system mount points and other namespaces for each partition; Step S22: Write an eBPF program to intercept system calls to control task scheduling. The eBPF program determines which partition's tasks should be executed according to a predefined schedule. Step S23: define a task list and execution schedule for each partition, and trigger execution of each task at a predetermined time in the eBPF program; Step S24: communication between tasks, setting a shared memory area or IPC mechanism for tasks within a partition to enable mutual communication between partitions; Step S25: Perform testing and verification to ensure that the scheduling behavior complies with the requirements of the ARINC 653 standard; Step S3: soft bus configuration communication, providing soft bus services based on Linux IPC mechanism, and configuring communication between ARINC 653 partitions; Step S4: software source code module is established, according to the functional requirements of the avionics software, the software source code module is established based on the partition design and ARINC 653; Step S5: compiling an executable file. If the operating system provides an ARINC 653 interface, only the avionics software source code is compiled into an executable file. Otherwise, the avionics software source code is compiled together with the ARINC 653 service layer and the OS abstraction layer into an executable file. On Linux, each partition corresponds to an OS process, and each ARINC Process corresponds to an OS thread. The mapping relationship between partitions and ARINC 653 Processes is maintained in the OS abstraction layer. Step S6: software packaging, packaging the operating system and avionics software executable files into an executable software package, which will run in the virtual machine; Step S7: packaging the entire system including the host operating system, partition scheduler / soft bus, virtual machine and avionics software based on the virtual machine; Step S8: Deployment, operation and testing: deploy, run and test the above packaged software in the host machine.

2. The method for constructing an onboard display portable system based on a virtual machine according to claim 1, characterized in that: The host machine is selected in step S1 by the following steps: Step S11: clarify the requirements of the avionics system, including the CPU computing power, storage requirements and interface type, as well as real-time requirements; Step S12: selecting a hardware platform according to the requirements of the avionics system, the hardware platform including but not limited to an embedded processor, a single board computer or an industrial-grade computer; Step S13: Configure the Linux operating system, select the Linux operating system version according to the requirements, customize the Linux operating system kernel according to the hardware characteristics and application requirements, install the tool chain, configure the file system, select the appropriate file system format and start the loader; Step S14: Development and testing: building a development environment on the host machine, developing software, writing applications, and conducting comprehensive testing.

3. The method for constructing an onboard display portable system based on a virtual machine according to claim 1, characterized in that: Configuring the communication between ARINC 653 partitions in step S3 includes the following contents: Define the communication protocol: determine the message format, transmission method and error handling mechanism; Create partitions: Use cgroups to create different partitions and allocate independent resources to each partition; Set up the IPC mechanism: select shared memory or sockets as the communication mechanism, create shared memory segments or sockets so that each partition can use them correctly; Programming implementation: write appropriate code in each partition to implement the functions of sending and receiving messages. If shared memory is used, the data remains consistent.

4. The method for constructing an onboard display portable system based on a virtual machine according to claim 1, characterized in that: The software source code in step S4 is established in the following manner: Step S41: clarify the functional requirements, identify the security critical areas and determine the security level according to the corresponding time, throughput and resource occupancy performance indicators; Step S42: Divide the entire system into multiple logical partitions according to functional requirements, define communication interfaces between the partitions, and make data exchange comply with ARINC 653 requirements; Step S43: further subdividing each partition into manageable modules, defining input and output interfaces for each module, and enabling modules to communicate through ARINC 653 API; Step S44: Select a suitable programming language and write the code according to the modular principle so that each file is responsible for one function point; Step S45: Perform individual tests and combined tests on each module to ensure that the modules work together normally; Step S46: Verify the correctness of the code in the safety-critical area to meet the requirements of the ARINC 653 standard.

Images