A fault injection and diagnostic response time closed loop test system

Abstract

The application relates to the technical field of automobile testing, and discloses a fault injection and diagnosis response time closed-loop test system, which comprises an upper computer test management layer, a hardware layer and a tested ECU layer. The upper computer test management layer is used for sending test configuration information to the hardware layer, correcting a response timestamp according to timestamp information fed back by the hardware layer, and determining a fault response time. The hardware layer is used for applying a target fault to the tested ECU layer according to the test configuration information, recording a fault occurrence timestamp when the target fault is actually applied and a response timestamp when a response event is confirmed based on a unified time reference, and feeding back the timestamp information to the upper computer test management layer. The tested ECU layer is used for receiving the target fault applied by the hardware layer, and outputting a response signal corresponding to the target fault to the hardware layer. The scheme solves the problem that fault response time measurement is inaccurate due to timing starting point deviation and response confirmation delay in the existing fault injection test.

Description

Technical Field

[0001] This specification relates to the field of automotive testing technology, and in particular to a closed-loop test system for fault injection and diagnosis response time. Background Technology

[0002] As automotive electronic and electrical architecture continues to evolve, the control and diagnostic functions undertaken by the Electronic Control Unit (ECU) are increasing. Whether the ECU can respond diagnostically within a specified time when communication anomalies, wiring faults, or signal abnormalities occur has become a crucial issue in automotive electronic system testing.

[0003] Existing fault injection tests typically focus on the execution of fault injection, while diagnostic response time is mainly analyzed after acquiring signals using an oscilloscope or bus testing tools. When determining the moment of fault occurrence, if the moment the host computer issues the fault injection command is used as the timing start point, a discrepancy can easily arise between the determined timing start point and the actual moment of fault application, since the fault injection hardware still needs a certain amount of time after executing the command before the fault is actually applied to the ECU interface.

[0004] Furthermore, when monitoring bus signals, digital signals, or analog signals output by the ECU, immediately confirming the response event after a signal change can easily lead to misinterpreting signal glitches or transient fluctuations as valid responses. Conversely, if the response event is confirmed through debouncing or stability checks, the recorded response time will include the corresponding confirmation waiting time. Therefore, existing technologies struggle to accurately measure the ECU's fault response time while ensuring reliable response event identification. A closed-loop testing system for fault injection and diagnostic response time is urgently needed to address these issues. Summary of the Invention

[0005] In view of this, the present invention aims to propose a closed-loop test system for fault injection and diagnosis response time, in order to solve the problem that it is difficult to accurately determine the actual application time of the target fault and the corresponding time of the response event in existing fault injection tests, which leads to inaccurate fault response time measurement.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: A fault injection and diagnosis response time closed-loop test system, the system includes a host computer test management layer, a hardware layer and a test ECU layer, the hardware layer being connected to the host computer test management layer and the test ECU layer respectively; The host computer test management layer is used to send test configuration information to the hardware layer, correct the response timestamp based on the timestamp information fed back by the hardware layer, and determine the fault response time. The hardware layer is used to apply a target fault to the ECU layer under test according to the test configuration information, record the fault occurrence timestamp when the target fault is actually applied and the response timestamp when the response event is confirmed based on a unified time base, and feed back the timestamp information to the host computer test management layer. The ECU layer under test is used to receive the target fault applied by the hardware layer and output a response signal corresponding to the target fault to the hardware layer.

[0007] Furthermore, the host computer test management layer includes a fault configuration module, a timeline analysis module, and a report generation module; The fault configuration module is used to generate the test configuration information based on the target fault and the response event; The timeline analysis module is used to correct the response timestamp and determine the fault response time; The report generation module is used to generate a test report based on the fault response time.

[0008] Furthermore, the hardware layer includes fault injection hardware, event monitoring hardware, and a time reference unit; The fault injection hardware is used to apply the target fault to the ECU layer under test and generate a fault trigger signal when the target fault is actually applied. The event monitoring hardware is used to monitor the response signal output by the tested ECU layer and generate a response trigger signal when the response event is confirmed. The time reference unit is used to record the fault occurrence timestamp based on the fault trigger signal and the response timestamp based on the unified time reference.

[0009] Furthermore, the fault injection hardware is also used for: Monitor the electrical status of faulty output channels; When the electrical state of the fault output channel changes in accordance with the target fault, it is determined that the target fault has actually been applied, and the fault trigger signal is generated.

[0010] Furthermore, the event monitoring hardware includes at least one of a bus monitoring channel, a digital signal monitoring channel, and an analog signal monitoring channel, which are used to monitor the bus response signal, digital response signal, and analog response signal output by the ECU layer under test, respectively.

[0011] Furthermore, the bus monitoring channel, the digital signal monitoring channel, and the analog signal monitoring channel are each configured with corresponding response confirmation conditions; When the event monitoring hardware includes the bus monitoring channel, the bus monitoring channel is used to confirm the corresponding response event when the bus response signal meets the preset message matching conditions; When the event monitoring hardware includes the digital signal monitoring channel, the digital signal monitoring channel is used to confirm the corresponding response event when the digital response signal undergoes a preset level change and continues to reach a preset debouncing time; When the event monitoring hardware includes the analog signal monitoring channel, the analog signal monitoring channel is used to confirm the corresponding response event when the analog response signal meets the preset signal range or rate of change condition and continues to reach the preset stable time.

[0012] Furthermore, the timeline analysis module is also used for: Determine the listening channel corresponding to each response event; Obtain the inherent hardware latency of each monitoring channel and determine the response confirmation waiting time based on the response confirmation conditions corresponding to each monitoring channel; The timestamp correction amount for the corresponding response event is determined based on the inherent hardware latency and the response confirmation waiting time.

[0013] Furthermore, the timeline analysis module is also used for: The corrected response timestamp is obtained by subtracting the timestamp correction amount corresponding to the response event from the response timestamp corresponding to the response event. The fault response time is determined based on the time difference between the corrected response timestamp and the fault occurrence timestamp.

[0014] Furthermore, the test configuration information includes multiple response events; The timeline analysis module is also used for: Determine the corrected response timestamp and fault response time for each of the aforementioned response events; Based on the order in which the response events occur, the time difference between the corrected response timestamps corresponding to adjacent response events is calculated, and the time difference is determined as the stage response time. A fault response timeline is generated based on the fault response time and the stage response time of each of the aforementioned response events.

[0015] Furthermore, the test configuration information also includes fault tolerance time thresholds corresponding to each of the response events; The timeline analysis module is also used to compare the fault response time of each response event with the corresponding fault tolerance time threshold to obtain the response time determination result. The report generation module is used to generate the test report based on the fault response timeline and the response time determination result, and send test completion information including the response time determination result to the fault configuration module; The fault configuration module is further configured to respond to the test completion information, determine the next test configuration information based on the response time determination result, and send the next test configuration information to the hardware layer.

[0016] The principles and advantages of this invention are: 1. A closed-loop test system is constructed by establishing a host computer test management layer, a hardware layer, and the ECU under test layer. The hardware layer performs fault injection, response monitoring, and timestamp recording, while the host computer test management layer analyzes the timestamp information and generates a test report. This enables integrated testing of fault injection and fault response time measurement.

[0017] 2. By monitoring the electrical status of the fault output channel, the actual application of the target fault is determined when a change in the electrical status occurs corresponding to the target fault, and the fault occurrence timestamp is recorded based on a unified time base. This allows the actual application time of the target fault to be used as the timing starting point, improving the accuracy of the timing starting point.

[0018] 3. Response events are confirmed using the response confirmation conditions corresponding to different monitoring channels, and the response timestamp is corrected based on the inherent hardware latency and response confirmation waiting time of each monitoring channel. This reduces the impact of signal misjudgment and response confirmation delays on measurement results, improving the accuracy of fault response time measurement.

[0019] 4. By determining the fault response time and stage response time of multiple response events, a fault response timeline is generated. The fault response time is then compared with the corresponding fault tolerance time threshold. Based on the comparison result, a test report is generated and the configuration information for the next test is loaded. This enables time-series analysis and continuous closed-loop testing of multiple response events. Attached Figure Description

[0020] 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 fault injection and diagnosis response time closed-loop test system according to some embodiments of this specification; Figure 2 This is a schematic diagram illustrating the response timestamp correction principle based on some embodiments of this specification; Figure 3 This is a schematic diagram illustrating three types of response event confirmation based on some embodiments of this specification; Figure 4 This is a schematic diagram of the multi-response event fault response timeline according to some embodiments of this specification. Detailed Implementation

[0021] 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.

[0022] 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.

[0023] 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.

[0024] The following detailed explanation illustrates the specific implementation methods: ECU (Electronic Control Unit) refers to an electronic control unit. In the embodiments of this specification, the ECU is the object under test, used to receive external input signals and execute corresponding control and diagnostic functions. When the ECU receives faults such as communication abnormalities, line faults, or signal abnormalities, it can set diagnostic fault codes, output diagnostic messages, change digital signal levels, or output alternative values ​​and safety status signals according to its internal diagnostic mechanism.

[0025] The target fault is the fault that needs to be applied to the ECU layer under test. In some embodiments, the target fault can be a short circuit, open circuit, bus interference, voltage fluctuation, or abnormal signal values ​​and check errors in the bus message.

[0026] The response signal is the signal output by the ECU layer under test to the hardware layer after receiving the target fault. It can include bus response signals, digital response signals and analog response signals.

[0027] A response event is an event that occurs when the hardware layer confirms, based on the response signal output by the ECU, that the ECU has made the expected response.

[0028] The fault occurrence timestamp represents the timestamp when the target fault was actually applied, and the response timestamp represents the timestamp recorded when the response event was confirmed. The corrected response timestamp represents the timestamp obtained by subtracting the corresponding timestamp correction amount from the response timestamp, and the fault response time represents the time difference between the corrected response timestamp and the fault occurrence timestamp.

[0029] Example 1: Figure 1 This is an exemplary block diagram of a fault injection and diagnosis response time closed-loop test system according to some embodiments of this specification. Figure 1 As shown, the closed-loop test system includes a host computer test management layer, a hardware layer, and a tested ECU layer.

[0030] The host computer test management layer is used to send test configuration information to the hardware layer, correct the response timestamp based on the timestamp information fed back by the hardware layer, and determine the fault response time. The hardware layer is used to apply the target fault to the ECU under test layer according to the test configuration information, record the fault occurrence timestamp when the target fault is actually applied and the response timestamp when the response event is confirmed based on a unified time base, and feed back the timestamp information to the host computer test management layer. The ECU under test layer is used to receive the target fault applied by the hardware layer and output the response signal corresponding to the target fault to the hardware layer.

[0031] In this embodiment, the host computer test management layer is deployed within the host computer, which communicates with the hardware layer via Ethernet. The hardware layer connects to the interface under test (DUT) of the ECU layer via a fault output channel, and connects to the response output terminal of the ECU layer via at least one of a bus interface, a digital signal interface, or an analog signal interface. The Ethernet connection is used to transmit test configuration information and timestamp information, the fault output channel is used to apply a target fault to the ECU layer under test, and the aforementioned response signal interface is used to acquire the response signal output by the ECU layer under test.

[0032] In this embodiment, the fault output channel is a hardware signal path between the fault injection hardware and the interface under test (DUT) of the ECU layer being tested, used to output the target fault. The fault injection hardware determines whether the target fault is actually applied to the ECU layer being tested by monitoring the electrical state of the fault output channel.

[0033] The host computer test management layer includes a fault configuration module, a timeline analysis module, and a report generation module.

[0034] The fault configuration module generates test configuration information based on the target fault and response events.

[0035] The test configuration information is used to instruct the hardware layer to apply the target fault and listen for the corresponding response events.

[0036] In some embodiments, the target fault in the test configuration information can be configured by one or more of the following: fault type, injection interface, injection time, number of injections, and duration; the response event can be configured by the response signal type and response confirmation conditions.

[0037] The response confirmation condition is used to determine whether the response signal output by the tested ECU layer constitutes the corresponding response event. For example, the response confirmation condition for a bus response signal can be that the bus message meets a preset message matching condition; the response confirmation condition for a digital response signal can be that the digital response signal undergoes a preset level change and continues for a preset debouncing time; the response confirmation condition for an analog response signal can be that the analog response signal meets a preset signal range or rate of change condition and continues for a preset stabilization time. When the response signal meets the corresponding response confirmation condition, the event monitoring hardware confirms the corresponding response event.

[0038] Specifically, the fault configuration module reads the fault type, injection interface, injection time, injection count, and duration from pre-set test cases to form the configuration content of the target fault, and reads the response signal type and response confirmation conditions corresponding to the target fault to form the configuration content of the response event. The fault configuration module combines the configuration content of the target fault and the configuration content of the response event to generate test configuration information, and sends the test configuration information to the hardware layer so that the fault injection hardware applies the target fault and the event listening hardware listens for and confirms the corresponding response event. For a specific configuration example of a CAN communication loss fault, see Embodiment 3; for a specific configuration example of a CAN FD signal tampering fault, see Embodiment 4.

[0039] The timeline analysis module is used to receive timestamp information from the hardware layer, correct the response timestamp, and determine the fault response time based on the corrected timestamp information.

[0040] The report generation module generates a test report based on the fault response time. The test report can record the target fault, fault occurrence timestamp, response event, response timestamp, corrected response timestamp, and fault response time to facilitate analysis of the diagnostic response process after the target fault occurs.

[0041] The hardware layer includes fault injection hardware, event listening hardware, and time base unit.

[0042] The fault injection hardware is used to receive test configuration information, control the fault output channel to apply the target fault to the ECU layer under test according to the test configuration information, and generate a fault trigger signal when the target fault is actually applied.

[0043] In this embodiment, the fault injection hardware can be an FPGA-based fault injection card, and the fault output channel can be driven by a relay, optocoupler, solid-state switch, or level converter. Optionally, when the fault output channel is controlled by a solid-state switch, the solid-state switch can be a high-speed solid-state switch with a response time of less than 100ns.

[0044] The event monitoring hardware continuously monitors the response signals output by the ECU under test. Based on the response confirmation conditions in the test configuration information, it determines whether the response signal corresponds to a pre-configured response event and generates a response trigger signal upon confirmation. The event monitoring hardware operates independently of the ECU under test and can acquire response signals through the ECU under test's external bus interface, digital signal interface, or analog signal interface without utilizing the ECU under test's internal software timestamps.

[0045] The time reference unit is connected to both the fault injection hardware and the event monitoring hardware, providing a unified time reference for both. The time reference unit records the fault occurrence timestamp based on the fault trigger signal and the response timestamp based on the response trigger signal. In some embodiments, the time reference unit may use GPS / PPS or an atomic clock as the time source and record the timestamps using a time-to-digital converter within the FPGA. In one implementation of this embodiment, the time reference unit uses a GPS-disciplined crystal oscillator module, outputting a 10MHz reference clock and 1PPS second pulses.

[0046] During the closed-loop test system operation, the fault configuration module first sends test configuration information to the hardware layer. The fault injection hardware applies the target fault to the ECU under test (ECU) based on the test configuration information and generates a fault trigger signal when the target fault is actually applied. Upon receiving the target fault, the ECU under test outputs a corresponding response signal according to its internal diagnostic mechanism. The event monitoring hardware generates a response trigger signal when it confirms that the response signal corresponds to a pre-configured response event. The time base unit records the fault occurrence timestamp and response timestamp based on a unified time base, and the hardware layer feeds back the timestamp information, including the fault occurrence timestamp and response timestamp, to the host computer test management layer. The timeline analysis module corrects the response timestamp and determines the fault response time, and the report generation module generates a test report based on the fault response time.

[0047] Since both the fault occurrence timestamp and the response timestamp are recorded by the time base unit based on a unified time base, there is no need to perform post-event alignment of software clocks from different devices, enabling fault injection, response monitoring, and time analysis to be completed continuously within the same test system.

[0048] Example 2: This embodiment, based on Embodiment 1, further explains the determination of the actual application time of the target fault, the confirmation of the response event, and the correction of the response timestamp.

[0049] The fault injection hardware is also used to monitor the electrical state of the fault output channel. When the electrical state of the fault output channel changes in accordance with the target fault, the fault injection hardware determines that the target fault has been actually applied to the ECU layer under test and generates a fault trigger signal.

[0050] For example, when the target fault is an open circuit fault, the actual application of the target fault can be determined when the fault output channel changes from the on state to the off state; when the target fault is a voltage abnormality, the actual application of the target fault can be determined when the output voltage of the fault output channel changes to the state specified in the test configuration information.

[0051] The time reference unit records the fault occurrence timestamp in response to the fault trigger signal. Therefore, the moment when the host computer sends the test configuration information is not used as the starting point for the fault response time, and the hardware execution time between the host computer sending the test configuration information and the actual application of the target fault is also not included in the fault response time.

[0052] Figure 2 This is a schematic diagram illustrating the response timestamp correction principle based on some embodiments of this specification. For example... Figure 2 As shown, after the response signal output by the tested ECU layer changes, the event monitoring hardware needs to process the signal through the monitoring channel and confirm the response event according to the corresponding response confirmation conditions. The time base unit records the response timestamp when the response event is confirmed. Response timestamp Compared to the actual moment when the response signal changes, there is a time offset caused by the inherent hardware delay of the corresponding monitoring channel and the response confirmation waiting time. Therefore, the timeline analysis module adjusts the response timestamp according to the monitoring channel and response confirmation conditions of the corresponding response event. Make corrections.

[0053] In this embodiment, the timeline analysis module first determines the first... For each response event, obtain the listening channel corresponding to that listening channel and its inherent hardware latency. And determine the response confirmation waiting time based on the response confirmation conditions corresponding to the monitoring channel. Then determine the timestamp correction amount according to the following formula. : = + ; in, Indicates the sequence number of the response event. Indicates the first Each response event corresponds to the inherent hardware latency of the listening channel. Indicates the first The response confirmation waiting time for each response event. Indicates the first The timestamp correction amount corresponding to each response event.

[0054] The timeline analysis module uses response timestamps Deduct timestamp correction amount Receive the corrected response timestamp : = - ; Then based on the corrected response timestamp timestamp of the failure The time difference between them is determined. Fault response time Δ for each response event : Δ = - ; The inherent hardware latency of each monitoring channel can be calibrated before testing. For example, the inherent hardware latency can be obtained by measuring the time difference between the input of the response signal to the monitoring channel and the detection of the signal change by the monitoring channel using an oscilloscope, or by using factory calibration or self-test calibration, and the calibration results can be saved for use by the timeline analysis module.

[0055] The response confirmation waiting time is determined according to the corresponding response confirmation conditions. Specifically, the response confirmation waiting time for the digital signal monitoring channel includes the preset debounce time, the response confirmation waiting time for the analog signal monitoring channel includes the preset stabilization time, and the response confirmation waiting time for the bus monitoring channel is determined according to the preset message matching conditions.

[0056] Figure 3 This is a schematic diagram illustrating three types of response event confirmation based on some embodiments of this specification. For example... Figure 3 As shown, the event monitoring hardware includes at least one of a bus monitoring channel, a digital signal monitoring channel, and an analog signal monitoring channel. Each monitoring channel is configured with corresponding response confirmation conditions. After confirming a response event, each monitoring channel generates a response trigger signal to the time base unit, which then records the corresponding response timestamp based on a unified time base.

[0057] When the event monitoring hardware includes a bus monitoring channel, the bus monitoring channel is used to monitor the bus response signal output by the ECU layer under test.

[0058] In some embodiments, the bus monitoring channel may include an FPGA and a protocol controller for capturing messages on a CAN, CANFD, or Ethernet bus and filtering messages according to message identifiers, diagnostic fault code masks, or fault status bits configured in the test configuration information. When a bus response signal meets a preset message matching condition, the bus monitoring channel acknowledges the corresponding response event.

[0059] For example, a corresponding response event can be confirmed when a preset change is detected in the confirmation status bit of a specified diagnostic fault code, or when a diagnostic response message corresponding to a specified diagnostic fault code is detected.

[0060] When the event monitoring hardware includes a digital signal monitoring channel, the digital signal monitoring channel is used to monitor digital response signals such as fault indicator lights or safety status output pins. The digital signal monitoring channel is configured with preset level changes and preset debounce time. When the digital response signal undergoes a preset level change and continues to reach the preset debounce time, the corresponding response event is confirmed.

[0061] For example, the response event can be confirmed when the digital response signal changes from high to low and remains low for 100 ns, in order to reduce misjudgments caused by transient glitches.

[0062] When the event monitoring hardware includes an analog signal monitoring channel, the analog signal monitoring channel is used to monitor analog response signals such as substitution values ​​or limp states. The analog signal monitoring channel can be configured with voltage or current ranges, rate of change conditions, or deviation ranges from preset reference values, and continuously acquires analog response signals via an analog-to-digital converter. When the analog response signal meets the preset signal range or rate of change condition and continues to reach a preset settling time, the corresponding response event is confirmed.

[0063] For example, the analog signal monitoring channel can use an analog-to-digital converter with a sampling rate of not less than 1MSPS to confirm the response event when the analog response signal enters the preset signal range of 2.5V±0.1V and lasts for 200μs.

[0064] Therefore, each monitoring channel does not directly confirm the response event when the response signal changes instantaneously, but only after the response signal meets the corresponding confirmation conditions, thereby reducing misjudgments caused by signal glitches or instantaneous fluctuations. Simultaneously, by subtracting the inherent hardware delay and response confirmation waiting time from the response timestamp, the time offset caused by the response confirmation process is reduced. Under the above calibration and configuration conditions, the residual random error of each monitoring channel can be controlled within ±200ns; when the error of the time reference unit itself is less than 100ns, the overall error of the closed-loop test system can be controlled within 300ns.

[0065] Example 3: This embodiment, based on Embodiment 1 and Embodiment 2, further explains the fault response time analysis and continuous closed-loop testing of multiple response events.

[0066] Figure 4 This is a schematic diagram of the multi-response event fault response timeline according to some embodiments of this specification. For example... Figure 4 As shown, the test configuration information includes multiple response events and the corresponding fault tolerance time threshold for each response event. The event monitoring hardware monitors multiple response events conforming to the test configuration information in real time and generates corresponding response trigger signals for each response event. The time base unit records the response timestamp of each response event based on a unified time base. The timeline analysis module determines the corrected response timestamp and fault response time for each response event according to the method described in Embodiment 2, and sorts the response events according to the corrected response timestamp.

[0067] For adjacent th - The first response event and the first For each response event, the timeline analysis module calculates the time difference between the corrected response timestamps and determines this time difference as the stage response time. : = - ; in, Indicates the first - The response event up to the first Phase response time of each response event Indicates the first The corrected response timestamp for each response event. Indicates the first - The corrected response timestamp for each response event.

[0068] The timeline analysis module generates a fault response timeline based on the fault response time and stage response time of each response event, and compares the fault response time of each response event with the corresponding fault tolerance time threshold. When the fault response time of a response event is not greater than the corresponding fault tolerance time threshold, the response time determination result is obtained that the response event meets the fault tolerance time requirement; when the fault response time is greater than the corresponding fault tolerance time threshold, the response time determination result is obtained that the response event does not meet the fault tolerance time requirement.

[0069] The report generation module generates a test report based on the fault response timeline and the response time determination results for each response event, and sends test completion information, including the response time determination results, to the fault configuration module. In response to the test completion information, the fault configuration module determines the next test configuration information based on the response time determination results and sends the next test configuration information to the hardware layer.

[0070] In some embodiments, when all response events in the current test meet the corresponding fault tolerance time requirements, the fault configuration module can load the test configuration information corresponding to the next target fault; when there are response events that do not meet the corresponding fault tolerance time requirements, the fault configuration module can adjust the number of injections or the duration of maintenance of the target fault according to the response time determination result to form the next test configuration information, so as to verify the corresponding test items again.

[0071] The following explanation uses the diagnostic response time test for CAN communication loss fault as an example. The ECU under test is the Body Domain Controller (BDM), which supports the UDS diagnostic protocol and has CAN communication loss fault detection functionality. The time reference unit uses a GPS-disciplined crystal oscillator module, outputting a 10MHz reference clock and 1PPS pulse per second. The fault injection hardware uses an FPGA-based CAN bus fault injection card. The event monitoring hardware includes a CAN bus monitoring channel and a digital signal monitoring channel. The CAN bus monitoring channel is used to monitor the bus response signal corresponding to diagnostic fault code U0073, and the digital signal monitoring channel is connected to the fault indicator output pin of the BDM. The host computer test management layer communicates with the hardware layer via Ethernet.

[0072] The test configuration information generated by the fault configuration module indicates that the fault injection hardware continuously inserts error frames during the transmission of a specified CAN message, causing the body domain controller (BDM) to detect the loss of CAN communication, and configures the response event corresponding to the diagnostic fault code U0073 and the response event corresponding to the fault indicator light illumination as two response events.

[0073] In a specific example, the fault injection hardware inserts five consecutive error frames during the transmission of the 10th frame of the message with message identifier 0x123; when the reception period of the message is 200μs, the target fault injection window corresponding to the five error frames is 1ms.

[0074] The fault injection hardware generates a fault trigger signal when the electrical state of the fault output channel actually changes, and the time base unit records the fault occurrence timestamp. and with As the starting point of the relative time axis, the CAN bus monitoring channel confirms the first response event when the bus response signal meets the preset message matching conditions corresponding to diagnostic fault code U0073, and the digital signal monitoring channel confirms the second response event when the fault indicator output pin changes from high level to low level and remains there for a preset debouncing time. The time reference unit records the response timestamps when the two response events are confirmed.

[0075] The timeline analysis module determines the timestamp correction amount for the CAN bus monitoring channel and the digital signal monitoring channel, and corrects the two response timestamps.

[0076] In this example, the corrected fault code response time is 47.123ms, and the fault indicator response time is 89.345ms. The fault tolerance time threshold for both response events is configured to 100ms. Therefore, the fault response times for both events are no greater than the corresponding fault tolerance time threshold, and the response time determination result meets the fault tolerance time requirement. The timeline analysis module also determines the stage response time between the two corrected response timestamps based on the time difference and generates a fault response timeline. The report generation module generates a test report based on the fault response timeline and the response time determination result, and the fault configuration module determines and sends the next test configuration information based on the response time determination result.

[0077] This embodiment records the actual application time of the target fault and the response time corresponding to the diagnostic fault code and fault indicator light using the same time base, and corrects the response timestamps recorded by different monitoring channels. This allows the fault response time and stage response time of multiple response events to be determined without modifying the BDM software.

[0078] Example 4: Based on Examples 1 to 3, this embodiment uses the diagnostic response time test of CAN FD signal tampering fault as an example to illustrate the combined monitoring of bus response signal and analog response signal.

[0079] The tested ECU layer is the Power Domain Controller (PDCU), which communicates with the vehicle via the CAN FD bus. The target fault is the tampering with the accelerator pedal position signal in the CAN FD message and corrupting the cyclic redundancy check (CRC) field of the message. In a specific example, the normal range of the accelerator pedal position signal is 0–100%, with a signal period of 50ms. The test configuration information generated by the fault configuration module instructs the fault injection hardware to tamper with the accelerator pedal position signal to 150% at the 23ms mark of a signal period and toggle the CRC bit of the message.

[0080] The event monitoring hardware includes a CAN FD bus monitoring channel and an analog signal monitoring channel. The CAN FD bus monitoring channel is used to monitor the bus response signal corresponding to diagnostic fault code P2122, and the analog signal monitoring channel is used to monitor the engine torque command voltage output by the power domain controller (PDCU). The test configuration information configures the response event corresponding to diagnostic fault code P2122 and the response event corresponding to the default value of switching the engine torque command to limp state as two separate response events.

[0081] The fault injection hardware generates a fault trigger signal when the target fault is actually applied, and the time base unit records the fault occurrence timestamp. The CAN FD bus monitoring channel confirms the first response event when the bus response signal meets the preset message matching conditions corresponding to diagnostic fault code P2122. The analog signal monitoring channel confirms the second response event when the engine torque command voltage enters the preset signal range corresponding to the limp-state default value and continues to do so for a preset stabilization time. The time reference unit records the response timestamps when the two response events are confirmed.

[0082] The timeline analysis module determines the timestamp correction amount based on the inherent hardware latency and response confirmation waiting time of the corresponding monitoring channels for the two response events, and obtains the corrected response timestamps for the two response events. In this example, the corrected fault response time for the diagnostic fault code response event is 52.3ms, and the fault response time corresponding to the engine torque command switching to the default limp state is 78.9ms. The fault tolerance time threshold for both response events is configured to 150ms, therefore the response time determination results for both response events meet the fault tolerance time requirements. The report generation module generates a test report based on the fault response time, stage response time, and response time determination results of the two response events. The fault configuration module determines and sends the next test configuration information based on the response time determination results.

[0083] This embodiment applies a target fault that simultaneously includes abnormal signal values ​​and verification errors to the tested ECU layer, and uses bus monitoring channels and analog signal monitoring channels to confirm different types of response events. It can obtain the fault response time of diagnostic response and safety status response under a unified time base, reflecting the multi-level response process of the power domain controller PDCU to the composite target fault.

[0084] 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 closed-loop test system for fault injection and diagnosis response time, characterized in that, The system includes a host computer test management layer, a hardware layer, and a test ECU layer, wherein the hardware layer is connected to the host computer test management layer and the test ECU layer respectively. The host computer test management layer is used to send test configuration information to the hardware layer, correct the response timestamp based on the timestamp information fed back by the hardware layer, and determine the fault response time. The hardware layer is used to apply a target fault to the ECU layer under test according to the test configuration information, record the fault occurrence timestamp when the target fault is actually applied and the response timestamp when the response event is confirmed based on a unified time base, and feed back the timestamp information to the host computer test management layer. The ECU layer under test is used to receive the target fault applied by the hardware layer and output a response signal corresponding to the target fault to the hardware layer.

2. The fault injection and diagnosis response time closed-loop test system according to claim 1, characterized in that, The host computer test management layer includes a fault configuration module, a timeline analysis module, and a report generation module; The fault configuration module is used to generate the test configuration information based on the target fault and the response event; The timeline analysis module is used to correct the response timestamp and determine the fault response time; The report generation module is used to generate a test report based on the fault response time.

3. The fault injection and diagnosis response time closed-loop test system according to claim 2, characterized in that, The hardware layer includes fault injection hardware, event monitoring hardware, and a time base unit; The fault injection hardware is used to apply the target fault to the ECU layer under test and generate a fault trigger signal when the target fault is actually applied. The event monitoring hardware is used to monitor the response signal output by the tested ECU layer and generate a response trigger signal when the response event is confirmed. The time reference unit is used to record the fault occurrence timestamp based on the fault trigger signal and the response timestamp based on the unified time reference.

4. The fault injection and diagnosis response time closed-loop test system according to claim 3, characterized in that, The fault injection hardware is also used for: Monitor the electrical status of faulty output channels; When the electrical state of the fault output channel changes in accordance with the target fault, it is determined that the target fault has actually been applied, and the fault trigger signal is generated.

5. The fault injection and diagnosis response time closed-loop test system according to claim 3, characterized in that, The event monitoring hardware includes at least one of a bus monitoring channel, a digital signal monitoring channel, and an analog signal monitoring channel, which are used to monitor the bus response signal, digital response signal, and analog response signal output by the ECU layer under test, respectively.

6. The fault injection and diagnosis response time closed-loop test system according to claim 5, characterized in that, The bus monitoring channel, the digital signal monitoring channel, and the analog signal monitoring channel are each configured with corresponding response confirmation conditions; When the event monitoring hardware includes the bus monitoring channel, the bus monitoring channel is used to confirm the corresponding response event when the bus response signal meets the preset message matching conditions; When the event monitoring hardware includes the digital signal monitoring channel, the digital signal monitoring channel is used to confirm the corresponding response event when the digital response signal undergoes a preset level change and continues to reach a preset debouncing time; When the event monitoring hardware includes the analog signal monitoring channel, the analog signal monitoring channel is used to confirm the corresponding response event when the analog response signal meets the preset signal range or rate of change condition and continues to reach the preset stable time.

7. The fault injection and diagnosis response time closed-loop test system according to claim 6, characterized in that, The timeline analysis module is also used for: Determine the listening channel corresponding to each response event; Obtain the inherent hardware latency of each monitoring channel and determine the response confirmation waiting time based on the response confirmation conditions corresponding to each monitoring channel; The timestamp correction amount for the corresponding response event is determined based on the inherent hardware latency and the response confirmation waiting time.

8. The fault injection and diagnosis response time closed-loop test system according to claim 7, characterized in that, The timeline analysis module is also used for: Subtract the timestamp correction amount corresponding to the response event from the response timestamp corresponding to the response event to obtain the corrected response timestamp; The fault response time is determined based on the time difference between the corrected response timestamp and the fault occurrence timestamp.

9. The fault injection and diagnosis response time closed-loop test system according to claim 8, characterized in that, The test configuration information includes multiple response events; The timeline analysis module is also used for: Determine the corrected response timestamp and fault response time for each of the aforementioned response events; Based on the order in which the response events occur, the time difference between the corrected response timestamps corresponding to adjacent response events is calculated, and the time difference is determined as the stage response time. A fault response timeline is generated based on the fault response time and the stage response time of each of the aforementioned response events.

10. A closed-loop test system for fault injection and diagnosis response time according to claim 9, characterized in that, The test configuration information also includes fault tolerance time thresholds corresponding to each of the response events; The timeline analysis module is also used to compare the fault response time of each response event with the corresponding fault tolerance time threshold to obtain the response time determination result. The report generation module is used to generate the test report based on the fault response timeline and the response time determination result, and send test completion information including the response time determination result to the fault configuration module; The fault configuration module is further configured to respond to the test completion information, determine the next test configuration information based on the response time determination result, and send the next test configuration information to the hardware layer.

Images