Vehicle ECU diagnosis method, system and device and storage medium

Abstract

The invention discloses a vehicle ECU diagnosis method, system and device and a storage medium, and the method comprises the steps: determining unit information corresponding to each ECU in a plurality of ECUs of a target vehicle, and obtaining a plurality of pieces of unit information; when the diagnosis mode is a batch diagnosis mode, generating a diagnosis task queue according to the multiple pieces of unit information; the multiple ECUs are diagnosed based on a preset diagnosis strategy and the diagnosis task queue, and a first diagnosis result is obtained; when the diagnosis mode is a single diagnosis mode, unit information corresponding to a target ECU is selected from the multiple pieces of unit information, and target unit information is obtained; the target ECU is any one ECU in the plurality of ECUs; and diagnosing the target ECU according to the target unit information to obtain a second diagnosis result. The target vehicle is diagnosed through the two diagnosis modes, and the vehicle ECU diagnosis efficiency can be improved.

Description

Technical Field

[0001] The present application relates to the field of vehicle diagnosis technology, and in particular to a vehicle ECU diagnosis method, system, device and storage medium. Background Art

[0002] As automotive electronic systems become increasingly complex, modern vehicles are generally equipped with more than a dozen electronic control units (ECUs). These ECUs work together to control many key functions of the vehicle, such as the engine, braking system, and body electronics.

[0003] However, with the increase in vehicle ECUs, vehicle ECU diagnosis has also become complicated. Existing ECU diagnostic equipment usually adopts a single-thread operation mode and only supports diagnosis of each ECU one by one. When facing multiple ECUs, the diagnostic time will be greatly extended, thereby reducing the diagnostic efficiency.

[0004] Therefore, how to improve the diagnostic efficiency of vehicle ECU has become an urgent problem to be solved. Summary of the Invention

[0005] The embodiments of the present application provide a vehicle ECU diagnostic method, system, device and storage medium, which improve the vehicle ECU diagnostic efficiency by quickly screening the target vehicle, accurately diagnosing the faulty ECU, and finally performing closed-loop verification of the repair effect.

[0006] In a first aspect, an embodiment of the present application provides a vehicle ECU diagnostic method, which is applied to a diagnostic device, wherein the diagnostic device is communicatively connected to a target vehicle; the method includes:

[0007] Determining unit information corresponding to each of the multiple ECUs of the target vehicle to obtain multiple unit information; each unit information includes: a set of functions to be diagnosed, a communication protocol type, and historical failure rate data;

[0008] When the diagnosis mode is the batch diagnosis mode, generating a diagnosis task queue according to the plurality of unit information;

[0009] diagnosing the plurality of ECUs based on a preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result;

[0010] When the diagnostic mode is the single diagnostic mode, unit information corresponding to a target ECU is selected from the plurality of unit information to obtain target unit information; the target ECU is any one of the plurality of ECUs;

[0011] The target ECU is diagnosed according to the target unit information to obtain a second diagnosis result.

[0012] In a second aspect, an embodiment of the present application provides a vehicle ECU diagnostic system, which is applied to a diagnostic device, wherein the diagnostic device is communicatively connected to a target vehicle; the vehicle ECU diagnostic device includes: a unit information determination module, a diagnostic task queue generation module, a first diagnostic module, an ECU selection module, and a second diagnostic module, wherein:

[0013] The unit information determination module is used to determine the unit information corresponding to each ECU in the multiple ECUs of the target vehicle to obtain multiple unit information; each unit information includes: a set of functions to be diagnosed, a communication protocol type, and historical failure rate data;

[0014] The diagnostic task queue generating module is configured to generate a diagnostic task queue according to the plurality of unit information when the diagnostic mode is the batch diagnostic mode;

[0015] The first diagnostic module is used to diagnose the multiple ECUs based on a preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result;

[0016] The ECU selection module is configured to select unit information corresponding to a target ECU from the plurality of unit information to obtain target unit information when the diagnostic mode is the single diagnostic mode; the target ECU is any one of the plurality of ECUs;

[0017] The second diagnostic module is used to diagnose the target ECU according to the target unit information to obtain a second diagnostic result.

[0018] In a third aspect, an embodiment of the present application provides an electronic device comprising: 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 program includes instructions for executing the steps in the first aspect of the embodiment of the present application.

[0019] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the above-mentioned computer-readable storage medium stores a computer program for electronic data exchange, wherein the above-mentioned computer program enables a computer to execute some or all of the steps described in the first aspect of the embodiment of the present application.

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

[0021] It can be seen that the embodiments of the present application have the following beneficial effects:

[0022] By implementing the embodiments of the present application, the unit information corresponding to each of the multiple ECUs of the target vehicle is determined to obtain multiple unit information; when the diagnostic mode is the batch diagnostic mode, a diagnostic task queue is generated based on the multiple unit information; the multiple ECUs are diagnosed based on the preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result; when the diagnostic mode is the single diagnostic mode, the unit information corresponding to the target ECU is selected from the multiple unit information to obtain target unit information; the target ECU is any one of the multiple ECUs; the target ECU is diagnosed based on the target unit information to obtain a second diagnostic result. It can be seen that the efficient collaboration of vehicle-level batch screening and single-ECU precision diagnosis can improve the efficiency of vehicle ECU diagnosis. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the background technology, the drawings required for use in the embodiments of the present application or the background technology will be described below.

[0024] Figure 1 This is a flow chart of a vehicle ECU diagnostic method provided by an embodiment of the present application;

[0025] Figure 2 is a schematic structural diagram of a diagnostic device provided in an embodiment of the present application;

[0026] Figure 3 This is an application scenario diagram of a parallel diagnosis strategy provided by an embodiment of the present application;

[0027] Figure 4 is a schematic diagram of a fault diagnosis report provided in an embodiment of the present application;

[0028] Figure 5 This is a flow chart of another vehicle ECU diagnostic method provided by an embodiment of the present application;

[0029] Figure 6 This is a schematic diagram of the structure of a vehicle ECU diagnostic system provided by an embodiment of the present application;

[0030] Figure 7 This is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0031] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0032] The terms "first," "second," and the like in the specification and claims of this application and the accompanying drawings are used to distinguish between different objects, not to describe a particular order. Furthermore, the terms "including," "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements but may optionally include steps or elements not listed, or may optionally include other steps or elements inherent to the process, method, product, or apparatus.

[0033] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0034] The following describes the relevant contents, concepts, meanings, technical issues, technical solutions, beneficial effects, etc. involved in the embodiments of this application.

[0035] See Figure 1 , Figure 1 1 is a flow chart of a vehicle ECU diagnostic method provided in an embodiment of the present application. The method is applied to a diagnostic device that is communicatively connected to a target vehicle. The method includes but is not limited to the following steps:

[0036] S101. Determine unit information corresponding to each of a plurality of ECUs of the target vehicle to obtain a plurality of unit information.

[0037] In an embodiment of the present application, the target vehicle includes multiple electronic control units (ECUs), wherein the multiple ECUs may be an engine control unit, a transmission control unit, a body electronic control unit, an anti-lock braking system control unit, an in-vehicle infotainment system control unit, etc., which cover core electronic systems such as vehicle powertrain, chassis control, body electronics and intelligent networking.

[0038] In the embodiment of the present application, each unit of information includes: a set of functions to be diagnosed, a communication protocol type, and historical failure rate data.

[0039] Among them, the set of functions to be diagnosed refers to the diagnostic service combination preset for each ECU, which may include: configuration writing, writing VIN, reading VIN, action testing, clearing fault codes, and parameter configuration waiting for diagnosis functions.

[0040] The communication protocol type refers to the protocol standard followed when the ECU communicates with the diagnostic equipment. Common types include CAN (Controller Area Network), LIN (Local Interconnect Network), K-Line, FlexRay, and others, but are not limited here. Different ECUs typically use different communication protocols. For example, the engine control unit typically uses the high-speed CAN protocol, while the in-vehicle infotainment system control unit typically uses the LIN protocol.

[0041] Historical failure rate data refers to the probability of failure of the to-be-diagnosed functions of multiple ECUs in the target vehicle. For example, the probability of failure of the parameter configuration to-be-diagnosed function of the in-vehicle infotainment system control unit is 25%.

[0042] See Figure 2 , Figure 2 This is a structural diagram of a diagnostic device provided in an embodiment of the present application. As shown in the figure, the diagnostic device includes: a communication module, a processing module, a storage module, a human-computer interaction module, and a power management module.

[0043] The communication module enables physical connection and data exchange with the vehicle's ECU and consists of a hardware interface unit and a protocol processing unit. The hardware interface unit supports physical layer connections for OBD-II interfaces and communication protocols such as CAN, LIN, and K-Line. The protocol processing unit includes a pre-set communication protocol library covering multiple communication protocol types. The protocol processing unit can dynamically load the corresponding driver based on the target ECU's communication protocol type to implement protocol parsing and data encapsulation of diagnostic instructions.

[0044] The processing module is the computing core of the diagnostic equipment. It can analyze the vehicle ECU data in the storage module and determine the corresponding diagnostic strategy. When diagnosing the vehicle ECU, it can parse the ECU unit information and run the difference data analysis algorithm to locate the fault. It can also train the machine learning model based on the historical diagnostic log for fault prediction.

[0045] The storage module can store real-time diagnostic data and diagnostic task queues to ensure that the processing module can quickly access data. The storage module can also store vehicle configuration databases, historical diagnostic logs and other data.

[0046] The human-computer interaction module provides an interactive interface between the user and the diagnostic equipment, including a touchscreen display and status indicator lights. The touchscreen supports gestures and can display diagnostic process progress, data visualization charts, and repair recommendation reports. It also displays shortcut keys such as "batch diagnostic mode," "single diagnostic mode," and "mode switching" to facilitate user convenience. The status indicator lights provide real-time feedback on the operating status of the diagnostic equipment (e.g., communication connection, diagnosis in progress, fault warnings) through different colors (e.g., red, yellow, green) and flashing frequencies.

[0047] The power management module can provide stable power supply and supports dual modes of power supply from the OBD interface and external power adapter.

[0048] In a specific embodiment, unit information corresponding to each ECU in multiple ECUs of the target vehicle is determined to obtain multiple unit information. Specifically, after the diagnostic device establishes a connection with the target vehicle through the OBD-II interface, the ECU configuration list of the vehicle can be retrieved from the background database of the target vehicle. The ECU configuration list includes multiple ECUs, such as engine ECU, transmission ECU, etc. Each ECU is associated with its corresponding set of functions to be diagnosed, communication protocol type and historical failure rate data.

[0049] For new vehicle models or ECUs with unknown protocols, the diagnostic device can use a multi-protocol polling detection mechanism. The diagnostic device uses its own communication module to sequentially send initialization instructions for protocols in the preset communication protocol library to the target vehicle, and determines the supported protocol type based on the response timeout. For example, it sends an initialization instruction for the CAN protocol to the vehicle infotainment system control unit. After waiting for 50ms without a response, it switches to the LIN protocol. If the vehicle infotainment system control unit returns valid data to the LIN protocol data request, the communication protocol type of the ECU is marked as LIN protocol.

[0050] By determining the unit information corresponding to each of the multiple ECUs of the target vehicle, the ECU's function to be diagnosed, the communication protocol type, and the vehicle's ECU historical failure rate data can be clarified, and the unit information can be used for ECU diagnosis of the target vehicle.

[0051] S102: When the diagnosis mode is the batch diagnosis mode, generate a diagnosis task queue according to the plurality of unit information.

[0052] In the embodiment of the present application, the diagnostic device includes one of the following: a batch diagnostic mode and a single diagnostic mode. The user can select the diagnostic mode through the human-computer interaction module of the diagnostic device.

[0053] Among them, the batch diagnosis mode can perform vehicle-level electronic system detection, and through multi-threaded parallel technology and dynamic resource scheduling, it can perform automatic batch diagnosis of all ECUs configured in the target vehicle; the single diagnosis mode can perform in-depth detection of a single ECU. Users can select the target ECU from the fault list or the full ECU list generated by the batch diagnosis, and call the full function set of the ECU (such as action test, firmware flashing, communication stability test, etc.) for item-by-item verification.

[0054] In a specific embodiment, in batch diagnosis mode, the diagnostic device can generate a diagnostic task queue based on multiple unit information. By generating an efficient and orderly diagnostic task queue, a dynamic balance between risk priority, communication efficiency and system load can be achieved.

[0055] Specifically, ECUs can be initially prioritized based on historical failure rate data. By extracting the fault code frequency and severity weights from each ECU's information and using a weighted summation algorithm to calculate a comprehensive risk value, high-frequency, high-risk ECUs are prioritized in the diagnostic queue. For high-frequency, high-risk ECUs, such as engine and transmission ECUs, their pre-set severity weights are higher than those for low-frequency, low-risk ECUs.

[0056] Next, ECUs can be grouped according to their communication protocol type to optimize bus resource utilization. The diagnostic equipment groups ECUs supporting the same protocol into groups (e.g., CAN, LIN, or K-Line), and employs multi-threaded concurrent technology to generate parallel diagnostic tasks for these ECUs. For example, eight ECUs within a CAN protocol group (e.g., engine, transmission, ABS, etc.) can simultaneously establish communication links using multiple channels of an extended CAN controller. Each channel carries diagnostic instructions for two to three ECUs, eliminating the context switching overhead of cross-protocol communication. Meanwhile, body sensor nodes within the LIN protocol group perform diagnostics sequentially using a master-slave polling mechanism, reducing the probability of bus conflicts.

[0057] Optionally, for each ECU's set of functions to be diagnosed, the diagnostic device can perform task decomposition and logical sequencing. For example, basic diagnostic functions such as fault code reading and real-time parameter sampling can be called first to quickly identify explicit faults. Then, time-consuming operations such as configuration writing and action testing can be performed to avoid blocking the diagnostic process of other ECUs. For functions with dependencies, such as VIN writing, which must first pass the VIN reading verification, sequential execution constraints can be generated to ensure the accuracy of the diagnostic logic. For example, the diagnostic task of the transmission ECU is split into the sequence of "read fault code → sample oil temperature → clear fault code → perform shift test", and the reliability of the diagnostic results is improved through logical sequence control.

[0058] Optionally, the diagnostic device optimizes task execution through a dynamic resource scheduling mechanism. This mechanism monitors bus load and processor utilization in real time. For example, when the CAN bus load exceeds 80%, it automatically postpones bandwidth-intensive parameter flow monitoring tasks and prioritizes lightweight instructions. If a particular ECU experiences multiple consecutive communication timeouts, the task is marked as abnormal and temporarily stored, waiting to be rescheduled after the diagnosis of other ECUs is complete, thus preventing a single node failure from disrupting the overall process. Optimizing task execution through dynamic resource scheduling can improve the stability of the diagnostic device in vehicle ECU diagnosis.

[0059] In one possible embodiment, the generated diagnostic task queue is stored in a priority queue data structure, with each task item containing attributes such as ECU identification, protocol type, task type, priority level, and dependencies. For example, in one optimization strategy, high-priority tasks are prioritized for high-bandwidth channels on the CAN bus, while low-priority configuration writing tasks are scheduled for execution during idle periods on the bus. This creates an optimization strategy that parallelizes basic functions and staggers time-consuming operations, ensuring an efficient and organized diagnostic process.

[0060] Optionally, the above step of generating a diagnostic task queue according to the plurality of unit information may include the following steps:

[0061] A201. Based on the communication protocol types in the plurality of unit information, the plurality of ECUs are divided into at least one initial ECU group; the ECUs in the same initial ECU group use the same communication protocol;

[0062] A202. Sort the ECUs in each of the at least one initial ECU group in a preset order based on the historical failure rate data in the plurality of unit information to obtain at least one ECU group.

[0063] A203. Determine a diagnostic task corresponding to each ECU group in the at least one ECU group to obtain at least one diagnostic task; wherein the diagnostic task represents a function test of a set of to-be-diagnosed functions corresponding to the ECUs in the ECU group;

[0064] A204. Determine a priority order corresponding to the at least one diagnostic task according to the at least one ECU group;

[0065] A205. Determine the diagnostic task queue according to the at least one diagnostic task and the priority order.

[0066] In a specific embodiment, the diagnostic device first parses the communication protocol type contained in each ECU unit's information and, based on the protocol type, maps multiple ECUs to different initial groups, resulting in at least one initial ECU group. For example, engine ECUs, transmission ECUs, and ABS control units that support the CAN protocol are grouped in the CAN group, while door control modules and seat adjustment modules that utilize the LIN protocol are grouped in the LIN group. This grouping strategy, based on the physical and data link layer characteristics of the communication protocol, allows ECUs within the same group to share communication channels, avoiding frequent hardware configuration switching during cross-protocol communication and improving bus utilization. The system allocates a separate communication thread to each initial group, enabling multi-protocol parallel diagnosis.

[0067] Within each initial group, the ECUs in each initial ECU group in at least one initial ECU group can be sorted in a preset order based on the historical failure rate data in multiple unit information to obtain at least one ECU group, wherein the preset order can be the order of the historical failure rate data from high to low.

[0068] Next, by traversing each ECU group, a specific diagnostic task is generated according to its set of functions to be diagnosed. The diagnostic task represents the functional detection of the set of functions to be diagnosed corresponding to the ECUs in the ECU group to determine whether the corresponding functions to be diagnosed of the ECUs are faulty.

[0069] The priority order corresponding to at least one diagnostic task is determined based on at least one ECU group. Subsequently, a diagnostic task queue is determined based on the at least one diagnostic task and the priority order. Each diagnostic task node in the diagnostic task queue may include the following attributes: task ID, ECU group to which it belongs, ID of the function to be diagnosed, priority level, execution condition (such as a predecessor task completion flag), and timeout threshold. The system arranges task nodes from high to low priority, using a first-come, first-served principle for tasks of the same level. The diagnostic task queue supports dynamic adjustment. When a diagnostic task times out or fails, it is automatically moved to the end of the queue and marked with the number of retries to ensure the robustness of the diagnostic process.

[0070] Optionally, the above step of determining the priority order corresponding to the at least one diagnostic task according to the at least one ECU group may include the following steps:

[0071] Determine the resource requirement of the diagnostic task corresponding to each ECU group based on the number of ECUs corresponding to each ECU group in the at least one ECU group and the estimated bus bandwidth required for the communication protocol type corresponding to each ECU group, and obtain at least one resource requirement; determine the priority order based on the at least one resource requirement.

[0072] In a specific embodiment, the resource requirement of each ECU group is calculated. This indicator is determined by the number of ECUs and the estimated bus bandwidth of the communication protocol. For the number of ECUs, the number of ECUs in the group is directly counted. For the estimated bus bandwidth of the communication protocol, a preset benchmark value based on the physical layer characteristics of the protocol type is used. For example, the benchmark bandwidth for the high-speed CAN protocol is 400 kbps, and the benchmark bandwidth for the LIN protocol is 15 kbps. The resource requirement of the diagnostic task corresponding to each ECU group is determined based on the number of ECUs corresponding to each ECU group and the estimated bus bandwidth required by the communication protocol type corresponding to each ECU group. At least one resource requirement is obtained, and a priority order is determined based on the at least one resource requirement.

[0073] Optionally, after obtaining the estimated bus bandwidth, the estimated bus bandwidth can be corrected based on the function correction coefficient, and then the resource requirement can be determined based on the number of ECUs and the corrected estimated bus bandwidth. The function correction coefficient is a dynamic adjustment parameter introduced by the diagnostic equipment to adapt to the differentiated bus bandwidth requirements of the diagnostic function characteristics of different ECUs. It quantitatively analyzes the operation types and data traffic in the set of ECU functions to be diagnosed, and corrects the communication protocol baseline bandwidth to more accurately reflect the actual resource requirements. The function correction coefficient is a dimensionless value with a range of 0.5 to 2.0, which is determined specifically according to the communication load characteristics of the function type. The function correction coefficient can solve the problem of bandwidth estimation deviation under the same protocol and different function scenarios.

[0074] The function correction coefficient is calculated based on the communication characteristics of each operation in the set of functions to be diagnosed and is generated using a weighted average method. First, diagnostic functions are divided into three categories: lightweight operations, medium-weight operations, and heavyweight operations. Lightweight operations refer to operations with small amounts of data, such as fault code reading and simple parameter queries, and their corresponding coefficients can range from 0.8 to 1.0. Medium-weight operations refer to operations involving periodic data transmission or multi-step interactions, such as real-time parameter flow monitoring and action testing, and their corresponding coefficients can range from 1.1 to 1.5. Heavyweight operations refer to operations involving large amounts of data transmission or long-term bus occupancy, such as firmware flashing and batch writing of configuration data, and their corresponding coefficients can range from 1.6 to 2.0.

[0075] Weights are assigned to each function based on its execution frequency in the diagnostic task. The higher the frequency, the greater the weight. For example, the diagnostic task of an ECU includes 30% lightweight operations, 50% medium-weight operations, and 20% heavyweight operations. The function correction coefficient can be determined based on the proportion of each operation and the coefficient corresponding to the operation.

[0076] S103 , diagnose the multiple ECUs based on a preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result.

[0077] In the embodiments of the present application, the preset diagnostic strategy refers to a pre-set diagnostic strategy, which can include a sequential diagnostic strategy and a parallel diagnostic strategy. The sequential diagnostic strategy refers to a single-threaded sequential execution strategy, which is suitable for scenarios where the ECUs of some vehicle models do not support multi-threaded communication and require sequential execution to avoid protocol conflicts, or for high-risk operations such as ECU firmware upgrades and VIN writes. The parallel diagnostic strategy refers to a multi-threaded, protocol-based concurrent strategy, which can perform parallel diagnosis on multiple ECUs simultaneously to shorten the single-vehicle inspection time.

[0078] When selecting a diagnostic strategy, if the target vehicle only supports a single-channel CAN bus, a sequential diagnostic strategy is automatically used. If the target vehicle is equipped with a multi-channel CAN controller and an independent LIN controller, a parallel diagnostic strategy can be enabled. The diagnostic device also provides an interface for manually selecting the strategy, allowing users to freely switch between strategy modes based on diagnostic requirements (such as precise timing control or rapid batch testing).

[0079] In a specific embodiment, multiple ECUs are diagnosed based on a preset diagnostic strategy and a diagnostic task queue to obtain a first diagnostic result. Specifically, during ECU diagnosis, the data returned by each ECU regarding the function to be diagnosed can be compared with standard thresholds in a preset backend database in the diagnostic device, and parameter items that exceed the allowable range can be marked. When an ECU fault is determined to have occurred, the diagnostic device can analyze the fault code and associate the fault description, possible cause, and repair suggestions. Furthermore, the diagnostic device can combine the historical failure rate data of the ECU to perform a risk assessment of the current fault, ultimately obtaining the first diagnostic result. The fault distribution of all ECUs in the vehicle is displayed in the form of a heat map, and the fluctuation of abnormal parameters is compared using trend curves to generate a structured report containing a fault list and repair priority.

[0080] Optionally, the preset diagnostic strategy includes one of the following: a sequential diagnostic strategy and a parallel diagnostic strategy; the above step of diagnosing the multiple ECUs based on the preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result may include the following steps:

[0081] When the preset diagnostic strategy is the sequential diagnostic strategy, the diagnostic task is executed according to the diagnostic task queue to obtain the first diagnostic result.

[0082] The preset diagnosis strategy includes one of the following: sequential diagnosis strategy and parallel diagnosis strategy.

[0083] In a specific embodiment, when the preset diagnostic strategy is a sequential diagnostic strategy, the diagnostic device first retrieves the highest-priority diagnostic task from the head of the diagnostic task queue. This diagnostic task corresponds to a specific ECU group (e.g., the powertrain ECU of the CAN protocol group). By parsing the diagnostic task parameters, namely, the communication protocol type and the set of functions to be diagnosed, the diagnostic task context is initialized, such as configuring the baud rate and frame format of the CAN controller, and the diagnostic task is performed based on this context. After a diagnostic task is completed, subsequent tasks are retrieved in the order of the diagnostic task queue until the diagnostic task queue is completed, and the first diagnostic result can be obtained.

[0084] When executing a diagnostic task for a specific ECU group, the diagnostic device monopolizes the corresponding communication channel until all ECUs in the group have completed testing. For example, in a diagnostic task for a CAN protocol group that includes an engine ECU, a communication session with the engine ECU can be established first, followed by fault code reading, real-time data monitoring, and active testing. During this period, the CAN bus is completely occupied by the diagnostic task, and other protocol groups (such as the LIN bus body module) must wait for resource release, avoiding bus conflicts that may arise from multitasking concurrency. This is suitable for safety-critical systems that require high communication stability, such as brake and steering control modules.

[0085] Within a specific ECU group's diagnostic tasks, each ECU's diagnostic task can be broken down into an ordered chain of subtasks, with the execution results of the preceding tasks directly influencing subsequent operations. For example, the diagnostic process for a transmission ECU could include: basic status query (fault code reading), parameter sampling and analysis, actuation test verification, and configuration parameter verification. This chained execution mechanism ensures the integrity of the diagnostic logic. Furthermore, if the basic status query indicates a fault, subsequent diagnostic processes can be skipped to improve diagnostic efficiency.

[0086] After completing all diagnostic tasks in the diagnostic task queue, the results of each ECU diagnosis can be integrated to generate a fault diagnosis report. The fault diagnosis report may include: fault code analysis, parameter abnormality location, risk classification assessment, etc.

[0087] The sequential diagnosis strategy can improve the reliability and traceability of the diagnostic process through a deterministic task execution mechanism, and is suitable for older vehicle models or systems with poor communication protocol compatibility.

[0088] Optionally, the above step of diagnosing the plurality of ECUs based on a preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result may include the following steps:

[0089] When the preset diagnostic strategy is the parallel diagnostic strategy, corresponding diagnostic threads are allocated according to the number of queue elements in the diagnostic task queue to obtain at least one diagnostic thread; each diagnostic task in the diagnostic task queue is synchronously executed based on the at least one diagnostic thread to obtain the first diagnostic result.

[0090] In a specific embodiment, when the preset diagnostic strategy is a parallel diagnostic strategy, corresponding diagnostic threads are allocated according to the number of queue elements in the diagnostic task queue to obtain at least one diagnostic thread. Then, each diagnostic task in the diagnostic task queue is synchronously executed based on the at least one diagnostic thread to obtain a first diagnostic result. Specifically, since the diagnostic task queue divides ECUs into independent groups according to the communication protocol type, each group corresponds to a unique protocol, and each group corresponds to a diagnostic task, a diagnostic thread is allocated to the diagnostic task. For example, when the diagnostic task queue includes three groups, namely CAN groups, LIN groups, and FlexRay groups, a thread is allocated to each group, forming a total of three parallel execution units, each thread exclusively using the physical communication interface of the corresponding protocol, such as the CAN thread communicating with all ECUs in the group through the CAN controller, and the LIN thread communicating with all ECUs in the group through the LIN controller. Within the same diagnostic task, the same communication protocol is used for ECU diagnosis to avoid performance loss caused by cross-protocol switching.

[0091] After each diagnostic thread is started, the diagnostic tasks corresponding to each diagnostic thread can be executed synchronously. After each diagnostic thread completes the diagnosis of all ECUs in the group, the ECU data collected by different threads can be analyzed and compared to determine the faulty ECU and obtain the first diagnostic result.

[0092] See Figure 3 , Figure 3 This is an application scenario diagram of a parallel diagnostic strategy provided by an embodiment of the present application. As shown in the figure, three diagnostic threads in the thread pool are presented, namely diagnostic thread 1, diagnostic thread 2, and diagnostic thread 3. Among them, diagnostic thread 1 is responsible for the CAN group, which includes the engine ECU, transmission ECU, and ABSECU; diagnostic thread 2 is responsible for the LIN group, involving the door control ECU and seat control ECU; diagnostic thread 3 is responsible for the FlexRay group, including the chassis control ECU. Vehicle ECUs are grouped according to different communication protocols, and each diagnostic thread corresponds to a group. Through multi-threaded parallel processing, ECUs of different communication types can be diagnosed at the same time, improving the efficiency of vehicle ECU diagnosis.

[0093] Optionally, the first diagnostic result includes: a target faulty ECU, a target repair suggestion, and a target fault diagnosis report; and the step of synchronously executing each diagnostic task in the diagnostic task queue based on the at least one diagnostic thread to obtain the first diagnostic result may include the following steps:

[0094] A301, based on the at least one diagnostic thread, obtaining ECU data of each ECU group in the at least one ECU group performing a diagnostic task according to the communication protocol type corresponding to each diagnostic task in the diagnostic task queue, to obtain multiple ECU data;

[0095] A302. Acquire multiple preset reference ECU data corresponding to the multiple ECU data;

[0096] A303, determining a plurality of abnormal parameter deviations based on the plurality of ECU data and the plurality of preset reference ECU data;

[0097] A304. Determine the maximum value among the multiple abnormal parameter deviations to obtain the maximum abnormal parameter deviation;

[0098] A305. Determine the target fault ECU, the target maintenance suggestion, and the target fault diagnosis report based on the maximum abnormal parameter deviation.

[0099] The first diagnostic result includes: target fault ECU, target repair suggestion, and target fault diagnosis report.

[0100] In a specific embodiment, based on at least one diagnostic thread, ECU data of each ECU group in at least one ECU group performing a diagnostic task is obtained according to the communication protocol type corresponding to each diagnostic task in the diagnostic task queue, and multiple ECU data can be obtained.

[0101] Next, multiple preset reference ECU data corresponding to the multiple ECU data are obtained. Specifically, the corresponding preset reference ECU data can be retrieved from a cloud server. The cloud server refers to a server that stores the target vehicle data, and the preset reference ECU data refers to standard values ​​of the function to be diagnosed, for example, an engine idle speed of 800±50rpm, a coolant temperature of 85°C to 105°C, etc. Multiple abnormal parameter deviations are determined based on the multiple ECU data and the multiple preset reference ECU data. The deviations between the ECU data and the preset reference ECU data are determined based on a comparison between the ECU data and the preset reference ECU data, thereby obtaining the multiple abnormal parameter deviations.

[0102] The maximum value among multiple abnormal parameter deviations is determined to obtain the maximum abnormal parameter deviation. Based on the maximum abnormal parameter deviation, the target faulty ECU, target repair recommendation, and target fault diagnosis report can be determined. Specifically, the target faulty ECU can be matched and located based on the maximum abnormal parameter deviation. A target repair recommendation is generated for the target faulty ECU and the maximum abnormal parameter deviation. The target faulty ECU can be repaired based on the target repair recommendation. Finally, all diagnostic information, such as abnormal parameter trend graphs generated during diagnosis, historical fault frequencies, and repair cost estimates, can be integrated to generate a target fault diagnosis report including graphics and text.

[0103] See Figure 4 , Figure 4 This is a schematic diagram of a fault diagnosis report provided by an embodiment of the present application. As shown in the figure, a fault diagnosis report can be displayed in the diagnostic device. The report shows that the fault is located in the engine control unit, the fault code is P0171, and the fault description is that the system is too lean. The possible causes of the fault include insufficient fuel pump pressure and air flow meter signal drift. This fault will cause power loss, increased fuel consumption, and there is also a risk of damage to the three-way catalytic converter. Therefore, in terms of maintenance recommendations, first use a multimeter to check the fuel pump power supply voltage, and secondly, use a special cleaning agent to clean the air flow meter, and the cleaning operation has a higher priority. Finally, a risk level can also be given, such as level B, which is used to indicate that maintenance personnel need to handle it within 48 hours.

[0104] Optionally, after diagnosing the plurality of ECUs based on the preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result, the following steps may be further included:

[0105] B301. Switch the batch diagnosis mode to the single diagnosis mode, repair the target faulty ECU according to the target repair suggestion and the target fault diagnosis report, and obtain a target repair result;

[0106] B302. Switch the single diagnosis mode to the batch diagnosis mode, inspect the target faulty ECU according to the target repair result, and obtain a target inspection result.

[0107] In a specific embodiment, after completing the batch diagnosis of multiple ECUs based on a preset diagnostic strategy and generating a first diagnostic result, the diagnostic device may switch modes to perform maintenance verification.

[0108] First, the batch diagnosis mode is switched to the single diagnosis mode. In this mode, communication resources are exclusively allocated to the target faulty ECU to ensure the reliable transmission of maintenance instructions and the real-time collection of feedback data.

[0109] For faults that can be automatically repaired, such as parameter configuration errors that require adjustment, the diagnostic device can repair the target faulty ECU based on the targeted repair suggestions and targeted fault diagnosis report. For physical faults that require manual intervention, such as a broken sensor line that renders read and write operations invalid, the diagnostic device displays the targeted repair suggestions and targeted fault diagnosis report on the device's touchscreen display, instructing the user to perform repairs and then obtain the repair results.

[0110] After completing the repair operation, the single diagnostic mode is switched back to batch diagnostic mode to quickly inspect multiple ECUs for parameter compliance verification, functional integrity testing, etc., and ultimately obtain the target inspection results.

[0111] After completing batch diagnostics on multiple ECUs, switching to single diagnostics mode allows for targeted repairs on the target faulty ECU. This ensures exclusive resource usage during repairs, allowing maintenance personnel to focus on the target fault point, avoiding interference from other ECUs and improving operational efficiency. After completing repairs, switching back to batch diagnostics mode for a comprehensive inspection further enhances diagnostic accuracy.

[0112] S104 . When the diagnosis mode is the single diagnosis mode, select unit information corresponding to a target ECU from the plurality of unit information to obtain target unit information; the target ECU is any one of the plurality of ECUs.

[0113] In a specific embodiment, when the diagnosis mode is a single diagnosis mode, unit information corresponding to a target ECU is selected from a plurality of unit information to obtain target unit information, wherein the target ECU is any one ECU among the plurality of ECUs.

[0114] Specifically, the diagnostic device can display multiple ECUs of a target vehicle on a touchscreen display. The user can select a target ECU using the ECU selection control on the touchscreen. After determining the target ECU, the user can select the unit information corresponding to the target ECU from the multiple units of information to obtain the target unit information. Based on the target unit information, a targeted diagnosis can be performed on the target ECU.

[0115] When the diagnostic mode is single diagnostic mode, by accurately selecting the unit information of the target ECU, the diagnostic equipment can focus on the functional detection of the specific ECU, avoiding interference from irrelevant ECUs, and improving diagnostic efficiency and accuracy.

[0116] S105 : Diagnose the target ECU according to the target unit information to obtain a second diagnosis result.

[0117] In a specific embodiment, the target unit information includes the target ECU's corresponding set of functions to be diagnosed, the communication protocol type, and historical failure rate data. When diagnosing a target ECU, diagnostic data for the target ECU's set of functions to be diagnosed can be obtained based on the target ECU's corresponding communication protocol type. The target ECU's historical failure rate data can be used as a reference during diagnosis, for example, prioritizing functions with high historical failure rates. Once the diagnostic data is obtained, it can be analyzed to determine the type of fault occurring in the target ECU and generate corresponding repair recommendations and a fault diagnosis report.

[0118] See Figure 5 , Figure 5 This is a flowchart of another vehicle ECU diagnostic method provided by an embodiment of the present application. As shown in the figure, the diagnostic equipment obtains the unit information of each ECU by communicating with the target vehicle, including the set of functions to be diagnosed, the communication protocol type and the historical failure rate data.

[0119] Determine whether the current diagnostic mode is batch diagnostic mode or single diagnostic mode. In batch diagnostic mode, a diagnostic task queue is first generated. It can group the unit information of each ECU according to the communication protocol, sort it based on historical failure rates, and determine the task priority based on resource requirements to finally build the diagnostic task queue.

[0120] Next, the system determines the diagnostic strategy for batch diagnosis mode. If the diagnostic strategy is sequential, diagnostic tasks are executed sequentially in the queue order. If the diagnostic strategy is parallel, multiple threads are allocated and the diagnostic tasks are executed synchronously. During diagnosis, real-time data is compared with reference data to calculate the deviation of abnormal parameters and locate the fault point with the maximum deviation. Ultimately, a first diagnostic result is generated, including the faulty ECU, repair recommendations, and a diagnostic report.

[0121] Based on the repair suggestions of batch diagnosis, switch to single mode to repair the target ECU, and then switch back to batch mode to verify the repair effect, forming a closed loop process of diagnosis, repair and verification to ensure that the fault is completely eliminated.

[0122] In single diagnosis mode, the target ECU data can be filtered from the unit information of batch diagnosis to perform in-depth diagnosis and generate a second diagnosis result, which is suitable for accurately locating single ECU faults.

[0123] Rapid ECU diagnosis based on batch diagnosis mode or targeted ECU diagnosis based on single diagnosis mode enables effective, accurate and efficient diagnosis of vehicle ECUs. It is also suitable for efficient maintenance and troubleshooting of vehicle electronic systems, can quickly locate faults and improve the efficiency of troubleshooting.

[0124] In summary, by implementing the embodiments of the present application, the unit information corresponding to each of the multiple ECUs of the target vehicle can be determined to obtain multiple unit information; when the diagnostic mode is the batch diagnostic mode, a diagnostic task queue is generated based on the multiple unit information; the multiple ECUs are diagnosed based on the preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result; when the diagnostic mode is the single diagnostic mode, the unit information corresponding to the target ECU is selected from the multiple unit information to obtain target unit information; the target ECU is any one of the multiple ECUs; the target ECU is diagnosed based on the target unit information to obtain a second diagnostic result. It can be seen that the efficient collaboration of vehicle-level batch screening and single-ECU precision diagnosis can improve the efficiency of vehicle ECU diagnosis.

[0125] See Figure 6 , Figure 6 : This is a structural diagram of a vehicle ECU diagnostic system provided by an embodiment of the present application. The vehicle ECU diagnostic system is applied to a diagnostic device, and the diagnostic device is communicatively connected to a target vehicle. The vehicle ECU diagnostic system 200 includes: a unit information determination module 201, a diagnostic task queue generation module 202, a first diagnostic module 203, an ECU selection module 204, and a second diagnostic module 205, wherein:

[0126] The unit information determination module 201 is used to determine the unit information corresponding to each ECU in the multiple ECUs of the target vehicle to obtain multiple unit information; each unit information includes: a set of functions to be diagnosed, a communication protocol type, and historical failure rate data;

[0127] The diagnostic task queue generating module 202 is configured to generate a diagnostic task queue according to the plurality of unit information when the diagnostic mode is the batch diagnostic mode;

[0128] The first diagnostic module 203 is used to diagnose the multiple ECUs based on a preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result;

[0129] The ECU selection module 204 is configured to select unit information corresponding to a target ECU from the plurality of unit information to obtain target unit information when the diagnostic mode is the single diagnostic mode; the target ECU is any one of the plurality of ECUs;

[0130] The second diagnosis module 205 is configured to diagnose the target ECU according to the target unit information to obtain a second diagnosis result.

[0131] Optionally, in terms of generating a diagnostic task queue according to the plurality of unit information, the diagnostic task queue generating module 202 is further specifically configured to:

[0132] Based on the communication protocol types in the plurality of unit information, the plurality of ECUs are divided into at least one initial ECU group; the ECUs in the same initial ECU group use the same communication protocol;

[0133] sorting the ECUs in each of the at least one initial ECU group in a preset order according to historical failure rate data in the plurality of unit information to obtain at least one ECU group;

[0134] Determining a diagnostic task corresponding to each ECU group in the at least one ECU group to obtain at least one diagnostic task; wherein the diagnostic task represents a function test of a set of to-be-diagnosed functions corresponding to the ECUs in the ECU group;

[0135] determining a priority order corresponding to the at least one diagnostic task according to the at least one ECU group;

[0136] The diagnostic task queue is determined according to the at least one diagnostic task and the priority order.

[0137] Optionally, in determining the priority order corresponding to the at least one diagnostic task according to the at least one ECU group, the diagnostic task queue generating module 202 is further specifically configured to:

[0138] determining a resource requirement for a diagnostic task corresponding to each ECU group according to the number of ECUs corresponding to each ECU group in the at least one ECU group and an estimated bus bandwidth required for a communication protocol type corresponding to each ECU group, to obtain at least one resource requirement;

[0139] The priority order is determined according to the at least one resource requirement.

[0140] Optionally, the preset diagnostic strategy includes one of the following: a sequential diagnostic strategy and a parallel diagnostic strategy; in diagnosing the multiple ECUs based on the preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result, the first diagnostic module 203 is further specifically configured to:

[0141] When the preset diagnostic strategy is the sequential diagnostic strategy, the diagnostic task is executed according to the diagnostic task queue to obtain the first diagnostic result.

[0142] Optionally, in terms of diagnosing the plurality of ECUs based on a preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result, the first diagnostic module 203 is further specifically configured to:

[0143] When the preset diagnostic strategy is the parallel diagnostic strategy, corresponding diagnostic threads are allocated according to the number of queue elements in the diagnostic task queue to obtain at least one diagnostic thread;

[0144] Each diagnostic task in the diagnostic task queue is synchronously executed based on the at least one diagnostic thread to obtain the first diagnostic result.

[0145] Optionally, the first diagnostic result includes: a target faulty ECU, a target repair suggestion, and a target fault diagnosis report; in terms of synchronously executing each diagnostic task in the diagnostic task queue based on the at least one diagnostic thread to obtain the first diagnostic result, the first diagnostic module 203 is further specifically configured to:

[0146] acquiring, based on the at least one diagnostic thread and according to the communication protocol type corresponding to each diagnostic task in the diagnostic task queue, ECU data of each ECU group in the at least one ECU group performing the diagnostic task, to obtain a plurality of ECU data;

[0147] Acquire a plurality of preset reference ECU data corresponding to the plurality of ECU data;

[0148] determining a plurality of abnormal parameter deviations based on the plurality of ECU data and the plurality of preset reference ECU data;

[0149] Determining a maximum value among the multiple abnormal parameter deviations to obtain a maximum abnormal parameter deviation;

[0150] The target fault ECU, the target maintenance suggestion, and the target fault diagnosis report are determined according to the maximum abnormal parameter deviation.

[0151] Optionally, after diagnosing the plurality of ECUs based on the preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result, the vehicle ECU diagnostic system 200 is further specifically configured to:

[0152] Switching the batch diagnosis mode to the single diagnosis mode, repairing the target faulty ECU according to the target maintenance suggestion and the target fault diagnosis report, and obtaining a target maintenance result;

[0153] The single diagnosis mode is switched to the batch diagnosis mode, and the target fault ECU is inspected according to the target repair result to obtain a target inspection result.

[0154] The vehicle ECU diagnostic system 200 described in this application can determine the unit information corresponding to each of the multiple ECUs of the target vehicle to obtain multiple unit information; when the diagnostic mode is the batch diagnostic mode, a diagnostic task queue is generated based on the multiple unit information; the multiple ECUs are diagnosed based on a preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result; when the diagnostic mode is the single diagnostic mode, the unit information corresponding to the target ECU is selected from the multiple unit information to obtain target unit information; the target ECU is any one of the multiple ECUs; the target ECU is diagnosed based on the target unit information to obtain a second diagnostic result. It can be seen that the efficient collaboration of vehicle-level batch screening and single-ECU precision diagnosis can improve the efficiency of vehicle ECU diagnosis.

[0155] See Figure 7 , Figure 7 : is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. The electronic device may include a processor, a memory, a communication interface, and one or more programs. The processor, memory, and communication interface may be interconnected via a bus. The one or more programs are stored in the memory and configured to be executed by the processor. In the embodiment of the present application, the program includes instructions for performing the following steps:

[0156] Determine unit information corresponding to each of the multiple ECUs of the target vehicle to obtain multiple unit information; each unit information includes: a set of functions to be diagnosed, a communication protocol type, and historical failure rate data;

[0157] When the diagnosis mode is the batch diagnosis mode, generating a diagnosis task queue according to the plurality of unit information;

[0158] diagnosing the plurality of ECUs based on a preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result;

[0159] When the diagnostic mode is the single diagnostic mode, unit information corresponding to a target ECU is selected from the plurality of unit information to obtain target unit information; the target ECU is any one of the plurality of ECUs;

[0160] The target ECU is diagnosed according to the target unit information to obtain a second diagnosis result.

[0161] The electronic device described in this application can determine the unit information corresponding to each of the multiple ECUs of the target vehicle to obtain multiple unit information; when the diagnostic mode is the batch diagnostic mode, generate a diagnostic task queue based on the multiple unit information; diagnose the multiple ECUs based on a preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result; when the diagnostic mode is the single diagnostic mode, select the unit information corresponding to the target ECU from the multiple unit information to obtain target unit information; the target ECU is any one of the multiple ECUs; diagnose the target ECU based on the target unit information to obtain a second diagnostic result. It can be seen that the efficient collaboration of vehicle-level batch screening and single-ECU precision diagnosis can improve the efficiency of vehicle ECU diagnosis.

[0162] An embodiment of the present application also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program for electronic data exchange, and the computer program enables a computer to execute part or all of the steps of any method described in the above method embodiments, and the above computer includes an electronic device.

[0163] The present application also provides a computer program product comprising a non-transitory computer-readable storage medium storing a computer program, wherein the computer program is 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 comprise an electronic device.

[0164] Those skilled in the art will appreciate that all or part of the process steps in the above-described method embodiments can be implemented by a computer program instructing the relevant hardware. The program can be stored in a computer-readable storage medium, and when executed, the program can include the process steps in the above-described 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.

[0165] The steps of the method or algorithm described in the embodiments of the present application can be implemented in hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and storage medium can be located in an ASIC. In addition, the ASIC can be located in a terminal device or a management device. Of course, the processor and storage medium can also be present in a terminal device or a management device as discrete components.

[0166] Those skilled in the art will appreciate that in one or more of the above examples, the functions described in the embodiments of the present application can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, they can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. 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 computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital video disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0167] The modules / units included in the devices and products described in the above embodiments may be software modules / units, hardware modules / units, or partly software modules / units and partly hardware modules / units. For example, for the devices and products applied to or integrated in the chip, the modules / units included therein may all be implemented in the form of hardware such as circuits, or at least part of the modules / units may be implemented in the form of software programs, which run on the processor integrated inside the chip, and the remaining (if any) modules / units may be implemented in the form of hardware such as circuits; for the devices and products applied to or integrated in the chip module, the modules / units included therein may all be implemented in the form of hardware such as circuits, and different modules / units may be located in the same component (such as chip, circuit module, etc.) or different components of the chip module, or at least part of the modules / units may be It is implemented in the form of a software program, which runs on the processor integrated inside the chip module, and the remaining (if any) modules / units can be implemented in the form of hardware such as circuits; for various devices and products applied to or integrated in the terminal equipment, the various modules / units contained therein can be implemented in the form of hardware such as circuits, and different modules / units can be located in the same component (for example, chip, circuit module, etc.) or different components in the terminal equipment, or, at least some modules / units can be implemented in the form of a software program, which runs on the processor integrated inside the terminal equipment, and the remaining (if any) modules / units can be implemented in the form of hardware such as circuits.

[0168] The specific implementation methods described above further illustrate the purpose, technical solutions and beneficial effects of the embodiments of the present application. It should be understood that the above description is only a specific implementation method of the embodiments of the present application and is not intended to limit the scope of protection of the embodiments of the present application. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of the embodiments of the present application should be included in the scope of protection of the embodiments of the present application.

Claims

1. A vehicle ECU diagnostic method, characterized in that: Applied to a diagnostic device, the diagnostic device being communicatively connected to a target vehicle; the method comprising: Determining unit information corresponding to each of the multiple ECUs of the target vehicle to obtain multiple unit information; each unit information includes: a set of functions to be diagnosed, a communication protocol type, and historical failure rate data; When the diagnosis mode is the batch diagnosis mode, generating a diagnosis task queue according to the plurality of unit information; diagnosing the plurality of ECUs based on a preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result; When the diagnostic mode is the single diagnostic mode, unit information corresponding to a target ECU is selected from the plurality of unit information to obtain target unit information; the target ECU is any one of the plurality of ECUs; The target ECU is diagnosed according to the target unit information to obtain a second diagnosis result.

2. The method according to claim 1, wherein Generating a diagnostic task queue according to the plurality of unit information includes: Based on the communication protocol types in the plurality of unit information, the plurality of ECUs are divided into at least one initial ECU group; the ECUs in the same initial ECU group use the same communication protocol; sorting the ECUs in each of the at least one initial ECU group in a preset order according to historical failure rate data in the plurality of unit information to obtain at least one ECU group; Determining a diagnostic task corresponding to each ECU group in the at least one ECU group to obtain at least one diagnostic task; wherein the diagnostic task represents a function test of a set of to-be-diagnosed functions corresponding to the ECUs in the ECU group; determining a priority order corresponding to the at least one diagnostic task according to the at least one ECU group; The diagnostic task queue is determined according to the at least one diagnostic task and the priority order.

3. The method according to claim 2, wherein The determining the priority order corresponding to the at least one diagnostic task according to the at least one ECU grouping includes: determining a resource requirement for a diagnostic task corresponding to each ECU group according to the number of ECUs corresponding to each ECU group in the at least one ECU group and an estimated bus bandwidth required for a communication protocol type corresponding to each ECU group, to obtain at least one resource requirement; The priority order is determined according to the at least one resource requirement.

4. The method according to claim 3, wherein The preset diagnostic strategy includes one of the following: a sequential diagnostic strategy and a parallel diagnostic strategy; and the diagnosing the plurality of ECUs based on the preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result includes: When the preset diagnostic strategy is the sequential diagnostic strategy, the diagnostic task is executed according to the diagnostic task queue to obtain the first diagnostic result.

5. The method according to claim 4, wherein The diagnosing the plurality of ECUs based on the preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result includes: When the preset diagnostic strategy is the parallel diagnostic strategy, corresponding diagnostic threads are allocated according to the number of queue elements in the diagnostic task queue to obtain at least one diagnostic thread; Each diagnostic task in the diagnostic task queue is synchronously executed based on the at least one diagnostic thread to obtain the first diagnostic result.

6. The method according to claim 5, wherein The first diagnostic result includes: a target faulty ECU, a target repair suggestion, and a target fault diagnostic report; and the synchronous execution of each diagnostic task in the diagnostic task queue based on the at least one diagnostic thread to obtain the first diagnostic result includes: acquiring, based on the at least one diagnostic thread and according to the communication protocol type corresponding to each diagnostic task in the diagnostic task queue, ECU data of each ECU group in the at least one ECU group performing the diagnostic task, to obtain a plurality of ECU data; Acquire a plurality of preset reference ECU data corresponding to the plurality of ECU data; determining a plurality of abnormal parameter deviations based on the plurality of ECU data and the plurality of preset reference ECU data; Determining a maximum value among the multiple abnormal parameter deviations to obtain a maximum abnormal parameter deviation; The target fault ECU, the target maintenance suggestion, and the target fault diagnosis report are determined according to the maximum abnormal parameter deviation.

7. The method according to claim 6, wherein After diagnosing the plurality of ECUs based on the preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result, the method further includes: Switching the batch diagnosis mode to the single diagnosis mode, repairing the target faulty ECU according to the target maintenance suggestion and the target fault diagnosis report, and obtaining a target maintenance result; The single diagnosis mode is switched to the batch diagnosis mode, and the target fault ECU is inspected according to the target repair result to obtain a target inspection result.

8. A vehicle ECU diagnostic system, characterized in that: Applied to diagnostic equipment, the diagnostic equipment is connected to the target vehicle in communication; the vehicle ECU diagnostic device includes: a unit information determination module, a diagnostic task queue generation module, a first diagnostic module, an ECU selection module, and a second diagnostic module, wherein, The unit information determination module is used to determine the unit information corresponding to each ECU in the multiple ECUs of the target vehicle to obtain multiple unit information; each unit information includes: a set of functions to be diagnosed, a communication protocol type, and historical failure rate data; The diagnostic task queue generating module is configured to generate a diagnostic task queue according to the plurality of unit information when the diagnostic mode is the batch diagnostic mode; The first diagnostic module is used to diagnose the multiple ECUs based on a preset diagnostic strategy and the diagnostic task queue to obtain a first diagnostic result; The ECU selection module is configured to select unit information corresponding to a target ECU from the plurality of unit information to obtain target unit information when the diagnostic mode is the single diagnostic mode; the target ECU is any one of the plurality of ECUs; The second diagnostic module is used to diagnose the target ECU according to the target unit information to obtain a second diagnostic result.

9. An electronic device, characterized in that: include: a processor, a memory, a 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, wherein the programs include instructions for executing the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program includes program instructions, and when the program instructions are executed by a processor, the processor is caused to perform the method according to any one of claims 1 to 7.

Images