Diagnostic process evaluation method and system for intelligent networked automobile simulation fault

Abstract

The invention discloses a diagnosis process evaluation method and system for an intelligent networked automobile simulation fault, and the method comprises the steps: enabling a fault control box to be connected between an original automobile wire harness and an automobile function module in a lossless manner, building a switchable signal path, and avoiding the physical damage to an original automobile circuit; a teacher end instruction is responded to control relay state switching, and remote, rapid and reversible simulation of faults is achieved; fault state information is sent to the vehicle-mounted computing platform in real time and is visually displayed, and trainees are guided to carry out standard detection; after diagnosis results are compared, a recovery instruction is automatically triggered, and a'setting-diagnosis-verification-reset 'closed-loop process is formed; meanwhile, diagnosis quality indexes and personal ability portraits are generated based on operation behaviors and result data, and automation and individuation of teaching evaluation are achieved. According to the method, the practical training safety, the teaching consistency and the evaluation objectivity are improved, and the problems of vehicle damage, uncontrollable process and feedback lag in a traditional mode are effectively solved.

Description

Technical Field

[0001] This invention belongs to the field of automotive fault diagnosis technology, specifically relating to a diagnostic process evaluation method and system for simulated faults in intelligent connected vehicles. Background Technology

[0002] In the teaching of intelligent connected vehicle repair, traditional practical training methods typically simulate faults by manually disconnecting and reconnecting wiring harnesses and setting short circuits or open circuits. These methods require physical intervention in the vehicle, which can easily cause secondary damage such as wiring harness wear and loose terminals. Furthermore, each change of fault type requires manual operation, resulting in long preparation times and poor repeatability. Instructors struggle to standardize assessment criteria, and students cannot receive real-time feedback, leading to low teaching efficiency and insufficient training in the standardized procedures of fault diagnosis.

[0003] Existing technical solutions rely on directly modifying the original vehicle wiring or using simple switch boxes to control on / off states. They lack status feedback mechanisms and process recording capabilities, making it impossible to achieve reversibility of fault settings and quantitative evaluation of the diagnostic process. The resulting technical problem is: how to achieve rapid and reversible fault simulation without damaging the original vehicle wiring harness, and simultaneously complete closed-loop evaluation and automatic recovery of the trainee's diagnostic process. Summary of the Invention

[0004] The purpose of this invention is to provide a diagnostic process evaluation method and system for simulated faults in intelligent connected vehicles, which improves the safety of practical training, the consistency of teaching and the objectivity of evaluation, and effectively solves the problems of vehicle damage, uncontrollable process and delayed feedback in traditional methods.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a method for evaluating the diagnostic process of simulated faults in intelligent connected vehicles, comprising: A switchable signal path is established by connecting the original vehicle wiring harness and the vehicle function module in a non-destructive manner through the fault control box. In response to the fault setting command issued by the teacher, the state switching of the relay in the fault control box is controlled to simulate the target fault; The fault status information is sent to the vehicle computing platform, and the scope of the fault impact is visualized on the vehicle screen or teacher terminal. Students perform detection operations according to the visual prompts and submit the diagnostic results. The diagnostic results submitted by the trainees are compared with the preset faults. If they match, the diagnosis is considered correct. When the diagnosis is correct, the fault recovery command is automatically triggered, and the relay is controlled to return to its original state. Based on the operational behavior data and outcome data of trainees during the diagnosis process, a diagnosis quality index and an individual capability profile are generated.

[0006] Preferably, establishing a switchable signal path includes: Connect the original vehicle wiring harness to the input terminal block of the fault control box via an industrial-grade anti-return pin connector, and reconnect the output terminal block to the input terminal of the vehicle function module. Inside the fault control box, a double-pole double-throw electromagnetic relay is configured for each signal. The common terminal is connected to the original vehicle ECU output, and the normally closed terminal is connected to the target sensor or actuator input. The relay is normally closed and conducting by default, and the coil is controlled by the MCU through an optocoupler-isolated MOSFET drive circuit; Each channel is clearly labeled with its wire number and function name, and the channels are electrically isolated to avoid signal crosstalk.

[0007] Preferably, before the relay state switching, the fault control box performs system initialization and physical connection confirmation, specifically including: After power-on, scan the current physical state of all relays and compare it with the last power-off state stored in the EEPROM; If there are inconsistencies, an exception log will be recorded; if all are consistent, the system will enter standby mode. The system readiness message is broadcast via the CAN bus. The data field includes the status code, the unique serial number of the control box, the total number of relays, and the CRC16 check value. After receiving the data, the vehicle-mounted computing platform displays on the human-machine interface that the control box has been connected.

[0008] Preferably, the response to the fault setting command issued by the teacher includes: Teachers select a fault setting mode on an operating terminal, which includes Windows host computer software, a web server interface, or a handheld group control device. Based on the selection result, activate the corresponding command channel: the host computer enables UDP port 5001 to listen, the web server establishes a WebSocket long connection, and the group control device starts the 433MHz radio frequency receiver. Teachers are required to enter administrator credentials for identity verification. Credentials can be dynamic passwords, IC cards, or fingerprint recognition. After successful verification, the system loads the vehicle system structure diagram of the current training vehicle. The vehicle system structure diagram is rendered and displayed on the operation terminal interface in layers according to the perception layer, decision layer, execution layer and communication layer, and the fault point selection function area is activated at the same time.

[0009] Preferably, after the vehicle system structure diagram is loaded and displayed stably, fault point selection and mapping are performed, specifically including: Teachers can click on a functional module in the vehicle system structure diagram using a touch screen or mouse, and the system will highlight the module and its associated signal path. After clicking "Confirm," the system maps it to an internally unique fault code. The mapping relationship is queried from the local SQLite database, and the fields include fault name, system, relay number, default status, and recovery method; The system synchronously calculates and displays the teaching weight value of the fault point to help teachers screen high-value fault points.

[0010] Preferably, the generation and transmission of fault setting instructions include: Generate control command data packets based on the selected fault codes; If using host computer or web server mode, the CAN frame is encapsulated with identifier 0x7E8, and the 0th byte is 0xA1 to indicate that a fault is set. If a group control device is used, the wireless frame is encapsulated with a preamble of 0xAA55 and an additional CRC8 checksum is added. The command is sent to the fault control box via the USB-CAN adapter or wireless module, triggering the fault control box to enter the command receiving and parsing state.

[0011] Preferably, the fault control box enters command reception and parsing, including: The MCU continuously monitors the CAN bus and the wireless RF interface, and parses the instruction content after receiving a 0x7E8 frame or a 0xAA55 frame. Query the internal relay mapping table to obtain the corresponding relay number and target status; Check the current state. If it is inconsistent with the target, drive the corresponding MOSFET to energize or de-energize the coil to complete the switching. The MCU generates an internal event flag indicating that the relay state switching is complete and controls the buzzer to sound a short beep to indicate that the action has been executed.

[0012] Preferably, after the internal event flag for the relay state switching completion is set, confirmation and feedback after the relay state switching are performed, specifically including: The MCU waits for 100 milliseconds to stabilize before reading the contact feedback signal again to confirm that the physical state has stabilized. If the state switch fails, the error code is recorded and the error message is sent via a CAN message with identifier 0x7E9, and the buzzer sounds a continuous alarm. If the switch is successful, a status update message with identifier 0x7E1 is generated. The data field contains status code 0xBB, relay number, current status, fault code and timestamp. The message is broadcast via the CAN bus and can be received by both the vehicle computing platform and the host computer.

[0013] Preferably, after the status update message is successfully generated and broadcast, the vehicle computing platform receives the message and completes the visualization display of the fault impact range, and generates a diagnostic quality index based on the diagnostic operation behavior data and result data of the trainee under the visualization prompts.

[0014] On the other hand, this invention proposes a diagnostic process evaluation system for simulated faults in intelligent connected vehicles, comprising: The fault control box connects to the original vehicle wiring harness and vehicle function module via an industrial-grade anti-return pin connector. It is equipped with a double-pole double-throw electromagnetic relay array. The common terminal of the relay is connected to the output of the original vehicle ECU, and the normally closed terminal is connected to the input of the target sensor or actuator. The coil is controlled by the MCU through the MOSFET drive circuit. The multi-channel communication unit integrates a CAN 2.0B bus interface, a 433MHz wireless RF transceiver module, and a USB / RS485 debugging interface. The three are hardware isolated and the instruction priority is set by the MCU arbitration logic. The self-test and status feedback module is used to scan the physical status of the relays after power-on and compare it with historical records. After completing the self-test, it broadcasts a system ready message containing the serial number and the total number of relays. The instruction parsing and execution module is used to receive and verify fault setting instructions from the host computer, web server or group control device, parse out the fault code, query the mapping table to determine the target relay number and status, and drive the corresponding MOSFET to complete the coil on / off control. The status confirmation and message generation module is used to read the contact feedback signal after the relay switching to confirm that the status is stable, generate a CAN message containing status code, relay number, current status, fault code and time stamp and broadcast it through the CAN bus; The vehicle-mounted computing platform is used to listen to status update messages on the CAN bus, parse them, call the graphics engine to highlight the affected system modules on the vehicle screen, and present a multi-vehicle fault status matrix view on the teacher's interface. The diagnostic guidance module provides descriptions of typical symptoms, possible functional impacts, recommended testing tools, and standard troubleshooting flowcharts. The content is derived from an editable fault knowledge base. The diagnostic result comparison and recovery trigger module is used to compare the fault codes submitted by the students with the preset codes of the teachers. If they match, a fault clearing command is automatically generated and returned to the fault control box via the original path. The automatic fault recovery module responds to the clear command to drive the relay back to the normally closed state. After confirmation, it broadcasts a message that the fault has been recovered, so that the on-board computing platform clears the highlighted prompts and updates the teacher's interface. The evaluation and profile generation module extracts data from the entire diagnostic process of trainees, calculates the diagnostic quality index by combining path deviation and step coverage, generates personal ability radar charts, trend curves and improvement roadmaps based on multiple training records, and outputs PDF ability reports to trainee accounts and teacher backends.

[0015] Technical effects and advantages of the present invention: The diagnostic process evaluation method and system for simulated faults in intelligent connected vehicles proposed in this invention have the following advantages compared with the prior art: This invention uses a fault control box to connect non-destructively between the original vehicle wiring harness and vehicle functional modules, establishing a switchable signal path and avoiding physical damage to the original vehicle circuitry. It responds to teacher commands to control relay state switching, enabling remote, rapid, and reversible fault simulation. Fault status information is sent to the onboard computing platform in real time and displayed visually, guiding trainees in standardized testing. After comparing diagnostic results, a recovery command is automatically triggered, forming a closed-loop process of "setting—diagnosis—verification—reset." Simultaneously, based on operational behavior and result data, a diagnostic quality index and individual competency profile are generated, achieving automated and personalized teaching evaluation. This method improves training safety, teaching consistency, and evaluation objectivity, effectively solving the problems of vehicle damage, uncontrollable processes, and delayed feedback in traditional methods. Attached Figure Description

[0016] Figure 1 This is a flowchart of the diagnostic process evaluation method for simulated faults in intelligent connected vehicles according to the present invention; Figure 2 This is a block diagram of the diagnostic process evaluation system for simulated faults in intelligent connected vehicles according to the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The specific embodiments described herein are merely used to explain the present invention and are not intended to limit the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] This invention provides, for example Figure 1 The method for evaluating the diagnostic process of a simulated fault in an intelligent connected vehicle, as shown, includes the following steps: A fault control box is used to connect the original vehicle wiring harness and the vehicle's functional modules in a non-destructive manner, establishing a switchable signal path. Specifically, this involves connecting the original vehicle wiring harness to the input terminal block of the fault control box via industrial-grade anti-reverse pin connectors, and reconnecting the output terminal block to the input terminal of the vehicle's functional modules. Inside the fault control box, a double-pole double-throw electromagnetic relay is configured for each signal path. The common terminal is connected to the original vehicle ECU output, and the normally closed terminal is connected to the target sensor or actuator input. The relays are normally closed and conducting by default, and the coils are controlled by the MCU through an optocoupler-isolated MOSFET drive circuit. Each channel is clearly labeled with its wire number and function name, and there is electrical isolation between channels to avoid signal crosstalk.

[0019] It enables seamless access to the original vehicle wiring harness and reliable switching of signal paths, avoiding terminal wear and poor contact caused by repeated plugging and unplugging; it ensures that the original vehicle circuit maintains a complete path in the inactive state during fault simulation, maintaining normal basic vehicle communication and power supply; through electrical isolation and independent channel design, it prevents mutual interference between multiple signals, ensuring the accuracy of fault injection and the stability of system operation; it provides the hardware foundation for subsequent remote control, status feedback and automatic recovery, supporting safe, reversible and repeatable operation in the teaching process.

[0020] In response to the fault setting command issued by the teacher, the system controls the state switching of the relays in the fault control box to simulate the target fault. Specifically, this includes: scanning the current physical state of all relays after power-on and comparing it with the last power-off state stored in the EEPROM; if there is a discrepancy, an exception log is recorded; if all are consistent, the system enters a standby state; a system ready message is broadcast via the CAN bus, with the data field containing the status code, the unique serial number of the control box, the total number of relays, and the CRC16 check value; after receiving the message, the vehicle-mounted computing platform displays "Control Box Connected" on the human-machine interface.

[0021] Ensure the fault control box is in a known and consistent initial state before each training session to prevent residual faults caused by relay malfunctions or power outages; achieve self-testing traceability through state comparison and anomaly recording to improve system reliability; utilize unique serial numbers and channel information broadcasting to enable the vehicle-mounted computing platform to accurately identify access devices and establish communication associations, providing a foundation for device management and status synchronization in multi-vehicle, multi-terminal teaching scenarios, and ensuring the accuracy and uniqueness of command issuance and feedback reception.

[0022] Furthermore, responding to fault setting instructions issued by the teacher includes: the teacher selecting a fault setting mode on the operating terminal, which may include Windows host computer software, a web server interface, or a handheld group control device; activating the corresponding instruction channel based on the selection result: the host computer enables UDP port 5001 for listening, the web server establishes a WebSocket long connection, and the group control device starts a 433MHz radio frequency receiver; requiring the teacher to enter administrator credentials for identity verification, with credentials including dynamic passwords, IC cards, or fingerprint recognition; after successful verification, the system loads the vehicle system structure diagram of the current training vehicle, which is rendered and displayed on the operating terminal interface in layers according to the perception layer, decision layer, execution layer, and communication layer, while simultaneously activating the fault point selection function area.

[0023] It enables unified command access and operation permission control in multi-terminal environments, ensuring the security and controllability of fault setting operations; it prevents unauthorized personnel from misoperating through an identity verification mechanism, ensuring the standardization of the training process; the layered rendering of the vehicle system structure diagram provides an intuitive understanding of the system topology, helping teachers accurately locate the target system and fault points, improving the efficiency of fault setting and the relevance of teaching.

[0024] In addition, after the vehicle system structure diagram is loaded and displayed stably, fault point selection and mapping are performed. Specifically, the teacher clicks on a functional module in the vehicle system structure diagram via touch screen or mouse, and the system highlights the module and its associated signal path. After clicking "confirm," the system maps it to an internal unique fault code. The mapping relationship is queried from the local SQLite database, and the fields include fault name, system, relay number, default status, and recovery method. The system simultaneously calculates and displays the teaching weight value of the fault point to help teachers select high-value fault points.

[0025] It achieves precise mapping between fault points and hardware execution units, ensuring a one-to-one correspondence between software operations and physical relay actions; it enhances the intuitiveness of human-computer interaction by highlighting functional modules and signal paths, reducing the risk of misselection; the local database supports fast querying and stable mapping, ensuring real-time system response; and the synchronous presentation of teaching weight values ​​provides teachers with quantitative decision-making basis, improving the teaching relevance and training value of fault selection.

[0026] For example, the generation and transmission of fault setting instructions include: generating a control instruction data packet based on the selected fault code; if using a host computer or web server mode, encapsulating it as a CAN frame with identifier 0x7E8, where the 0th byte is 0xA1 to indicate fault setting; if using a group control device, encapsulating it as a wireless frame with preamble 0xAA55, with an additional CRC8 checksum; the instruction is transmitted to the fault control box via a USB-CAN adapter or wireless module, triggering the fault control box to enter the instruction receiving and parsing state.

[0027] This process ensures the accurate generation and efficient transmission of fault setting commands, enabling precise control of the fault control box. Specific identifiers and bytes are used to distinguish command formats in different modes, enhancing the accuracy of command recognition and system compatibility. Reliable encapsulation protocols and verification mechanisms guarantee the integrity and security of data transmission, reducing the risk of misoperation. Successful command transmission and reception can instantly trigger fault simulation, supporting real-time fault diagnosis and handling training, and improving the realism and practicality of the teaching and testing environment.

[0028] The fault control box enters the instruction reception and parsing process, which includes: the MCU continuously monitors the CAN bus and the wireless radio frequency interface, and after receiving a 0x7E8 frame or a 0xAA55 frame, it parses the instruction content; it queries the internal relay mapping table to obtain the corresponding relay number and target status; it checks the current status, and if it is inconsistent with the target, it drives the corresponding MOSFET to energize or de-energize the coil to complete the switching; the MCU generates an internal event flag indicating that the relay status switching is complete, and controls the buzzer to sound a short beep to indicate that the action has been executed.

[0029] Specifically, after the internal event flag is set upon completion of the relay state switch, confirmation and feedback are performed. This includes: the MCU waiting for 100 milliseconds to stabilize before rereading the contact feedback signal to confirm that the physical state has stabilized; if the state switch is unsuccessful, an error code is recorded and an error message is sent via a CAN message with identifier 0x7E9, and a buzzer sounds a continuous alarm; if the switch is successful, a state update message with identifier 0x7E1 is generated, and the data field includes the status code 0xBB, relay number, current status, fault code, and timestamp; the message is broadcast via the CAN bus and can be received by both the vehicle computing platform and the host computer.

[0030] In addition, after the status update message is successfully generated and broadcast, the on-board computing platform receives the message and completes the visualization of the fault impact range. Based on the diagnostic operation behavior data and result data of the trainee under the visualization prompts, a diagnostic quality index is generated.

[0031] The fault status information is sent to the vehicle computing platform, and the scope of the fault impact is visualized on the vehicle screen or teacher terminal. Students perform detection operations according to the visual prompts and submit diagnostic results. The diagnostic results submitted by students are compared with preset faults. If they match, the diagnosis is considered correct. When the diagnosis is correct, the fault recovery command is automatically triggered to control the relay to return to its original state. Based on the operation behavior data and result data of students in the diagnosis process, a diagnostic quality index and personal ability profile are generated.

[0032] Real-time synchronization and multi-terminal visualization of fault status enable trainees to intuitively identify affected systems and conduct targeted tests, improving diagnostic efficiency and path standardization. Automatic comparison of diagnostic results enables immediate evaluation, eliminating human bias. Correct diagnosis automatically triggers recovery commands, ensuring reversible fault states and guaranteeing the continuity of subsequent training and the integrity of vehicle functions. A diagnostic quality index and individual competency profile generated based on operational behavior and result data provide quantifiable learning effectiveness assessments, supporting refined teaching feedback and personalized training content, forming a closed-loop teaching mechanism of "diagnosis—evaluation—improvement."

[0033] On the other hand, this invention proposes a diagnostic process evaluation system for simulated faults in intelligent connected vehicles, such as... Figure 2 As shown, it includes: The fault control box connects to the original vehicle wiring harness and vehicle function module via an industrial-grade anti-return pin connector. It is equipped with a double-pole double-throw electromagnetic relay array. The common terminal of the relay is connected to the output of the original vehicle ECU, and the normally closed terminal is connected to the input of the target sensor or actuator. The coil is controlled by the MCU through the MOSFET drive circuit. The multi-channel communication unit integrates a CAN 2.0B bus interface, a 433MHz wireless RF transceiver module, and a USB / RS485 debugging interface. The three are hardware isolated and the instruction priority is set by the MCU arbitration logic. The self-test and status feedback module is used to scan the physical status of the relays after power-on and compare it with historical records. After completing the self-test, it broadcasts a system ready message containing the serial number and the total number of relays. The instruction parsing and execution module is used to receive and verify fault setting instructions from the host computer, web server or group control device, parse out the fault code, query the mapping table to determine the target relay number and status, and drive the corresponding MOSFET to complete the coil on / off control. The status confirmation and message generation module is used to read the contact feedback signal after the relay switching to confirm that the status is stable, generate a CAN message containing status code, relay number, current status, fault code and time stamp and broadcast it through the CAN bus; The vehicle-mounted computing platform is used to listen to status update messages on the CAN bus, parse them, call the graphics engine to highlight the affected system modules on the vehicle screen, and present a multi-vehicle fault status matrix view on the teacher's interface. The diagnostic guidance module provides descriptions of typical symptoms, possible functional impacts, recommended testing tools, and standard troubleshooting flowcharts. The content is derived from an editable fault knowledge base. The diagnostic result comparison and recovery trigger module is used to compare the fault codes submitted by the students with the preset codes of the teachers. If they match, a fault clearing command is automatically generated and returned to the fault control box via the original path. The automatic fault recovery module responds to the clear command to drive the relay back to the normally closed state. After confirmation, it broadcasts a message that the fault has been recovered, so that the on-board computing platform clears the highlighted prompts and updates the teacher's interface. The evaluation and profile generation module extracts data from the entire diagnostic process of trainees, calculates the diagnostic quality index by combining path deviation and step coverage, generates personal ability radar charts, trend curves and improvement roadmaps based on multiple training records, and outputs PDF ability reports to trainee accounts and teacher backends.

[0034] This system is designed for teaching and training scenarios in intelligent connected vehicles, constructing a highly structured, process-oriented, traceable, and reusable fault simulation and diagnostic training solution. The system does not rely on any destructive methods, does not alter the original vehicle structure, and does not replace original vehicle parts. All fault injection and recovery are achieved through electrical signal routing control, ensuring that the vehicle remains in factory condition after multiple training sessions, significantly reducing teaching losses and maintenance costs.

[0035] In addition, the modules in the system are also used to implement other steps of the aforementioned evaluation method for simulating fault diagnosis in intelligent connected vehicles, as follows: Step 1: System environment initialization and physical connection establishment The goal of this step is to seamlessly embed the fault control device into the vehicle's electrical system without damaging the original vehicle. At the same time, it completes the initial handshake of the control box, communication link, computing platform, and human-machine interface to ensure that all units reach a state consensus at startup, providing stable underlying support for subsequent fault injection and feedback.

[0036] 1.1 The original vehicle wiring harness of the intelligent connected vehicle is connected to the input terminal block of the fault control box via industrial-grade anti-reverse pin connectors. The output terminal block of the control box is reconnected to the input terminal of the corresponding functional module of the vehicle via connectors of the same specification, forming a signal path from the original vehicle ECU to the control box input, relay contacts, and control box output to the target sensor or actuator. This connection method fully adopts the original vehicle interface protocol, without cutting, soldering, or modifying the wiring. Signal routing is achieved only through adapters, ensuring that the original electrical characteristics, impedance matching, and signal timing of the vehicle are completely preserved. Each signal path inside the control box is configured with an independent physical channel, with electrical isolation between channels to avoid crosstalk. Each channel is clearly labeled with wire numbers and function names, such as "CAM_PWR_12V", "RADAR_CAN_H", and "EPS_TORQUE_CMD", facilitating quick location and management by instructors. This physical connection structure provides the hardware carrier for all subsequent fault simulation behaviors. All fault modes such as "open circuit", "short circuit", and "signal tampering" are implemented through relay state switching in this path, ensuring the authenticity and repeatability of fault injection.

[0037] 1.2 Inside the fault control box, a double-pole double-throw electromagnetic relay is configured for each input signal. Each relay includes a common terminal, a normally open terminal, and a normally closed terminal. Its coil is controlled by the main control MCU of the control box through a MOSFET drive circuit. The relay's default state is "normally closed and conducting," meaning the original vehicle signal is directly connected. When the coil is energized, it switches to a "normally open" or "floating" state, simulating faults such as "open circuit" or "short circuit to ground." The relay selection meets automotive-grade standards, supports a mechanical life of over 2 million cycles, and has a contact capacity of 30V / 5A, adapting to 12V / 24V vehicle systems. The drive circuit uses optocoupler isolation and freewheeling diode protection to prevent the coil back EMF from damaging the MCU. The physical path established in 1.1 is given dynamic controllability here. The relay contacts become the physical execution unit for fault injection. Their state switching does not rely on software simulation but actually changes the electrical connection of the circuit, ensuring that the fault phenomenon is completely consistent with the actual vehicle fault, thus improving the realism of the diagnosis. For example, when simulating a "power supply failure of the front-view camera", the relay cuts off the 12V power supply line, the camera immediately goes black, and the corresponding status bit in the CAN message changes to "no response", which is completely consistent with the phenomenon of a real wire harness breakage.

[0038] 1.3 The control box has three built-in independent communication interfaces: the first is a CAN 2.0B bus interface, used to receive fault setting commands forwarded by the onboard computing platform and send relay status feedback; the second is a 433MHz wireless RF transceiver module, used to receive wireless commands sent by the group control device; the third is a USB or RS485 debugging interface, used for local configuration and firmware upgrades. These three interfaces are isolated at the hardware level, and the command priority is determined by the MCU's internal arbitration logic: wireless commands have the highest priority, followed by CAN commands, and debugging commands have the lowest priority, ensuring that emergency operations can interrupt the normal process. All communication protocols use a custom frame structure with verification and retransmission mechanisms. The relay drive circuit configured in 1.2 is linked to the communication interface here. The MCU parses the target relay number and target status according to the received command content, driving the corresponding MOSFET to turn on or off, achieving precise control of the relay coil. For example, when the instruction "Set fault point F03" is received, the MCU parses the relay number as R03 and the target state as "open". Then it drives the corresponding MOSFET to turn on, so that the R03 coil is energized and the contacts switch from normally closed to normally open, thus completing the physical circuit break.

[0039] 1.4 After the control box is powered on, it executes a self-test program, sequentially scanning the current physical state of all relays (reading contact feedback signals via GPIO) and comparing it with the last power-off state stored in the EEPROM. If they do not match, an exception log is recorded. After the self-test is completed, a "System Ready" message is broadcast to the vehicle computing platform via the CAN bus. The message identifier is 0x7E0, and the data field is 8 bytes, defined as follows: byte 0 is the status code 0xAA (indicating initialization complete), bytes 1 to 4 are the unique serial number of the control box (e.g., 0x12345678), byte 5 is the total number of relays N, and bytes 6 to 7 are the CRC16 checksum. Upon receiving this message, the vehicle computing platform displays "Control box [serial number] connected, N relays available" on the human-machine interface and illuminates the corresponding vehicle icon in green. The communication capability established in 1.3 is used here for system status synchronization, ensuring that teachers and students are aware that the equipment is ready before operation, avoiding misoperation due to communication failure. Meanwhile, the serial number mechanism supports parallel management of multiple vehicles, with each vehicle's control box being independently identified and not interfering with each other.

[0040] To quantify system initialization integrity, define device readiness. : ; when If so, the system allows you to proceed to the next step; if If the error occurs, a warning message will pop up saying "Some channels are abnormal, please check Rxx". Forced repairs must be performed before continuing. This formula ensures that all physical channels are under control, preventing teaching accidents caused by hardware failures.

[0041] Step 2: Fault Setting Mode Selection and Permission Verification This step is used to determine the fault setting method adopted in this training and to complete operator authentication, ensuring that only authorized personnel can preset faults and preventing students from accidentally interfering with the teaching process. The system supports three independent operation paths, which are adapted to different scenarios such as local stand-alone teaching, remote centralized management and control, and hands-on practice in environments without network access.

[0042] 2.1 Teachers select "Fault Setting Mode" on their operating terminals. Terminal types include: Windows host computer software installed on the teacher's computer, a Web server interface deployed on the campus intranet, and a handheld group control device's physical operation panel. After selection, the system activates the corresponding command channel: if host computer software is selected, local UDP port 5001 is enabled for listening; if a Web server is selected, a WebSocket long connection is established to the specified IP and port; if a group control device is selected, the 433MHz RF receiver is activated and enters listening mode. This selection directly affects the source of commands listened to by the control box in the first step, ensuring the command path and operational intent are aligned. Figure 1For example, when a teacher selects "group control device", the control box will ignore the setting commands on the CAN bus and only respond to the wireless radio frequency signal to avoid multipath command conflicts.

[0043] 2.2 The system requires teachers to enter administrator credentials. Credential formats supported include: username plus a 6-digit dynamic password (refreshed every 30 seconds), IC card authentication, and fingerprint recognition. The verification process is completed locally or on the server side, without relying on the internet. Upon successful verification, the system unlocks the "Fault Point Selection" function and displays "Administrator mode activated, valid for 15 minutes" at the top of the interface. If verification fails, all fault setting-related buttons, menus, and sliders are grayed out and disabled, and a "Insufficient permissions, please contact the administrator" prompt appears. The command channel selected in 2.1 is granted operational permissions here; only authorized users can trigger subsequent command issuance, ensuring teaching order. The dynamic password mechanism prevents prolonged unauthorized access due to password leaks, and the 15-minute automatic logout mechanism prevents the device from remaining operational after the teacher leaves.

[0044] 2.3 The teacher browses the vehicle system topology diagram on the visual interface. The topology diagram is displayed hierarchically by functional domain, including the perception layer (camera, millimeter-wave radar, ultrasonic radar, lidar), the decision-making layer (domain controller, algorithm module), the execution layer (steering motor, brake pump, drive motor), and the communication layer (CAN bus, Ethernet switch, V2X module), etc. Each functional module has several configurable fault points, such as "forward camera image loss," "millimeter-wave radar target tracking failure," and "steering angle sensor signal drift," etc., with a total of more than 128. After the teacher clicks on a target fault point, the system maps it to an internal unique fault code, recorded as... ,in This represents the fault point number, ranging from 1 to N, where N is the maximum number of fault points supported by the system. The mapping relationship is stored in a local SQLite database, with fields including fault name, system, relay number, default status, and recovery method. The unlocking function in section 2.2 is concretized here as a fault point selection action. The encoding mapping ensures that the human-machine interaction content can be understood by the underlying hardware, avoiding semantic ambiguity.

[0045] To evaluate the rationality and educational value of fault point setting, fault teaching weights are introduced. : ; in: This indicates the technical complexity of the fault point (e.g., 5 for multi-system linkage, 1 for a single circuit breaker). This indicates the frequency of the fault in actual vehicles (based on statistics from the after-sales database). Indicates the level of security impact (0 = no impact, 1 = functional degradation, 2 = functional failure). This is the weighting coefficient, with default values ​​of 0.4, 0.3, and 0.3. Teachers can customize the values.

[0046] The system allows teachers to select... Automatically calculate and display. This helps teachers identify high-value fault points. For example, a fault point involving a communication interruption in the braking system. ,but This is high-priority teaching content.

[0047] 2.4 The system, based on the selection in 2.3 This generates the corresponding control command data packet. If using a host computer or server mode, the data packet is encapsulated as a standard CAN frame, with the identifier 0x7E8. The data field format is: byte 0 is the command type 0xA1 (indicating "set fault"), and byte 1 is the fault code. The second byte indicates the operation type (0x00 for "activate fault", 0x01 for "clear fault"), and bytes 3 to 7 are reserved fields, filled with 0x00. This frame is sent to the vehicle computing platform via the USB-CAN adapter, and then forwarded by the computing platform to the fault control box via the vehicle CAN bus. If a group control device is used, it is encapsulated as a wireless data frame with a preamble of 0xAA55. The first byte of the data field is the device address (paired and bound to the control box), the first byte is the instruction 0xB1, and the second byte is... The third byte indicates the operation type, and bytes 4 through 7 are CRC8 checksums. The CAN and wireless communication links established in section 1.4 are used here for command transmission, ensuring that commands are accurately delivered to the control box regardless of the selected mode. The command includes an operation type field, supporting bidirectional "activation" and "clearing" control, providing a basis for subsequent automatic recovery.

[0048] To ensure reliable command transmission, a command delivery confidence level is defined. : ; The time from when the feedback message was sent to when it was received in section 3.4 This is the timeout threshold (default 2 seconds). If The system automatically resends commands, up to three times. This formula, based on an exponential decay model, quantifies the impact of communication latency on reliability, ensuring that critical commands are not lost.

[0049] Step 3: Fault Command Analysis and Relay State Switching This step follows the control commands generated in the second step. The fault control box completes the entire closed loop of command parsing, relay driving, and status feedback, ensuring that the fault setting action takes physical effect and transmitting the execution results back in real time for confirmation by the upper-level system.

[0050] 3.1 The MCU in the fault control box continuously monitors the CAN bus and the wireless RF interface. When a CAN frame with identifier 0x7E8 is received, the 0th byte of the data field is parsed; if it is 0xA1, the fault setting process is initiated. When a wireless frame with preamble 0xAA55 is received, the 1st byte is parsed after CRC8 verification; if it is 0xB1, the fault setting process is initiated. The MCU records an operation log based on the source of the instruction, including timestamp, operator ID (if via server), instruction type, and target fault point. The instruction data packet generated in 2.4 is received and initially verified here to ensure that the instruction format is valid and the source is reliable, avoiding malfunctions caused by noise or erroneous data.

[0051] 3.2 The MCU parses the fault code from 3.1 Query the internal relay mapping table to obtain the corresponding relay number. With the target state (Open or Closed). The mapping table is stored in Flash memory and supports online updates. For example, fault code F03 corresponds to relay R07, and the target state is "open". The MCU then checks the current state of the relay (reading the contact feedback via GPIO). If it matches the target state, the drive is skipped, and the feedback process is entered directly; if they do not match, the corresponding MOSFET is driven, energizing or de-energizing the relay coil, completing the state switch. The switching process is accompanied by a short beep from the buzzer, indicating that the physical action has been performed. The fault codes and operation types contained in 2.4 are translated into specific hardware actions here, ensuring a one-to-one correspondence between software instructions and physical responses.

[0052] To evaluate relay switching efficiency, a state switching delay index is defined. : ; in: The time from the driving MOSFET to the contact state stabilizing (measured by 3.3); The nominal operating time of the relay (e.g., 5ms); To allow the maximum latency (e.g., 50ms).

[0053] like The system records "Relay Rj responds slowly," and replacement is recommended. This formula quantifies the impact of hardware aging on the teaching experience.

[0054] 3.3 After the relay state switching is completed, the MCU waits for 100 milliseconds to stabilize before reading the contact feedback signal again to confirm that the physical state has stabilized at the target value. If the state switching is not successful (e.g., relay jamming, drive circuit failure), error codes E01 to E05 are recorded, and an error message (ID=0x7E9, data byte 0=0xEE, byte 1=error code) is sent via the CAN bus, while a buzzer sounds for 3 seconds. If the state switching is successful, a state confirmation message is prepared to be sent. The physical switching action performed in 3.2 is verified twice here to ensure the reliability of fault injection and avoid teaching accidents where "software displays that it has been set, but hardware does not respond."

[0055] 3.4 The MCU generates a relay status feedback CAN message with the identifier 0x7E1. The data field format is as follows: byte 0 is the status code 0xBB (indicating "status update"), and byte 1 is the relay number. The second byte indicates the current status (0x00 = closed, 0x01 = open), and the third byte indicates the associated fault code. Bytes 4 to 7 are timestamps (the lower 4 bytes of Unix time). This message is broadcast via the CAN bus and can be received by both the onboard computing platform and the host computer software. Simultaneously, if the command originates from a group control device, the MCU also transmits an acknowledgment frame via the wireless module (data byte 0 = 0xC1, byte 1 = ...). (The second byte = status). The status information that was successfully verified in 3.3 is encapsulated into a standard message here for the upper-layer system to use for interface updates and process recording, forming a complete closed loop of "instruction-execution-feedback".

[0056] To ensure consistency of state across multiple terminals, a state synchronization deviation is defined. : ; like The system displays a message on the teacher's end: "Terminal synchronization delay, please check the network," ensuring that all students see the fault status at the same time.

[0057] Step 4: Visualization of Fault Phenomena and Diagnostic Guidance This step transforms the physically triggered fault status from step three into visual prompts via the in-vehicle computing platform. The affected system modules are highlighted on the vehicle's infotainment screen or the teacher's terminal, guiding students to focus on the diagnostic scope, avoiding blind troubleshooting, and improving teaching efficiency.

[0058] 4.1 The onboard computing platform continuously monitors the CAN bus. When it receives a status update message with identifier 0x7E1, it parses the 3rd byte of the data field to obtain the fault code. The second byte retrieves the current status of the relay. The platform queries the local fault-system mapping table to determine the functional system to which the fault point belongs, such as "F03, forward-looking camera, perception system". The mapping table supports dynamic loading in JSON format, making it convenient to add fault points without recompiling the software. The status message broadcast in section 3.4 is received and parsed here, providing a data source for visualization.

[0059] 4.2 Based on the functional systems defined in 4.1, the computing platform uses a graphics engine to highlight the corresponding system modules on the vehicle's central control screen or the teacher's monitoring screen. Highlighting methods include: a flashing red border, a semi-transparent red overlay on the module icon, and the system name text turning red with a scrolling message "Fault Activation in Progress." Simultaneously, the status bar at the bottom of the screen displays "Currently Activated Fault: Power Supply Disconnection to Forward-Looking Camera (F03)" and records the activation time. If multiple fault points are activated within the same system, they are combined and displayed as "Multiple Faults in the Perception System," which can be clicked to expand details. The fault codes and system attribution information contained in 3.4 are transformed into intuitive visual prompts here, helping trainees quickly locate the problem domain.

[0060] To quantify the effectiveness of the prompts, the clarity of fault location is defined. : ; This represents the hierarchical depth of the fault point within the system topology (e.g., vehicle = 1, subsystem = 2, component = 3, signal = 4). The formula is the Sigmoid function, when... (Component level) ,when (Signal level) Teachers are encouraged to set fine-grained faults to improve diagnostic accuracy.

[0061] 4.3 The system synchronously displays an overview of the fault status of all vehicles on the teacher's interface, using a matrix layout. The horizontal axis represents vehicle numbers, and the vertical axis represents system categories. Cell colors indicate status (green = normal, red = faulty, gray = offline). Teachers can click on any red cell to drill down and view a detailed list of fault points, activation time, and expected recovery method for that vehicle and system. Simultaneously, the system automatically starts a timer to record the time elapsed from the activation of the fault point to the student submitting a diagnosis, for subsequent evaluation. The visual information generated in 4.2 is aggregated into a global view here, allowing teachers to monitor multiple vehicles and multiple faults simultaneously, improving classroom management efficiency.

[0062] 4.4 To assist trainees in diagnosis, the system provides a description of typical symptoms of the fault, potentially affected functions, recommended testing tools (such as a multimeter to measure voltage, an oscilloscope to measure waveforms, and a diagnostic tool to read DTCs), and a standard troubleshooting flowchart on the "Diagnostic Assistant" tab of the vehicle's infotainment interface. The content is sourced from a fault knowledge base and can be customized by instructors. For example, for F03, the prompt is: "Symptom: No image output from the forward-facing camera, ADAS function disabled; Test: Measure the voltage at the camera power supply pin; it should be 12V±0.5V; Procedure: Check fuses, relays, wiring harnesses, and ECU outputs." The fault information recorded in 4.3 is transformed into teaching guidance content here, lowering the entry barrier for trainees and ensuring that the diagnostic process is based on evidence.

[0063] To assess the completeness of the guidance path, diagnostic path coverage is defined. : ; This value is calculated in real time in 5.2. Before submission, the system will display a message suggesting additional testing steps: XXX, to improve the rigor of the diagnosis.

[0064] Step 5: Student Diagnostic Operations and Result Submission This step is led by the trainees. Based on the visual prompts and diagnostic guidance provided in step four, they use tools such as multimeters, oscilloscopes, and diagnostic instruments to conduct actual tests. Finally, they submit their diagnostic conclusions in the host computer software. The system automatically compares the correctness and triggers the evaluation and recovery process.

[0065] 5.1 Students log in to the student client of the host computer software. The interface automatically synchronizes the list of active fault systems for the current vehicle (from the global view in 4.3). Students select the vehicle and system to be diagnosed and enter the "Diagnostic Workbench" interface. The left side of the interface displays the system topology and highlighted fault modules, the right side is a diagnostic tool simulation panel (supporting virtual multimeter, virtual oscilloscope, and virtual diagnostic instrument), and the bottom is the "Submit Answer" button. The guidance information provided in 4.4 is integrated into the operation interface here, ensuring that students conduct diagnosis in a unified environment.

[0066] 5.2 Trainees use physical or virtual tools to detect suspected fault points. For example, for a "power supply interruption to the front-view camera," trainees use a multimeter to measure the voltage at the power supply pin of the camera plug. If the reading is 0V, a power supply line fault is suspected. Next, the voltage at the output terminal of the fault control box is measured. If it is still 0V but the input terminal is 12V, the fault is located in the control box relay. During the detection process, the system records the type of tool used by the trainee, the measurement points, the measured values, and the operation time, forming a diagnostic trajectory log. The detection methods recommended in 4.4 are actually executed here, and the system records the process behavior through the log for subsequent process evaluation.

[0067] To quantify the rationality of the diagnostic path, a path deviation degree is defined. : ; This represents the recommended total number of steps. If... The system flags the path as "abnormal" and provides optimization suggestions in the report.

[0068] 5.3 On the "Diagnostic Workbench" interface, the trainee clicks the "Submit Answer" button, and a fault selection list pops up. The list content is consistent with the teacher's settings (e.g., F01 to F128). The trainee selects the fault code they believe to be correct. Confirm submission. The system immediately locks the student's submission privileges for that fault point to prevent duplicate submissions. Submission content includes: Student ID, Vehicle ID, and Fault Code. The submission time, diagnostic time, and list of tools used are included. The diagnostic trajectory recorded in section 5.2 is summarized here into a submission data package as an evaluation criterion.

[0069] 5.4 The system will process the data submitted by the trainees. Compared with the teacher's pre-set plan Perform a comparison. If... If the diagnosis is successful, the system records "Diagnosis Successful" and automatically triggers the fault recovery process (see step six); if If the diagnosis is incorrect, the system records "Diagnosis Failed" and displays "Incorrect answer, please retest" on the interface. No recovery is triggered, allowing students to retest and submit (unlimited attempts, but the number of retries is recorded). The comparison results are simultaneously updated on the teacher's statistics panel, displaying each student's accuracy rate, average time taken, number of retries, etc. The diagnostic conclusions submitted in section 5.3 are evaluated here, and the evaluation results directly drive subsequent recovery actions, forming a closed-loop teaching system of "diagnosis-evaluation-recovery".

[0070] To comprehensively evaluate the quality of a single diagnosis, a diagnostic quality index is defined. : ; in If correct, If there is an error; The time taken for the first submission (in seconds); The number of submissions is the maximum score. This index considers accuracy, speed, path standardization, and step completeness, with a maximum score of 100.

[0071] Step 6: Automatic Fault Recovery and Status Synchronization This step is automatically triggered after the trainee makes a correct diagnosis. It controls the relay to return to its original state through reverse commands, clears the fault, and updates all terminal displays simultaneously to ensure that the vehicle is back to usable status and prepares for the next round of training.

[0072] 6.1 When the diagnosis in 5.4 is correct, the system automatically generates a "Clear Fault" command data packet. The format is completely consistent with that in 2.4, except that the operation type of the second byte is changed to 0x01. This command returns via the original path: if the original settings were through the host computer, the host computer will still send the CAN frame; if it was through the group control device, the server will generate a wireless frame and send it. The command target remains the same control box and relay. The correct evaluation result in 5.4 is converted into a recovery command here to ensure that the recovery action is consistent with the setting action path and avoid state confusion.

[0073] 6.2 After receiving the "Clear Fault" command, the fault control box MCU parses the target relay number. With operation type 0x01, the corresponding MOSFET is driven to de-energize the coil, and the relay contacts switch from normally open to normally closed, restoring the original vehicle signal path. After the switch is complete, the contact status is read again to confirm successful restoration; if it fails, an error is reported. The physical restoration process is also accompanied by a short beep from the buzzer to indicate that restoration is complete. The restoration command generated in 6.1 is executed here to ensure that the fault is truly eliminated.

[0074] 6.3 The MCU generates a recovery confirmation message, CAN ID=0x7E1, data byte 0=0xBC (indicating "recovered"), byte 1= Byte 2 = 0x00 (closed), Byte 3 = Bytes 4 to 7 represent the recovery timestamp. After this message is broadcast, the onboard computing platform receives it, immediately clears the highlighted display of the corresponding system module, restores it to the normal green, and displays "Fault F03 has been recovered" in the status bar. The physical recovery completed in section 6.2 is reflected in the interface here, ensuring that the visual status is synchronized with the physical status.

[0075] 6.4 The teacher's interface updates synchronously; the fault cell for the corresponding vehicle changes from red to green, the timer stops, and the total diagnostic time and recovery time are recorded. The system automatically generates a diagnostic report for this task, including the student's name, diagnosed fault point, submitted answer, whether it was correct, time taken, number of retries, and tools used, and stores it in the database for later analysis. The interface status updated in 6.3 is aggregated into a teaching report here, supporting teachers' post-lesson review and student ability assessment.

[0076] To assess recovery efficiency, a recovery integrity index is defined. : ; The relay recovery time is specified in section 6.2. This refers to the interface update time in version 6.3. .like The system displays a message indicating "interface synchronization delay," and the rendering logic has been optimized.

[0077] Step 7: Diagnostic Process Evaluation and Capability Profile Generation This step, based on the data accumulated in the previous six steps, conducts a multi-dimensional quantitative evaluation of the trainees' diagnostic behavior, generates a personal competency profile, and provides data support for teaching improvement and personalized training.

[0078] 7.1 The system extracts data from the entire process of a single diagnosis, including: the time elapsed from fault activation to the initial submission. Total number of submissions The combination of tools used in each submission Is it ultimately correct? (1 or 0), Total recovery time Define the diagnostic efficiency index. for: ; This index comprehensively reflects speed, accuracy, and recovery capability. The raw data generated in section 6.4 is transformed into quantitative indicators here, supporting cross-sectional comparisons.

[0079] 7.2 Based on trainees' multiple training records, the system calculates their average efficiency index, accuracy rate, and average time consumption under different fault types (power supply, signal, communication, and actuator), and plots radar charts and trend curves. For example, if a trainee's average efficiency is 85 points in "power supply" faults but only 60 points in "communication" faults, the system will indicate that "communication fault diagnosis capabilities need improvement." The individual indices calculated in 7.1 are aggregated here into capability dimension analysis to help trainees identify their weaknesses.

[0080] To predict ability growth trends, a "ability growth model" is introduced: ; The ability score is given after t training sessions. This is the theoretical upper limit (e.g., 95 points). The number of training sessions required to double the ability (default 5). The system fits the student's historical data, predicts the amount of training needed to reach the target score, and generates an "ability improvement roadmap".

[0081] 7.3 The system, in conjunction with a fault knowledge base, analyzes whether trainees' commonly used diagnostic paths conform to standard procedures. For example, for a "CAN communication interruption" fault, the standard procedure should be "check the terminating resistor, check the CAN_H / CAN_L voltage, check message transmission and reception." If a trainee skips the resistor and directly measures the voltage, it is marked as "procedure skipping," and the report suggests "following the standard procedure to improve coverage." The capability dimensions in 7.2 are refined to the operational procedure level here, providing suggestions for process improvement.

[0082] 7.4 Finally, a student's individual competency report PDF is generated, including: overall score, scores for each dimension, weak areas highlighted, a list of recommended training fault points, and a historical performance comparison chart. The report is automatically pushed to the student's account and the teacher's management backend, and supports export and printing. Teachers can adjust the focus of subsequent courses based on the class report, such as "if the average score for communication faults in the whole class is below 70, add CAN bus training hours next week." The process analysis in 7.3 is integrated here into actionable teaching suggestions, realizing a closed loop of teaching iteration of "evaluation-feedback-optimization".

[0083] To quantify the overall level of the class and define the degree of teaching achievement : ; For the number of students, Let k be the efficiency index of student k. The system suggests "increasing the proportion of basic fault training".

[0084] This embodiment, from physical connection to access control, from fault injection to phenomenon visualization, from student operation to automatic recovery, and from data collection to capability profiling, does not rely on any destructive methods. It supports multi-vehicle parallel operation, multi-terminal collaboration, and offline operation, and is suitable for various scenarios such as vocational schools, corporate training, and skills competitions. It achieves a fundamental shift from "experience-based teaching" to "data-driven teaching," providing industrial-grade practical training and evaluation standards for cultivating new professional talents such as intelligent connected vehicle assembly and maintenance personnel and testers.

[0085] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for evaluating the diagnostic process of simulated faults in intelligent connected vehicles, characterized in that, include: A switchable signal path is established by connecting the original vehicle wiring harness and the vehicle function module in a non-destructive manner through the fault control box. In response to the fault setting command issued by the teacher, the state switching of the relay in the fault control box is controlled to simulate the target fault; The fault status information is sent to the vehicle computing platform, and the scope of the fault impact is visualized on the vehicle screen or teacher terminal. Students perform detection operations according to the visual prompts and submit the diagnostic results. The diagnostic results submitted by the trainees are compared with the preset faults. If they match, the diagnosis is considered correct. When the diagnosis is correct, the fault recovery command is automatically triggered, and the relay is controlled to return to its original state. Based on the operational behavior data and outcome data of trainees during the diagnosis process, a diagnosis quality index and an individual capability profile are generated.

2. The evaluation method for the diagnostic process of simulated faults in intelligent connected vehicles according to claim 1, characterized in that, The establishment of a switchable signal path includes: Connect the original vehicle wiring harness to the input terminal block of the fault control box via an industrial-grade anti-return pin connector, and reconnect the output terminal block to the input terminal of the vehicle function module. Inside the fault control box, a double-pole double-throw electromagnetic relay is configured for each signal. The common terminal is connected to the original vehicle ECU output, and the normally closed terminal is connected to the target sensor or actuator input. The relay is normally closed and conducting by default, and the coil is controlled by the MCU through an optocoupler-isolated MOSFET drive circuit; Each channel is clearly labeled with its wire number and function name, and the channels are electrically isolated to avoid signal crosstalk.

3. The evaluation method for the diagnostic process of simulated faults in intelligent connected vehicles according to claim 2, characterized in that, Before the relay state switch, the fault control box performs system initialization and physical connection confirmation, specifically including: After power-on, scan the current physical state of all relays and compare it with the last power-off state stored in the EEPROM; If there are inconsistencies, an exception log will be recorded; if all are consistent, the system will enter standby mode. The system readiness message is broadcast via the CAN bus. The data field includes the status code, the unique serial number of the control box, the total number of relays, and the CRC16 check value. After receiving the data, the vehicle-mounted computing platform displays on the human-machine interface that the control box has been connected.

4. The evaluation method for the diagnostic process of simulated faults in intelligent connected vehicles according to claim 3, characterized in that, The response to the fault setting command issued by the teacher includes: Teachers select a fault setting mode on an operating terminal, which includes Windows host computer software, a web server interface, or a handheld group control device. Based on the selection result, activate the corresponding command channel: the host computer enables UDP port 5001 to listen, the web server establishes a WebSocket long connection, and the group control device starts the 433MHz radio frequency receiver. Teachers are required to enter administrator credentials for identity verification. Credentials can be dynamic passwords, IC cards, or fingerprint recognition. After successful verification, the system loads the vehicle system structure diagram of the current training vehicle. The vehicle system structure diagram is rendered and displayed on the operation terminal interface in layers according to the perception layer, decision layer, execution layer and communication layer, and the fault point selection function area is activated at the same time.

5. The evaluation method for the diagnostic process of simulated faults in intelligent connected vehicles according to claim 4, characterized in that, After the vehicle system structure diagram is loaded and displayed stably, fault point selection and mapping are performed, specifically including: Teachers can click on a functional module in the vehicle system structure diagram using a touch screen or mouse, and the system will highlight the module and its associated signal path. After clicking "Confirm," the system maps it to an internally unique fault code. The mapping relationship is queried from the local SQLite database, and the fields include fault name, system, relay number, default status, and recovery method; The system synchronously calculates and displays the teaching weight value of the fault point to help teachers screen high-value fault points.

6. The evaluation method for the diagnostic process of simulated faults in intelligent connected vehicles according to claim 5, characterized in that, The generation and transmission of fault setting instructions include: Generate control command data packets based on the selected fault codes; If using host computer or web server mode, the CAN frame is encapsulated with identifier 0x7E8, and the 0th byte is 0xA1 to indicate that a fault is set. If a group control device is used, the wireless frame is encapsulated with a preamble of 0xAA55 and an additional CRC8 checksum is added. The command is sent to the fault control box via the USB-CAN adapter or wireless module, triggering the fault control box to enter the command receiving and parsing state.

7. The evaluation method for the diagnostic process of simulated faults in intelligent connected vehicles according to claim 6, characterized in that, The fault control box enters command reception and parsing, including: The MCU continuously monitors the CAN bus and the wireless RF interface, and parses the instruction content after receiving a 0x7E8 frame or a 0xAA55 frame. Query the internal relay mapping table to obtain the corresponding relay number and target status; Check the current state. If it is inconsistent with the target, drive the corresponding MOSFET to energize or de-energize the coil to complete the switching. The MCU generates an internal event flag indicating that the relay state switching is complete and controls the buzzer to sound a short beep to indicate that the action has been executed.

8. The evaluation method for the diagnostic process of simulated faults in intelligent connected vehicles according to claim 7, characterized in that, After the internal event flag for the relay state switching is set, confirmation and feedback are performed after the relay state switching, specifically including: The MCU waits for 100 milliseconds to stabilize before reading the contact feedback signal again to confirm that the physical state has stabilized. If the state switch fails, the error code is recorded and the error message is sent via a CAN message with identifier 0x7E9, and the buzzer sounds a continuous alarm. If the switch is successful, a status update message with identifier 0x7E1 is generated. The data field contains status code 0xBB, relay number, current status, fault code and timestamp. The message is broadcast via the CAN bus and can be received by both the vehicle computing platform and the host computer.

9. The evaluation method for the diagnostic process of simulated faults in intelligent connected vehicles according to claim 8, characterized in that, After the status update message is successfully generated and broadcast, the vehicle computing platform receives the message and completes the visualization display of the fault impact range. Based on the diagnostic operation behavior data and result data of the trainee under the visualization prompts, a diagnostic quality index is generated.

10. A diagnostic process evaluation system for simulating faults in intelligent connected vehicles to implement the method as described in any one of claims 1-9, characterized in that, include: The fault control box connects to the original vehicle wiring harness and vehicle function module via an industrial-grade anti-return pin connector. It is equipped with a double-pole double-throw electromagnetic relay array. The common terminal of the relay is connected to the output of the original vehicle ECU, and the normally closed terminal is connected to the input of the target sensor or actuator. The coil is controlled by the MCU through the MOSFET drive circuit. The multi-channel communication unit integrates a CAN 2.0B bus interface, a 433MHz wireless RF transceiver module, and a USB / RS485 debugging interface. The three are hardware isolated and the instruction priority is set by the MCU arbitration logic. The self-test and status feedback module is used to scan the physical status of the relays after power-on and compare it with historical records. After completing the self-test, it broadcasts a system ready message containing the serial number and the total number of relays. The instruction parsing and execution module is used to receive and verify fault setting instructions from the host computer, web server or group control device, parse out the fault code, query the mapping table to determine the target relay number and status, and drive the corresponding MOSFET to complete the coil on / off control. The status confirmation and message generation module is used to read the contact feedback signal after the relay switching to confirm that the status is stable, generate a CAN message containing status code, relay number, current status, fault code and time stamp and broadcast it through the CAN bus; The vehicle-mounted computing platform is used to listen to status update messages on the CAN bus, parse them, call the graphics engine to highlight the affected system modules on the vehicle screen, and present a multi-vehicle fault status matrix view on the teacher's interface. The diagnostic guidance module provides descriptions of typical symptoms, possible functional impacts, recommended testing tools, and standard troubleshooting flowcharts. The content is derived from an editable fault knowledge base. The diagnostic result comparison and recovery trigger module is used to compare the fault codes submitted by the students with the preset codes of the teachers. If they match, a fault clearing command is automatically generated and returned to the fault control box via the original path. The automatic fault recovery module responds to the clear command to drive the relay back to the normally closed state. After confirmation, it broadcasts a message that the fault has been recovered, so that the on-board computing platform clears the highlighted prompts and updates the teacher's interface. The evaluation and profile generation module extracts data from the entire diagnostic process of trainees, calculates the diagnostic quality index by combining path deviation and step coverage, generates personal ability radar charts, trend curves and improvement roadmaps based on multiple training records, and outputs PDF ability reports to trainee accounts and teacher backends.

Images