Method, system and device for adaptively adjusting OBD (On-Board Diagnostic) diagnosis sequence under high load and vehicle

Abstract

The invention provides an OBD diagnosis sequence adaptive adjustment method, system and device under a high load and a vehicle, and relates to the technical field of intelligent driving, the method can collect communication data of each network segment in real time through an OBD interface when the load of a vehicle-mounted network is high, and the communication data of each network segment can be acquired in combination with basic information of a controller, a vehicle operation mode and a fault level; the key type of the controller is identified, the network segment load rate is calculated, the diagnosis sequence is dynamically adjusted on the basis, and the diagnosis communication of the key controller is preferentially guaranteed. And when the load of the target network segment exceeds a threshold value, communication of the non-key controller is automatically suspended to release bus resources, communication of the non-key controller is recovered after key diagnosis is completed, and total detection is executed again. According to the method, the diagnosis efficiency and success rate of the OBD system in a high-load environment are effectively improved, the diagnosis priority of a key system is guaranteed, communication delay and data loss caused by bus congestion are avoided, and the real-time performance, stability and reliability of the system are enhanced.

Description

Technical Field

[0001] This invention relates to the field of intelligent driving technology, and in particular to a method, system, device, and vehicle for adaptive adjustment of OBD diagnostic sequences under high load. Background Technology

[0002] OBD (On-Board Diagnostics) is a technology that uses an on-board diagnostic system to monitor automotive electronic systems in real time. The OBD system communicates with other ECUs (Electronic Control Units) on the vehicle via a CAN (Controller Area Network) bus to monitor the status of multiple key components and systems. However, under high load conditions, increased CAN bus load can prolong the time it takes for the OBD system to acquire diagnostic data. This not only affects the real-time performance of fault detection but may also impact the accuracy of diagnostic results and system stability to varying degrees. Specifically, under high load conditions, the longer waiting time to receive necessary diagnostic data causes delays in fault detection; additional data transmission errors or losses affect diagnostic accuracy; and sustained high load can destabilize the entire network, further impacting the normal operation of the OBD system. Summary of the Invention

[0003] The purpose of this invention is to provide a method, system, device, and vehicle for adaptive adjustment of OBD diagnostic sequences under high load, in order to solve one or more technical problems existing in the prior art, or at least provide a beneficial option or create conditions.

[0004] The solution to the technical problem of this invention is as follows: On the one hand, this invention provides an adaptive adjustment method for OBD diagnostic sequences under high load, comprising the following steps: The communication data of each network segment of the vehicle is collected in real time through the OBD interface. Based on the basic information of the controller in each network segment, the current operating mode of the vehicle and the real-time fault level, the current load rate of each network segment is calculated and the criticality type of each controller in each network segment is identified. The criticality type of each controller includes critical controllers and non-critical controllers. The critical controller refers to the controller that needs to prioritize diagnostic communication, while the non-critical controller refers to the controller that can temporarily reduce the diagnostic frequency or suspend communication. Based on the current load rate of each network segment and the criticality type of each controller, combined with the preset load sensitivity coefficient table and the remaining load capacity of each network segment, the controller diagnostic sequence is dynamically adjusted. Based on the controller diagnostic sequence, the target critical controller to be detected and its target network segment are determined, and it is determined whether the current load rate of the target network segment exceeds the preset high load threshold. If it does, a stop communication command is sent to the non-critical controllers in the target network segment. After the target critical controller is detected, the communication of the non-critical controller is restored, and the OBD detection of all controllers is re-executed according to the controller diagnostic sequence.

[0005] Furthermore, the step of collecting communication data from each network segment of the vehicle in real time via the OBD interface, calculating the current load rate of each network segment based on the basic information of the controllers within each network segment, the current operating mode of the vehicle, and the real-time fault level, and identifying the criticality type of each controller in each network segment, includes the following steps: The communication data of each module of the vehicle to which it belongs is collected in real time through the OBD interface; Based on the basic information, the communication data, the current vehicle operating mode, and the real-time fault level, a load calculation model and a controller classification model are constructed. The load calculation model is used to characterize the mapping relationship between network segment load rate and communication data and operating mode, and the controller classification model is used to characterize the association rules between controller criticality and operating mode and fault level. The load calculation model is fitted with parameters, and the current load rate of each network segment is calculated by combining the preset sliding window algorithm. The controller classification model is subjected to rule matching, and the critical type of each controller in each network segment is identified based on the current operating mode of the vehicle and the real-time fault level.

[0006] Further, the step of fitting parameters to the load calculation model and calculating the current load rate of each network segment using a preset sliding window algorithm includes the following steps: Based on the time-sharing load feature extraction method, the number of communication frames, single frame data length and transmission time interval of periodic signals and event triggering signals in each network segment in the communication data are statistically analyzed according to a preset time window. Using a pre-defined sliding window algorithm, the instantaneous peak load and average load of each network segment are calculated; the instantaneous peak load refers to the maximum data transmission volume within a single time window, and the average load refers to the average load across multiple time windows. Based on the vehicle's current operating mode, the instantaneous peak load and average load of each network segment, the current load rate of each network segment is calculated according to the load calculation model.

[0007] Furthermore, the load calculation model satisfies the following calculation formula: ; in, Indicates the The current load rate of each network segment Indicates the Average load of each network segment Indicates the The instantaneous peak load of each network segment; This indicates the current operating mode of the vehicle. This represents the basic load percentage coefficient under the current operating mode of the vehicle. ; This represents the percentage of sudden loads in the current operating mode of the vehicle. ; .

[0008] Furthermore, the basic information includes the controller's function type and historical failure frequency; The step of performing rule matching on the controller classification model to identify the critical type of each controller in each network segment based on the vehicle's current operating mode and the real-time fault level includes the following steps: Based on the current vehicle operating mode and the function type of the controller, a preset function priority matrix is ​​retrieved to obtain the priority of the controller for each function type under the current vehicle operating mode; wherein, the function priority matrix is ​​used to define the priority of the controller for each function type under different vehicle operating modes; Based on the real-time fault level and the historical fault frequency of the controller, a preset fault level mapping table is retrieved to obtain the criticality of each controller corresponding to the real-time fault level; wherein, the fault level mapping table is used to define the association rules between different fault levels and controller criticality. The priority of each functional type of controller in the current operating mode of the vehicle and the criticality of each controller corresponding to the real-time fault level are weighted and fused to calculate the criticality evaluation value of each controller. Based on the criticality assessment value and a preset criticality threshold, the criticality type of each controller in each network segment is identified.

[0009] Furthermore, the step of dynamically adjusting the controller diagnostic sequence based on the current load rate of each network segment and the criticality type of each controller, combined with a preset load sensitivity coefficient table and the remaining load capacity of each network segment, includes the following steps: Based on the current load rate of each network segment and the criticality type of each controller, the load sensitivity coefficient table is retrieved to obtain the diagnostic sequence adjustment weight of each controller; The load sensitivity coefficient table is used to define the diagnostic sequence adjustment weights for critical and non-critical controllers within different load rate ranges. The diagnostic sequence adjustment factor of each controller is calculated based on the remaining load capacity and the diagnostic sequence adjustment weight of each controller. The diagnostic sequence of each controller is dynamically adjusted based on the diagnostic sequence adjustment factor and criticality type.

[0010] Furthermore, the step of dynamically adjusting the controller diagnostic sequence based on the diagnostic sequence adjustment factor and criticality type of each controller includes the following steps: For the critical controller, if its diagnostic sequence adjustment factor is not lower than the first adjustment threshold, the original diagnostic frequency is maintained; if its diagnostic sequence adjustment factor is lower than the first adjustment threshold but not lower than the second adjustment threshold, its diagnostic frequency is reduced; if its diagnostic sequence adjustment factor is lower than the second adjustment threshold, its diagnostic communication is prioritized, and the communication time slot of the non-critical controller is temporarily occupied. For the non-critical controller, if its diagnostic sequence adjustment factor is not lower than the third adjustment threshold, the original diagnostic frequency is maintained; if its diagnostic sequence adjustment factor is lower than the third adjustment threshold but not lower than the fourth adjustment threshold, its diagnostic frequency is reduced; if its diagnostic sequence adjustment factor is lower than the fourth adjustment threshold, its diagnostic request is suspended.

[0011] On the other hand, this application provides an adaptive adjustment system for OBD diagnostic sequences under high load, for performing the aforementioned adaptive adjustment method for OBD diagnostic sequences under high load.

[0012] On the other hand, this application provides an adaptive adjustment device for OBD diagnostic sequences under high load, including a processor and a memory; the memory stores a computer program, and the processor executes the computer program to implement the aforementioned adaptive adjustment method for OBD diagnostic sequences under high load.

[0013] On the other hand, this application provides a vehicle that integrates the aforementioned high-load OBD diagnostic sequence adaptive adjustment device.

[0014] The beneficial effects of this invention are as follows: The OBD diagnostic sequence adaptive adjustment method provided in this application under high load can collect communication data of each network segment in real time through the OBD interface when the vehicle network load is high. Combined with controller basic information, vehicle operating mode, and fault level, it identifies the critical type of the controller and calculates the network segment load rate. Based on this, it dynamically adjusts the diagnostic sequence, prioritizing the diagnostic communication of critical controllers. When the target network segment load exceeds a threshold, it automatically suspends communication of non-critical controllers to release bus resources. After the critical diagnosis is completed, communication of non-critical controllers is restored, and a full detection is re-executed. This method effectively improves the diagnostic efficiency and success rate of the OBD system under high load conditions, ensures the diagnostic priority of critical systems, avoids communication delays and data loss caused by bus congestion, and enhances the real-time performance, stability, and reliability of the system. This application also provides corresponding systems, devices, and vehicles. The beneficial effects of the systems, devices, and vehicles are similar to those of the method and will not be elaborated here.

[0015] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0016] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, and do not constitute a limitation on the technical solutions of the present invention.

[0017] Figure 1 This is a flowchart of the OBD diagnostic sequence adaptive adjustment method under high load provided in this application; Figure 2 This is a structural diagram of the OBD diagnostic sequence adaptive adjustment system under high load provided in this application; Figure 3 This is a structural diagram of the OBD diagnostic sequence adaptive adjustment device under high load provided in this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] The present application will be further described below with reference to the accompanying drawings and specific embodiments. The described embodiments should not be considered as limitations on the present application, and all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of the present application.

[0020] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0022] As automotive electronic systems become increasingly complex, OBD (On-Board Diagnostics) has become increasingly important as a technology for real-time monitoring of the vehicle's engine electronic control system and other functional modules. The OBD system communicates with other ECUs (Electronic Control Units) on the vehicle via the CAN (Controller Area Network) bus to obtain various data related to the electronic systems. This data includes, but is not limited to, status information for EGR (Exhaust Gas Recirculation), the engine, the particulate filter, the catalytic converter, the oxygen sensor, the emission control system, and the fuel system. When any of these systems or components malfunction, the OBD system will promptly issue an alert and notify the driver via a malfunction indicator lamp or a check engine warning light.

[0023] In existing technologies, OBD systems may encounter a series of problems under high-load environments. Specifically, since the CAN bus is a data transmission channel shared by multiple ECUs, its load rate directly affects the performance and stability of the OBD system. Under high load conditions, the OBD system may require a longer time to obtain the necessary diagnostic data from other ECUs, which not only affects the real-time performance of fault detection but may also lead to varying degrees of decrease in the accuracy of diagnostic results and system stability.

[0024] Specifically, under high load conditions, the large amount of data on the CAN bus prolongs the time it takes for the OBD system to receive diagnostic data, thus affecting the speed and efficiency of fault detection. High load environments increase the risk of data transmission errors or loss, negatively impacting the diagnostic results of the OBD system and potentially leading to misdiagnosis or missed diagnosis. Sustained high load conditions can destabilize the entire network, further affecting the normal operation of the OBD system and even potentially causing network congestion and system crashes. Furthermore, existing technologies fail to provide an effective adaptive adjustment mechanism to cope with changing diagnostic needs under different load conditions, particularly regarding prioritizing diagnostic communication for critical controllers under high load environments.

[0025] To address these issues, this application proposes a method, system, device, and vehicle for adaptive adjustment of OBD diagnostic sequences under high load conditions. This method configures the diagnostic instrument's detection sequence to adaptively adjust parameters under high bus load conditions, identifies and distinguishes between critical and non-critical controllers, and dynamically adjusts the diagnostic sequence based on the current network segment load. This not only ensures the diagnostic priority of critical controllers but also alleviates the load pressure on the CAN network segment by temporarily reducing or suspending communication of non-critical controllers, thereby improving the overall system performance and stability. This method effectively improves the response speed, diagnostic accuracy, and system reliability of the OBD system under complex operating conditions.

[0026] First, the adaptive adjustment method for OBD diagnostic sequences under high load provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0027] Reference Figure 1 The implementation process of the OBD diagnostic sequence adaptive adjustment method under high load provided in this application embodiment includes, but is not limited to, the following steps.

[0028] Step S110: Real-time acquisition of communication data of each network segment of the vehicle through the OBD interface; calculation of the current load rate of each network segment based on the basic information of the controller in each network segment, the current operating mode of the vehicle and the real-time fault level; and identification of the critical type of each controller in each network segment.

[0029] The criticality of each controller is categorized into critical controllers and non-critical controllers. Critical controllers are those that require priority in ensuring diagnostic communication, while non-critical controllers are those whose diagnostic frequency can be temporarily reduced or whose communication can be suspended.

[0030] In step S110, communication data from each network segment of the vehicle is collected in real time via the OBD interface. Based on the basic information of the controllers within each network segment, the vehicle's current operating mode, and the real-time fault level, the current load rate of each network segment is calculated, and the criticality type of each controller in each network segment is identified. This process first ensures a comprehensive understanding of the vehicle network status, providing basic data support for subsequent diagnostic sequence adjustments. Specifically, by monitoring communication data in real time, the system can accurately grasp the load status of each network segment, and then identify, according to preset rules, which controllers are critical (requiring priority for diagnostic communication) and which are non-critical (whose diagnostic frequency can be temporarily reduced or communication suspended). This classification helps optimize resource allocation under high load conditions, ensuring that the most important systems are diagnosed in a timely manner.

[0031] Step S120: Based on the current load rate of each network segment and the criticality type of each controller, combined with the preset load sensitivity coefficient table and the remaining load capacity of each network segment, dynamically adjust the controller diagnostic sequence.

[0032] In step S120, based on the current load rate of each network segment and the criticality type of each controller, combined with the preset load sensitivity coefficient table and the remaining load capacity of each network segment, the controller diagnostic sequence is dynamically adjusted. The core of this step lies in optimizing the diagnostic process using known load conditions and controller importance. The load sensitivity coefficient table defines the adjustment weights for the diagnostic sequences of critical and non-critical controllers within different load rate ranges, enabling the system to flexibly adjust diagnostic strategies under different load conditions. This approach not only ensures the diagnostic needs of critical systems but also effectively avoids network congestion caused by bus overload, thereby improving the stability and efficiency of the entire system.

[0033] Step S130: Based on the controller diagnostic sequence, determine the target key controller to be detected and its target network segment, and determine whether the current load rate of the target network segment exceeds the preset high load threshold.

[0034] In step S130, based on the adjusted controller diagnostic sequence, the target critical controller to be tested and its corresponding target network segment are identified, and it is further determined whether the current load rate of the target network segment exceeds a preset high load threshold. This step aims to accurately identify critical controllers that require immediate attention so that appropriate measures can be taken to ensure that their diagnostics are not interfered with. If the load rate of the target network segment exceeds the set high load threshold, it indicates that the network segment is currently in a state unfavorable for efficient diagnostics, providing a basis for further action. Through detailed analysis of the target network segment, the system can respond in a targeted manner to ensure the smooth diagnostics of critical controllers.

[0035] Step S140: If the limit is exceeded, a stop communication command is sent to the non-critical controllers in the target network segment. After the target critical controller has completed the detection, communication of the non-critical controllers is restored, and the OBD detection of all controllers is re-executed according to the controller diagnostic sequence.

[0036] In step S140, after confirming that the load rate of the target network segment exceeds the preset high load threshold, the following specific measures are taken: A stop communication command is sent to non-critical controllers in the target network segment to reduce data traffic on the bus, lower load pressure, and ensure that the diagnostic process of critical controllers is not affected. Once the critical controller's detection is complete, communication with non-critical controllers is restored, and the OBD detection of all controllers is re-executed. This method effectively solves the network congestion problem that may occur under high load conditions, ensures priority diagnosis of critical systems, and also considers the completeness and accuracy of the overall diagnosis. By temporarily interrupting non-critical communication, the system can maximize resource utilization and improve diagnostic efficiency without affecting security and performance.

[0037] In some embodiments of this application, in step S110, the communication data of each network segment of the vehicle is collected in real time through the OBD interface. Based on the basic information of the controller in each network segment, the current operating mode of the vehicle, and the real-time fault level, the current load rate of each network segment is calculated, and the implementation process of identifying the key types of each controller in each network segment includes, but is not limited to, the following steps.

[0038] Step S210: Real-time acquisition of communication data of the network segments to which each module of the vehicle belongs via the OBD interface.

[0039] In step S210, the system is provided with the ability to perceive the status of the vehicle network. Communication data from different CAN network segments belonging to various functional modules of the vehicle is acquired via the OBD interface, including but not limited to message traffic, frame rate, communication cycle, and data length. This data reflects the actual load of each network segment in the current vehicle network and forms the basis for subsequent load calculations and controller classification. This step ensures the system's real-time performance and dynamic response capabilities, enabling diagnostic strategies to be adjusted promptly based on the actual operating status, avoiding blind scheduling or resource waste.

[0040] Step S220: Based on basic information, communication data, the vehicle's current operating mode, and real-time fault level, construct a load calculation model and a controller classification model.

[0041] Among them, the load calculation model is used to characterize the mapping relationship between network segment load rate and communication data and operating mode, and the controller classification model is used to characterize the association rules between controller criticality and operating mode and fault level.

[0042] In step S220, two key models are established: a load calculation model and a controller classification model. These models are used to assess the network segment load level and identify the criticality type of controllers, respectively. The load calculation model describes the mapping relationship between network segment load rate, communication data characteristics, and vehicle operating modes, aiming to transform raw communication data into quantifiable load indicators. The controller classification model defines the association rules between controller criticality and operating mode and fault level, used to determine which controllers are critical controllers requiring priority protection in the current state, and which are non-critical controllers that can be temporarily downclocked or have their communication suspended. The establishment of these two models enables the system to make intelligent decisions, automatically identifying network bottlenecks and key diagnostic objects based on input data under different operating conditions, thereby supporting subsequent diagnostic sequence optimization.

[0043] Step S230: Perform parameter fitting on the load calculation model and calculate the current load rate of each network segment using a preset sliding window algorithm.

[0044] In step S230, the load calculation model is parameter optimized and a specific load rate value is output. By introducing a sliding window algorithm, the system can perform weighted averaging of communication data within a certain time window, eliminating interference caused by instantaneous fluctuations and obtaining a more stable and accurate load rate assessment result. This dynamic update mechanism ensures that the system can continuously track the changing trend of network segment load, providing a scientific basis for whether the diagnostic sequence needs to be adjusted subsequently. At the same time, the sliding window setting also takes into account the system's response speed and stability, avoiding the impact on overall efficiency due to frequent switching of diagnostic strategies.

[0045] Step S240: Perform rule matching on the controller classification model, and identify the critical type of each controller in each network segment based on the vehicle's current operating mode and real-time fault level.

[0046] In step S240, by matching the rules in the controller classification model, the system can accurately identify which controllers are critical and which are non-critical under the current operating conditions. For example, when the engine is running at high speed or the emission system is abnormal, the relevant controllers will be marked as critical controllers and prioritized for diagnosis; while under certain low-risk operating conditions, some comfort or auxiliary ECUs can be classified as non-critical controllers, allowing for temporary reduction of communication frequency or suspension of communication to free up bus resources. This mechanism not only improves diagnostic efficiency but also effectively reduces the risk of bus congestion under high load conditions, realizing intelligent management of on-demand allocation of diagnostic resources.

[0047] In some embodiments of this application, the process of performing parameter fitting on the load calculation model and calculating the current load rate of each network segment in step S230, combined with a preset sliding window algorithm, includes but is not limited to the following steps.

[0048] Step S310: Based on the time-sharing load feature extraction method, the number of communication frames, single frame data length and transmission time interval of periodic signals and event triggering signals in each network segment in the communication data are statistically analyzed according to a preset time window.

[0049] In step S310, data preparation for calculating the vehicle network load rate is performed by extracting representative load characteristic parameters from the raw communication data. Using a time-division load characteristic extraction method, the system performs segmented statistical analysis of the communication behavior of each CAN network segment of the vehicle according to a set time window. Specifically, the number of communication frames for periodic signals reflects the regularity and data density of fixed-cycle ECU communication; the number of communication frames for event-triggered signals reflects the additional communication pressure caused by sudden faults or state changes; and the single-frame data length and transmission time interval are used to assess the bus resource usage of each communication frame. These parameters collectively constitute the basic indicators for measuring the communication pressure of network segments, providing a reliable data source for subsequent calculations of instantaneous peak and average loads. This step ensures the comprehensiveness and accuracy of the load assessment and helps identify the contribution of different communication types to the bus load.

[0050] Step S320: Using a preset sliding window algorithm, calculate the instantaneous peak load and average load of each network segment.

[0051] Instantaneous load peak refers to the maximum data transmission volume within a single time window, while average load refers to the average load across multiple time windows.

[0052] In step S320, after obtaining the basic characteristics of the communication data, a sliding window algorithm is introduced to dynamically analyze the communication load of each network segment, calculating the instantaneous peak load and average load respectively. The instantaneous peak load refers to the maximum data transmission volume that can be achieved within a time window, used to determine whether there is a risk of short-term high load; the average load refers to the average load over multiple time windows, used to characterize the overall load trend and stability. The advantage of the sliding window mechanism is that it not only focuses on the load status at the current moment, but also combines historical data for smoothing, avoiding misjudgments caused by short-term fluctuations. This calculation method enables the system to more accurately perceive the changing trend of network segment load and provides a reliable input basis for the next step of calculating the load rate based on the operating mode. At the same time, the dual indicators of instantaneous peak load and average load also enhance the system's ability to identify sudden congestion and continuous high load.

[0053] Step S330: Based on the vehicle's current operating mode, the instantaneous peak load and average load of each network segment, the current load rate of each network segment is calculated according to the load calculation model.

[0054] In step S330, the previously extracted communication features are combined with the operating status to generate a quantitative indicator that can be directly used for diagnostic scheduling decisions, namely the network segment load rate. Specifically, vehicle operating modes (such as starting, driving, rapid acceleration, braking, etc.) affect the data traffic distribution of different network segments; instantaneous load peaks are used to identify whether immediate countermeasures are needed; average load is used to determine whether a network segment is in a long-term high-load state. These factors are input into a pre-built load calculation model, and after weighted calculation, the real-time load rate of each network segment is finally obtained. This load rate result not only reflects the actual communication pressure of the current vehicle network, but also provides a scientific basis for subsequent diagnostic sequence adjustment and controller priority allocation. This step realizes the key transformation from raw communication data to executable control strategies and is one of the core supports for realizing adaptive adjustment of OBD diagnosis.

[0055] In summary, steps S310 to S330 constitute a complete mechanism for extracting vehicle network load features and dynamically evaluating them. Through refined modeling and dynamic calculation of communication data, it provides the system with accurate and real-time load perception capabilities, ensuring that the diagnostic scheduling strategy can make a rapid and reasonable response in the complex and ever-changing vehicle network environment. This is an important foundation and key technical path for realizing the core technical solution of adaptive adjustment of OBD diagnostic sequence under high load.

[0056] In some embodiments of this application, the load calculation model satisfies the following calculation formula (1): (1); In formula (1), Indicates the The current load rate of each network segment Indicates the Average load of each network segment Indicates the The instantaneous peak load of each network segment. Indicates the vehicle's current operating mode. This represents the basic load percentage coefficient under the current vehicle operating mode. . This represents the percentage of sudden loads in the vehicle's current operating mode. . .

[0057] In formula (1), the load calculation model is used to determine the current load rate of each network segment. This model is achieved by combining two key factors: average load and instantaneous load peak. Specifically, it considers the impact of the vehicle's current operating mode on the load. First, the model calculates a base load percentage coefficient and a burst load percentage coefficient based on the vehicle's current operating mode. These two coefficients reflect the contribution of average load and instantaneous load peak to the total load rate under a specific operating mode. The base load percentage coefficient represents the proportion of average load in the total load, while the burst load percentage coefficient represents the proportion of instantaneous load peak in the total load. The sum of these two coefficients equals one, ensuring that they together constitute a complete description of the load rate.

[0058] Then, the model multiplies the average load of each network segment by the base load ratio, and adds the corresponding instantaneous peak load multiplied by the burst load ratio to obtain the current load rate of the network segment. This is done to comprehensively consider both stable communication pressure and sudden high load situations within different time windows, thus more accurately reflecting the actual network load. In this way, the load calculation model can dynamically adjust the load assessment method according to the communication characteristics under different operating modes, providing a scientific basis for the adaptive adjustment of subsequent diagnostic sequences.

[0059] In some embodiments of this application, the basic information includes the controller's functional type and historical fault frequency. Step S240 involves rule matching of the controller classification model to identify the implementation process of the critical types of each controller in each network segment based on the vehicle's current operating mode and real-time fault level, including but not limited to the following steps.

[0060] Step S410: Based on the current operating mode of the vehicle and the function type of the controller, retrieve the preset function priority matrix to obtain the priority of each function type of the controller in the current operating mode of the vehicle.

[0061] The function priority matrix is ​​used to define the priority of controllers of each function type under different vehicle operation modes.

[0062] In step S410, by combining the vehicle's current operating mode with the function type of each controller, a preset function priority matrix is ​​invoked to determine the priority of each function type controller in a specific operating mode. The core of this step lies in understanding the differences in the needs of various controllers under different driving scenarios. For example, at high speeds, the priority of engine control and safety systems (such as ABS and ESP) will significantly increase; while when stopped or idling, the priority of comfort systems (such as air conditioning and audio) may be relatively high. The function priority matrix provides a structured method to quantify these needs, enabling the system to dynamically adjust diagnostic strategies in complex in-vehicle network environments, ensuring that the most critical functions are monitored and maintained in a timely manner.

[0063] Step S420: Based on the real-time fault level and the historical fault frequency of the controller, retrieve the preset fault level mapping table to obtain the criticality of each controller corresponding to the real-time fault level.

[0064] The fault level mapping table is used to define the association rules between different fault levels and the criticality of the controller.

[0065] Step S420 focuses on a comprehensive assessment of real-time fault levels and historical fault frequencies of controllers, determining the criticality of each controller by invoking a pre-defined fault level mapping table. This step emphasizes the importance of rapid response to faults occurring during actual operation. The fault level mapping table considers not only the severity of the current fault but also the controller's past performance, i.e., its historical fault frequency. This method can more accurately identify high-risk controllers that require immediate attention, even if they are not traditionally considered critical systems. In this way, the system can respond to emergencies more flexibly and intelligently, ensuring that the most urgent issues are addressed first.

[0066] Step S430: The priority of each functional type of controller and the criticality of each controller corresponding to the real-time fault level in the current operating mode of the vehicle are weighted and fused to calculate the criticality evaluation value of each controller.

[0067] In step S430, the information obtained in the first two steps—namely, the controller priority calculated based on the vehicle's current operating mode and the controller criticality determined based on real-time fault levels and historical fault frequencies—is weighted and fused to derive a criticality assessment value for each controller. The goal of this step is to integrate multi-dimensional data sources to form a comprehensive indicator reflecting the importance of each controller. By reasonably assigning weights to priority and criticality, and performing mathematical weighted averaging or other forms of fusion processing, the system can generate a quantified criticality score for each controller. This step is crucial for subsequent decision-making processes because it provides the foundational data for determining which controllers should be prioritized for protection.

[0068] Step S440: Based on the criticality assessment value and the preset criticality threshold, identify the criticality type of each controller in each network segment.

[0069] In step S440, based on the criticality evaluation values ​​of each controller calculated in the previous steps and combined with the preset criticality threshold, the system can identify the criticality type of each controller in each network segment. This process realizes the transformation from numerical evaluation to actual classification, clarifying which controllers are considered critical controllers (requiring priority for diagnostic communication) and which are non-critical controllers (whose diagnostic frequency can be temporarily reduced or communication suspended). The set criticality threshold acts as a decision-making criterion, helping the system make rapid and accurate judgments in complex and ever-changing operating environments, thereby optimizing resource allocation and improving the overall system stability and efficiency. This classification mechanism ensures that even under high network load, the normal operation of the most important systems can be effectively guaranteed.

[0070] In some embodiments of this application, in step S120, the process of dynamically adjusting the controller diagnostic sequence based on the current load rate of each network segment and the criticality type of each controller, combined with a preset load sensitivity coefficient table and the remaining load capacity of each network segment, includes but is not limited to the following steps.

[0071] Step S510: Based on the current load rate of each network segment and the criticality type of each controller, retrieve the load sensitivity coefficient table to obtain the diagnostic sequence adjustment weight for each controller.

[0072] The load sensitivity coefficient table is used to define the diagnostic sequence adjustment weights for critical and non-critical controllers within different load rate ranges.

[0073] In step S510, a dynamic response mechanism is established to enable the diagnostic scheduling strategy to automatically adjust based on the current network load and controller importance. By introducing a load sensitivity coefficient table, the system can define diagnostic priority adjustment rules for critical and non-critical controllers according to different load ranges (e.g., low, medium, and high). For example, under low load conditions, all controllers can be diagnosed normally; while under medium to high load conditions, the diagnostic weight of critical controllers will be increased, while the diagnostic frequency or communication priority of non-critical controllers will be appropriately reduced. This load range-based weighted strategy allows the diagnostic sequence to reasonably control bus resource usage without affecting the monitoring of critical systems, avoiding network congestion caused by blind scheduling.

[0074] Step S520: Calculate the diagnostic sequence adjustment factor for each controller based on the remaining load capacity and the diagnostic sequence adjustment weights of each controller.

[0075] In step S520, based on the obtained diagnostic weights, the remaining load capacity of the network segment is further introduced as an adjustment basis for more refined control of diagnostic behavior. Remaining load capacity refers to the unused communication bandwidth in the current network segment, reflecting how much additional communication pressure the system can withstand without causing congestion. By comprehensively calculating (e.g., multiplying) the diagnostic sequence adjustment weights with the remaining load capacity, the system can generate a specific diagnostic sequence adjustment factor for each controller. This factor determines whether the controller should perform diagnostics earlier, later, or whether its communication frequency needs to be reduced. This step realizes the transformation from qualitative judgment to quantitative control, improving the flexibility and accuracy of diagnostic scheduling.

[0076] Step S530: Dynamically adjust the controller diagnostic sequence according to the diagnostic sequence adjustment factor and criticality type of each controller.

[0077] In step S530, the analysis results from the first two steps are converted into actual diagnostic scheduling instructions. Based on the diagnostic sequence adjustment factor and the criticality type (critical / non-critical) of the controllers, the system can dynamically rearrange the OBD detection order, ensuring that critical controllers are diagnosed first, and reducing the frequency or even suspending communication for non-critical controllers when necessary. Furthermore, this step supports flexible adjustment of the diagnostic cycle, such as accelerating the diagnostic speed under low load and extending the diagnostic interval under high load, thereby achieving a balance between diagnostic efficiency and network stability. This dynamic mechanism not only improves the intelligence level of the OBD system but also significantly enhances its adaptability in complex in-vehicle network environments.

[0078] In summary, steps S510 to S530 constitute a complete dynamic optimization mechanism for the diagnostic sequence. By combining multi-dimensional information such as network segment load status, controller criticality, and remaining load capacity, intelligent scheduling of OBD diagnostic tasks is achieved. This not only effectively alleviates the pressure on the CAN bus under high load conditions and ensures the diagnostic priority of critical systems, but also provides strong support for the stable operation of the vehicle's electronic systems. It is an important component of the core technology for adaptive adjustment of OBD diagnostic sequences under high load conditions.

[0079] In some embodiments of this application, the process of dynamically adjusting the controller diagnostic sequence according to the diagnostic sequence adjustment factor and criticality type of each controller in step S530 includes, but is not limited to, the following steps.

[0080] For critical controllers, if their diagnostic sequence adjustment factor is not lower than the first adjustment threshold, the original diagnostic frequency is maintained. If their diagnostic sequence adjustment factor is lower than the first adjustment threshold but not lower than the second adjustment threshold, their diagnostic frequency is reduced. If their diagnostic sequence adjustment factor is lower than the second adjustment threshold, their diagnostic communication is prioritized, and the communication time slots of non-critical controllers are temporarily occupied.

[0081] Specifically, for critical controllers, if their diagnostic sequence adjustment factor is not lower than the first adjustment threshold, the original diagnostic frequency is maintained. This criterion is used to identify whether the critical controller is still within a stable range that allows it to maintain its original diagnostic frequency under the current network load environment. When the diagnostic sequence adjustment factor is not lower than the set first adjustment threshold, it means that the remaining load capacity of the current network segment is sufficient or the priority of the controller has not been significantly affected, and the system does not need to intervene in its diagnostic behavior. Maintaining the original diagnostic frequency at this time not only ensures the real-time monitoring capability of the critical system but also avoids unnecessary resource waste and increased scheduling complexity. This strategy reflects the design concept of maintaining diagnostic continuity without affecting system stability.

[0082] If the diagnostic sequence adjustment factor is lower than the first adjustment threshold but not lower than the second adjustment threshold, its diagnostic frequency is reduced. This judgment condition indicates that although the controller is of a critical type, maintaining the original diagnostic frequency may pose a certain risk of resource strain due to the current network segment load or overall communication pressure. In this case, by appropriately reducing the diagnostic frequency (such as extending the diagnostic cycle), the bus congestion problem can be alleviated without seriously affecting functional safety. This flexible frequency reduction mechanism achieves a balance between criticality and resource utilization, ensuring the basic monitoring needs of the controller while leaving more communication space for other controllers.

[0083] If the diagnostic sequence adjustment factor is lower than the second adjustment threshold, its diagnostic communication is prioritized, and the communication time slots of non-critical controllers are temporarily occupied. When the diagnostic sequence adjustment factor further drops below the second adjustment threshold, it indicates that the communication environment of the critical controller is under considerable strain, which may even affect the diagnostic response of its core functions. At this time, the system adopts a proactive preemptive scheduling strategy, that is, prioritizing the diagnostic communication of the critical controller and temporarily borrowing the communication time slots of non-critical controllers when necessary to complete the diagnostic task. This mechanism ensures the availability of communication resources for high-priority controllers in extreme situations, prevents functional abnormalities or safety hazards caused by communication delays, and is an important means to achieve intelligent and flexible scheduling of the vehicle OBD system.

[0084] For non-critical controllers, if their diagnostic sequence adjustment factor is not lower than the third adjustment threshold, the original diagnostic frequency is maintained; if their diagnostic sequence adjustment factor is lower than the third adjustment threshold but not lower than the fourth adjustment threshold, their diagnostic frequency is reduced; if their diagnostic sequence adjustment factor is lower than the fourth adjustment threshold, their diagnostic requests are suspended.

[0085] Specifically, for non-critical controllers, if the diagnostic sequence adjustment factor is not lower than the third adjustment threshold, it indicates that current network resources are relatively abundant and will not significantly burden overall communication. Therefore, their original diagnostic frequency can be maintained to ensure that the status of non-critical systems can also be continuously monitored. This strategy helps improve the overall observability of the vehicle's electronic systems while avoiding the subsequent processing costs caused by unnecessary diagnostic interruptions.

[0086] When the diagnostic sequence adjustment factor of a non-critical controller falls below the third adjustment threshold but has not yet reached the minimum critical value, it indicates that its diagnostic behavior has already had a certain impact on the overall network resource allocation. In this case, the system moderately compresses its diagnostic resource usage, for example, by appropriately extending its diagnostic cycle, thereby freeing up some bandwidth for critical controllers. This measure reflects the resource management principle of on-demand allocation and dynamic resource yielding, improving the overall system operating efficiency without excessively sacrificing the monitoring quality of non-critical systems.

[0087] When the diagnostic sequence adjustment factor of a non-critical controller falls below the fourth adjustment threshold, it indicates that its continued execution of diagnostic tasks may interfere with the communication of critical controllers, or even cause network congestion. In this case, the system will completely suspend its diagnostic requests, temporarily removing it from the diagnostic queue until the network load recovers to an acceptable level. This step is a reasonable trade-off made by the system under resource constraints, aiming to maximize the reliability of communication and the timeliness of diagnostics for critical systems, while also reserving the possibility of retrying diagnostics after network recovery.

[0088] In summary, this implementation process constructs a multi-layered, fine-grained diagnostic scheduling mechanism by setting different diagnostic sequence adjustment strategies for critical and non-critical controllers and introducing multiple dynamic adjustment thresholds. This mechanism can not only flexibly adjust diagnostic behavior according to changes in network load, but also effectively guarantee the communication priority of critical systems while taking into account the diagnostic needs of non-critical systems. It has high intelligence and adaptability, and is one of the key technologies for achieving efficient and reliable operation of vehicle OBD systems in complex network environments.

[0089] In summary, the adaptive adjustment method for OBD diagnostic sequences under high load provided in this application has the following technical effects.

[0090] The OBD diagnostic sequence adaptive adjustment method under high load provided in this application realizes intelligent optimization of the OBD diagnostic sequence by analyzing the communication data of each network segment of the vehicle and the criticality type of the controller in real time. This method can accurately calculate the load rate of each network segment and dynamically adjust the diagnostic strategy according to the vehicle's operating mode, ensuring that critical controllers receive priority diagnostic resources under high load conditions, thereby improving the efficiency and accuracy of fault detection while ensuring the stability and reliability of the system. Furthermore, by sending communication stop commands to non-critical controllers or adjusting their diagnostic frequencies, the pressure on the CAN bus is effectively alleviated, improving the overall network resource utilization efficiency.

[0091] This approach supports flexible responses to different driving conditions and fault states, enabling the on-board diagnostic system to make rapid and accurate responses in complex environments. Through these technical means, the method of this application significantly enhances the adaptability of the OBD system under high-load environments, ensuring both the timeliness of diagnosis of critical systems and the rational allocation of resources, providing solid technical support for vehicle networking applications.

[0092] Secondly, refer to Figure 2 This application provides an adaptive adjustment system for OBD diagnostic sequences under high load, used to execute the aforementioned adaptive adjustment method for OBD diagnostic sequences under high load. The system includes a data acquisition and processing module 610, a diagnostic sequence adjustment module 620, and an adaptive OBD detection module 630.

[0093] The data acquisition and processing module 610 is used to acquire communication data from each network segment of the vehicle in real time via the OBD interface. Based on the basic information of the controllers within each network segment, the vehicle's current operating mode, and the real-time fault level, it calculates the current load rate of each network segment and identifies the criticality type of each controller in each network segment. The criticality types of each controller include critical controllers and non-critical controllers. Critical controllers are those whose diagnostic communication needs to be prioritized, while non-critical controllers are those whose diagnostic frequency can be temporarily reduced or whose communication can be suspended.

[0094] The diagnostic sequence adjustment module 620 is used to dynamically adjust the controller diagnostic sequence based on the current load rate of each network segment and the criticality type of each controller, combined with the preset load sensitivity coefficient table and the remaining load capacity of each network segment.

[0095] The adaptive OBD detection module 630 is used to determine the target critical controller to be detected and its target network segment according to the controller diagnostic sequence, and to determine whether the current load rate of the target network segment exceeds the preset high load threshold. If it exceeds the threshold, it sends a stop communication command to the non-critical controllers in the target network segment. After the target critical controller is detected, it restores the communication of the non-critical controllers and re-executes the OBD detection of all controllers according to the controller diagnostic sequence.

[0096] Furthermore, refer to Figure 3 This application provides an adaptive adjustment device for OBD diagnostic sequences under high load, including a processor and a memory. The memory stores a computer program, and when the processor executes the computer program, it implements the aforementioned adaptive adjustment method for OBD diagnostic sequences under high load.

[0097] Furthermore, this application provides a vehicle that integrates the aforementioned high-load OBD diagnostic sequence adaptive adjustment device.

[0098] Similarly, the systems, devices, and vehicles provided in the embodiments of this application have the same technical effects as the method embodiments described above.

[0099] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards of the relevant countries and regions. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data for the proper functioning of the embodiments of this application obtained.

[0100] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0101] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of ordinary skill of an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary skill. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0102] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, 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 programs to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0103] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequential list of executable programs for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, a program execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can retrieve and execute a program from or in conjunction with such a program execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit a program for use by or in conjunction with a program execution system, apparatus, or device.

[0104] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or, if necessary, processing in a suitable manner, and then stored in computer memory.

[0105] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable program execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0106] In the foregoing description of this specification, the reference to terms such as "one embodiment / implementation," "another embodiment / implementation," or "certain embodiments / implementations," etc., indicates that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in an embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0107] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0108] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of the present invention.

Claims

1. An adaptive adjustment method for OBD diagnostic sequences under high load, characterized in that, Includes the following steps: The communication data of each network segment of the vehicle is collected in real time through the OBD interface. Based on the basic information of the controller in each network segment, the current operating mode of the vehicle and the real-time fault level, the current load rate of each network segment is calculated and the criticality type of each controller in each network segment is identified. The criticality type of each controller includes critical controllers and non-critical controllers. The critical controller refers to the controller that needs to prioritize diagnostic communication, while the non-critical controller refers to the controller that can temporarily reduce the diagnostic frequency or suspend communication. Based on the current load rate of each network segment and the criticality type of each controller, combined with the preset load sensitivity coefficient table and the remaining load capacity of each network segment, the controller diagnostic sequence is dynamically adjusted. Based on the controller diagnostic sequence, the target critical controller to be detected and its target network segment are determined, and it is determined whether the current load rate of the target network segment exceeds the preset high load threshold. If it does, a stop communication command is sent to the non-critical controllers in the target network segment. After the target critical controller is detected, the communication of the non-critical controller is restored, and the OBD detection of all controllers is re-executed according to the controller diagnostic sequence.

2. The adaptive adjustment method for OBD diagnostic sequences under high load according to claim 1, characterized in that, The method of collecting communication data of each network segment of the vehicle in real time through the OBD interface, calculating the current load rate of each network segment based on the basic information of the controllers in each network segment, the current operating mode of the vehicle, and the real-time fault level, and identifying the criticality type of each controller in each network segment includes the following steps: The communication data of each module of the vehicle to which it belongs is collected in real time through the OBD interface; Based on the basic information, the communication data, the current vehicle operating mode, and the real-time fault level, a load calculation model and a controller classification model are constructed. The load calculation model is used to characterize the mapping relationship between network segment load rate and communication data and operating mode, and the controller classification model is used to characterize the association rules between controller criticality and operating mode and fault level. The load calculation model is fitted with parameters, and the current load rate of each network segment is calculated by combining the preset sliding window algorithm. The controller classification model is subjected to rule matching, and the critical type of each controller in each network segment is identified based on the current operating mode of the vehicle and the real-time fault level.

3. The adaptive adjustment method for OBD diagnostic sequences under high load according to claim 2, characterized in that, The step of fitting parameters to the load calculation model and calculating the current load rate of each network segment using a preset sliding window algorithm includes the following steps: Based on the time-sharing load feature extraction method, the number of communication frames, single frame data length and transmission time interval of periodic signals and event triggering signals in each network segment in the communication data are statistically analyzed according to a preset time window. Using a pre-defined sliding window algorithm, the instantaneous peak load and average load of each network segment are calculated; the instantaneous peak load refers to the maximum data transmission volume within a single time window, and the average load refers to the average load across multiple time windows. Based on the vehicle's current operating mode, the instantaneous peak load and average load of each network segment, the current load rate of each network segment is calculated according to the load calculation model.

4. The OBD diagnostic sequence adaptive adjustment method under high load according to claim 3, characterized in that, The load calculation model satisfies the following calculation formula: ； in, Indicates the The current load rate of each network segment Indicates the Average load of each network segment Indicates the The instantaneous peak load of each network segment; This indicates the current operating mode of the vehicle. This represents the basic load percentage coefficient under the current operating mode of the vehicle. ; This represents the percentage of sudden loads in the current operating mode of the vehicle. ; .

5. The adaptive adjustment method for OBD diagnostic sequences under high load according to claim 2, characterized in that, The basic information includes the controller's function type and historical failure frequency; The step of performing rule matching on the controller classification model to identify the critical type of each controller in each network segment based on the vehicle's current operating mode and the real-time fault level includes the following steps: Based on the current vehicle operating mode and the function type of the controller, a preset function priority matrix is ​​retrieved to obtain the priority of the controller for each function type under the current vehicle operating mode; wherein, the function priority matrix is ​​used to define the priority of the controller for each function type under different vehicle operating modes; Based on the real-time fault level and the historical fault frequency of the controller, a preset fault level mapping table is retrieved to obtain the criticality of each controller corresponding to the real-time fault level; wherein, the fault level mapping table is used to define the association rules between different fault levels and controller criticality. The priority of each functional type of controller in the current operating mode of the vehicle and the criticality of each controller corresponding to the real-time fault level are weighted and fused to calculate the criticality evaluation value of each controller. Based on the criticality assessment value and a preset criticality threshold, the criticality type of each controller in each network segment is identified.

6. The adaptive adjustment method for OBD diagnostic sequences under high load according to claim 1, characterized in that, The step of dynamically adjusting the controller diagnostic sequence based on the current load rate of each network segment and the criticality type of each controller, combined with a preset load sensitivity coefficient table and the remaining load capacity of each network segment, includes the following steps: Based on the current load rate of each network segment and the criticality type of each controller, the load sensitivity coefficient table is retrieved to obtain the diagnostic sequence adjustment weight of each controller; The load sensitivity coefficient table is used to define the diagnostic sequence adjustment weights for critical and non-critical controllers within different load rate ranges. The diagnostic sequence adjustment factor of each controller is calculated based on the remaining load capacity and the diagnostic sequence adjustment weight of each controller. The diagnostic sequence of each controller is dynamically adjusted based on the diagnostic sequence adjustment factor and criticality type.

7. The OBD diagnostic sequence adaptive adjustment method under high load according to claim 6, characterized in that, The step of dynamically adjusting the controller diagnostic sequence based on the diagnostic sequence adjustment factor and criticality type of each controller includes the following steps: For the critical controller, if its diagnostic sequence adjustment factor is not lower than the first adjustment threshold, the original diagnostic frequency is maintained; if its diagnostic sequence adjustment factor is lower than the first adjustment threshold but not lower than the second adjustment threshold, its diagnostic frequency is reduced; if its diagnostic sequence adjustment factor is lower than the second adjustment threshold, its diagnostic communication is prioritized, and the communication time slot of the non-critical controller is temporarily occupied. For the non-critical controller, if its diagnostic sequence adjustment factor is not lower than the third adjustment threshold, the original diagnostic frequency is maintained; if its diagnostic sequence adjustment factor is lower than the third adjustment threshold but not lower than the fourth adjustment threshold, its diagnostic frequency is reduced; if its diagnostic sequence adjustment factor is lower than the fourth adjustment threshold, its diagnostic request is suspended.

8. An adaptive adjustment system for OBD diagnostic sequences under high load, characterized in that, Used to perform the OBD diagnostic sequence adaptive adjustment method under high load as described in any one of claims 1 to 7.

9. An adaptive adjustment device for OBD diagnostic sequences under high load, characterized in that, It includes a processor and a memory; the memory stores a computer program, and the processor executes the computer program to implement the OBD diagnostic sequence adaptive adjustment method under high load as described in any one of claims 1 to 7.

10. A vehicle, characterized in that, The vehicle integrates the OBD diagnostic sequence adaptive adjustment device under high load as described in claim 9.

Images