System and method for remote procedure call (RPC) based on MHAL / MOCB
By using a Remote Procedure Call (RPC) system based on MHAL/MOCB, the communication problem of CORBA middleware in heterogeneous processing environments is solved, realizing efficient, cross-platform software radio system communication, which is suitable for various bus protocol environments.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINESE AERONAUTICAL RADIO ELECTRONICS RES INST
- Filing Date
- 2025-12-19
- Publication Date
- 2026-05-01
AI Technical Summary
Existing CORBA middleware has complex communication protocols and is difficult to develop and debug in heterogeneous processing environments with multiple bus protocols, and cannot meet the communication requirements of software radio systems. Traditional RPC relies on Ethernet TCP/IP protocol and cannot be directly applied to heterogeneous processing environments with multiple bus protocols.
A remote procedure call (RPC) system based on MHAL/MOCB is adopted. It communicates on the SRIO bus through the hardware abstraction layer MHAL/MOCB, providing lightweight remote procedure calls without IDL and realizing communication between nodes.
It achieves efficient communication in heterogeneous processing environments with multiple bus protocols, supports remote method calls from different development tools and languages, and has a communication speed higher than the traditional TCP/IP protocol.
Smart Images

Figure CN121967502A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of embedded software radio technology, and more specifically to a system and method for Remote Procedure Call (RPC) based on MHAL / MOCB. Background Technology
[0002] Software-defined radio (SDR) systems combine general-purpose processing hardware and software to enable reconfigurability. This allows SDR systems to reconfigure device functions using different software configurations. The same hardware can perform different functions by loading and running different software. This change has greatly promoted the development of the traditional SDR communication industry towards software-based, intelligent, universal, and miniaturized features.
[0003] The SCA platform software architecture comprises a core framework, middleware, and a hardware abstraction layer. The core framework defines standardized interfaces to constrain system components (devices and services) and waveform components, thereby providing standardized waveform and device management capabilities. The middleware provides an information transmission mechanism for distributed heterogeneous processing environments, enabling distributed cross-platform processing through standard client / server operations. The hardware abstraction layer, based on various bus protocols, defines unified data read / write and control interfaces, shielding underlying differences and enabling interconnection between heterogeneous waveform components. This includes MHAL (Hardware Abstraction Layer) and MOCB (On-Chip Hardware Abstraction Layer).
[0004] Traditional software-defined radio (SDR) systems use CORBA (Common Object Request Broker Architecture) as middleware to achieve communication between distributed systems. However, in current distributed radio systems, CORBA middleware suffers from drawbacks such as protocol complexity, the need for IDL (Independent Language Definition Language), difficulties in development, debugging, and porting, reliance on Ethernet TCP / IP, and poor compatibility with domestic operating systems. These limitations prevent it from meeting the communication needs of SDR systems in heterogeneous environments with multiple bus protocols. While replacing CORBA with RPC (Remote Procedure Call) can simplify the protocol to some extent, traditional RPC also relies on Ethernet TCP / IP and cannot be directly applied to SDR environments with heterogeneous bus protocols. Therefore, how to implement a lightweight, IDL-free RPC middleware in distributed heterogeneous environments under various bus protocols has become a pressing problem in this field. Summary of the Invention
[0005] To address the aforementioned shortcomings in the prior art, this invention provides a system and method for Remote Procedure Call (RPC) based on MHAL / MOCB.
[0006] To achieve the aforementioned objectives, the present invention, according to a first aspect, proposes a system based on MHAL / MOCB Remote Procedure Call (RPC) for use in a core framework of an SCA platform software architecture including a server and a client; the core framework client establishes a connection with the core framework server via an MHAL / MOCB-based RPC middleware.
[0007] To meet the needs of high-speed data transmission, nodes in current distributed software radio systems typically use the Hardware Abstraction Layer (MHAL / MOCB) protocol to communicate on the SRIO bus, instead of the traditional Ethernet-based TCP / IP communication protocol.
[0008] Traditional communication middleware cannot communicate in the aforementioned hardware and software environment. Therefore, this invention provides a system architecture for Remote Procedure Call (RPC) based on MHAL / MOCB, applicable to remote procedure call communication needs between nodes in a software-defined radio system.
[0009] In one possible embodiment, the RPC middleware includes a client stub and a server stub, residing on different nodes. The client stub serializes the parameters of a method call into a hardware abstraction layer message. The server stub restores the received hardware abstraction layer message back into the method call parameters, executes the local method call, obtains the return value, and returns the return value to the client stub. The client stub and the server stub communicate via MHAL / MOCB. The client stub and the server stub encapsulate the MHAL / MOCB communication method, providing a unified RPC interface call for the core framework.
[0010] According to a second aspect of the present invention, a method for Remote Procedure Call (RPC) based on MHAL / MOCB is proposed, employing the aforementioned system for Remote Procedure Call (RPC) based on MHAL / MOCB, comprising the following steps: The core framework client calls the RPC interface. The RPC client stub serializes the method call parameters into a Hardware Abstraction Layer (HAL) message and sends it to the server stub via MHAL / MOCB. The server stub restores the received HAL message back into the method call parameters, executes the method call on the local core framework server, obtains the return value, serializes the return value into a HAL message, and sends it to the client stub via MHAL / MOCB. The client stub then restores the received HAL message back into the method call return value and returns it to the core framework client, completing a remote procedure call.
[0011] In one possible embodiment, the specific process of serializing the parameters / return values of a method call into a hardware abstraction layer message includes: Establish a list of interface function definitions for method calls. Each function definition in the list is in the form of ret func(param1, param2, ..., paramN), where the method name is func, the return value is ret, and the parameters are param1~N. The corresponding method ID, funcID, is determined. Define the number and attributes of the parameters. The attributes of the parameters include parameter number, data type, data size, input / output type, and data content. Define the properties of the return value, including data type, data size, and data content; Determine the hardware abstraction layer message frame format; The method call's method number, parameters, and return value are encapsulated into a Hardware Abstraction Layer (HAL) message according to the HAL message frame format.
[0012] In one possible embodiment, the specific process of restoring the received hardware abstraction layer message into method call parameters / return values includes: Based on the hardware abstraction layer message frame format, extract the method number, parameters, and return value of the method call; Based on the method number of the method call, search the list of interface function definitions to determine the corresponding interface function definition; Based on the corresponding interface function definition, determine the parameters and return value of the method call.
[0013] According to a third aspect of the present invention, a communication device is provided, comprising: a processor and a memory, the memory storing computer execution instructions; the processor executing the computer execution commands stored in the memory, causing the communication device to perform the method as described above.
[0014] According to a fourth aspect of the present invention, a computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described above.
[0015] According to a fifth aspect of the present invention, a computer program product includes a computer program that, when run, causes a computer to perform the method described above.
[0016] Advantages and beneficial effects of the present invention: The remote method access involved in this invention is independent of specific applications. As long as a development language and development tools can be used to develop applications based on MHAL / MOCB, remote method invocation can be implemented. The server and client can be implemented using different development tools and languages respectively.
[0017] The system employing the MHAL / MOCB-based Remote Procedure Call (RPC) of this invention allows the server and client nodes to communicate on the SRIO bus using the Hardware Abstraction Layer (MHAL / MOCB) protocol, resulting in a communication speed higher than that of traditional TCP / IP-based Ethernet.
[0018] The Remote Procedure Call (RPC) method proposed in this invention is compatible with various bus protocols such as MHAL / MOCB and TCP / IP, and is suitable for software radio systems in heterogeneous processing environments with multiple bus protocols. Attached Figure Description
[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. The drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0020] Figure 1 This is a diagram of the RPC architecture based on MHAL / MOCB in an embodiment of the present invention; Figure 2 This is a flowchart illustrating the parameter serialization process in an embodiment of the present invention. Figure 3 This is a flowchart illustrating the parameter restoration process in an embodiment of the present invention. Figure 4 This is a parameter attribute diagram of parameter serialization in an embodiment of the present invention; Figure 5 This is a diagram of the RPC data frame format in an embodiment of the present invention. Detailed Implementation
[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0022] The features and illustrative embodiments of various aspects of the present invention will now be described in detail. Numerous specific details are set forth in the following detailed description to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention may be practiced without requiring some of these specific details. The following description of embodiments is merely intended to provide a better understanding of the invention by illustrating examples of the invention. The invention is by no means limited to any specific setups and methods set forth below, but covers any improvements, substitutions, and modifications to structures, methods, and devices without departing from the spirit of the invention. Well-known structures and techniques are not shown in the drawings and the following description to avoid unnecessarily obscuring the invention.
[0023] In the description of this invention, it should be noted that the directions or positional relationships indicated by terms such as "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer" are based on the directions or positional relationships shown in the accompanying drawings and are only for the convenience of describing and simplifying the invention, and should not be construed as limiting the invention. Furthermore, the use of ordinal numbers (e.g., "first and second," etc.) is for distinguishing objects and is not limited to this order, and should not be construed as indicating or implying relative importance.
[0024] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly, encompassing both direct connection and indirect connection via an intermediate medium. Those skilled in the art can understand the specific meaning of these terms in this invention based on the specific circumstances.
[0025] It should be noted that, unless otherwise specified, the embodiments of the present invention and the features thereof can be combined with each other, and the various embodiments can be referenced and cited in each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.
[0026] The present invention will be further described in detail below with reference to the embodiments and accompanying drawings, but the embodiments of the present invention are not limited thereto.
[0027] Example 1 A system based on MHAL / MOCB Remote Procedure Call (RPC) is provided for the core framework of an SCA platform software architecture that includes a server and a client. The core framework client establishes a connection with the core framework server through an RPC middleware based on MHAL / MOCB.
[0028] The RPC system architecture shown in this invention is as follows: Figure 1As shown, the system consists of client nodes and server nodes, which are connected in hardware via a SIRO bus. The client stub of the RPC middleware resides on the client node of the system, and the server stub of the RPC middleware resides on the server node of the system. The client stub and the server stub communicate through the Hardware Abstraction Layer (MHAL / MOCB) during the system's send and receive processes.
[0029] The client node's user process invokes a local client stub. The client stub serializes the method call parameters into a Hardware Abstraction Layer (HAL) message and sends it to the HAL in the RPC sending process, while the client user process suspends. The HAL sends the message to the server node via the SRIO bus. The server node's RPC receiving process parses the HAL message and invokes the corresponding server stub to restore the parameters. The server stub passes the parameters to the worker process, which then calls the actual service method. The service method executes and returns a value to the server stub. The server stub serializes the return value into a HAL message and sends it back to the client via the SRIO bus. The client stub receives the message, restores the returned value, and returns it to the client user process. The client user process receives the return value, exits suspension, and resumes execution.
[0030] Example 2 A method for Remote Procedure Call (RPC) based on MHAL / MOCB, employing the aforementioned system for RPC based on MHAL / MOCB, includes the following procedures: The core framework client calls the RPC interface, and the RPC client stub is stored according to... Figure 2 The process shown serializes the method call parameters into Hardware Abstraction Layer (HAL) messages, which are then sent to the server stub via MHAL / MOCB. The server stub processes the received HAL messages according to... Figure 3 The process shown is restored to the method call parameters, the method call on the local core framework server is executed and the return value is obtained, and the return value is serialized into a hardware abstraction layer message and sent to the client stub via MHAL / MOCB. The client stub then restores the received hardware abstraction layer message into the return value of the method call and returns it to the core framework client, thus completing a remote procedure call.
[0031] In this embodiment, the specific process of serializing the parameters / return values of a method call into a hardware abstraction layer message includes: Create a list of interface functions for method calls. Each function in the list is defined in the form ret func(param1, param2, ..., paramN), where the method name is func, the return value is ret, and the parameters are param1~N. The corresponding method ID, funcID, is determined. Define the number and attributes of the parameters. Parameter attributes are as follows: Figure 4 As shown, this includes parameter number, data type, data size, input / output type, and data content. The parameter number indicates the parameter's position in the method call; param1 has parameter number 1, param2 has parameter number 2, and so on. The data type `type` is defined by the developer, and the data size `size` represents the number of bytes in the data content. There are three input / output types: input parameter `in`, output parameter `out`, and input / output parameter `inout`. The data content `data` is stored using an 8-bit byte array. Define the properties of the return value. The properties of the return value are as follows: Figure 4 As shown, the return value's attributes include parameter number, data type, data size, input / output type, and data content. The return value has a parameter number of 0, the data type (type) is defined by the developer, the data size (size) represents the number of bytes in the data content, the input / output type is output type (out), and the data content (data) is stored using an 8-bit byte array. The hardware abstraction layer message frame format is Figure 5 The RPC data frame format shown is as follows; The method call is encapsulated in a Hardware Abstraction Layer (HAL) message frame. The source address byte field contains the address of the node sending the data frame, the destination address byte field contains the address of the node receiving the data frame, and the method number byte field contains the method number (funcID) determined in step 2. If this method call is initiated by the client, the return identifier byte field is filled with 0; otherwise, it is filled with 1. If the core framework client does not require a return value for this method call, the bidirectional identifier byte field is filled with 0; otherwise, it is filled with 1. If this method call is initiated by the client, the total number of parameters byte field contains the total number of in and inout type parameters, and the parameter packet byte field contains the in and inout type parameters. If this method call is initiated by the server, the total number of parameters byte field contains the total number of out and inout type parameters / return values, and the parameter packet byte field contains the out and inout type parameters / return values.
[0032] In this embodiment, the specific process of restoring the received hardware abstraction layer message into method call parameters / return values includes: according to Figure 5 The RPC data frame format shown is used to extract the return identifier, method number, and parameter / return value attributes of the method call. Based on the method number of the method call, search the list of interface function definitions to determine the corresponding interface function definition; Based on the parameter number and input / output type of the extracted parameter / return value attributes, and combined with the return identifier, the matching parameter / return value is determined by searching in the corresponding interface function definition.
[0033] The above detailed embodiments are a description of the present invention. It should not be considered that the specific embodiments of the present invention are limited to these descriptions. For those skilled in the art, several simple deductions and substitutions can be made without departing from the concept of the present invention, and all of these should be considered to fall within the protection scope of the present invention.
Claims
1. A system for Remote Procedure Call (RPC) based on MHAL / MOCB, characterized in that, The core framework of the SCA platform software architecture includes both server and client sides; the core framework client establishes a connection with the core framework server through RPC middleware based on MHAL / MOCB remote procedure calls.
2. The system for Remote Procedure Call (RPC) based on MHAL / MOCB according to claim 1, characterized in that, The RPC middleware includes a client stub and a server stub, which reside on different nodes. The client stub serializes the parameters of the method call into a Hardware Abstraction Layer (HAL) message. The server stub restores the received HAL message into the method call parameters, executes the local method call, obtains the return value, and returns the return value to the client stub. The client stub and the server stub communicate via MHAL / MOCB. The client stub and the server stub encapsulate the MHAL / MOCB communication method, providing a unified RPC interface call for the core framework.
3. A method for Remote Procedure Call (RPC) based on MHAL / MOCB, characterized in that, A system employing any one of claims 1-2, based on MHAL / MOCB, for Remote Procedure Call (RPC) includes the following process: The core framework client calls the RPC interface. The RPC client stub serializes the method call parameters into a Hardware Abstraction Layer (HAL) message and sends it to the server stub via MHAL / MOCB. The server stub restores the received HAL message back into the method call parameters, executes the method call on the local core framework server, obtains the return value, serializes the return value into a HAL message, and sends it to the client stub via MHAL / MOCB. The client stub then restores the received HAL message back into the method call return value and returns it to the core framework client, completing a remote procedure call.
4. The method for Remote Procedure Call (RPC) based on MHAL / MOCB according to claim 3, characterized in that, The specific process of serializing method call parameters / return values into hardware abstraction layer messages includes: Establish a list of interface function definitions for method calls. Each function definition in the list is in the form of ret func(param1, param2, ..., paramN), where the method name is func, the return value is ret, and the parameters are param1~N. The corresponding method ID, funcID, is determined. Define the number and attributes of the parameters. The attributes of the parameters include parameter number, data type, data size, input / output type, and data content. Define the properties of the return value, including data type, data size, and data content; Determine the hardware abstraction layer message frame format; The method call's method number, parameters, and return value are encapsulated into a Hardware Abstraction Layer (HAL) message according to the HAL message frame format.
5. A method for Remote Procedure Call (RPC) based on MHAL / MOCB according to claim 3, characterized in that, The specific process of restoring the received hardware abstraction layer messages into method call parameters / return values includes: Based on the hardware abstraction layer message frame format, extract the method number, parameters, and return value of the method call; Based on the method number of the method call, search the list of interface function definitions to determine the corresponding interface function definition; Based on the corresponding interface function definition, determine the parameters and return value of the method call.
6. A communication device, characterized in that, include: A processor and a memory, the memory storing computer-executable instructions; the processor executing the computer-executable commands stored in the memory, causing the communication device to perform the method as described in any one of claims 3-5.
7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 3-5.
8. A computer program product, characterized in that, Includes a computer program that, when run, causes a computer to perform the method as described in any one of claims 3-5.