A method and apparatus for verifying the vehicle signals and component status of an intelligent driving system.

Abstract

This disclosure provides a method and apparatus for verifying the vehicle signals and device status of intelligent driving systems. By using an independently deployed verification agent, the system automatically collects, analyzes, and verifies the vehicle's CAN signals, in-vehicle Ethernet signals, and device status information. Based on the verification results, a standardized report is generated. This method can detect abnormal vehicle signal response and device communication in the early stages of intelligent driving system development, reducing the workload of manual analysis, minimizing human judgment bias, and improving the efficiency of vehicle signal and device status verification. It also facilitates R&D personnel to quickly locate the root cause of problems and carry out rectification based on the standardized verification results.

Description

Technical Field

[0001] This disclosure relates to the field of intelligent driving system testing and verification technology, and more specifically, to a method and apparatus for verifying the vehicle signals and component status of an intelligent driving system. Background Technology

[0002] With the development of intelligent driving technology, intelligent driving systems in vehicles typically need to communicate and interact with multiple controllers, sensors, and actuators throughout the vehicle, such as exchanging signals with components like LiDAR, cameras, domain controllers, brake controllers, and steering controllers. To ensure the normal operation of the intelligent driving system in the vehicle environment, it is necessary to verify the CAN signals, CAN FD signals, in-vehicle Ethernet signals, and the operating status of each component during the vehicle development process. This verifies whether the vehicle communication link, signal response logic, and component status feedback meet the design requirements.

[0003] Current methods for verifying vehicle signals and the status of components typically rely on manual operation of testing equipment for signal acquisition and analysis. Testers need to manually configure test parameters according to the vehicle's communication protocol, connect dedicated testing equipment to acquire CAN or Ethernet signals, and then manually analyze and compare the acquired data. Furthermore, for the matching status between the intelligent driving system and its components, it is usually necessary to verify, through real-vehicle debugging, whether each component can power on, communicate, and provide feedback normally after the intelligent driving system has basically completed full-function development and is installed in the vehicle.

[0004] However, existing verification usually requires waiting until the basic development of the full functionality of the intelligent driving system is completed before it can be carried out. This makes it impossible to detect problems such as signal loss, communication anomalies, or mechanical logic errors in advance during vehicle assembly, power-on, or the early development stage of the intelligent driving system. This results in a delay in problem detection and increases the cost of subsequent network protocol modifications, mechanical software adjustments, and vehicle rectification. Summary of the Invention

[0005] This disclosure provides at least one method and apparatus for verifying the vehicle signals and device status of an intelligent driving system. It uses an independently deployed verification agent to automatically collect, analyze, and verify the vehicle's CAN signals, in-vehicle Ethernet signals, and device status information. Based on the verification results, a standardized report is generated. This allows for the early detection of abnormal vehicle signal responses and device communication anomalies in the early stages of intelligent driving system development, reducing manual analysis workload, minimizing human error, and improving the efficiency of vehicle signal and device status verification. Furthermore, it facilitates rapid identification of the root cause of problems and prompts rectification by R&D personnel based on standardized verification results.

[0006] This disclosure provides a method for verifying the vehicle signals and device status of an intelligent driving system, applied to a verification agent independently deployed on the vehicle communication interface or in-vehicle communication gateway. The method includes: Obtain the verification configuration information for the vehicle to be verified, including signal acquisition parameters, signal verification rules, and a list of counterpart components to be verified; Based on the signal acquisition parameters, raw vehicle signal data is acquired from the vehicle communication network of the vehicle to be verified. The raw vehicle signal data includes vehicle bus signal data and vehicle Ethernet signal data. According to the signal verification rules, the original vehicle signal data is automatically parsed to obtain the vehicle signal parsing results, and abnormal signal data is determined based on the vehicle signal parsing results. Send an intelligent driving system verification command to the vehicle communication network, and collect the signal response data returned by the vehicle to be verified in response to the intelligent driving system verification command. Based on the signal response data and the vehicle signal analysis results, determine the vehicle signal response verification result. Based on the list of counterparty components to be verified, the counterparty component status information corresponding to each counterparty component to be verified is extracted from the vehicle signal analysis results, and the counterparty component status detection result is determined based on the counterparty component status information. The abnormal signal data, the vehicle signal response verification results, and the device status detection results are integrated to generate vehicle signal and device status verification results.

[0007] In one optional implementation, obtaining verification configuration information for the vehicle to be verified specifically includes: Receive verification parameters configured by R&D personnel through a local operating interface or remote terminal; The verification parameters include at least the vehicle bus signal acquisition frequency, the vehicle Ethernet signal acquisition frequency, the signal standard threshold, the intelligent driving system verification command, the signal response timeout threshold, and the list of counterparts to be verified. The verification configuration information is generated based on the verification parameters, and the verification configuration information is stored in the storage module of the verification Agent.

[0008] In one optional implementation, based on the signal acquisition parameters, raw vehicle signal data is acquired from the vehicle communication network of the vehicle to be verified, specifically including: The vehicle bus signal data in the vehicle CAN network is acquired through the CAN bus interface. The vehicle bus signal data includes at least one of the following: signal ID, frame format, data length, transmission rate, and device feedback status code. In addition, the vehicle Ethernet signal data in the vehicle Ethernet network is collected through the vehicle Ethernet interface, and the vehicle Ethernet signal data includes at least one of Ethernet message format, transmission rate and data interaction content; The collected raw vehicle signal data is synchronously sent to the automated parsing submodule, and the raw vehicle signal data is stored locally.

[0009] In one optional implementation, the raw vehicle signal data is automatically parsed according to the signal verification rules to obtain the vehicle signal parsing result, specifically including: When the original vehicle signal data includes CAN signal data, the bit timing parameters, sampling point positions, frame formats, and CRC check results of the CAN signal data are parsed according to the CAN signal parsing rules. When the original vehicle signal data includes vehicle Ethernet signal data, the message format, transmission rate and data interaction logic of the vehicle Ethernet signal data are parsed according to the vehicle Ethernet signal parsing rules. The parsed signal parameters are compared with the corresponding standard thresholds, and signal data that does not meet the standard thresholds are marked as abnormal signal data.

[0010] In one optional implementation, a smart driving system verification command is sent to the vehicle communication network, and signal response data returned by the vehicle to be verified in response to the smart driving system verification command is collected, specifically including: The intelligent driving system verification command to be sent is determined based on the verification configuration information. The intelligent driving system verification command includes at least one of the following: a steering signal verification command, a braking signal verification command, and a perception sensor trigger signal verification command. The intelligent driving system verification command is sent through the vehicle communication network; After sending the intelligent driving system verification command, the system collects the signal response data returned by the vehicle to be verified. The signal response data includes at least one of response time, response data content, and response stability data.

[0011] In one optional implementation, the vehicle signal response verification result is determined based on the signal response data and the vehicle signal analysis result, specifically including: The response speed, accuracy, and stability of the vehicle to be verified in response to the verification command of the intelligent driving system are determined based on the signal response data. When the response speed does not meet the signal response timeout threshold, the response accuracy does not meet the preset response content requirements, or the response stability does not meet the preset stability requirements, the vehicle signal response is determined to be abnormal. Record the anomaly type, occurrence time, and signal ID corresponding to the vehicle signal response anomaly, and use the recording results as part of the vehicle signal response verification results.

[0012] In one optional implementation, based on the list of rival components to be verified, the status information of each rival component to be verified is extracted from the vehicle signal parsing results, and the status detection result of the rival component is determined based on the rival component status information, specifically including: Based on the preset counterpart signal feature library, determine the normal working status code, signal interaction frequency and data transmission format of each counterpart to be verified; Extract the status code, signal interaction data, and data transmission format corresponding to each device to be verified from the vehicle signal analysis results; The extracted status code, signal interaction data, and data transmission format are matched with the normal operation status code, the signal interaction frequency, and the data transmission format, respectively. When there is an abnormal status code, interrupted signal interaction, or incorrect data transmission format, determine that the corresponding peer to be verified has an abnormal status, and record the name of the abnormal peer, the type of abnormality, and the root cause of the problem.

[0013] In one optional implementation, the abnormal signal data, the vehicle signal response verification result, and the component status detection result are integrated to generate vehicle signal and component status verification results, specifically including: According to the preset report template, the verification basic information, signal analysis results, vehicle signal response verification results, manual component status detection results and rectification suggestions are compiled; Generate a standardized verification report, which includes verification time, vehicle identification information, intelligent driving system version, signal parsing pass rate, abnormal signal details, response pass rate, abnormal response details, normal operation rate of counterparts, abnormal counterparts details, and root cause of the problem. The standardized verification report can be stored locally, exported externally, or pushed remotely in a preset file format.

[0014] In an optional implementation, after generating the vehicle signals and the verification results of the component status, the method further includes: In response to the secondary verification command following the rectification of the anomaly, the current verification configuration information is re-acquired; Based on the current verification configuration information, re-execute vehicle signal acquisition, automated parsing, vehicle signal response verification, and component status detection; The regenerated verification results are compared with the verification results before rectification, and the anomalies are determined based on the comparison results.

[0015] This disclosure also provides a verification device for the vehicle signal and the status of the device in an intelligent driving system, applied to a verification agent independently deployed at the vehicle communication interface or the vehicle communication gateway. The device includes: The data acquisition module is used to acquire the verification configuration information for the vehicle to be verified, including signal acquisition parameters, signal verification rules, and a list of counterpart components to be verified. The data acquisition module is used to acquire raw vehicle signal data from the vehicle communication network of the vehicle to be verified based on the signal acquisition parameters. The raw vehicle signal data includes vehicle bus signal data and vehicle Ethernet signal data. The data parsing module is used to automatically parse the original vehicle signal data according to the signal verification rules, obtain the vehicle signal parsing result, and determine abnormal signal data based on the vehicle signal parsing result; The response verification module is used to send a smart driving system verification command to the vehicle communication network, collect the signal response data returned by the vehicle to be verified in response to the smart driving system verification command, and determine the vehicle signal response verification result based on the signal response data and the vehicle signal parsing result. The counterpart component detection module is used to extract counterpart component status information corresponding to each counterpart component to be verified from the vehicle signal parsing result according to the counterpart component to be verified list, and to determine the counterpart component status detection result based on the counterpart component status information. The verification result determination module is used to integrate the abnormal signal data, the vehicle signal response verification result, and the device status detection result to generate the vehicle signal and device status verification result.

[0016] This disclosure also provides an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the above-described method for verifying the vehicle signals and device status of the intelligent driving system, or any possible implementation of the above-described method for verifying the vehicle signals and device status of the intelligent driving system.

[0017] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the above-described method for verifying the vehicle signals and device status of the intelligent driving system, or any possible implementation of the above-described method for verifying the vehicle signals and device status of the intelligent driving system.

[0018] This disclosure also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the above-described method for verifying the vehicle signals and device status of the intelligent driving system, or the steps in any possible implementation of the above-described method for verifying the vehicle signals and device status of the intelligent driving system.

[0019] This disclosure provides a method and apparatus for verifying vehicle signals and device status in an intelligent driving system. It uses an independently deployed verification agent to automatically collect, analyze, and verify vehicle CAN signals, in-vehicle Ethernet signals, and device status information. Based on the verification results, a standardized report is generated. This allows for the early detection of abnormal vehicle signal responses and device communication anomalies in the early stages of intelligent driving system development, reducing manual analysis workload, minimizing human error, and improving the efficiency of vehicle signal and device status verification. Furthermore, it facilitates rapid identification of the root cause of problems and prompts rectification by R&D personnel based on standardized verification results.

[0020] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly described below. These drawings are incorporated in and constitute a part of this specification. They illustrate embodiments conforming to this disclosure and, together with the specification, serve to explain the technical solutions of this disclosure. It should be understood that the following drawings only show some embodiments of this disclosure and should not be considered as limiting the scope. Those skilled in the art can obtain other related drawings based on these drawings without creative effort.

[0022] Figure 1 A flowchart is shown below illustrating a method for verifying the vehicle signals and device status of an intelligent driving system according to an embodiment of this disclosure. Figure 2 A flowchart is shown for another method for verifying the vehicle signals and device status of an intelligent driving system provided in an embodiment of this disclosure; Figure 3 A schematic diagram of a verification device for vehicle signals and component status of an intelligent driving system provided in an embodiment of this disclosure is shown. Figure 4 A schematic diagram of an electronic device provided in an embodiment of the present disclosure is shown. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. The components of the embodiments of this disclosure described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this disclosure provided in the accompanying drawings is not intended to limit the scope of the claimed disclosure, but merely represents selected embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure.

[0024] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0025] In this document, the term "and / or" merely describes a relationship, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" in this document means any combination of at least two of any one or more elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0026] Research has found that current verification typically requires waiting until the basic development of all functions of the intelligent driving system is completed before it can be carried out. This makes it impossible to detect problems such as signal loss, communication anomalies, or logical errors of the components in advance during vehicle assembly, power-on, or the early development stage of the intelligent driving system. This results in a delay in problem detection and increases the cost of subsequent network protocol modifications, component software adjustments, and vehicle rectification.

[0027] Based on the above research, this disclosure provides a method and apparatus for verifying the vehicle signals and the status of components in an intelligent driving system. By using an independently deployed verification agent, the system automatically collects, analyzes, and verifies the vehicle's CAN signals, in-vehicle Ethernet signals, and the status information of components. Based on the verification results, a standardized report is generated. This method can detect abnormal vehicle signal response and abnormal component communication in the early stages of intelligent driving system development, reduce the workload of manual analysis, reduce the bias of manual judgment, and improve the efficiency of verifying the vehicle signals and the status of components. At the same time, it facilitates R&D personnel to quickly locate the root cause of the problem and carry out rectification based on the standardized verification results.

[0028] To facilitate understanding of this embodiment, a detailed description of the method for verifying the vehicle signals and device status of an intelligent driving system disclosed in this disclosure embodiment will be provided first. The execution entity of the method for verifying the vehicle signals and device status of an intelligent driving system provided in this disclosure embodiment is generally a computer device with certain computing capabilities. This computer device may include, for example, a terminal device, a server, or other processing devices. The terminal device may be a user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, wearable device, etc. In some possible implementations, the method for verifying the vehicle signals and device status of an intelligent driving system can be implemented by a processor calling computer-readable instructions stored in memory.

[0029] See Figure 1 The diagram shows a flowchart of a method for verifying the vehicle signal and component status of an intelligent driving system according to an embodiment of this disclosure. The method includes steps S101 to S106, wherein: S101. Obtain the verification configuration information for the vehicle to be verified, including signal acquisition parameters, signal verification rules, and a list of counterpart components to be verified.

[0030] In practice, before performing rapid verification of vehicle signals and component status, the verification agent first obtains the verification configuration information for the vehicle to be verified. The vehicle to be verified can be a vehicle that has already completed body assembly and is ready for power-on, or a prototype vehicle in the intelligent driving system development stage. The verification agent can be independently deployed at the OBD interface, onboard communication gateway, or other locations capable of accessing the vehicle's communication network, enabling the verification agent to enter the vehicle's communication environment and perform verification tasks in advance, without relying on the full functionality of the intelligent driving system being developed.

[0031] Here, the verification configuration information is used to define the verification object, data acquisition method, parsing rules, and judgment criteria for this verification task. Specifically, the verification configuration information may include signal acquisition parameters, signal verification rules, and a list of counterparts to be verified. Among them, the signal acquisition parameters are used to determine how the verification agent acquires signal data from the vehicle to be verified. For example, it may include CAN signal acquisition frequency, CAN FD signal acquisition frequency, vehicle Ethernet signal acquisition frequency, single acquisition trigger conditions, continuous acquisition duration, range of signal IDs to be acquired, communication channel selection information, etc.

[0032] Here, signal verification rules are used to parse and determine the pass / fail status of subsequently acquired raw vehicle signal data. Signal verification rules can include CAN signal parsing rules, CAN FD signal parsing rules, automotive Ethernet signal parsing rules, and corresponding standard thresholds. For example, CAN signal parsing rules can include bit timing parameter rules, sampling point location rules, frame format rules, data length rules, CRC check rules, and signal period rules; automotive Ethernet signal parsing rules can include message format rules, transmission rate rules, data interaction logic rules, and link status rules. Standard thresholds can include signal response timeout thresholds, signal period deviation thresholds, message loss thresholds, and status code anomaly judgment rules, etc.

[0033] Here, the list of adversary components to be verified is used to identify the intelligent driving system-related components that need to be tested in this verification task. These adversary components can include LiDAR, cameras, domain controllers, brake controllers, steering controllers, cockpit controllers, and other vehicle components that have signal interaction relationships with the intelligent driving system. The list can record information such as the name, communication type, communication channel, corresponding signal ID, normal operating status code, signal interaction frequency, and data transmission format of each adversary component. During subsequent verification, the verification agent can extract the corresponding adversary component status information from the vehicle signal analysis results based on the list of adversary components to be verified, and determine whether the corresponding adversary component is powered on normally, whether it has established effective signal interaction with the intelligent driving system, and whether there are communication failures or abnormal data formats.

[0034] In practical implementation, verification configuration information can be configured through the local operating interface of the verification agent. This local interface can include a touchscreen, physical buttons, or other human-machine interface components, allowing developers to input or select signal acquisition frequency, verification commands, standard thresholds, and a list of devices to be verified on-site. Verification configuration information can also be configured remotely. For example, developers can establish a 4G, 5G, WiFi, or wired communication connection with the verification agent via a computer, mobile phone, or debugging terminal, and then remotely send verification configuration information. In this way, the verification agent can meet both the needs of rapid on-site verification and the needs of remote debugging and remote data interaction.

[0035] In some embodiments, after receiving the verification parameters input by the R&D personnel, the verification Agent performs format and integrity checks on the verification parameters. For example, the verification Agent can determine whether the signal acquisition frequency is within a preset allowable range, whether the signal verification rule matches the currently accessed communication network type, and whether the list of peer devices to be verified contains necessary information such as the peer device name, communication channel, and status determination rules. When the verification parameters meet the preset configuration requirements, the verification Agent generates verification configuration information based on the verification parameters and stores the verification configuration information in the storage module; when the verification parameters are missing or do not meet the preset configuration requirements, the verification Agent can output a configuration error message through the local operation interface or remote terminal to prompt the R&D personnel to supplement or modify the verification parameters.

[0036] S102. Based on the signal acquisition parameters, collect the original vehicle signal data from the vehicle communication network of the vehicle to be verified. The original vehicle signal data includes vehicle bus signal data and vehicle Ethernet signal data.

[0037] In practice, after obtaining the verification configuration information for the vehicle to be verified, the verification agent collects raw vehicle signal data from the vehicle's in-vehicle communication network based on the signal acquisition parameters in the verification configuration information. The in-vehicle communication network can include a vehicle bus network and an in-vehicle Ethernet network. The vehicle bus network can be a CAN network or a CAN FD network, and the in-vehicle Ethernet network can be 100BASE-T1, 1000BASE-T1, or other in-vehicle Ethernet communication networks. The raw vehicle signal data includes both vehicle bus signal data and in-vehicle Ethernet signal data, allowing the verification agent to simultaneously cover both traditional in-vehicle bus communication links and high-speed Ethernet communication links.

[0038] Specifically, the verification agent can access the vehicle's in-vehicle communication network through a communication interface module. The communication interface module may include at least one of a CAN bus interface, a CAN FD interface, an in-vehicle Ethernet interface, and an OBD interface.

[0039] The CAN bus interface or CAN FD interface is used to establish a communication connection with the vehicle bus network of the vehicle under test. The vehicle Ethernet interface is used to establish a communication connection with the vehicle Ethernet network of the vehicle under test. The OBD interface can be used to verify the power supply connection and backup communication connection between the Agent and the vehicle under test. The communication interface module is bidirectionally connected to the core processing module. The raw vehicle signal data collected by the communication interface module can be transmitted to the core processing module in real time, so that the core processing module can run subsequent signal analysis, signal response verification, and device status detection logic.

[0040] Here, when collecting vehicle bus signal data, the verification agent can monitor or actively collect signals in the CAN network or CAN FD network according to the vehicle bus acquisition frequency, target signal ID range, communication channel, and acquisition duration set in the signal acquisition parameters. Vehicle bus signal data can include signal ID, frame format, data length, data fields, transmission rate, signal period, timestamp, sending node information, and status codes fed back to the counterpart. The frame format can include standard frames or extended frames, the data length can be used to determine whether the message payload conforms to the communication protocol requirements, the timestamp can be used for subsequent calculation of signal response time and signal interaction frequency, and the status code can be used to subsequently determine the working status of the corresponding counterpart.

[0041] Furthermore, when collecting in-vehicle Ethernet signal data, the verification agent can collect packets from the in-vehicle Ethernet network according to the Ethernet collection frequency, target packet type, target IP address or port, collection duration, and link channel set in the signal collection parameters. In-vehicle Ethernet signal data can include information such as Ethernet packet format, transmission rate, link status, source address, destination address, packet length, data content, communication timestamp, and data interaction relationships.

[0042] In some embodiments, signal acquisition parameters may include continuous acquisition parameters and triggered acquisition parameters. Continuous acquisition parameters control the verification agent to continuously acquire vehicle bus signal data and in-vehicle Ethernet signal data at a preset frequency, thereby obtaining the continuous communication status of the vehicle under test during power-on, static debugging, or operation. Triggered acquisition parameters are used for precise single-shot or short-cycle acquisition in specific verification scenarios. For example, after sending a braking verification command, steering verification command, or perception sensor trigger command, the verification agent acquires the corresponding signal response data within a preset time window.

[0043] In some embodiments, when the verification agent collects raw signal data from the vehicle, it can add a collection identifier to each piece of collected signal data. The collection identifier may include the collection time, communication network type, communication channel, signal source, signal ID, or message identifier.

[0044] In some embodiments, after completing the acquisition of raw vehicle signal data, the verification agent sends the acquired vehicle bus signal data and in-vehicle Ethernet signal data to the automated parsing submodule, and simultaneously stores the raw vehicle signal data in the storage module. The storage module can classify and store the raw vehicle signal data according to the acquisition task number, vehicle identification information, acquisition time, and communication network type, so as to facilitate subsequent traceability analysis, report generation, or secondary verification comparison.

[0045] S103. According to the signal verification rules, the original vehicle signal data is automatically parsed to obtain the vehicle signal parsing result, and abnormal signal data is determined based on the vehicle signal parsing result.

[0046] In practice, after collecting the raw vehicle signal data, the verification agent automatically parses the data according to pre-configured signal verification rules to obtain the vehicle signal parsing results. Based on these results, abnormal signal data is identified. The signal verification rules can be pre-stored in the verification agent's storage module or configured or updated by R&D personnel through a local interface or remote terminal. These rules can include vehicle bus signal verification rules and in-vehicle Ethernet signal verification rules to adapt to different communication data in the vehicle bus network and in-vehicle Ethernet network, respectively.

[0047] Specifically, when the raw vehicle signal data includes vehicle bus signal data, the verification agent invokes vehicle bus signal verification rules to parse the vehicle bus signal data. These rules can include CAN signal parsing rules and CAN FD signal parsing rules. The verification agent can perform field splitting, format identification, and parameter extraction on the vehicle bus signal data based on signal ID, frame format, data length, data fields, transmission rate, signal period, timestamp, and sending node information, thereby obtaining the corresponding bus signal parsing results.

[0048] Here, when parsing CAN or CAN FD signals, the verification agent can verify whether the bit timing parameters, sampling point positions, frame formats, data lengths, CRC check results, and signal periods of the corresponding signals meet the signal verification rules. For example, the verification agent can determine whether the sampling point position is within a preset allowable range, whether the frame format is the expected standard or extended frame, whether the data length is consistent with the data length defined in the communication protocol, whether the CRC check result passes, and whether the message period of the same signal ID meets the preset period requirement. If any of the above parsing items does not meet the corresponding rules, the verification agent can mark the corresponding vehicle bus signal data as abnormal signal data and record the reason for the abnormality.

[0049] When the raw vehicle signal data includes in-vehicle Ethernet signal data, the verification agent invokes in-vehicle Ethernet signal verification rules to parse the data. These rules can include message format rules, transmission rate rules, link state rules, source and destination address rules, message length rules, data interaction logic rules, and communication timeout rules. Based on the source address, destination address, message type, message length, data content, and communication timestamp in the Ethernet message, the verification agent can determine the message format, transmission rate, link state, and data interaction relationship of the in-vehicle Ethernet signal, obtaining the corresponding Ethernet signal parsing results.

[0050] When parsing vehicular Ethernet signal data, the verification agent can determine whether the message format meets the preset requirements, whether the transmission rate meets the rate requirements of the corresponding vehicular Ethernet link, whether the link status is in a normal connection state, and whether the data interaction order and content between target devices conform to the preset interaction logic. If there are errors such as incorrect message format, abnormal transmission rate, link interruption, message loss, abnormal data interaction order, or incorrect data interaction content, the verification agent can mark the corresponding vehicular Ethernet signal data as abnormal signal data and record the corresponding abnormality type, abnormal time, and abnormal communication object.

[0051] In some embodiments, the vehicle signal analysis results may include bus signal analysis results, Ethernet signal analysis results, and comprehensive analysis results. Specifically, the bus signal analysis results may include the signal ID, frame format, data length, transmission rate, signal period, verification result, and status code analysis result for each vehicle bus signal; the Ethernet signal analysis results may include the source address, destination address, message format, transmission rate, link status, data interaction content, and interaction time for each Ethernet message; and the comprehensive analysis results can be used to characterize whether there are communication anomalies, format anomalies, or data anomalies in the overall vehicle communication network.

[0052] In some embodiments, when identifying abnormal signal data, the verification agent can compare the vehicle signal parsing results with standard thresholds in the signal verification rules. Standard thresholds may include signal response timeout thresholds, signal period deviation thresholds, transmission rate thresholds, message loss thresholds, data length allowable ranges, status code allowable ranges, and link status determination rules, etc. If any parsing parameter in the vehicle signal parsing results does not meet the corresponding standard threshold, the verification agent determines that the original signal data corresponding to that parsing parameter is abnormal signal data.

[0053] In some embodiments, the verification agent can also classify and label abnormal signal data. Abnormal categories can include signal missing anomalies, frame format anomalies, data length anomalies, CRC check anomalies, signal period anomalies, transmission rate anomalies, message format anomalies, link status anomalies, data interaction logic anomalies, and status code anomalies. The verification agent can generate an anomaly record for each abnormal signal data entry. The anomaly record includes the anomaly category, anomaly occurrence time, communication network type, communication channel, signal ID or message identifier, anomaly parameter value, and corresponding standard threshold.

[0054] In some embodiments, the verification agent can associate abnormal signal data with a list of adversary devices to be verified. For example, when the signal ID or message identifier corresponding to the abnormal signal data belongs to a certain adversary device to be verified, the verification agent can establish an association between the abnormal signal data and the corresponding adversary device. Therefore, during subsequent adversary device status detection, the abnormal signal data can be used to determine whether the corresponding adversary device has a communication failure, abnormal status feedback, or abnormal data format, thereby improving the accuracy of adversary device anomaly location.

[0055] S104. Send an intelligent driving system verification command to the vehicle communication network, and collect the signal response data returned by the vehicle to be verified in response to the intelligent driving system verification command. Based on the signal response data and the vehicle signal analysis result, determine the vehicle signal response verification result.

[0056] In practice, after collecting and automatically parsing the raw signal data of the entire vehicle, the verification agent sends a driving system verification command to the vehicle's onboard communication network and collects the signal response data returned by the vehicle in response to the verification command. The driving system verification command is used to simulate the interaction commands issued by the intelligent driving system to relevant controllers, sensors, or actuators in the vehicle environment. This allows for early verification of whether the vehicle's communication link and signal response logic meet design requirements, even before the intelligent driving system has completed full-function development.

[0057] Specifically, the verification agent can determine the intelligent driving system verification commands to be sent based on the verification configuration information. These verification commands can include steering signal verification commands, braking signal verification commands, sensor trigger signal verification commands, domain controller communication verification commands, and other verification commands related to the vehicle's overall intelligent driving system functions. Different types of intelligent driving system verification commands can correspond to different communication networks and target objects. For example, braking signal verification commands can be sent to the brake controller via the vehicle bus network, steering signal verification commands can be sent to the steering controller via the vehicle bus network, and sensor trigger signal verification commands can be sent to the LiDAR, camera, or domain controller via the in-vehicle Ethernet network.

[0058] Here, before sending the intelligent driving system verification command, the verification agent can encapsulate the intelligent driving system verification command according to the verification configuration information. The encapsulation content can include the command type, target communication channel, target signal ID or target message identifier, target device identifier, command data content, number of transmissions, transmission interval, and response acquisition time window. For verification commands sent through the vehicle bus network, the verification agent can generate the corresponding bus message according to the preset CAN or CAN FD frame format; for verification commands sent through the vehicle Ethernet network, the verification agent can generate the corresponding Ethernet message according to the preset vehicle Ethernet message format.

[0059] Here, after sending the intelligent driving system verification command, the verification agent collects the signal response data returned by the vehicle to be verified in response to the verification command through the signal acquisition submodule. The signal response data may include response time, response signal ID, response message identifier, response data content, response status code, number of responses, response cycle, response link status, and response stability data. The response time can be determined based on the timestamp of the intelligent driving system verification command's transmission and the timestamp of the corresponding response signal's reception; the response data content can be used to determine whether the data returned by the vehicle to be verified is consistent with the expected response content; the response status code can be used to determine whether the target controller or actuator is in normal working condition; and the response cycle and number of responses can be used to determine whether the corresponding signal response is stable.

[0060] In some embodiments, the verification agent can establish a command response association record based on the correspondence between the verification command and signal response data of the intelligent driving system. The command response association record may include the verification command type, sending time, target communication network, target device, target signal ID or target message identifier, actual response time, actual response content, and response status.

[0061] Furthermore, after collecting the signal response data, the verification agent determines the vehicle signal response verification result based on the signal response data and the vehicle signal parsing results. Specifically, the verification agent can determine whether the signal response data meets the corresponding communication format requirements based on the vehicle signal parsing results, and then determine the response speed, accuracy, and stability of the vehicle to be verified in response to the intelligent driving system verification commands based on the signal response data. Response speed can be determined by comparing the response time with the signal response timeout threshold; response accuracy can be determined by comparing the actual response data content with the preset response content or expected status code; response stability can be determined by the periodic consistency of the corresponding response data after sending the same verification command multiple times, the number of responses, and packet loss.

[0062] In some embodiments, when the response time of the signal response data exceeds the signal response timeout threshold, the verification agent determines that there is a response timeout anomaly; when the response content in the signal response data is inconsistent with the preset response content, or the response status code is not within the normal status code range, the verification agent determines that there is a response data error anomaly; when the same intelligent driving system verification command is sent multiple times in a row, and there is response loss, response cycle fluctuation exceeding the preset range, or intermittent interruption of the response link, the verification agent determines that there is a response stability anomaly.

[0063] It should be noted that the above-mentioned response timeout anomalies, response data error anomalies, and response stability anomalies can all be written into the vehicle signal response verification results as vehicle signal response anomalies.

[0064] In some embodiments, the vehicle signal response verification result may include verification instruction information, response pass / fail judgment result, abnormal response details, and abnormal location information. The verification instruction information may include instruction type, sending time, target communication network, and target counterpart; the response pass / fail judgment result can be used to characterize whether the vehicle under verification responds normally to the corresponding intelligent driving system verification instruction; the abnormal response details may include abnormal type, abnormal occurrence time, abnormal signal ID or abnormal message identifier, actual response parameters, and corresponding standard threshold; the abnormal location information can be used to identify the communication channel, controller, or counterpart corresponding to the abnormal response.

[0065] In some embodiments, the verification agent can also perform correlation analysis between the vehicle signal response verification results and the aforementioned abnormal signal data.

[0066] For example, if the response to a certain braking signal verification command times out, and the vehicle signal analysis results show abnormalities in the cycle or status code of the brake controller-related signals, the verification agent can associate the abnormal response with the abnormalities in the brake controller-related signals, so as to provide a clearer root cause of the problem in the subsequent standardized verification report.

[0067] For example, when the response data corresponding to the verification command triggered by a certain sensing sensor is missing, and there is an anomaly of link interruption or message loss in the vehicle Ethernet signal parsing result, the verification agent can locate the response anomaly to the corresponding Ethernet communication link or the target sensing device.

[0068] S105. Based on the list of counterpart components to be verified, extract the counterpart component status information corresponding to each counterpart component to be verified from the vehicle signal analysis result, and determine the counterpart component status detection result based on the counterpart component status information.

[0069] In practice, after obtaining the vehicle signal analysis results, the verification agent extracts the corresponding counterpart status information from the counterpart list based on the vehicle signal analysis results, and determines the counterpart status detection result based on the counterpart status information. The counterparts to be verified can be vehicle components that have signal interaction relationships with the intelligent driving system, such as LiDAR, cameras, domain controllers, brake controllers, steering controllers, cockpit controllers, or other sensors and actuators. By extracting and judging the status information of each counterpart, abnormal power-on, communication, or signal interaction of counterparts can be detected in advance before the full functionality of the intelligent driving system is developed.

[0070] Specifically, the list of adversary components to be verified can record the adversary component identifier, adversary component name, communication network type, communication channel, corresponding signal ID or message identifier, normal operating status code, signal interaction frequency, data transmission format, and status determination rules for each adversary component to be verified. The verification agent can, based on the list of adversary components to be verified, match the corresponding signal ID, message identifier, communication channel, or communication address from the vehicle signal analysis results with each adversary component to be verified, thereby extracting the status information belonging to the corresponding adversary component from the vehicle signal analysis results.

[0071] In some embodiments, the device status information may include at least one of the following: device power-on status, communication connection status, operating status code, signal interaction frequency, data transmission format, message transmission period, message reception status, link status, and anomaly feedback information. For example, for a brake controller or steering controller that communicates via a vehicle bus network, the verification agent can extract the status code, message period, data length, and CRC check result under the corresponding signal ID from the vehicle bus signal parsing results; for a LiDAR, camera, or domain controller that communicates via an in-vehicle Ethernet network, the verification agent can extract the link status, message format, transmission rate, and data interaction content under the corresponding source address, destination address, or message identifier from the in-vehicle Ethernet signal parsing results.

[0072] In some embodiments, the verification agent may pre-store a database of competitor signal features. This database may include signal features of various intelligent driving system-associated competitors under normal operating conditions, such as normal operating status codes, normal power-on feedback signals, preset signal interaction frequencies, preset message formats, preset data lengths, normal communication link states, and normal data interaction sequences. After extracting competitor status information, the verification agent can match this information with the corresponding competitor signal features in the database to determine whether the competitor to be verified is in a normal operating state.

[0073] Here, when determining whether a peer device is powered on normally, the verification agent can determine its power-on status based on the corresponding peer device's power-on feedback signal, status code, or initialization message. If no power-on feedback signal is collected from the corresponding peer device within a preset time, or if the extracted status code indicates a power-off, initialization failure, or fault state, the verification agent can determine that the peer device to be verified has an abnormal power-on status and record the abnormal peer device name, the time of the abnormality, the abnormal status code, and the corresponding communication channel.

[0074] Here, when determining whether a counterparty has established a valid signal interaction with the intelligent driving system, the verification agent can make a judgment based on the corresponding counterparty's signal interaction frequency, message sending period, message receiving status, and data interaction order. When the corresponding counterparty's signal interaction frequency is lower than a preset frequency threshold, the message sending period deviates from a preset period range, the target message is not received for multiple consecutive acquisition periods, or the data interaction order does not conform to the preset interaction logic, the verification agent can determine that the counterparty to be verified has a signal interaction anomaly. This signal interaction anomaly can include communication interruption, communication delay, message loss, incorrect interaction order, or abnormal interaction content.

[0075] Here, when determining whether a peer device has an abnormal data transmission format, the verification agent can compare the extracted data transmission format, data length, message format, and verification result with the preset formats in the peer device's signal feature library. When the data length is inconsistent, the message format is incorrect, the field position does not match, the CRC check fails, or the status field value is not within the preset allowed range, the verification agent can determine that the corresponding peer device to be verified has an abnormal data transmission format and associate the abnormality with the corresponding signal ID or message identifier.

[0076] In some embodiments, the verification agent can also combine the vehicle signal response verification results to make a joint judgment on the status of the device.

[0077] For example, when a brake signal verification command is sent to the brake controller, if the vehicle signal response verification result shows a response timeout and the device status information shows that the brake controller status code is abnormal or the corresponding message is lost, then the verification agent can determine that the brake controller has a communication failure or an abnormal working state.

[0078] For example, when a trigger signal verification command is sent to a perception sensor, and the vehicle Ethernet signal parsing result shows that the corresponding sensor link is interrupted, the verification agent can determine that the Ethernet signal interaction between the perception sensor and the intelligent driving system is abnormal. Through joint judgment, the accuracy of locating abnormalities in hand components can be improved.

[0079] In some embodiments, the status detection results of the peer device may include the status detection conclusions of each peer device to be verified, details of abnormal peer devices, and root cause information. The status detection conclusions can be used to characterize whether each peer device to be verified is powered on normally, communicates normally, provides normal feedback, and meets data interaction requirements. Details of abnormal peer devices may include the name of the abnormal peer device, the type of abnormality, the time of the abnormality, the abnormal signal ID or abnormal message identifier, the abnormal status code, and the abnormal communication channel. The root cause information can be determined based on the type of abnormality and the analysis results of associated signals, such as loose wiring, communication link interruption, abnormal status code, incorrect message format, software logic abnormality, or protocol configuration mismatch.

[0080] In some embodiments, the verification agent can classify and store the status detection results of the adversary device according to the adversary device type, communication network type, or severity of the anomaly. For example, status detection records can be formed for sensor-type adversaries, controller-type adversaries, and actuator-type adversaries respectively, and anomaly classification records can be formed for CAN communication anomalies, Ethernet communication anomalies, status code anomalies, and data format anomalies respectively.

[0081] S106. Integrate the abnormal signal data, the vehicle signal response verification results, and the device status detection results to generate vehicle signal and device status verification results.

[0082] In practice, after identifying abnormal signal data, vehicle signal response verification results, and component status detection results, the verification agent integrates these data to generate vehicle signal and component status verification results. These results are used to centrally characterize the communication signal status of the vehicle under verification, the intelligent driving system command response status, and the working status of each component under verification during this verification task. This allows R&D personnel to quickly locate abnormal issues based on unified verification results.

[0083] Specifically, the verification agent can first process the abnormal signal data to obtain signal parsing anomaly information. This information can include the communication network type, communication channel, signal ID or message identifier, anomaly occurrence time, anomaly type, actual parsing parameter values, and corresponding standard thresholds. Anomaly types can include signal missing anomalies, frame format anomalies, data length anomalies, CRC check anomalies, signal period anomalies, transmission rate anomalies, message format anomalies, link status anomalies, data interaction logic anomalies, and status code anomalies, among others.

[0084] Here, the verification agent can also organize the vehicle signal response verification results to obtain response verification information. This information can include the instruction type of the intelligent driving system verification command, the target communication network, the target counterpart, the instruction sending time, the actual response time, the preset response timeout threshold, the actual response content, the preset response content, the response pass / fail judgment result, and details of abnormal responses. When there is a response timeout, incorrect response data, lost response, or abnormal response stability, the verification agent can write the corresponding abnormal response record into the response verification information and associate it with the relevant signal ID, message identifier, or target counterpart.

[0085] Furthermore, the verification agent can also organize the peer device status detection results to obtain a summary of peer device status information. This summary can include the name of each peer device to be verified, communication network type, communication channel, power-on status, communication connection status, operating status code, signal interaction frequency, data transmission format, status detection conclusion, and details of abnormal peer devices. For peer devices with abnormal status, the agent can further record the anomaly type, anomaly status code, anomaly occurrence time, anomaly communication channel, associated anomaly signals, and root cause information. The root cause information can be determined based on the correlation between anomaly signal data, signal response verification results, and peer device status detection results, such as communication link interruption, wiring abnormality, status code abnormality, message format error, protocol configuration mismatch, or peer device software logic abnormality.

[0086] In some embodiments, the verification agent can associate abnormal signal data, vehicle signal response verification results, and component status detection results based on a unified verification task identifier. The verification task identifier may include verification time, vehicle identification information, intelligent driving system version, verification configuration version, and verification personnel information.

[0087] In some embodiments, the verification agent can perform correlation analysis on the causes of anomalies based on the correspondence between abnormal signal data and the counterpart to be verified, as well as the correspondence between the vehicle signal response verification results and the intelligent driving system verification commands. For example, when the Ethernet link corresponding to a counterpart is interrupted and the intelligent driving system verification command corresponding to that counterpart is not responded to, the verification agent can classify the anomaly as a communication link anomaly of that counterpart; when the CRC check of a CAN signal is abnormal and the corresponding vehicle controller's response data is incorrect, the verification agent can classify the anomaly as a corresponding bus signal transmission anomaly.

[0088] In some embodiments, the verification agent can generate a standardized verification report according to a preset report template, and output the standardized verification report as the verification result of the vehicle signal and component status. The standardized verification report may include basic verification information, signal parsing results, vehicle signal response verification results, component status detection results, anomaly summary information, and rectification suggestion information. Specifically, the basic verification information may include verification time, vehicle identification information, intelligent driving system version, and verification configuration content; the signal parsing results may include the parsing pass rate of CAN signals, CAN FD signals, and vehicle Ethernet signals, as well as details of abnormal signals; the vehicle signal response verification results may include the response pass rate, details of abnormal responses, and corresponding verification instruction information; the component status detection results may include the component normality rate, details of abnormal components, and root causes of problems; and the rectification suggestion information may provide corresponding troubleshooting directions based on the anomaly type and root cause of the problem.

[0089] In some embodiments, rectification suggestion information can be generated based on preset anomaly handling rules. For example, when the anomaly type is communication link interruption, the rectification suggestion information may prompt you to check the corresponding communication harness, interface connection status, or gateway configuration; when the anomaly type is status code anomaly, the rectification suggestion information may prompt you to check the corresponding device's software status, power-on status, or fault diagnosis information; when the anomaly type is message format error, the rectification suggestion information may prompt you to verify the communication protocol version, message definition, or data field configuration.

[0090] In some embodiments, the standardized verification report can be generated in PDF, Excel, or other preset file formats. The verification agent can store the generated standardized verification report to a local storage module, export it via an external storage device, or push it to a remote terminal via 4G, 5G, WiFi, or wired communication. R&D personnel can view real-time verification results through a local operation interface or receive and view the standardized verification report through a remote terminal, thereby meeting different usage needs for on-site verification and remote debugging.

[0091] In some embodiments, the verification results of vehicle signals and counterpart status can also be used for subsequent secondary verification. After the R&D personnel complete the anomaly rectification based on the standardized verification report, the verification agent can re-execute vehicle signal acquisition, automated parsing, vehicle signal response verification, and counterpart status detection based on the same or updated verification configuration information, and compare the regenerated verification results with the verification results before rectification to determine whether the abnormal signals, abnormal responses, or abnormal counterparts have been eliminated.

[0092] See Figure 2The diagram shows a flowchart of another method for verifying the vehicle signal and component status of an intelligent driving system according to an embodiment of this disclosure. The method includes steps S201 to S203, wherein: S201. In response to the secondary verification command after rectification of the anomaly, re-acquire the current verification configuration information.

[0093] S202. Based on the current verification configuration information, re-execute vehicle signal acquisition, automated parsing, vehicle signal response verification, and component status detection.

[0094] S203. Compare the regenerated verification results with the verification results before rectification, and determine whether the anomalies have been eliminated based on the comparison results.

[0095] In practice, after generating the vehicle signal and component status verification results, the verification agent can also respond to secondary verification commands for corrected anomalies, re-executing the verification process to confirm whether the corrected anomalies have been eliminated. Secondary verification commands can be input by R&D personnel through the verification agent's local interface after correcting abnormal signals, responses, or components, or can be issued remotely. By setting up a secondary verification process, the verification agent can quickly complete retesting under the same vehicle, the same verification scenario, or the same anomaly, avoiding the need for R&D personnel to rebuild the test environment and reorganize the verification data.

[0096] Specifically, R&D personnel can rectify anomalies based on the initially generated vehicle signals and the verification results of the peer components. Anomalies may include abnormal vehicle bus signals, abnormal in-vehicle Ethernet signals, abnormal responses to intelligent driving system verification commands, abnormal peer component status, or abnormal peer component signal interaction. Rectification methods may include reconnecting or securing communication harnesses, adjusting in-vehicle network configuration, updating communication protocol versions, modifying peer component software logic, restoring the peer component to its power-on state, and reconfiguring domain controller communication parameters. After rectification, R&D personnel can send a secondary verification command to the verification agent.

[0097] Here, the verification agent responds to the secondary verification command and retrieves the current verification configuration information again. The current verification configuration information can be the verification configuration information used during the initial verification, or it can be the verification configuration information adjusted by the developers based on the rectification situation.

[0098] For example, when the initial verification finds that the LiDAR Ethernet signal interaction is interrupted, the secondary verification can use the Ethernet signal acquisition frequency, signal verification rules and LiDAR device configuration from the initial verification. When the communication protocol version or target signal ID changes during the rectification process, the R&D personnel can update the corresponding signal verification rules, the range of signals to be acquired or the list of devices to be verified, and the verification Agent can reread the updated current verification configuration information.

[0099] In some embodiments, when the verification agent re-acquires the current verification configuration information, it can prioritize reading the verification configuration version saved in the initial verification task and use that version as the baseline configuration for the secondary verification. The verification agent can also perform a consistency check between the current verification configuration information and the verification configuration information before rectification to determine whether the secondary verification is comparable to the initial verification. When there are differences between the current verification configuration information and the verification configuration information before rectification, the verification agent can record the differences, such as changes in collection frequency, verification threshold, target signal ID, or the list of counterparties to be verified, for explanation during subsequent comparison of verification results.

[0100] Furthermore, after re-acquiring the current verification configuration information, the verification agent re-executes vehicle signal acquisition, automated parsing, vehicle signal response verification, and counterpart status detection based on the current verification configuration information. Specifically, the verification agent can re-acquire raw vehicle signal data from the vehicle's in-vehicle communication network according to the current signal acquisition parameters; automatically parse the re-acquired raw vehicle signal data according to the current signal verification rules, and re-determine whether there is any abnormal signal data; re-send verification commands to the in-vehicle communication network according to the current intelligent driving system verification commands, and acquire the corresponding signal response data; and re-extract the counterpart status information of each counterpart to be verified according to the current counterpart list, and re-determine the counterpart status detection results.

[0101] In some embodiments, to improve the efficiency of secondary verification, the verification agent can determine the scope of secondary verification based on the anomalies before rectification. For example, when the anomalies before rectification only involve the automotive Ethernet communication link of a certain competitor, the verification agent can focus on collecting the Ethernet packets corresponding to that competitor during secondary verification and perform signal response verification and status detection related to that competitor. When the anomalies before rectification involve the periodicity of a certain CAN signal, the verification agent can focus on collecting the signal ID corresponding to that CAN signal and determine whether its period has recovered to a preset range. This can shorten the secondary verification time while ensuring the accuracy of the retest.

[0102] After regenerating the verification results, the verification agent compares the regenerated results with the original results and determines whether the anomalies have been eliminated based on the comparison. The comparison objects can include abnormal signal data, vehicle signal response verification results, component status detection results, and root cause information. For abnormal signal data, the verification agent can compare the anomaly type, number of anomalies, anomaly occurrence time, actual parameter values, and standard thresholds corresponding to the same signal ID or message identifier before and after rectification. For vehicle signal response verification results, the verification agent can compare the response time, response content, response status code, and response stability corresponding to the same intelligent driving system verification commands before and after rectification. For component status detection results, the verification agent can compare the power-on status, communication connection status, operating status code, signal interaction frequency, and data transmission format of the same components before and after rectification.

[0103] In some embodiments, when signal data marked as abnormal before rectification no longer shows the corresponding abnormality in the secondary verification result, or when its parsing parameters recover to the standard threshold range, the verification agent determines that the corresponding signal abnormality has been eliminated. When a smart driving system verification command marked as having an abnormal response before rectification can return the correct response content within the signal response timeout threshold in the secondary verification, and multiple responses meet the stability requirements, the verification agent determines that the corresponding vehicle signal response abnormality has been eliminated. When a counterpart component marked as having an abnormal status before rectification can power on and communicate normally in the secondary verification, and its status code, signal interaction frequency, and data transmission format all meet the requirements in the counterpart component signal feature library, the verification agent determines that the corresponding counterpart component status abnormality has been eliminated.

[0104] In some embodiments, if the regenerated verification result still contains anomalies from before the rectification, the verification agent can determine that the anomaly has not been eliminated, retain the original anomaly record, and update the actual anomaly parameters in the secondary verification. If the regenerated verification result no longer contains anomalies from before the rectification, but new anomaly signals, responses, or device states appear, the verification agent can mark the original anomalies as eliminated and separately mark the newly appearing anomalies as new anomalies. This allows developers to distinguish whether the rectification was effective and whether new communication or status issues were introduced during the rectification process.

[0105] In some embodiments, the verification agent can generate a secondary verification result report based on the comparison results. The secondary verification result report may include anomalies before rectification, retest results after rectification, anomaly elimination status, details of unresolved anomalies, details of newly added anomalies, and retest conclusions. Anomaly elimination status may include eliminated, not eliminated, and newly added anomalies. For eliminated anomalies, the secondary verification result report may record their abnormal behavior before rectification and normal parameters after rectification; for unresolved anomalies, the report may record the reasons for their continued abnormality or suggestions for further investigation; for newly added anomalies, the report may record the signal ID, message identifier, device name, or communication channel corresponding to the new anomaly.

[0106] This disclosure provides a method for verifying the status of vehicle signals and components in an intelligent driving system. It utilizes an independently deployed verification agent to automatically collect, analyze, and verify vehicle CAN signals, in-vehicle Ethernet signals, and component status information. Based on the verification results, a standardized report is generated. This method enables early detection of abnormal vehicle signal responses and component communication anomalies in the early stages of intelligent driving system development, reducing manual analysis workload, minimizing human error, and improving the efficiency of vehicle signal and component status verification. Furthermore, it facilitates rapid identification of the root cause of problems and subsequent rectification by R&D personnel based on standardized verification results.

[0107] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0108] Based on the same inventive concept, this disclosure also provides a verification device for the vehicle signals and device status of an intelligent driving system, corresponding to the verification method for the vehicle signals and device status of the intelligent driving system. Since the principle of the device in this disclosure for solving the problem is similar to the above-mentioned verification method for the vehicle signals and device status of the intelligent driving system in this disclosure, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0109] Please see Figure 3 , Figure 3 This is a schematic diagram of a verification device for vehicle signals and component status in an intelligent driving system, provided as an embodiment of this disclosure. Figure 3 As shown in the figure, the verification device 300 for verifying the vehicle signals and component status of the intelligent driving system provided in this embodiment includes: The data acquisition module 310 is used to acquire the verification configuration information for the vehicle to be verified. The verification configuration information includes signal acquisition parameters, signal verification rules, and a list of counterpart components to be verified.

[0110] The data acquisition module 320 is used to acquire raw vehicle signal data from the vehicle communication network of the vehicle to be verified based on the signal acquisition parameters. The raw vehicle signal data includes vehicle bus signal data and vehicle Ethernet signal data.

[0111] The data parsing module 330 is used to automatically parse the original vehicle signal data according to the signal verification rules, obtain the vehicle signal parsing result, and determine abnormal signal data based on the vehicle signal parsing result.

[0112] The response verification module 340 is used to send a smart driving system verification command to the vehicle communication network, collect the signal response data returned by the vehicle to be verified in response to the smart driving system verification command, and determine the vehicle signal response verification result based on the signal response data and the vehicle signal parsing result.

[0113] The opponent component detection module 350 is used to extract the opponent component status information corresponding to each opponent component to be verified from the vehicle signal parsing result according to the list of opponent components to be verified, and to determine the opponent component status detection result based on the opponent component status information.

[0114] The verification result determination module 360 ​​is used to integrate the abnormal signal data, the vehicle signal response verification result, and the device status detection result to generate the vehicle signal and device status verification result.

[0115] The processing flow of each module in the device and the interaction flow between each module can be referred to the relevant descriptions in the above method embodiments, and will not be detailed here.

[0116] This disclosure provides a verification device for vehicle signals and device status in an intelligent driving system. It uses an independently deployed verification agent to automatically collect, analyze, and verify vehicle CAN signals, in-vehicle Ethernet signals, and device status information. Based on the verification results, a standardized report is generated. This device can detect abnormal vehicle signal response and device communication in the early stages of intelligent driving system development, reducing manual analysis workload, minimizing human error, and improving the efficiency of vehicle signal and device status verification. It also facilitates rapid identification of the root cause of problems and implementation of corrective measures by R&D personnel based on standardized verification results.

[0117] Corresponding to Figure 1 and Figure 2 The present disclosure also provides an electronic device 400 for verifying the vehicle signals and device status of the intelligent driving system. Figure 4 The diagram shown is a structural schematic of an electronic device 400 provided in an embodiment of this disclosure, including: Processor 41, memory 42, and bus 43; memory 42 is used to store execution instructions, including main memory 421 and external memory 422; the main memory 421, also called internal memory, is used to temporarily store the computational data in processor 41, as well as the data exchanged with external memory 422 such as hard disk. Processor 41 exchanges data with external memory 422 through main memory 421. When the electronic device 400 is running, processor 41 and memory 42 communicate through bus 43, enabling processor 41 to execute... Figure 1 and Figure 2 The steps of the verification method for vehicle signals and component status in the intelligent driving system.

[0118] This disclosure also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program performs the steps of the verification method for vehicle signals and device states of the intelligent driving system described in the above-described method embodiments. The storage medium can be a volatile or non-volatile computer-readable storage medium.

[0119] This disclosure also provides a computer program product, which includes computer instructions. When the computer instructions are executed by a processor, they can perform the steps of the verification method for vehicle signals and device status of the intelligent driving system described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0120] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0121] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this disclosure, it should be understood that the disclosed device and method can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0122] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0123] In addition, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0124] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0125] Finally, it should be noted that the above-described embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.

Claims

1. A method for verifying the vehicle signals and component status of an intelligent driving system, characterized in that, The method for using an authentication agent independently deployed on a vehicle communication interface or in-vehicle communication gateway includes: Obtain the verification configuration information for the vehicle to be verified, including signal acquisition parameters, signal verification rules, and a list of counterpart components to be verified; Based on the signal acquisition parameters, raw vehicle signal data is acquired from the vehicle communication network of the vehicle to be verified. The raw vehicle signal data includes vehicle bus signal data and vehicle Ethernet signal data. According to the signal verification rules, the original vehicle signal data is automatically parsed to obtain the vehicle signal parsing results, and abnormal signal data is determined based on the vehicle signal parsing results. Send an intelligent driving system verification command to the vehicle communication network, and collect the signal response data returned by the vehicle to be verified in response to the intelligent driving system verification command. Based on the signal response data and the vehicle signal analysis results, determine the vehicle signal response verification result. Based on the list of counterparty components to be verified, the counterparty component status information corresponding to each counterparty component to be verified is extracted from the vehicle signal analysis results, and the counterparty component status detection result is determined based on the counterparty component status information. The abnormal signal data, the vehicle signal response verification results, and the device status detection results are integrated to generate vehicle signal and device status verification results.

2. The method according to claim 1, characterized in that, Obtain the verification configuration information for the vehicle to be verified, specifically including: Receive verification parameters configured by R&D personnel through a local operating interface or remote terminal; The verification parameters include at least the vehicle bus signal acquisition frequency, the vehicle Ethernet signal acquisition frequency, the signal standard threshold, the intelligent driving system verification command, the signal response timeout threshold, and the list of counterparts to be verified. The verification configuration information is generated based on the verification parameters, and the verification configuration information is stored in the storage module of the verification Agent.

3. The method according to claim 1, characterized in that, Based on the signal acquisition parameters, raw vehicle signal data is acquired from the vehicle communication network of the vehicle to be verified, specifically including: The vehicle bus signal data in the vehicle CAN network is acquired through the CAN bus interface. The vehicle bus signal data includes at least one of the following: signal ID, frame format, data length, transmission rate, and device feedback status code. In addition, the vehicle Ethernet signal data in the vehicle Ethernet network is collected through the vehicle Ethernet interface, and the vehicle Ethernet signal data includes at least one of Ethernet message format, transmission rate and data interaction content; The collected raw vehicle signal data is synchronously sent to the automated parsing submodule, and the raw vehicle signal data is stored locally.

4. The method according to claim 1, characterized in that, According to the signal verification rules, the raw vehicle signal data is automatically parsed to obtain the vehicle signal parsing results, specifically including: When the original vehicle signal data includes CAN signal data, the bit timing parameters, sampling point positions, frame formats, and CRC check results of the CAN signal data are parsed according to the CAN signal parsing rules. When the original vehicle signal data includes vehicle Ethernet signal data, the message format, transmission rate and data interaction logic of the vehicle Ethernet signal data are parsed according to the vehicle Ethernet signal parsing rules. The parsed signal parameters are compared with the corresponding standard thresholds, and signal data that does not meet the standard thresholds are marked as abnormal signal data.

5. The method according to claim 1, characterized in that, Sending a smart driving system verification command to the vehicle communication network and collecting signal response data returned by the vehicle to be verified in response to the smart driving system verification command, specifically including: The intelligent driving system verification command to be sent is determined based on the verification configuration information. The intelligent driving system verification command includes at least one of the following: a steering signal verification command, a braking signal verification command, and a perception sensor trigger signal verification command. The intelligent driving system verification command is sent through the vehicle communication network; After sending the intelligent driving system verification command, the system collects the signal response data returned by the vehicle to be verified. The signal response data includes at least one of response time, response data content, and response stability data.

6. The method according to claim 5, characterized in that, Based on the signal response data and the vehicle signal analysis results, the vehicle signal response verification results are determined, specifically including: The response speed, accuracy, and stability of the vehicle to be verified in response to the verification command of the intelligent driving system are determined based on the signal response data. When the response speed does not meet the signal response timeout threshold, the response accuracy does not meet the preset response content requirements, or the response stability does not meet the preset stability requirements, the vehicle signal response is determined to be abnormal. Record the anomaly type, occurrence time, and signal ID corresponding to the vehicle signal response anomaly, and use the recording results as part of the vehicle signal response verification results.

7. The method according to claim 1, characterized in that, Based on the list of counterparts to be verified, the counterpart status information corresponding to each counterpart to be verified is extracted from the vehicle signal analysis results, and the counterpart status detection result is determined based on the counterpart status information, specifically including: Based on the preset counterpart signal feature library, determine the normal working status code, signal interaction frequency and data transmission format of each counterpart to be verified; Extract the status code, signal interaction data, and data transmission format corresponding to each device to be verified from the vehicle signal analysis results; The extracted status code, signal interaction data, and data transmission format are matched with the normal operation status code, the signal interaction frequency, and the data transmission format, respectively. When there is an abnormal status code, interrupted signal interaction, or incorrect data transmission format, determine that the corresponding peer to be verified has an abnormal status, and record the name of the abnormal peer, the type of abnormality, and the root cause of the problem.

8. The method according to claim 1, characterized in that, The abnormal signal data, the vehicle signal response verification results, and the device status detection results are integrated to generate vehicle signal and device status verification results, specifically including: According to the preset report template, the verification basic information, signal analysis results, vehicle signal response verification results, manual component status detection results and rectification suggestions are compiled; Generate a standardized verification report, which includes verification time, vehicle identification information, intelligent driving system version, signal parsing pass rate, abnormal signal details, response pass rate, abnormal response details, normal operation rate of counterparts, abnormal counterparts details, and root cause of the problem. The standardized verification report can be stored locally, exported externally, or pushed remotely in a preset file format.

9. The method according to claim 1, characterized in that, After generating the vehicle signals and the verification results of the counterpart components, the method further includes: In response to the secondary verification command following the rectification of the anomaly, the current verification configuration information is re-acquired; Based on the current verification configuration information, re-execute vehicle signal acquisition, automated parsing, vehicle signal response verification, and component status detection; The regenerated verification results are compared with the verification results before rectification, and the anomalies are determined based on the comparison results.

10. A verification device for vehicle signals and component status of an intelligent driving system, characterized in that, An authentication agent deployed independently at a vehicle communication interface or in-vehicle communication gateway, the device comprising: The data acquisition module is used to acquire the verification configuration information for the vehicle to be verified, including signal acquisition parameters, signal verification rules, and a list of counterpart components to be verified. The data acquisition module is used to acquire raw vehicle signal data from the vehicle communication network of the vehicle to be verified based on the signal acquisition parameters. The raw vehicle signal data includes vehicle bus signal data and vehicle Ethernet signal data. The data parsing module is used to automatically parse the original vehicle signal data according to the signal verification rules, obtain the vehicle signal parsing result, and determine abnormal signal data based on the vehicle signal parsing result; The response verification module is used to send a smart driving system verification command to the vehicle communication network, collect the signal response data returned by the vehicle to be verified in response to the smart driving system verification command, and determine the vehicle signal response verification result based on the signal response data and the vehicle signal parsing result. The counterpart component detection module is used to extract counterpart component status information corresponding to each counterpart component to be verified from the vehicle signal parsing result according to the counterpart component to be verified list, and to determine the counterpart component status detection result based on the counterpart component status information. The verification result determination module is used to integrate the abnormal signal data, the vehicle signal response verification result, and the device status detection result to generate the vehicle signal and device status verification result.

Images