An RPC communication method based on ARINC653 partitions

Abstract

The present invention provides an RPC communication method based on ARINC653 partitions. The 653 partition operating system runs on both the client physical platform and the server physical platform, both of which include multiple 653 application partitions, and an RPC core support module is configured in the core OS. Each partition on the server side provides an RPC service, including: an RPC service discovery process, a client discovery RPC service process, and a server registration RPC service process; the client partition calls the PRC service on the server side, and the response processing of the server side partition; among them, the client partition calls the PRC service on the server side, including: RPC synchronous call processing or RPC asynchronous call processing. The technical solution of the embodiment of the present invention solves the problems that in the existing partition operating system, the cross-node call processing of applications may be complicated, the platform transplantation is difficult, and it is difficult to meet the requirements of the future distributed avionics system for the rapid migration of applications.

Description

Technical Field

[0001] The present invention relates to, but is not limited to, the technical field of computer system software, and specifically provides an RPC communication method based on ARINC653 partitions. Background Art

[0002] In avionics systems, multifunctions are processed on the same physical platform, and an integrated processing platform emerges as the times require. The partitioned operating system that complies with the avionics ARINC653 standard widely used in this integrated processing platform can provide capabilities such as time and space isolation partitions, static storage management, and fault monitoring.

[0003] Future avionics systems need to execute tasks through multi-processors or even multi-computers in cooperation, and their processing methods are developing in the direction of distributed processing. However, if multiple physical platforms of the current partitioned operating system need to communicate, only explicit use of network protocols can be applied, and the application calls are complicated to process, and platform transplantation is difficult, which is difficult to meet the requirements of future avionics systems for rapid function migration. Summary of the Invention

[0004] The purpose of the embodiments of the present invention is to provide an RPC communication method based on ARINC653 partitions to solve the problems that when the existing partitioned operating system communicates between multiple physical platforms, due to the only application of explicit use of network protocols, the application calls are complicated to process, the platform transplantation is difficult, and it is difficult to meet the requirements of future avionics systems for rapid function migration.

[0005] The technical solution of the embodiments of the present invention is as follows: The embodiments of the present invention provide an RPC communication method based on ARINC653 partitions. The 653 partitioned operating system runs on both the client physical platform and the server physical platform. Both the client physical platform and the server physical platform include multiple 653 application partitions, and an RPC core support module is configured in the core operating system (OS). Moreover, each partition on the server side provides an RPC service; the RPC call method includes:

[0006] Step 1, the RPC service discovery process, including: the client discovery RPC service process and the server registration RPC service process;

[0007] Step 2, the client partition calls the PRC service of the server side by sending an RPC service request, and the server side partition processes the response to the RPC service request;

[0008] Among them, the client partition calls the PRC service of the server side, including: RPC synchronous call processing or RPC asynchronous call processing; during the RPC synchronous call processing, it waits until the service result returned by the server side or the timeout; during the RPC asynchronous call processing, a callback function is registered during the call, and when the RPC core support module in the kernel layer receives the service result returned by the server side, it delivers a virtual interrupt message to the client partition to indicate to execute the callback function to the client partition.

[0009] Optionally, in the RPC communication method based on ARINC653 partitions as described above, the process of the client discovering the RPC service in step 1 includes:

[0010] The RPC core support module of the client creates and runs two tasks during initialization, including: an RPC broadcast packet sending task and an RPC broadcast packet receiving task;

[0011] Among them, the RPC broadcast packet sending task is used to obtain the groups of RPC service numbers and port numbers of each server side with an established network connection when the client starts, and save the obtained groups of RPC service numbers and port numbers in the local service information copy;

[0012] The RPC broadcast packet receiving task is used to receive the RPC service port numbers broadcast by the server side that has completed the port mapping service during the operation of the client, and update the local saved service information copy according to the RPC service port numbers received this time.

[0013] Optionally, in the RPC communication method based on ARINC653 partitions as described above, the process of the server side registering the RPC service in step 1 includes:

[0014] The server side partition enters the service address mapper in the kernel layer by calling the service registration interface, so that the service address mapper dynamically assigns corresponding port numbers to the RPC service, and saves the RPC service of the server side partition corresponding to the assigned port numbers in the service address mapping table; the RPC core support module of the server side broadcasts the groups of RPC service numbers and port numbers of the registered RPC service in the network.

[0015] Optionally, in the RPC communication method based on ARINC653 partitions as described above, the process of the server side registering the RPC service in step 1 further includes:

[0016] Update the content in the service address mapping table according to the newly registered RPC service of the server side and the exit of the registered RPC service.

[0017] Optionally, in the RPC communication method based on ARINC653 partitions as described above, the synchronous call processing of the client partition in step 2 includes:

[0018] The client partition sends an RPC service synchronous call request and the timeout time, and waits for the server to return the result all the time. If the call return result is received before the timeout time arrives, the client partition processes the return result normally; otherwise, call error handling is performed.

[0019] Optionally, in the RPC communication method based on ARINC653 partitions as described above, the asynchronous call processing of the client partition in step 2 includes:

[0020] The client partition sends an RPC service asynchronous call request and registers a callback function for processing the returned service result, and continues to process other functional tasks;

[0021] In the kernel layer of the client, the RPC core support module creates a daemon process for receiving the service result. The newly created daemon process waits to receive the processing result returned by the server. When the daemon process receives the return result, it sends a virtual interrupt message to the client partition that sent the request to indicate that the callback function of the client partition processes the return result.

[0022] Optionally, in the RPC communication method based on ARINC653 partitions as described above,

[0023] During the service discovery process of step 1, the server partition also calls the server stub in this partition, and the called server stub creates the corresponding RPC server handle; during the registration of the RPC service, an RPC daemon task of the RPC service is also created and started in the kernel layer, and a service daemon process is created in the server partition.

[0024] Optionally, in the RPC communication method based on ARINC653 partitions as described above, the response processing of the server partition to the RPC service request in step 2 includes:

[0025] When the RPC daemon task in the kernel layer of the server receives an RPC service request, it sends the RPC service request to the server partition corresponding to the RPC service request in the form of a virtual interrupt message through the RPC server handle, so that the service daemon process of the server partition responds to the RPC service request, and returns the processing result to the client partition corresponding to the RPC service call in the client through the RPC core support module in the kernel layer.

[0026] The beneficial effects of the embodiments of the present invention are:

[0027] An RPC communication method based on ARINC653 partitions is proposed in an embodiment of the present invention, which provides the ability of remote procedure call for application partitions on a distributed embedded operating system platform with a kernel-layer partition architecture. The implementation of the present invention mainly includes the following aspects: First, analyze the timing of service enabling, and use two methods of active discovery combined with passive broadcast to enable the client to perceive all service information enabled on the network. Second, the client requests calls in both synchronous and asynchronous ways, and the asynchronous situation is implemented using the virtual interrupt mechanism. Third, the service resides in the partition, and the server receives the request and processes the service.

[0028] By adopting the technical solution provided in the embodiment of the present invention, the ability of cross-node interoperability can be provided to partition applications on a distributed embedded system platform, realizing transparent interoperability of global tasks and resources; in a distributed embedded system, a function call mechanism between nodes in a real-time and deterministic distributed system can be realized for application partitions based on the network, supporting transparent interoperability between multi-node applications; in addition, by supporting synchronous / asynchronous modes, applications can flexibly select calls according to demand scenarios and tolerate network delays. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The drawings are used to provide a further understanding of the technical solution of the present invention, and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the technical solution of the present invention, and do not constitute a limitation to the technical solution of the present invention.

[0030] Figure 1 It is a schematic diagram of the working principle of an RPC communication method based on ARINC653 partitions provided in an embodiment of the present invention;

[0031] Figure 2 It is a schematic flowchart of the RPC service discovery process in the RPC communication method based on ARINC653 partitions provided in an embodiment of the present invention;

[0032] Figure 3 It is a schematic diagram of the working principle of an asynchronous call request in the RPC communication method based on ARINC653 partitions provided in an embodiment of the present invention;

[0033] Figure 4 It is a schematic flowchart of the processing of a client requesting a service and a server-side partition responding to the request in the RPC communication method based on ARINC653 partitions provided in an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0034] To make the objectives, technical solutions, and advantages of the present invention clearer and more understandable, the embodiments of the present invention will be described in detail below with reference to the drawings. It should be noted that, without conflict, the embodiments and features in the present application can be combined arbitrarily with each other.

[0035] As described in the above background art, when using the existing partitioned operating system for communication between multiple physical platforms, only explicit use of network protocols can be applied. Therefore, there are problems such as complicated application call processing, difficult platform transplantation, and difficulty in meeting the requirements of future avionics systems for rapid function migration.

[0036] Since the partitioned operating system provides capabilities such as time and space isolation partitions, static storage management, and fault monitoring, and has strong real-time performance, reliability, determinism, and security. Therefore, the partitioned operating system is widely used in avionics systems.

[0037] In the future distributed processing avionics system, a complete business function may need to be completed through the cooperation of multiple distributed application entities, and high-quality transparent interoperability capabilities between these applications need to be provided. As described above, the communication method in the existing partitioned operating system can only apply explicit use of network protocols, with complicated application call processing and difficult platform transplantation, making it difficult to meet the requirements of future avionics systems for rapid function migration.

[0038] For business functions that need to be completed through the cooperation of multiple distributed application entities, especially for the human-machine interface / display control area, which consists of a server and various display control devices, the functions are encapsulated as services in the server for each display control device to call to complete the presentation of information. Therefore, a service-oriented remote procedure call (RPC) mechanism can be considered to make it as convenient for the client to make a remote call as a local call, so that the caller cannot perceive the logic of the remote call, thereby realizing service-based interoperability.

[0039] However, the partitioned operating system provides time and space isolation partitions, and different applications reside in different partitions. The current general RPC mechanism does not make special treatment for the partitioned operating system, and cannot meet the synchronous / asynchronous call services of client partition applications and the remote provision of services by different partition applications on the server side.

[0040] In order to enable the applications deployed in partitions to have remote procedure call and interoperability capabilities in a distributed embedded partitioned operating system platform, the embodiments of the present invention provide an RPC communication method based on ARINC653 partitions. This RPC call method proposes a technical approach to deploy the client and the server in partitions by analyzing the RPC solution, supports synchronous and asynchronous service calls, and realizes a function call mechanism between nodes in a real-time and deterministic distributed system based on the network.

[0041] The present invention provides the following specific embodiments that can be combined with each other. For the same or similar concepts or processes, they may not be repeated in some embodiments.

[0042] Figure 1It is a schematic diagram of the working principle of an RPC communication method based on ARINC653 partitions provided by an embodiment of the present invention. The embodiment of the present invention adopts a client-server mode to implement. The 653 partition operating system runs in both the client physical platform and the server physical platform. Both the client physical platform and the server physical platform include multiple 653 application partitions. The RPC core support module is configured in the core operating system (OS), and each partition on the server side provides an RPC service. Based on the partition operating system architecture of the client and the server as shown in Figure 1 the RPC call method provided by the embodiment of the present invention includes:

[0043] Step 1, the RPC service discovery process, including: the client discovery RPC service process and the server registration RPC service process;

[0044] Step 2, the client partition calls the PRC service of the server side by sending an RPC service request, and the server side partition processes the response to the RPC service request.

[0045] It should be noted that the implementation method of the client partition calling the PRC service of the server side in step 2 of the embodiment of the present invention includes: RPC synchronous call processing or RPC asynchronous call processing; during the RPC synchronous call processing, it waits until the service result returned by the server side or the timeout time is received; during the RPC asynchronous call processing, a callback function is registered during the call. When the RPC core support module in the kernel layer receives the service result returned by the server side, a virtual interrupt message is delivered to the client partition to indicate the execution of the callback function to the client partition.

[0046] Figure 2 It is a flow schematic diagram of the RPC service discovery process in the RPC communication method based on ARINC653 partitions provided by an embodiment of the present invention.

[0047] In the embodiment of the present invention, on the one hand, the client discovery RPC service process in step 1 above may include:

[0048] When the RPC core support module of the client is initialized, two tasks are created and run. These two tasks include: the RPC broadcast packet sending task and the RPC broadcast packet receiving task;

[0049] Among them, the RPC broadcast packet sending task is used to obtain the groups of RPC service numbers and port numbers of each server side with which a network connection has been established when the client starts, and save the obtained groups of RPC service numbers and port numbers in the local service information copy;

[0050] The RPC receiving broadcast packet task is used to receive the RPC service port numbers broadcast by the server side that has completed the port mapping service during the operation of the client, and update the local copy of the service information based on the RPC service port numbers received this time.

[0051] In an embodiment of the present invention, on the other hand, the server-side RPC service registration process in step 1 above may include:

[0052] The server-side partition enters the service address mapper in the kernel layer by calling the service registration interface, so that the service address mapper dynamically allocates corresponding port numbers for the RPC service, and saves the RPC service of the server-side partition corresponding to the allocated port numbers in the service address mapping table; the RPC core support module on the server side broadcasts the groups of RPC service numbers and port numbers of the registered RPC services in the network.

[0053] Further, in step 1 of the embodiment of the present invention, the server-side RPC service registration process may further include:

[0054] Update the content in the service address mapping table according to the newly registered RPC service on the server side and the exit of the registered RPC services.

[0055] In an embodiment of the present invention, the synchronous call processing of the client partition in step 2 above may include:

[0056] The client partition sends an RPC service synchronous call request and the timeout time, and keeps waiting for the server side to return the result. If the call return result is received before the timeout time arrives, the client partition normally processes the return result; otherwise, call error handling is performed.

[0057] Figure 3 It is a schematic diagram of the working principle of the asynchronous call request in the RPC communication method based on ARINC653 partition provided by the embodiment of the present invention. In an embodiment of the present invention, the asynchronous call processing of the client partition in step 2 above may include:

[0058] The client partition sends an RPC service asynchronous call request and registers a callback function for processing the returned service result, and continues to process other functional tasks;

[0059] The RPC core support module in the kernel layer of the client creates a daemon process for receiving the service result. The newly created daemon process waits to receive the processing result returned by the server side. When the daemon process receives the return result, it sends a virtual interrupt message to the client partition that sent the request to indicate that the callback function of the client partition processes the return result.

[0060] In an implementation manner of the embodiment of the present invention, during the service discovery process of the above step 1, the server-side partition also calls the server stub in this partition, and the called server stub creates a corresponding RPC server handle; during the registration of the RPC service, an RPC daemon task of the RPC service is also created and started in the kernel layer, and a service daemon process is created in the server-side partition.

[0061] In an implementation manner of the embodiment of the present invention, the response processing of the server-side partition to the RPC service request in the above step 2 may include:

[0062] When the RPC daemon task in the kernel layer of the server side receives an RPC service request, the RPC service request is sent to the server-side partition corresponding to the RPC service request in the form of a virtual interrupt message through the RPC server handle, so that the service daemon process of the server-side partition performs response processing on the RPC service request, and returns the processing result to the client partition that calls the RPC service in the client through the RPC core support module in the kernel layer.

[0063] The embodiment of the present invention provides an RPC communication method based on ARINC653 partition, which provides the ability of remote procedure call for application partitions on a distributed embedded operating system platform adopting a kernel layer partition architecture; the implementation of the present invention mainly includes the following aspects: First, analyze the timing of service enabling, and use the two methods of active discovery combined with passive broadcast to enable the client to perceive all the service information enabled on the network; Second, the client requests calls in both synchronous and asynchronous manners, and the asynchronous situation is implemented by using the virtual interrupt mechanism; Third, the service resides in the partition, and the server receives the request and performs service processing.

[0064] By adopting the technical solution provided by the embodiment of the present invention, the cross-node interoperability ability can be provided to the partition application on the distributed embedded system platform, and the transparent interoperability of global tasks and resources can be realized; in the distributed embedded system, a function call mechanism between nodes in a real-time and deterministic distributed system can be realized for the application partition based on the network, and transparent interoperability between multi-node applications is supported; in addition, by supporting the synchronous / asynchronous mode, the application can flexibly select the call according to the demand scenario and tolerate network latency.

[0065] The following uses some specific implementation examples to schematically illustrate the specific implementation manners of the RPC communication method based on ARINC653 partition provided by the embodiment of the present invention.

[0066] A specific embodiment of the present invention provides an RPC communication method based on ARINC653 partitions, which is implemented using the client / server mode, and provides remote service calls in synchronous and asynchronous modes at the client node and the server node that activate the remote procedure call (RPC) service framework.

[0067] The technical solution of an RPC communication method based on ARINC653 partitions provided by an embodiment of the present invention mainly includes the following processes:

[0068] Process 1, RPC service discovery process, which mainly includes: client discovery of RPC services process and server registration of RPC services process.

[0069] It should be noted that the timing of enabling the RPC service is either before the client starts or after the client starts. As Figure 2 shown, it is a flow diagram of the RPC service discovery process in the RPC communication method based on ARINC653 partitions provided by an embodiment of the present invention.

[0070] In order to enable the client to perceive all services registered in the discovery network domain, the RPC support module of the client creates and runs two tasks during initialization: (1) RPC broadcast packet sending task, to request and obtain the groups of RPC service numbers and port numbers of each server end with which a network connection has been established, and save the obtained RPC service port numbers in the local service information copy; (2) RPC broadcast packet receiving task, as a daemon task for the client to receive server-side broadcast packets, the RPC broadcast packets received by this task contain the groups of RPC service numbers and port numbers of the port mapping services that have been completed. After the RPC broadcast receiving task of the client receives the message, it parses the message to obtain the groups of RPC service numbers and port numbers that have been registered, and updates the local saved service information copy.

[0071] Each server partition of the server side provides a specific RPC service. The server partition calls the server stub in this partition, and creates a corresponding RPC server handle by the called server stub; the server partition also enters the service address mapper in the kernel layer by calling the service registration interface, dynamically allocates a corresponding port number for the RPC service, and saves the correspondence between the RPC service of this server partition and the allocated port number in the service address mapping table; the service registration function of the RPC core support module on the server side is responsible for broadcasting information such as the corresponding PRC service number and port number in the network once the registration of a certain RPC service is completed. Further, update the content in the service address mapping table according to the registration and exit of the RPC service.

[0072] Process 2, synchronous or asynchronous call processing of the client partition

[0073] The synchronous and asynchronous request calls of the client partition are completed through the system call mechanism. The PRC synchronous call waits until the service message is received or the timeout period expires. The PRC asynchronous call returns to the user state to continue executing other tasks after the request is successfully sent.

[0074] like Figure 3 As shown, it is a schematic diagram of the working principle of the asynchronous call request in the RPC communication method based on ARINC653 partition provided in an embodiment of the present invention;

[0075] During the asynchronous call processing, the client application makes an RPC service call. The user needs to register a callback function after receiving the service result. In order to support multiple callback function processing, the message ID is used as the keyword to distinguish. When making an RPC asynchronous call, a daemon process for receiving service results is created for each RPC call. The task that sends the RPC call request returns directly after sending successfully. The newly created daemon process for receiving service results waits for the processing result returned by the server. Once the daemon process receives the message, it finds the partition application that initiated the request and sends a virtual interrupt to the partition. Callback processing in asynchronous mode is supported. After the daemon process receives the message returned by the server, it enters the virtual interrupt handler, deserializes and extracts the request ID and result, searches the RPC callback global table with the request ID as the index, finds the callback function corresponding to the request ID, passes the RPC processing result returned by the server to the callback processing task through the message queue, and performs callback processing.

[0076] Process 3: Server-side partition response request processing

[0077] like Figure 4 As shown, it is a schematic diagram of the processing flow of the client request service and the server partition response request in the RPC communication method based on ARINC653 partitions provided by an embodiment of the present invention. The server has a kernel layer daemon task to receive the RPC call request. After receiving the request packet,

[0078] The partition providing the service is notified through a virtual interrupt. The virtual interrupt handler wakes up the server stub of the user partition, parses the request parameters through a deserialization operation, performs actual service processing, and then serializes the result and encapsulates and sends it to the RPC service of the kernel through a system call.

[0079] The specific service exists in the application partition. The partition server stub actively calls the interface to register the service provided. After successful registration, the service exists in the partition as a daemon process. Once a request is received, the virtual interrupt handler of the partition is responsible for waking up the specific service process. The specific process of receiving and processing the request is as follows:

[0080] (1) The server receives the network data packet from the client in asynchronous IO;

[0081] (2) Parse the data packet, deserialize the byte stream, obtain the program service number, find the partition where the service is located, and deliver a virtual interrupt to the partition, enter the virtual interrupt processing routine of the service partition, and wake up the specific service;

[0082] (3) Different services require different service parameters. The service partition process calls the corresponding deserialization interface to parse the request data packet according to the specific process number of the service, obtains the request parameters required for the service processing, finds the process entry for specific processing, and obtains the return result after the service processing ends;

[0083] (4) The user partition serializes the call result into a network byte stream through a system call, and the server returns the result to the client.

[0084] Reference Figures 1 to 4 As shown, the specific implementation of the RPC communication method based on ARINC653 partition provided in this specific embodiment is as follows:

[0085] 1) The client application makes an RPC call, activating the client stub. The client stub creates a client handle for this RPC call and retrieves the local RPC service port mapping table to obtain the server address (network address + port number) through the RPC call program name, procedure name, and version number when creating the handle.

[0086] 2) Call the service provided by the serialization library to serialize the call parameters, and pass the processed parameter address to the RPC service call interface. The interface falls into a privileged state to call the function in the RPC support library for RPC encapsulation, and transmits the encapsulated message to the server through the Socket standard interface via the network.

[0087] 3) If it is a synchronous RPC call, wait for the server to return the service call result, deserialize the data packet returned by the server, and finally return the result to the application.

[0088] 4) If it is an asynchronous RPC call, the user needs to register a callback function after receiving the service result, execute the RPC call request, and directly return to the user state to continue executing the user code after the request is sent. The core RPC daemon process has been waiting for the network message returned by the request service.

[0089] 5) Once the daemon receives the packet returned by the server, it returns the message ID and service result to the corresponding partition through a virtual interrupt. The partition retrieves the callback function address corresponding to the message ID in the callback mapping table saved in the partition based on the message ID of the returned packet, and processes the result of the user registration.

[0090] 6) Each partition on the server side provides an RPC service. When a user calls the service registration interface to enter the service address mapper in the kernel mode, the port mapping information is saved in the service address mapping table. Once the registration of a certain RPC service is completed, information such as the service number, version number, and port number is broadcast in the network.

[0091] 7) The server side has a kernel daemon task to receive RPC call requests. After receiving a request packet, it notifies the partition providing the service through a virtual interrupt. The virtual interrupt handler wakes up the server stub in the user partition and parses the request parameters through deserialization operations.

[0092] 8) After actual service processing, the result is serialized and then passed through a system call to the RPC service in the kernel for encapsulation and sending.

[0093] Although the disclosed embodiments of the present invention are as above, the content is only an embodiment adopted for the convenience of understanding the present invention and is not used to limit the present invention. Any person skilled in the art within the scope of the present invention can make any modifications and changes in the form and details of the implementation without departing from the spirit and scope disclosed by the present invention. However, the scope of patent protection of the present invention shall still be subject to the scope defined by the appended claims.

Claims

1. An RPC communication method based on ARINC653 partitions, characterized in that, The 653 partition operating system runs on both the client physical platform and the server physical platform. Both the client physical platform and the server physical platform include multiple 653 application partitions. The RPC core support module is configured in the core operating system, and each partition on the server side provides an RPC service; The specific steps of the RPC communication method include: Step 1, the RPC service discovery process, including: the client discovery RPC service process and the server registration RPC service process; Step 2, the client partition invokes the RPC service on the server side by sending an RPC service request, and the server side partition processes the response to the RPC service request; Among them, the client partition invokes the RPC service on the server side, including: RPC synchronous call processing or RPC asynchronous call processing; during the RPC synchronous call processing, it waits until it receives the service result returned by the server side or the timeout; during the RPC asynchronous call processing, a callback function is registered during the call. When the RPC core support module in the kernel layer receives the service result returned by the server side, it delivers a virtual interrupt message to the client partition to indicate the execution of the callback function to the client partition.

2. The RPC communication method based on ARINC653 partitions according to claim 1, characterized in that, The client discovery RPC service process in the said Step 1 includes: The RPC core support module of the client creates and runs two tasks during initialization, including: the RPC send broadcast packet task and the RPC receive broadcast packet task; Among them, the RPC send broadcast packet task is used to obtain the groups of RPC service numbers and port numbers of each server side with an established network connection when the client starts, and save the obtained groups of RPC service numbers and port numbers in the local service information copy; The RPC receive broadcast packet task is used to receive the RPC service port numbers broadcast by the server side that has completed the port mapping service during the operation of the client, and update the local saved service information copy according to the RPC service port numbers received this time.

3. The RPC communication method based on ARINC653 partitions according to claim 1, characterized in that, The server registration RPC service process in the said Step 1 includes: The server side partition enters the service address mapper in the kernel layer by calling the service registration interface, so that the service address mapper dynamically assigns corresponding port numbers to the RPC service, and saves the RPC service of the server side partition corresponding to the assigned port numbers in the service address mapping table; the RPC core support module of the server side broadcasts the groups of RPC service numbers and port numbers that have completed the registration of the RPC service in the network.

4. The RPC communication method based on ARINC653 partitions according to claim 3, characterized in that, The server registration RPC service process in the said Step 1 also includes: Updating the content in the service address mapping table according to the newly registered RPC service on the server side and the exit of the registered RPC service.

5. The RPC communication method based on ARINC653 partitions according to any one of claims 1 to 4, characterized in that, The synchronous call processing of the client partition in the said Step 2 includes: The client partition sends an RPC service synchronous call request and sends the timeout. It waits all the time for the server side to return the result. If it receives the call return result before the timeout arrives, the client partition normally processes the return result; otherwise, it performs call error processing.

6. The RPC communication method based on ARINC653 partitions according to any one of claims 1 to 4, characterized in that, The asynchronous call processing of the client partition in the said Step 2 includes: The client partition sends an asynchronous call request for the RPC service, registers a callback function for processing the returned service result, and continues to process other functional tasks; In the RPC core support module in the kernel layer of the client, a daemon process for receiving the service result is created. The newly created daemon process waits to receive the processing result returned by the server. When the daemon process receives the returned result, it sends a virtual interrupt message to the client partition that sent the request to indicate that the callback function of the client partition processes the returned result.

7. The RPC communication method based on ARINC653 partitions according to any one of claims 1 to 4, characterized in that, During the service discovery process in Step 1, the server partition also calls the server stub in this partition, and the called server stub creates a corresponding RPC server handle; during the RPC service registration process, an RPC daemon task for this RPC service is also created and started in the kernel layer, and a service daemon process is created in the server partition.

8. The RPC communication method based on ARINC653 partitions according to claim 7, characterized in that, The response processing of the server partition to the RPC service request in Step 2 includes: When the RPC daemon task in the kernel layer of the server receives an RPC service request, it sends the RPC service request in the form of a virtual interrupt message to the server partition corresponding to the RPC service request through the RPC server handle, so that the service daemon process of the server partition responds to the RPC service request and returns the processing result to the corresponding client partition that calls the RPC service in the client through the RPC core support module in the kernel layer.

Images