Method and system for inter-partition low-delay communication under ARINC 653 standard

Abstract

The invention discloses a method and a system for inter-partition low-delay communication under an ARINC 653 standard, which realize sharing of files / equipment through inter-partition message communication on the premise of not damaging the independence of an ARINC 653 partition and keeping the compatibility of an ARINC 653 APEX service interface, are very low in sharing overhead, provide a higher degree of freedom for software design, and can be applied to the field of communication and communication. And a low-delay inter-partition communication scheme is realized.

Description

Technical Field

[0001] The present invention relates to the field of inter-partition communication, and in particular to a method and system for inter-partition low-delay communication under the ARINC 653 standard. Background Art

[0002] As the core specification of the real-time operating system (RTOS) for avionics systems, the ARINC 653 standard defines a partitioned architecture that aims to ensure the independent operation of multiple mission-critical applications through a partitioning mechanism that isolates them in time and space, and to ensure the isolation and determinism of communication between each partition.

[0003] ARINC 653 standardizes the APEX (Application Executive) interface and provides a set of standardized APIs for partition scheduling management, task management, time management, and communication management to support the development and operation of applications in avionics systems.

[0004] In the existing communication process, the message memory is copied twice. For operating systems with user-mode / kernel-mode partitions, there may be additional copies between user-mode and kernel-mode. For a message service built on a real-time operating system, this will undoubtedly increase the latency of message delivery and increase the loss of message delivery between partitions.

[0005] In summary, a method and system for low-latency communication between partitions under the ARINC 653 standard are needed to address the deficiencies in the prior art. Summary of the invention

[0006] In view of the deficiencies in the prior art, the present invention provides a method and system for low-latency communication between partitions under the ARINC 653 standard, aiming to solve the above problems.

[0007] To achieve the above object, the present invention provides the following technical solution: a method for low-latency communication between partitions under the ARINC 653 standard, comprising the following steps: Step S1: The sender partition calls the create port service to establish a send port, and the receiver partition calls the create port service to establish a receive port; Step S2: The sender partition copies the message to be sent to a pre-allocated buffer by calling the send message service; Step S3: Mapping the cache to the memory address space of the receiving partition through the memory management unit; Step S4: The receiving partition directly reads the message from the mapped cache by calling the receive message service; Step S5: Searching and binding of file descriptors. The sender sends the file descriptor, searches for the struct file object corresponding to the file descriptor, binds it to the struct file pointer, and shares the file descriptor.

[0008] Optionally, when creating a port in step S1, the required cache size is calculated according to the parameters MAX_MESSAGE_SIZE and MAX_NB_MESSAGE, and the cache is allocated.

[0009] Optionally, the cache size calculation formula is: , Wherein, Ceiling function means rounding up, and PAGE_SIZE is an integer of the operating system page size.

[0010] Optionally, the message receiving service in step S4 is: The receiving partition calls the RECEIVE_QUEUING_MESSAGE service and reads the message content directly from the mapped cache.

[0011] Optionally, the file descriptor sent by the sender in step S5 is: When the sending partition calls the SEND_QUEUING_MESSAGE service to send a file descriptor, it looks up the struct file object corresponding to the file descriptor and caches the pointer to the struct file.

[0012] Optionally, the shared file descriptor in S5 is: When the receiving partition calls the RECEIVE_QUEUING_MESSAGE service, it looks for an unused file descriptor and binds this file descriptor to the struct file pointer in the cache to share the file descriptor.

[0013] A system for low-latency communication between partitions under the ARINC 653 standard, using a method for low-latency communication between partitions under the ARINC 653 standard, comprising: Soft bus daemon: responsible for providing message service interface, managing cache, partition-port mapping and routing, and coordinating specific operations of cross-partition communication; Soft bus driver module: responsible for managing the core functions of cross-partition communication, including sharing of file descriptors, mapping of memory buffers, and message delivery.

[0014] Optionally, the soft bus driver module implements the core functions of the soft bus through the operation of a virtual device, wherein the operation of the virtual device includes but is not limited to creating a communication port running in a queue mode and requesting to return a queue port identifier corresponding to the queue port name.

[0015] Optionally, the soft bus driver module also supports operations on the created ports, including but not limited to sending messages in the specified queue port, receiving messages from the specified queue port, sending file descriptors in the specified queue port, and receiving file descriptors from the specified queue port.

[0016] Optionally, when sending the file descriptor, a pointer to the file object struct file corresponding to the file descriptor is stored in the cache; when receiving the file descriptor, the pointer to the struct file is bound to the new file descriptor of the recipient to complete the sharing of the file or device.

[0017] Beneficial effects of the present invention: 1. In the present invention, without compromising the independence of ARINC 653 partitions and maintaining the compatibility of ARINC 653 APEX service interfaces, the sharing of files / devices through inter-partition message communication is realized. This sharing overhead is very low, which provides a higher degree of freedom for software design and realizes a low-latency inter-partition communication solution.

[0018] 2. In the present invention, through the copy-mapping process of the memory and the search-binding process of the file / device, through the message interface specified by ARINC 653, low-latency inter-partition communication is achieved, providing better support for the development and design of upper-level airborne system applications.

[0019] 3. In the present invention, the search-binding process is carried out with the support of the operating system, and the sharing of files / devices is realized semantically in the process of message sending-receiving. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 The present invention is a flow chart of a method.

[0021] Figure 2 This is an inter-partition communication interaction diagram of the present invention.

[0022] Figure 3 A system architecture diagram of the present invention.

[0023] Figure 4 A diagram is created for a communication port of the present invention.

[0024] Figure 5 This is a memory mapping diagram of the present invention.

[0025] Figure 6 A communication port acquisition diagram of the present invention.

[0026] Figure 7 This is a diagram of sending and receiving messages according to the present invention.

[0027] Figure 8 A file device sharing diagram of the present invention. DETAILED DESCRIPTION

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

[0029] like Figure 1 , Figure 2 as well as Figures 4 to 8 As shown, a method for low-latency communication between partitions under the ARINC 653 standard includes: The main source of latency in message transmission between partitions is memory copying, so reducing the number of memory copies during message transmission is the main design idea of ​​the soft bus. As mentioned above, a simple approach to this problem is to use two memory copies, one from P1 to the cache, and the other from the cache to P2.

[0030] Modern operating systems achieve process / partition memory independence by mapping virtual memory to physical memory. Generally speaking, this is achieved through the MMU (Memory Management Unit) hardware to implement paging memory management technology to protect different processes from interfering with each other. In this mechanism, virtual memory is divided into fixed-size pages, each page points to a location in physical memory through a page table entry, and the MMU uses the page table to find the physical address. When a process / partition accesses memory, it sees the virtual memory address. The MMU splits the virtual address into two parts: the page number and the page offset. The page number is used to find the page table entry. If the page table entry is valid, the page frame number corresponding to the physical memory is found from the page table entry and combined with the page offset to form a complete physical address; if the page table entry is invalid, it indicates that the page is not in physical memory, and the MMU will generate a page fault interrupt. The operating system will respond to this interrupt, load the required page from disk into physical memory, and update the page table to reflect the new mapping.

[0031] Specifically using this feature, this technical solution can reduce the number of copies. The specific idea is: When the sender calls SEND_QUEUING_MESSAGE, it copies the message memory to a specific buffer.

[0032] This cache is mapped to the memory address space of the receiver through the MMU, so that after the sender copies the message to the cache, the cache is available to the receiver when the receiver calls RECEIVE_QUEUING_MESSAGE.

[0033] This idea is called a single-copy transaction. Assuming the delay of the original solution is T , in The delay introduced by a memory copy is for , We assume The latency introduced by a memory mapping is already performed during the port establishment process in the implementation of this technical solution. In modern operating systems, memory mapping is a faster operation than memory copying, and does not increase with the growth of message memory length. Therefore, this technical solution has a lower and more stable latency, which is a desired feature in airborne systems.

[0034] Since the need for inter-partition communication runs through the entire system operation, the cache lifetime should be the same as the partition. This technical solution allocates cache after the partition is established and does not need to consider cache recycling. For operating systems that meet ARINC 653, when the partition is started, the two APEX interfaces CREATE_SAMPLING_PORT_ID or CREATE_QUEUING_PORT_ID will be called to create an inter-partition communication port. This technical solution will create a cache and map it to the receiving partition when the receiving port is created by the receiving partition. The parameters MAX_MESSAGE_SIZE in these two APEX interfaces represent the maximum message length, and MAX_NB_MESSAGE represents the maximum number of messages. The cache applied for by this technical solution in this step should not be less than the product of the maximum message length and the maximum number of messages. In addition, the cache size should be an integer number of operating system page sizes PAGE_SIZE. Therefore, the cache size applied for should be:

[0035] The Ceiling function means rounding up.

[0036] Another advantage of this technical solution is that it can realize the sharing of files / devices between partitions in the form of messages at a low cost. Take the operating system that meets the Portable Operating System Interface (POSIX) as an example. This type of operating system uses "everything is a file" as its design concept; under this concept, files / devices are represented by file descriptors (File Descriptor) to the application layer. The data type of a file descriptor is generally an integer. For different partitions, passing the literal value of this integer through messages is meaningless and does not represent the sharing of files / devices: because file descriptors with the same value have different meanings in different partitions, and cannot be guaranteed to correspond to the same file or device, this technical solution uses the support of the operating system to perform the search-binding process, and semantically realizes the sharing of files / devices in the process of sending and receiving messages. The specific process is as follows: When the sender calls SEND_QUEUING_MESSAGE to send a file descriptor, it does not copy the file descriptor to the cache, but finds the struct file object corresponding to the file descriptor and caches the pointer to this struct file.

[0037] When the receiver calls RECEIVE_QUEUING_MESSAGE, it finds an unused file descriptor in the running context of the receiving partition and maps this new file descriptor to the corresponding struct file, thereby realizing the sharing of file descriptors.

[0038] The file descriptor and struct file in the above process description are based on the example of an operating system that meets the Portable Operating System Interface (POSIX). In this type of system, a file descriptor is a non-negative integer, usually represented as an integer variable in the user program. When a program opens a file (or other resources, such as a network socket, device node, etc.), the kernel returns a file descriptor. This file descriptor can be used to perform subsequent read and write operations; the struct file object is a reference count-managed data structure used to represent the status of an open file / device. It is created when the first caller opens the file / device and is released when all callers close the file / device. In this design, the file descriptor is an index pointing to the struct file, and the process has its own private file descriptor table, which records all open files and their associated struct files. When a file / device is opened, the operating system will assign a file descriptor to the process that opens the file. If the file / device has not been opened by other callers, the operating system will create a struct file to track the status of the file / device and establish a mapping relationship between the file descriptor and the newly created struct file by updating the file descriptor table. If the file / device has been opened, the operating system will find the corresponding struct file object and also establish this mapping relationship by updating the file descriptor table. On other operating systems, the concepts and processes are similar: files / devices will also be used by user programs in the form of resource handles, and sharing between partitions can be achieved through the search-binding process of this technical solution.

[0039] This technical solution is based on a message sending / receiving interface and establishes a mapping relationship between a file descriptor and a struct file object through a file descriptor table. When sending a file descriptor, first find the pointer of the file object struct file corresponding to the file descriptor and store the pointer in a cache. When receiving a file descriptor, first apply for an unused file descriptor in the receiver's file descriptor table. By updating the receiver's file descriptor table, the pointer to the struct file in the cache is bound to the new file descriptor, thereby completing the sharing of files / devices.

[0040] In summary, this technical solution implements low-latency inter-partition communication through the message interface specified by ARINC 653 by using the memory copy-mapping process and the file / device search-binding process, thus providing better support for the development and design of upper-level airborne system applications.

[0041] A system for low-latency communication between partitions under the ARINC 653 standard, the architecture is as follows Figure 3 As shown in FIG. 1 , the softbus, as a service module of the operating system, is divided into two parts: the softbus daemon and the softbus driver.

[0042] As a service provider of ARINC 653 message functions, the soft bus daemon starts running when the system starts. It is responsible for providing interfaces to each partition, managing cache, determining partition-port mapping and routing, and coordinating specific operations of cross-partition communication.

[0043] The soft bus driver is a custom kernel module that manages the core functions of cross-partition communication. It handles the sharing of file descriptors, mapping of memory buffers, and message delivery to ensure that inter-partition communication can be completed efficiently and with low latency. The driver interacts directly with system calls and resources in the partition, providing underlying support based on the operating system.

[0044] When the operating system is started, the device " / dev / softbus" is registered when the soft bus driver is loaded. This is a virtual device. The core functions of the soft bus are implemented by operating the device. From the perspective of the soft bus driver, the available commands for the device include the following Table 1

[0045] The above command returns the communication port between partitions. The operations that can be performed on the port are shown in Table 2 below.

[0046] During the partition initialization phase, the soft bus will perform port initialization operations for each partition. The partition calls CREATE_QUEUING_PORT to establish a communication port and obtain PORT_ID. The function call process is as follows: Figure 4 Shown CREATE_QUEUING_PORT implements the function of establishing a port by interacting with the soft bus driver and returns PORT_ID. In this process, the corresponding relationship between PORT_ID and cache is established. Note that when the partition establishes a receiving port, a mapping between the cache and the partition memory space should be established, such as Figure 5 Shown During the partition operation phase, the port ID can be obtained through GET_QUEUING_PORT_ID. The process is as follows Figure 6 As shown, the partition obtains the port ID corresponding to the port name from the soft bus daemon process through interaction with the soft bus driver.

[0047] like Figure 7As shown, after obtaining PORT_ID, the partition can operate the cache. For the sender, the relevant API can be called to send and receive messages. For the softbus driver, the relevant operations are SOFTBUS_CMD_SEND_MSG and SOFTBUS_CMD_RECEIVE_MSG. The main operation of SOFTBUS_CMD_SEND_MSG is to copy the message to the cache corresponding to PORT_ID. For the receiver of the message, because the cache has been mapped to its own address space, no additional copying is required to receive the message.

[0048] For file / device sharing, it is similar to the sending and receiving of messages: for the softbus driver, the related operations are SOFTBUS_CMD_SEND_FD and SOFTBUS_CMD_RECEIVE_FD. This technical solution uses this pair of softbus driver commands to realize the sharing function. The flow chart is as follows: Figure 8 shown.

[0049] When sending a file descriptor, the pointer to the file object structfile corresponding to the file descriptor is stored in the cache; similarly, when receiving a file descriptor, the pointer to the struct file is bound to the new file descriptor of partition 2 (named target_fd in the figure), thereby completing the sharing of files / devices.

[0050] The present invention realizes the sharing of files / devices through inter-partition message communication without compromising the independence of ARINC 653 partitions and maintaining the compatibility of ARINC 653 APEX service interfaces. This sharing overhead is very low, which provides a higher degree of freedom for software design and realizes a low-latency inter-partition communication solution.

[0051] Through the copy-map process of memory and the search-bind process of files / devices, low-latency inter-partition communication is achieved through the message interface specified by ARINC 653, providing better support for the development and design of upper-level airborne system applications. Through the support of the operating system, the search-bind process is carried out, and file / device sharing is semantically achieved in the process of message sending and receiving.

[0052] 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 low-latency communication between partitions under the ARINC 653 standard, characterized in that: The following steps are involved: Step S1: The sender partition calls the create port service to establish a send port, and the receiver partition calls the create port service to establish a receive port; Step S2: The sender partition copies the message to be sent to a pre-allocated buffer by calling the send message service; Step S3: Mapping the cache to the memory address space of the receiving partition through the memory management unit; Step S4: The receiving partition directly reads the message from the mapped cache by calling the receive message service; Step S5: Searching and binding of file descriptors. The sender sends the file descriptor, searches for the struct file object corresponding to the file descriptor, binds it to the struct file pointer, and shares the file descriptor.

2. The method for low-latency communication between partitions under the ARINC 653 standard according to claim 1, characterized in that: When creating a port in step S1, the required buffer size is calculated according to the parameters MAX_MESSAGE_SIZE and MAX_NB_MESSAGE, and the buffer is allocated.

3. The method for low-latency communication between partitions under the ARINC 653 standard according to claim 2, characterized in that: The cache size calculation formula is: ， Wherein, Ceiling function means rounding up, and PAGE_SIZE is an integer of the operating system page size.

4. The method for low-latency communication between partitions under the ARINC 653 standard according to claim 1, characterized in that: The message receiving service in step S4 is: The receiving partition calls the RECEIVE_QUEUING_MESSAGE service and reads the message content directly from the mapped cache.

5. The method for low-latency communication between partitions under the ARINC 653 standard according to claim 1, characterized in that: The file descriptor sent by the sender in step S5 is: When the sending partition calls the SEND_QUEUING_MESSAGE service to send a file descriptor, it looks up the struct file object corresponding to the file descriptor and caches the pointer to the struct file.

6. The method for low-latency communication between partitions under the ARINC 653 standard according to claim 1, characterized in that: The shared file descriptor in S5 is: When the receiving partition calls the RECEIVE_QUEUING_MESSAGE service, it looks for an unused file descriptor and binds this file descriptor to the struct file pointer in the cache to share the file descriptor.

7. A system for low-latency communication between partitions under the ARINC 653 standard, using the method for low-latency communication between partitions under the ARINC 653 standard as claimed in claim 1, characterized in that: include: Soft bus daemon: responsible for providing message service interface, managing cache, partition-port mapping and routing, and coordinating specific operations of cross-partition communication; Soft bus driver module: responsible for managing the core functions of cross-partition communication, including sharing of file descriptors, mapping of memory buffers, and message delivery.

8. The system for low-latency communication between partitions under the ARINC 653 standard according to claim 7, characterized in that: The soft bus driver module implements the core functions of the soft bus through the operation of the virtual device, and the operation of the virtual device includes but is not limited to creating a communication port running in a queue mode and requesting to return a queue port identifier corresponding to the queue port name.

9. The system for low-latency communication between partitions under the ARINC 653 standard according to claim 7, characterized in that: The soft bus driver module also supports operations on the created ports, including but not limited to sending messages in the specified queue port, receiving messages from the specified queue port, sending file descriptors in the specified queue port, and receiving file descriptors from the specified queue port.

10. The system for low-latency communication between partitions under the ARINC 653 standard according to claim 9, characterized in that: When sending the file descriptor, a pointer to the file object struct file corresponding to the file descriptor is stored in the cache; When receiving a file descriptor, bind the pointer of struct file to the new file descriptor of the receiver to complete the sharing of the file or device.

Images