Multi-ECU communication method based on temporary conference mechanism and related device

Abstract

The invention provides a multi-ECU communication method based on a temporary conference mechanism and a related device, and the method comprises the steps: receiving a target communication request for a target diagnosis module, the target communication request carrying a target communication demand parameter, and determining m ECUs corresponding to the target communication demand parameter; generating a first temporary conference according to the target communication demand parameter; determining m first diagnosis messages according to the m identification numbers corresponding to the m ECUs; generating m conference invitation commands according to the first conference number and the m identification numbers; determining the ECUs participating in the first temporary conference in the m ECUs according to the m conference invitation commands to obtain n ECUs; determining a second diagnosis message according to the first conference number and the reference diagnosis message; and identifying and analyzing the second diagnosis message through the n ECUs to obtain communication information so as to complete the target communication request. Diagnostic communication is carried out based on the temporary conference, and the communication efficiency among the multiple ECUs is improved.

Description

Technical Field

[0001] This application relates to the field of diagnostic communication technology, and in particular to a multi-ECU communication method and related device based on a temporary conference mechanism. Background Technology

[0002] Currently, diagnostic communication between diagnostic equipment and ECUs, as well as between ECUs themselves, is a one-to-one communication. During communication, the target ECU's identifier can be entered into the diagnostic message and sent to the vehicle's communication bus. However, only the target ECU will receive this diagnostic message; other ECUs cannot. Therefore, when multiple ECUs need to communicate, a large number of messages need to be sent between them, resulting in relatively low diagnostic efficiency.

[0003] Therefore, improving the communication efficiency between multiple ECUs is an urgent problem to be solved. Summary of the Invention

[0004] This application provides a multi-ECU communication method and related apparatus based on a temporary conference mechanism. By dynamically generating temporary conferences and performing diagnostic communication based on these temporary conferences, the communication efficiency between multiple ECUs is improved, facilitating collaborative diagnosis of multiple ECUs.

[0005] In a first aspect, embodiments of this application provide a multi-ECU communication method based on a temporary conference mechanism, the method comprising:

[0006] Receive a target communication request for a target diagnostic module, the target communication request carrying target communication requirement parameters, and determine the m ECUs corresponding to the target communication requirement parameters; m is an integer greater than 1.

[0007] A first temporary conference is generated based on the target communication requirement parameters; the first temporary conference includes a first conference number and first conference parameters;

[0008] Based on the m identifiers corresponding to the m ECUs, m first diagnostic messages are determined; each first diagnostic message corresponds to one identifier.

[0009] Generate m meeting invitation commands based on the first meeting number and the m identifiers;

[0010] Based on the m meeting invitation commands, determine the ECUs from the m ECUs that will participate in the first temporary meeting, resulting in n ECUs; n is a positive integer less than or equal to m;

[0011] The second diagnostic message is determined based on the first conference number and the reference diagnostic message; the reference diagnostic message is any one of the m first diagnostic messages;

[0012] The n ECUs identify and parse the second diagnostic message to obtain communication information in order to complete the target communication request.

[0013] Secondly, embodiments of this application provide a multi-ECU communication device based on a temporary conference mechanism. The device includes a first determining module, a first generating module, a second determining module, a second generating module, a third determining module, a fourth determining module, and a communication center module, wherein:

[0014] The first determining module is configured to receive a target communication request for a target diagnostic module, the target communication request carrying target communication requirement parameters, and determine m ECUs corresponding to the target communication requirement parameters; m is an integer greater than 1.

[0015] The first generation module is used to generate a first temporary conference based on the target communication requirement parameters; the first temporary conference includes a first conference number and first conference parameters;

[0016] The second determining module is used to determine m first diagnostic messages based on the m identifiers corresponding to the m ECUs; each first diagnostic message corresponds to an identifier.

[0017] The second generation module is used to generate m meeting invitation commands based on the first meeting number and the m identifiers;

[0018] The third determining module is used to determine the ECUs participating in the first temporary meeting from among the m ECUs according to the m meeting invitation commands, so as to obtain n ECUs; n is a positive integer less than or equal to m;

[0019] The fourth determining module is used to determine the second diagnostic message based on the first conference number and the reference diagnostic message; the reference diagnostic message is any one of the m first diagnostic messages;

[0020] The communication center module is used to identify and parse the second diagnostic message through the n ECUs to obtain communication information in order to complete the target communication request.

[0021] Thirdly, embodiments of this application provide an electronic device, including a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the programs include instructions for performing steps in any method of the first aspect of this application.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program for electronic data interchange, wherein the computer program causes a computer to perform some or all of the steps described in any method of the first aspect of this application.

[0023] Fifthly, embodiments of this application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps described in any method of the first aspect of this application. The computer program product may be a software installation package.

[0024] By implementing the embodiments of this application, temporary meetings can be dynamically generated, and diagnostic communication can be carried out based on the temporary meetings, which improves the communication efficiency between multiple ECUs and facilitates multi-ECU collaborative diagnosis. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is an application scenario diagram of multi-ECU communication provided in an embodiment of this application;

[0027] Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0028] Figure 3 This is a flowchart illustrating a multi-ECU communication method based on a temporary conference mechanism provided in an embodiment of this application;

[0029] Figure 4 This is a schematic diagram of a process for determining a first diagnostic message provided in an embodiment of this application;

[0030] Figure 5 This is a schematic diagram of the architecture of a first temporary meeting provided in an embodiment of this application;

[0031] Figure 6 This is a schematic diagram of the structure of a diagnostic message provided in an embodiment of this application;

[0032] Figure 7 This is a schematic diagram of a process for identifying and parsing a second diagnostic message provided in an embodiment of this application;

[0033] Figure 8This is a block diagram of the functional modules of a multi-ECU communication device based on a temporary conference mechanism, provided in an embodiment of this application. Detailed Implementation

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

[0035] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0036] It should be understood that the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, "multiple" refers to two or more.

[0037] In the embodiments of this application, "at least one item" or its similar expression refers to any combination of these items, including any combination of a single item or a plurality of items. "One or more" means one or more, while "multiple" means two or more. For example, "at least one item" of a, b, or c can represent the following seven cases: a, b, c; a and b; a and c; b and c; a, b, and c. Each of a, b, and c can be an element or a set containing one or more elements.

[0038] In this application, the term "connection" refers to various connection methods, such as direct connection or indirect connection, to achieve communication between devices. This application does not impose any limitations on this.

[0039] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0040] The following is an explanation of the relevant terms used in this application:

[0041] Electronic Control Unit (ECU): This refers to the core control component of an automotive electronic system. It receives sensor signals, executes preset programs, and outputs control commands to achieve intelligent management and control of various automotive systems.

[0042] Currently, diagnostic communication between diagnostic equipment and ECUs, as well as between ECUs themselves, is a one-to-one communication. During communication, the target ECU's identifier can be entered into the diagnostic message and sent to the vehicle's communication bus. However, only the target ECU will receive this diagnostic message; other ECUs cannot. Therefore, when multiple ECUs need to communicate, a large number of messages need to be sent, resulting in low diagnostic efficiency. Therefore, improving the communication efficiency between multiple ECUs is an urgent problem to be solved.

[0043] To address the aforementioned issues, this application provides a multi-ECU communication method and related apparatus based on a temporary conference mechanism. First, a target communication request for a target diagnostic module is received. The target communication request carries target communication requirement parameters, and m ECUs corresponding to the target communication requirement parameters are determined; m is an integer greater than 1. Then, a first temporary conference is generated based on the target communication requirement parameters. The first temporary conference includes a first conference number and first conference parameters. M first diagnostic messages are determined based on m identifiers corresponding to the m ECUs; each first diagnostic message corresponds to an identifier. Next, m conference invitation commands are generated based on the first conference number and the m identifiers. The ECUs participating in the first temporary conference are determined based on the m conference invitation commands, resulting in n ECUs; n is a positive integer less than or equal to m. A second diagnostic message is determined based on the first conference number and a reference diagnostic message; the reference diagnostic message is any one of the m first diagnostic messages. Finally, the n ECUs identify and parse the second diagnostic message to obtain communication information, thereby completing the target communication request. By dynamically generating temporary meetings and conducting diagnostic communication based on these meetings, the communication efficiency between multiple ECUs is improved, facilitating collaborative diagnostics among multiple ECUs.

[0044] For easier understanding, please refer to Figure 1 , Figure 1 This is an application scenario diagram of multi-ECU communication provided in an embodiment of this application. The target vehicle represents the actual automotive entity that needs diagnosis or control, including all ECUs, the target diagnostic module, and the communication bus. The target diagnostic module can be a diagnostic device or an ECU, without specific limitations. This target diagnostic module is responsible for initiating diagnostic commands, parsing data fed back by the ECUs, sending communication information, and interacting with other ECUs. The communication bus refers to the communication line for data transmission within the target vehicle, enabling the target diagnostic module to exchange instructions and data with each ECU. An ECU refers to the core control module of the target vehicle's electronic system. It can precisely regulate the engine, transmission, and other power systems by monitoring sensor data in real time, optimizing fuel efficiency and emissions; control vehicle electronic devices (such as lights and air conditioning) to improve comfort; support intelligent driving assistance (such as adaptive cruise control and automatic parking); and achieve data interaction between various systems through the communication bus. It also has fault diagnosis functions to ensure the efficient, safe, and intelligent operation of the target vehicle. The first ECU, second ECU, and third ECU represent controllers with different functions; for example, the first ECU is the engine ECU, the second ECU is the door ECU, and the third ECU is the instrument panel ECU, without specific limitations.

[0045] In one possible embodiment, when the target diagnostic module needs to conduct diagnostic communication with the first ECU, second ECU, and third ECU, a temporary conference can be created, and a unique conference number can be generated. Then, a conference invitation command can be sent to the ECUs that want to participate in the temporary conference. After receiving the conference invitation command, the ECUs that agree to join will record the conference number. Finally, when the target diagnostic module sends diagnostic messages to the first ECU, second ECU, and third ECU, it can directly use the conference number as the identifier of the first ECU, second ECU, and third ECU, thereby ensuring that all ECUs in the temporary conference can receive the diagnostic message once it is sent.

[0046] In the diagnostic scenario, the target diagnostic module sends diagnostic requests (such as reading fault codes and collecting sensor data) to the first ECU, second ECU, and third ECU via the communication bus; the first ECU, second ECU, and third ECU respond to the requests and send status information back to the target diagnostic module. In the control scenario, the target diagnostic module can also issue control commands (such as calibration parameters and activating test modes) to the first ECU, second ECU, and third ECU via the communication bus; the first ECU, second ECU, and third ECU execute these commands and then provide feedback on the results.

[0047] It is evident that by using a temporary conference mechanism for communication, multiple target ECUs can be triggered to respond in parallel at once, improving the communication efficiency between multiple ECUs. Furthermore, by filtering the target ECUs participating in the temporary conference and excluding irrelevant ECUs, the load on the communication bus is reduced, invalid ECU wake-ups are decreased, the sleep time of the target vehicle is extended, and energy consumption is reduced.

[0048] The following is combined Figure 2 The electronic devices in the embodiments of this application will be described. Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 2 As shown, the electronic device includes one or more processors, a memory, a communication interface, and one or more programs. The processor is connected to the memory and the communication interface via an internal communication bus.

[0049] The processor is mainly used for:

[0050] Receive a target communication request for a target diagnostic module, the target communication request carrying target communication requirement parameters, and determine the m ECUs corresponding to the target communication requirement parameters; m is an integer greater than 1.

[0051] A first temporary conference is generated based on the target communication requirement parameters; the first temporary conference includes a first conference number and first conference parameters;

[0052] Based on the m identifiers corresponding to the m ECUs, m first diagnostic messages are determined; each first diagnostic message corresponds to one identifier.

[0053] Generate m meeting invitation commands based on the first meeting number and the m identifiers;

[0054] Based on the m meeting invitation commands, determine the ECUs from the m ECUs that will participate in the first temporary meeting, resulting in n ECUs; n is a positive integer less than or equal to m;

[0055] The second diagnostic message is determined based on the first conference number and the reference diagnostic message; the reference diagnostic message is any one of the m first diagnostic messages;

[0056] The n ECUs identify and parse the second diagnostic message to obtain communication information in order to complete the target communication request.

[0057] The one or more programs are stored in the aforementioned memory and configured to be executed by the aforementioned processor, and the one or more programs include instructions for performing any step in the above method embodiments.

[0058] The processor can be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, cells, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc. The communication unit can be a communication interface, transceiver, transceiver circuitry, etc., and the storage unit can be a memory.

[0059] The memory can be volatile or non-volatile, or a combination of both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0060] It is understood that the electronic device may include more or fewer structural elements than those shown in the block diagram above, such as a power module, physical buttons, a Wi-Fi module, a speaker, a Bluetooth module, sensors, a display module, etc., without limitation. It is understood that this electronic device can be applied to, for example... Figure 1 The scenario described.

[0061] After understanding the software and hardware architecture of this application, the following will be combined with... Figure 3 This application describes a multi-ECU communication method based on a temporary conference mechanism. Figure 3 This is a flowchart illustrating a multi-ECU communication method based on a temporary conference mechanism provided in an embodiment of this application, specifically including the following steps:

[0062] Step S301: Receive a target communication request for the target diagnostic module. The target communication request carries target communication requirement parameters. Determine the m ECUs corresponding to the target communication requirement parameters.

[0063] Where m is an integer greater than 1, after receiving a target communication request for the target diagnostic module, the target communication requirement parameters carried in the target communication request are parsed to determine the corresponding m ECUs. These target communication requirement parameters include, but are not limited to, diagnostic type, data range, and priority, which are not specifically limited here. For example, when the diagnostic type of the target communication requirement parameters is "powertrain fault," the data range is "engine speed, transmission gear," and the priority is "emergency," then the engine ECU and transmission ECU can be matched first, while irrelevant ECUs such as the body ECU and entertainment system ECU can be filtered out.

[0064] Step S302: Generate a first temporary conference based on the target communication requirement parameters.

[0065] The first temporary conference includes a first conference number and first conference parameters. The specific steps for generating the first temporary conference based on the target communication requirements include:

[0066] A1. Analyze the target communication requirement parameters to obtain the first conference type;

[0067] A2. Determine the current timestamp corresponding to the target communication requirement parameters;

[0068] A3. Determine the first prefix identifier corresponding to the first meeting type based on the preset mapping relationship between meeting types and prefix identifiers;

[0069] A4. Obtain a reference random number of a preset length;

[0070] A5. Determine the reference meeting number based on the current timestamp and the reference random number;

[0071] A6. Determine the first conference number based on the first prefix identifier and the reference conference number;

[0072] A7. Determine the first meeting parameters according to the first meeting type;

[0073] A8. Generate the first temporary meeting based on the first meeting number and the first meeting parameters.

[0074] In a specific embodiment, firstly, the target communication requirement parameters are analyzed. Based on the diagnostic type of the target communication requirement parameters, the basic type of the meeting is determined. Then, based on its data range, the scope of participation in the meeting is determined. Finally, based on its priority, the urgency level of the meeting is determined. Next, the first meeting type is determined based on the basic type, scope of participation, and urgency level. For example, when the basic type is "rapid diagnosis," the scope of participation is "whole vehicle," and the urgency level is "routine," then the first meeting type is "rapid diagnosis - whole vehicle - routine."

[0075] Then, the current timestamp corresponding to the target communication requirement parameters can be obtained through the target diagnostic module, and the first prefix identifier corresponding to the first conference type can be determined according to the preset mapping relationship between conference type and prefix identifier. For example, when the first conference type is "Quick Diagnosis - Full Vehicle - Regular", the corresponding first prefix identifier is "0X20", which is usually 1 byte long and is not specifically limited here. Then, a reference random number of preset length is generated through a random number generator, where the preset length can be 8 bytes or 4 bytes, and is not specifically limited here. Then, the current timestamp and the reference random number are concatenated to obtain the reference conference number. Then, the first prefix identifier and the reference conference number are concatenated to obtain the first conference number.

[0076] Finally, the first meeting parameters are determined based on the first meeting type. These parameters include, but are not limited to, meeting timeout duration and meeting security level, and are not specifically limited here. Then, a first temporary meeting is generated based on the first meeting number and the first meeting parameters.

[0077] It is evident that by dynamically adapting the target communication requirement parameters to the conference type, diagnostic efficiency and resource utilization can be maximized, and the reliability and security of multi-ECU collaboration can be ensured by using a unique conference number and standardized parameter structure.

[0078] Step S303: Determine m first diagnostic messages based on the m identifiers corresponding to the m ECUs.

[0079] For easier understanding, please refer to Figure 4 , Figure 4This is a flowchart illustrating a method for determining a first diagnostic message according to an embodiment of this application. Each first diagnostic message corresponds to an identifier. The specific steps for determining m first diagnostic messages based on the m identifiers corresponding to the m ECUs include:

[0080] B1. Determine m first identification fields based on the m identification numbers; each first identification field corresponds to one identification number;

[0081] B2. Determine the first type field based on the first meeting type;

[0082] B3. Combine each of the m first identifier fields with the first type field to obtain the m first diagnostic messages.

[0083] In a specific embodiment, firstly, each of the m identifiers is converted into a corresponding logical address field, resulting in m first identifier fields. Each first identifier field corresponds to one identifier, ensuring accurate addressing of the target ECU and avoiding broadcast storms or address conflicts. Then, the first conference type is converted into a corresponding first type field. Finally, each of the m first identifier fields is combined with the first type field according to a preset field alignment method, resulting in m first diagnostic messages. It should be noted that each first diagnostic message includes a first identifier field, a first type field, a data field, and a checksum. The data field and checksum are automatically generated when the first diagnostic message is created. The data field of the first diagnostic message is initially empty and needs to be encoded and filled in later based on communication information. The checksum is used to verify the integrity of the first diagnostic message.

[0084] Step S304: Generate m meeting invitation commands based on the first meeting number and the m identifiers.

[0085] Specifically, according to the protocol specifications, the first conference number is combined with each of the m identifiers to obtain m conference invitation commands. These invitation commands are targeted, ensuring accurate activation of the target ECU and its inclusion in the first temporary conference.

[0086] It is evident that by selectively inviting specific ECUs to join the first ad hoc meeting, efficient management of the ad hoc meeting was achieved, providing a reliable communication bridge for subsequent fault diagnosis and data analysis.

[0087] Step S305: Determine the ECUs from the m ECUs that will participate in the first temporary meeting based on the m meeting invitation commands, thus obtaining n ECUs.

[0088] Where n is a positive integer less than or equal to m, the specific steps of determining the ECUs participating in the first temporary meeting from the m ECUs according to the m meeting invitation commands to obtain n ECUs include:

[0089] C1. Send a reference meeting invitation command to the reference ECU; the reference meeting invitation command is any one of the m meeting invitation commands; the reference ECU is the ECU corresponding to the reference meeting invitation command among the m ECUs;

[0090] C2. The reference ECU responds to the reference conference invitation command and obtains the current status of the reference ECU; the current status includes any one of the following: busy status, idle status;

[0091] C3. If the current state is the idle state, then the reference ECU will provide feedback of agreement information, and the first conference number will be received according to the reference conference invitation command;

[0092] C4. Save the first conference number to the reference ECU to obtain the ECU corresponding to the reference ECU among the n ECUs.

[0093] In a specific embodiment, firstly, a reference meeting invitation command is sent to a reference ECU. This reference meeting invitation command is any one of m meeting invitation commands, and the reference ECU is the ECU corresponding to the reference meeting invitation command among the m ECUs. Then, the reference ECU responds to the reference meeting invitation command and obtains its current state, which can be either busy or idle. A busy state indicates that the ECU is executing a high-priority task or is in another temporary meeting, while an idle state indicates that the ECU has no high-priority task and is not in another temporary meeting. If the current state is idle, the reference ECU sends back an agreement message and receives the first meeting number according to the reference meeting invitation command. Finally, the first meeting number is saved to the reference ECU, thus obtaining the ECU corresponding to the reference ECU among the n ECUs.

[0094] It should be noted that when a rejection message is received from the ECU or the response time exceeds a preset first response time threshold, the ECU is determined to be in a busy state. When an acceptance message is received from the ECU and the response time does not exceed a preset second response time threshold, the ECU is determined to be in an idle state. The first response time threshold can be 500ms, and the second response time threshold can be 100ms; no specific limitation is made here.

[0095] As can be seen, by sending a meeting invitation command to the reference ECU and obtaining its status, the ECU is only added to the temporary meeting when it is idle. This avoids sending invalid invitations to busy ECUs, reduces waste of communication resources, ensures that the temporary meeting only includes available devices, and improves meeting efficiency. The participating ECUs can be adjusted according to the real-time status to adapt to the status changes of ECUs in the vehicle system that may be caused by task switching (e.g., an ECU becomes idle after completing its current task and can be added to the meeting later).

[0096] For easier understanding, please refer to Figure 5 , Figure 5 This is a schematic diagram of the architecture of a first temporary meeting provided in an embodiment of this application. The target diagnostic module, as the initiator, sends a "meeting invitation command" to the ECU via the communication bus. The ECU, as the receiver, interacts with the target diagnostic module via the communication bus. After receiving the meeting invitation command, it determines its current state (busy / idle). If it is idle, it sends an agreement message and receives and saves the first meeting number to join the first temporary meeting.

[0097] In one possible embodiment, if the target diagnostic module needs to communicate with the first ECU, second ECU, third ECU, and fourth ECU, it generates four reference conference invitation commands and sends them to these ECUs via the communication bus. Since the target diagnostic module does not need to communicate with the fifth ECU, it does not invite it to the first temporary conference, ensuring that only necessary ECU resources are utilized and preventing unrelated ECUs from being occupied, thus guaranteeing the vehicle's basic functions. After receiving the conference invitation commands, the first, second, third, and fourth ECUs obtain the current state of each ECU, resulting in a first state, a second state, a third state, and a fourth state.

[0098] If the first state is busy, a rejection message is sent to the target diagnostic module via the first ECU, and the current state of the first ECU is updated in the first state list. After receiving the rejection message from the first ECU, the target diagnostic module will not send a meeting invitation command to the first ECU. The target diagnostic module can check the first state list at a preset period. If it determines that the current state of the first ECU in the first state list has been updated to idle and the first temporary meeting has not been terminated, it will send a meeting invitation command to that first ECU.

[0099] If the second, third, and fourth states are all idle states, then the second, third, and fourth ECUs send an agreement message to the target diagnostic module. After receiving the agreement message, the target diagnostic module records the second, third, and fourth ECUs in the meeting list. Based on the reference meeting invitation command, the first meeting number is received and saved to the second, third, and fourth ECUs to confirm that the second, third, and fourth ECUs have joined the first temporary meeting.

[0100] As can be seen, during the meeting creation phase, the target diagnostic module generates meeting invitation commands on demand, sending invitations only to necessary ECUs to avoid resource waste. ECUs autonomously decide whether to join the meeting through status detection; busy ECUs prioritize ensuring critical vehicle functions, while idle ECUs participate in diagnostics, ensuring both diagnostic efficiency and driving safety.

[0101] Step S306: Determine the second diagnostic message based on the first conference number and the reference diagnostic message.

[0102] Wherein, the reference diagnostic message is any one of the m first diagnostic messages, and the specific steps for determining the second diagnostic message based on the first conference number and the reference diagnostic message include:

[0103] D1. Determine the first data format of the reference diagnostic message;

[0104] D2. Identify the reference diagnostic message according to the first data format to obtain the reference identifier field and the reference type field;

[0105] D3. Replace the identifier corresponding to the reference identifier field with the first conference number to obtain the second identifier field;

[0106] D4. Determine the communication information based on the target communication request;

[0107] D5. Encode the communication information according to the preset encoding rules to obtain the data field;

[0108] D6. Combine the second identifier field, the reference type field, and the data field to obtain the second diagnostic message.

[0109] In a specific embodiment, firstly, the first data format of the reference diagnostic message is determined. Different diagnostic message protocol specifications correspond to different data formats, such as the Controller Area Network (CAN) protocol and the Unified Diagnostic Services (UDS) protocol; no specific limitation is made here. Then, the reference diagnostic message is identified according to the first data format to obtain a reference identifier field and a reference type field. The reference identifier field represents the address of the target ECU, and the reference type field represents the diagnostic service type.

[0110] Next, the identifier corresponding to the reference identifier field is replaced with the first conference number to obtain the second identifier field, which is then directed to the first temporary conference instead of the fixed ECU. Then, the communication information is determined based on the target communication request; for example, if the target communication request is "read engine speed," the communication information could be "read" and "engine speed." Finally, the communication information is converted into the corresponding code according to a preset encoding rule to obtain the data field.

[0111] Finally, the second identifier field, reference type field, and data field are combined according to the protocol specifications to obtain the second diagnostic message. It should be noted that the second diagnostic message includes the second identifier field, reference type field, data field, and checksum, which is automatically generated when the second diagnostic message is created. The checksum is used to verify the integrity of the second diagnostic message.

[0112] As can be seen, by replacing the ECU identifier with a conference number, diagnostic messages can be directed to temporary conferences instead of fixed hardware addresses, supporting the dynamic formation of diagnostic networks (such as temporarily waking up multiple ECUs to work together). Data field generation according to preset encoding rules ensures that different ECUs have consistent parsing logic for the same communication information (such as sensor data requests), reducing compatibility issues in cross-system diagnostics. Messages with the same conference number can be recognized by multiple ECUs, enabling data sharing and collaborative analysis (such as the engine ECU and transmission ECU simultaneously responding to driving mode switching requests), significantly improving the flexibility and reliability of the diagnostic process.

[0113] For easier understanding, please refer to Figure 6 , Figure 6 This is a schematic diagram of the structure of a diagnostic message provided in an embodiment of this application. The diagnostic message includes an identifier field, a type field, a data field, and a checksum. The identifier field uniquely identifies the origin of the diagnostic message and typically includes the ECU's identifier or the meeting number of a temporary meeting; the type field defines the diagnostic type of the message; the data field carries the actual diagnostic content or communication information; and the checksum verifies the integrity of the diagnostic message, preventing tampering and packet loss.

[0114] Step S307: The n ECUs identify and parse the second diagnostic message to obtain communication information in order to complete the target communication request.

[0115] For easier understanding, please refer to Figure 7 , Figure 7 This is a schematic diagram illustrating a process for identifying and parsing a second diagnostic message according to an embodiment of this application. Specifically, the step of identifying and parsing the second diagnostic message through the n ECUs to obtain communication information includes:

[0116] E1. Determine the second data format corresponding to the second diagnostic message;

[0117] E2. The first ECU identifies the identification field of the second diagnostic message according to the second data format to obtain the second identification field; the first ECU is any one of the n ECUs;

[0118] E3. If the identifier corresponding to the second identifier field is the first conference number, then the data field of the second diagnostic message is identified according to the second data format to obtain the data field.

[0119] E4. Parse the data field according to the encoding rules to obtain the communication information.

[0120] In a specific embodiment, firstly, the protocol specification followed by the second diagnostic message is identified, and the second data format corresponding to its protocol specification is determined. Then, the first ECU identifies the identification field of the second diagnostic message according to the second data format, down to the second identification field. Here, the first ECU is any one of the n ECUs.

[0121] Next, it is verified whether the second diagnostic message belongs to the first temporary conference, that is, whether the identifier number corresponding to the second identifier field is the first conference number. If the identifier number corresponding to the second identifier field is the first conference number, the data field of the second diagnostic message can be identified according to the second data format to obtain the data field. If the identifier number corresponding to the second identifier field is not the first conference number, the second diagnostic message is discarded and the relevant log is recorded.

[0122] Finally, the data field is parsed according to the encoding rules to obtain the communication information. Based on this communication information, the first ECU is used to perform data queries, parameter configurations, or function control operations. For example, real-time engine speed is collected from sensors or fuel injection parameters are modified; specific limitations are not specified here. The communication information includes, but is not limited to, configuration word information, data query commands, function control commands, and diagnostic log data.

[0123] As can be seen, by identifying the data format of the second diagnostic message, it ensures that different ECUs parse instructions using unified rules, avoiding diagnostic errors caused by format incompatibility. Only messages with the locally stored conference number are parsed, filtering out instructions from other conferences to prevent cross-conference interference. For example, when multiple diagnostic tasks are performed in parallel, this mechanism can prevent ECUs from incorrectly responding to instructions from other conferences, ensuring the accuracy of diagnostic data.

[0124] In one possible embodiment, a termination time is determined based on the first meeting parameters; a termination command is generated based on the termination time and the first meeting number; in response to the termination command, the first meeting number of each of the n ECUs is deleted; and it is determined that the n ECUs have exited the first temporary meeting.

[0125] Specifically, the parameters for the first meeting include the meeting timeout duration, and the termination time is the sum of the creation time of the first temporary meeting and the timeout duration. For example, if the first temporary meeting is created at 14:30:22 and the meeting timeout duration is set to 5000 milliseconds, then the termination time is 14:30:27. It should be noted that when an anomaly is detected during the diagnostic process (such as multiple ECU response timeouts or excessive bus load), the timeout duration can be automatically shortened (e.g., shortened to 50% of the original time), terminating the meeting early to free up resources. Additionally, high-priority meetings (such as emergency fault diagnosis) can be set with shorter timeout durations (e.g., 2000 milliseconds) to ensure rapid response.

[0126] Then, a termination command is generated based on the termination time and the first conference number. Specifically, a termination command is generated at the termination time based on the first conference number. This termination command includes the first conference number, the termination type (e.g., normal termination, abnormal termination), and security verification information. When n ECUs receive the termination command, they respond by parsing the conference number in the command and comparing it with the locally stored first conference number. If a match is found, subsequent operations are executed; otherwise, no action is taken. Then, the security verification code (e.g., digital signature) of the termination command is verified to ensure that the termination command has not been tampered with.

[0127] Finally, delete the first meeting number of each of the n ECUs and return an acknowledgment response to the target diagnostic module, indicating that the first meeting number has been deleted and the resources have been released, thereby confirming that the n ECUs have exited the first temporary meeting.

[0128] It should be noted that if an ECU does not acknowledge the termination command within one second, the target diagnostic module marks the ECU as "abnormal and not exiting," and will not send any further meeting-related commands to it, and the abnormality will be recorded in the log. If a critical system fault is detected (such as a brake ECU malfunction), the regular timeout calculation can be skipped, a termination command can be generated immediately and sent through a high-priority channel to ensure that critical ECUs release resources first. If an ECU loses power during the meeting, all temporary meeting numbers will be automatically cleared upon restart to prevent residual sessions from affecting normal operation.

[0129] As can be seen, the temporary meeting termination mechanism can free up diagnostic resources such as meeting numbers, supporting rapid access to new tasks and improving continuous diagnostic efficiency. Simultaneous exit of multiple ECUs from the temporary meeting ensures communication consistency and avoids protocol conflicts.

[0130] The above primarily describes the solutions of the embodiments of this application from the perspective of the method execution process. It is understood that, in order to achieve the above functions, the electronic device includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments provided herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0131] This application embodiment can divide the electronic device into functional units according to the above method example. For example, each function can be divided into a separate functional unit, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0132] When dividing each function into modules according to its corresponding function. Figure 8 This is a functional block diagram of a multi-ECU communication device based on a temporary conference mechanism provided in an embodiment of this application. The multi-ECU communication device 800 based on the temporary conference mechanism includes a first determining module 810, a first generating module 820, a second determining module 830, a second generating module 840, a third determining module 850, a fourth determining module 860, and a communication center module 870, wherein:

[0133] The first determining module 810 is used to receive a target communication request for a target diagnostic module, the target communication request carrying target communication requirement parameters, and to determine m ECUs corresponding to the target communication requirement parameters; m is an integer greater than 1.

[0134] The first generation module 820 is used to generate a first temporary conference based on the target communication requirement parameters; the first temporary conference includes a first conference number and first conference parameters;

[0135] The second determining module 830 is used to determine m first diagnostic messages based on the m identifiers corresponding to the m ECUs; each first diagnostic message corresponds to an identifier.

[0136] The second generation module 840 is used to generate m meeting invitation commands based on the first meeting number and the m identifiers;

[0137] The third determining module 850 is used to determine the ECUs participating in the first temporary meeting from among the m ECUs according to the m meeting invitation commands, so as to obtain n ECUs; n is a positive integer less than or equal to m;

[0138] The fourth determining module 860 is used to determine the second diagnostic message based on the first conference number and the reference diagnostic message; the reference diagnostic message is any one of the m first diagnostic messages;

[0139] The communication center module 870 is used to identify and parse the second diagnostic message through the n ECUs to obtain communication information in order to complete the target communication request.

[0140] Optionally, in generating the first temporary meeting according to the target communication requirements, the first generation module 820 is specifically used for:

[0141] The target communication requirement parameters are analyzed to obtain the first conference type;

[0142] Determine the current timestamp corresponding to the target communication requirement parameters;

[0143] Based on the preset mapping relationship between meeting types and prefix identifiers, determine the first prefix identifier corresponding to the first meeting type;

[0144] Get a reference random number of a preset length;

[0145] The reference meeting number is determined based on the current timestamp and the reference random number;

[0146] The first conference number is determined based on the first prefix identifier and the reference conference number;

[0147] The first meeting parameters are determined based on the first meeting type;

[0148] The first temporary meeting is generated based on the first meeting number and the first meeting parameters.

[0149] Optionally, in determining the m first diagnostic messages based on the m identifiers corresponding to the m ECUs, the second determining module 830 is specifically used for:

[0150] Based on the m identifiers, m first identifier fields are determined; each first identifier field corresponds to one identifier.

[0151] Determine the first type field based on the first meeting type;

[0152] Each of the m first identifier fields is combined with the first type field to obtain the m first diagnostic messages.

[0153] Optionally, in determining the second diagnostic message based on the first conference number and the reference diagnostic message, the fourth determining module 860 is specifically used for:

[0154] Determine the first data format of the reference diagnostic message;

[0155] The reference diagnostic message is identified according to the first data format to obtain the reference identifier field and the reference type field;

[0156] Replace the identifier corresponding to the reference identifier field with the first meeting number to obtain the second identifier field;

[0157] The communication information is determined based on the target communication request;

[0158] The communication information is encoded according to a preset encoding rule to obtain a data field.

[0159] The second identification field, the reference type field, and the data field are combined to obtain the second diagnostic message.

[0160] Optionally, in the step of identifying and parsing the second diagnostic message through the n ECUs to obtain communication information, the communication center module 870 is specifically used for:

[0161] Determine the second data format corresponding to the second diagnostic message;

[0162] The first ECU identifies the identification field of the second diagnostic message according to the second data format to obtain the second identification field; the first ECU is any one of the n ECUs.

[0163] If the identifier corresponding to the second identifier field is the first conference number, then the data field of the second diagnostic message is identified according to the second data format to obtain the data field.

[0164] The data field is parsed according to the encoding rules to obtain the communication information.

[0165] Optionally, in determining the ECUs participating in the first temporary meeting from the m ECUs based on the m meeting invitation commands, to obtain n ECUs, the third determining module 850 is specifically used for:

[0166] A reference meeting invitation command is sent to a reference ECU; the reference meeting invitation command is any one of the m meeting invitation commands; the reference ECU is the ECU corresponding to the reference meeting invitation command among the m ECUs;

[0167] The reference ECU responds to the reference conference invitation command and obtains the current status of the reference ECU; the current status includes any one of the following: busy status, idle status;

[0168] If the current state is the idle state, then the reference ECU will provide feedback on the agreement information, and the first meeting number will be received according to the reference meeting invitation command;

[0169] The first conference number is saved to the reference ECU to obtain the ECU corresponding to the reference ECU among the n ECUs.

[0170] Optionally, the communication center module 870 is further specifically used for:

[0171] The termination time is determined based on the first meeting parameters;

[0172] A termination command is generated based on the termination time and the first meeting number;

[0173] In response to the termination command, delete the first conference number of each of the n ECUs;

[0174] Determine that the n ECUs exit the first temporary meeting.

[0175] As can be seen, dynamically generating temporary meetings and conducting diagnostic communication based on these meetings improves communication efficiency between multiple ECUs, facilitating collaborative diagnostics across multiple ECUs. During meeting creation, the target diagnostic module generates meeting invitation commands on demand, sending invitations only to necessary ECUs to avoid resource waste. ECUs autonomously decide whether to join the meeting through status detection; busy ECUs prioritize critical vehicle functions, while idle ECUs participate in diagnostics, ensuring both diagnostic efficiency and driving safety. During diagnostic message exchange, a second diagnostic message generated based on the meeting number and reference message standardizes logical addressing and instructions, ensuring different ECUs parse instructions using unified rules and process only messages from their respective meetings, preventing cross-session interference. After parsing the message, the ECU obtains communication information, supporting various diagnostic operations such as data querying and parameter configuration. During meeting termination, the termination time is determined based on meeting parameters, generating a termination command to cause the ECU to delete the meeting number and release resources. This supports emergency termination in abnormal scenarios, preventing prolonged resource occupation and preventing malicious reuse of the meeting number, thus ensuring system security. In terms of resource utilization, this ad hoc meeting mechanism reduces bus load and ECU resource consumption, and improves resource reusability; in terms of diagnostic efficiency, parallel processing of multiple ECUs shortens diagnostic time; in terms of security, it prevents unauthorized command intrusion and protects data privacy; and in terms of flexibility, it can adapt to different vehicle models and diagnostic scenarios, ensuring that diagnostic tasks and basic vehicle functions do not interfere with each other, thus comprehensively improving the reliability and practicality of the diagnostic system.

[0176] It should be noted that the specific implementation of each operation can be described in the corresponding description of the method embodiments shown above. The multi-ECU communication device 800 based on the temporary conference mechanism can be used to execute the method embodiments of this application, and will not be described again here.

[0177] This application also provides a computer-readable storage medium storing a computer program for electronic data interchange, which causes a computer to perform some or all of the steps of any of the methods described in the above method embodiments, wherein the computer includes an electronic device.

[0178] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments. The computer program product may be a software installation package, and the computer may include an electronic device.

[0179] It should be noted that, for the sake of simplicity, the above embodiments are all described as a series of actions. Those skilled in the art should understand that this application is not limited to the described order of actions, as some steps in the embodiments of this application can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions, steps, modules, or units involved are not necessarily essential to the embodiments of this application.

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

[0181] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0182] The steps of the methods or algorithms described in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, electrically erasable programmable read-only memory (EEPROM), registers, hard disk, portable hard disk, read-only optical disk (CD-ROM), or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Furthermore, the ASIC can reside in a terminal device or management device. Alternatively, the processor and storage medium can exist as discrete components in the terminal device or management device.

[0183] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in the embodiments of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0184] The modules / units included in the various devices and products described in the above embodiments can be software modules / units, hardware modules / units, or a combination of both. For example, for devices and products applied to or integrated into a chip, all modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits. For devices and products applied to or integrated into a chip module, all modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The implementation is achieved through a software program that runs on a processor integrated within the chip module. The remaining modules / units (if any) can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into terminal equipment, each of their modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components within the terminal equipment. Alternatively, at least some modules / units can be implemented using a software program that runs on a processor integrated within the terminal equipment, while the remaining modules / units (if any) can be implemented using hardware methods such as circuits.

[0185] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above descriptions are merely specific embodiments of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A multi-ECU communication method based on a temporary conference mechanism, characterized in that, The method includes: Receive a target communication request for a target diagnostic module, the target communication request carrying target communication requirement parameters, and determine the m ECUs corresponding to the target communication requirement parameters; m is an integer greater than 1. A first temporary conference is generated based on the target communication requirement parameters; the first temporary conference includes a first conference number and first conference parameters; Based on the m identifiers corresponding to the m ECUs, m first diagnostic messages are determined; each first diagnostic message corresponds to one identifier. Generate m meeting invitation commands based on the first meeting number and the m identifiers; Based on the m meeting invitation commands, determine the ECUs from the m ECUs that will participate in the first temporary meeting, resulting in n ECUs; n is a positive integer less than or equal to m; The second diagnostic message is determined based on the first conference number and the reference diagnostic message; the reference diagnostic message is any one of the m first diagnostic messages; The n ECUs identify and parse the second diagnostic message to obtain communication information in order to complete the target communication request.

2. The method as described in claim 1, characterized in that, The step of generating a first temporary conference based on the target communication requirements includes: The target communication requirement parameters are analyzed to obtain the first conference type; Determine the current timestamp corresponding to the target communication requirement parameters; Based on the preset mapping relationship between meeting types and prefix identifiers, determine the first prefix identifier corresponding to the first meeting type; Get a reference random number of a preset length; The reference meeting number is determined based on the current timestamp and the reference random number; The first conference number is determined based on the first prefix identifier and the reference conference number; The first meeting parameters are determined based on the first meeting type; The first temporary meeting is generated based on the first meeting number and the first meeting parameters.

3. The method as described in claim 2, characterized in that, The step of determining m first diagnostic messages based on m identifiers corresponding to the m ECUs includes: Based on the m identifiers, m first identifier fields are determined; each first identifier field corresponds to one identifier. Determine the first type field based on the first meeting type; Each of the m first identifier fields is combined with the first type field to obtain the m first diagnostic messages.

4. The method as described in claim 3, characterized in that, The step of determining the second diagnostic message based on the first conference number and the reference diagnostic message includes: Determine the first data format of the reference diagnostic message; The reference diagnostic message is identified according to the first data format to obtain the reference identifier field and the reference type field; Replace the identifier corresponding to the reference identifier field with the first meeting number to obtain the second identifier field; The communication information is determined based on the target communication request; The communication information is encoded according to a preset encoding rule to obtain a data field. The second identification field, the reference type field, and the data field are combined to obtain the second diagnostic message.

5. The method as described in claim 4, characterized in that, The step of identifying and parsing the second diagnostic message through the n ECUs to obtain communication information includes: Determine the second data format corresponding to the second diagnostic message; The first ECU identifies the identification field of the second diagnostic message according to the second data format to obtain the second identification field; the first ECU is any one of the n ECUs. If the identifier corresponding to the second identifier field is the first conference number, then the data field of the second diagnostic message is identified according to the second data format to obtain the data field. The data field is parsed according to the encoding rules to obtain the communication information.

6. The method as described in claim 1, characterized in that, The process of determining the ECUs participating in the first temporary meeting from the m ECUs based on the m meeting invitation commands yields n ECUs, including: A reference meeting invitation command is sent to a reference ECU; the reference meeting invitation command is any one of the m meeting invitation commands; the reference ECU is the ECU corresponding to the reference meeting invitation command among the m ECUs; The reference ECU responds to the reference conference invitation command and obtains the current status of the reference ECU; the current status includes any one of the following: busy status, idle status; If the current state is the idle state, then the reference ECU will provide feedback on the agreement information, and the first meeting number will be received according to the reference meeting invitation command; The first conference number is saved to the reference ECU to obtain the ECU corresponding to the reference ECU among the n ECUs.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: The termination time is determined based on the first meeting parameters; A termination command is generated based on the termination time and the first meeting number; In response to the termination command, delete the first conference number of each of the n ECUs; Determine that the n ECUs exit the first temporary meeting.

8. A multi-ECU communication device based on a temporary conference mechanism, characterized in that, The device includes a first determining module, a first generating module, a second determining module, a second generating module, a third determining module, a fourth determining module, and a communication center module, wherein: The first determining module is configured to receive a target communication request for a target diagnostic module, the target communication request carrying target communication requirement parameters, and determine m ECUs corresponding to the target communication requirement parameters; m is an integer greater than 1. The first generation module is used to generate a first temporary conference based on the target communication requirement parameters; the first temporary conference includes a first conference number and first conference parameters; The second determining module is used to determine m first diagnostic messages based on the m identifiers corresponding to the m ECUs; each first diagnostic message corresponds to an identifier. The second generation module is used to generate m meeting invitation commands based on the first meeting number and the m identifiers; The third determining module is used to determine the ECUs participating in the first temporary meeting from among the m ECUs according to the m meeting invitation commands, so as to obtain n ECUs; n is a positive integer less than or equal to m; The fourth determining module is used to determine the second diagnostic message based on the first conference number and the reference diagnostic message; the reference diagnostic message is any one of the m first diagnostic messages; The communication center module is used to identify and parse the second diagnostic message through the n ECUs to obtain communication information in order to complete the target communication request.

9. An electronic device, characterized in that, include: Processor, memory, communication interface, and one or more programs; The one or more programs are stored in the memory and configured to be executed by the processor, the programs including instructions for performing the steps of the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1-7.

Images