A dynamic closed-loop fault injection diagnosis test system based on double trigger conditions

Abstract

The application relates to the field of automobile testing technology and discloses a dynamic closed-loop fault injection diagnosis test system based on double triggering conditions, which comprises an upper computer, a HIL real-time simulation platform, and a CAN hardware board card. The upper computer is used for issuing a test configuration containing preset triggering conditions, a diagnosis request and an expected result. The HIL real-time simulation platform is used for monitoring target communication bus message transmission states and system simulation time, outputting a fault triggering signal when preset triggering conditions are met, and triggering fault injection. The CAN hardware board card is used for sending the diagnosis request to a measured ECU, receiving a response message returned by the ECU as diagnosis response data feedback. After comparison and judgment of the upper computer and the expected result, a closed-loop scheduling instruction is generated to drive subsequent tests. The preset triggering conditions include first and second triggering conditions based on message transmission states and system simulation time. The closed-loop scheduling instruction is used for adjusting test parameters, retrying or executing a next test case. The scheme solves the problems of single triggering difficulty and the lack of a closed loop in a test process.

Description

Technical Field

[0001] This specification relates to the field of automotive testing technology, and in particular to a dynamic closed-loop fault injection diagnostic testing system based on dual triggering conditions. Background Technology

[0002] In hardware-in-the-loop testing, verifying whether the Electronic Control Unit (ECU) can accurately identify and store diagnostic fault codes is an important task.

[0003] Current fault injection tests often determine the injection timing based on a single time or event condition. However, the preconditions for diagnostic activation vary significantly across different controllers; some require accumulating a certain number of communication messages, while others require running for a specific duration. Relying on a single condition to trigger a fault may lead to missed faults. Furthermore, when injecting faults using existing technologies, the controller is typically still initializing, and the diagnostic functions are in a dormant state. This can cause tests to miss target faults, and testers may easily overlook the injection timing variable, mistaking missed test results for software defects in the controller itself.

[0004] Furthermore, conventional testing often separates fault injection, response reading, and result judgment, resulting in a lack of feedback loops from the judgment results to the control unit. Faced with test failures, the system struggles to automatically distinguish between controller defects and test parameter conflicts. Parameter adjustments, failure retries, and subsequent test case development all heavily rely on manual intervention, leading to a loss of continuity in the entire testing process. The industry urgently needs a dynamic closed-loop fault injection diagnostic testing system based on dual-trigger conditions to address these issues. Summary of the Invention

[0005] In view of this, the present invention aims to propose a dynamic closed-loop fault injection diagnostic test system based on dual triggering conditions, so as to solve the problems that the existing fault injection test triggering conditions are single, which leads to deviations in injection timing, and the judgment results are only based on a single test, which leads to the reliance on manual advancement of subsequent processes.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: A dynamic closed-loop fault injection diagnostic testing system based on dual triggering conditions includes: The host computer is used to issue test configurations containing preset trigger conditions, diagnostic requests and expected results; it is also used to receive diagnostic response data fed back by the CAN hardware board, compare and judge with the expected results, and generate closed-loop scheduling instructions based on the judgment results to drive the subsequent test process. The HIL real-time simulation platform is used to monitor the message transmission status and system simulation time on the target communication bus during test operation. When the message transmission status and / or the system simulation time meet the preset triggering conditions, a fault triggering signal is output to trigger the injection of a target fault into the ECU under test. A CAN hardware board is used to receive the diagnostic request, convert the diagnostic request into a CAN bus diagnostic request message and send it to the ECU under test, receive the response message returned by the ECU under test, and feed the response message back to the host computer as the diagnostic response data. The preset triggering conditions include a first triggering condition based on the message transmission status and a second triggering condition based on the system simulation time. The first triggering condition and the second triggering condition are determined according to preset logic. The closed-loop scheduling instruction is used to instruct the adjustment of test parameters, retrying the current test, or executing the next test case.

[0007] Furthermore, the HIL real-time simulation platform includes a Simulink test model and a fault injection module; The host computer is also used to load test cases and configure the preset triggering conditions, the target fault, the diagnostic request, and the expected results according to the test cases; The Simulink test model outputs the diagnostic request based on the test cases.

[0008] Furthermore, the Simulink test model includes a frame count submodule; The frame count submodule is used to count the number of message transmission frames corresponding to the specified message identifier on the target communication bus, and to determine that the first triggering condition is met when the number of message transmission frames reaches the preset frame count threshold. The Simulink test model is also used to obtain the system simulation time, and when the system simulation time reaches a preset time threshold, it is determined that the second triggering condition is met. The Simulink test model is also used to determine the first triggering condition and the second triggering condition according to the preset logic, generate the fault triggering signal when the determination result satisfies the preset logic, and generate a fault injection instruction when the fault triggering signal is generated. The preset logic includes independent triggering and combined triggering; when triggered independently, the preset triggering condition is considered to be satisfied if either the first triggering condition or the second triggering condition is satisfied; when triggered combined, the preset triggering condition is considered to be satisfied if both the first triggering condition and the second triggering condition are satisfied simultaneously.

[0009] Furthermore, the CAN hardware board is also used to receive the fault injection command, convert the fault injection command into a CAN bus fault message and send it to the ECU under test to complete the protocol layer fault injection.

[0010] Furthermore, the HIL real-time simulation platform also includes a vehicle dynamics model, a sensor simulation model, and a load simulation model; The HIL real-time simulation platform is used to provide a virtual vehicle operating environment based on the vehicle dynamics model, the sensor simulation model and the load simulation model, and to form a closed-loop operation with the ECU under test. The HIL real-time simulation platform is also used to provide the system simulation time to the Simulink test model.

[0011] Furthermore, the fault injection module includes a relay matrix and a fault injection circuit; The fault injection module is used to receive the fault trigger signal and control the relay matrix and the fault injection circuit to perform physical layer fault injection on the ECU under test according to the fault trigger signal. The physical layer fault injection includes at least one of the following fault types: CAN_H open circuit, CAN_L open circuit, CAN_H short circuit to power supply, and CAN_L short circuit to GND.

[0012] Furthermore, the Simulink test model is also used to determine the timing of sending the diagnostic request based on a preset diagnostic waiting time after the target fault is applied; When the diagnostic waiting time is zero, the Simulink test model is used to output the diagnostic request within the current simulation step or the next simulation step after the target fault is applied; When the diagnostic waiting time is greater than zero, the Simulink test model is used to wait for the diagnostic waiting time after the target fault is applied before outputting the diagnostic request.

[0013] Furthermore, the host computer is also used to parse the diagnostic response data and extract at least one of the following from the diagnostic response data: DTC number, DTC status bit, fault occurrence timestamp, diagnostic response time, and DTC set corresponding to multiple DTCs; The host computer is also used to compare at least one of the extracted DTC number, DTC status bit, fault occurrence timestamp, diagnostic response time, and DTC set with the expected result, and generate the judgment result based on the comparison result.

[0014] Furthermore, the host computer is also used to obtain the number of retries for the currently executed test case when the determination result is that the test fails, and compare the number of retries with the preset maximum number of retries; When the number of retries is less than the preset maximum number of retries, the tested ECU is reset, and the simulation environment of the HIL real-time simulation platform is restored before the current test case is executed again. When the number of retries reaches the preset maximum number of retries, the current test case is determined to be a failure, and the next test case is executed.

[0015] The principles and advantages of this invention are: 1. The HIL real-time simulation platform provides system simulation time based on a virtual vehicle operating environment, monitors the message transmission status on the target communication bus and the system simulation time in real time, and judges the first and second trigger conditions according to preset logic. When the preset logic is met, a fault trigger signal is output to trigger the target fault injection. This allows for flexible matching of the differentiated diagnostic activation preconditions of various controllers, improving the accuracy of fault injection timing and the targeting of testing.

[0016] 2. The fault injection command is converted into a CAN bus fault message and sent via the CAN hardware board to complete the protocol layer fault injection. The fault injection module then controls the relay matrix and fault injection circuit to perform physical layer fault injection based on the fault trigger signal. This allows message-level faults and line-level electrical faults to be applied through their respective paths, expanding the coverage of fault types.

[0017] 3. Using a Simulink test model, the timing of the diagnostic request output is determined based on a preset diagnostic waiting time after the target fault is applied. Output is made immediately when the diagnostic waiting time is zero, and output after a waiting period when the waiting time is greater than zero. This allows the timing of the diagnostic request to be adapted to the controller's internal de-jitter filtering and diagnostic monitoring cycle, improving the effectiveness of the diagnostic response data.

[0018] 4. The host computer compares the parsed content of the diagnostic response data with the expected results to generate a judgment result. Based on the judgment result, a closed-loop scheduling instruction is generated to instruct the adjustment of test parameters, retrying the current test, or executing the next test case. When a test fails, the comparison between the number of retries and the preset maximum number of retries determines whether to reset and rerun the test or skip the current test case. This allows the judgment result to automatically drive the subsequent test process, achieving continuous closed-loop testing. Attached Figure Description

[0019] This specification will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein: Figure 1 This is an exemplary block diagram of a dynamic closed-loop fault injection diagnostic test system based on dual triggering conditions, as shown in some embodiments of this specification. Figure 2 This is a schematic diagram of the dual-trigger condition determination process according to some embodiments of this specification; Figure 3 This is a schematic diagram of the dynamic closed-loop fault injection diagnostic test process according to some embodiments of this specification; Figure 4 This is a system timing diagram illustrating some embodiments of the present specification. Detailed Implementation

[0020] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some examples or embodiments of this specification. For those skilled in the art, these drawings can be applied to other similar scenarios without creative effort. Unless obvious from the linguistic context or otherwise specified, the same reference numerals in the drawings represent the same structures or operations.

[0021] As indicated in this specification and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" are not specifically singular and may include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0022] Flowcharts are used in this specification to illustrate the operations performed by the system according to embodiments of this specification. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, the steps can be processed in reverse order or simultaneously. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0023] The following detailed explanation illustrates the specific implementation methods: A hardware-in-the-loop (HIL) real-time simulation platform refers to a simulation platform that uses a real-time running virtual vehicle model to replace a real vehicle in a laboratory environment, forming a closed-loop operation with the device under test (DUT). After the DUT is connected to the platform, its input comes from the simulation model, and its output is fed back to the simulation model, with an operating state close to that of an actual vehicle.

[0024] In this specification, the device under test is specifically an Electronic Control Unit (ECU), which can be an engine controller, transmission controller, or body controller, etc. The ECU is connected to the HIL real-time simulation platform via the target communication bus, forming a closed-loop operation with the virtual vehicle operating environment.

[0025] The target communication bus is typically a Controller Area Network (CAN) bus. The CAN bus transmits messages based on the voltage difference between the CAN_H and CAN_L signal lines. These two lines together form the communication link between the ECU under test and the nodes of the test system.

[0026] To verify the fault diagnosis function of the ECU, the test system injects target faults into the ECU under test in the test environment. Based on the level of effect, target faults include protocol layer faults and physical layer faults. Protocol layer faults affect the message content level, covering situations such as message signal tampering, message loss or timeout, and abnormal message cycle. Physical layer faults affect the electrical level of the circuit, covering situations such as CAN_H open circuit, CAN_L open circuit, CAN_H short circuit to power supply, and CAN_L short circuit to GND. Specifically, an open circuit in CAN_H or CAN_L means that the corresponding signal line is disconnected. After the line is disconnected, the voltage difference carrying the message disappears, and message transmission is interrupted. A short circuit between CAN_H and power supply means that the CAN_H signal line is accidentally connected to the positive terminal of the power supply, and a short circuit between CAN_L and GND means that the CAN_L signal line is accidentally connected to the ground terminal. The signal line level is forcibly pulled to a fixed potential, and the normal communication waveform is destroyed. All of the above physical layer faults will cause the ECU under test to lose its effective message receiving channel, thereby triggering its internal communication fault diagnosis logic.

[0027] When a target fault is applied to the ECU and confirmed by its internal diagnostic mechanism, the ECU converts the fault status into a specific digital identifier for storage, which can then be read and verified by external testing equipment. This digital identifier is the Diagnostic Trouble Code (DTC). The host computer reads the DTC by sending a diagnostic request and uses it as the basis for determining whether the fault diagnosis function of the ECU under test has passed the test.

[0028] Example 1: Figure 1 This is an exemplary block diagram of a dynamic closed-loop fault injection diagnostic test system based on dual triggering conditions, as shown in some embodiments of this specification.

[0029] like Figure 1 As shown, a dynamic closed-loop fault injection diagnostic test system based on dual triggering conditions includes a host computer, a HIL real-time simulation platform, and a CAN hardware board; the HIL real-time simulation platform is connected to the host computer and the CAN hardware board respectively.

[0030] The host computer, acting as the test control terminal, loads test cases and configures preset trigger conditions, target faults, diagnostic requests, and expected results based on the test cases. The host computer also receives diagnostic response data from the CAN hardware board, compares the diagnostic response data with the expected results, generates a judgment result, and generates closed-loop scheduling instructions based on the judgment result to drive subsequent test processes.

[0031] The HIL real-time simulation platform provides a virtual vehicle operating environment for the ECU under test and runs the simulation and test models required during the testing process. In some embodiments, the HIL real-time simulation platform may include vehicle dynamics models, sensor simulation models, load simulation models, and Simulink test models, etc., to run corresponding simulation tests according to test cases.

[0032] The CAN hardware board is used to realize CAN communication between the test system and the ECU under test, and to receive or send corresponding CAN messages according to the test process.

[0033] The ECU under test is the electronic control unit connected to the corresponding test interface of the HIL real-time simulation platform. During the test, the HIL real-time simulation platform runs a virtual vehicle operating environment, the host computer loads test cases and controls the test process, and the CAN hardware board is responsible for data communication between the test system and the ECU under test.

[0034] In this embodiment, the host computer, the HIL real-time simulation platform, the CAN hardware board, and the ECU under test together constitute a dynamic closed-loop fault injection diagnostic test environment. The host computer determines the test conditions and test objectives through test cases, the HIL real-time simulation platform executes corresponding test controls according to the test running status, the CAN hardware board completes CAN communication with the ECU under test, and feeds back the diagnostic response data of the ECU under test to the host computer.

[0035] The above structure integrates test case configuration, HIL real-time simulation, CAN communication, and diagnostic testing of the ECU under test into the same test environment. This allows fault injection, diagnostic requests, and diagnostic responses to be performed in the same test process, providing a foundation for subsequent test scheduling based on test results.

[0036] Example 2: This embodiment describes the dual triggering condition determination process of the present invention based on Embodiment 1.

[0037] like Figure 2 As shown, Figure 2 This is a schematic diagram of the dual-trigger condition determination process according to some embodiments of this specification.

[0038] In this embodiment, the host computer loads test cases and configures preset trigger conditions according to the test cases. The preset trigger conditions include a first trigger condition and a second trigger condition.

[0039] The first triggering condition is determined based on the message transmission status on the target communication bus, and the second triggering condition is determined based on the system simulation time of the HIL real-time simulation platform.

[0040] In this embodiment, the HIL real-time simulation platform includes a Simulink test model, which is used to perform test control based on test cases.

[0041] For the first trigger condition, the Simulink test model includes a frame count submodule. This submodule counts the number of transmitted frames corresponding to a specified message identifier on the target communication bus and compares this number with a preset frame count threshold. When the number of transmitted frames reaches the preset frame count threshold, the first trigger condition is deemed met.

[0042] For example, in a specific example, reaching 100 frames corresponding to a specified message identifier on the target communication bus can be set as the first trigger condition. When the HIL real-time simulation platform is running, and the frame counting submodule counts the corresponding message transmission frame count to reach 100 frames, the first trigger condition is determined to be met. The aforementioned 100 frames is only an example; the actual preset frame count threshold can be configured according to the test cases.

[0043] For the second triggering condition, the Simulink test model acquires the system simulation time of the HIL real-time simulation platform and compares the system simulation time with a preset time threshold. When the system simulation time reaches the preset time threshold, the second triggering condition is determined to be met.

[0044] For example, in a specific case, a system simulation time of 5 seconds can be set as the second trigger condition. When the HIL real-time simulation platform runs for 5 seconds, the second trigger condition is determined to be met. The 5-second timeframe mentioned above is only an example; the actual preset time threshold can be configured according to the test cases.

[0045] In this embodiment, the Simulink test model determines the first and second triggering conditions according to the preset logic in the test cases.

[0046] The preset logic includes independent triggering and combined triggering.

[0047] When using independent triggering, the preset triggering condition is considered satisfied if either the first or second triggering condition is met. When using combined triggering, the preset triggering condition is considered satisfied only if both the first and second triggering conditions are met simultaneously.

[0048] For example, when the test case is configured to be combined triggering, and the first triggering condition is "the number of message transmission frames corresponding to the specified message identifier reaches 100 frames" and the second triggering condition is "the system simulation time reaches 5 seconds", the Simulink test model will only determine that the preset triggering conditions are met when the number of message transmission frames reaches 100 frames and the system simulation time reaches 5 seconds.

[0049] When the judgment result meets the preset logic, the Simulink test model generates a fault trigger signal and generates a fault injection instruction when the fault trigger signal is generated, so as to enter the subsequent fault injection process.

[0050] In some embodiments, the preset triggering conditions can also configure the frame number threshold, time threshold, and triggering logic according to different requirements of the test cases. For example, when the test results show that the ECU under test needs to receive more messages before entering the corresponding diagnostic monitoring state, the frame number threshold can be adjusted from 100 frames to 150 frames; the specific adjustment value is determined according to the test cases.

[0051] In this way, the first triggering condition determines the fault injection timing from the perspective of communication events, and the second triggering condition determines the fault injection timing from the perspective of simulation time. Furthermore, it allows for independent or combined triggering based on different test cases. Therefore, compared to methods that only perform fault injection at fixed times, this embodiment enables the fault injection timing to simultaneously match the actual message transmission of the target communication bus and the simulation time, thereby adapting to the testing requirements of different ECU diagnostic logics regarding fault injection timing.

[0052] Example 3: This embodiment describes a complete dynamic closed-loop fault injection diagnostic test process based on Embodiment 1 and Embodiment 2.

[0053] like Figure 3 As shown, Figure 3 This is a schematic diagram of a dynamic closed-loop fault injection diagnostic test process according to some embodiments of this specification.

[0054] In this embodiment, a CAN communication fault diagnosis test of an on-board engine controller (ECU) is taken as an example. The ECU under test is connected to the HIL test bench, and communication is established with the host computer via the CAN hardware board. Test cases are loaded in the host computer, and the target fault, preset trigger conditions, diagnostic requests, and expected results are configured.

[0055] In this embodiment, the target fault is a CAN communication loss fault, and the preset triggering condition adopts a combination of time triggering and frame number triggering.

[0056] Specifically, the system simulation time reaches 5 seconds as the second trigger condition, the number of message transmission frames corresponding to the specified message identifier on the CAN bus reaches 100 frames as the first trigger condition, and the expected diagnostic result is configured as the DTC stored in the ECU under test.

[0057] After the test begins, the HIL real-time simulation platform runs a virtual vehicle operating environment. The Simulink test model continuously acquires the system simulation time according to the test cases and counts the number of message transmission frames corresponding to the specified message identifier through the frame count submodule.

[0058] When the system simulation time reaches 5 seconds and the number of message transmission frames corresponding to the specified message identifier reaches 100 frames, the first trigger condition and the second trigger condition are met simultaneously. The Simulink test model determines that the preset trigger condition is met according to the preset combined trigger logic and generates a fault trigger signal and a fault injection instruction.

[0059] In this embodiment, the target fault is injected using a composite fault injection method. The fault injection module controls the relay matrix to disconnect the CAN communication line of the ECU under test according to the fault trigger signal, thus completing the physical layer fault injection; at the same time, the CAN hardware board converts the fault injection command into a CAN bus fault message and sends it to the ECU under test, thus completing the protocol layer fault injection.

[0060] After the fault injection is completed, the Simulink test model determines when to send the diagnostic request based on the pre-set diagnostic waiting time in the test case.

[0061] In this embodiment, the diagnostic waiting time is set to 2 seconds. Therefore, after the target fault injection is completed, wait 2 seconds, and the Simulink test model generates a diagnostic request according to the UDS protocol and sends a diagnostic request to the ECU under test to read the current DTC through the CAN hardware board.

[0062] In other embodiments, when the diagnostic waiting time is 0, the Simulink test model can output a diagnostic request within the current simulation step or the next simulation step after the target fault injection is completed; when the diagnostic waiting time is greater than 0, the Simulink test model waits for the corresponding diagnostic waiting time after the target fault injection is completed before outputting the diagnostic request. The aforementioned diagnostic waiting time can be configured according to the de-jittering mechanism inside the ECU under test, the diagnostic monitoring cycle, or the actual diagnostic test requirements.

[0063] After receiving the diagnostic request, the ECU under test returns a diagnostic response message. The CAN hardware board receives the diagnostic response message and uploads the diagnostic response data to the host computer.

[0064] Figure 4 These are system timing diagrams illustrating some embodiments of the system described in this specification. For example... Figure 4 As shown, in a complete test, the Simulink test model first monitors the message transmission status and system simulation time. When the preset trigger conditions are met, it outputs a fault trigger signal to the fault injection module. The fault injection module then performs physical layer fault injection on the ECU under test according to the fault trigger signal. Simultaneously, the Simulink test model sends a fault injection command to the CAN hardware board. The CAN hardware board sends a CAN bus fault message to the ECU under test to complete the protocol layer fault injection. After the target fault is applied, the Simulink test model outputs a diagnostic request according to the diagnostic waiting time. The CAN hardware board forwards the diagnostic request to the ECU under test and receives the response message returned by the ECU under test. The response message is then fed back to the host computer as diagnostic response data. The host computer automatically compares and judges the expected results and feeds back closed-loop scheduling instructions to the Simulink test model to drive the subsequent test process.

[0065] Furthermore, after receiving the diagnostic response data, the host computer compares the diagnostic response data with the expected results in the test cases and generates a judgment result.

[0066] In this embodiment, the host computer parses the diagnostic response data and can make a determination based on at least one of the following: DTC number, DTC status bit, fault occurrence timestamp, diagnostic response time, and DTC set corresponding to multiple DTCs.

[0067] Specifically, for the DTC number, the host computer compares the actual DTC number read with the expected DTC number in the test case; when the actual DTC number matches the expected DTC number, the corresponding decision item is deemed to have passed.

[0068] For DTC status bits, the host computer compares the actual DTC status bits with the expected status in the test case to determine whether the DTC is in the expected current fault state, historical fault state, or acknowledgment state.

[0069] For the fault occurrence timestamp, the host computer compares the fault occurrence timestamp in the diagnostic response data with the preset time range in the test case. When the fault occurrence time is within the preset time range, the corresponding judgment item is determined to pass.

[0070] Regarding the diagnostic response time, the host computer determines the time from sending the diagnostic request to receiving the complete diagnostic response, and compares the diagnostic response time with a preset response time threshold. For example, in some test cases, a response time of no more than 100ms can be used as a criterion; the 100ms threshold is merely an example.

[0071] For multiple DTCs, the host computer can form a DTC set from the actual DTCs read, and compare this DTC set with the expected DTC set in the test case. When the two DTC sets match, the corresponding decision item is considered passed. The different decision items mentioned above can be configured according to the test case, and it is not required that all decision items be used in a single test.

[0072] In some embodiments, the host computer can also configure different judgment methods according to the test cases. In strict matching mode, a judgment result indicating that the test has passed is generated when all configured judgment dimensions meet the corresponding expected results; in lenient matching mode, only the DTC number can be matched, and a judgment result can be generated based on the matching result of the DTC number. The above judgment modes can be configured by the host computer.

[0073] When abnormal situations occur during diagnostic testing, the host computer can also record the abnormal situations individually. For example, if no diagnostic response is received after a preset response timeout threshold is exceeded after sending a diagnostic request, it can be recorded as an ECU no-response abnormality; if the received diagnostic response does not conform to the preset UDS protocol format, it can be recorded as a message format abnormality; if a valid DTC is actually read but it is not the expected DTC, it can be recorded as an unexpected DTC; if the diagnostic response uses multi-frame transmission and the received frame order does not conform to the preset order, it can be recorded as a multi-frame order abnormality.

[0074] Each judgment can also record the actual value, the expected value, and the corresponding comparison result, and store the judgment result in a structured manner for subsequent test result analysis and test report generation. The above-mentioned anomaly records and judgment result records can serve as the basis for the host computer to generate closed-loop scheduling instructions based on the judgment results.

[0075] The host computer generates a test report based on the judgment results, and generates a closed-loop scheduling instruction based on the judgment results to drive the subsequent test process.

[0076] In some embodiments, the host computer can manage multiple test cases according to the execution order of the test cases, and determine the execution method of subsequent test cases based on the judgment result of the current test case. When the current test case passes, the host computer records the pass status and test data of the current test case, and determines whether there is a next test case that has not been executed; if there is a next test case, the host computer loads the next test case and starts execution; if there is no next test case, the host computer generates a test report and ends the current test.

[0077] When the current test case fails, the host computer records the test failure status and the corresponding failure reason, and obtains the retry count for the current test case, comparing it with the preset maximum retry count. When the retry count is less than the preset maximum retry count, the host computer controls the ECU under test to reset, restores the simulation environment of the HIL real-time simulation platform, and re-executes the current test case; when the retry count reaches the preset maximum retry count, the host computer determines the current test case as failed and controls the execution of the next test case.

[0078] In some embodiments, the preset maximum number of retries can be configured through test cases, for example, it can be set to 3 times. When the same test case fails consecutively to the preset number, subsequent tests can also be paused and an alarm can be output to avoid continuing to execute a large number of test cases when there are anomalies in the test environment.

[0079] During the test, the host computer can also generate closed-loop scheduling instructions for adjusting test parameters based on the current judgment results. These test parameters include fault injection parameters, parameters corresponding to preset trigger conditions, and parameters corresponding to diagnostic requests.

[0080] The fault injection parameters can include the fault duration, fault amplitude, and fault injection time offset. For example, for a CAN_H open-circuit fault, the fault duration can be adjusted based on the test results.

[0081] The parameters corresponding to the preset trigger conditions can include a frame count threshold, a time threshold, and preset logic between the first and second trigger conditions. For example, when the ECU under test needs to receive more communication messages before entering the corresponding diagnostic state, the frame count threshold can be adjusted based on the test results.

[0082] The parameters for a diagnostic request can include the diagnostic waiting time, response timeout threshold, and number of diagnostic request retransmissions. For example, if the tested ECU needs a certain amount of time to update the DTC after a fault occurs, the diagnostic waiting time can be adjusted based on the test results.

[0083] In some embodiments, the host computer can adjust the test parameters based on different test results. For example, when the target fault has been injected and the ECU under test can communicate normally, but the expected DTC is not read, the fault duration and diagnostic waiting time can be increased; when the target fault is not injected but an unexpected DTC is read, the parameters corresponding to the preset trigger conditions can be adjusted, and a fault-free pre-detection can be added; when the diagnostic response times out frequently while CAN communication is still in a normal state, the response timeout threshold can be increased and the minimum interval between diagnostic requests can be increased; when the ECU under test experiences continuous abnormal resets during the test, the fault amplitude or severity of the target fault can be reduced, and the time interval between different test cases can be increased.

[0084] For example, in cases where faults do not respond as expected, the fault duration and diagnostic waiting time can be gradually increased by 20% of the initial parameters until the expected DTC is read. For cases with frequent diagnostic response timeouts, the response timeout threshold can be adjusted by increasing it by 50ms each time. For cases where the bus load exceeds 60%, the transmission rate of other non-test messages can be reduced to reserve communication bandwidth for diagnostic request messages. The specific adjustment values ​​mentioned above are only examples; the actual adjustment parameters and magnitudes can be configured according to the test cases.

[0085] In some embodiments, when the same test case fails five times consecutively, the host computer can generate a batch failure protection command, suspend the test and output an alarm, and record the corresponding test risk information in the test report; after gaining control to continue testing, subsequent tests can be resumed. The above consecutive failure count is only an example, and the specific threshold can be configured according to the test case.

[0086] During testing, the host computer determines the next test operation based on the current test results. If the test results do not meet expectations, subsequent tests are processed accordingly based on the current test results, and test parameters are adjusted and the test is re-executed if necessary. If the test results meet expectations, the next test case is executed. Thus, the judgment result of the previous test can serve as the basis for processing subsequent tests until the execution of the corresponding test case is completed.

[0087] In this way, the host computer can not only determine whether the current test passes based on the comparison between the diagnostic response data and the expected results, but also control the retry of the current test case, the execution of the next test case, and the adjustment of test parameters based on the test results, so that the test results can directly participate in the subsequent test process. For cases where the test fails, re-verification can be performed by resetting the ECU under test, restoring the HIL real-time simulation environment, and re-executing the test cases, thereby reducing the need for manual processing of each item based on a single test result.

[0088] Furthermore, by comparing at least one of the following: DTC number, DTC status bit, fault occurrence timestamp, diagnostic response time, and DTC set, the fault diagnosis results of the tested ECU can be judged accordingly for different test cases; by recording the actual value, expected value, and comparison results, the data on which the test judgment is based can be retained; by adjusting the fault injection parameters, the parameters corresponding to the preset trigger conditions, or the parameters corresponding to the diagnostic request according to the judgment results, subsequent tests can continue to use the adjusted test configuration.

[0089] This embodiment can determine the timing of injecting the target fault based on the message transmission status on the target communication bus and the system simulation time. After the target fault is injected, a diagnostic request is sent according to the diagnostic waiting time, and a judgment result is generated based on the diagnostic response data returned by the tested ECU. Then, based on the judgment result, a retry, parameter adjustment, or the next test case is executed, thereby completing a complete dynamic closed-loop fault injection diagnostic test.

[0090] The above are merely embodiments of the present invention. Commonly known structures and characteristics are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are aware of all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can, under the guidance of this application, improve and implement this solution in combination with their own capabilities. Some typical known structures or methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention. These should also be considered within the scope of protection of the present invention, and will not affect the effectiveness of the implementation of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. A dynamic closed-loop fault injection diagnostic testing system based on dual triggering conditions, characterized in that, include: The host computer is used to issue test configurations that include preset trigger conditions, diagnostic requests, and expected results. It is also used to receive diagnostic response data fed back by the CAN hardware board, compare and judge it with the expected result, and generate a closed-loop scheduling instruction based on the judgment result to drive the subsequent test process. The HIL real-time simulation platform is used to monitor the message transmission status and system simulation time on the target communication bus during test operation. When the message transmission status and / or the system simulation time meet the preset triggering conditions, a fault triggering signal is output to trigger the injection of a target fault into the ECU under test. A CAN hardware board is used to receive the diagnostic request, convert the diagnostic request into a CAN bus diagnostic request message and send it to the ECU under test, receive the response message returned by the ECU under test, and feed the response message back to the host computer as the diagnostic response data. The preset triggering conditions include a first triggering condition based on the message transmission status and a second triggering condition based on the system simulation time. The first triggering condition and the second triggering condition are determined according to preset logic. The closed-loop scheduling instruction is used to instruct on adjusting test parameters, retrying the current test, or executing the next test case.

2. The dynamic closed-loop fault injection diagnostic test system based on dual triggering conditions according to claim 1, characterized in that, The HIL real-time simulation platform includes a Simulink test model and a fault injection module; The host computer is also used to load test cases and configure the preset triggering conditions, the target fault, the diagnostic request, and the expected results according to the test cases; The Simulink test model outputs the diagnostic request based on the test cases.

3. The dynamic closed-loop fault injection diagnostic test system based on dual triggering conditions according to claim 2, characterized in that, The Simulink test model includes a frame count submodule; The frame count submodule is used to count the number of message transmission frames corresponding to the specified message identifier on the target communication bus, and to determine that the first triggering condition is met when the number of message transmission frames reaches the preset frame count threshold. The Simulink test model is also used to obtain the system simulation time, and when the system simulation time reaches a preset time threshold, it is determined that the second triggering condition is met. The Simulink test model is also used to determine the first triggering condition and the second triggering condition according to the preset logic, generate the fault triggering signal when the determination result satisfies the preset logic, and generate a fault injection instruction when the fault triggering signal is generated. The preset logic includes independent triggering and combined triggering; when triggered independently, the preset triggering condition is considered to be satisfied if either the first triggering condition or the second triggering condition is satisfied; when triggered combined, the preset triggering condition is considered to be satisfied if both the first triggering condition and the second triggering condition are satisfied simultaneously.

4. The dynamic closed-loop fault injection diagnostic test system based on dual triggering conditions according to claim 3, characterized in that, The CAN hardware board is also used to receive the fault injection command, convert the fault injection command into a CAN bus fault message and send it to the ECU under test to complete the protocol layer fault injection.

5. The dynamic closed-loop fault injection diagnostic test system based on dual triggering conditions according to claim 2, characterized in that, The HIL real-time simulation platform also includes a vehicle dynamics model, a sensor simulation model, and a load simulation model; The HIL real-time simulation platform is used to provide a virtual vehicle operating environment based on the vehicle dynamics model, the sensor simulation model and the load simulation model, and to form a closed-loop operation with the ECU under test. The HIL real-time simulation platform is also used to provide the system simulation time to the Simulink test model.

6. The dynamic closed-loop fault injection diagnostic test system based on dual triggering conditions according to claim 2, characterized in that, The fault injection module includes a relay matrix and a fault injection circuit; The fault injection module is used to receive the fault trigger signal and control the relay matrix and the fault injection circuit to perform physical layer fault injection on the ECU under test according to the fault trigger signal. The physical layer fault injection includes at least one of the following fault types: CAN_H open circuit, CAN_L open circuit, CAN_H short circuit to power supply, and CAN_L short circuit to GND.

7. The dynamic closed-loop fault injection diagnostic test system based on dual triggering conditions according to claim 2, characterized in that, The Simulink test model is also used to determine the timing of sending the diagnostic request based on a preset diagnostic waiting time after the target fault is applied. When the diagnostic waiting time is zero, the Simulink test model is used to output the diagnostic request within the current simulation step or the next simulation step after the target fault is applied; When the diagnostic waiting time is greater than zero, the Simulink test model is used to wait for the diagnostic waiting time after the target fault is applied before outputting the diagnostic request.

8. The dynamic closed-loop fault injection diagnostic test system based on dual triggering conditions according to claim 1, characterized in that, The host computer is also used to parse the diagnostic response data and extract at least one of the following from the diagnostic response data: DTC number, DTC status bit, fault occurrence timestamp, diagnostic response time, and DTC set corresponding to multiple DTCs. The host computer is also used to compare at least one of the extracted DTC number, DTC status bit, fault occurrence timestamp, diagnostic response time, and DTC set with the expected result, and generate the judgment result based on the comparison result.

9. The dynamic closed-loop fault injection diagnostic test system based on dual triggering conditions according to claim 1, characterized in that, The host computer is also used to obtain the number of retries for the currently executed test case when the determination result is that the test fails, and compare the number of retries with the preset maximum number of retries; When the number of retries is less than the preset maximum number of retries, the tested ECU is reset, and the simulation environment of the HIL real-time simulation platform is restored before the current test case is executed again. When the number of retries reaches the preset maximum number of retries, the current test case is determined to be a failure, and the next test case is executed.

Images