Electronic control unit request task management method and vehicle diagnostic system

Abstract

This application relates to the field of automotive electronic control technology, and in particular to an electronic control unit request task management method and a vehicle diagnostic system. The method includes: obtaining a request-response profile cache record corresponding to each electronic control unit from the request-response profile cache data corresponding to all vehicles, based on the composite identifier of each electronic control unit; receiving a diagnostic job selected by the user, decomposing the diagnostic job into multiple atomic tasks, and allocating a corresponding communication channel to each atomic task; calculating an adaptive timeout threshold corresponding to each electronic control unit based on preset dynamic factors and using the request-response profile cache record, through a timeout decision processing module; encapsulating the request information carried by the corresponding atomic task based on the adaptive timeout threshold; and sending the corresponding request information to the vehicle in parallel through the corresponding communication channels of the atomic tasks of different electronic control units, thereby reducing the false positive rate and improving processing efficiency.

Description

Technical Field

[0001] This application relates to the field of automotive electronic control technology, and in particular to an electronic control unit request task management method and a vehicle diagnostic system. Background Technology

[0002] Within the UDS diagnostic framework, after the diagnostic master control unit (such as a PC-based diagnostic tool or a vehicle-side remote diagnostic module) sends diagnostic requests (such as 0x19 reading fault codes, 0x27 secure access) to each Electronic Control Unit (ECU), a timeout period must be set to determine whether a communication anomaly has occurred in the ECU. This timeout mechanism is a fundamental element in ensuring the controllability and robustness of the diagnostic process.

[0003] Currently, mainstream diagnostic software and tools in the industry (such as Vector CANoe.DiVa, ETAS INCA, and domestic Xentry-like platforms) generally adopt a global static timeout configuration strategy: that is, a fixed timeout threshold is uniformly set for all ECU requests (commonly 2000 ms or 5000 ms), or a few thresholds are preset according to ECU function type (such as powertrain domain, body domain) (e.g., BMS: 1500 ms; sensors: 800 ms). This solution is based on the nominal response time of the ECU datasheet and empirical safety margin settings, and has the advantages of simple implementation and strong compatibility during the development and verification phase.

[0004] However, the aforementioned static timeout mechanism has the following objectively verifiable technical flaws in actual vehicle diagnostic scenarios: 1) Inability to adapt to individual ECU response differences: The response delay of the same model ECU varies significantly under different operating conditions. For example, at an ambient temperature of... At 10℃, a certain BMS module exhibits a measured response delay exceeding 1800 ms due to decreased electrolyte conductivity and reduced MCU clock stability; however, at room temperature (25℃), its typical response is only 600 ms. Using a fixed 1500 ms timeout significantly increases the false positive rate in low-temperature scenarios; increasing it to 2000 ms results in an average wait time of 1400 ms per request at room temperature, leading to decreased diagnostic efficiency. This problem stems from the static threshold failing to reflect the distribution characteristics of the ECU's real-time / historical response behavior.

[0005] 2) Exacerbating multi-channel resource contention and scheduling imbalance: In systems supporting concurrent diagnostics across multiple physical channels such as CAN FD and Ethernet (DoIP), if a low-speed ECU task continuously occupies a channel due to a long timeout, it will block high-priority, short-response tasks within the same channel (such as real-time parameter reading of ADAS domain control 0x22), resulting in a decrease in channel throughput. Conversely, if the timeout is uniformly shortened (e.g., set to 500 ms) to improve efficiency, it is easy to trigger frequent retries for truly slow-response ECUs, increasing bus load and ECU interrupt pressure, forming a negative feedback loop. This problem indicates that existing technologies have not established a dynamic coordination relationship between timeout parameters and channel resource release strategies.

[0006] 3) Lack of context awareness and historical experience reuse capabilities: Current diagnostic software does not collect, store, or model historical response latency data for individual ECUs, nor does it incorporate key operating states affecting response, such as temperature, supply voltage, session mode (Default / Programming), and security level, as correction factors; each vehicle connection starts from a default threshold, making continuous optimization across diagnostic sessions impossible. This deficiency limits the intelligence level of the diagnostic system and fails to meet the evolution requirements of ISO / PAS 21434 for "adaptive cybersecurity monitoring."

[0007] In summary, the existing static, coarse-grained, and memoryless timeout management methods are no longer sufficient to meet the diagnostic needs of new energy vehicles, which require multi-domain integration, high real-time performance, and strong environmental adaptability. Summary of the Invention

[0008] In view of this, embodiments of this application provide an electronic control unit request task management method and a vehicle diagnostic system.

[0009] In a first aspect, embodiments of this application provide an electronic control unit request task management method, applicable to vehicle diagnostic systems, the method comprising: Based on the composite identifier of each electronic control unit, the request and response profile cache record corresponding to each electronic control unit is obtained from the request and response profile cache data corresponding to all vehicles; Receive the diagnostic job selected by the user, decompose the diagnostic job into multiple atomic tasks, and allocate a corresponding communication channel for each atomic task; Based on preset dynamic factors, the adaptive timeout threshold corresponding to each electronic control unit is calculated by using the cached records of each request response profile through the timeout decision processing module. The request information carried by the corresponding atomic task is encapsulated based on the adaptive timeout threshold; The atomic tasks of different electronic control units are used to send corresponding request information to the vehicle in parallel through their respective communication channels.

[0010] In some embodiments, the composite identifier includes the logical address of the electronic control unit and the vehicle type identifier of the corresponding vehicle; The step of retrieving the request-response profile cache record corresponding to each electronic control unit from the request-response profile cache data corresponding to all vehicles based on the composite identifier of each electronic control unit includes: Based on the vehicle type identifier, the request and response profile cache sub-data of the target vehicle corresponding to the target electronic control unit is obtained from the request and response profile cache data of multiple types of vehicles. Based on the logical address, the request response profile cache record is retrieved from the request response profile cache sub-data.

[0011] In some embodiments, the method further includes: When the vehicle diagnostic system connects to the electronic control unit for the first time, the model of the electronic control unit is obtained, and the default value corresponding to the adaptive timeout threshold of the electronic control unit is obtained from the preset timeout threshold dictionary based on the model of the electronic control unit, and used as the current adaptive timeout reference value. Based on the model of the electronic control unit, the logical address of the electronic control unit, the vehicle type identifier of the corresponding vehicle, the constructed historical response latency data, the current adaptive timeout baseline value, and the last update timestamp, a request-response profile cache record of the electronic control unit is created.

[0012] In some embodiments, receiving a diagnostic job selected by the user, decomposing the diagnostic job into multiple atomic tasks, and allocating a corresponding communication channel for each atomic task includes: The task scheduler reads a predefined job configuration table and iterates through each type of electronic control unit and each type of diagnostic service corresponding to each electronic control unit in the job configuration table, generating a corresponding atomic task for each diagnostic service. The corresponding target communication channel is obtained by querying the routing table based on the logical address of each electronic control unit; The atomic tasks corresponding to the electronic control unit are assigned to the corresponding target communication channels.

[0013] In some embodiments, the step of calculating the adaptive timeout threshold corresponding to each electronic control unit based on preset dynamic factors, utilizing the cached records of each request-response profile, and through the timeout decision processing module includes: The timeout decision processing module receives the logical address of the electronic control unit and loads the request-response profile cache record based on the logical address. The timeout decision processing module calculates the basic timeout threshold based on the most recent N historical response delays and preset safety margins in the request-response profile cache record. The timeout decision processing module determines an environmental adjustment coefficient based on the current environmental parameters within the preset dynamic factors, and corrects the basic timeout threshold according to the environmental adjustment coefficient to obtain the adaptive timeout threshold.

[0014] In some embodiments, the atomic tasks of different electronic control units, to send corresponding request information to the vehicle in parallel through their respective communication channels, include: The multiple atomic tasks corresponding to each electronic control unit are sorted in a preset order to obtain the atomic task sequence corresponding to each electronic control unit. The request information of each atomic task in each atomic task sequence is sent to the vehicle through the corresponding communication channel in the preset order.

[0015] In some embodiments, the method further includes: The system receives response information from the electronic control unit based on the request information within the corresponding atomic task, calculates the actual response time of the atomic task based on the response information, and updates the corresponding request-response profile cache record of the electronic control unit.

[0016] In some embodiments, receiving response information from the electronic control unit based on request information within the corresponding atomic task, calculating the actual response time of the atomic task based on the response information, and updating the corresponding request-response profile cache record of the corresponding electronic control unit includes: In response to sending the atomic task, a timer is started; In response to receiving the response information from the request information feedback within the corresponding atomic task, the timer is stopped to obtain the actual response delay; based on a preset update method, the actual response delay is updated in the request response profile cache record corresponding to the electronic control unit.

[0017] In some embodiments, the step of encapsulating the request information carried by the corresponding atomic task based on the adaptive timeout threshold includes: The adaptive timeout threshold of the electronic control unit, as well as at least one of the vehicle model identifier, the logical address of the electronic control unit, the diagnostic service, the communication channel, and the model of the electronic control unit, are encapsulated using a preset data structure to obtain the request information of the corresponding atomic task.

[0018] Secondly, embodiments of this application provide a vehicle diagnostic system, including: The record acquisition module is used to acquire the request and response profile cache record corresponding to each electronic control unit from the request and response profile cache data corresponding to all vehicles based on the composite identifier of each electronic control unit; The task decomposition module is used to receive the diagnostic job selected by the user, decompose the diagnostic job into multiple atomic tasks, and allocate a corresponding communication channel for each atomic task. The adaptive timeout threshold calculation module, based on preset dynamic factors, utilizes the cached records of each request response profile and calculates the adaptive timeout threshold corresponding to each electronic control unit through the timeout decision processing module. The request information encapsulation module is used to encapsulate the request information carried by the corresponding atomic task based on the adaptive timeout threshold; The task execution module is used to send corresponding request information to the vehicle in parallel through the corresponding communication channels via atomic tasks of different electronic control units.

[0019] The embodiments of this application have the following beneficial effects: This application, based on the composite identifier of each electronic control unit (ECU), retrieves the corresponding request-response profile cache record for each ECU from the request-response profile cache data for all vehicles. It receives the diagnostic job selected by the user, decomposes the diagnostic job into multiple atomic tasks, and assigns a corresponding communication channel to each atomic task. Based on preset dynamic factors, and utilizing the request-response profile cache record for each ECU, an adaptive timeout threshold is calculated through a timeout decision processing module. The request information carried by the corresponding atomic task is encapsulated based on the adaptive timeout threshold. The corresponding request information is then sent to the vehicle in parallel through the corresponding communication channels of the atomic tasks of different ECUs. Therefore, this application provides an adaptive timeout threshold for each ECU, offering high flexibility, reducing the false positive rate, and improving the processing efficiency of the vehicle diagnostic system through multi-channel processing. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A flowchart of an electronic control unit request task management method according to an embodiment of this application is shown; Figure 2This paper illustrates a flowchart of querying request-response profile cache records in the electronic control unit request task management method according to an embodiment of this application. Figure 3 This paper illustrates a flowchart of the electronic control unit request task management method for decomposing diagnostic services and allocating communication channels in an embodiment of this application. Figure 4 A flowchart illustrating the calculation of an adaptive timeout threshold in the electronic control unit request task management method according to an embodiment of this application is shown. Figure 5 This paper illustrates a flowchart of an electronic control unit request task management method for executing atomic tasks according to an embodiment of this application. Figure 6 A schematic diagram of a vehicle diagnostic system according to an embodiment of this application is shown.

[0022] Explanation of key component symbols: 610 - Record Acquisition Module; 620 - Task Decomposition Module; 630 - Adaptive Timeout Threshold Calculation Module; 640 - Request Information Encapsulation Module; 650 - Task Execution Module. Detailed Implementation

[0023] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0024] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0025] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0026] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0027] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0028] Therefore, there is an urgent need for a technical solution that can be implemented independently on the vehicle diagnostic system side, without the need for ECU firmware, can model based on the historical response behavior of the ECU and dynamically adjust the timeout threshold by integrating operating environment factors, and can also deeply coordinate with multi-channel task scheduling to improve diagnostic reliability, concurrency efficiency and adaptive evolution capabilities.

[0029] The following describes the electronic control unit request task management method in conjunction with some specific embodiments.

[0030] Figure 1 A flowchart of an electronic control unit requesting task management method according to an embodiment of this application is shown. Exemplarily, the electronic control unit requesting task management method includes the following steps: S100: Based on the composite identifier of each electronic control unit, retrieve the request and response profile cache record corresponding to each electronic control unit from the request and response profile cache data corresponding to all vehicles.

[0031] The request-response profile cache data stores request-response profile cache records for all electronic control units (ECUs) in the vehicle. In other words, the request-response profile cache data includes multiple request-response profile cache records.

[0032] As an example, request-response profile cache data is cached in the local non-volatile memory of the vehicle diagnostic system. For instance, request-response profile cache data is stored in a JSON file in the local non-volatile memory.

[0033] For example, the request-response profile cache record includes the logical address of the electronic control unit, the vehicle type identifier of the corresponding vehicle, historical response latency data, the current adaptive timeout baseline value, the last update timestamp, and the model of the electronic control unit, etc.

[0034] S200: Receive the diagnostic job selected by the user, decompose the diagnostic job into multiple atomic tasks, and allocate a corresponding communication channel for each atomic task.

[0035] S300, based on preset dynamic factors, utilizes the cached records of each request response profile, and calculates the adaptive timeout threshold corresponding to each electronic control unit through the timeout decision processing module.

[0036] S400, based on the adaptive timeout threshold, encapsulate the request information carried by the corresponding atomic task.

[0037] The S500 uses atomic tasks from different electronic control units to send corresponding request information to the vehicle in parallel through their respective communication channels.

[0038] In one implementation, to accurately identify the electronic control unit (ECU), a composite identifier is used in this embodiment. The composite identifier includes the logical address of the ECU and the corresponding vehicle type identifier. For example, if the ECU is a vehicle control unit (VCU), then the corresponding logical address is 0x7E0. The vehicle type identifier uses the vehicle's VIN code.

[0039] like Figure 2 As shown, in step S100, the step of obtaining the request-response profile cache record corresponding to each electronic control unit from the request-response profile cache data corresponding to all vehicles based on the composite identifier of each electronic control unit includes: S110, based on the vehicle type identifier, retrieve the request response profile cache sub-data of the target vehicle corresponding to the target electronic control unit from the request response profile cache data storing multiple types of vehicles.

[0040] S120, based on the logical address, retrieve the request response profile cache record from the request response profile cache sub-data.

[0041] The request-response profile cache data includes multiple request-response profile cache sub-data, and each request-response profile cache sub-data includes multiple request-response profile cache records.

[0042] For example, request-response profile cache data includes, but is not limited to, using a request-response profile cache table.

[0043] Retrieve the request-response profile cache entry carrying the vehicle type identifier from the request-response profile cache table.

[0044] Then, from the request-response profile cache entry carrying the vehicle type identifier, obtain the request-response profile cache entry carrying the logical address to obtain the request-response profile cache record.

[0045] Prior to step S100, the method of this application embodiment further includes: establishing a connection between the vehicle diagnostic system and the vehicle.

[0046] The logical addresses of the aforementioned ECUs, such as 0x7E0 and 0x7E1, belong to the communication layer. The associated Vehicle Identification Number (VIN) is used for vehicle brand isolation. For example, different VIN data can be used to identify different vehicle brands.

[0047] When querying the request-response profile cache record for the electronic control unit, relying solely on the logical address is insufficient. This is because 0x7E0 could represent the engine (ECM) or the transmission (TCM) in different vehicle models, or even different configurations of the same model. If only the logical address is used for querying, the request-response profile cache record corresponding to the engine of vehicle A might be incorrectly identified as the request-response profile cache record for the transmission of vehicle B. Therefore, this embodiment incorporates VIN code locking: the VIN code is the vehicle's identification number. The vehicle diagnostic system first confirms which vehicle is currently connected (e.g., VIN_A), and then searches the request-response profile cache table only for records belonging to VIN_A.

[0048] As an example, when obtaining the request-response profile cache record corresponding to each of the electronic control units in step S100, the specific steps include: S101, When the vehicle diagnostic system connects to the vehicle and is ready to initiate a task, the following logic is executed to distinguish which ECU's request response profile cache record to load.

[0049] S102, Perform vehicle-level isolation, specifically including: 1) Obtaining the vehicle type identifier of the vehicle that has been connected in communication. The vehicle type identifier includes, but is not limited to, the VIN code. For example, after the vehicle diagnostic system starts or successfully connects to the vehicle, it first reads the VIN code of the current vehicle (the vehicle that has been connected in communication) through a diagnostic service (such as ReadDataByIdentifier(0xF190)).

[0050] 2) Loading and filtering cache: Read the local JSON file; perform filtering operations on the JSON file, for example, iterate through all records in the JSON file and keep only the records whose associated vehicle VIN is equal to the current vehicle VIN.

[0051] As a result, only the cached list of ECU request-response profiles belonging to this specific vehicle remains in memory, eliminating interference from data from other vehicles.

[0052] S103, execute the ECU-level positioning request response profile cache record, specifically including: 1) In multi-channel concurrent tasks, when the scheduler needs to send a request to a specific logical address (e.g., 0x7E0), the input target is: the task scheduler issues the instruction: "I want to send a request to address 0x7E0".

[0053] 2) Search Record: The vehicle diagnostic system searches for the request-response profile cache record corresponding to ECU logical address == 0x7E0 in the filtered request-response profile cache record list corresponding to the current vehicle.

[0054] For cases where the request to the electronic control unit is not the first time, the request response profile cache record is retrieved based on the vehicle VIN code and the logical address of the electronic control unit.

[0055] Directly read the historical response latency list and the current adaptive timeout threshold from the request response profile cache record.

[0056] In the case of the first request to the electronic control unit (new user / new ECU), if no request response profile cache record can be found based on the vehicle VIN code and the logical address of the electronic control unit, a new request response profile cache record will be created for that single control unit.

[0057] In one implementation, if no request-response profile cache record corresponding to the target electronic control unit is obtained from the request-response profile cache data corresponding to all vehicles based on the composite identifier of the target electronic control unit, then a request-response profile cache record is created for the target electronic control unit.

[0058] In other words, when the vehicle diagnostic system connects to the electronic control unit for the first time, a request-response profile cache record is created for the electronic control unit.

[0059] For example, when the vehicle diagnostic system is connected to the electronic control unit for the first time, the model of the electronic control unit is obtained, and the default value corresponding to the adaptive timeout threshold of the electronic control unit is obtained from the preset timeout threshold dictionary based on the model of the electronic control unit, and used as the current adaptive timeout reference value. Based on the model of the electronic control unit, the logical address of the electronic control unit, the vehicle type identifier of the corresponding vehicle, the constructed historical response latency data, the current adaptive timeout baseline value, and the last update timestamp, a request-response profile cache record of the electronic control unit is created.

[0060] In other words, the steps to create a new request-response profile cache record for this single control unit include: The secondary confirmation of the electronic control unit model includes: In order to determine the default value of the adaptive timeout threshold (whether it is the BMS or the sensor), the vehicle diagnostic system will immediately initiate a ReadDataByIdentifier (0xF180 / 0xF190) request to the logical address to obtain the specific model / part number of the ECU, which will be used as the model of the electronic control unit.

[0061] Initialization: Based on the identified model, select the default value of the adaptive timeout threshold (e.g., BMS=1500ms) from DEFAULT_TIMEOUT_MAP (preset timeout threshold dictionary), generate a new request-response profile cache record and store it in a JSON file.

[0062] In one implementation, such as Figure 3 As shown, in step S200, receiving the diagnostic job selected by the user, decomposing the diagnostic job into multiple atomic tasks, and allocating a corresponding communication channel for each atomic task includes: S210, the task scheduler reads the predefined job configuration table, and iterates through each type of electronic control unit and each type of diagnostic service corresponding to each electronic control unit in the job configuration table, and generates a corresponding atomic task for each diagnostic service.

[0063] Understandably, the job configuration table includes the types of electronic control units included in the target vehicle and the types of diagnostic services corresponding to each electronic control unit.

[0064] S220: Query the routing table according to the logical address of each electronic control unit to obtain the corresponding target communication channel; S230, the atomic tasks corresponding to the electronic control unit are assigned to the corresponding target communication channels. The core function of the task scheduler is to transform the user's macroscopic "diagnostic tasks" (such as whole vehicle scanning) into microscopic, parallel-executable "atomic task sequences" and to allocate communication resources reasonably.

[0065] The following section, using the specific scenario of "vehicle scanning," provides a detailed analysis of the task scheduler's task decomposition logic and execution process: Core decomposition logic: from "diagnostic tasks" to "atomic tasks"; The task scheduler's decomposition process follows a three-step strategy: "target decomposition -> resource mapping -> dependency sorting". Step 1: Job Decomposition.

[0066] When a user selects "Vehicle Scan", the task scheduler first reads the predefined job configuration table (ScanPlan). This job configuration table defines which ECUs are included in the vehicle and which diagnostic services each ECU needs to perform.

[0067] The input to the task scheduler is: Job type = "Vehicle scan".

[0068] The task scheduler's action is to traverse the list of all target ECUs in the job configuration table (e.g., engine ECM, transmission TCM, battery BMS, airbag ACU, etc., a total of 20 nodes).

[0069] The task scheduler generates atomic tasks: for each ECU, it generates a standard sequence of requests corresponding to each diagnostic service.

[0070] As a result, what was originally a large-scale "whole vehicle scan" diagnostic task was broken down into N ECUs × M diagnostic services = a total of dozens of independent atomic tasks.

[0071] Step 2: Channel Mapping.

[0072] Based on the vehicle's network topology, atomic tasks are assigned to specific physical communication channels. The routing table is queried to determine which physical channel (communication channel) each ECU logical address (e.g., 0x7E0) is mounted on. For example: 0x7E0 (ECM) -> Mapped to CAN1 (Powertrain); 0x7E1 (TCM) -> Mapped to CAN1 (Powertrain); 0x7C0 (BMS) -> Mapped to CAN2 (chassis / high voltage grid); 0x600 (Gateway / Entertainment) -> Mapped to ETH (Ethernet).

[0073] Concurrent queue construction: The task scheduler maintains an independent task queue for each communication channel. For example: Queue_CAN1: [Task_ECM_ReadDTC, Task_TCM_ReadDTC, ...] Queue_CAN2: [Task_BMS_ReadDTC, ...] Queue_ETH: [Task_GW_ReadDTC, ...] Therefore, in this embodiment of the application, the different buses (CAN1, CAN2, ETH) are physically isolated, so the tasks in these three queues can be sent in parallel without blocking each other.

[0074] In one implementation, the request-response profile cache record includes: the logical address of the electronic control unit and historical response latency data (including the most recent N historical response latencies).

[0075] like Figure 4 As shown, it can be understood that in step S300, the step of calculating the adaptive timeout threshold corresponding to each electronic control unit based on preset dynamic factors, utilizing the cached records of each request-response profile, and through the timeout decision processing module, includes: S310, the timeout decision processing module receives the logical address of the electronic control unit and loads the request response profile cache record based on the logical address.

[0076] S320, the timeout decision processing module calculates the basic timeout threshold based on the most recent N historical response delays and preset safety margins in the request-response profile cache record.

[0077] S330, the timeout decision processing module determines the environmental adjustment coefficient based on the current environmental parameters within the preset dynamic factors, and corrects the basic timeout threshold according to the environmental adjustment coefficient to obtain the adaptive timeout threshold.

[0078] When calculating the adaptive timeout threshold for each of the electronic control units, specifically, based on historical timeout delay data and current environmental parameters, the optimal time (T_timeout) for waiting for the ECU (electronic control unit) response is dynamically calculated to balance "diagnostic efficiency" (not wanting to wait too long) and "diagnostic success rate" (not wanting to misjudge failure due to premature timeout).

[0079] For example, a timeout threshold calculation function is defined, taking the ECU's logical address as a parameter. Within this function, the ECU request-response profile cache data is loaded. Historical response latency data for that specific ECU is obtained (including the response latency of the past 30 times, ECU type, etc.). This is the foundation for achieving "adaptive" behavior, meaning the system doesn't apply a one-size-fits-all approach to all ECUs, but rather "tailors its approach to each ECU."

[0080] When the vehicle diagnostic system connects to a vehicle for the first time, or when the ECU is being scanned for the first time, and there is no data in the cache or historical response latency data: Determine if the current ECU has a request-response profile cache record.

[0081] If not, the default value of the preset adaptive timeout threshold is returned from DEFAULT_TIMEOUT_MAP[ecu_type]. This prevents calculation errors due to lack of data. The vehicle diagnostic system uses conservative empirical values ​​(e.g., 1500ms for BMS) based on the known ECU type (such as BMS battery management system, sensors, etc.) to ensure the safety of the first interaction.

[0082] The basic timeout threshold is calculated using the following method: Take the 90th percentile of historical response latency data plus a safety margin (20%), and extract the historical response latency list (e.g., [100ms, 120ms, 150ms, ...]) from the request response profile cache record. Calculate the 90th percentile based on this historical response latency list. In historical data, 90% of request response times are less than this value. The maximum value may be an "outlier" caused by occasional bus congestion or anomalies. Setting the timeout based on the maximum value would lead to extremely low diagnostic efficiency under normal circumstances. The 90th percentile covers the vast majority of normal cases while excluding interference from extreme outliers.

[0083] Even though historical data shows that 90% of cases are completed within X milliseconds, an additional 20% time buffer is reserved to handle minor network fluctuations or computational errors, further reducing the probability of false timeouts. The variable obtained at this point is the statistically optimized base timeout threshold.

[0084] Subsequently, the baseline timeout threshold is dynamically adjusted based on environmental factors, specifically including the following steps: By diagnostically reading the current ambient temperature, if the current ambient temperature is lower than a first temperature value, a correction factor greater than 1 is set (response is slower at low temperatures). The base timeout threshold is then adjusted based on this correction factor to obtain an adaptive timeout threshold. The ECU's processing speed is greatly affected by temperature; at low temperatures, the crystal oscillator frequency may drift or the processor frequency may decrease, leading to a slower response. For example, if the current ambient temperature is less than 10 degrees Celsius, the correction factor is set to 1.3; if it is a low temperature, the base timeout threshold is extended by 30%. This is a dynamic compensation mechanism. In harsh environments, the timeout limit is proactively relaxed to avoid being judged as a fault due to inevitable delays caused by physical characteristics, thus improving the system's robustness under extreme conditions.

[0085] Furthermore, the method in this application embodiment also includes: a boundary restriction strategy (safety clamp).

[0086] The method in this embodiment further determines whether the adaptive response threshold is within a preset reasonable range. For example, the preset reasonable range is (min=300ms, max=5000ms), and a clamping function is used to ensure that the return value is within the interval [min, max].

[0087] The minimum timeout limit is min=300ms to prevent the calculated timeout from being too short (e.g., 60ms) due to excellent historical data (e.g., all 50ms). CAN / Ethernet communication itself has protocol overhead, and an excessively short timeout can easily lead to misjudgments due to minor jitter. 300ms is a bottom line to ensure communication stability.

[0088] The maximum timeout limit is set to 5000ms to prevent excessively long timeouts (e.g., calculated to be 20 seconds) due to data anomalies or extreme environmental compensation. In multi-channel concurrent diagnostics, if one channel is stuck for too long, it will block the entire task scheduling engine and reduce overall efficiency. 5 seconds is usually the user-acceptable waiting limit; exceeding this value typically indicates a genuine ECU failure or bus disconnection, requiring timely error reporting rather than indefinite waiting.

[0089] In one implementation, such as Figure 5 As shown, in step S500, the atomic tasks of different electronic control units, which send corresponding request information to the vehicle in parallel through their respective communication channels, include: S510, sort the multiple atomic tasks corresponding to each electronic control unit in a preset order to obtain the atomic task sequence corresponding to each electronic control unit.

[0090] S520, the request information of each atomic task in each atomic task sequence is sent to the vehicle through the corresponding communication channel according to the preset order.

[0091] Multiple atomic tasks of the same ECU are usually arranged sequentially, while tasks of different ECUs are executed in parallel if they are on different channels.

[0092] In one embodiment, the method further includes: S600, receive the response information fed back by the electronic control unit based on the request information in the corresponding atomic task, and calculate the actual response time of the atomic task based on the response information, and update the corresponding request response profile cache record of the corresponding electronic control unit.

[0093] Further, the step of receiving the response information fed back by the electronic control unit based on the request information within the corresponding atomic task, calculating the actual response time of the atomic task based on the response information, and updating the corresponding request-response profile cache record of the corresponding electronic control unit includes: S610, in response to sending the atomic task, start the timer; S620, in response to receiving the response information of the request information feedback in the corresponding atomic task, the timer ends and the actual response delay is obtained; based on the preset update method, the actual response delay is updated to the request response profile cache record corresponding to the electronic control unit.

[0094] In one implementation, the step of encapsulating the request information carried by the corresponding atomic task based on the adaptive timeout threshold includes: The adaptive timeout threshold of the electronic control unit, as well as at least one of the vehicle model identifier, the logical address of the electronic control unit, the diagnostic service, the communication channel, and the model of the electronic control unit, are encapsulated using a preset data structure to obtain the request information of the corresponding atomic task.

[0095] Dynamic timeout injection – adaptive timeout threshold.

[0096] Before an atomic task officially enters the sending queue, the task scheduler intercepts each atomic task and executes the key steps in the execution plan: The decision module is invoked: `T_timeout = compute_timeout(target_ecu_addr)`; the request packet is encapsulated: the calculated dynamic timeout value `T_timeout` is written into the Task Control Block (TCB). The task structure is: `{ Vehicle VIN ID: 101, Logical Address Addr: 0x7E0, Diagnostic Service: ReadDTC, Communication Channel: CAN1, Adaptive Timeout Threshold Timeout: 1450ms, Status: Pending}`; this ensures that each atomic task has its own dedicated, adaptive waiting time during subsequent execution, instead of using a globally fixed timeout value.

[0097] The method of this application embodiment is described below in conjunction with whole vehicle scanning services: Assume the vehicle network topology is as follows: CAN1 (500kbps): Connects to ECM (0x7E0), TCM (0x7E1) CAN2 (250kbps): Connect to BMS (0x7C0) ETH (100Mbps): Connected to IVI (0x600) User action: Click "Start Vehicle Scan".

[0098] Phase 1: Diagnostic service decomposition and communication channel allocation (completed by the task scheduler).

[0099]

[0100] Multiple atomic tasks of the same ECU are usually arranged sequentially, while atomic tasks of different ECUs are executed in parallel if they are on different communication channels.

[0101] Phase Two: Multi-channel concurrent execution.

[0102] After the task scheduler starts, the execution threads of the three channels work simultaneously: CAN1 thread: Retrieve Task_A (ECM) and send 0x19 02 (ReadDTC).

[0103] Start timer: Set timeout to 1440ms.

[0104] Concurrent behavior: During the 1.4 seconds of waiting for the ECM response, the CAN1 thread cannot send Task_C (because CAN is half-duplex and bus collisions need to be avoided, usually serial on the same channel), but this does not affect other channels.

[0105] CAN2 thread (fully parallel to CAN1): retrieves Task_D (BMS) and sends a request; starts timer: sets timeout to 1950ms (due to long low-temperature compensation); status: at this time, BMS is responding, and ECM is also responding, and the two do not interfere with each other on the physical bus.

[0106] ETH thread (fully parallel to the previous two): retrieves Task_E (IVI) and sends a request; starts a timer: sets the timeout to 300ms; status: due to the extremely high speed and bandwidth of Ethernet, this task may have already completed and returned results while CAN1 and CAN2 are still waiting.

[0107] Phase 3: Results Feedback.

[0108] When an atomic task in a certain channel receives a response (or times out), the status of that atomic task is immediately updated to Success or Timeout; the task scheduler collects the results of all channels; once all queues are cleared, it reports to the user interface: "Vehicle scan complete, X fault codes found".

[0109] The task decomposition approach used in this application has the following advantages: Maximizing efficiency: By grouping tasks by channel, the physical parallelism of the multi-bus (CAN1+CAN2+ETH) is utilized. Traditional single-threaded scanning queries one after another, while this solution employs a multi-pronged approach, significantly reducing overall time consumption.

[0110] Precise fault tolerance: By encapsulating request information and injecting dynamic timeout thresholds into the request information, the BMS (slow) will not falsely report failure due to the timeout setting being too short, and the IVI (fast) will not waste user time due to waiting too long.

[0111] Flexible expansion: If the vehicle adds CAN3 or more ECUs in the future, only rules need to be added in the "resource mapping" stage, without rewriting the core scheduling logic.

[0112] In summary, the task scheduler plays the role of "commander" here: it breaks down a large command into smaller commands, distributes them to different "teams" (communication channels), and equips each team with a customized "timer" (adaptive timeout), thereby achieving efficient and accurate concurrent diagnosis.

[0113] This application describes the method of the embodiment of the application based on the following scenario: An authorized service station of a new energy vehicle brand used its self-developed diagnostic software "THINKCARX10" to perform "deep maintenance on the high-voltage system" of a high-end electric SUV, involving the following ECUs: VCU (Vehicle Controller): 0x7E0, located on CAN1; BMS (Battery Management System): 0x760, located on CAN2; OBC (On-Board Charger): 0x765, located on CAN2; ADAS Domain Controller: 0x1000, located on Ethernet.

[0114] User operation: Click "One-click high-voltage maintenance", and the vehicle diagnostic system will automatically perform the following: read all relevant ECU DTCs; if there is no serious fault in the BMS, perform safe access and read battery health data; clear confirmed harmless DTCs.

[0115] Problems with traditional diagnostic systems: Fixed timeout of 2 seconds → BMS response time often reaches 1.4 seconds in winter workshop (8°C), although successful, each task waits 600ms in vain; ADAS response time is only 70ms, but also waits 2 seconds, resulting in low channel utilization; OBC response time was occasionally 1.8 seconds, which was mistakenly judged as offline by the old software (timeout 1.5s), causing the operation to be interrupted.

[0116] The implementation effect of this application's embodiment in THINKCAR X10: S701. Initial vehicle connection: The vehicle diagnostic system reads each ECU model, initializes the profile, and obtains request-response profile cache data; BMS profile: Adaptive timeout threshold T base=1500ms (default value); ADAS profile: Adaptive timeout threshold T base=200ms (default).

[0117] S702. Execute ReadDTC(BMS): The measured response time was 1380ms. The ambient temperature was detected to be 9°C; a low-temperature correction factor of 1.3 was applied. The next request timeout for BMS is 1380 × 1.2 × 1.3 ≈ 2150ms, but is limited by max = 2000ms → set to 2000ms; at the same time, update the BMS profile sample library.

[0118] S703. Execute ReadDTC (ADAS): Response latency = 68ms; Calculate Tbase = 68 × 1.2 ≈ 82ms → Assume a timeout of 100ms; The atomic task is completed within 100ms, and the communication channel is immediately released for the next atomic task.

[0119] S704. Advantages of concurrent scheduling: On the CAN2 channel, the BMS task uses a 2000ms timeout, while the OBC task (fast response) uses a 500ms timeout. The two processes are executed alternately without blocking each other; High-speed rotating ADAS tasks via Ethernet channel; The total operation time has been reduced from 4.1 minutes to 2.6 minutes.

[0120] S705. Exception Robustness Verification: In one instance, the BMS experienced a response delay of 2.3 seconds due to an internal watchdog reset. The first attempt timed out (2000ms) and was retried. The second attempt timed out (2300ms) after an update and successfully captured the response; the task continued without interrupting the entire job.

[0121] As a result, the average processing time for repair work orders is reduced by 37%; false alarms caused by "ECU no response" are reduced by 95%; the software does not require manual configuration of timeout parameters and is ready to use out of the box; it supports cross-vehicle learning: the optimized timeout is used for the second diagnosis of the same model vehicle.

[0122] Figure 6 A schematic diagram of a vehicle diagnostic system according to an embodiment of this application is shown. Exemplarily, the vehicle diagnostic system includes: a record acquisition module 610, a task decomposition module 620, an adaptive timeout threshold calculation module 630, a request information encapsulation module 640, and a task execution module 650.

[0123] The record acquisition module is used to acquire the request and response profile cache record corresponding to each electronic control unit from the request and response profile cache data corresponding to all vehicles based on the composite identifier of each electronic control unit; The task decomposition module is used to receive the diagnostic job selected by the user, decompose the diagnostic job into multiple atomic tasks, and allocate a corresponding communication channel for each atomic task. The adaptive timeout threshold calculation module, based on preset dynamic factors, utilizes the cached records of each request response profile and calculates the adaptive timeout threshold corresponding to each electronic control unit through the timeout decision processing module. The request information encapsulation module is used to encapsulate the request information carried by the corresponding atomic task based on the adaptive timeout threshold; The task execution module is used to send corresponding request information to the vehicle in parallel through the corresponding communication channels via atomic tasks of different electronic control units.

[0124] It is understood that the apparatus of this embodiment corresponds to the method of the above embodiments, and the options in the above embodiments are also applicable to this embodiment, so they will not be described again here.

[0125] This application also provides a terminal device, exemplary of which includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to enable the terminal device to perform the functions of the above-described electronic control unit request task management method or the various modules in the above-described electronic control unit request task management system.

[0126] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0127] The memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory is used to store computer programs, and the processor can execute the computer programs accordingly after receiving execution instructions.

[0128] This application also provides a computer-readable storage medium for storing the computer program used in the aforementioned terminal device. For example, the computer-readable storage medium may include, but is not limited to, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0129] In the several embodiments provided in this application, it should be understood that the disclosed systems and methods can also be implemented in other ways. The system embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, as an alternative implementation, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0130] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0131] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0132] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for managing request tasks by an electronic control unit, characterized in that, Applicable to vehicle diagnostic systems, the method includes: Based on the composite identifier of each electronic control unit, the request and response profile cache record corresponding to each electronic control unit is obtained from the request and response profile cache data corresponding to all vehicles; Receive the diagnostic job selected by the user, decompose the diagnostic job into multiple atomic tasks, and allocate a corresponding communication channel for each atomic task; Based on preset dynamic factors, using the cached records of each request response profile, the adaptive timeout threshold corresponding to each electronic control unit is calculated through the timeout decision processing module; The request information carried by the corresponding atomic task is encapsulated based on the adaptive timeout threshold; The atomic tasks of different electronic control units are used to send corresponding request information to the vehicle in parallel through their respective communication channels.

2. The electronic control unit request task management method according to claim 1, characterized in that, The composite identifier includes the logical address of the electronic control unit and the vehicle type identifier of the corresponding vehicle. The step of retrieving the request-response profile cache record corresponding to each electronic control unit from the request-response profile cache data corresponding to all vehicles based on the composite identifier of each electronic control unit includes: Based on the vehicle type identifier, the request and response profile cache sub-data of the target vehicle corresponding to the electronic control unit is obtained from the request and response profile cache data of multiple types of vehicles. Based on the logical address, the request response profile cache record is retrieved from the request response profile cache sub-data.

3. The electronic control unit request task management method according to claim 1, characterized in that, The method further includes: When the vehicle diagnostic system connects to the electronic control unit for the first time, the model of the electronic control unit is obtained, and the default value corresponding to the adaptive timeout threshold of the electronic control unit is obtained from the preset timeout threshold dictionary based on the model of the electronic control unit, and used as the current adaptive timeout reference value. Based on the model of the electronic control unit, the logical address of the electronic control unit, the vehicle type identifier of the corresponding vehicle, the constructed historical response latency data, the current adaptive timeout baseline value, and the last update timestamp, a request-response profile cache record of the electronic control unit is created.

4. The electronic control unit request task management method according to claim 1, characterized in that, The process of receiving a diagnostic job selected by the user, decomposing the diagnostic job into multiple atomic tasks, and allocating a corresponding communication channel for each atomic task includes: The task scheduler reads a predefined job configuration table and iterates through each type of electronic control unit and each type of diagnostic service corresponding to each electronic control unit in the job configuration table, generating a corresponding atomic task for each diagnostic service. The corresponding target communication channel is obtained by querying the routing table based on the logical address of each electronic control unit; The atomic tasks corresponding to the electronic control unit are assigned to the corresponding target communication channels.

5. The electronic control unit request task management method according to claim 1, characterized in that, Based on preset dynamic factors, and utilizing the cached records of each request-response profile, the adaptive timeout threshold corresponding to each electronic control unit is calculated through the timeout decision processing module, including: The timeout decision processing module receives the logical address of the electronic control unit and loads the request-response profile cache record based on the logical address. The timeout decision processing module calculates the basic timeout threshold based on the most recent N historical response delays and preset safety margins in the request-response profile cache record. The timeout decision processing module determines an environmental adjustment coefficient based on the current environmental parameters within the preset dynamic factors, and corrects the basic timeout threshold according to the environmental adjustment coefficient to obtain the adaptive timeout threshold.

6. The electronic control unit request task management method according to claim 1, characterized in that, The atomic tasks of different electronic control units, which send corresponding request information to the vehicle in parallel through their respective communication channels, include: The multiple atomic tasks corresponding to each electronic control unit are sorted in a preset order to obtain the atomic task sequence corresponding to each electronic control unit. The request information of each atomic task in each atomic task sequence is sent to the vehicle through the corresponding communication channel in the preset order.

7. The electronic control unit request task management method according to claim 1, characterized in that, The method further includes: The system receives response information from the electronic control unit based on the request information within the corresponding atomic task, calculates the actual response time of the atomic task based on the response information, and updates the corresponding request-response profile cache record of the electronic control unit.

8. The electronic control unit request task management method according to claim 7, characterized in that, The process of receiving response information from the electronic control unit based on request information within the corresponding atomic task, calculating the actual response time of the atomic task based on the response information, and updating the corresponding request-response profile cache record of the electronic control unit includes: In response to sending the atomic task, a timer is started; In response to receiving the response information from the request information feedback within the corresponding atomic task, the timer is stopped to obtain the actual response delay; based on a preset update method, the actual response delay is updated in the request response profile cache record corresponding to the electronic control unit.

9. The electronic control unit request task management method according to claim 1, characterized in that, The process of encapsulating the request information carried by the corresponding atomic task based on the adaptive timeout threshold includes: The adaptive timeout threshold of the electronic control unit, as well as at least one of the vehicle model identifier, the logical address of the electronic control unit, the diagnostic service, the communication channel, and the model of the electronic control unit, are encapsulated using a preset data structure to obtain the request information of the corresponding atomic task.

10. A vehicle diagnostic system, characterized in that, include: The record acquisition module is used to acquire the request and response profile cache record corresponding to each electronic control unit from the request and response profile cache data corresponding to all vehicles based on the composite identifier of each electronic control unit; The task decomposition module is used to receive the diagnostic job selected by the user, decompose the diagnostic job into multiple atomic tasks, and allocate a corresponding communication channel for each atomic task. The adaptive timeout threshold calculation module, based on preset dynamic factors, utilizes the cached records of each request response profile and calculates the adaptive timeout threshold corresponding to each electronic control unit through the timeout decision processing module. The request information encapsulation module is used to encapsulate the request information carried by the corresponding atomic task based on the adaptive timeout threshold; The task execution module is used to send corresponding request information to the vehicle in parallel through the corresponding communication channels via atomic tasks of different electronic control units.

Images