Controller hibernation test method, apparatus, system, and medium

Abstract

This application relates to the field of vehicle electronic control system technology, and discloses a method, apparatus, system, and medium for testing the sleep mode of a controller. The method includes sending a sleep command to the controller under test (DUT) and notifying a data acquisition unit connected to the DUT to perform data acquisition operations on the DUT; acquiring the acquired data sent by the data acquisition unit and filtering sleep characteristic data from the acquired data; and detecting whether the DUT has sleep anomalies based on the sleep characteristic data. Through multi-dimensional data acquisition and analysis, synchronous verification of the sleep state in the communication domain and power domain is achieved. It can perform multi-modal collaborative testing by combining bus communication status, power domain parameters, and multi-voltage domain output status, effectively detecting hidden faults in the controller's sleep process and ensuring sleep reliability.

Description

Technical Field

[0001] This application relates to the field of vehicle electronic control system technology, specifically to a method, apparatus, system, and medium for testing the sleep state of a controller. Background Technology

[0002] In related technologies, the verification of the sleep timing of the area controller is determined by sending a sleep command and monitoring whether the bus / Ethernet messages stop. The sleep criterion is singular and cannot comprehensively and accurately verify the potential hidden faults of the area controller during the sleep transition process. Summary of the Invention

[0003] This application provides a method, apparatus, system, and medium for testing the sleep mode of a controller. In a first aspect, this application provides a method for testing the sleep mode of a controller, applied to a host computer. The method includes: sending a sleep command to the controller under test (DUT) and notifying a data acquisition unit connected to the DUT to perform data acquisition operations on the DUT; acquiring the acquired data sent by the data acquisition unit and filtering out sleep characteristic data from the acquired data; and detecting whether the DUT has a sleep abnormality based on the sleep characteristic data.

[0004] Based on the above technical means, anomaly detection is performed based on multi-dimensional sleep characteristic data, which overcomes the limitations of traditional single bus criteria. It can comprehensively verify the power domain status, multi-voltage domain coordination, and potential hidden wake-up faults of the 48V area controller during the sleep transition process, thereby improving the accuracy and coverage of sleep test.

[0005] In one optional implementation, detecting whether the controller under test has a sleep anomaly based on sleep feature data includes: comparing the extracted sleep feature data with the corresponding preset timing window threshold; if all parameters in the sleep feature data fall within the corresponding preset timing window threshold range and the timing of the data is normal, then the sleep is qualified; if any parameter in the sleep feature data exceeds the corresponding preset timing window threshold range, or an abnormal timing pattern is detected in the data, then a sleep anomaly is determined; when a sleep anomaly is found, the fault type of the controller under test during the sleep process is determined.

[0006] Based on the above technical means, the efficiency and accuracy of hibernation testing are improved, and it is especially suitable for hibernation verification of complex systems such as 48V area controllers for new energy vehicles. In one optional implementation, when a sleep anomaly exists, the fault type of the controller under test during the sleep process is determined, including: judging whether the controller under test has a first fault based on the bus silence duration and the power sleep duration, wherein the bus silence duration is used to characterize the bus sleep time and the power sleep duration is used to characterize the sleep time of each power device in the controller under test.

[0007] Based on the above technical means, the accuracy and efficiency of sleep testing are improved, and its value is particularly prominent for complex systems with multiple voltage domains and high integration, such as 48V area controllers. In one optional implementation, the sleep characteristic data includes bus messages and input current waveforms. Determining whether the controller under test (DUT) has a first fault based on the bus silence duration and power sleep duration includes: querying the sleep trigger message and sleep end message in the bus messages respectively; determining the bus silence duration based on the time difference between the sleep trigger message and the sleep end message; analyzing the input current waveform to determine the duration it takes for the current of the DUT to drop to a preset first current threshold after the sleep trigger operation, thus obtaining the power sleep duration; and determining that the controller under test has a first fault when the difference between the bus silence duration and the power sleep duration is greater than the preset duration threshold.

[0008] Based on the above technical means, this application can clearly identify that the sleep characteristic data includes bus messages and input current waveforms, thereby providing an accurate data basis for subsequent calculation of sleep time in the communication domain and power domain.

[0009] In one optional implementation, the controller includes a 48V area controller, which includes multiple voltage domain outputs. The sleep characteristic data also includes the output voltage waveforms of each voltage domain. When a sleep anomaly exists, the fault type of the controller under test during the sleep process is determined. This also includes: obtaining the sleep duration and voltage drop slope of each voltage domain based on the output voltage waveforms of each voltage domain; if the sleep duration order of each voltage domain is different from the preset order, then the controller under test is determined to have a second fault, wherein the preset order includes that the sleep duration of each voltage domain is inversely proportional to the voltage of each voltage domain; if the voltage drop slope of any voltage domain is greater than a preset slope threshold, then the voltage transformation anomaly of the corresponding voltage domain is determined.

[0010] Based on the above technical means, potential problems such as current backflow or logic disorder that cannot be detected by relying solely on bus silence in traditional methods are avoided, thereby improving the comprehensiveness and accuracy of 48V area controller sleep test and ensuring the stability and low power consumption performance of the controller in sleep state.

[0011] In one optional implementation, when a hibernation anomaly exists, determining the fault type of the controller under test during the hibernation process further includes: acquiring the output port voltage of each voltage domain after hibernation; when the output port voltage of any voltage domain is greater than the corresponding preset voltage threshold, it is determined that the controller under test has a third fault.

[0012] Based on the above technical means, the problem that existing detection methods cannot detect such hidden faults with low power consumption is solved, avoiding the situation of misjudging the hibernation test as qualified, making the controller hibernation test more comprehensive and accurate, and improving the integrity and reliability of the hibernation test.

[0013] In one optional implementation, when a hibernation anomaly exists, determining the fault type of the controller under test during the hibernation process further includes: acquiring the output port current of the controller under test after hibernation; when the output port current is greater than a preset second current threshold, it is determined that the controller under test has a fourth fault.

[0014] Based on the above technical means, it is possible to identify latent power domain sleep anomalies that cannot be detected by the original detection methods, thereby improving the fault coverage of sleep test.

[0015] In one optional implementation, after sending a sleep command to the controller under test, the method further includes: injecting a disturbance voltage into the programmable power supply in the controller under test, and determining whether the disturbance voltage interferes with the controller under test based on the collected data after the disturbance voltage is injected.

[0016] Based on the above technical means, the comprehensiveness, reliability and robustness of the controller sleep test are improved, ensuring that the controller can still stably and reliably enter and maintain the sleep state in actual complex power supply environments. In an optional implementation, the method further includes: after the controller under test (DUT) goes into sleep mode, simulating the generation of back electromotive force (EMF) at the load end of the DUT; if the DUT is awakened by the back EMF, then it is determined that the DUT has a fifth fault.

[0017] Based on the above technical means, this solution can more reliably verify its hibernation performance and improve the completeness and accuracy of controller hibernation testing. Secondly, this application provides a sleep test device for a controller, the device comprising: a sending module for sending a sleep command to the controller under test and notifying a data acquisition unit connected to the controller under test to perform data acquisition operations on the controller under test; a filtering module for acquiring the acquired data sent by the data acquisition unit and filtering out sleep characteristic data from the acquired data; and a judgment module for detecting whether the controller under test has a sleep abnormality based on the sleep characteristic data.

[0018] Thirdly, this application provides a testing system, including: a programmable power supply, a communication module, a current sensor, a voltage sensor, a data acquisition unit, and a host computer. The programmable power supply is connected to the controller under test (DUT) to provide power to the DUT; the communication module is connected to the DUT to transmit sleep commands and bus messages; the current sensor is connected to the power input terminal of the DUT to capture current information during the DUT's sleep process; multiple voltage sensors are connected to the output ports of each voltage domain of the DUT to capture voltage information during the DUT's sleep process, and the voltage domain output ports include at least one of a 48V load output port, a 12V bus output port after internal DC-DC voltage conversion, a 5V low-dropout linear regulator output port, and a 3V low-dropout linear regulator output port; the data acquisition unit is connected to the DUT to acquire the transmitted data of the DUT during the test; the host computer is connected to the communication module and the data acquisition unit for time synchronization and analysis of the acquired data.

[0019] Fifthly, this application provides a computer-readable storage medium storing computer instructions for causing a computer to execute the sleep test method of the controller of the first aspect or any corresponding embodiment described above.

[0020] In a sixth aspect, this application provides a computer program product, including computer instructions for causing a computer to execute the sleep test method of the controller of the first aspect or any corresponding embodiment described above. Attached Figure Description

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

[0022] Figure 1 This is a schematic flowchart of a first method for testing the sleep mode of a controller according to an embodiment of this application; Figure 2 This is a second flowchart illustrating the sleep test method for a controller according to an embodiment of this application; Figure 3 This is a schematic diagram of the third process of the controller sleep test method according to an embodiment of this application; Figure 4 This is a schematic diagram of the normal sleep timing according to an embodiment of this application; Figure 5 This is a schematic diagram of DC-DC no-load anomaly according to an embodiment of this application; Figure 6 This is a schematic diagram of the residual output port voltage according to an embodiment of this application; Figure 7 A structural block diagram of a controller sleep test device according to an embodiment of this application; Figure 8 This is a schematic diagram of a test system according to an embodiment of this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of 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, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] It is understood that before using the technical solutions disclosed in the various embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

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

[0026] In related technologies, controller sleep test methods mainly rely on bus communication status for judgment. When applied to 48V area controllers, these methods have limitations such as a single sleep criterion, multi-voltage domain coupling, energy shutdown delay, and hidden wake-up by high-voltage loads. This results in the inability to fully verify the power domain status, multi-voltage domain coordination, and potential hidden faults, leading to inaccurate sleep test results and failing to meet the complex verification requirements of area controllers under 48V electrical architectures.

[0027] To address this, this application proposes a sleep test method for a controller, applied to a host computer, such as... Figure 1 As shown, the method includes: Step S101: Send a sleep command to the controller under test and notify the data acquisition unit connected to the controller under test to perform data acquisition operation on the controller under test.

[0028] The host computer, in this context, refers to the computer system responsible for issuing control commands, receiving data, and processing and analyzing it within the testing system. As the central hub of the entire testing process, it coordinates the execution of various testing tasks.

[0029] The controller under test (DUT) refers to an electronic control unit that requires verification of its sleep function. In the field of new energy vehicles, it can be a zone controller, such as a 48V zone controller, responsible for managing specific functional areas of the vehicle.

[0030] A sleep command is a command sent by the host computer to the controller under test (DUT) to trigger it to enter a low-power sleep state. This command is typically transmitted via a specific communication protocol.

[0031] A data acquisition unit is a device connected to the controller under test (DUT) to monitor and record various physical quantities or logical states of the DUT in real time during its sleep state. It may include sensors, oscilloscopes, bus analyzers, etc., to acquire data such as voltage, current, and bus messages.

[0032] Specifically, the host computer sends a sleep command to the controller under test (DUT) to trigger it into sleep mode. Simultaneously, the host computer instructs the data acquisition unit connected to the DUT to initiate data acquisition. As one implementation, the sleep command can be sent to the DUT via a communication interface such as CAN bus, Ethernet, or LIN bus. The data acquisition unit can be configured to begin acquisition immediately upon receiving the notification from the host computer, or to begin acquisition after a preset delay following the transmission of the sleep command. For example, the data acquisition unit can be set to continuously acquire data for a period of time to cover the entire process of the DUT transitioning from normal operation to complete sleep mode.

[0033] Step S102: Obtain the collected data sent by the data acquisition unit, and filter out the dormant feature data from the collected data.

[0034] The acquired data refers to the raw data set obtained by the data acquisition unit during the sleep state of the controller under test. This data reflects various operating parameters of the controller under test during sleep transition and sleep state.

[0035] Sleep characteristic data refers to key data extracted from raw collected data that can directly or indirectly characterize the sleep state of the controller under test. It serves as the basis for determining whether sleep is normal.

[0036] Specifically, the host computer acquires the data sent by the data acquisition unit and filters out sleep characteristic data from the acquired data. The acquired data can include various types, such as bus communication messages, power input current, and output voltages of various voltage domains. The host computer can use preset rules or algorithms to perform preliminary processing on this raw acquired data to identify and extract the parts directly related to the sleep state determination. For example, a time window can be set to retain only the data within that time window; or, filtering can be performed based on data type to retain only specific types of waveform or message data.

[0037] Step S103: Based on the sleep characteristic data, detect whether the controller under test has a sleep abnormality.

[0038] Among them, hibernation abnormality refers to the failure of the controller under test to enter or maintain a normal low-power hibernation state as required by the design after executing the hibernation command, or the occurrence of unexpected behavior patterns during the hibernation process.

[0039] Specifically, based on the selected sleep characteristic data, the system detects whether the controller under test (DUT) exhibits sleep anomalies. The detection process may include analyzing the sleep characteristic data to determine if it conforms to the expected sleep mode. For example, it may involve observing changes in the level of specific signals or the cessation of message transmission. If the detection results show that the sleep characteristic data does not conform to the preset normal sleep mode, the DUT is determined to have a sleep anomaly.

[0040] It is understood that the controller sleep test method in this embodiment ensures the integrity of data throughout the entire sleep process by coordinating the sending of sleep commands and data acquisition simultaneously through a host computer. By filtering the multi-dimensional acquired data, focusing on sleep characteristic data, interference from irrelevant data is avoided. Therefore, anomaly detection based on multi-dimensional sleep characteristic data overcomes the limitations of traditional single-bus criteria, and can comprehensively verify the power domain state, multi-voltage domain coordination, and potential hidden wake-up faults of the 48V area controller during the sleep transition process, improving the accuracy and coverage of sleep testing. In some of the solutions mentioned above in this application, a method is proposed to detect whether the controller under test has a sleep anomaly based on sleep feature data in order to complete the sleep test of the controller. However, in this process, the original simple detection method can only determine whether sleep has been completed. It cannot accurately identify anomalies from the two dimensions of parameters and timing, nor can it further determine the fault type after the anomaly occurs. It is difficult to adapt to the sleep test requirements of controllers with multi-voltage domain and multi-state coupling, and it cannot detect hidden faults such as communication sleep but power domain not sleep, and cannot meet the requirements of comprehensive and accurate testing.

[0041] In response, this application further proposes a method for testing the sleep state of a controller, such as... Figure 2 As shown, the method includes: Step S201: Send a sleep command to the controller under test (DUT) and notify the data acquisition unit connected to the DUT to perform data acquisition operations on the DUT. See details... Figure 1 Step S101 in the embodiment will not be described again here.

[0042] Step S202: Acquire the collected data sent by the data acquisition unit, and filter out the dormant characteristic data from the collected data. See details... Figure 1 Step S101 in the embodiment will not be described again here.

[0043] Step S203: Based on the sleep characteristic data, detect whether the controller under test has a sleep anomaly. Specifically, this includes: Step S2031: Compare the extracted dormant feature data with the corresponding preset time window threshold.

[0044] Step S2032: If all parameters in the hibernation feature data fall within the corresponding preset time window threshold range, and the time sequence of the data is normal, then the hibernation is qualified.

[0045] Step S2033: If any parameter in the dormant feature data exceeds the corresponding preset time window threshold range, or if an abnormal time pattern is detected in the data, then it is determined that there is a dormant abnormality.

[0046] Step S2034: When a hibernation anomaly exists, determine the fault type of the controller under test during the hibernation process.

[0047] Specifically, comparing the extracted sleep characteristic data with the corresponding preset timing window thresholds involves comparing various sleep-related data collected from the controller under test (DUT) with pre-set numerical ranges and time series standards used to define normal sleep behavior. Sleep characteristic data may include, but is not limited to, bus messages, input current waveforms, and output voltage waveforms for each voltage domain. The preset timing window thresholds are determined based on the DUT's design specifications and expected sleep behavior; for example, the voltage of a certain signal should drop to a certain range within a specific time period, or an event should occur within a specific time window. The comparison operation can be implemented in various ways. For example, numerical range comparison can be used, checking each parameter value in the sleep characteristic data, such as current and voltage, to determine whether it falls between the preset minimum and maximum values; or timing event comparison can be used, verifying whether the occurrence time, duration, or sequence of key events during the sleep process, such as bus silence and voltage domain shutdown, conform to the preset time window or sequence requirements.

[0048] If all parameters in the hibernation feature data fall within the corresponding preset timing window threshold range, and the timing of the data is normal, then the hibernation is considered successful. This indicates that during the hibernation process, the numerical performance of all key parameters and the timing logic of events of the controller under test completely conform to the expected normal state. For example, the system can compare all collected parameters one by one and verify all timing events one by one using logical AND judgment. Only when all comparison results are "qualified" is the hibernation finally determined to be successful. Alternatively, a hibernation state transition model can be preset, with the collected data as input. If the controller completes all state transitions according to the preset state machine path and time nodes, then the hibernation is considered successful.

[0049] If any parameter in the dormant feature data exceeds the corresponding preset timing window threshold range, or if an abnormal timing pattern is detected in the data, a dormant anomaly is determined to exist. This means that as long as any key indicator deviates during the dormant process, whether it is a numerical out-of-bounds error or a timing disorder, it will be identified as an anomaly. For example, threshold out-of-bounds detection can be used, where any parameter value, such as current or voltage, exceeding its preset upper limit or falling below its preset lower limit will trigger an anomaly determination. Alternatively, timing violation detection can be used, where an event that does not occur within a specified time, occurs in the wrong order, or lasts for too long or too short will trigger an anomaly determination.

[0050] When a sleep anomaly is detected, the fault type of the controller under test (DUT) during the sleep process is determined. The aim is to further diagnose the detected sleep anomaly and identify the specific cause or fault mode leading to the anomaly. For example, a fault rule base can be established through rule-based matching, matching detected anomaly characteristics, such as which parameter is abnormal and the timing pattern of the anomaly, with predefined fault types to identify the fault. Alternatively, decision tree analysis can be used, constructing a decision tree based on a series of preset judgment conditions, such as bus quiescent duration, power sleep duration, and voltage domain drop slope, gradually narrowing down the fault range until the specific fault type is determined.

[0051] It is understood that, through the above technical solution, this application can comprehensively and accurately detect the sleep state of the controller from both parameter and timing dimensions, making up for the shortcomings of traditional single detection methods. This improves the efficiency and accuracy of sleep testing, and is particularly suitable for sleep verification of complex systems such as 48V area controllers in new energy vehicles. In some of the embodiments described above in this application, the fault type of the controller under test during the sleep process is determined to accurately locate different sleep anomalies and provide a basis for subsequent fault diagnosis. However, in its implementation, there is no specific judgment method for common sleep anomalies such as the asynchrony between the communication domain and the power domain. The existing technology only relies on the bus status to determine whether the sleep is normal, and cannot identify hidden faults where the bus has been silenced but the power domain has not yet gone into sleep. Such faults will cause the static current of the controller to exceed the standard, affecting the power consumption control of the whole vehicle and failing to meet the sleep verification requirements of the 48V area controller.

[0052] In response, this application further proposes a method for determining the fault type of the controller under test during the sleep process when a sleep anomaly exists, including: Step a1: Based on the bus silence duration and power sleep duration, determine whether the controller under test has a first fault. The bus silence duration is used to characterize the bus sleep time, and the power sleep duration is used to characterize the sleep time of each power device in the controller under test.

[0053] Specifically, this judgment step aims to identify a specific type of hibernation anomaly: the "first fault," where the communication domain has entered hibernation but the power domain has not yet fully entered hibernation. This fault may cause the controller to appear to be in hibernation, but in reality, it may still be consuming unnecessary power. Judgment can be made by comparing the relationship between the bus quiescent duration and the power hibernation duration. For example, a reasonable difference range or timing relationship can be set. If the difference exceeds this range or does not conform to the preset timing, the first fault is identified. Another implementation is to compare the bus quiescent duration and the power hibernation duration with their respective preset acceptable thresholds. If the bus quiescent duration is acceptable but the power hibernation duration is unacceptable, the first fault can be preliminarily identified. The bus quiescent duration refers to the time required for the controller under test to stop its bus communication activity after receiving a hibernation command. This duration is a key indicator of whether the controller's communication domain has successfully entered hibernation. Specifically, it can be determined by monitoring the message transmission on the controller's external communication buses, such as CAN, LIN, and Ethernet. For example, the duration from the moment the hibernation command is issued until no valid message transmission is detected on the bus can be recorded. Alternatively, a bus activity threshold can be set. When the data traffic or number of messages on the bus consistently falls below this threshold, the bus is considered to enter a silent state, and the duration is recorded. Power sleep time refers to the time required for the various power devices within the controller under test (DUT), such as DC-DC converters, voltage regulators, and MOSFETs, to transition from an operating state to a low-power or off state after receiving a sleep command. This duration reflects the actual sleep progress of the controller's power domain. Specifically, this can be achieved by monitoring the overall input current waveform of the DUT and recording the time required from the moment the sleep command is issued until the input current stabilizes and reaches the preset low-power threshold. Another implementation method is to monitor the voltage or current changes at key power output ports within the controller, and record the time it takes for all key power outputs to drop to their preset sleep state values.

[0054] It is understandable that by introducing two key parameters—bus silence duration and power sleep duration—and using their relationship to determine the presence of a primary fault, this application effectively solves the problem in existing technologies that rely solely on bus status to determine sleep mode and cannot identify hidden faults in the power domain. This improves the accuracy and efficiency of sleep mode testing, and its value is particularly prominent for complex systems with multiple voltage domains and high integration, such as 48V area controllers. In some embodiments described above in this application, a method is proposed to determine whether the controller under test (DUT) has a first fault based on the bus quiescent duration and power sleep duration, in order to determine the specific fault type after the controller detects a sleep anomaly. The bus quiescent duration is used to characterize the bus sleep time, and the power sleep time is used to characterize the sleep time of each power device in the DUT. However, in its implementation, no specific method for obtaining the bus quiescent duration and power sleep duration is given, nor are specific rules for judging faults based on the two durations clearly defined. This cannot solve the problem that traditional tests rely solely on the bus status to determine whether sleep is successful, and cannot detect faults such as the bus being quiescent but the power domain not sleeping properly. Such faults can cause the controller's static current to exceed the limit, but cannot be detected by traditional methods.

[0055] In response, this application further proposes sleep characteristic data including bus messages and input current waveforms, and determines whether the controller under test has a first fault based on the bus silence duration and power sleep duration, including: Step b1: Query the sleep trigger message and sleep end message in the bus messages respectively.

[0056] Step b2: Determine the bus silence duration based on the time difference between the sleep trigger message and the sleep end message.

[0057] Step b3: Analyze the input current waveform to determine the duration when the current of the controller under test drops to the preset first current threshold after the sleep trigger operation, and obtain the power sleep duration.

[0058] Step b4: When the difference between the bus silence duration and the power sleep duration is greater than the preset duration threshold, it is determined that the controller under test has a first fault.

[0059] Bus messages are data frames sent and received by the controller on the communication bus, reflecting the activity status of the communication domain and communication events during sleep processes. Input current waveforms directly reflect the overall power consumption changes of the controller under test (DUT), especially the current consumption of individual devices in the power domain, serving as a crucial basis for determining whether the power domain has entered a low-power state. Bus messages can be captured and recorded in real time using automotive communication bus protocol analyzers such as CAN, LIN, FlexRay, and Ethernet. Input current waveforms can be continuously sampled and recorded using a high-precision current probe or current sensor connected to the power input of the DUT, along with an oscilloscope or data acquisition device. Alternatively, a diagnostic module can be integrated within the DUT to output key bus communication events and internal current sampling data through a specific diagnostic interface, which can then be received and analyzed by a host computer.

[0060] The goal is to accurately identify the start point of the controller's hibernation process and the end point of the communication domain's hibernation completion from the captured bus messages by querying the hibernation trigger message and hibernation end message. The hibernation trigger message is a specific communication message sent by the host computer or other system modules to the controller under test (DUT) instructing it to enter hibernation mode. The hibernation end message is the last communication message that the DUT may send after completing the hibernation operation in the communication domain, or the last valid message before the bus becomes silent. The host computer or test system can be pre-configured to identify specific message IDs and data contents as identifiers for hibernation trigger and end messages, for example, by filtering by CAN ID or matching message content. Alternatively, the bus communication protocol specification can be analyzed to determine messages with specific semantics in the hibernation process as trigger and end markers, and corresponding parsing algorithms can be written for identification.

[0061] The bus silence duration is determined by the time difference between the sleep trigger message and the sleep end message. This time difference quantifies the time required for the communication domain of the controller under test to complete bus communication silence from receiving the sleep command. The calculation of the time difference directly reflects whether the sleep efficiency and timing of the communication domain meet expectations. In the host computer or data analysis software, the timestamps of the sleep trigger message and the sleep end message are recorded, and then the difference between these two timestamps is directly calculated. If the sleep end message is difficult to define precisely, the timestamp of the sleep trigger message can be used as the starting point, and the point where bus communication completely stops (i.e., the point in time when no new messages appear) can be used as the ending point to calculate the time difference.

[0062] By analyzing the input current waveform, the duration for the current of the controller under test (DUT) to drop to a preset first current threshold after a sleep trigger operation is determined, thus obtaining the power sleep duration. This duration aims to quantify the time required for the power domain of the DUT to reduce its power consumption to a normal sleep level after receiving a sleep command. The input current waveform directly reflects the activity state of the power devices inside the controller, and the preset first current threshold serves as a benchmark for determining whether the power domain has truly entered a low-power sleep state. Digital signal processing is performed on the acquired input current waveform to identify the point in time when the current begins to decrease from the normal operating level and first reaches or falls below the preset first current threshold. Then, the time difference between this point and the sleep trigger operation time, such as the timestamp of the sleep trigger message, is calculated. Moving average filtering or threshold detection algorithms can be used to smooth the current waveform and accurately identify the point in time when the current drops below the threshold. The preset first current threshold is typically set based on the design specifications of the DUT and the typical current consumption value in low-power mode.

[0063] The core logic for determining the existence of a first fault in the controller under test (DUT) is to identify it when the difference between the bus quiescent duration and the power sleep duration exceeds a preset duration threshold. The bus quiescent duration reflects the sleep speed of the communication domain, while the power sleep duration reflects the sleep speed of the power domain. A difference between the two, especially when the communication domain is quiescent but the power domain has not yet reached a low-power state, indicates an anomaly. The preset duration threshold serves as the tolerance standard for determining whether this difference constitutes a fault. In the host computer or test software, the absolute difference between the determined bus quiescent duration and the power sleep duration is calculated and compared with the preset duration threshold. If the difference exceeds the threshold, a fault alarm is triggered and recorded as the first fault. The preset duration threshold can be calibrated based on the design requirements of the DUT, system response time, and empirical data. For example, it can be set to several milliseconds to tens of milliseconds to allow for normal timing deviations while capturing power domain sleep delays.

[0064] It is understood that, through the above technical solution, this application can clearly define that the sleep characteristic data includes bus messages and input current waveforms, thus providing an accurate data foundation for subsequent calculation of sleep time in the communication domain and power domain, and solving the problem that single data cannot simultaneously cover the sleep states of the communication domain and power domain. It also solves the problem that excessive controller static current cannot be detected by traditional methods, improving the comprehensiveness and accuracy of controller sleep fault detection. In some embodiments described above in this application, a method is proposed to determine the fault type of the controller under test during the sleep process when a sleep anomaly occurs, in order to detect sleep anomaly problems in the controller. However, in its implementation, for 48V area controllers with multiple voltage domain outputs, the original solution cannot effectively identify sleep faults caused by incorrect turn-off timing of multiple voltage domains or abnormal voltage drop. Since the 48V area controller needs to manage multiple voltage platforms with different voltages, the turn-off sequence of the loads in each voltage domain must strictly follow the design requirements; otherwise, it will cause current backflow or logic disorder problems. The original detection solution cannot effectively monitor and verify such anomalies of multi-voltage domain coordinated turn-off, and therefore cannot accurately locate the corresponding fault type.

[0065] In this regard, this application further proposes that the controller includes a 48V area controller, which includes multiple voltage domain outputs, and the sleep characteristic data also includes the output voltage waveforms of each voltage domain. When a sleep anomaly exists, determining the fault type of the controller under test during the sleep process also includes: Step c1: Based on the output voltage waveform of each voltage domain, obtain the sleep duration and voltage drop slope of each voltage domain.

[0066] Step c2: When the sleep duration order of each voltage domain is different from the preset order, it is determined that the controller under test has a second fault. The preset order includes the sleep duration of each voltage domain being inversely proportional to the voltage of each voltage domain.

[0067] Step c3: When the voltage drop slope of any voltage domain is greater than the preset slope threshold, the voltage transformation of the corresponding voltage domain is determined to be abnormal.

[0068] Specifically, the controller includes a 48V area controller, which typically refers to an area controller used in the 48V electrical architecture of new energy vehicles. This controller, as a core component, is responsible for managing and controlling specific functional areas of the vehicle and integrates multiple functions such as power management, communication, and control. This 48V area controller usually needs to manage multiple voltage platforms, such as 48V, 12V, 5V, and 3.3V, to meet the power supply requirements of different loads. The 48V area controller includes multiple voltage domain outputs, meaning that it integrates multiple independent power conversion modules or voltage regulator circuits. Each module or circuit is responsible for outputting power at a specific voltage level, forming an independent voltage domain. For example, a 48V area controller might contain a DC-DC module that converts 48V to 12V, an LDO module that converts 12V to 5V, and a voltage regulator module that converts 5V to 3.3V. These 12V, 5V, and 3.3V outputs represent different voltage domain outputs.

[0069] The sleep characteristic data also includes the output voltage waveforms of each voltage domain. These waveforms refer to the curves showing the voltage changes over time at each voltage domain output port, which are synchronously acquired and recorded by the data acquisition unit during the process of the controller under test entering sleep mode. These voltage waveforms can intuitively reflect the shutdown process and state of each voltage domain. For example, a high-precision oscilloscope or multi-channel data acquisition device can be used to continuously monitor and record the voltage value at the output terminal of each voltage domain after the sleep command is issued, forming a continuous voltage-time curve.

[0070] Based on the output voltage waveforms of each voltage domain, the sleep duration and voltage drop slope of each voltage domain are obtained. The sleep duration of each voltage domain refers to the time required from a specific moment when a sleep command is triggered or the voltage begins to drop until the output voltage of that voltage domain stably drops to a preset low-power state threshold, such as approaching 0V or falling below a certain safe voltage value. This duration can be calculated by analyzing the voltage waveform to identify the start and end points of the voltage drop. For example, a voltage threshold can be set, with the first time the voltage falls below this threshold serving as the end point of sleep, and the start point being the moment the sleep command is issued. The voltage drop slope of each voltage domain refers to the rate at which its output voltage changes with time during the voltage domain's shutdown process. This slope can be obtained by differentiating the voltage waveform or by selecting a specific time period during the voltage drop process and calculating the ratio of the voltage change to the time change within that time period. For example, the time required for the voltage to drop from 90% to 10% of its nominal value can be calculated, and the average drop slope can be calculated accordingly.

[0071] If the sleep duration order of each voltage domain differs from the preset order, a second fault is identified in the controller under test (DUT). The preset order is an ideal sequence of sleep durations for each voltage domain, pre-defined according to the design specifications and power management logic of the 48V area controller. This preset order typically follows certain physical or logical rules. For example, to prevent current backflow or logic disruption, higher voltage domains, such as 12V, are usually required to have slower or later shutdown speeds than lower voltage domains, such as 5V and 3.3V. The preset order includes the fact that the sleep duration of each voltage domain is inversely proportional to its voltage. This means that higher voltage domains should have longer sleep durations (i.e., slower shutdowns), while lower voltage domains should have shorter sleep durations (i.e., faster shutdowns). For example, if the design requires the 12V domain to have the longest sleep duration, followed by the 5V domain, and the 3.3V domain to have the shortest, then if the actual sleep durations obtained during testing do not conform to this order, a second fault is identified. The second fault usually refers to a power management logic error, that is, when the power management unit inside the controller executes the hibernation command, it fails to effectively control each voltage domain according to the preset shutdown sequence.

[0072] When the voltage drop slope of any voltage domain exceeds a preset slope threshold, a voltage transformation anomaly is identified for that voltage domain. The preset slope threshold is a maximum allowable voltage drop rate set based on the normal discharge characteristics and design requirements of the voltage domain. This threshold ensures that the voltage drops smoothly and in a controlled manner during shutdown, avoiding excessively fast or slow voltage changes. For example, if a voltage domain has a large capacitance, its voltage drop slope should be relatively small. If the actual detected slope is much larger than this preset threshold, an anomaly may exist. A voltage transformation anomaly refers to a voltage drop rate exceeding the normal range during the dormant process of that voltage domain. This may indicate an abnormal discharge path, incomplete load disconnection, internal short circuit, or power management circuit failure in that voltage domain, leading to excessively rapid voltage discharge.

[0073] It is understood that, through the above technical solution, this application can effectively solve the problem of difficulty in identifying abnormalities in the multi-voltage domain coordinated shutdown timing and voltage drop during sleep testing of 48V area controllers. By incorporating the output voltage waveforms of each voltage domain into the sleep characteristic data, and further analyzing the sleep duration and voltage drop slope of each voltage domain, this application can accurately identify secondary faults such as "power management logic errors" where the shutdown sequence of multiple voltage domains does not meet design requirements, as well as "voltage transformation anomalies" where the voltage discharge process is abnormal. This avoids potential problems such as current backflow or logic disorder that cannot be detected by traditional methods that rely solely on bus silence, thereby improving the comprehensiveness and accuracy of sleep testing for 48V area controllers and ensuring the stability and low power consumption performance of the controller in sleep mode. In some embodiments described above, this application proposes determining the fault type of the controller under test during its sleep process when sleep anomalies occur, in order to comprehensively detect sleep anomaly faults in the controller. However, in its implementation, previous solutions only focus on bus sleep timing, power sleep duration, and shutdown timing of multiple voltage domains, failing to detect hidden faults such as residual voltage at the output ports of each voltage domain after the controller has gone into sleep mode. This can lead to excessive static current in the controller and continuous low power consumption by the downstream load. Traditional bus detection methods and fault detection methods that only target timing cannot detect these problems. Especially for 48V area controllers with multiple voltage domains, large capacitors at the output end are prone to residual voltage, which cannot be covered by existing detection steps and can easily lead to false judgments of sleep mode compliance. Therefore, corresponding fault detection steps are needed to detect these types of faults.

[0074] In response, this application further proposes a method for determining the fault type of the controller under test during the sleep process when a sleep anomaly exists, which also includes: Step d1: Obtain the output port voltage of each voltage domain after it has gone into sleep mode; Step d2: When the output port voltage of any voltage domain is greater than the corresponding preset voltage threshold, it is determined that the controller under test has a third fault.

[0075] Specifically, obtaining the output port voltage after each voltage domain enters the sleep state aims to detect whether there is any undue voltage residue at the output ports of each voltage domain after the controller enters the sleep state. This is crucial for discovering micro-power consumption problems caused by incomplete capacitor discharge or failed discharge circuits. In actual operation, through a data acquisition unit, such as a high-precision voltmeter, oscilloscope, or multi-channel data recorder, after the controller under test receives the sleep command and has passed a sufficient long sleep stabilization time, the voltage of the output port of each voltage domain is measured. For example, for a 48V area controller, the outputs of multiple voltage domains such as 48V, 12V, 5V, 3.3V, etc. may need to be measured. In addition, a voltage monitoring module can also be integrated inside the controller under test. After the controller enters the sleep state, this module samples the output voltage of each voltage domain periodically or at specific time points, and sends the sampling results to the data acquisition unit through a low-power communication interface, such as SPI or I2C.

[0076] On this basis, when the output port voltage of any voltage domain is greater than the corresponding preset voltage threshold, it is determined that the controller under test has a third fault. This judgment criterion is used to identify voltage residue faults. By comparing the actually measured voltage with the preset qualified standard, it is possible to quantitatively judge whether there is an abnormality. The preset voltage threshold can be set according to the design specifications of the controller under test, the rated voltage of each voltage domain, and the upper limit of the allowable residual voltage. For example, for a voltage domain with a nominal voltage of 5V, its preset voltage threshold may be set to 0.1V or 0.05V, indicating that when the voltage is higher than this value, it is considered abnormal. This comparison process can be implemented by a software algorithm in the host computer. At the same time, the preset voltage threshold can also be dynamically adjusted, for example, fine-tuned according to factors such as ambient temperature and controller load conditions. The comparison logic can be programmed in the host computer. When it is detected that the output voltage of any voltage domain exceeds its corresponding preset threshold, the system triggers an alarm and records it as a third fault.

[0077] It can be understood that through the above technical solutions, in the existing sleep anomaly fault classification detection framework, this application adds a detection step for output voltage residue faults, which can effectively detect hidden sleep faults that cannot be found by existing solutions. It solves the problem that existing detection methods cannot discover such micro-power consumption hidden faults, avoids misjudging the sleep as qualified, makes the controller sleep test more comprehensive and accurate, and improves the integrity and reliability of the sleep test. In some of the embodiments described above in this application, a method is proposed to determine the fault type of the controller under test during the sleep process when a sleep anomaly exists, in order to classify and locate different sleep anomalies, facilitating subsequent troubleshooting and rectification. However, in its implementation, the existing fault determination dimensions only cover the detection of anomalies in bus timing and voltage-related parameters, and do not cover issues such as abnormal output port current after the controller goes into sleep mode. For example, after a 48V area controller goes into sleep mode, there may be PCB leakage, MOSFETs not being completely turned off, etc. These problems will cause the controller's static current to exceed the standard, which cannot be detected by bus communication status detection or voltage parameter detection. The original fault determination scheme cannot accurately locate such hidden power domain sleep faults.

[0078] In response, this application further proposes a method for determining the fault type of the controller under test during the sleep process when a sleep anomaly exists, which also includes: Step e1: Obtain the output port current of the controller under test after it goes into sleep mode.

[0079] Step e2: When the output port current is greater than the preset second current threshold, it is determined that the controller under test has a fourth fault.

[0080] Specifically, in acquiring the output port current of the controller under test (DUT) after it enters sleep mode, this step aims to accurately measure the actual current consumption at its output port after the DUT enters and stabilizes in sleep mode. This current value is a key indicator for evaluating the quality of the controller's sleep mode, particularly whether there is abnormal leakage or incomplete shutdown. One approach is to use a high-precision current sensor, such as a Hall effect sensor or a shunt resistor connected in series with the output port of the DUT, along with an amplifier circuit, to convert the current signal into a voltage signal, which is then sampled and digitized by a data acquisition unit. Another approach is to directly measure the current at the output port after sleep mode has stabilized using a clamp meter or a high-precision digital multimeter. This method is suitable for manual or semi-automatic testing in a laboratory environment. Furthermore, for highly integrated test systems, miniature current probes can be pre-embedded in the test fixture and integrated with the data acquisition unit to achieve automated, high-frequency current data acquisition.

[0081] When the output port current exceeds a preset second current threshold, a fourth fault is identified in the controller under test (DUT). The preset second current threshold represents the maximum allowable static current value at the output port of the DUT in normal sleep mode. Any current exceeding this threshold indicates an anomaly and is classified as a fourth fault. One implementation involves the host computer receiving the output port current data from the data acquisition unit and comparing the real-time current value with the preset second current threshold stored in a database or configuration file using a software algorithm. If the real-time value exceeds the threshold, the fourth fault determination is triggered. Another implementation involves integrating a comparator circuit within the data acquisition unit to perform a hardware comparison between the acquired current signal, or its converted voltage signal, and a reference voltage representing the preset second current threshold. If an exceedance is detected, a fault signal is immediately generated and reported to the host computer. The setting of the preset second current threshold should be based on the DUT's design specifications, device datasheet, and actual power consumption test data. A certain margin is typically allowed to avoid false positives, but it must be sufficiently stringent to capture minor anomalies.

[0082] It is understandable that, through the above technical solution, this application adds the detection dimension of output port current on the basis of the original fault classification and judgment, which can identify the hidden power domain sleep abnormalities that cannot be detected by the original detection method, and improve the fault coverage of sleep test.

[0083] In some of the solutions mentioned above in this application, a method is proposed to collect data and detect whether the sleep mode of the controller under test is abnormal after the host computer sends a sleep command to the controller under test, so as to complete the sleep test of the controller. However, in this process, the original solution can only test the sleep state of the controller under normal power supply conditions. It cannot verify the anti-interference capability of the controller when it encounters power voltage disturbance during the sleep process, and cannot find the sleep abnormality problem that may occur when there is power fluctuation disturbance in the actual application scenario. It cannot meet the reliability test requirements of controller sleep mode covering complex working conditions.

[0084] In response, this application further proposes a sleep test for the controller, such as... Figure 3 As shown, the method includes: Step S301: Send a sleep command to the controller under test (DUT) and notify the data acquisition unit connected to the DUT to perform data acquisition operations on the DUT. See details... Figure 1 Step S101 in the embodiment will not be described again here.

[0085] Step S302: Acquire the collected data sent by the data acquisition unit, and filter out the dormant characteristic data from the collected data. See details... Figure 1 Step S101 in the embodiment will not be described again here.

[0086] Step S303: Based on the sleep characteristic data, detect whether the controller under test has a sleep anomaly. Specifically, this includes: Step S3031: Compare the extracted dormant feature data with the corresponding preset time-series window threshold. See details... Figure 2 Step S2031 in the embodiment will not be described again here.

[0087] Step S3032: If all parameters in the hibernation feature data fall within the corresponding preset time window threshold range, and the timing of the data is normal, then the hibernation is qualified. (See details...) Figure 2 Step S2032 in the embodiment will not be described again here.

[0088] Step S3033: If any parameter in the dormant feature data exceeds the corresponding preset time window threshold range, or if an abnormal time pattern is detected in the data, then a dormant anomaly is determined to exist. (See details...) Figure 2 Step S2033 in the embodiment will not be repeated here.

[0089] Step S3034: When a sleep disorder occurs, determine the fault type of the controller under test during the sleep process. See details... Figure 2 Step S2034 in the embodiment will not be described again here.

[0090] Step S304: Inject a disturbance voltage into the programmable power supply of the controller under test, and determine whether the disturbance voltage interferes with the controller under test based on the collected data after the disturbance voltage is injected.

[0091] Specifically, "injecting disturbance voltage into the programmable power supply of the controller under test" refers to superimposing or applying a non-ideal voltage signal onto the supply voltage of the controller under test by controlling its internal or closely connected programmable power supply after the controller under test receives a sleep command. For example, the programmable power supply can be controlled by a host computer to output a preset voltage drop waveform during the critical transition from operating mode to sleep mode of the controller under test to simulate a momentary undervoltage situation. Alternatively, the programmable power supply can superimpose high-frequency noise or periodic ripple voltage during the sleep transition to test the controller's immunity to power supply noise. In addition, the programmable power supply can simulate transient overvoltage of the power supply, such as raising the supply voltage to a certain peak value for a short period of time and then quickly restoring it, to test the controller's sleep stability under overvoltage impact.

[0092] "Determining whether a disturbance voltage interferes with the controller under test (DUT) based on the acquired data after the disturbance voltage is injected" refers to analyzing various operating parameters collected by the data acquisition unit after the disturbance voltage is injected to evaluate the internal state and behavior of the DUT under disturbance, and then determining whether its sleep process still conforms to the expected behavior pattern and performance indicators. Acquired data may include bus messages, input current waveforms, and output voltage waveforms for each voltage domain. For example, sleep characteristic data after the disturbance voltage is injected, such as bus silence duration, power sleep duration, sleep duration for each voltage domain, and voltage drop slope, can be compared with baseline data or preset thresholds under no-disturbance conditions. If the acquired data shows abnormalities, such as sleep characteristic data exceeding the preset threshold range, timing abnormalities, or the controller being unexpectedly woken up, it indicates that the disturbance voltage has interfered with the controller, causing abnormal sleep. Another method is to monitor whether the controller under test (DUT) unexpectedly wakes up after the injection of a disturbance voltage. For example, if the controller's bus communication or power consumption suddenly returns to its operating level after a sleep command is issued, during or after the disturbance, it indicates that the disturbance caused the controller to wake up, thus identifying it as interference. Furthermore, analyzing collected internal state data, such as the controller's internal register states and error logs, can help determine whether the disturbance caused internal logic errors or abnormal states, thereby identifying the presence of interference.

[0093] It is understood that, through the above technical solution, this application can inject a disturbance voltage into the programmable power supply of the controller under test after receiving a sleep command, thereby simulating complex operating conditions such as power fluctuations, transient drops, and overvoltage spikes that may be encountered in actual vehicle operation. This improves the comprehensiveness, reliability, and robustness of the controller sleep test, ensuring that the controller can still stably and reliably enter and maintain a sleep state in actual complex power environments. In some of the solutions mentioned above in this application, a method is proposed in which the host computer performs a sleep test on the controller and collects data by sending a sleep command to detect whether the sleep is abnormal. This is to solve the problem that traditional sleep tests cannot fully detect abnormal sleep of the controller. However, in this process, the original test solution does not take into account that the back electromotive force generated after the 48V inductive load is turned off may be coupled to the wake-up pin of the controller through parasitic parameters, causing the controller to be passively woken up. There is no bus log to query for this type of fault, and the original test solution cannot detect this kind of hidden wake-up fault and cannot cover this kind of abnormal problem in the controller sleep scenario.

[0094] In response, this application further proposes that after the controller under test goes into sleep mode, a back electromotive force is simulated and generated at the load end of the controller under test; if the controller under test is awakened by the back electromotive force, it is determined that the controller under test has a fifth fault.

[0095] Specifically, after the host computer sends a sleep command to the controller under test (DUT) and notifies the data acquisition unit to perform data acquisition operations on the DUT, and the DUT has entered a low-power state, this application further performs subsequent tests. "After the DUT enters sleep mode" means that after receiving the sleep command and performing a series of internal operations, the DUT has entered a low-power state, and its main functional modules have stopped working or are in an extremely low-power mode. Methods to confirm that the controller has entered sleep mode may include, but are not limited to: monitoring the bus communication status of the DUT, such as bus quiescence; monitoring the current consumption of the power domain, such as current dropping below a preset sleep current threshold; or monitoring specific status registers, such as sleep status flag bits.

[0096] Subsequently, a back electromotive force (EMF) is simulated at the load terminal of the controller under test (DUT). Back EMF refers to the electromotive force generated across the load terminals in the opposite direction to the original voltage due to electromagnetic induction when the current in an inductive load changes. In the controller sleep test, simulating the generation of back EMF is to simulate the scenario in actual vehicle operation where, at the moment of shutdown, the energy stored within a 48V inductive load is released and coupled to the controller's wake-up pin via parasitic parameters. One implementation method is to connect a controllable inductive element in series at the load terminal of the DUT, and after the controller enters sleep mode, rapidly de-energize this inductive element via an external circuit to generate a transient high-voltage back EMF. Another implementation method is to use a dedicated back EMF simulator, which can precisely inject a simulated back EMF signal at the load terminal of the DUT according to a preset waveform and amplitude to simulate the shutdown characteristics of different types of inductive loads.

[0097] Next, it is determined whether the controller under test (DUT) is awakened by back EMF. "If the DUT is awakened by back EMF" means that the DUT re-enters the operating state from a dormant state under the influence of simulated back EMF. This indicates that the controller's wake-up mechanism is sensitive to back EMF interference. Methods for determining whether the controller has been awakened may include, but are not limited to: monitoring whether the bus communication of the DUT has resumed; monitoring whether the current consumption in the power domain has increased; monitoring specific status registers, such as whether the wake-up status flag has changed; or observing changes in the voltage or current at the controller's output port.

[0098] If the controller under test (DUT) is detected to be woken up by back EMF, a fifth fault is identified in the DUT. The fifth fault specifically refers to an unexpected wake-up fault caused by back EMF. This is usually due to the lack of an active discharge circuit in the 48V drive circuit, resulting in ineffective discharge of the back EMF, or insufficient anti-interference capability of the wake-up pin, causing the parasitic coupled back EMF signal to be misinterpreted as a wake-up signal. Once such a wake-up is detected, the system will automatically record the test result as "fifth fault" and can further record the back EMF parameters at the time of wake-up and the wake-up response time for subsequent fault analysis and location.

[0099] It is understood that, based on the above technical solution, which involves the host computer performing sleep tests on the controller and collecting data, this application further expands the detection range of sleep anomalies. This solution can more reliably verify its sleep performance and improve the completeness and accuracy of the controller sleep test. Simultaneously, by simulating the location and timing of back electromotive force generation under actual operating conditions, the effectiveness and authenticity of the test are ensured, avoiding misjudgments or omissions. In some embodiments, this application further clarifies the fault types of hibernation anomalies, wherein the first fault includes DC-DC no-load operation and 48V load shoot-through; the second fault includes power management logic error; the third fault includes excessive output capacitor and failure of bleed circuit; the fourth fault includes PCB leakage and MOSFET not being completely turned off; and the fifth fault includes the lack of active bleed circuit in 48V drive circuit or insufficient anti-interference of wake-up pin.

[0100] Specifically, DC-DC no-load operation refers to a DC-DC converter remaining operational but not driving a load after the controller under test (DUT) enters sleep mode, thus generating unnecessary energy consumption. Possible implementation methods include, but are not limited to: the DC-DC enable signal not being properly deactivated during sleep mode, causing it to continue operating; or the DC-DC control logic failing to respond correctly to sleep commands, keeping it in active mode. 48V load pass-through refers to a 48V power supply being directly connected to a load during the DUT's sleep mode, bypassing normal power management or switching circuits, resulting in current consumption even in sleep mode. Possible implementation methods include, but are not limited to: a failure in the power switching device responsible for controlling the 48V power supply, causing it to remain normally open; or the existence of a bypass path in the circuit design allowing the 48V power supply to directly power the load even in sleep mode.

[0101] A power management logic error refers to a deviation in the control logic of the power management unit inside the controller under test when performing a sleep operation, resulting in the turn-off timing or voltage drop slope of each voltage domain not meeting the design requirements.

[0102] Excessive output capacitance means that the filter capacitor at the output of the controller under test exceeds the design specifications, resulting in slow voltage discharge during sleep and the formation of a continuous residual voltage.

[0103] PCB leakage current refers to the degradation of the insulation performance of a printed circuit board (PCB), causing current to flow along unexpected paths, thus generating additional current consumption in the dormant state.

[0104] MOSFET not being fully turned off means that after receiving a sleep command, the metal-oxide-semiconductor field-effect transistor (MOSFET) fails to completely turn off, and a small leakage current still flows through it.

[0105] The lack of an active discharge circuit in the 48V drive circuit means that when the controller under test turns off the 48V inductive load, its drive circuit is not designed with a dedicated circuit to quickly dissipate the back electromotive force energy generated by the inductive load.

[0106] In one example, the following provides a more detailed explanation of the above technical solution through a more specific example: In a new energy vehicle controller development lab, engineers need to test the sleep function of a 48V area controller. This controller under test manages the loads across multiple voltage domains of the vehicle, including 48V, 12V, 5V, and 3V, and its sleep performance directly affects the vehicle's energy consumption.

[0107] First, the host computer, acting as the test platform, sends a sleep command to the controller under test (DUT). This command, transmitted via the CAN bus, instructs the DUT to enter a low-power sleep mode. Simultaneously, the host computer immediately notifies the high-speed data acquisition unit connected to the DUT to initiate data acquisition for that DUT. The data acquisition unit then synchronously records the DUT's bus messages, input current waveforms, and output voltage waveforms for various voltage domains, such as 48V, 12V, 5V, and 3V.

[0108] After a period of data acquisition, the host computer obtains complete acquisition data from the data acquisition unit. The host computer processes this raw acquisition data and filters out hibernation characteristic data closely related to the hibernation process. This data includes the bus message sequence before and after hibernation triggering, the current change curve at the main power input terminal of the controller under test, and the waveforms of the output voltage of each voltage domain dropping from the normal operating voltage to zero or the preset hibernation voltage.

[0109] Subsequently, the host computer uses this sleep characteristic data to detect whether the controller under test has any sleep abnormalities. Specifically, the host computer compares the extracted parameters such as bus silence duration, power sleep duration, sleep duration of each voltage domain, and voltage drop slope with the preset timing window thresholds.

[0110] like Figure 4 As shown, if the bus message stops as expected after the sleep command is issued, the input current waveform drops steadily to below the preset first current threshold within a specified time, and the output voltage waveforms of each voltage domain also drop in a preset order and slope, all parameters fall within the corresponding preset timing window threshold range, and the timing of the data is normal, then the controller under test is deemed to be in sleep mode.

[0111] However, if the host computer detects that any parameter in the sleep characteristic data exceeds the corresponding preset timing window threshold range, or if the timing of the data shows an abnormal pattern, such as the bus message failing to stop in time, the input current decreasing slowly or failing to reach the preset threshold, or the voltage drop sequence of a certain voltage domain being incorrect or the drop slope being abnormal, then it is determined that there is a sleep abnormality.

[0112] When a hibernation anomaly is detected, the host computer will further determine the specific fault type of the controller under test during the hibernation process.

[0113] For example, such as Figure 5 As shown, the host computer first queries the sleep trigger message and sleep end message in the bus messages, and determines the bus silence duration based on the time difference between them. Simultaneously, the host computer analyzes the input current waveform to determine the time it takes for the current of the controller under test to drop to a preset first current threshold after the sleep trigger operation, thus obtaining the power sleep duration. If the difference between the bus silence duration and the power sleep duration is greater than the preset duration threshold, the controller under test is determined to have a first fault. This may indicate that the DC-DC converter inside the controller under test is still running under no-load conditions after the MCU goes into sleep mode, or that there is a shoot-through phenomenon in the 48V load, causing the static current to exceed the standard. Traditional testing methods that rely solely on bus silence cannot detect such power domain problems.

[0114] Furthermore, the host computer calculates the sleep duration and voltage drop slope of each voltage domain based on the output voltage waveforms of each voltage domain. If the sleep duration order of each voltage domain differs from the preset order—for example, a voltage domain with a higher voltage should be turned off earlier, and its sleep duration is inversely proportional to the voltage—then a second fault is determined in the controller under test. This usually indicates an error in the power management logic, failing to coordinate the shutdown of multiple voltage domain loads as designed, which may lead to current backflow or logic disorder. If the voltage drop slope of any voltage domain is greater than a preset slope threshold, the voltage transformation of the corresponding voltage domain is determined to be abnormal, which may mean that there is a problem with the discharge circuit of that voltage domain.

[0115] like Figure 6 As shown, the host computer will also acquire the output port voltage of each voltage domain after it has gone into sleep mode. If the output port voltage of any voltage domain is greater than the corresponding preset voltage threshold, it is determined that the controller under test has a third fault. This may be due to the output capacitor being too large, causing slow voltage discharge and forming "voltage residue", or the discharge circuit failing, causing the connected sensor to be in a low-power state, which is difficult to detect by traditional methods.

[0116] Simultaneously, the host computer acquires the output port current of the controller under test after it goes into sleep mode. If the output port current is greater than the preset second current threshold, it is determined that the controller under test has a fourth fault. This may indicate leakage in the PCB or that the MOSFET has not been completely turned off, resulting in unnecessary power consumption.

[0117] To further verify the robustness of the controller under test (DUT), after sending a sleep command to the DUT, the host computer injects a preset disturbance voltage into the programmable power supply of the DUT. Subsequently, the host computer determines whether the disturbance voltage interferes with the sleep process of the DUT based on the acquired data after the disturbance voltage is injected (such as whether the bus messages are abnormal or whether the current fluctuates).

[0118] After the controller under test (DUT) goes into sleep mode, the host computer simulates and generates a back electromotive force (EMF) through a simulator connected to the load side of the DUT. If the DUT is awakened by this back EMF (by detecting bus messages or a sudden increase in current), it is determined that the DUT has a fifth fault. This may indicate that the 48V drive circuit lacks an active discharge circuit, or that the anti-interference capability of the wake-up pin is insufficient, causing the back EMF generated by the high-voltage inductive load at the moment of turn-off to be coupled to the wake-up pin through parasitic parameters, thus passively waking up the controller. Such faults cannot be found in the bus log in traditional methods.

[0119] Through the above multimodal data acquisition and comprehensive analysis, this method can comprehensively and accurately verify the power domain status, multi-voltage domain coordination, and potential hidden faults of the 48V area controller during the sleep transition process. It overcomes the limitations of existing single communication detection methods that cannot cover these aspects, and improves the comprehensiveness and accuracy of sleep testing.

[0120] This embodiment also provides a controller sleep test device, which is used to implement the above embodiments and preferred embodiments, and will not be repeated as already described. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0121] This embodiment provides a controller sleep test device, such as... Figure 7 As shown, it includes: The sending module 701 is used to send a sleep command to the controller under test and notify the data acquisition unit connected to the controller under test to perform data acquisition operations on the controller under test. The filtering module 702 is used to acquire the data sent by the data acquisition unit and filter out the dormant feature data from the acquired data; The judgment module 703 is used to detect whether the controller under test has a sleep abnormality based on sleep characteristic data.

[0122] In some optional implementations, the determination module 703 includes: The first unit is used to compare the extracted dormant feature data with the corresponding preset time window threshold.

[0123] The second unit is used to determine whether the hibernation is qualified if all parameters in the hibernation feature data fall within the corresponding preset time window threshold range and the timing of the data is normal.

[0124] The third unit is used to determine that a dormancy anomaly exists if any parameter in the dormant feature data exceeds the corresponding preset time window threshold range, or if an abnormal time pattern is detected in the data.

[0125] The fourth unit is used to determine the fault type of the controller under test during the sleep process when a sleep anomaly exists.

[0126] The controller sleep test device provided in this application embodiment can execute the controller sleep test method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0127] This application also provides a testing system, such as... Figure 8 As shown, the system includes: a programmable power supply (i.e., a 48V power supply), a communication module, a current sensor, a voltage sensor, a data acquisition unit, and a host computer (for timing analysis). The programmable power supply is connected to the controller under test (DUT) to provide power. The communication module is connected to the DUT to transmit sleep commands and bus messages. The current sensor is connected to the power input terminal of the DUT to capture current information during the DUT's sleep process. Multiple voltage sensors are connected to the output ports of each voltage domain of the DUT to capture voltage information during the DUT's sleep process. The voltage domain output ports include at least one of the following: a 48V load output port, a 12V bus output port after internal DC-DC voltage conversion, a 5V low-dropout linear regulator output port, and a 3V low-dropout linear regulator output port. The data acquisition unit is connected to the DUT to collect transmitted data during the test. The host computer is connected to the communication module and the data acquisition unit for time synchronization and analysis of the collected data.

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

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

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

Claims

1. A method for testing the sleep state of a controller, characterized in that, Applied to a host computer, the method includes: Send a sleep command to the controller under test and notify the data acquisition unit connected to the controller under test to perform data acquisition operation for the controller under test; Acquire the data collected by the data acquisition unit, and filter out dormant feature data from the collected data; Based on the hibernation feature data, detect whether the controller under test has a hibernation anomaly.

2. The method according to claim 1, characterized in that, The step of detecting whether the controller under test has a sleep anomaly based on the sleep feature data includes: The extracted dormant feature data is compared with the corresponding preset time window threshold. If all parameters in the hibernation feature data fall within the corresponding preset time window threshold range, and the timing of the data is normal, then the hibernation is qualified. If any parameter in the hibernation feature data exceeds the corresponding preset time window threshold range, or if an abnormal time pattern is detected in the data, then a hibernation abnormality is determined to exist. When a hibernation anomaly occurs, determine the fault type of the controller under test during the hibernation process.

3. The method according to claim 2, characterized in that, When a hibernation anomaly occurs, determining the fault type of the controller under test during the hibernation process includes: Based on the bus silence duration and power sleep duration, it is determined whether the controller under test has a first fault. The bus silence duration is used to characterize the bus sleep time, and the power sleep duration is used to characterize the sleep time of each power device in the controller under test.

4. The method according to claim 3, characterized in that, The sleep characteristic data includes bus messages and input current waveforms. The step of determining whether the controller under test has a first fault based on the bus silence duration and power sleep duration includes: Query the sleep trigger message and sleep end message in the bus messages respectively; The bus silence duration is determined based on the time difference between the sleep trigger message and the sleep end message; By analyzing the input current waveform, the duration for which the current of the controller under test drops to a preset first current threshold after the sleep trigger operation is determined, and the power sleep duration is obtained. When the difference between the bus silence duration and the power sleep duration is greater than a preset duration threshold, it is determined that the controller under test has a first fault.

5. The method according to claim 2, characterized in that, The controller includes a 48V area controller, which includes multiple voltage domain outputs. The sleep characteristic data also includes the output voltage waveforms of each voltage domain. Determining the fault type of the controller under test during the sleep process when a sleep anomaly exists further includes: Based on the output voltage waveforms of each voltage domain, the sleep duration and voltage drop slope of each voltage domain are obtained; When the sleep duration order of each voltage domain is different from the preset order, it is determined that the controller under test has a second fault, wherein the preset order includes the sleep duration of each voltage domain being inversely proportional to the voltage of each voltage domain; When the voltage drop slope of any voltage domain is greater than a preset slope threshold, the voltage transformation of the corresponding voltage domain is determined to be abnormal.

6. The method according to claim 2, characterized in that, The step of determining the fault type of the controller under test during the sleep process when a sleep anomaly exists further includes: Obtain the output port voltage of each voltage domain after it has gone into sleep mode; If the output port voltage of any of the voltage domains is greater than the corresponding preset voltage threshold, then the controller under test is determined to have a third fault.

7. The method according to claim 2, characterized in that, The step of determining the fault type of the controller under test during the sleep process when a sleep anomaly exists further includes: Obtain the output port current of the controller under test after it has gone into sleep mode; When the output port current is greater than the preset second current threshold, it is determined that the controller under test has a fourth fault.

8. The method according to claim 1, characterized in that, After sending a sleep command to the controller under test, the method further includes: A disturbance voltage is injected into the programmable power supply of the controller under test, and the collected data after the disturbance voltage is injected is used to determine whether the disturbance voltage interferes with the controller under test.

9. The method according to claim 1, characterized in that, The method further includes: After the controller under test goes into sleep mode, a back electromotive force is simulated and generated at the load terminal of the controller under test. If the controller under test is awakened by the back electromotive force, then it is determined that the controller under test has a fifth fault.

10. A sleep test device for a controller, characterized in that, The device includes: The sending module is used to send a sleep command to the controller under test and notify the data acquisition unit connected to the controller under test to perform data acquisition operation on the controller under test. The filtering module is used to acquire the data collected by the data acquisition unit and filter out dormant feature data from the data collected. The judgment module is used to detect whether the controller under test has a sleep abnormality based on the sleep characteristic data.

11. A testing system, characterized in that, include: Programmable power supply, communication module, current sensor, voltage sensor, data acquisition unit, and host computer. The programmable power supply is connected to the controller under test and is used to provide power to the controller under test; The communication module is connected to the controller under test and is used to transmit sleep commands and bus messages; The current sensor is connected to the power input terminal of the controller under test and is used to capture the current information of the controller under test during the sleep process. The voltage sensor includes multiple sensors, which are respectively connected to each voltage domain output port of the controller under test, and are used to capture voltage information during the sleep process of the controller under test. The voltage domain output port includes at least one of the following: a 48V load output port, a 12V bus output port after internal DC voltage conversion, a 5V low dropout linear regulator output port, and a 3V low dropout linear regulator output port. The data acquisition unit is connected to the controller under test and is used to acquire the transmitted data of the controller under test during the test. The host computer is connected to the communication module and the data acquisition unit for time synchronization and analysis of the acquired data.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the sleep test method of the controller according to any one of claims 1 to 9.

Images