A method, system and vehicle for communicating services of modules in a vehicle terminal

Abstract

The present application relates to the field of vehicle technology, and in particular to a method, system and vehicle for communication between services of various modules in an on-board terminal. The method for communication between services of various modules in an on-board terminal comprises the following steps: defining a data structure description file according to Capnp; compiling the data structure description file into a target programming language file through a Capnp compiler; obtaining a data source, and calling the serialization interface of Capnp to encode the data to be published; calling the sending interface of ZMQ to publish data; the data subscriber receives the data of the publisher, and calls the deserialization interface of Capnp to decode the published data; obtaining the structure data defined by the publisher, and performing different applications on the data. The method supports a 1:n relationship between one publisher and multiple subscribers, and Canpn directly supports the construction of RPC interfaces, without the need for additional components for RPC interface construction.

Description

Technical Field

[0001] The present application relates to the field of vehicle technology, and in particular to a method, system and vehicle for communicating services among modules in a vehicle-mounted terminal. Background Art

[0002] With the development of intelligent vehicles, vehicle information services are increasing. Therefore, the communication requirements of various on-board modules in the vehicle are growing, and the communication range is getting wider and wider. A vehicle terminal involves multiple processors and controllers, each processor or controller often has multiple sensor modules, and the main processor also involves multiple services (processes). It is quite complicated to handle the data communication and overall business logic between them.

[0003] A distributed vehicle terminal service communication method that meets this requirement is particularly important. The communication between multiple modules in the vehicle terminal is mainly based on USB network cards and WIFI. ZeroMQ is a network middleware suitable for this requirement with good scalability. Each task is handled by a node (a node is a thread), two nodes on the same machine (a node is a process), and two machines on the same network (a node is a machine) without changing the application. The request response (REQ / REP) and publish-subscribe (PUB / SUB) models provided meet the message communication needs of various modules inside the vehicle.

[0004] However, ZeroMQ only provides a message communication model, and the message processing module also involves data serialization. The biggest disadvantage of the currently widely used cross-language data serialization formats such as json and xml is performance issues, and there is no data type information. At the same time, the data serialization redundancy is large, which is not suitable for embedded systems. Supporting data encoding compression and providing IDL (Interface Description language) to describe data schema, which is used to define the serialization of structured or unstructured data, is suitable for embedded system scenarios. Among them, Google's Protobuf is a widely used protocol. It is a language-independent, platform-independent, and extensible method for serializing structured data. It can be used for (data) communication protocols, data storage, etc. In addition to data publishing / subscription, the communication between modules in the distributed vehicle terminal system also involves remote procedure calls (RPC), but Protobuf does not provide a related rpc framework, which is not very convenient to use. Summary of the invention

[0005] In view of the above problems, the present application provides a method for communication between modules in a vehicle terminal to solve the technical problem that the existing method for communication between modules in a vehicle terminal cannot take into account both data subscription and RPC interface. The specific technical solution is as follows:

[0006] A service communication method for each module in a vehicle terminal, comprising the steps of:

[0007] Define the data structure description file according to Capnp;

[0008] Compile the data structure description file into a target programming language file by using a Capnp compiler;

[0009] Get the data source and call Capnp's serialization interface to encode the data to be published;

[0010] Call ZMQ's sending interface to publish data;

[0011] The data subscriber receives the data from the publisher and calls the Capnp deserialization interface to decode the published data;

[0012] Obtain the structured data defined by the publisher and perform different application processing on the data.

[0013] Furthermore, before the step of “obtaining the data source”, the following steps are specifically included:

[0014] The data publisher creates a socket in zmq publishing mode and binds it to a specific port.

[0015] Furthermore, the “data subscriber receives the data from the publisher and calls the deserialization interface of Capnp to decode the published data” specifically includes the following steps:

[0016] The data subscriber creates a socket in ZMQ subscription mode and connects to the publisher's IP address and the specific port;

[0017] The data subscriber continuously receives the data from the publisher and calls the Capnp deserialization interface to decode the published data.

[0018] Furthermore, the target programming language file is a C++ file.

[0019] Furthermore, the RPC interface is constructed based on Capnp;

[0020] The RPC interface construction includes the following steps:

[0021] Define the RPC interface and related data structure description files according to Capnp's IDL schema specific description;

[0022] Compile the data structure description file into a C++ file using a Capnp compiler;

[0023] The server calls capnp::EzRpcServer to establish an RPC server and bind it to the port specified by the user;

[0024] The server continues to run, waiting to accept client connections and process related requests;

[0025] The client calls capnp::EzRpcClient to establish an RPC client and establish a connection with the server's specified port;

[0026] The client calls the RPC interface request and waits for the server's response;

[0027] The server receives the RPC interface request, processes it and sends the result back to the client;

[0028] The client receives the response from the server and performs corresponding processing.

[0029] In order to solve the above technical problems, a service communication system for each module in a vehicle terminal is also provided. The specific technical solution is as follows:

[0030] A service communication system for each module in a vehicle terminal, comprising: a target file generation module, a data publishing module and a data subscription module;

[0031] The target file generation module is used to: define a data structure description file according to Capnp; compile the data structure description file into a target programming language file through a Capnp compiler;

[0032] The data publishing module is used to: obtain the data source, and call the serialization interface of Capnp to encode the data to be published; call the sending interface of ZMQ to publish the data;

[0033] The data subscription module is used for: the data subscriber receives the data from the publisher and calls the deserialization interface of Capnp to decode the published data; obtains the structure data defined by the publisher and performs different application processing on the data.

[0034] Furthermore, the data publishing module is also used for: the data publisher creates a socket in zmq publishing mode and binds it to a specific port.

[0035] Furthermore, the data subscription module is also used for: the data subscriber creates a socket in ZMQ subscription mode and connects to the IP address of the publisher and the specific port;

[0036] The data subscriber continuously receives the data from the publisher and calls the Capnp deserialization interface to decode the published data.

[0037] Furthermore, it also includes: an RPC interface construction module, the RPC interface construction module includes: a server and a client;

[0038] The target file generation module is used to: define the RPC interface and related data structure description files according to the specific description of Capnp's IDL schema; compile the data structure description files into C++ files through the Capnp compiler;

[0039] The server is used to: call capnp::EzRpcServer to establish an RPC server and bind it to the port specified by the user; the server continues to run, waiting to accept client connections and process related requests;

[0040] The client is used to: call capnp::EzRpcClient to establish an RPC client and establish a connection with a designated port of the server; the client calls an RPC interface request and waits for a response from the server;

[0041] The server is also used to: receive the RPC interface request, process it and reply the result to the client;

[0042] The client is also used to: receive a response from the server and perform corresponding processing.

[0043] In order to solve the above technical problems, a vehicle is also provided, and the specific technical solution is as follows:

[0044] A vehicle includes the above-mentioned service communication system for each module in the vehicle-mounted terminal.

[0045] The beneficial effect of the present invention is: a service communication method for each module in a vehicle terminal, including the steps of: defining a data structure description file according to Capnp; compiling the data structure description file into a target programming language file through a Capnp compiler; obtaining the data source, and calling the serialization interface of Capnp to encode the data to be published; calling the sending interface of ZMQ to publish the data; the data subscriber receives the data of the publisher, and calls the deserialization interface of Capnp to decode the published data; obtaining the structure data defined by the publisher, and performing different applications on the data. The method supports a 1:n relationship between a publisher and multiple subscribers, and is applied to occasions where multiple distributed applications require the same data, and can flexibly manage and control distributed data. Canpn directly supports the construction of RPC interfaces, and does not require other components to construct RPC interfaces, making system development easier. The interface definition (IDL) is used to describe data types and methods, and complex data can be flexibly and conveniently analyzed and processed. Application developers do not need to know the implementation details behind the interface, which is convenient for the development of the application layer. The distributed communication technology based on publishing and subscription facilitates the expansion of services without affecting the original services.

[0046] The above-mentioned records related to the invention content are only an overview of the technical solution of the present application. In order to enable ordinary technicians in the field to more clearly understand the technical solution of the present application, and then implement it according to the text of the specification and the contents recorded in the drawings, and to make the above-mentioned purpose and other purposes, features and advantages of the present application easier to understand, the following is an explanation in combination with the specific implementation mode and drawings of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] The drawings are only used to illustrate the principles, implementation methods, applications, characteristics and effects of the specific embodiments of the present application and other related contents, and shall not be considered as limitations of the present application.

[0048] In the drawings of the specification:

[0049] Figure 1 A process of a service communication method for each module in a vehicle terminal described in a specific implementation method Figure 1 ;

[0050] Figure 2 Schematic diagram of a service communication method for each module in a vehicle terminal according to a specific implementation method Figure 1 ;

[0051] Figure 3 It is a schematic diagram comparing the Cannp RPC described in the specific implementation method with the traditional RPC;

[0052] Figure 4 A process of a service communication method for each module in a vehicle terminal described in a specific implementation method Figure 2 ;

[0053] Figure 5 Schematic diagram of a service communication method for each module in a vehicle terminal according to a specific implementation method Figure 2 ;

[0054] Figure 6 A schematic diagram of modules of a service communication system of each module in a vehicle-mounted terminal according to a specific implementation method;

[0055] Figure 7 A schematic diagram of a module of a vehicle described in a specific implementation manner;

[0056] Figure 8 It is a schematic diagram of a module in a vehicle according to a specific implementation method.

[0057] The reference numerals in the above drawings are described as follows:

[0058] 600. A service communication system for each module in a vehicle terminal,

[0059] 601. Target file generation module,

[0060] 602. Data publishing module,

[0061] 603. Data subscription module,

[0062] 700. A vehicle. DETAILED DESCRIPTION

[0063] In order to explain in detail the possible application scenarios, technical principles, specific schemes that can be implemented, and the purposes and effects that can be achieved, the following is a detailed description of the specific embodiments listed in conjunction with the accompanying drawings. The embodiments described herein are only used to more clearly illustrate the technical solutions of the present application, and are therefore only used as examples, and cannot be used to limit the scope of protection of the present application.

[0064] Reference to "embodiment" herein means that the specific features, structures or characteristics described in conjunction with the embodiment may be included in at least one embodiment of the present application. The term "embodiment" appearing in various places in the specification does not necessarily refer to the same embodiment, nor does it particularly limit its independence or association with other embodiments. In principle, in the present application, as long as there is no technical contradiction or conflict, the various technical features mentioned in the embodiments can be combined in any way to form a corresponding implementable technical solution.

[0065] Unless otherwise defined, the technical terms used in this document have the same meanings as those generally understood by those skilled in the art to which this application belongs; the use of relevant terms in this document is only for describing specific embodiments and is not intended to limit this application.

[0066] In the description of this application, the term "and / or" is an expression used to describe the logical relationship between objects, indicating that three relationships may exist, for example, A and / or B, which means: A exists, B exists, and A and B exist at the same time. In addition, the character " / " in this article generally indicates that the objects before and after are in an "or" logical relationship.

[0067] In the present application, terms such as “first” and “second” are merely used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship of quantity, priority or sequence between these entities or operations.

[0068] Without further limitations, in this application, the words "include", "comprises", "has" or other similar expressions used in the sentences are intended to cover non-exclusive inclusion. These expressions do not exclude the presence of additional elements in the process, method or product including the elements, so that the process, method or product including a series of elements may include not only those limited elements, but also other elements not explicitly listed, or also include elements inherent to such process, method or product.

[0069] Similar to the understanding in the Examination Guidelines, in this application, expressions such as "greater than", "less than", "exceed" and the like are understood to exclude the number itself; expressions such as "above", "below", "within" and the like are understood to include the number itself. In addition, in the description of the embodiments of this application, "multiple" means more than two (including two), and similar expressions related to "multiple" are also understood in this way, such as "multiple groups", "multiple times", etc., unless otherwise clearly and specifically limited.

[0070] The core technical idea of ​​this embodiment is to realize the service communication method of each module in the vehicle terminal by cooperating with Capnp and ZMQ. In this embodiment, Capnp refers to Capnproto. Capnproto is a very fast data exchange format and function-based RPC system. Compared with JSON, it provides binary data serialization, and compared with Protobuf, it provides faster data encoding and decoding speed; it can not only be used for data serialization encoding during ZMQ data publishing / subscription, but also can implement RPC interface and corresponding operations through Capnproto's specific Schema language. Such a terminal system will not become complicated due to the existence of multiple IDL data descriptions.

[0071] The following combination Figures 1 to 5 A method for communicating services among modules in a vehicle-mounted terminal is described, and the method for communicating services among modules in a vehicle-mounted terminal can be applied to a vehicle. Figure 8As shown, in a vehicle, the wireless processor can serve as a sensor data publisher, and each service module in the main processor serves as a data subscriber, or the main controller serves as a sensor data publisher, and each service module in the main processor serves as a data subscriber.

[0072] like Figure 1 As shown, the specific steps of constructing the service communication method of each service module in the vehicle terminal based on ZMQ publish-subscribe and Capnp protocol include:

[0073] Step S101: Define a data structure description file according to Capnp. In this embodiment, the data structure description file is defined according to the IDL schema specific description of Capnp. Figure 2 As shown, it can be: gnss_data_publish.capnp.

[0074] Step S102: Compile the data structure description file into a target programming language file through the Capnp compiler. In this embodiment, the target programming language file is a C++ file, that is, compiled into a C++ object for use by the Capnp compiler, and outputted as gnss_data_publish.c++ and gnss_data_publish.hpp.

[0075] The following describes data publishing from step S103 and step S104:

[0076] Step S103: Get the data source, and call the Capnp serialization interface to encode the data to be published. Before step S103, the data publisher also includes the following steps: Create a socket in zmq publishing mode and bind it to a specific port.

[0077] Step S104: Call the ZMQ sending interface to publish data.

[0078] The following describes data subscription from step S105 and step S106:

[0079] Step S105: The data subscriber receives the data from the publisher and calls the deserialization interface of Capnp to decode the published data. It specifically includes the following steps: the data subscriber creates a socket in ZMQ subscription mode and connects to the IP address and the specific port of the publisher; the data subscriber continuously receives the data from the publisher and calls the deserialization interface of Capnp to decode the published data. It should be noted that for the data publisher, when there is data published, it will repeat steps S103 and S104. When there is data published, the data subscriber will receive it.

[0080] Just like Figure 8As shown, the fuel-saving system service module subscribes to the data release of the main controller, so when the main controller releases data, the fuel-saving system service module will receive it.

[0081] Step S106: Obtain the structure data defined by the publisher and perform different application processing on the data. Figure 8 As shown, the fuel saving system service obtains the current fuel remaining status of the vehicle sent by the main controller, analyzes the fuel usage, and makes corresponding prompts and adjustments.

[0082] The flowchart of the above steps S101 to S106 is as follows: Figure 2 shown.

[0083] The above method supports a 1:n relationship between one publisher and multiple subscribers. It is applied to situations where multiple distributed applications require the same data. It can flexibly manage and control distributed data. Canpn directly supports the construction of RPC interfaces, and no additional components are required for RPC interface construction, making system development easier. It uses interface definition (IDL) to describe data types and methods, and flexibly and conveniently analyzes and processes complex data. Application developers do not need to know the implementation details behind the interface, which facilitates the development of the application layer. Distributed communication technology based on publishing and subscription facilitates business expansion without affecting the original business.

[0084] As mentioned above, Canpn directly supports RPC interface construction, such as Figure 3 As shown in the figure, Capnp RPC is compared with traditional RPC: In the Capnproto framework, a different approach can be taken. Capnproto's RPC adopts a method similar to Promise, which streamlines all interface operations. Intermediate results do not need to be sent back to the client first, but only need to wait for the final result to be returned. Therefore, this reduces the round-trip transmission of intermediate results and reduces call latency.

[0085] The following is combined Figure 4 and Figure 5 The method of constructing an RPC interface based on Capnp is described, which includes the following steps:

[0086] Step S401: Define the RPC interface and related data structure description files according to the Capnp IDL schema specific description. Figure 4 As shown, it can be: nad_system_rpc_service.capnp.

[0087] Step S402: Compile the data structure description file into a C++ file using a Capnp compiler, such as outputting nad_system_rpc_service.c++ and nad_system_rpc_service.hpp.

[0088] The following steps S403, S404 and S407 are actions performed by the server, and steps S405, S406 and S408 are actions performed by the client. The flowchart is shown in FIG. Figure 5 shown.

[0089] Step S403: The server calls capnp::EzRpcServer to establish an RPC server and bind it to the port specified by the user.

[0090] Step S404: The server continues to run, waiting to accept client connections and process related requests.

[0091] Step S405: The client calls capnp::EzRpcClient to establish an RPC client and establish a connection with the designated port of the server.

[0092] Step S406: The client calls the RPC interface request and waits for a response from the server.

[0093] Step S407: The server receives the RPC interface request, processes it and returns the result to the client.

[0094] Step S408: The client receives a response from the server and performs corresponding processing.

[0095] like Figure 8 As shown, the main controller is provided with a control system RPC interface, and the wireless processor is provided with a wireless system RPC interface, wherein the main processor acts as a client, and each service module in the main processor can request the data it needs from the main controller (equivalent to the server) or the wireless processor (also equivalent to the server) according to its own needs.

[0096] The above wireless additional components are used to implement the RPC interface function, which will greatly simplify the system design.

[0097] See below Figure 6 , a specific implementation of a service communication system 600 of each module in a vehicle terminal is described:

[0098] A service communication system 600 for each module in a vehicle terminal, comprising: a target file generation module 601, a data publishing module 602 and a data subscription module 603;

[0099] The target file generation module 601 is used to define a data structure description file according to Capnp.

[0100] In this embodiment, the data structure description file is defined according to the Capnp IDL schema specific description. Figure 2 As shown, it can be: gnss_data_publish.capnp.

[0101] The data structure description file is compiled into a target programming language file by a Capnp compiler.

[0102] In this embodiment, the target programming language file is a C++ file, that is, it is compiled into a C++ object by a Capnp compiler and outputted as gnss_data_publish.c++ and gnss_data_publish.hpp.

[0103] The data publishing module 602 is used for: the data publisher creates a socket in zmq publishing mode and binds it to a specific port; obtains the data source and calls the serialization interface of Capnp to encode the data to be published; and calls the sending interface of ZMQ to publish the data.

[0104] The data subscription module 603 is used for: the data subscriber receives the data from the publisher and calls the deserialization interface of Capnp to decode the published data. Specifically, the data subscriber creates a socket in ZMQ subscription mode and connects to the IP address of the publisher and the specific port; the data subscriber continuously receives the data from the publisher and calls the deserialization interface of Capnp to decode the published data. It should be noted that for the data publisher, when there is data to be published, it will be republished, and when there is data to be published, the data subscriber will receive it.

[0105] Just like Figure 8 As shown, the fuel-saving system service module subscribes to the data release of the main controller, so when the main controller releases data, the fuel-saving system service module will receive it.

[0106] Get the structure data defined by the publisher and perform different application processing on the data. Figure 8 As shown, the fuel saving system service obtains the current fuel remaining status of the vehicle sent by the main controller, analyzes the fuel usage, and makes corresponding prompts and adjustments.

[0107] The above system 600 supports a 1:n relationship between one publisher and multiple subscribers, and is applied to situations where multiple distributed applications require the same data. It can flexibly manage and control distributed data, and Canpn directly supports the construction of RPC interfaces, without the need for additional components to build RPC interfaces, making system development easier. It uses interface definition (IDL) to describe data types and methods, and flexibly and conveniently analyzes and processes complex data. Application developers do not need to know the implementation details behind the interface, which facilitates the development of the application layer. Distributed communication technology based on publishing and subscription facilitates business expansion without affecting the original business.

[0108] As mentioned above, Canpn directly supports RPC interface construction, such as Figure 3 As shown in the figure, Capnp RPC is compared with traditional RPC: In the Capnproto framework, a different approach can be taken. Capnproto's RPC adopts a method similar to Promise, which streamlines all interface operations. Intermediate results do not need to be sent back to the client first, but only need to wait for the final result to be returned. Therefore, this reduces the round-trip transmission of intermediate results and reduces call latency.

[0109] The following is an explanation of the method of building an RPC interface based on Capnp:

[0110] Furthermore, it also includes: an RPC interface construction module, the RPC interface construction module includes: a server and a client;

[0111] The target file generation module 601 is used to define the RPC interface and related data structure description files according to the Capnp IDL schema specific description. Figure 4 As shown, it can be: nad_system_rpc_service.capnp.

[0112] The data structure description file is compiled into a C++ file by using the Capnp compiler, and the output is as follows: nad_system_rpc_service.c++ and nad_system_rpc_service.hpp.

[0113] The server is used to: call capnp::EzRpcServer to establish an RPC server and bind it to the port specified by the user; the server continues to run, waiting to accept client connections and process related requests;

[0114] The client is used to: call capnp::EzRpcClient to establish an RPC client and establish a connection with a designated port of the server; the client calls an RPC interface request and waits for a response from the server;

[0115] The server is also used to: receive the RPC interface request, process it and reply the result to the client;

[0116] The client is also used to: receive a response from the server and perform corresponding processing.

[0117] like Figure 8 As shown, the main controller is provided with a control system RPC interface, and the wireless processor is provided with a wireless system RPC interface, wherein the main processor acts as a client, and each service module in the main processor can request the data it needs from the main controller (equivalent to the server) or the wireless processor (also equivalent to the server) according to its own needs.

[0118] The above wireless additional components are used to implement the RPC interface function, which will greatly simplify the system design.

[0119] It should be noted that, as Figure 8 As shown, the data subscription module 603 and the client may be the same module, such as the fuel saving system service module in the main processor, and the data publishing module 602 and the server may be the same module, such as a wireless processor or a main controller.

[0120] See below Figure 7 , a specific implementation of a vehicle 700 is described:

[0121] The vehicle 700 includes the above-mentioned in-vehicle terminal module service communication system 600.

[0122] Finally, it should be noted that although the above embodiments have been described in the specification and drawings of this application, this does not limit the scope of patent protection of this application. All technical solutions generated by replacing or modifying equivalent structures or equivalent processes based on the essential concept of this application using the contents recorded in the specification and drawings of this application, as well as directly or indirectly implementing the technical solutions of the above embodiments in other related technical fields, are included in the scope of patent protection of this application.

Claims

1. A service communication method for each module in a vehicle terminal, characterized in that: Includes steps: Define the data structure description file according to Capnp; Compile the data structure description file into a target programming language file by using a Capnp compiler; Get the data source and call Capnp's serialization interface to encode the data to be published; Call ZMQ's sending interface to publish data; The data subscriber receives the data from the publisher and calls the Capnp deserialization interface to decode the published data; Obtain the structured data defined by the publisher and perform different application processing on the data.

2. A method for communication between modules in a vehicle terminal according to claim 1, characterized in that: Before obtaining the data source, the method further includes the following steps: The data publisher creates a socket in zmq publishing mode and binds it to a specific port.

3. A method for communication between modules in a vehicle terminal according to claim 2, characterized in that: The data subscriber receives the data from the publisher and calls the deserialization interface of Capnp to decode the published data, which specifically includes the steps of: The data subscriber creates a socket in ZMQ subscription mode and connects to the publisher's IP address and the specific port; The data subscriber continuously receives the data from the publisher and calls the Capnp deserialization interface to decode the published data.

4. A method for communication between modules in a vehicle terminal according to any one of claims 1 to 3, characterized in that: The target programming language file is a C++ file.

5. A method for communication between modules in a vehicle terminal according to claim 1, characterized in that: Build RPC interface based on Capnp; The RPC interface construction includes the following steps: Define the RPC interface and related data structure description files according to Capnp's IDL schema specific description; Compile the data structure description file into a C++ file using a Capnp compiler; The server calls capnp::EzRpcServer to establish an RPC server and bind it to the port specified by the user; The server continues to run, waiting to accept client connections and process related requests; The client calls capnp::EzRpcClient to establish an RPC client and establish a connection with the server's specified port; The client calls the RPC interface request and waits for the server's response; The server receives the RPC interface request, processes it and sends the result back to the client; The client receives the response from the server and performs corresponding processing.

6. A service communication system for each module in a vehicle terminal, characterized in that: include: Target file generation module, data publishing module and data subscription module; The target file generation module is used to: define a data structure description file according to Capnp; Compile the data structure description file into a target programming language file by using a Capnp compiler; The data publishing module is used to: obtain the data source, and call the serialization interface of Capnp to encode the data to be published; call the sending interface of ZMQ to publish the data; The data subscription module is used for: the data subscriber receives the data from the publisher and calls the deserialization interface of Capnp to decode the published data; obtains the structure data defined by the publisher and performs different application processing on the data.

7. A service communication system for each module in a vehicle terminal according to claim 6, characterized in that: The data publishing module is also used for: the data publisher creates a socket in zmq publishing mode and binds it to a specific port.

8. A service communication system for each module in a vehicle terminal according to claim 7, characterized in that: The data subscription module is also used for: the data subscriber creates a socket in ZMQ subscription mode and connects to the IP address of the publisher and the specific port; The data subscriber continuously receives the data from the publisher and calls the Capnp deserialization interface to decode the published data.

9. A service communication system for each module in a vehicle terminal according to claim 6, characterized in that: Also includes: An RPC interface building module, wherein the RPC interface building module includes: a server and a client; The target file generation module is used to: define the RPC interface and related data structure description files according to the specific description of Capnp's IDL schema; compile the data structure description files into C++ files through the Capnp compiler; The server is used to: call capnp::EzRpcServer to establish an RPC server and bind it to the port specified by the user; the server runs continuously, waiting to accept client connections and process related requests; The client is used to: call capnp::EzRpcClient to establish an RPC client and establish a connection with a designated port of the server; the client calls an RPC interface request and waits for a response from the server; The server is also used to: receive the RPC interface request, process and reply the result to the client; The client is also used to: receive a response from the server and perform corresponding processing.

10. A vehicle, characterized in that: A service communication system for each module in a vehicle-mounted terminal comprising any one of claims 6 to 9.

Images