Vehicle communication method and vehicle

Abstract

The embodiment of the application provides a vehicle communication method and a vehicle, the method comprises the following steps: obtaining a configuration file and a role of a service unit, wherein the configuration file is used for defining the attribute of any communication subject; and establishing a communication link according to the attribute of any communication subject in the configuration file and the role of the service unit, wherein the communication link is used for providing a communication route for the service unit. The application solves the technical problem of resource redundancy in the related art when cross-process communication is implemented.

Description

Technical Field

[0001] This application relates to the field of intelligent driving software technology, and more specifically, to a vehicle communication method and a vehicle. Background Technology

[0002] For cross-process communication, existing solutions mainly rely on shared memory or middleware-based communication protocols, such as Data Distribution Service (DDS). While shared memory can achieve high-performance data sharing, its deployment is complex, its synchronization mechanism is cumbersome, and it has stringent requirements for inter-process permission management and memory mapping consistency, making it difficult to be universally applicable in multi-tasking, security-critical autonomous driving environments. Although middleware such as DDS has good cross-platform and cross-process communication capabilities, DDS introduces complete serialization and deserialization processes, network stack overhead, and other resource entities, resulting in a large amount of unnecessary resource consumption, memory overhead, and communication latency, thus wasting performance.

[0003] There is currently no good solution to the above problems. Summary of the Invention

[0004] This application provides a vehicle communication method and a vehicle to at least solve the technical problem of resource redundancy in cross-process communication in related technologies.

[0005] According to one aspect of the embodiments of this application, a vehicle communication method is provided, comprising: obtaining a configuration file and the roles of a business unit, wherein the configuration file is used to define the attributes of any communication topic; and establishing a communication link based on the attributes of any communication topic in the configuration file and the roles of the business unit, wherein the communication link is used to provide communication routing for the business unit.

[0006] Furthermore, establishing a communication link based on the attributes of any communication topic in the configuration file and the role of the business unit includes: in response to the business unit's role being a subscriber, obtaining a first Boolean value corresponding to any communication topic in the configuration file, wherein the first Boolean value is used to determine whether the message of any communication topic needs to be received across processes; in response to the first Boolean value being true and the existence of a cross-process communication receiver corresponding to any communication topic, associating any communication topic with the corresponding cross-process communication receiver to establish a communication link, wherein the cross-process communication receiver is used to receive the message of any communication topic across processes; in response to the first Boolean value being true and the absence of a cross-process communication receiver, creating a cross-process communication receiver and associating any communication topic with the corresponding cross-process communication receiver to establish a communication link.

[0007] Furthermore, the vehicle communication method also includes: subscribing to messages for any communication topic through a cross-process communication receiver.

[0008] Furthermore, the vehicle communication method also includes: obtaining callback functions for messages to be subscribed to; storing the callback functions in a subscription management mapping table within the process, wherein the subscription management mapping table uses any communication topic as the key and the list of callback functions corresponding to any communication topic as the value.

[0009] Furthermore, the vehicle communication method also includes: in response to the first Boolean value being false, storing the callback function in the subscription management mapping table.

[0010] Furthermore, establishing a communication link based on the attributes of any communication topic in the configuration file and the role of the business unit includes: in response to the business unit's role being a publisher, obtaining a second Boolean value corresponding to any communication topic in the configuration file, wherein the second Boolean value is used to determine whether the message of any communication topic needs to be published across processes; in response to the second Boolean value being true, submitting the message of any communication topic to the cross-process communication sender corresponding to any communication topic to establish a communication link, wherein the cross-process communication sender is used to publish the message of any communication topic across processes.

[0011] Furthermore, the vehicle communication method also includes: publishing messages on any communication topic through a cross-process communication sender.

[0012] Furthermore, the vehicle communication method also includes: in response to the second boolean value being false, querying whether any communication topic exists in the subscription management mapping table within the process; in response to the existence of any communication topic in the subscription management mapping table, obtaining a list of callback functions corresponding to any communication topic; encapsulating each callback function in the callback function list to obtain multiple tasks; and asynchronously executing the multiple tasks through a thread pool or asynchronous executor.

[0013] Furthermore, the vehicle communication method also includes: exiting the current operation in response to the absence of any communication topic in the subscription management mapping table.

[0014] According to another aspect of the embodiments of this application, a vehicle communication device is also provided, comprising: an acquisition module for acquiring a configuration file and the roles of business units, wherein the configuration file is used to define the attributes of any communication topic; and an establishment module for establishing a communication link based on the attributes of any communication topic in the configuration file and the roles of business units, wherein the communication link is used to provide communication routing for the business units.

[0015] Furthermore, the module is also used to, in response to the business unit's role being a subscriber, obtain a first Boolean value corresponding to any communication topic in the configuration file, wherein the first Boolean value is used to determine whether the message of any communication topic needs to be received across processes; in response to the first Boolean value being true and the existence of a cross-process communication receiver corresponding to any communication topic, associate any communication topic with the corresponding cross-process communication receiver to establish a communication link, wherein the cross-process communication receiver is used to receive the message of any communication topic across processes; in response to the first Boolean value being true and the absence of a cross-process communication receiver, create a cross-process communication receiver and associate any communication topic with the corresponding cross-process communication receiver to establish a communication link.

[0016] Furthermore, the vehicle communication device also includes a subscription module for subscribing to messages on any communication topic through a cross-process communication receiver.

[0017] Furthermore, the vehicle communication device also includes: a storage module for obtaining callback functions for messages to be subscribed to; storing the callback functions in a subscription management mapping table within the process, wherein the subscription management mapping table uses any communication topic as the key and the list of callback functions corresponding to any communication topic as the value.

[0018] Furthermore, the storage module is also used to store the callback function in the subscription management mapping table in response to the first boolean value being false.

[0019] Furthermore, the module is also used to obtain a second Boolean value corresponding to any communication topic in the configuration file in response to the role of the business unit as the publisher. The second Boolean value is used to determine whether the message of any communication topic needs to be published across processes. In response to the second Boolean value being true, the module submits the message of any communication topic to the cross-process communication sender corresponding to any communication topic to establish a communication link. The cross-process communication sender is used to publish the message of any communication topic across processes.

[0020] Furthermore, the vehicle communication device also includes a publishing module for publishing messages on any communication topic via a cross-process communication sender.

[0021] Furthermore, the vehicle communication device also includes: an execution module, configured to: query whether any communication topic exists in the subscription management mapping table within the process in response to a second Boolean value being false; obtain a list of callback functions corresponding to any communication topic in response to the existence of any communication topic in the subscription management mapping table; encapsulate each callback function in the callback function list to obtain multiple tasks; and execute the multiple tasks asynchronously through a thread pool or an asynchronous executor.

[0022] Furthermore, the vehicle communication device also includes an exit module, used to exit the current operation in response to the absence of any communication topic in the subscription management mapping table.

[0023] According to another aspect of the embodiments of this application, a vehicle is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the vehicle communication methods in various embodiments of this application when it runs.

[0024] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to execute the vehicle communication method of various embodiments of this application.

[0025] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the vehicle communication methods in various embodiments of this application.

[0026] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the vehicle communication methods in various embodiments of this application.

[0027] In this embodiment, the configuration file and the role of the business unit are first obtained. The configuration file is used to define the attributes of any communication topic. Then, a communication link is established based on the attributes of any communication topic in the configuration file and the role of the business unit. The communication link is used to provide communication routing for the business unit. By dynamically judging the cross-process enabling status of the communication topic, cross-process communication resources are created only when necessary, thereby improving system configurability and reducing maintenance costs. This achieves the technical effect of enabling cross-process communication on demand and optimizing resource utilization, and solves the technical problem of resource redundancy in the implementation of cross-process communication in related technologies. Attached Figure Description

[0028] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0029] Figure 1 This is a flowchart of a vehicle communication method according to an embodiment of this application;

[0030] Figure 2 This is a schematic diagram of an optional system architecture according to an embodiment of this application;

[0031] Figure 3This is a flowchart of an optional subscriber registration method according to an embodiment of this application;

[0032] Figure 4 This is a flowchart of an optional message publishing method according to an embodiment of this application;

[0033] Figure 5 This is a structural block diagram of a vehicle communication device according to an embodiment of this application. Detailed Implementation

[0034] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0035] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0036] According to an embodiment of this application, an embodiment of a vehicle communication method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0037] This method embodiment can be executed in an electronic device or similar computing device that includes memory and a processor. Taking operation on a computer terminal as an example, the computer terminal may include one or more processors (processors may include, but are not limited to, central processing units (CPUs), graphics processing units (GPUs), digital signal processing (DSP) chips, microcontroller units (MCUs), field-programmable gate arrays (FPGAs), neural network processors (NPUs), tensor processors (TPUs), artificial intelligence (AI) type processors, etc.) and memory for storing data. Optionally, the computer terminal may also include transmission devices, input / output devices, and display devices for communication functions. Those skilled in the art will understand that the above structural description is merely illustrative and does not limit the structure of the computer terminal. For example, the computer terminal may include more or fewer components than described above, or have a different configuration than described above.

[0038] The memory can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the vehicle communication method in this embodiment. The processor executes various functional applications and data processing by running the computer program stored in the memory, thereby implementing the aforementioned vehicle communication method. The memory may include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks (LANs), mobile communication networks, and combinations thereof.

[0039] The transmission device is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the mobile terminal's communication provider. In one example, the transmission device includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0040] Display devices can be, for example, touchscreen liquid crystal displays (LCDs) and touch displays (also referred to as "touchscreens" or "touch displays"). The LCD allows users to interact with the user interface of the mobile terminal. In some embodiments, the mobile terminal has a graphical user interface (GUI), which allows users to interact with the GUI through finger contact and / or gestures on a touch-sensitive surface. Optional human-computer interaction functions include: creating web pages, drawing, word processing, creating electronic documents, playing games, video conferencing, instant messaging, sending and receiving emails, call interfaces, playing digital video, playing digital music, and / or web browsing, etc. Executable instructions for performing the above human-computer interaction functions are configured / stored in one or more processor-executable computer program products or readable storage media.

[0041] This embodiment provides a vehicle communication method. Figure 1 This is a flowchart of a vehicle communication method according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps:

[0042] Step S10: Obtain the configuration file and the role of the business unit, wherein the configuration file is used to define the attributes of any communication topic;

[0043] In this embodiment of the application, the configuration file refers to a static configuration document written in a structured format and loaded when the system starts. It is used to uniformly define the communication attributes of all communication topics in the system, including but not limited to: inter_process_send_enabled, which indicates whether the messages of the communication topic are allowed to be sent from the current process to other processes; and inter_process_receive_enabled, which indicates whether the messages of the communication topic are allowed to be received from other processes to the current process, which is not restricted here.

[0044] A business unit refers to a software module or component in an intelligent driving software system that performs a specific function, such as a perception module, a planning module, a control module, and a localization module. Each business unit plays the role of a publisher or subscriber in the communication system; that is, as a publisher, it is responsible for generating and sending data on a specific communication topic; as a subscriber, it is responsible for receiving and processing data on a specific communication topic. There are no restrictions on this.

[0045] A communication topic is a unique named channel used in a communication system to identify the semantics of a data flow; it is a logical abstraction of data interaction between publishers and subscribers. Each communication topic corresponds to a structured data type, and its content contains data with specific business semantics. Communication topics are managed by configuration files and serve as the basis for establishing communication routes; however, no restrictions are imposed here.

[0046] The process of obtaining configuration files and the roles of business units can be understood as loading external configuration files from a preset path, parsing the cross-process communication attributes of each communication topic defined therein, listening for or receiving subscription or publish / register requests from each business unit, identifying the role (publisher or subscriber) that each business unit plays in the communication network, and its associated specific communication topic.

[0047] It can be seen that by reading configuration and registration information at runtime to dynamically perceive and establish communication relationships, code modifications due to deployment changes are avoided, significantly improving the maintainability and reconfigurability of the software.

[0048] Step S12: Establish a communication link based on the attributes of any communication topic in the configuration file and the role of the business unit, wherein the communication link is used to provide communication routing for the business unit.

[0049] In this embodiment of the application, a communication link refers to a logical data transmission channel that is dynamically constructed by the core of the communication system at runtime, based on the cross-process enabling attribute of a certain communication topic in the configuration file and the specific role (publisher or subscriber) of the business unit.

[0050] Establishing a communication link based on the attributes of any communication topic in the configuration file and the role of the business unit can be understood as intelligently determining and dynamically constructing a data transmission path that is most suitable for the current scenario by reading the communication policy of any communication topic in the configuration file (such as whether cross-process sending and receiving is allowed) and combining whether the current business unit is a publisher or a subscriber.

[0051] As can be seen, the system automatically selects the optimal communication path based on the configuration and business roles loaded at runtime, enabling the same set of business code to adapt to multiple deployment models and greatly improving the flexibility of the architecture.

[0052] Through the above steps, the configuration file and the role of the business unit are first obtained. The configuration file is used to define the attributes of any communication topic. Then, a communication link is established based on the attributes of any communication topic in the configuration file and the role of the business unit. The communication link is used to provide communication routing for the business unit. By dynamically judging the cross-process enabling status of the communication topic, cross-process communication resources are created only when necessary, thereby improving system configurability and reducing maintenance costs. This achieves the technical effect of enabling cross-process communication on demand and optimizing resource utilization, and solves the technical problem of resource redundancy in the implementation of cross-process communication in related technologies.

[0053] Further, in step S12, a communication link is established based on the attributes of any communication topic in the configuration file and the role of the business unit, including the following steps:

[0054] Step S121: In response to the business unit's role being a subscriber, obtain the first boolean value corresponding to any communication topic in the configuration file, wherein the first boolean value is used to determine whether the message of any communication topic needs to be received across processes;

[0055] Step S122: In response to the first Boolean value being true and the existence of a cross-process communication receiver corresponding to any communication topic, associate any communication topic with the corresponding cross-process communication receiver to establish a communication link, wherein the cross-process communication receiver is used to receive messages of any communication topic across processes.

[0056] Step S123: In response to the first Boolean value being true and no cross-process communication receiver existing, create a cross-process communication receiver and associate any communication topic with the corresponding cross-process communication receiver to establish a communication link.

[0057] In this embodiment, the first Boolean value is a switch attribute defined in the configuration file for a certain communication topic, named inter_process_receive_enabled, and its value is a Boolean type (true or false). The first Boolean value is used to explicitly indicate whether the messages for this communication topic need to be received from other processes. For example, if it is true, it means that this service unit (as a subscriber) expects to receive messages for this topic from an external process; if it is false, it means that the messages for this topic are limited to internal transmission within this process and do not need to listen to data in external networks or shared memory, which is not restricted here.

[0058] An inter-process communication (IPC) receiver is a low-level system component used to receive communication data from other processes. It is typically provided by middleware, such as the DataReader in a Data Distribution Service (DDS) or a receive listener in a shared memory mechanism. An IPC receiver has the ability to listen to external communication channels (such as networks or shared memory buffers) and can pass the received raw data to the upper-level system. The creation and destruction of IPC receivers are controlled by a first Boolean value; they are instantiated only when necessary to avoid resource waste.

[0059] In response to the business unit's role as a subscriber, obtaining the first boolean value corresponding to any communication topic in the configuration file can be understood as follows: when a business unit needs to receive messages from a certain topic (i.e., as a subscriber), the system will automatically look up the definition of that communication topic in the configuration file and read a boolean switch named inter_process_receive_enabled, which is the first boolean value.

[0060] In response to the first boolean value being true and the existence of a cross-process communication receiver for any communication topic, associating any communication topic with the corresponding cross-process communication receiver to establish a communication link can be understood as follows: if the system determines that the communication topic requires cross-process reception (boolean value being true) and finds that a receiving component (such as DDS's DataReader) has already been created for the topic in the system, then the system does not need to create it again. Instead, it directly binds the current subscriber's request with the existing cross-process communication receiver, thereby forming a communication channel. This ensures that multiple subscribers can share the same cross-process receiving resource, improving efficiency and avoiding duplicate system overhead.

[0061] In response to a true first boolean value and the absence of a cross-process communication receiver, a cross-process communication receiver is created, and any communication topic is associated with the corresponding cross-process communication receiver to establish a communication link. This can be understood as follows: if the system determines that a communication topic requires cross-process reception but has not yet created a corresponding receiving component (e.g., the topic is being subscribed to for the first time, or resources have been released previously), the system dynamically initializes a cross-process communication receiver (e.g., creating a DDSDataReader) and binds it to the current topic to form a communication channel. Therefore, when an external process publishes a message for this communication topic, the corresponding cross-process communication receiver can capture the data and forward it to the local subscriber.

[0062] As can be seen, by dynamically reading the first boolean value in the configuration during subscriber registration, the system achieves on-demand activation and intelligent reuse of cross-process receiving capabilities. The underlying communication receiver is created or associated only when the configuration explicitly requires cross-process receiving, avoiding unnecessary resource consumption. Simultaneously, by sharing existing cross-process receivers, the system effectively reduces memory and thread overhead caused by repeated initialization, ensuring that the communication link achieves maximum resource efficiency and performance while maintaining functional integrity, thus realizing a highly flexible and low-overhead communication mechanism.

[0063] Furthermore, the vehicle communication method also includes the following steps:

[0064] Step S1221: Subscribe to messages for any communication topic through the cross-process communication receiver.

[0065] In this embodiment, subscribing to messages on any communication topic through a cross-process communication receiver can be understood as the system using a cross-process communication receiver (such as DDS's DataReader or a shared memory listener) to initiate a listening request to the communication network or shared channel, indicating that the node is interested in data on a specific topic. The cross-process communication receiver registers a topic identifier at the protocol level, continuously waits for and captures specific topic messages published by other processes, and once data is received, triggers a local callback or caching mechanism to pass the original message to the upper-layer business module.

[0066] As can be seen, the above steps are completed automatically by the system without the need for business code intervention, and are only initiated when the first boolean value is true, ensuring the accuracy, immediacy and resource controllability of cross-process communication.

[0067] Furthermore, the vehicle communication method also includes the following steps:

[0068] Step S1222: Obtain the callback function for the message to be subscribed;

[0069] Step S1223: Store the callback function in the subscription management mapping table within the process, wherein the subscription management mapping table uses any communication topic as the key and the list of callback functions corresponding to any communication topic as the value.

[0070] In this embodiment, a callback function refers to a function pointer or executable object provided by a business module (such as a perception or planning subsystem) when registering and subscribing to a communication topic. This function is automatically invoked by the system to process the received data when a new message arrives for that communication topic. For example, when the perception module publishes a target object list message, the control module registers a function named `onObjectListReceived(const ObjectList& data)` as a callback. When the system receives a message for that communication topic, it automatically passes the message content as a parameter to this callback function, triggering subsequent decision-making logic.

[0071] The subscription management mapping table is an in-memory data structure maintained by the system within a process, typically a hash table in key-value pair format. For example, the function of this subscription management mapping table is: when a topic is published within the local process, the system can quickly locate all local subscribers interested in that topic simply by looking up this table, without relying on external communication, and then sequentially call their callback functions, achieving zero-copy, high-efficiency message distribution within the process. No further restrictions are imposed here.

[0072] The callback function for obtaining messages to be subscribed can be understood as follows: when a business unit requests to listen to a certain communication topic as a subscriber, the system extracts its predefined processing function (i.e., callback function) from the subscription request of that business unit. This callback function encapsulates the specific business logic to be executed after receiving the message. The system captures it as the response entry point when the message arrives, preparing for subsequent local distribution. There are no restrictions here.

[0073] Storing callback functions in an in-process subscription management mapping table can be understood as the system storing the obtained callback functions in a globally maintained subscription management mapping table within the process, using the communication topic they are listening to as the key. This creates a one-to-one mapping relationship between the communication topic and all registered processing functions, ensuring that when the communication topic is subsequently published within the process, the system can quickly, lock-free, and batch call all relevant callbacks to complete efficient, asynchronous, and zero-copy local message distribution.

[0074] As can be seen, by actively obtaining callback functions provided by business modules during the subscription registration phase and storing these callback functions in the in-process subscription management mapping table, the decoupling of communication logic and business logic and the optimization of in-process message distribution are achieved. This allows for direct triggering of local callback functions via hash lookup during message publication, enabling zero-copy, low-latency, and high-concurrency asynchronous distribution. Furthermore, the topic-based index structure supports multiple subscribers sharing the same communication topic, ensuring scalability and resource reusability, and improving system real-time performance and operational efficiency.

[0075] Furthermore, the vehicle communication method also includes the following steps:

[0076] In step S1224, in response to the first boolean value being false, the callback function is stored in the subscription management mapping table.

[0077] In this embodiment of the application, storing the callback function in the subscription management mapping table in response to the first boolean value being false can be understood as follows: even if the current communication topic is configured not to receive across processes (i.e., inter_process_receive_enabled=false), the system still unconditionally registers the callback function provided by the business module to the subscription management mapping table within the process, ensuring that the subscriber can still receive messages on the same topic published by other modules within the same process.

[0078] As can be seen, through the above steps, regardless of whether cross-process communication is enabled, as long as there is a local subscription requirement, the system guarantees its efficient and zero-copy local message receiving capability, thereby achieving complete decoupling and deployment independence of the communication mechanism. That is, the module's subscription behavior does not change due to the deployment form, and the cross-process channel is only dynamically controlled by configuration, which greatly improves the flexibility and reconfigurability of the software architecture.

[0079] Further, in step S12, a communication link is established based on the attributes of any communication topic in the configuration file and the role of the business unit, including the following steps:

[0080] Step S124: In response to the role of the business unit being the publisher, obtain the second boolean value corresponding to any communication topic in the configuration file, wherein the second boolean value is used to determine whether the message of any communication topic needs to be published across processes;

[0081] Step S125: In response to the second Boolean value being true, submit the message of any communication topic to the cross-process communication sender corresponding to any communication topic to establish a communication link, wherein the cross-process communication sender is used to publish the message of any communication topic across processes.

[0082] In this embodiment, the second Boolean value refers to a Boolean switch parameter (such as inter_process_send_enabled) configured in the configuration file for each communication topic, used to indicate whether the messages of the communication topic are allowed to be sent to other processes. For example, when the second Boolean value is true, it means that the messages of the communication topic need to be distributed externally through an inter-process communication mechanism (such as DDS, shared memory, etc.), and when the second Boolean value is false, it means that the messages of the communication topic are limited to propagation within the current process, and the system will skip the inter-process sending process.

[0083] The inter-process communication sender refers to an abstract component dynamically created or reused by the system according to configuration, which encapsulates the underlying inter-process communication protocol (such as DDS's DataWriter, shared memory write port, etc.). When the second boolean value is true, the inter-process communication sender is used to receive raw message data from the publishing module, perform necessary serialization, protocol encapsulation, and network / shared channel delivery operations, and reliably send the message to the corresponding receiving end of other processes. There are no restrictions here.

[0084] Responding to the business unit's role as a publisher, obtaining the second boolean value corresponding to any communication topic in the configuration file can be understood as follows: when the system detects that a business unit is performing a message publishing operation, it automatically queries the configuration file for the second boolean value (such as inter_process_send_enabled) corresponding to that communication topic to determine whether the message for that topic is allowed to be transmitted across process boundaries.

[0085] In response to a true second Boolean value, the message for any communication topic is submitted to the cross-process communication sender corresponding to that topic to establish a communication link. This can be understood as follows: when the configuration indicates that a topic needs to be published across processes, the system hands over the raw message data to a pre-created or on-demand initialized cross-process communication sender (such as DDS DataWriter, shared memory write port, etc.) for processing. The cross-process communication sender is responsible for performing serialization, protocol encapsulation, and low-level transmission, delivering the message to the receiver of other processes. This establishes a reliable message channel between processes, ensuring that cross-process communication resources (such as DDS Participant, Topic, DataWriter) are created and used on demand, avoiding unnecessary memory usage in intra-process communication scenarios, and achieving optimal resource utilization and performance optimization.

[0086] As can be seen, the above steps together construct an intelligent routing mechanism. The publishing end no longer cares whether the message crosses processes. The system automatically determines the communication range according to the configuration file and activates the cross-process sending end only when necessary, thereby decoupling business logic from communication topology. This ensures the reliability of cross-process communication and achieves zero overhead for intra-process communication.

[0087] Furthermore, the vehicle communication method also includes the following steps:

[0088] Step S1251: Publish a message for any communication topic through the cross-process communication sender.

[0089] In this embodiment of the application, publishing a message on any communication topic through the inter-process communication sender can be understood as the inter-process communication sender, as a standardized encapsulation component of the underlying communication protocol, converting the message into a format supported by the target communication protocol after receiving the message, and atomically sending the message to the corresponding receiving end of one or more remote processes through the operating system, thus ensuring the selectivity, reliability and efficiency of inter-process communication.

[0090] As can be seen, by taking the above steps, the original message is serialized and efficiently delivered to the remote process in one go, thereby avoiding unnecessary serialization, network stack calls and resource occupation in the context of intra-process communication, significantly reducing system overhead and memory consumption, and improving the flexibility, performance and maintainability of the intelligent driving software architecture.

[0091] Furthermore, the vehicle communication method also includes the following steps:

[0092] Step S1252: In response to the second Boolean value being false, query whether any communication topic exists in the subscription management mapping table within the process;

[0093] Step S1253: In response to the existence of any communication topic in the subscription management mapping table, obtain the list of callback functions corresponding to any communication topic;

[0094] Step S1254: Encapsulate each callback function in the callback function list to obtain multiple tasks;

[0095] Step S1255: Execute multiple tasks asynchronously using a thread pool or an asynchronous executor.

[0096] In this embodiment of the application, multiple tasks refer to encapsulating each callback function associated with a certain communication topic in the in-process subscription management mapping table into an independent, schedulable, lightweight execution unit.

[0097] A thread pool is a set of reusable worker threads that are pre-created and maintained by the system during the initialization phase to asynchronously process multiple tasks generated by the deployment process.

[0098] An asynchronous executor is a high-level component that encapsulates task scheduling, thread management, and execution strategies. It can be implemented based on a thread pool or extended to an asynchronous runtime environment based on an event loop, coroutines, or priority queues.

[0099] In response to the second boolean value being false, querying the subscription management mapping table within the process to check if any communication topic exists can be understood as follows: when the system determines that a certain communication topic does not need to be published across processes (i.e., the second boolean value inter_process_send_enabled is false), it does not terminate the message distribution process, but actively queries the subscription management mapping table maintained within the process to confirm whether there are subscribers interested in the topic within the current process. This ensures the integrity and consistency of the communication mechanism and avoids message loss due to changes in deployment mode.

[0100] In response to the existence of any communication topic in the subscription management mapping table, obtaining the list of callback functions corresponding to any communication topic can be understood as follows: after confirming that there are local subscribers for the communication topic, the system directly extracts all callback functions bound to the communication topic from the subscription management mapping table to form a callback function list. This supports fast traversal and concurrent access and is a key data structure for achieving high-throughput intra-process communication.

[0101] Each callback function in the callback function list is encapsulated to obtain multiple tasks. This can be understood as the system packaging each callback function and its associated message data into an independent, immutable execution unit (i.e., a task). This task includes a function pointer, parameter bindings, and execution context. The encapsulated task is designed as a stateless, serializable, and schedulable lightweight object, eliminating the need for the publishing end to wait for any time-consuming operations to complete, thus ensuring the real-time performance and stability of the critical path.

[0102] Asynchronous execution of multiple tasks using thread pools or asynchronous executors can be understood as the system submitting multiple encapsulated tasks in batches to a pre-initialized thread pool or asynchronous executor. This avoids the blocking and latency caused by directly calling callback functions in the publishing thread, effectively improving system concurrency and response throughput. Simultaneously, by reusing thread resources, the overhead of context switching and thread creation is significantly reduced, ensuring low latency and high stability even in high-frequency message scenarios.

[0103] As can be seen, the above steps achieve zero-blocking, high-concurrency, low-latency, and efficient resource utilization for in-process message distribution. When the communication topic does not need to be published across processes, the system can still accurately identify local subscribers and directly obtain the callback list using function pointers, avoiding serialization overhead. By encapsulating each callback as a lightweight task and assigning it to a thread pool or asynchronous executor for asynchronous execution, the execution paths of message publishing and business processing are decoupled, allowing the publishing thread to return immediately without waiting for any time-consuming callbacks, significantly improving the system's real-time performance and throughput.

[0104] Furthermore, the vehicle communication method also includes the following steps:

[0105] Step S1256: In response to the absence of any communication topic in the subscription management mapping table, exit the current operation.

[0106] In this embodiment of the application, the exit from the current operation in response to the absence of any communication topic in the subscription management mapping table can be understood as follows: when the system confirms that a certain communication topic has no subscribers in the current process (i.e., there is no corresponding key value in the mapping table), it indicates that the message does not need to be distributed in this process. The system will immediately terminate the subsequent local processing flow and no longer perform redundant operations such as callback encapsulation, task delivery, or thread scheduling, which significantly improves the efficiency and response speed of the message processing path.

[0107] As can be seen, when the system determines that the current message has no subscribers in the current process, it immediately terminates all subsequent local processing flows (such as callback lookup, task encapsulation, thread scheduling, etc.), thus avoiding meaningless calculations and memory overhead on empty topics.

[0108] Figure 2 This is a schematic diagram of an optional system architecture according to an embodiment of this application, such as... Figure 2 As shown, the system architecture includes: business modules, a unified communication interface, a communication system core, a communication middleware abstraction layer, and underlying communication media. The business modules interact with the communication system core through a unified communication interface, completely shielding the underlying implementation. The communication system core consists of modules such as a configuration management module, a publish management module, a subscribe management module, and an asynchronous executor, responsible for intelligently routing messages based on configuration. The communication middleware abstraction layer encapsulates the specific implementations of inter-process communication protocols, giving the system good scalability. The underlying communication media carries and implements the specific physical transmission channels and protocol stacks for cross-process communication; it is the actual communication infrastructure invoked by the communication middleware abstraction layer.

[0109] Figure 3 This is a flowchart of an optional subscriber registration method according to an embodiment of this application, such as... Figure 3As shown, when the system starts, it loads a unified configuration file (such as XML, YAML, PROTO, or JSON format). This configuration file defines the properties of all communication topics in the system, including the key configuration item: `inter_process_receive_enabled`: a boolean value indicating whether the topic is allowed to receive messages from other processes. When a business module, acting as a subscriber, wants to register a subscription to a topic, it performs the following: First, it handles cross-process subscriptions: it queries the configuration. If `inter_process_receive_enabled` for the topic is true, it indicates that the topic's messages need to be received across processes. If a cross-process communication receiver exists (e.g., DDS's DataReader), it is associated with that receiver. If no cross-process communication receiver exists (e.g., DDS's DataReader), it is created or associated with a cross-process communication receiver (e.g., DDS's DataReader) for the topic. This receiver is responsible for listening to and receiving data from external processes. Second, it handles intra-process subscriptions: without querying the configuration, it directly stores the callback function provided by the subscriber into a global subscription management map within the process. This map uses the topic as the key and the list of callback functions corresponding to that topic as the value.

[0110] Figure 4 This is a flowchart of an optional message publishing method according to an embodiment of this application, such as... Figure 4As shown, when the system starts, it loads a unified configuration file (such as XML, YAML, PROTO, or JSON format). This configuration file defines the properties of all communication topics in the system, including the key configuration item: `inter_process_send_enabled`: a boolean value indicating whether messages for this topic are allowed to be sent to other processes. When a business module sends a message for a topic as a publisher, it first performs cross-process data transmission: it queries the configuration to determine if `inter_process_send_enabled` for the topic is true. If true, it indicates that the topic message needs to be transmitted across processes, so the message is first submitted to the cross-process communication sender corresponding to the topic (such as DDS's DataWriter), which serializes the message and sends it to other processes. If false, it indicates that the topic message does not need to be transmitted across processes, and no further operations are performed. Secondly, it performs intra-process data transmission: it does not first need to query the configuration, but only checks if the topic exists in the intra-process subscription management map. If it exists, it indicates that there are subscribers to this topic within the process. It finds the corresponding callback function list and iterates through each callback function in the list for processing. To ensure the performance of the publishing thread and avoid being blocked by time-consuming callback functions, an asynchronous scheduling mechanism is preferred: each callback function call is encapsulated as a task and submitted to an independent thread pool or asynchronous executor for execution, thereby achieving zero-copy, non-blocking, and high-performance message distribution within the process. If it does not exist, it means that there are no subscribers to this topic within the process, and no in-process data publishing is required.

[0111] Through the above technical solution, communication behavior is defined by configuration files, decoupling business code from specific underlying communication interfaces. When the module deployment location changes, only the configuration needs to be modified, without rewriting any communication code, greatly improving the reconfigurability and maintainability of the software. For in-process subscribers, messages are directly passed via function pointer callbacks, achieving zero-copy delivery with extremely low latency. This application introduces an intelligent serialization mechanism; if the same message needs to be sent both outside and inside the process, serialization is performed only once (for cross-process sending). For in-process subscribers, no serialization operation is required; the original object is directly passed, avoiding the performance overhead of serialization. Furthermore, the asynchronous execution mechanism avoids time-consuming callbacks blocking the publishing thread, ensuring the real-time performance of critical threads. In addition, this application only creates resources such as DDS Participant, DataWriter, and DataReader when cross-process communication is explicitly required in the configuration, reducing resource waste in in-process communication scenarios. Managing all communication attributes through a unified configuration center reduces system complexity. New communication protocols can be easily integrated through the communication middleware abstraction layer, resulting in strong system scalability.

[0112] The following is a specific embodiment:

[0113] I. Configuration file preparation:

[0114] Define the communication topic and message structure:

[0115] Define key topics, such as: / perception / objects (a list of target objects published by the perception module).

[0116] Use IDL (Interface Definition Language) or Protobuf to define the message structure ObjectList for this topic, which contains information such as the target object's code, location, and speed.

[0117] Write a unified configuration file (using YAML format as an example):

[0118] Configuration 1 (Two modules in the same process): Since communication only occurs within the process, it is configured to not require cross-process communication.

[0119] # config_single_process.yaml

[0120] topics:

[0121] name:" / perception / objects"

[0122] inter_process_send_enabled: false # Do not send interprocess to other processes

[0123] inter_process_receive_enabled: false # Do not receive data from other processes

[0124] #Other configurations, such as reliability and historical depth, can be added here.

[0125] reliability: BEST_EFFORT

[0126] history_depth:10

[0127] Configuration 2 (Independent deployment of planning modules): The configuration file needs to be modified to set the send and receive enable of the corresponding topic to true.

[0128] # config_multi_process.yaml

[0129] topics:

[0130] - name:" / perception / objects"

[0131] inter_process_send_enabled:true # The perception module needs to send messages to the process.

[0132] inter_process_receive_enabled: true # The planning module needs to receive this message from outside the process.

[0133] reliability: RELIABLE # Cross-process communication may require higher reliability.

[0134] history_depth:10

[0135] II. System Initialization:

[0136] When the system starts, the configuration management module loads a YAML-formatted configuration file from a specified path (such as / etc / config / comm_config.yaml).

[0137] The module parses the file and builds a configuration cache in memory.

[0138] Initialize the asynchronous executor and create a thread pool containing several worker threads.

[0139] Initialize the communication middleware abstraction layer, such as the underlying layer that is adapted to DDS (such as Fast DDS) as the implementation of cross-process communication.

[0140] III. Subscription Registration Process:

[0141] Taking the topic " / perception / objects" as an example:

[0142] During initialization, the control module calls the subscription interface: CreateSubscriber(" / perception / objects", callback_func), where callback_func is the callback function for receiving subscription messages.

[0143] The subscription management module queries the configuration. If it is configuration 1 above, it finds that inter_process_receive_enabled is false, indicating that the topic does not need to be sent across processes and no DDS DataReader needs to be created. If it is configuration 2 above, it finds that inter_process_receive_enabled is true, and then creates a DDS DataReader through the communication middleware abstraction layer (if it has not been created yet) and starts subscribing to the topic messages in the network.

[0144] Subsequently, callback_func is added to the callback function list corresponding to " / perception / objects" in the in-process subscription mapping table.

[0145] IV. Message Sending Process:

[0146] Taking sending to the topic " / perception / objects" as an example:

[0147] After the perception module captures a frame of image, it calls: publish(" / perception / objects", objects_data).

[0148] After receiving the message, the publishing management module queries the configuration. If it is configuration 1 above, it finds that inter_process_send_enabled is false, so there is no need to send data to external processes. If it is configuration 2 above, it finds that inter_process_send_enabled is true, so it serializes the objects_data and publishes it to the DDS network using the DDS DataWriter that was previously created for the topic.

[0149] Next, check the in-process subscription mapping table. If there are subscribers, encapsulate each callback function as a task and submit it to an independent thread pool or asynchronous executor for asynchronous execution. If there are no subscribers, this step ends.

[0150] V. Message Receiving and Distribution Process:

[0151] Taking the topic " / perception / objects" as an example:

[0152] Cross-process reception: After the communication middleware abstraction layer (such as the communication abstraction interface that encapsulates DDS, through DDS's DataReader) receives a message for the topic " / perception / objects" from the network, it encapsulates the subsequent business processing flow into a task and submits it to an independent thread pool or asynchronous executor, which then executes it asynchronously.

[0153] In-process reception: In-process reception has already been processed when the message was sent in the previous step.

[0154] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0155] According to an embodiment of this application, a vehicle communication device is provided. It should be noted that the device can be used to execute the above-described vehicle communication method.

[0156] Figure 5 This is a structural block diagram of a vehicle communication device according to an embodiment of this application, such as... Figure 5 As shown, the vehicle communication device 500 further includes: an acquisition module 501, used to acquire a configuration file and the roles of service units, wherein the configuration file is used to define the attributes of any communication topic; and an establishment module 502, used to establish a communication link based on the attributes of any communication topic in the configuration file and the roles of service units, wherein the communication link is used to provide communication routing for service units.

[0157] Furthermore, module 502 is also configured to, in response to the business unit's role being a subscriber, obtain a first Boolean value corresponding to any communication topic in the configuration file, wherein the first Boolean value is used to determine whether the message of any communication topic needs to be received across processes; in response to the first Boolean value being true and the existence of a cross-process communication receiver corresponding to any communication topic, associate any communication topic with the corresponding cross-process communication receiver to establish a communication link, wherein the cross-process communication receiver is used to receive the message of any communication topic across processes; in response to the first Boolean value being true and the absence of a cross-process communication receiver, create a cross-process communication receiver and associate any communication topic with the corresponding cross-process communication receiver to establish a communication link.

[0158] Furthermore, the vehicle communication device also includes a subscription module for subscribing to messages on any communication topic through a cross-process communication receiver.

[0159] Furthermore, the vehicle communication device also includes: a storage module for obtaining callback functions for messages to be subscribed to; storing the callback functions in a subscription management mapping table within the process, wherein the subscription management mapping table uses any communication topic as the key and the list of callback functions corresponding to any communication topic as the value.

[0160] Furthermore, the storage module is also used to store the callback function in the subscription management mapping table in response to the first boolean value being false.

[0161] Furthermore, the establishment module 502 is also used to obtain a second Boolean value corresponding to any communication topic in the configuration file in response to the role of the business unit being the publisher. The second Boolean value is used to determine whether the message of any communication topic needs to be published across processes. In response to the second Boolean value being true, the message of any communication topic is submitted to the cross-process communication sender corresponding to any communication topic to establish a communication link. The cross-process communication sender is used to publish the message of any communication topic across processes.

[0162] Furthermore, the vehicle communication device also includes a publishing module for publishing messages on any communication topic via a cross-process communication sender.

[0163] Furthermore, the vehicle communication device also includes: an execution module, configured to: query whether any communication topic exists in the subscription management mapping table within the process in response to a second Boolean value being false; obtain a list of callback functions corresponding to any communication topic in response to the existence of any communication topic in the subscription management mapping table; encapsulate each callback function in the callback function list to obtain multiple tasks; and execute the multiple tasks asynchronously through a thread pool or an asynchronous executor.

[0164] Furthermore, the vehicle communication device also includes an exit module, used to exit the current operation in response to the absence of any communication topic in the subscription management mapping table.

[0165] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0166] Embodiments of this application also provide a vehicle, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the clock synchronization method in various embodiments of this application during runtime.

[0167] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0168] Step S10: Obtain the configuration file and the role of the business unit, wherein the configuration file is used to define the attributes of any communication topic;

[0169] Step S12: Establish a communication link based on the attributes of any communication topic in the configuration file and the role of the business unit, wherein the communication link is used to provide communication routing for the business unit.

[0170] Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to execute the clock synchronization method of various embodiments of this application.

[0171] Optionally, in this embodiment, the storage medium may be configured to store a computer program for performing the following steps:

[0172] Step S10: Obtain the configuration file and the role of the business unit, wherein the configuration file is used to define the attributes of any communication topic;

[0173] Step S12: Establish a communication link based on the attributes of any communication topic in the configuration file and the role of the business unit, wherein the communication link is used to provide communication routing for the business unit.

[0174] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the clock synchronization method in various embodiments of this application.

[0175] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0176] Step S10: Obtain the configuration file and the role of the business unit, wherein the configuration file is used to define the attributes of any communication topic;

[0177] Step S12: Establish a communication link based on the attributes of any communication topic in the configuration file and the role of the business unit, wherein the communication link is used to provide communication routing for the business unit.

[0178] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the clock synchronization method in various embodiments of this application.

[0179] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0180] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0181] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0182] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0183] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0184] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A vehicle communication method, characterized in that, include: Obtain the configuration file and the roles of the business units, wherein the configuration file is used to define the attributes of any communication topic; A communication link is established based on the attributes of any communication topic in the configuration file and the role of the business unit, wherein the communication link is used to provide communication routing for the business unit.

2. The method according to claim 1, characterized in that, The step of establishing a communication link based on the attributes of any communication topic in the configuration file and the role of the business unit includes: In response to the business unit's role being a subscriber, a first boolean value corresponding to any communication topic in the configuration file is obtained, wherein the first boolean value is used to determine whether the message of any communication topic needs to be received across processes; In response to the first Boolean value being true and the existence of a cross-process communication receiver corresponding to any of the communication topics, the any of the communication topics is associated with the corresponding cross-process communication receiver to establish the communication link, wherein the cross-process communication receiver is used to receive messages of any of the communication topics across processes; In response to the first Boolean value being true and the absence of the cross-process communication receiver, the cross-process communication receiver is created, and any communication topic is associated with the corresponding cross-process communication receiver to establish the communication link.

3. The method according to claim 2, characterized in that, The method further includes: The cross-process communication receiver can subscribe to messages for any of the communication topics.

4. The method according to claim 3, characterized in that, The method further includes: Retrieve the callback function for messages to be subscribed to; The callback function is stored in the subscription management mapping table within the process, wherein the subscription management mapping table uses the any communication topic as the key and the list of callback functions corresponding to the any communication topic as the value.

5. The method according to claim 4, characterized in that, The method further includes: In response to the first boolean value being false, the callback function is stored in the subscription management mapping table.

6. The method according to claim 1, characterized in that, The step of establishing a communication link based on the attributes of any communication topic in the configuration file and the role of the business unit includes: In response to the role of the business unit being a publisher, a second boolean value corresponding to any communication topic in the configuration file is obtained, wherein the second boolean value is used to determine whether the message of any communication topic needs to be published across processes; In response to the second Boolean value being true, the message of any communication topic is submitted to the cross-process communication sender corresponding to the any communication topic to establish the communication link, wherein the cross-process communication sender is used to publish the message of any communication topic across processes.

7. The method according to claim 6, characterized in that, The method further includes: Messages on any of the communication topics are published through the cross-process communication sender.

8. The method according to claim 6, characterized in that, The method further includes: If the second Boolean value is false, query the subscription management mapping table within the process to see if any of the communication topics exists; In response to the existence of any of the communication topics in the subscription management mapping table, a list of callback functions corresponding to any of the communication topics is obtained; Each callback function in the callback function list is encapsulated to obtain multiple tasks; The multiple tasks are executed asynchronously using a thread pool or an asynchronous executor.

9. The method according to claim 8, characterized in that, The method further includes: If none of the communication topics exist in the subscription management mapping table, exit the current operation.

10. A vehicle, characterized in that, include: Memory, which stores executable programs; A processor for running the executable program, wherein the executable program, when run on the processor, performs the vehicle communication method as described in any one of claims 1 to 9.

Images