Data communication methods, devices, electronic equipment, target vehicles and media

Abstract

This invention relates to the field of data communication technology, specifically to data communication methods, apparatus, electronic devices, target vehicles, and media. The method includes: receiving a target data topic registration request submitted by a target communication module; obtaining a communication configuration file corresponding to the target data topic registration request based on the request; parsing the communication configuration file to obtain a target communication instance corresponding to the registration request; and feeding back the target communication instance to the target communication module, enabling the module to send and receive target data topics based on the instance. This solves the problem that a single protocol cannot adequately handle performance across multiple scenarios, improving the real-time performance and efficiency of data transmission. It provides an efficient communication mechanism capable of quickly matching protocols and providing communication instances.

Description

Technical Field

[0001] This invention relates to the field of data communication technology, specifically to data communication methods, devices, electronic equipment, target vehicles, and media. Background Technology

[0002] As autonomous driving technology evolves towards higher levels, vehicle electronic and electrical architecture is rapidly transforming from the traditional distributed ECU architecture to a centralized or domain-centralized architecture. Under the new architecture, autonomous driving systems need to run a large number of functional modules such as perception, localization, planning, and control in parallel. These modules need to form a collaborative closed loop through high-frequency data acquisition, real-time processing, and efficient communication to support autonomous driving decision-making and execution in complex road conditions. Their communication performance directly affects the safety and reliability of vehicle operation.

[0003] The communication topologies of different functional modules vary significantly, resulting in various communication scenarios such as intra-process communication, inter-process communication, and inter-controller communication. The performance requirements for communication protocols differ significantly across these scenarios. For example, intra-process communication requires extremely low latency to ensure real-time data interaction, while inter-controller communication has stringent requirements for bandwidth and interference resistance, and inter-process communication needs to balance latency and compatibility. A single communication protocol cannot simultaneously meet the high-performance requirements of multiple scenarios. Using a fixed protocol to adapt to all scenarios can lead to excessively high communication latency and unstable data transmission in some scenarios, even affecting the closed-loop response efficiency of the autonomous driving system's "perception-decision-control" mechanism.

[0004] To address the issue of multi-protocol adaptation, existing technologies support multiple mainstream media protocols through a unified protocol adaptation interface and enable dynamic loading and unloading of modules, thereby improving system scalability and protocol compatibility. However, this solution focuses primarily on media protocol adaptation and does not optimize for the communication scenarios of autonomous driving systems. It cannot automatically match the optimal communication protocol and instance configuration based on the differentiated needs of different communication scenarios (such as intra-process and cross-controller scenarios), making it difficult to meet the refined requirements for communication latency, reliability, and bandwidth in autonomous driving scenarios.

[0005] Therefore, how to build an efficient communication mechanism that can quickly provide communication instances for the characteristics of multiple communication scenarios in autonomous driving has become a pressing technical challenge. Summary of the Invention

[0006] This invention provides a data communication method, device, electronic device, target vehicle, and medium to address the problem of how to construct an efficient communication mechanism that can quickly provide communication instances for the characteristics of multiple communication scenarios in autonomous driving.

[0007] In a first aspect, the present invention provides a data communication method, the method comprising: receiving a target data topic registration request submitted by a target communication module; obtaining a communication configuration file corresponding to the target data topic registration request based on the target data topic registration request; parsing the communication configuration file to obtain a target communication instance corresponding to the target data topic registration request; and feeding back the target communication instance to the target communication module so that the target communication module can send and receive target data topics based on the target communication instance.

[0008] The data communication method provided in this application receives a target data topic registration request submitted by a target communication module, accurately accepts the communication needs of upper-layer business modules (such as autonomous driving and ADAS modules) of the intelligent driving system, establishes a "module-topic" requirement association, and provides a clear target orientation for subsequent scenario matching and target communication instance allocation. Based on the target data topic registration request, the communication configuration file corresponding to the target data topic registration request is obtained. Communication rules are stored in an independent communication configuration file, so upper-layer business modules do not need to pay attention to the details of the underlying protocol. When modifying communication parameters or scenario matching rules later, only the configuration file needs to be adjusted, without modifying the business code, thus improving the maintainability and scalability of the system. The communication configuration file is parsed to obtain the target communication instance corresponding to the target data topic registration request, solving the problem that a single protocol cannot simultaneously handle the performance of multiple scenarios, and improving the real-time performance and efficiency of data transmission. The target communication instance is fed back to the target communication module so that the target communication module can send and receive target data topics based on the target communication instance. This completes the entire closed-loop process of "request-parsing-instance allocation-business use," ensuring that upper-layer modules can quickly obtain available target communication instances, achieving efficient data interoperability between multiple modules, and supporting the multi-module collaborative function of the intelligent driving system. Target communication instances are uniformly allocated and managed by electronic devices. When a target communication module submits a deregistration request, the corresponding target communication instance can be accurately located for resource reclamation, preventing resource leaks and ensuring long-term stable system operation. An efficient communication mechanism is provided that can quickly match protocols and provide communication instances.

[0009] In one optional implementation, parsing the communication configuration file to obtain the target communication instance corresponding to the target data topic registration request includes: parsing the communication configuration file to determine the module deployment relationship and target communication parameters corresponding to the target data topic registration request; generating a communication topology diagram corresponding to the target data topic registration request based on the module deployment relationship and target communication parameters; determining the target communication scenario corresponding to the target data topic registration request based on the communication topology diagram; obtaining the target communication instance based on the target communication scenario, and incrementing the instance reference count corresponding to the target communication instance by 1.

[0010] The data communication method provided in this application parses the communication configuration file to determine the module deployment relationship and target communication parameters corresponding to the target data topic registration request. This provides a quantitative basis for subsequent scenario determination and avoids protocol matching errors caused by subjective judgment. By processing the configuration file with a unified parsing logic, it ensures consistent interpretation rules for configuration information of different data topics and modules, improving system compatibility and stability. Based on the module deployment relationship and target communication parameters, a communication topology diagram corresponding to the target data topic registration request is generated. This transforms scattered module deployment information into a structured communication topology diagram, clearly showing the publish / subscribe modules corresponding to the data topic and the connection types between modules, facilitating system operation and maintenance and troubleshooting. The communication parameters corresponding to each link are bound in the communication topology diagram, achieving precise "link-parameter" mapping and providing an intuitive reference for subsequent target communication scenario determination and protocol selection. Based on the communication topology diagram, the target communication scenario corresponding to the target data topic registration request is determined. Based on the link types in the communication topology diagram, the target communication scenario is automatically determined, solving the problem of complex protocol adaptation across multiple scenarios and ensuring optimal data transmission performance. The target communication scenario is clearly defined by the communication topology diagram and directly mapped to the preset protocol stack, avoiding the involvement of upper-layer modules in protocol decisions and reducing the coupling between business modules and underlying communication. Scenarios are determined based on standardized communication topology diagrams and preset rules, avoiding discrepancies in judgment results caused by manual intervention and improving the uniformity of system communication strategies. Based on the target communication scenario, the target communication instance is obtained, and the instance reference count corresponding to the target communication instance is incremented by 1. Available target communication instances in the local instance pool are matched according to the target communication scenario, avoiding duplicate instance creation and plugin loading, reducing system memory and CPU resource consumption, and improving the response speed of communication requests. The usage status of the target communication instance is marked by the instance reference count; incrementing the count indicates the addition of a user to the target communication, providing a basis for the subsequent "release if no reference" resource reclamation mechanism and preventing instance resource leakage. Communication instances adapted to the scenario are directly obtained and delivered to upper-layer modules, eliminating the need for modules to adapt protocols themselves, reducing the development and usage costs of business modules, and supporting efficient collaboration among multiple modules in the intelligent driving system.

[0011] In one optional implementation, obtaining a target communication instance based on a target communication scenario includes: determining the target communication protocol stack and target protocol parameters corresponding to the target communication scenario based on a preset communication scenario and communication protocol stack mapping table; detecting whether a target communication instance has been created in the local instance pool based on the target communication protocol stack and target protocol parameters; and if a target communication instance has been created in the local instance pool, then obtaining the target communication instance is performed.

[0012] The data communication method provided in this application, based on a preset communication scenario and communication protocol stack mapping table, determines the target communication protocol stack and target protocol parameters corresponding to the target communication scenario. The preset communication scenario and communication protocol stack mapping table achieves precise matching between the target communication scenario and the target protocol stack, clearly defining specific communication parameters, avoiding blind protocol selection, and ensuring data transmission performance is adapted to the communication scenario. Based on the target communication protocol stack and target protocol parameters, the method detects whether a target communication instance has already been created in the local instance pool. It prioritizes detecting and reusing existing local communication instances, avoiding duplicate instance creation and plugin loading, reducing system resource consumption, and improving communication request response efficiency. If a target communication instance already exists in the local instance pool, it is acquired. A usable instance is directly acquired and delivered to the upper-layer module, eliminating the time-consuming processes of plugin loading and instance creation, reducing the usage cost of business modules, and supporting efficient collaborative communication among multiple modules in intelligent driving.

[0013] In one optional implementation, obtaining the target communication instance based on the target communication scenario further includes: if the local instance pool does not have a created target communication instance, then based on the target communication protocol stack, detecting whether there is a target plugin corresponding to the target communication protocol stack and a communication instance creator corresponding to the target plugin in the local loaded plugin list; if there is a target plugin and a communication instance creator corresponding to the target plugin in the local loaded plugin list, then creating the target communication instance based on the communication instance creator and incrementing the plugin reference count corresponding to the target plugin by 1.

[0014] The data communication method provided in this application, if the local instance pool does not contain a created target communication instance, then based on the target communication protocol stack, detects the presence of a target plugin corresponding to the target communication protocol stack and a corresponding communication instance creator in the local loaded plugin list. After instance reuse fails, priority is given to detecting locally loaded plugins to avoid resource consumption and time consumption caused by repeatedly loading plugins, thus improving the creation efficiency of the target communication instance. If the local loaded plugin list contains a target plugin and a corresponding communication instance creator, then the target communication instance is created based on the communication instance creator, and the plugin reference count corresponding to the target plugin is incremented by 1. The target communication instance is quickly generated using the communication instance creator of the loaded plugin, and the plugin reference count marks the dependency status of the target plugin, providing a basis for the safe uninstallation of subsequent plugins and ensuring controllable system resources.

[0015] In one optional implementation, obtaining the target communication instance based on the target communication scenario further includes: if the target plugin and its corresponding communication instance creator are not found in the locally loaded plugin list, then obtaining the plugin configuration file corresponding to the target plugin based on the target communication protocol stack; based on the plugin configuration file, checking whether the target plugin corresponding to the plugin configuration file exists in the plugin repository; if the target plugin exists in the plugin repository, loading the target plugin and registering the corresponding communication instance creator; incrementing the plugin reference count of the target plugin by 1; and calling the communication instance creator to generate the target communication instance based on the target protocol parameters.

[0016] The data communication method provided in this application embodiment, if the target plugin and its corresponding communication instance creator are not found in the locally loaded plugin list, then obtains the plugin configuration file corresponding to the target plugin based on the target communication protocol stack. Accurately locating the plugin configuration file through the protocol stack provides a standardized basis for subsequent plugin search and loading, avoiding blind plugin searches. Based on the plugin configuration file, it checks whether the target plugin corresponding to the configuration file exists in the plugin repository. Pre-verifying the existence and legality of the target plugin in the plugin repository avoids invalid loading operations and reduces the risk of system malfunctions. If the target plugin exists in the plugin repository, it loads the target plugin and registers the corresponding communication instance creator; the plugin reference count of the target plugin is incremented by 1. This enables dynamic on-demand loading of plugins and automatic registration of creators, while also supporting plugin lifecycle management by marking plugin dependency status through counting. The communication instance creator is called to generate a target communication instance based on the target protocol parameters. The plugin creator generates a communication instance adapted to the target scenario and parameters, ensuring that the instance function accurately matches business requirements and supports the data transmission and reception needs of upper-layer modules.

[0017] In an optional implementation, the method further includes: obtaining a target data topic deregistration request sent by the target communication module; finding the target communication instance corresponding to the target data topic registration request; calling the target communication interface corresponding to the target communication instance to terminate the data transmission and reception of the target communication instance and disconnect the protocol connection; decrementing the instance reference count corresponding to the target communication instance by 1; detecting whether the instance reference count corresponding to the target communication instance is equal to 0; and releasing the target communication instance if the instance reference count is equal to 0.

[0018] The data communication method provided in this application embodiment obtains a target data topic deregistration request sent by a target communication module. It accurately receives the deregistration request from the upper-layer module, serving as the starting point for the resource reclamation process, clearly identifying the target topic to be released, and ensuring the targeted nature of the deregistration operation. It locates the target communication instance corresponding to the target data topic registration request. This quickly identifies the communication instance to be reclaimed, avoiding accidental operation on other instances and ensuring the accuracy of resource reclamation. It calls the target communication interface corresponding to the target communication instance to terminate the data transmission and reception of the target communication instance and disconnect the protocol connection. It proactively terminates the instance's business functions and cuts off the protocol link to prevent data transmission and reception anomalies during the release process, ensuring system communication stability. It decrements the instance reference count corresponding to the target communication instance by 1. This updates the usage status of the target communication instance, providing a counting basis for subsequent judgments on whether to release the instance, supporting fine-grained management of the instance lifecycle. It checks whether the instance reference count corresponding to the target communication instance is equal to 0. It determines whether the target communication instance is still referenced by other modules, avoiding accidental release of occupied target communication instances and ensuring the security of resource reclamation. If the instance reference count is equal to 0, the target communication instance is released. Resource release is performed only on target communication instances that are not referenced, thus avoiding the leakage of system resources such as memory and ports and improving system resource utilization.

[0019] In one optional implementation, after releasing the target communication instance, the method further includes: obtaining the target plugin corresponding to the target communication instance, and counting the plugin reference count of the target plugin under all communication instances; decrementing the plugin reference count of the target plugin by 1; detecting whether the plugin reference count of the target plugin is equal to 0; and releasing the target plugin if the plugin reference count is equal to 0.

[0020] The data communication method provided in this application obtains the target plugin corresponding to the target communication instance and counts the plugin reference count of the target plugin under all communication instances. It establishes an association between the target communication instance and the target plugin, accurately obtaining the global dependency status of the target plugin and providing data support for target plugin resource reclamation. The plugin reference count corresponding to the target plugin is decremented by 1. The dependency count of the target plugin is updated to reflect changes in the usage status of the target plugin in real time, providing a basis for subsequent uninstallation decisions. It checks whether the plugin reference count corresponding to the target plugin is equal to 0. It determines whether the target plugin has no instance dependencies to avoid mistakenly uninstalling still-in-use plugins and ensure the stability of the system communication link. If the plugin reference count is equal to 0, the target plugin is released. Uninstallation is only performed on target plugins without dependencies, reclaiming the memory and handle resources occupied by the target plugin and avoiding dynamic link library resource leaks.

[0021] In a second aspect, the present invention provides a data communication device, the device comprising: The receiving module is used to receive the target data topic registration request submitted by the target communication module; The lookup module is used to find the communication configuration file corresponding to the target data topic registration request based on the target data topic registration request. The acquisition module is used to parse the communication configuration file and obtain the target communication instance corresponding to the target data topic registration request; The feedback module is used to feed back the target communication instance to the target communication module, so that the target communication module can send and receive target data topics based on the target communication instance.

[0022] Thirdly, the present invention provides an electronic device, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the data communication method described in the first aspect or any corresponding embodiment thereof.

[0023] Fourthly, the present invention provides a target vehicle, including a vehicle body and an electronic device as described in the third aspect.

[0024] Fifthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to perform the data communication method described in the first aspect or any corresponding embodiment thereof.

[0025] In a sixth aspect, the present invention provides a computer program product, including computer instructions for causing a computer to execute the data communication method described in the first aspect or any corresponding embodiment thereof. Attached Figure Description

[0026] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0027] Figure 1 This is a schematic diagram of the software architecture corresponding to the data communication method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the first type of data communication method according to an embodiment of the present invention; Figure 3 This is a schematic diagram of a second type of data communication method according to an embodiment of the present invention; Figure 4 This is the correspondence between communication scenarios and communication protocol stacks according to embodiments of the present invention; Figure 5 This is a schematic diagram of a third data communication method according to an embodiment of the present invention; Figure 6 This is a structural block diagram of a data communication device according to an embodiment of the present invention; Figure 7 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0029] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0030] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "multiple" means two or more, unless otherwise explicitly specified.

[0031] According to an embodiment of the present invention, a data communication method embodiment 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.

[0032] This embodiment provides a data communication method that can be used with an electronic device. The electronic device can be an electronic device in a target vehicle, a mobile terminal, or a server; this application does not specifically limit the type of electronic device. Figure 1 As shown, the electronic device includes a software architecture corresponding to the data communication method, which includes a scene management module, a communication management module, a plug-in management module, and a communication plug-in repository.

[0033] Publishers / subscribers can be business modules within an intelligent driving system, such as autonomous driving modules, ADAS modules, and high-precision map modules. The core function is to obtain / return target communication instances to the communication management module through a unified communication interface, enabling data publishing and subscription without needing to concern themselves with the underlying protocol details.

[0034] The input to the scenario management module is a communication configuration file (containing Topic, module deployment relationships, scenario-protocol mapping rules, etc.). Its core function is to parse the communication configuration file, generate a communication topology diagram, determine the communication scenario (intra-process / inter-process / inter-controller) corresponding to the current Topic, and pass the scenario information to the communication management module to achieve scenario-adaptive protocol selection.

[0035] The core functions of the communication management module are: maintaining a local communication instance pool and prioritizing the reuse of existing instances as target communication instances; managing the lifecycle of target communication instances (creation, reference counting, release); providing a unified interface for publishers / subscribers to obtain / return communication instances; and interacting with the plugin management module to obtain the communication instance creator and create target communication instances.

[0036] The input for the plugin management module is the plugin configuration file. Its core functions include: managing the entire lifecycle of communication plugins: dynamically loading / unloading plugins, registering / unregistering communication instance creators; maintaining plugin reference counts to ensure plugins are only uninstalled when they have no dependencies; and responding to dynamic management commands (loading, uninstalling, and upgrading plugins) from the command line / visual management interface.

[0037] The communication plugin repository stores all compiled communication plugins (such as .so dynamic link libraries), including shared memory plugins, Zmq plugins, TCP / IP plugins, etc.

[0038] The plugin management module can dynamically load / unload plugins from the communication plugin repository as needed.

[0039] The command-line / visual management terminal corresponds to the system operation and maintenance tools and serves as the entry point for manual operations. Its core function is to send commands to the plugin management module through a unified management interface, enabling dynamic management of plugins (loading, uninstalling, and upgrading), and supporting hot-swapping and hot upgrades.

[0040] Specifically, the publisher / subscriber (i.e., the target communication module) obtains / returns the target communication instance through the communication management module. The communication management module requests a creator from the plugin management module, which loads / unloads plugins and registers the creator. Based on the plugin configuration file, the plugin management module loads the target plugin from the communication plugin repository or uninstalls plugins without dependencies. The management terminal sends instructions, and the plugin management module executes plugin loading / unloading / upgrading, while also updating plugins and configuration files in the repository. The scenario management module transmits communication scenario information to the communication management module. The scenario management module parses the communication configuration, determines the communication scenario, and the communication management module matches the protocol stack and instance accordingly. Figure 2 This is a flowchart of a data communication method according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps: Step S101: Receive the target data topic registration request submitted by the target communication module.

[0041] The target communication module is the intelligent driving business module or other business model that initiates the registration request. For example, it could be an upper-layer application of the intelligent driving system, such as an autonomous driving decision-making module, an ADAS obstacle detection module, or a high-precision map module.

[0042] The target data topic registration request is a request submitted by the target communication module to use a specific data topic for data transmission and reception. The request initiated by the target communication module includes: the data topic name (e.g., lidar_point_cloud) and the operation type (publish / subscribe).

[0043] Specifically, the target communication module (such as the lidar data publishing module) sends a standardized target data topic registration request to the scene management module. The request specifies the name of the data topic to be registered (such as lidar_point_cloud) and the operation type (publishing).

[0044] Step S102: Based on the target data topic registration request, find the communication configuration file corresponding to the target data topic registration request.

[0045] The communication configuration file is a system-level configuration file that matches the registration request of the target data topic and originates from the configuration storage area of ​​the communication plugin repository. The communication configuration file includes: 1. The mapping relationship between all data topics and the target communication module; 2. The communication scenario (intra-process / inter-process / inter-controller) corresponding to the data topic; 3. The matching relationship between the scenario and the protocol plugin; 4. The protocol parameters of the protocol plugin (such as shared memory size and ZMQ URL).

[0046] Specifically, after receiving the target data topic registration request, the scene management module in the electronic device retrieves the communication configuration file corresponding to the data topic from the configuration storage area of ​​the communication plugin repository according to the data topic name in the target data topic registration request (if it is the first time the target data topic registration request is received, the lazy loading mechanism is triggered to load the full communication configuration file).

[0047] The scenario management module performs validity checks on the target data topic registration request and communication configuration file. It checks whether the target data topic registration request format conforms to the specifications (e.g., whether the data topic name is valid and whether the operation type is publish / subscribe); and it checks whether the communication configuration file exists (if it does not exist, a configuration missing error is returned directly, and the process terminates).

[0048] Step S103: Parse the communication configuration file to obtain the target communication instance corresponding to the target data topic registration request.

[0049] Specifically, the scenario management module can parse the communication configuration file to determine the target communication scenario corresponding to the target data topic registration request. Then, based on the target communication scenario, it can obtain the target communication instance corresponding to the target data topic registration request.

[0050] Step S104: Feed back the target communication instance to the target communication module so that the target communication module can send and receive target data topics based on the target communication instance.

[0051] Specifically, the communication management module in the electronic device feeds back the acquired target communication instance to the target communication module through a unified communication interface. After receiving the instance, the target communication module maintains a local data topic-communication instance mapping table (recording the instance corresponding to the data topic).

[0052] The target communication module calls the standardized interface of the target communication instance to send and receive data. Specifically, for a publish request: the instance's publish(data) method is called to send out the target data topic (such as LiDAR point cloud data); for a subscribe request: the instance's subscribe() method is called to receive all data of the data topic; the communication management module monitors the instance's running status in real time (such as whether the connection is normal and whether there is data loss) to ensure the reliability of data transmission and reception.

[0053] The data communication method provided in this application receives a target data topic registration request submitted by a target communication module, accurately accepts the communication needs of upper-layer business modules (such as autonomous driving and ADAS modules) of the intelligent driving system, establishes a "module-topic" requirement association, and provides a clear target orientation for subsequent scenario matching and target communication instance allocation. Based on the target data topic registration request, the communication configuration file corresponding to the target data topic registration request is obtained. Communication rules are stored in an independent communication configuration file, so upper-layer business modules do not need to pay attention to the details of the underlying protocol. When modifying communication parameters or scenario matching rules later, only the configuration file needs to be adjusted, without modifying the business code, thus improving the maintainability and scalability of the system. The communication configuration file is parsed to obtain the target communication instance corresponding to the target data topic registration request, solving the problem that a single protocol cannot simultaneously handle the performance of multiple scenarios, and improving the real-time performance and efficiency of data transmission. The target communication instance is fed back to the target communication module so that the target communication module can send and receive target data topics based on the target communication instance. This completes the entire closed-loop process of "request-parsing-instance allocation-business use," ensuring that upper-layer modules can quickly obtain available target communication instances, achieving efficient data interoperability between multiple modules, and supporting the multi-module collaborative function of the intelligent driving system. Target communication instances are uniformly allocated and managed by electronic devices. When a target communication module submits a deregistration request, the corresponding target communication instance can be accurately located for resource reclamation, preventing resource leaks and ensuring long-term stable system operation. An efficient communication mechanism is provided that can quickly match protocols and provide communication instances.

[0054] This embodiment provides a data communication method that can be used with an electronic device. The electronic device can be an electronic device in a target vehicle, a mobile terminal, or a server. This application does not specifically limit the type of electronic device. Figure 3 This is a flowchart of a data communication method according to an embodiment of the present invention, such as... Figure 3 As shown, the process includes the following steps: Step S201: Receive the target data topic registration request submitted by the target communication module.

[0055] Please refer to the above description of step S101 for details on this step, which will not be repeated here.

[0056] Step S202: Based on the target data topic registration request, locate the communication configuration file corresponding to the target data topic registration request.

[0057] Please refer to the above description of step S102 for details on this step, which will not be repeated here.

[0058] Step S203: Parse the communication configuration file to obtain the target communication instance corresponding to the target data topic registration request.

[0059] Specifically, step S203 above may include the following steps: Step S2031: Parse the communication configuration file to determine the module deployment relationship and target communication parameters corresponding to the target data topic registration request.

[0060] Specifically, the scenario management module retrieves the corresponding configuration node in the communication configuration file based on the data topic name in the target data topic registration request. Then, the scenario management module extracts the `module_deployment` field from the target data topic's configuration node and parses the core information. This core information includes: process ID (`process_id`): identifying the operating system process to which the module belongs; and controller ID (`controller_id`): identifying the hardware controller to which the module belongs (such as the central computing platform main controller or domain controller). This clarifies which modules participate in the communication of the target data topic and on which process / controller each module is deployed.

[0061] For example, the parsing results may include the following: LiDAR module: process 1001, controller 0; autonomous driving decision module: process 1001, controller 0; ADAS module: process 1002, controller 0.

[0062] Next, the scenario management module extracts the `communication_params` field from the configuration node of the target data topic and parses it to obtain the protocol parameters corresponding to different communication scenarios (such as the shared memory size within a process, the ZmqURL between processes, and the TCP / IP port between controllers). These parameters are the core basis for generating the target communication instance and will be dynamically selected according to the final determined communication scenario.

[0063] For example, the parsing result may include the following: intra-process communication parameters: 20MB shared memory; inter-process communication parameters: Zmq's TCP address tcp: / / 127.0.0.1:5555.

[0064] Finally, the scenario management module can verify the parsing results: verifying whether the module deployment information is complete (e.g., whether process_id / controller_id is missing); verifying whether the target communication parameters conform to the specifications (e.g., whether the shared memory size is a valid value); if the verification fails, it returns a "configuration parsing failed" error and terminates the subsequent process. After verification, the module deployment relationship is obtained, including the process ID and controller ID mapping table of each participating module; the target communication parameters include the set of protocol parameters corresponding to all communication scenarios pre-configured for the target data topic.

[0065] Step S2032: Based on the module deployment relationship and target communication parameters, generate a communication topology diagram corresponding to the target data topic registration request.

[0066] Specifically, the scene management module treats all communication modules participating in the target data topic communication as "nodes" in the communication topology, labeling the attributes of each node. These include: Node name: Module name (e.g., LiDAR module); Node attributes: Process ID, Controller ID, Role (Publisher / Subscriber).

[0067] Based on the module deployment relationship corresponding to the communication module, establish a "communication link" between nodes and label the link attributes. These include: Link type: determined by process / controller ID (same process, different processes under the same controller, different controllers); Link parameters: associated with the corresponding communication parameters parsed in step S2021.

[0068] For example, the link construction can be as follows: LiDAR module Autonomous driving decision-making module: same process (ID1001), link parameter marked "20MB shared memory"; LiDAR module ADAS module: different processes on the same controller (ID1001 / 1002), link parameter labeled "ZmqURL:tcp: / / 127.0.0.1:5555".

[0069] Finally, the scene management module generates a communication topology diagram corresponding to the target data topic registration request based on the communication links established between nodes, and stores it in JSON / dictionary format for easy reading by subsequent scene determination algorithms.

[0070] Step S2033: Based on the communication topology map, determine the target communication scenario corresponding to the target data topic registration request.

[0071] Specifically, electronic devices can extract the `link_type` attribute of all communication links from the `links` field of the communication topology diagram. For example, the extracted result would be: `intra_process` (for LiDAR). (Autonomous driving decision-making), inter_process (LiDAR) ADAS.

[0072] Then, based on the "link coverage" and "business priority", the target communication scenario for the data topic (i.e. the scenario that the system will eventually adapt to) is determined.

[0073] Optionally, the judgment rule 1 (single link): if the data topic has only one communication link, directly select the scenario corresponding to that communication link; the judgment rule 2 (multiple links): if the data topic has multiple links, select the core scenario according to the "optimal performance priority" (intra-process > inter-process > inter-controller), or match different scenarios for different links. For example, when the LiDAR module communicates with the autonomous driving decision module, the core scenario is "intra-process communication scenario"; when the LiDAR module communicates with the ADAS module, the core scenario is "inter-process communication scenario"; if the data subject has "autonomous driving decision module" as the core recipient, then the overall target communication scenario is determined to be "intra-process communication scenario".

[0074] The scenario management module binds the determined target communication scenario with the target communication parameters parsed in step S2021. For example, if the scenario is determined to be "intra-process communication scenario", the associated parameter is "20MB shared memory"; if the scenario is determined to be "inter-process communication scenario", the associated parameter is "ZmqURL:tcp: / / 127.0.0.1:5555".

[0075] The scenario management module encapsulates the "target communication scenario + associated parameters" into a standardized result and passes it to the communication management module.

[0076] Step S2034: Based on the target communication scenario, obtain the target communication instance and increment the instance reference count corresponding to the target communication instance by 1.

[0077] Specifically, obtaining the target communication instance based on the target communication scenario in step S2034 above may include the following steps: Step a1: Based on the preset communication scenario and communication protocol stack mapping table, determine the target communication protocol stack and target protocol parameters corresponding to the target communication scenario.

[0078] Specifically, the communication management module in the electronic device can load a locally stored preset communication scenario and communication protocol stack mapping table, as shown in Table 1, which is a structural example of the preset communication scenario and communication protocol stack mapping table.

[0079] Table 1. Example structure of the mapping table between preset communication scenarios and communication protocol stacks.

[0080] The communication management module accurately matches the corresponding target communication protocol stack in a preset communication scenario-to-protocol stack mapping table based on the input target communication scenario. For example, such as... Figure 4 The diagram shows the correspondence between communication scenarios and communication protocol stacks. For example, if the target communication scenario is an "intra-process communication scenario," then it matches a "shared memory protocol stack."

[0081] Then, the communication management module extracts the "default protocol parameters" corresponding to the target communication protocol stack from the preset communication scenario and communication protocol stack mapping table. Then, the communication management module uses the "target communication parameters" parsed in step S2021 to override the default parameters (if there are dedicated parameters in the configuration file).

[0082] For example, the default parameters of the mapping table are: shared memory size = 10MB; the specific parameters parsed from the configuration file are: shared memory size = 20MB; and the final target protocol parameters are: shared memory size = 20MB. The target communication protocol stack is such as a shared memory protocol stack or a ZMQ protocol stack. The target protocol parameters are a set of parameters specific to the data topic that match the protocol stack (such as 20MB of shared memory or the ZMQ URL).

[0083] Step a2: Detect whether a target communication instance has been created in the local instance pool based on the target communication protocol stack and target protocol parameters.

[0084] Specifically, the communication management module generates a unique instance matching identifier based on "target communication protocol stack + target protocol parameters + target data topic name". Example: Data topic: lidar_point_cloud; Protocol stack: shared memory protocol stack; Parameter: 20MB; Matching identifier: lidar_point_cloud_shm_20MB.

[0085] The communication management module iterates through the local instance pool, checking if a target communication instance exists that completely matches the "matching identifier." The matching rule is that only instances with identical protocol stacks, parameters, and data topics are considered "already exist." Instance attributes in the local instance pool include instance status (available / unavailable), reference count, and bound data topics.

[0086] If a match is successful: mark "The target communication instance exists in the local instance pool" and proceed to step a3; if a match fails: mark "The target communication instance does not exist in the local instance pool" and proceed to step a4.

[0087] Step a3: If a target communication instance already exists in the local instance pool, then the target communication instance will be retrieved.

[0088] Specifically, the communication management module checks the current status of the target communication instance. If the current status is "available", proceed to the next step; if the current status is "unavailable" (e.g., connection error, resource overload): determine that "target communication instance is unavailable" and jump to step a4.

[0089] Then, the communication management module increments the reference count of the target communication instance by 1 (marking it as "used by the target communication module"), thereby locking the instance's resources (to prevent accidental release by other processes). Finally, the handle / interface of the target communication instance is returned to the target communication module (or temporarily stored, awaiting subsequent unified feedback).

[0090] Step a4: If the target communication instance does not exist in the local instance pool, then based on the target communication protocol stack, check the local loaded plugin list to see if there is a target plugin corresponding to the target communication protocol stack and a communication instance creator corresponding to the target plugin.

[0091] Specifically, the communication management module can determine the target plugin corresponding to the target data topic registration request and the communication instance creator corresponding to the target plugin based on the target communication protocol stack.

[0092] For example, the target plugin corresponding to the shared memory protocol stack is a "shared memory protocol plugin"; the target creator is a "communication instance creator" registered within the target plugin for generating instances of the protocol stack.

[0093] The plugin management module in the electronic device iterates through the local list of loaded plugins and checks two core conditions: whether a "target plugin" exists (the plugin type matches the target protocol stack); and whether the target plugin has completed the registration of the "communication instance creator" (the creator must be registered with the communication management module to be valid).

[0094] If the target plugin exists in the local plugin list and the creator has been registered, then the detection is successful.

[0095] If the target plugin is not found in the locally loaded plugin list, or if the target plugin has not registered a creator (which will trigger the plugin loading process later), then the detection is considered to have failed.

[0096] Step a5: If the target plugin and its corresponding communication instance creator exist in the locally loaded plugin list, then create the target communication instance based on the communication instance creator and increment the plugin reference count corresponding to the target plugin by 1.

[0097] Specifically, if the detection is successful, the plugin management module notifies the communication management module and sends the target plugin and its corresponding communication instance creator back to the communication management module. The communication management module then invokes the communication instance creator, passing in the target protocol parameters to generate the target communication instance.

[0098] Then, the communication management module marks the newly created target communication instance with a unique identifier (protocol stack + parameters + data topic), initializes the instance reference count corresponding to the target communication instance to 1 (currently only used by the target communication module), adds the target communication instance to the local instance pool, and marks its status as "available".

[0099] In addition, the plugin management module locates the plugin reference count corresponding to the target plugin and increments the plugin reference count by 1. The plugin reference count indicates how many communication instances depend on the plugin (it can only be uninstalled when the count reaches 0). For example, the shared memory plugin originally had a reference count of 2, but after creating the target communication instance, the count became 3.

[0100] Step a6: If the target plugin and its corresponding communication instance creator are not found in the locally loaded plugin list, then obtain the plugin configuration file corresponding to the target plugin based on the target communication protocol stack.

[0101] Specifically, if the target plugin and its corresponding communication instance creator are not found in the locally loaded plugin list, the plugin management module in the electronic device locates the corresponding plugin configuration file from the system configuration directory based on the target communication protocol stack. For example, the configuration file naming convention is: [protocol stack name]_plugin_config.json (e.g., shm_plugin_config.json); the configuration file storage path is the configuration subdirectory of the plugin repository (e.g., / opt / ad / plugin / config / ).

[0102] Then, the plugin management module reads the plugin configuration file and parses the core information of the plugin configuration file. The core information may include the target plugin name, plugin file path, associated protocol stack, adaptation scenarios, default parameters, and plugin version.

[0103] Optionally, the plugin management module can also verify whether the plugin configuration file exists, whether the plugin path is valid, and whether the protocol stack matches. If the verification fails, it returns a "plugin configuration file is invalid" error and terminates the process.

[0104] Step a7: Based on the plugin configuration file, check if the target plugin corresponding to the plugin configuration file exists in the plugin repository.

[0105] Specifically, if the plugin configuration file verification is successful, the plugin management module checks whether the file corresponding to the plugin_path in the plugin configuration file exists. Specifically, the plugin management module can call system file interfaces (such as Linux's access() function) to check if the file exists and has read / execute permissions. For example, it checks whether / opt / ad / plugin / shm_plugin.so exists.

[0106] If the file exists, the plugin management module can further verify: whether the file's MD5 value matches the one recorded in the configuration file (to prevent the plugin file from being tampered with); and whether the file is a valid Linux dynamic link library (.so) format.

[0107] If a valid target plugin exists in the plugin repository, the detection is successful, and step a8 is executed. If no valid target plugin exists in the plugin repository, the detection is deemed to have failed, and the error "No target plugin found in plugin repository" is returned, terminating the data theme registration process.

[0108] Step a8: If the target plugin exists in the plugin repository, load the target plugin and register the communication instance creator corresponding to the target plugin; increment the plugin reference count of the target plugin by 1.

[0109] Specifically, the plugin management module can call the Linux system function `dlopen()` to load plugin files. For example, the call parameters can be: `dlopen(plugin_path, RTLD_LOCAL|RTLD_NOW)`; where `RTLD_LOCAL` represents the plugin symbols, meaning they are only visible to this plugin to avoid conflicts with other plugins; `RTLD_NOW` immediately resolves all plugin symbols, ensuring that it can be used immediately upon successful loading. If loading is successful, a plugin handle (`plugin_handle`) is returned; if loading fails, an error is returned (such as missing dependencies).

[0110] After the target plugin is loaded, the constructor of its internal global object `g_plugin_instance` is automatically executed, and the constructor calls the `Init()` method. The `Init()` method registers the communication instance creator within the target plugin with the communication management module. For example, the `Init()` method of the shared memory plugin registers `ShmInstanceCreator` with the creator list of the communication management module.

[0111] Optionally, the communication management module can check whether the communication instance creator corresponding to the target plugin has been successfully received. If the communication instance creator corresponding to the target plugin has not been received, it checks whether the creator interface is complete and whether it matches the protocol stack. If registration fails, it calls dlclose() to uninstall the plugin and returns a "creator registration failed" error.

[0112] Next, the plugin management module will write the information of the loaded target plugins into the "Loaded Plugins List". The record fields may include: plugin handle, plugin name, protocol stack, creator interface, loading time, and version. For example, {handle:0x7f8a1200,name:shm_plugin,stack:shared memory protocol stack,creator:0x7f8a120100}.

[0113] Finally, the plugin management module adds a counter entry for this plugin to the "Plugin Reference Count Table," with an initial value of 1. The reason for the count being 1 is that this plugin will be used to create a communication instance for the current data topic and is already depended on by an instance. Furthermore, the plugin management module can mark this target plugin as "loaded and in use," preventing it from being loaded repeatedly.

[0114] Step a9: Invoke the communication instance creator to generate a target communication instance based on the target protocol parameters.

[0115] Specifically, the communication management module retrieves the communication instance creator corresponding to the target plugin from the creator list, passes in the target protocol parameters, and generates the target communication instance. Then, the target communication instance allocates shared memory space according to the parameters, initializes the data transmission and reception buffer, binds the data topic name corresponding to the target communication instance, and generates a unique identifier for the target communication instance.

[0116] Then, the target communication instance is marked as "available", its reference count is initialized to 1, and it is added to the local instance pool of the communication management module. The standardized interface of the target communication instance (such as publish() / subscribe()) is returned to the target communication module that initiated the registration request.

[0117] Step S204: Feed back the target communication instance to the target communication module so that the target communication module can send and receive target data topics based on the target communication instance.

[0118] Please refer to the above description of step S104 for details on this step, which will not be repeated here.

[0119] The data communication method provided in this application parses the communication configuration file to determine the module deployment relationship and target communication parameters corresponding to the target data topic registration request. This provides a quantitative basis for subsequent scenario determination and avoids protocol matching errors caused by subjective judgment. By processing the configuration file with a unified parsing logic, it ensures consistent interpretation rules for configuration information of different data topics and modules, improving system compatibility and stability. Based on the module deployment relationship and target communication parameters, a communication topology diagram corresponding to the target data topic registration request is generated. This transforms scattered module deployment information into a structured communication topology diagram, clearly showing the publish / subscribe modules corresponding to the data topic and the connection types between modules, facilitating system operation and maintenance and troubleshooting. The communication parameters corresponding to each link are bound in the communication topology diagram, achieving precise "link-parameter" mapping and providing an intuitive reference for subsequent target communication scenario determination and protocol selection. Based on the communication topology diagram, the target communication scenario corresponding to the target data topic registration request is determined. Based on the link types in the communication topology diagram, the target communication scenario is automatically determined, solving the problem of complex protocol adaptation across multiple scenarios and ensuring optimal data transmission performance. The target communication scenario is clearly defined by the communication topology diagram and directly mapped to the preset protocol stack, avoiding the involvement of upper-layer modules in protocol decisions and reducing the coupling between business modules and lower-level communication. Based on the standardized communication topology diagram and preset rules for scenario determination, discrepancies in judgment results caused by manual intervention are avoided, improving the uniformity of the system's communication strategy.

[0120] Then, based on a preset communication scenario and communication protocol stack mapping table, the target communication protocol stack and target protocol parameters corresponding to the target communication scenario are determined. The preset communication scenario and communication protocol stack mapping table achieves precise matching between the target communication scenario and the target protocol stack, clearly defining specific communication parameters, avoiding blind protocol selection, and ensuring data transmission performance is adapted to the communication scenario. Based on the target communication protocol stack and target protocol parameters, the system checks if a target communication instance has already been created in the local instance pool. It prioritizes detecting and reusing existing local communication instances to avoid duplicate instance creation and plugin loading, reducing system resource consumption and improving communication request response efficiency. If a target communication instance already exists in the local instance pool, it is acquired. A usable instance is directly acquired and delivered to the upper-layer module, eliminating the time-consuming process of plugin loading and instance creation, reducing the usage cost of business modules, and supporting efficient collaborative communication among multiple modules in intelligent driving. If a target communication instance does not exist in the local instance pool, based on the target communication protocol stack, the system checks if the target plugin corresponding to the target communication protocol stack and the corresponding communication instance creator exist in the locally loaded plugin list. After instance reuse fails, priority is given to checking locally loaded plugins to avoid resource consumption and time consumption caused by repeated plugin loading, thus improving the creation efficiency of the target communication instance. If the target plugin and its corresponding communication instance creator exist in the locally loaded plugin list, the target communication instance is created based on the communication instance creator, and the plugin reference count of the target plugin is incremented by 1. The target communication instance is quickly generated using the communication instance creator of the loaded plugin, and the plugin reference count marks the dependency status of the target plugin, providing a basis for the safe uninstallation of subsequent plugins and ensuring controllable system resources. If the target plugin and its corresponding communication instance creator do not exist in the locally loaded plugin list, the plugin configuration file corresponding to the target plugin is obtained based on the target communication protocol stack. Accurately locating the plugin configuration file through the protocol stack provides a standardized basis for subsequent plugin search and loading, avoiding blind plugin searches. Based on the plugin configuration file, the existence of the target plugin corresponding to the configuration file in the plugin repository is checked. The existence and validity of the target plugin in the plugin repository are verified in advance to avoid invalid loading operations and reduce the risk of system malfunctions. If the target plugin exists in the plugin repository, it is loaded, and the corresponding communication instance creator is registered. The plugin reference count of the target plugin is incremented. This enables dynamic on-demand loading of plugins and automatic registration of the creator, while also using the count to mark plugin dependency status, providing support for plugin lifecycle management. The communication instance creator is invoked to generate a target communication instance based on the target protocol parameters. The plugin creator generates communication instances adapted to the target scenario and parameters, ensuring that instance functionality accurately matches business requirements and supports the data transmission and reception needs of upper-layer modules.

[0121] Furthermore, the instance reference count corresponding to the target communication instance is incremented by 1. Available target communication instances from the local instance pool are matched based on the target communication scenario, avoiding duplicate instance creation and plugin loading, reducing system memory and CPU resource consumption, and improving the response speed of communication requests. The instance reference count marks the usage status of the target communication instance; incrementing the count indicates the addition of a user to the target communication, providing a basis for the subsequent "release if no reference" resource reclamation mechanism and preventing instance resource leaks. Directly obtaining communication instances suitable for the scenario and delivering them to upper-layer modules eliminates the need for modules to adapt to protocols, reducing the development and usage costs of business modules and supporting efficient collaboration among multiple modules in the intelligent driving system.

[0122] This embodiment provides a data communication method that can be used with an electronic device. The electronic device can be an electronic device in a target vehicle, a mobile terminal, or a server. This application does not specifically limit the type of electronic device. Figure 5 This is a flowchart of a data communication method according to an embodiment of the present invention, such as... Figure 5 As shown, the process includes the following steps: Step S301: Obtain the target data topic deregistration request sent by the target communication module to deregister the target data topic registration request.

[0123] Specifically, a target communication module (such as an autonomous driving decision module) can proactively initiate a target data topic deregistration request. The core content of the target data topic deregistration request includes: the data topic name (such as "lidar_point_cloud") and the initiating module identifier (used for permission verification).

[0124] After receiving the target data topic cancellation request, the communication management module parses out the core fields in the target data topic cancellation request: target data topic name and initiating module ID.

[0125] Then, the communication management module can verify whether the target communication module initiating the deregistration request for the target data topic is a legitimate user of that data topic (whether it is in the instance's "Reference Module List"), and verify whether the data topic name exists (whether it exists in the local instance pool's data topic mapping table). If the verification fails, a "Deregistration Request Invalid" error is returned, and the process is terminated.

[0126] If the verification is successful, the communication management module records the time of the cancellation request for the data topic and the initiating module, leaving a record for subsequent operations.

[0127] Step S302: Locate the target communication instance corresponding to the target data topic registration request.

[0128] Specifically, the communication management module looks up the corresponding target communication instance in the mapping table of the local instance pool based on the target data topic name included in the target data topic registration request. Then, it checks whether the target communication instance is in an "available" state (not occupied by other processes) and whether the target communication module is in the "referenced module list" of the target communication instance (to prevent the module from deregistering instances that it does not reference).

[0129] If the target communication instance is not found, and / or the target communication instance is in an abnormal state, and / or the target communication module does not have reference permissions, the system will return "Target communication instance search failed" and terminate the process.

[0130] If a target communication instance is found and is in an "available" state (not occupied by other processes), and the target communication module is found in the "referenced module list" of the target communication instance, then the target communication instance (handle / pointer) is located, and the referenced module list, current reference count, and other attribute information of the target communication instance are determined.

[0131] Step S303: Call the target communication interface corresponding to the target communication instance to terminate the data transmission and reception of the target communication instance and disconnect the protocol connection.

[0132] Specifically, the communication management module can call the standardized deregistration interface (such as unregister()) of the target communication instance to trigger the protocol layer disconnection logic. The target communication instance can then execute the corresponding disconnection logic based on its own protocol type (the reverse of the initialization logic during creation).

[0133] For example, the disconnection logic for the shared memory protocol is: close the memory read / write handle, release the buffer, and unbind the target data subject from the memory region; the disconnection logic for the Zmq protocol is: close the Zmq socket, disconnect the TCP connection, and clean up the message queue; the disconnection logic for the TCP / IP protocol is: send a disconnection message, close the socket, and release port resources.

[0134] Then, the communication management module changes the status of the target communication instance from "available" to "pending release", prohibiting subsequent data sending and receiving operations.

[0135] Step S304: Decrement the instance reference count corresponding to the target communication instance by 1.

[0136] Specifically, the communication management module reads the current instance reference count (e.g., ref_count=1) from the target communication instance's attributes. Then, it decrements the current instance reference count by 1 (ref_count=ref_count-1). It updates the current instance reference count attribute of the target communication instance and removes the target communication module that initiated the deregistration from the "Reference Module List". Finally, the communication management module outputs the updated instance reference count (e.g., changing from 1 to 0) and the reference module list of the target communication instance after removing the target communication module that initiated the deregistration.

[0137] Step S305: Check whether the instance reference count corresponding to the target communication instance is equal to 0.

[0138] Specifically, the communication management module can read the latest instance reference count of the target communication instance: `int new_ref = target_instance->get_ref_count()`. Then, it determines whether the instance reference count corresponding to the target communication instance is equal to 0. If `new_ref == 0`: execute step S306 (release instance); if `new_ref > 0`: skip S306 and directly execute step S307 (process plugin count).

[0139] Step S306: If the instance reference count is equal to 0, then release the target communication instance.

[0140] Specifically, if the instance reference count is 0, the target communication instance executes its own resource release logic (the reverse of the resource allocation during creation). Then, the target communication instance is removed from the local instance pool's data topic-instance mapping table, along with all attribute records of the instance.

[0141] Next, the destructor of the target communication instance is called to release the space of the target communication instance in the heap memory, and the release time, data subject name, and resource release details of the target communication instance are recorded to facilitate troubleshooting.

[0142] Step S307: Obtain the target plugin corresponding to the target communication instance, and count the plugin reference count of the target plugin under all communication instances.

[0143] Specifically, the target communication module reads the plugin identifier (such as "shm_plugin") from the attributes of the target communication instance, and the plugin management module locates the target plugin based on the identifier. The plugin management module reads the plugin reference count of the target plugin across all communication instances from the "Plugin Reference Count Table".

[0144] Step S308: Decrement the plugin reference count corresponding to the target plugin by 1.

[0145] Specifically, the plugin management module reads the current plugin reference count (e.g., plugin_ref_count=1) corresponding to the target plugin, decrements the current plugin reference count by 1 (plugin_ref_count=plugin_ref_count-1), and then updates the record in the plugin reference count table.

[0146] Step S309: Check if the plugin reference count corresponding to the target plugin is equal to 0.

[0147] Specifically, the plugin management module reads the latest plugin reference count corresponding to the target plugin: `int new_plugin_ref = plugin_mgr->get_plugin_ref_count(plugin_id)`. It then checks if the latest plugin reference count is equal to 0. If `new_plugin_ref == 0`: execute step S310 (release the plugin); if `new_plugin_ref > 0`: the process terminates (the plugin is still depended on by other instances, so the plugin is retained). Step S310: If the plugin reference count is equal to 0, then release the target plugin.

[0148] Specifically, if the plugin reference count is 0, the plugin management module notifies the communication management module to unregister the communication instance creator corresponding to the target plugin. The plugin management module calls the destructor of the target plugin's global object `g_plugin_instance`, which in turn calls the `Release()` method to release the target plugin's internal global resources (such as connection pools and configuration caches). For example, a shared memory plugin releases its global memory management object.

[0149] Then, the plugin management module calls the Linux system function dlclose() to unload the target plugin handle and release the memory occupied by the target plugin. All records for the target plugin are then deleted from the "Loaded Plugins List" and the "Plugin Reference Count Table". Finally, the plugin management module sends a message to the communication management module saying "Target plugin released successfully," and the communication management module ultimately returns "Topic data deregistration successful" to the target communication module.

[0150] The data communication method provided in this application embodiment obtains a target data topic deregistration request sent by a target communication module. It accurately receives the deregistration request from the upper-layer module, serving as the starting point for the resource reclamation process, clearly identifying the target topic to be released, and ensuring the targeted nature of the deregistration operation. It locates the target communication instance corresponding to the target data topic registration request. This quickly identifies the communication instance to be reclaimed, avoiding accidental operation on other instances and ensuring the accuracy of resource reclamation. It calls the target communication interface corresponding to the target communication instance to terminate the data transmission and reception of the target communication instance and disconnect the protocol connection. It proactively terminates the instance's business functions and cuts off the protocol link to prevent data transmission and reception anomalies during the release process, ensuring system communication stability. It decrements the instance reference count corresponding to the target communication instance by 1. This updates the usage status of the target communication instance, providing a counting basis for subsequent judgments on whether to release the instance, supporting fine-grained management of the instance lifecycle. It checks whether the instance reference count corresponding to the target communication instance is equal to 0. It determines whether the target communication instance is still referenced by other modules, avoiding accidental release of occupied target communication instances and ensuring the security of resource reclamation. If the instance reference count is equal to 0, the target communication instance is released. Resource release is performed only on target communication instances that are not referenced, thus avoiding the leakage of system resources such as memory and ports and improving system resource utilization.

[0151] Next, the target plugin corresponding to the target communication instance is obtained, and the plugin reference count of the target plugin under all communication instances is counted. An association between the target communication instance and the target plugin is established to accurately obtain the global dependency status of the target plugin, providing data support for target plugin resource reclamation. The plugin reference count corresponding to the target plugin is decremented by 1. The dependency count of the target plugin is updated to reflect changes in the usage status of the target plugin in real time, providing a basis for subsequent uninstallation decisions. It is checked whether the plugin reference count corresponding to the target plugin is equal to 0. It is determined whether the target plugin has no instance dependencies to avoid mistakenly uninstalling still-in-use plugins and ensure the stability of the system communication link. If the plugin reference count is equal to 0, the target plugin is released. Uninstallation is only performed on target plugins without dependencies, reclaiming the memory and handle resources occupied by the target plugin to avoid dynamic link library resource leaks.

[0152] This embodiment also provides a data communication device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0153] This embodiment provides a data communication device, such as... Figure 6 As shown, it includes: Receiving module 401 is used to receive the target data topic registration request submitted by the target communication module; The lookup module 402 is used to look up the communication configuration file corresponding to the target data topic registration request based on the target data topic registration request. The acquisition module 403 is used to parse the communication configuration file and obtain the target communication instance corresponding to the target data topic registration request; Feedback module 404 is used to feed back the target communication instance to the target communication module so that the target communication module can send and receive target data topics based on the target communication instance.

[0154] The data communication device provided in this embodiment of the invention can execute the data communication method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the various modules and units described above are the same as in the corresponding embodiments described above, and will not be repeated here.

[0155] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0156] The following is a detailed reference. Figure 7 The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 01, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 02 or a program loaded from a memory 08 into a random access memory (RAM) 03. The RAM 03 also stores various programs and data required for the operation of the electronic device. The processor 01, ROM 02, and RAM 03 are interconnected via a bus 04. An input / output (I / O) interface 05 is also connected to the bus 04.

[0157] Typically, the following devices can be connected to I / O interface 05: input devices 06 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 07 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 08 including, for example, magnetic tapes, hard disks, etc.; and communication devices 09. Communication device 09 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 7 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0158] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 09, or installed from memory 08, or installed from ROM 02. When the computer program is executed by processor 01, it performs the functions defined in the data communication method of the embodiments of the present invention.

[0159] Figure 7 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0160] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the data communication methods shown in the above embodiments are implemented.

[0161] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0162] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A data communication method, characterized in that, The method includes: Receive the target data topic registration request submitted by the target communication module; Based on the target data topic registration request, obtain the communication configuration file corresponding to the target data topic registration request; The communication configuration file is parsed to obtain the target communication instance corresponding to the target data topic registration request; The target communication instance is fed back to the target communication module so that the target communication module can send and receive target data topics based on the target communication instance.

2. The method according to claim 1, characterized in that, The step of parsing the communication configuration file to obtain the target communication instance corresponding to the target data topic registration request includes: The communication configuration file is parsed to determine the module deployment relationship and target communication parameters corresponding to the target data topic registration request; Based on the module deployment relationship and target communication parameters, a communication topology diagram corresponding to the target data topic registration request is generated; Based on the communication topology map, the target communication scenario corresponding to the target data topic registration request is determined; Based on the target communication scenario, obtain the target communication instance and increment the instance reference count corresponding to the target communication instance by 1.

3. The method according to claim 2, characterized in that, The step of obtaining the target communication instance based on the target communication scenario includes: Based on a preset communication scenario and communication protocol stack mapping table, the target communication protocol stack and target protocol parameters corresponding to the target communication scenario are determined. Based on the target communication protocol stack and the target protocol parameters, detect whether there is a created target communication instance in the local instance pool; If a target communication instance already exists in the local instance pool, then the target communication instance will be retrieved.

4. The method according to claim 3, characterized in that, The step of obtaining the target communication instance based on the target communication scenario further includes: If the target communication instance does not exist in the local instance pool, then based on the target communication protocol stack, the local loaded plugin list is checked to see if the target plugin corresponding to the target communication protocol stack and the communication instance creator corresponding to the target plugin exist. If the target plugin and the corresponding communication instance creator exist in the list of locally loaded plugins, then the target communication instance is created based on the communication instance creator, and the plugin reference count corresponding to the target plugin is incremented by 1.

5. The method according to claim 4, characterized in that, The step of obtaining the target communication instance based on the target communication scenario further includes: If the target plugin and the corresponding communication instance creator do not exist in the list of locally loaded plugins, then the plugin configuration file corresponding to the target plugin is obtained based on the target communication protocol stack. Based on the plugin configuration file, detect whether the target plugin corresponding to the plugin configuration file exists in the plugin repository; If the target plugin exists in the plugin repository, then load the target plugin and register the communication instance creator corresponding to the target plugin; increment the plugin reference count of the target plugin by 1. The communication instance creator is invoked to generate the target communication instance based on the target protocol parameters.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: Obtain the target data topic deregistration request sent by the target communication module, which is a request to deregister the target data topic registration. Locate the target communication instance corresponding to the target data topic registration request; Invoke the target communication interface corresponding to the target communication instance to terminate the target communication instance. Data transmission and reception, disconnecting protocol connections; Decrement the instance reference count corresponding to the target communication instance by 1. Check if the instance reference count corresponding to the target communication instance is equal to 0; If the instance reference count is equal to 0, then the target communication instance is released.

7. The method according to claim 6, characterized in that, After releasing the target communication instance, the method further includes: Obtain the target plugin corresponding to the target communication instance, and count the plugin reference count of the target plugin under all communication instances; Decrement the plugin reference count corresponding to the target plugin by 1. Check if the plugin reference count corresponding to the target plugin is equal to 0; If the plugin reference count is 0, then the target plugin is released.

8. A data communication device, characterized in that, The device includes: The receiving module is used to receive the target data topic registration request submitted by the target communication module; The lookup module is used to look up the communication configuration file corresponding to the target data topic registration request based on the target data topic registration request. The acquisition module is used to parse the communication configuration file and acquire the target communication instance corresponding to the target data topic registration request; The feedback module is used to feed back the target communication instance to the target communication module, so that the target communication module can send and receive target data topics based on the target communication instance.

9. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the data communication method of any one of claims 1 to 7.

10. A target vehicle, characterized in that, include: The vehicle body and the electronic equipment described in claim 9.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the data communication method according to any one of claims 1 to 7.

12. A computer program product, characterized in that, It includes computer instructions for causing a computer to perform the data communication method according to any one of claims 1 to 7.

Images