Real-time fault judgment method and system based on ADAS hardware-in-loop simulation platform

Abstract

The invention provides a real-time fault judgment method and system based on an ADAS hardware-in-the-loop simulation platform. The real-time fault judgment method comprises the steps that an anomaly detection unit is connected into a test bench; when the test bench is started, the abnormity detection unit is controlled to carry out real-time detection on the test bench according to a preset time sequence so as to acquire real-time detection data; comparing the real-time detection data with preset operation data in real time; if the real-time detection data is different from the preset operation data, determining that the test bench has a fault point, and giving a fault alarm; and carrying out troubleshooting on the test bench according to the fault alarm. The invention solves the technical problems that an HIL test bench is usually adopted in the traditional automatic test, the HIL test bench cannot immediately identify component or link faults in the test process, and the problem needs to be found through log analysis after the test is finished, so that the troubleshooting lags.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic testing and verification technology, and more specifically, to a real-time fault diagnosis method and system based on an ADAS hardware-in-the-loop simulation platform. Background Technology

[0002] With the rapid development of automotive intelligent technology, Advanced Driver Assistance Systems (ADAS) have become a core component for improving vehicle safety and driving experience. To ensure the stable operation of ADAS under complex road conditions, Hardware-in-the-Loop (HIL) simulation test platforms are widely used in the research and development and verification process of ADAS. This platform combines the hardware controller of ADAS with software modules such as virtual sensors and vehicle dynamics models by building a virtual test environment. It can simulate a large number of real driving scenarios and achieve efficient testing of ADAS functions.

[0003] However, the relevant technologies have at least one of the following problems: traditional automated testing usually uses HIL test benches, but HIL test benches cannot immediately identify component or link failures during the testing process. Problems need to be discovered through log analysis after the test is completed, which leads to a delay in troubleshooting. Summary of the Invention

[0004] The technical problem solved by this invention is that traditional automated testing usually uses HIL test benches, but HIL test benches cannot immediately identify component or link failures during the testing process. Problems need to be discovered through log analysis after the test is completed, which leads to a delay in troubleshooting.

[0005] To address the aforementioned issues, this invention provides a real-time fault diagnosis method based on an ADAS hardware-in-the-loop simulation platform, comprising: connecting an anomaly detection unit to a test bench; when the test bench is started, controlling the anomaly detection unit to perform real-time detection on the test bench according to a preset timing sequence to obtain real-time detection data; comparing the real-time detection data with preset operating data in real time; if the real-time detection data differs from the preset operating data, determining that there is a fault point on the test bench and issuing a fault alarm; and troubleshooting the test bench based on the fault alarm.

[0006] Compared with existing technologies, the technical effects achieved by this solution are as follows: Compared with related technologies where HIL test benches cannot identify faults during testing, this invention integrates an anomaly detection unit into the test bench and performs real-time fault detection during and after the test bench's startup process according to a preset timing sequence. Through a "real-time comparison-alarm" mechanism, it compares real-time data with preset data, determines faults in real time, and issues an alarm. This achieves real-time fault judgment throughout the entire process of the test bench from startup to operation, breaking the post-test analysis model and establishing a closed-loop detection mode of real-time monitoring, immediate alarm, and rapid troubleshooting.

[0007] In one embodiment of the present invention, the preset operating data includes a hardware benchmark dataset; the control anomaly detection unit performs real-time detection on the test bench according to a preset timing sequence, including: controlling the anomaly detection unit to perform real-time detection on the hardware units in the test bench to obtain a first dataset; comparing the first dataset with the hardware benchmark dataset; if the data in the first dataset and the hardware benchmark dataset match, then controlling the anomaly detection unit to perform real-time detection on the software units in the test bench; if the data in the first dataset and the hardware benchmark dataset do not match, then controlling the anomaly detection unit to filter the first dataset and locate the data difference points; and troubleshooting the test bench based on the data difference points.

[0008] Compared with existing technologies, the technical effects achieved by this solution are as follows: When performing real-time testing on the test bench, the hardware units are tested first. The logic of comparing data first and then locating the differences in the data is clearly defined during the hardware unit testing process. This achieves a hierarchical judgment of hardware faults by first matching the overall data and then locating the differences, thereby improving the accuracy and efficiency of hardware unit fault diagnosis.

[0009] In one embodiment of the present invention, the preset running data further includes a software benchmark dataset; controlling the anomaly detection unit to perform real-time detection on the software units in the test bench includes: acquiring real-time detection data of the software units, denoted as a second dataset; comparing the second dataset with the software benchmark dataset according to preset rules; if there are data differences between the second dataset and the software benchmark dataset, controlling the anomaly detection unit to filter the second dataset, locate the data difference points, and issue a fault alarm; and troubleshooting the test bench based on the data difference points.

[0010] Compared with existing technologies, the technical effects achieved by this solution are as follows: when the first dataset in the hardware unit matches the hardware benchmark dataset, the software unit is then tested, thus building an independent testing system for the software unit; by establishing a comparison standard specific to the software unit through the software benchmark dataset, real-time identification and precise location of software faults are achieved.

[0011] In one embodiment of the present invention, the control anomaly detection unit performs real-time detection on the hardware unit in the test bench to obtain a first dataset, including: sending an initialization command to the hardware unit; performing real-time detection on the initialization status of the hardware unit to obtain a feedback signal value; comparing the feedback signal value with the CAN signal value in the hardware reference dataset; if the feedback signal value is consistent with the CAN signal value, it is determined that the hardware unit has completed initialization; if the feedback signal value is inconsistent with the CAN signal value and the output serial port of the hardware unit is abnormal, it is determined that a first fault type exists in the hardware unit and a fault alarm is issued; the first fault type includes failure to restore ADAS function status bits or failure to completely clear fault codes; wherein, the feedback signal value is included in the first dataset.

[0012] Compared with existing technologies, the technical effects achieved by this solution are as follows: during the hardware unit initialization phase, by comparing the feedback signal value with the CAN signal value, the faults during the hardware unit initialization phase can be identified in real time, avoiding the waste of subsequent test resources due to incomplete initialization.

[0013] In one embodiment of the present invention, after determining that the hardware unit has completed initialization, the real-time fault judgment method further includes: sending a communication link detection command to the hardware unit; collecting the response time of each node in the hardware unit in response to the communication link detection command; comparing the response time with the delay threshold in the hardware benchmark dataset; if any response time is greater than the delay threshold, then determining that there is a second fault type in the hardware unit, the second fault type including network interface fault; if the response time of all nodes is greater than the delay threshold, then determining that there is a third fault type in the hardware unit, the third fault type including hardware fault; wherein, the response time is included in the first dataset.

[0014] Compared with existing technologies, the technical effects achieved by adopting this technical solution are as follows: After hardware initialization, by comparing response time with latency pre-set, a hierarchical judgment logic for communication link failure is established, realizing the typological positioning of each hardware link failure in the hardware unit, and solving the problem that traditional test summaries only know that there is an anomaly in the link, but do not know the specific fault point.

[0015] In one embodiment of the present invention, acquiring real-time detection data of the software unit includes: performing fault diagnosis monitoring on the video stream output by the sensor module in the software unit; acquiring continuous frame data of the video stream in real time, and controlling the anomaly detection unit to monitor the output status of each frame image; if a single frame image is frozen and the duration exceeds a first preset duration, it is determined that there is a fourth fault type in the video injection link, and a video stream anomaly alarm is triggered; the fourth fault type includes sensor output frame freezing.

[0016] Compared with existing technologies, the technical effects achieved by this technical solution are as follows: In the process of detecting software units, video stream faults are included in the scope of real-time software detection. By monitoring whether a single frame image in the video stream is frozen and the duration of the freeze, it is determined whether the sensor has an output frame freeze fault and an alarm is issued, thus realizing an immediate alarm for abnormal sensor analog data input.

[0017] In one embodiment of the present invention, after performing fault diagnosis monitoring on the video stream output by the sensor module in the software unit, the real-time fault judgment method further includes: obtaining the currently loaded running use case ID of the software unit and reading the preset scenario parameters corresponding to the running use case ID; comparing the running use case ID with the planned use case ID in the software benchmark dataset; if the running use case ID is inconsistent with the planned use case ID, determining that there is a fifth fault type in the software unit, recording the difference information between the actual use case ID and the planned use case ID, and issuing a fault alarm; the fifth fault type includes use case loading anomaly; and incorporating the comparison results and difference information into the second dataset.

[0018] Compared with existing technologies, the technical effects achieved by this solution are as follows: after video stream detection, the consistency verification between the running test case ID and the planned test case ID identifies test case loading anomalies, enabling real-time verification of core parameters of the test scenario and avoiding invalid testing throughout the entire process due to test case loading errors; furthermore, it forms a dual software detection system of "input data - control parameters" with video stream detection, improving the reliability of the software unit.

[0019] In one embodiment of the present invention, after comparing the running use case ID with the planned use case ID in the software benchmark dataset, the real-time fault judgment method further includes: if the running use case ID is consistent with the planned use case ID, and the preset scene parameters match the actual scene features of the video stream, then the vehicle control signal output by the software unit and the actual response speed fed back by the vehicle dynamics model are obtained; the theoretical speed corresponding to the vehicle control signal is compared with the actual response speed in real time; the deviation value between the actual response speed and the theoretical speed is calculated, and the average deviation value within a continuous preset time period is statistically analyzed; if the average deviation value exceeds the preset deviation threshold, then the software unit is determined to have a sixth fault type, and the deviation parameters and the timestamp of the abnormality are recorded; the sixth fault type includes a mismatch between the vehicle control signal and the vehicle speed response; the real-time comparison result, the deviation parameters, and the fault type are included in the second dataset.

[0020] Compared with existing technologies, the technical effects achieved by this solution are as follows: After the use case ID is matched, the real-time monitoring of the vehicle control signal execution effect is realized by comparing the deviation between the theoretical vehicle speed and the actual response vehicle speed. Combined with video stream detection and use case ID detection in software unit detection, it covers the entire link detection of the software unit from the input video stream to the control use case ID and the final output vehicle control signal.

[0021] In one embodiment of the present invention, the real-time fault diagnosis method further includes: after the test bench is started, controlling the anomaly detection unit to perform real-time synchronous detection on the hardware units and software units in the test bench to obtain the detection data of the test bench during operation; and judging the fault points of the hardware units and software units based on the detection data.

[0022] Compared with existing technologies, the technical effects achieved by this solution are as follows: after the test bench is successfully started, the control anomaly detection unit simultaneously detects the hardware and software units, realizing detection covering the entire operation cycle of the test bench and improving the comprehensiveness of fault diagnosis.

[0023] In one embodiment of the present invention, a real-time fault diagnosis system based on an ADAS hardware-in-the-loop simulation platform is also provided, which can realize the real-time fault diagnosis method in any of the above embodiments. The fault diagnosis system includes: an anomaly detection unit, which is used to compare real-time detection data with preset running data in real time and to troubleshoot the test bench according to fault alarms; a host computer, which is used to generate test plans, configure software benchmark datasets and hardware benchmark datasets, and issue running test case instructions to the real-time machine; a slave computer, which is used to drive the hardware actuators of the test bench and collect the initialization status signals and communication link status data of the hardware units; a real-time machine, which is used to run vehicle dynamics models and virtual scene simulations, generate sensor simulation data, and synchronously coordinate the data interaction between the host computer and the controller; a controller, which is used to receive sensor simulation data output by the real-time machine, execute ADAS algorithms and output vehicle control signals, and send video stream fault diagnosis signals and running test case IDs through the vehicle Ethernet; and a hardware unit composed of the host computer, slave computer, real-time machine and controller.

[0024] Compared with existing technologies, the technical effects achieved by adopting this technical solution are: it can achieve the technical effects in any of the above examples, which will not be elaborated here.

[0025] By adopting the technical solution of the present invention, the following technical effects can be achieved: (1) The present invention integrates an anomaly detection unit into the test bench and performs real-time fault detection during the start-up process and after the start-up of the test bench according to a preset time sequence. Through the mechanism of "real-time comparison-alarm", the real-time data and preset data are compared, and the fault is determined and alarm is triggered in real time. This realizes real-time fault judgment of the entire process from start-up to operation of the test bench, breaks the post-test analysis mode, and establishes a closed-loop detection mode of real-time monitoring, instant alarm and rapid troubleshooting. (2) When the test bench is tested in real time, the present invention first tests the hardware unit and then tests the software unit. The present invention clarifies the logic of comparing data first and then locating the difference data in the hardware unit testing process. This realizes the hierarchical judgment of hardware faults by first matching the whole and then locating the difference points, which improves the accuracy and efficiency of hardware unit fault diagnosis. When the first dataset in the hardware unit matches the hardware benchmark dataset, the software unit is then tested, thus building an independent testing system for the software unit. By establishing a comparison standard for the software unit through the software benchmark dataset, the real-time identification and accurate location of software faults are realized. (3) After the test bench is successfully started, the present invention controls the abnormal detection unit to detect the hardware unit and software unit simultaneously, realizing detection covering the entire operation cycle of the test bench and improving the comprehensiveness of fault judgment. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings to be used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Figure 1 A flowchart illustrating a real-time fault diagnosis method based on an ADAS hardware-in-the-loop simulation platform, provided as an embodiment of the present invention; Figure 2 This is an architecture diagram of hardware connection and communication methods in a fault diagnosis system based on an ADAS hardware-in-the-loop simulation platform. Figure 3 This is a diagram showing the software workflow and anomaly detection mechanism in a fault diagnosis system based on an ADAS hardware-in-the-loop simulation platform. Detailed Implementation

[0027] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0028] See Figure 1 , Figure 1A flowchart illustrating a real-time fault diagnosis method based on an ADAS hardware-in-the-loop simulation platform is provided in this embodiment of the invention; combined with Figure 2 and Figure 3 Specifically, a real-time fault diagnosis method based on an ADAS hardware-in-the-loop simulation platform includes: S1: Connect an anomaly detection unit to the test bench; S2: When the test bench is started, the control anomaly detection unit performs real-time detection on the test bench according to a preset timing sequence to obtain real-time detection data; S3: Compare real-time detection data with preset operating data in real time; S31: If the real-time detection data is different from the preset operating data, it is determined that there is a fault point on the test bench and a fault alarm is issued; S32: If the real-time monitoring data is the same as the preset running data, the test bench is determined to have started successfully, and the anomaly detection unit is controlled to monitor the hardware and software in the test bench in real time. S4: Troubleshoot the test bench based on the fault alarm.

[0029] The real-time detection data includes at least one of the following: controller initialization status, video stream diagnostic signal, network node communication status, rolling counter signal, and vehicle speed response error.

[0030] The preset operating data includes: Depending on the specific work situation, due to the different startup and operation mechanisms of software and hardware, software faults and hardware anomalies are often decoupled. Therefore, the monitoring of anomalies needs to follow certain timing rules. After each component of the test bench is installed, the simulation program of the host computer and the CAN signal processing environment of the real-time machine need a certain amount of time to complete initialization. At this time, the control has not yet formed a closed loop. Therefore, the first step is to check whether the hardware has completed initialization and whether there are communication faults between the hardware components through the anomaly detection unit. Once it is confirmed that each hardware component has started successfully, the fault detection is then performed at the software level.

[0031] Furthermore, once both the hardware and software layers have started normally, various test case IDs need to be debugged and simulated. At this point, the anomaly detection unit needs to monitor both the hardware and software in the test bench simultaneously to ensure that fault points in the hardware and software of different test case IDs can be detected in a timely manner.

[0032] In one example, an anomaly detection unit is integrated into the test bench. When the test bench starts, the anomaly detection unit first performs hardware checks according to a preset timing sequence. After the hardware checks are completed and the real-time detection data returned by the hardware matches the preset running data, the software checks are then performed. The software monitoring mainly focuses on video stream fault diagnosis, perception result monitoring, and running test case ID checks. If the real-time detection data returned by the software matches the preset running data, the test bench is considered to have started successfully, and the anomaly detection unit switches from the preset timing monitoring mode to the continuous monitoring mode to perform real-time monitoring of the hardware and software. When a fault alarm is received, the tester uses the alarm information, combined with the fault occurrence time and fault data recorded by the anomaly detection unit, to troubleshoot the test bench.

[0033] Furthermore, the preset operating data includes a hardware benchmark dataset; the control anomaly detection unit performs real-time detection on the test bench according to a preset timing sequence to obtain real-time detection data, including: The anomaly detection unit controls the hardware units in the test bench to perform real-time detection in order to obtain the first dataset; The first dataset is compared with the hardware benchmark dataset; If the data in the first dataset matches the data in the hardware benchmark dataset, then control the anomaly detection unit to perform real-time detection on the software units in the test bench. If the first dataset does not match the hardware benchmark dataset, the anomaly detection unit is controlled to filter the first dataset and locate the data differences. Troubleshooting of the test bench is performed based on data discrepancies.

[0034] Preferably, the hardware benchmark dataset in the preset operating data is stored in the database of the host computer. This dataset contains the standard values ​​of various parameters of each hardware component when it is working normally.

[0035] Preferably, the hardware benchmark dataset includes standard CAN signal values ​​for hardware initialization, communication delay thresholds for each node, etc.

[0036] Based on the specific working conditions, the anomaly detection unit performs real-time detection on the hardware units in the test bench, acquiring real-time data from each hardware component to form the first dataset. This first dataset is then compared with the hardware benchmark dataset. For example, the data collected shows that the network latency of a certain port on the switch in the hardware unit is 80ms, and the signal transmission rate of the CAN channel is 500kbps. The hardware benchmark dataset shows that the normal network latency of the switch port is 0-50ms, and the normal signal transmission rate of the CAN channel is 500kbps. The comparison reveals that the 80ms network latency of the switch port exceeds the benchmark range, indicating a network node failure causing communication delays, while the CAN channel signal transmission rate is within the benchmark range.

[0037] Because the first dataset does not match the hardware benchmark dataset, the anomaly detection unit will filter the first dataset and locate the data difference point as the network latency of the switch port. Based on this data difference point, the testers will check the port connection, network configuration, and other aspects of the switch to solve the problem of delayed network fault diagnosis.

[0038] Furthermore, if the data in the first dataset matches the data in the hardware benchmark dataset, such as the network latency of the aforementioned switch port being 30ms and the CAN channel signal transmission rate being 500kbps, both within the benchmark range, then the control anomaly detection unit will begin real-time detection of the software unit in the test bench.

[0039] Furthermore, the preset operating data also includes a software benchmark dataset; the control anomaly detection unit performs real-time detection of the software units in the test bench, including: Acquire real-time detection data from the software unit, and denote it as the second dataset; The second dataset is compared with the software benchmark dataset according to preset rules; If the second dataset differs from the software benchmark dataset, the anomaly detection unit will filter the second dataset, locate the data discrepancies, and issue a fault alarm. If the data in the second dataset is the same as the data in the software benchmark dataset, the software unit is determined to start normally, and the anomaly detection unit is controlled to perform real-time monitoring of the hardware and software units in the test bench simultaneously. Troubleshooting of the test bench is performed based on data discrepancies.

[0040] Preferably, the software benchmark dataset in the preset running data is also stored on the host computer, which includes various parameter standards when the software unit is running normally, such as the upper limit of the scene loading response time being 2 seconds, and the output perception result data, etc.

[0041] Based on the specific work situation, the anomaly detection unit acquires real-time detection data from the software unit to form a second dataset. This second dataset is then compared with the software benchmark dataset according to preset rules. For example, if the software unit's response time for loading a "city road scene" is 3 seconds, and the preset rule is that the response time should not exceed 2 seconds, then the software unit's response time exceeds the 2-second limit in the benchmark dataset. This indicates a discrepancy between the second dataset and the benchmark dataset, suggesting a scene loading failure in the software unit's detection, leading to post-testing issues. At this point, the anomaly detection unit filters the second dataset, identifying the scene loading response time as the source of the discrepancy, and issues a fault alarm through the test bench's alarm system. Testers then examine the software's scene loading code logic based on this discrepancy.

[0042] Furthermore, the anomaly detection unit controls the hardware units in the test bench to perform real-time detection to obtain the first dataset, including: Send initialization instructions to the hardware unit; The initialization status of the hardware unit is detected in real time to obtain feedback signal values; The feedback signal value is compared with the CAN signal value in the hardware benchmark dataset; If the feedback signal value is consistent with the CAN signal value, it is determined that the hardware unit has completed initialization; If the feedback signal value is inconsistent with the CAN signal value and the output serial port of the hardware unit is abnormal, it is determined that there is a first type of fault in the hardware unit and a fault alarm is issued. The feedback signal value is included in the first dataset.

[0043] Preferably, the first fault type includes failure to restore ADAS function status bits or failure to completely clear fault codes.

[0044] Depending on the specific situation, the anomaly detection unit sends specific code to the hardware unit to cause the hardware unit to perform an initialization operation. After receiving the initialization command, the hardware unit begins initialization and feeds back the initialization status signal value to the anomaly detection unit. The anomaly detection unit monitors the initialization status of the hardware unit in real time and obtains the feedback signal value. The hardware benchmark dataset stores the corresponding CAN signal value, which is the standard feedback signal when the hardware unit is successfully initialized. For example, when the fault code is completely cleared, the CAN signal value is 0x01. The obtained feedback signal value is compared with the CAN signal value in the hardware benchmark dataset. If the feedback signal value and the CAN signal value are consistent, both being 0x01, then the hardware unit is determined to have completed initialization. If the feedback signal value is 0x00, while the CAN signal value in the hardware benchmark dataset is 0x01, and the hardware unit's output serial port has no data output, i.e., the output serial port is abnormal, then a first fault type is determined to exist in the hardware unit. The first fault type includes ADAS function status as recovery failure or fault code not being completely cleared. In this case, the anomaly detection unit issues a fault alarm and includes the feedback signal in the first dataset.

[0045] Furthermore, after determining that the hardware unit has completed initialization, the real-time fault diagnosis method also includes: Send a communication link detection command to the hardware unit; Collect the response time of each node in the hardware unit to the communication link detection command; Compare the response time with latency thresholds in the hardware benchmark dataset; If any response time exceeds the delay threshold, a second fault type is determined to exist in the hardware unit. The second fault type includes network interface fault. If the response time of all nodes is greater than the latency threshold, then the hardware unit is determined to have a third type of fault, which includes hardware faults. The response time was included in the first dataset.

[0046] Specifically, after determining that each piece of hardware in the hardware unit has completed initialization, the anomaly detection unit sends a communication link detection command to the hardware unit. This detection command is used to detect the communication status of the cutover point, such as nodes like the host computer, slave computer, real-time machine, and controller.

[0047] The hardware unit contains multiple nodes, such as sensor nodes and controller nodes. When a communication link fails, each node will return a response signal to the anomaly detection unit. The anomaly detection unit collects the response time of each node to the detection command.

[0048] The hardware benchmark dataset stores the latency thresholds for each node. For example, the latency threshold for sensor nodes is 100ms, and the latency threshold for controller nodes is 150ms. The response times of each node are then included in the first dataset. The collected response times are compared with the latency thresholds in the hardware benchmark dataset. If the response time of a sensor node is 120ms, which is greater than its latency threshold of 100ms, while the response times of other nodes are all within their respective threshold ranges, then a second type of fault is determined to exist in the hardware unit, i.e., a single point of failure in the network node. If the response times of all nodes are greater than their respective latency thresholds, such as a sensor node response time of 200ms and a controller node response time of 300ms, then a third type of fault is determined to exist in the hardware unit, i.e., a global network communication anomaly in the hardware unit.

[0049] Furthermore, while the anomaly detection unit returns a response signal and collects the response time of each node to the detection command, a specific CAN message is sent to the real-time machine, and a Rolling counter is added for monitoring. The collected response time is compared with the delay threshold of the hardware benchmark dataset, and the status of the Rolling counter is monitored. If the response time of the sensor node is 120ms, which is greater than the delay threshold of 100ms, and the nodes of other hardware units are normal, and the Rolling counter cycle is normal, then it is determined that there is a network interface fault in the hardware unit. If the response time of all nodes is greater than the threshold, and the Rolling counter stops or jumps, then it is determined that there is a third type of fault in the hardware unit, namely a real-time machine fault causing global network communication abnormality. Among them, the Rolling counter abnormality can directly locate the real-time machine related fault.

[0050] Finally, the response time and Rolling counter status data of each node are incorporated into the first dataset to further improve the accuracy of hardware fault location; the periodic characteristics of the Rolling counter can distinguish between "real-time machine self-message generation failure" and "external link transmission failure".

[0051] On the other hand, after collecting the response times of each node in the hardware unit to the communication link detection command, the real-time fault judgment method also includes: If the vehicle control-speed response mechanism is detected to be faulty, and the sensing link is fault-free and the controller process is running normally, then the network connectivity between the host computer and the real-time machine is checked. If the host computer successfully pings the real-time machine, it is determined that the CAN channel connection between the real-time machine and the controller under test is abnormal, that is, the CAN communication fails. Issue a CAN communication fault alarm and incorporate the vehicle control-speed response status, perception link status, controller process status, and network connectivity detection results into the first dataset.

[0052] In one instance, during the hardware unit communication link detection process, after the anomaly detection unit collects the response time of each node to the communication link detection command, it enters a further fault verification stage. The anomaly detection unit first monitors the status of the vehicle control-speed response mechanism. By comparing the vehicle control signal output by the controller with the actual vehicle speed fed back by the vehicle dynamics model, it finds that the deviation between the two is far beyond the preset threshold, and determines that the "vehicle control-speed response" mechanism has failed. This may mean that there is a problem with the signal transmission between the real-time machine and the controller.

[0053] Next, the anomaly detection unit inspects the sensing link, acquiring data through the sensing result monitoring tool on the lower-level machine to confirm that the sensing link is fault-free. Simultaneously, it monitors the process running status via the controller's serial port, outputting the process running status every 100ms, thus determining that the controller process is running normally and ruling out vehicle speed response failure caused by a crash in the controller's own program.

[0054] To further investigate the cause of the fault, the anomaly detection unit checks the network connectivity between the host computer and the real-time machine by sending an ICMP ping command from the host computer to the real-time machine. If a reply message is received from the real-time machine, it indicates that the network between the host computer and the real-time machine is connected, ruling out the possibility of the real-time machine crashing or the network link being interrupted.

[0055] Furthermore, after collecting the response times of each node in the hardware unit to communication link detection commands, the real-time fault diagnosis method also includes: The network connectivity between the host computer, the slave computer, and the controller under test is tested in pairs, and the communication status is verified by ICMP ping commands between nodes. If a single node cannot be pinged by the other two nodes, but the other two nodes can ping each other, then the node that cannot be pinged is determined to be a network failure node. Issue a single-point communication failure alarm for a network failure node, or automatically trigger the node's restart procedure; The ping status between nodes, the identifier of the failed node, and the processing results are included in the first dataset.

[0056] Specifically, during the hardware unit communication link detection process, after the anomaly detection unit collects the response time of each node, it further performs pairwise network connectivity detection on the three core nodes: the host computer, the slave computer, and the controller under test. The anomaly detection unit controls the three nodes to send ICMP ping commands in sequence: the host computer pings the slave computer and the controller under test, the slave computer pings the host computer and the controller under test, and the controller under test pings the host computer and the slave computer. The response result and response time of each ping command are recorded. If the following conditions are detected: the host computer successfully pings the slave computer, the host computer successfully pings the controller under test, the slave computer successfully pings the host computer, the slave computer fails to ping the controller under test, the controller under test successfully pings the host computer, and the controller under test fails to ping the slave computer, that is, the slave computer cannot be pinged by the host computer and the controller under test, but the host computer and the controller under test can ping each other, then the slave computer is determined to be a network failure node. At this point, the anomaly detection unit issues a single-point communication failure alarm and can automatically trigger the lower-level machine's restart program according to a preset strategy. If the lower-level machine resumes communication with other nodes after restarting, the test process continues. If communication is still not possible after restarting, the alarm state is maintained.

[0057] Furthermore, after performing pairwise network connectivity checks between the host computer, the slave computer, and the controller under test, the real-time fault diagnosis method also includes: If the host computer and the slave computer can successfully ping each other, but both fail to ping the controller under test, then check the sensor input signals, CAN signals and serial port printing status of the controller under test. If the sensor input signal is normal, the CAN signal transmission is stable, and the serial port printout shows that the controller process is running normally, then the vehicle Ethernet converter is determined to have the eighth fault type; the eighth fault type includes vehicle Ethernet converter failure. Issue an Ethernet converter fault alarm and incorporate network connectivity status, sensor and CAN signal detection results, and serial port print information into the first dataset.

[0058] In the network communication testing process of the hardware unit, after the anomaly detection unit completes the pairwise network connectivity testing between the host computer, the slave computer and the controller under test, if a specific anomaly mode occurs, a targeted fault diagnosis mechanism will be activated, which will not be explained further.

[0059] Furthermore, after performing pairwise network connectivity checks between the host computer, the slave computer, and the controller under test, the real-time fault diagnosis method also includes: If pinging between the host computer, the slave computer, and the controller under test fails, but pinging between the host computer and the real-time machine succeeds, then the network switch is determined to have a ninth type of fault; the ninth type of fault includes switch failure. Issue a network switch fault alarm and incorporate the network connectivity status between each node and the communication status between the host computer and the real-time machine into the first dataset.

[0060] For example, in the network communication testing of the hardware unit, after the anomaly detection unit completes the pairwise connectivity testing of the host computer, slave computer, and controller under test, if the following anomalies occur: the host computer times out pinging the slave computer and pinging the controller under test; the slave computer times out pinging the host computer and pinging the controller under test; the controller under test times out pinging the host computer and pinging the slave computer, meaning that none of the three can communicate with each other; at this time, the anomaly detection unit further detects the communication status between the host computer and the real-time machine, controls the host computer to send a ping command to the real-time machine, and successfully responds 10 times in a row, with an average response time of 6ms, which is within the normal range of the hardware benchmark dataset, indicating that the network interface of the host computer and the link connected to the real-time machine are normal. Based on network architecture analysis: the host computer, slave computer, and controller under test are all connected to the same network switch via network cables, while the real-time machine is directly connected to the host computer via a separate network cable. Since communication between any two of the three relies on the switch for forwarding, and the communication between the host computer and the real-time machine does not go through the switch and is normal, the possibility of a faulty network interface of the host computer or a complete network failure can be ruled out. The fault point is determined to be the network switch, i.e., the ninth type of fault.

[0061] Furthermore, real-time detection data of the software unit is acquired, including: Perform fault diagnosis and monitoring on the video stream output by the sensor module in the software unit; It acquires continuous frame data of the video stream in real time and controls the anomaly detection unit to monitor the output status of each frame image; If a single frame image freezes and the duration exceeds the first preset duration, it is determined that there is a fourth type of fault in the video injection link, and a video stream abnormality alarm is triggered; the fourth type of fault includes sensor output frame freezing. Specifically, the anomaly detection unit monitors the video stream output by the sensor module in the software unit for faults. The sensor module is a virtual camera module, and its output video stream is a continuous sequence of image frames, which is used as the perception input for the ADAS algorithm.

[0062] The anomaly detection unit acquires continuous frame data from the video stream and detects the output status of each frame, such as monitoring the frame update frequency and whether the image content has changed.

[0063] For example, if the first preset duration is 2 seconds, and a frame of an image is detected to remain unchanged within 2 seconds, indicating that a single frame of an image is frozen, and the duration of the single frame of an image being frozen exceeds the first preset duration, then it is determined that there is a sensor output frame freezing situation in the video injection link. At this time, the anomaly detection unit triggers a video stream anomaly alarm.

[0064] After monitoring and diagnosing faults in the video stream output by the sensor module in the software unit, the real-time fault judgment method also includes: Obtain the currently loaded test case ID of the software unit, and read the preset scenario parameters corresponding to the test case ID; Compare the run use case IDs with the planned use case IDs in the software baseline dataset; If the running use case ID is inconsistent with the planned use case ID, it is determined that there is a fifth fault type in the software unit, the difference information between the actual use case ID and the planned use case ID is recorded, and a fault alarm is issued; the fifth fault type includes use case loading anomaly. If the running use case ID matches the planned use case ID, then the check for running use case ID and planned use case ID is considered to have passed; The comparison results and differences were incorporated into the second dataset.

[0065] Specifically, after monitoring the video stream output by the sensor module in the software unit for fault diagnosis, the anomaly detection unit obtains the currently loaded running use case of the software unit through data interaction, such as the currently loaded use case ID being a rural road scene; at the same time, it reads the preset scene parameters corresponding to the running use case ID, including the number of vehicles in the scene, road type, etc.; it retrieves the planned use case ID from the software benchmark dataset, for example, "advanced mathematics road scene", and compares the running use case ID with the planned use case ID; if the running use case ID "rural road scene" is inconsistent with the planned use case ID "highway scene", it determines that the software unit has a fifth type of fault, namely scene loading error, records the difference information between the actual use case ID and the planned use case ID, issues a fault alarm, and incorporates the comparison results and difference information into the second dataset.

[0066] Furthermore, after comparing the run use case ID with the planned use case ID in the software benchmark dataset, the real-time fault diagnosis method also includes: If the running use case ID is consistent with the planned use case ID, and the preset scene parameters match the actual scene characteristics of the video stream, then the vehicle control signal output by the software unit and the actual response speed fed back by the vehicle dynamics model are obtained. The theoretical vehicle speed corresponding to the vehicle control signal is compared with the actual response speed in real time. Calculate the deviation between the actual response speed and the theoretical speed, and statistically analyze the average deviation over a continuous preset time period; If the average deviation exceeds the preset deviation threshold, the software unit is determined to have a sixth type of fault, and the deviation parameters and the timestamp of the abnormality are recorded. The sixth type of fault includes an abnormality in the matching between the vehicle control signal and the vehicle speed response. The real-time comparison results, deviation parameters, and fault types are incorporated into the second dataset.

[0067] Specifically, after comparing the running use case ID with the planned use case ID in the software benchmark dataset, if the running use case ID is consistent with the planned use case ID, and the preset scene parameters match the actual scene features of the video stream, then the anomaly detection unit obtains the vehicle control signals output by the software unit, such as acceleration signals, brake lights, and the actual response speed fed back by the vehicle dynamics model, such as the acceleration signal indicating that the current throttle opening is 30%, and the actual response speed indicating that the current actual vehicle speed is 40km / h.

[0068] Based on the preset mapping relationship obtained by querying the vehicle control signal, the corresponding theoretical vehicle speed is obtained; the theoretical vehicle speed is compared with the actual response vehicle speed; for example, the theoretical vehicle speed corresponding to the acceleration signal feedback throttle opening of 30% is 50km / h, while the actual response vehicle speed is 40km / h; the deviation between the actual response vehicle speed and the theoretical vehicle speed is calculated to be 10km / h, and the deviation value within 5 consecutive seconds is counted to be 8km / h.

[0069] If the preset deviation threshold is 5km / h, and the average deviation is 8km / h, which exceeds the preset deviation threshold, then the software unit is determined to have a sixth type of fault, namely, an abnormal match between the vehicle control signal and the vehicle speed response, or "vehicle control-vehicle speed response mismatch"; at the same time, the deviation parameters and the timestamp of the abnormality are recorded, and the real-time comparison results, deviation parameters and fault types are included in the second dataset.

[0070] Furthermore, real-time fault diagnosis methods also include: After the test bench is started, the control anomaly detection unit performs real-time synchronous detection on the hardware and software units in the test bench to obtain the detection data of the test bench during operation. The fault points of the hardware and software units are determined based on the test data.

[0071] Specifically, after the test bench is started, the anomaly detection unit performs real-time synchronous detection on the hardware and software units in the test bench according to the set monitoring frequency; for example, it collects data such as the communication link status of the hardware unit and the video stream output and test case running status of the software unit every 0.5 seconds to form the detection data of the test bench in operation.

[0072] Based on these test data, the fault points of the hardware and software units are comprehensively determined. If a large communication delay is detected in a certain node of the hardware unit, and the video stream output of the software unit is stuttering, it is determined that the fault of the hardware node may have caused the abnormality of the software unit, i.e., "hardware-software interaction abnormality".

[0073] Furthermore, the control of the anomaly detection unit to perform real-time detection of software units in the test bench also includes: Monitor the perception results deployed on the lower-level machine or detect the status of the output messages of the visualization tool in real time; If the output message is not updated within the second preset time period, the real-time signal of the vehicle control and speed response on the CAN bus is obtained. The real-time signal of vehicle control-speed response is compared with the corresponding standard signal in the hardware benchmark dataset; If the comparison results show that the vehicle control-speed response mechanism is normal, it is determined that the perception result or visualization tool itself has a seventh type of fault, and a tool fault alarm is issued; the seventh type of fault includes perception result monitoring or visualization tool crash. The output messages and the comparison results of vehicle control and speed response signals are incorporated into the second dataset.

[0074] For example, during real-time detection of software units, the anomaly detection unit includes the perception result monitoring / visualization tool deployed on the lower-level machine in its detection scope. This tool is used to display the perception results of the ADAS algorithm in real time. When working normally, it outputs a message containing perception data every 100ms. These messages are part of the second dataset of the software unit.

[0075] The anomaly detection unit monitors the status of the tool's output messages in real time, with a second preset duration of 300ms. If the tool's output messages are not updated within 300ms, a message freeze occurs, triggering a further verification process.

[0076] The anomaly detection unit acquires real-time vehicle control-speed response signals via the CAN bus interface, including acceleration or braking signals output by the controller and the actual vehicle speed fed back by the vehicle dynamics model. Simultaneously, it retrieves corresponding standard signals from the hardware benchmark dataset: for example, with a throttle opening of 20%, the theoretical vehicle speed should be 32 km / h, and the allowable deviation threshold is ±3 km / h. The real-time vehicle control-speed response signal is compared with the standard signal in the hardware benchmark dataset. The deviation between the actual vehicle speed and the theoretical vehicle speed is calculated to be 2 km / h. This deviation is within the preset threshold range, indicating that the vehicle control-speed response mechanism is normal and the control link is in a closed loop state, thus ruling out message freezing caused by ADAS algorithm failure or hardware actuator malfunction.

[0077] Furthermore, acquiring real-time detection data for software units also includes: Real-time monitoring of the output status of serial port tools; If the output of the serial port tool is not updated within the third preset time period, then obtain the real-time signal of vehicle control-vehicle speed response; The real-time signal of vehicle control-speed response is compared with the corresponding standard signal in the hardware benchmark dataset; If the comparison results show that the vehicle control-speed response mechanism is normal, then the serial port tool is determined to have the tenth fault type, and a serial port tool fault alarm is issued; the tenth fault type includes serial port tool crash; the comparison results show that the vehicle control-speed response mechanism is normal, that is, the deviation is within the preset range; The serial port tool output status, the comparison results of vehicle control-vehicle speed response signals, and fault judgment information are included in the second dataset.

[0078] In real-time testing of the software unit, the anomaly detection unit monitors the output status of the serial port tool, which receives real-time operation logs sent by the controller under test. For example, under normal circumstances, it outputs a message containing the controller process status every 500ms; this information is part of the second dataset. The anomaly detection unit sets a third preset duration of 1500ms. If the serial port tool's output is not updated within 1500ms, an output freeze occurs, triggering the verification process. The anomaly detection unit acquires the real-time vehicle control-speed response signal: the acceleration signal output by the controller and the actual vehicle speed fed back by the vehicle dynamics model. It compares the real-time signal with the standard signal and calculates the deviation between the actual and theoretical vehicle speeds. If the deviation is within a preset threshold, it indicates that the vehicle control-speed response mechanism is normal, and the controller is in normal working condition. Based on the above tests, the serial port tool output is frozen, but the vehicle control and speed response is normal, indicating that the serial port tool has a tenth type of fault.

[0079] Furthermore, this invention also provides a real-time fault diagnosis system based on an ADAS hardware-in-the-loop simulation platform, capable of implementing the real-time fault diagnosis method of any of the above examples. The fault diagnosis system includes: an anomaly detection unit, a host computer, a slave computer, a real-time machine, and a controller; the anomaly detection unit is used to compare real-time detection data with preset running data in real time and to troubleshoot the test bench based on fault alarms; the host computer is used to generate test plans, configure software benchmark datasets and hardware benchmark datasets, and issue running test case instructions to the real-time machine; the slave computer is used to drive the hardware actuators of the test bench and collect the initialization status signals and communication link status data of the hardware units; the real-time machine is used to run vehicle dynamics models and virtual scene simulations, generate sensor simulation data, and synchronously coordinate the data interaction between the host computer and the controller; the controller is used to receive sensor simulation data output by the real-time machine, execute ADAS algorithms and output vehicle control signals, and simultaneously send video stream fault diagnosis signals and running test case IDs through the vehicle Ethernet; the hardware unit consists of a host computer, a slave computer, a real-time machine, and a controller.

[0080] While the present invention has been disclosed above, it is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of the invention; therefore, the scope of protection of the present invention should be determined by the scope defined in the claims.

Claims

1. A real-time fault judgment method based on an ADAS hardware-in-the-loop simulation platform, characterized in that, The method comprises the following steps: connecting an anomaly detection unit to a test bench; controlling the anomaly detection unit to perform real-time detection on the test bench according to a preset time sequence to obtain real-time detection data when the test bench is started; comparing the real-time detection data with preset operation data in real time; if the real-time detection data is different from the preset operation data, determining that there is a fault point in the test bench and issuing a fault alarm; troubleshooting the test bench according to the fault alarm.

2. The real-time failure determination method according to claim 1, characterized by, The preset operation data comprises a hardware reference data set; the controlling the anomaly detection unit to perform real-time detection on the test bench according to a preset time sequence to obtain real-time detection data comprises the following steps: controlling the anomaly detection unit to perform real-time detection on a hardware unit in the test bench to obtain a first data set; comparing the first data set with the hardware reference data set; if the first data set matches the hardware reference data set, controlling the anomaly detection unit to perform real-time detection on a software unit in the test bench; if the first data set does not match the hardware reference data set, controlling the anomaly detection unit to screen the first data set and locate a data difference point; troubleshooting the test bench according to the data difference point.

3. The real-time failure determination method according to claim 2, characterized in that, The preset operation data further comprises a software reference data set; and the controlling the anomaly detection unit to perform real-time detection on the software unit in the test bench comprises the following steps: obtaining real-time detection data of the software unit, denoted as a second data set; comparing the second data set with the software reference data set according to a preset rule; if the second data set is different from the software reference data set, controlling the anomaly detection unit to screen the second data set, locating the data difference point, and issuing the fault alarm; troubleshooting the test bench according to the data difference point.

4. The real-time failure determination method according to claim 2, characterized by, The controlling the anomaly detection unit to perform real-time detection on the hardware unit in the test bench to obtain a first data set comprises the following steps: sending an initialization instruction to the hardware unit; performing real-time detection on an initialization state of the hardware unit to obtain a feedback signal value; comparing the feedback signal value with a CAN signal value in the hardware reference data set; if the feedback signal value is consistent with the CAN signal value, determining that the hardware unit is initialized; if the feedback signal value is inconsistent with the CAN signal value and an output serial port of the hardware unit is abnormal, determining that there is a first fault type in the hardware unit and issuing the fault alarm; the first fault type comprises a failure of ADAS function state bit recovery or a failure of fault code complete clearing; wherein the feedback signal value is included in the first data set.

5. The real-time failure determination method according to claim 4, characterized by, After the determining that the hardware unit is initialized, the real-time fault judgment method further comprises the following steps: sending a communication link detection instruction to the hardware unit; collecting response times of each node in the hardware unit to the communication link detection instruction; comparing the response time with a delay threshold in the hardware benchmark dataset; if any of the response times is greater than the delay threshold, determining that a second fault type exists in the hardware unit, the second fault type including a network interface fault; if all of the response times are greater than the delay threshold, determining that a third fault type exists in the hardware unit, the third fault type including a hardware fault; wherein the response time is included in the first dataset.

6. The real-time failure determination method according to claim 3, characterized by, The real-time fault judgment method further comprises: performing fault diagnosis monitoring on a video stream output by a sensor module in the software unit; real-time acquisition of continuous frame data of the video stream, and control of the anomaly detection unit to monitor the output state of each frame of image; if a single frame of image is frozen and the duration exceeds a first preset time length, determining that a fourth fault type exists in the video injection link, and triggering the video stream anomaly alarm; the fourth fault type includes sensor output frame freezing.

7. The real-time failure determination method according to claim 6, characterized by, After the fault diagnosis monitoring on the video stream output by the sensor module in the software unit, the real-time fault judgment method further comprises: acquiring a running use case ID currently loaded by the software unit, and reading preset scene parameters corresponding to the running use case ID; comparing the running use case ID with a planned use case ID in the software benchmark dataset; if the running use case ID is inconsistent with the planned use case ID, determining that a fifth fault type exists in the software unit, recording difference information between the actual use case ID and the planned use case ID, and issuing the fault alarm; the fifth fault type includes use case loading anomaly; the comparison result and the difference information are included in the second dataset.

8. The real-time failure determination method according to claim 7, characterized by, After the comparison between the running use case ID and the planned use case ID in the software benchmark dataset, the real-time fault judgment method further comprises: if the running use case ID is consistent with the planned use case ID, and the preset scene parameters and the actual scene feature of the video stream are matched, acquiring a vehicle control signal output by the software unit and an actual response vehicle speed fed back by a vehicle dynamics model; real-time comparison between a theoretical vehicle speed corresponding to the vehicle control signal and the actual response vehicle speed; calculating a deviation value of the actual response vehicle speed and the theoretical vehicle speed, and counting a deviation average value within a continuous preset time length; if the deviation average value exceeds a preset deviation threshold, determining that a sixth fault type exists in the software unit, recording deviation parameters and an abnormal occurrence timestamp; the sixth fault type includes matching anomaly between the vehicle control signal and the vehicle speed response; the real-time comparison result, the deviation parameters and the fault type are included in the second dataset.

9. The real-time failure determination method of claim 1, wherein, The real-time fault judgment method further comprises: after the test bench is started, controlling the anomaly detection unit to perform real-time synchronous detection on the hardware unit and the software unit in the test bench, to acquire detection data of the test bench in operation; determining fault points of the hardware unit and the software unit according to the detection data.

10. A real-time fault judgment system based on an ADAS hardware-in-the-loop simulation platform, characterized in that, The real-time fault judgment method as claimed in any one of claims 1 to 9 can be implemented, and the fault judgment system comprises: an abnormality detection unit, configured to compare real-time detection data with preset operation data in real time and troubleshoot the test bench according to the fault alarm; a host computer, configured to generate a test plan, configure a software benchmark data set and a hardware benchmark data set, and issue an operation case instruction to a real-time machine; a lower computer, configured to drive a hardware execution mechanism of the test bench and collect an initialization state signal and communication link state data of the hardware unit; the real-time machine, configured to run a vehicle dynamics model and a virtual scene simulation, generate sensor simulation data, and synchronize and coordinate data interaction between the host computer and the controller; the controller, configured to receive the sensor simulation data output by the real-time machine, execute an ADAS algorithm and output a control vehicle signal, and send a video stream fault diagnosis signal and an operation case ID through a vehicle-mounted Ethernet; the hardware unit composed of the host computer, the lower computer, the real-time machine and the controller.

Images