Instrument testing method and device, equipment, storage medium and program product

Abstract

The embodiment of the invention discloses an instrument testing method, device and equipment, a storage medium and a program product, and is applied to the technical field of vehicle testing, and the method comprises the steps: collecting a CAN bus message of an original end controller corresponding to a to-be-tested instrument on a system rack; generating a simulation message based on the CAN bus message; simulating signal input of a preset test scene for the to-be-tested instrument by using the simulation message, and triggering a display function of the to-be-tested instrument to obtain instrument display content; and generating a report based on a comparison result between the instrument display content and the expected display content corresponding to the preset test scene. The simulation message is generated by collecting the CAN bus message of the original end controller of the instrument to be tested on the rack, the instrument function of the instrument to be tested can be triggered by simulating the output of the original end controller in the test scene through the simulation message, and a large number of resources do not need to be input to simulate the vehicle working scene and the real vehicle test on the rack. And various instrument functions of the vehicle instrument can be triggered, so that the test cost is reduced.

Description

Technical Field

[0001] The present application relates to, but is not limited to, the field of vehicle testing technology, and in particular to an instrument testing method, device, equipment, storage medium, and program product. Background Art

[0002] With the rapid development of intelligent vehicles, the functions of automotive instrument clusters are becoming increasingly diverse and complex. Instrument clusters display information related to the powertrain and chassis systems, vehicle control systems, vehicle-to-the-cloud systems, and driving systems. The more information displayed, the higher the probability of failure. Furthermore, instrument clusters serve as a crucial interface for direct communication between the driver and the vehicle. Even a minor problem can lead to user complaints. Therefore, system-level testing of these instruments is crucial.

[0003] However, because the triggering of vehicle instrument functions relies on the output signals of the vehicle's primary controller, related art vehicle instrument testing typically involves simulating operating scenarios on a single test bench to trigger the output signals of the corresponding remote controllers. This approach requires frequent adjustments to various test scenarios, making the testing process cumbersome. Furthermore, some instrument functions can only be triggered under actual vehicle operating conditions, requiring significant investment in the production of actual vehicles for instrument testing, resulting in high testing costs. Summary of the Invention

[0004] In view of this, embodiments of the present application provide at least one instrument testing method, apparatus, device, storage medium, and program product.

[0005] The technical solution of the embodiment of the present application is implemented as follows:

[0006] In one aspect, an embodiment of the present application provides an instrument testing method, the method comprising:

[0007] Collect the CAN bus messages of the primary controller corresponding to the instrument under test on the system test bench;

[0008] Generate a simulation message based on the CAN bus message;

[0009] Using the simulation message to simulate the signal input of a preset test scenario for the instrument under test, triggering the display function of the instrument under test to obtain the instrument display content;

[0010] A report is generated based on a comparison result between the instrument display content and the expected display content corresponding to the preset test scenario.

[0011] In some embodiments of the present application, the step of using the simulation message to simulate a signal input of a preset test scenario for the instrument under test, triggering a display function of the instrument under test to obtain instrument display content, includes:

[0012] Configuring the communication protocol and message format of the original controller for the simulation message based on a preset test scenario to obtain a control instruction;

[0013] The control instruction is transmitted to the signal receiving port of the instrument to be tested through the system stand to obtain the instrument display content of the instrument to be tested.

[0014] The embodiment of the present application ensures that the control instructions can accurately simulate the signal input in the real vehicle environment by accurately configuring the communication protocol and format of the simulation message. Through the standardized transmission of the system test bench, the instrument under test can be tested in a near-real use environment.

[0015] In some embodiments of the present application, configuring the communication protocol and message format of the original controller for the simulation message based on a preset test scenario to obtain a control instruction includes:

[0016] Create corresponding CAN IDs for the engine control unit BMS, reversing radar controller RRS and airbag controller SRS based on the preset test scenarios;

[0017] Analyze the CRC check algorithm logic corresponding to the CAN ID and generate a check rule library corresponding to the CAN ID;

[0018] The control instruction is obtained by correcting the check code of the simulation message through the check rule library.

[0019] The embodiment of the present application ensures that the generated simulation message fully complies with the original factory communication protocol requirements through standardized CAN ID configuration, precise verification algorithm analysis and automated verification code correction.

[0020] In some embodiments of the present application, generating a simulation message based on the CAN bus message includes:

[0021] Extracting a signal value associated with an instrument display function from the CAN bus message;

[0022] The signal value is reconstructed into a simulation message.

[0023] The present embodiment achieves precise simulation of the actual vehicle CAN communication environment by accurately extracting instrument-related signal values ​​and reconstructing them into simulated messages. This enables the system to provide the instrument under test with signal input consistent with the real-world scenario without relying on the actual vehicle, ensuring the comprehensiveness and accuracy of instrument function testing. This method significantly improves test efficiency and reduces the cost of actual vehicle testing. It also covers edge scenarios that are difficult to trigger with traditional manual testing, providing reliable technical support for instrument system-level verification.

[0024] In some embodiments of the present application, extracting the signal value associated with the instrument display function in the CAN bus message includes:

[0025] Filtering specific frame data containing a vehicle speed signal, an engine speed signal, and a fault code signal in the CAN bus message;

[0026] decoding the specific frame data;

[0027] Convert the decoded specific frame data into a signal value in a standardized data format.

[0028] The embodiments of the present application ensure the accuracy and consistency of signal data required for instrument testing by automatically screening specific frame data, accurately decoding original signals, and unifying data format conversion.

[0029] In some embodiments of the present application, decoding the feature frame data includes:

[0030] Parsing the physical quantity unit and data range of a specific frame data according to the communication protocol definition of the original end controller;

[0031] The parsed specific frame data is compared with the preset threshold to verify the validity of the data.

[0032] This embodiment of the application ensures the accuracy and reliability of signal data collected from the CAN bus through a dual guarantee mechanism of precise parsing and threshold verification defined by the protocol. The system can automatically identify and filter abnormal data to prevent incorrect or distorted signal values ​​from affecting instrument function test results.

[0033] In some embodiments of the present application, generating a report based on a comparison result between the instrument display content and the expected display content corresponding to the preset test scenario includes:

[0034] Obtaining difference display analysis data between the instrument display content and the expected display content corresponding to the preset test scenario;

[0035] A standardized report document including test conclusions, defect lists and optimization suggestions is generated based on the display analysis data.

[0036] In some embodiments of the present application, using the simulation message to simulate the signal input of a preset test scenario for the instrument under test includes:

[0037] The simulation message is used to sequentially simulate the signal input of multiple preset test scenarios for the instrument under test, and the predicted test scenarios at least include: simulation test scenarios of the power chassis system, the vehicle control system, and the vehicle-cloud system.

[0038] The embodiments of the present application simulate multiple key test scenarios through simulation messages, so that the instrument under test can complete the functional verification of the power chassis system, vehicle control system and vehicle cloud system in a test bench environment. The system can efficiently cover complex scenarios that are difficult to trigger in a real vehicle, reduce dependence on real vehicle testing, improve test coverage, and at the same time reduce test costs and time consumption.

[0039] On the other hand, an embodiment of the present application provides an instrument testing device, the device comprising:

[0040] The acquisition module is used to collect the CAN bus messages of the primary controller corresponding to the instrument under test on the system test bench;

[0041] A test module, configured to generate a simulation message based on the CAN bus message;

[0042] Using the simulation message to simulate the signal input of a preset test scenario for the instrument under test, triggering the display function of the instrument under test to obtain the instrument display content;

[0043] An output module is used to generate a report based on a comparison result between the instrument display content and the expected display content corresponding to the preset test scenario.

[0044] On the other hand, an embodiment of the present application provides a computer device, including a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the program, it implements some or all of the steps in the above method.

[0045] In another aspect, an embodiment of the present application provides an instrument test system, the system comprising: a computer, a data acquisition and output device, a system bench, and a simulation test engineering panel;

[0046] The data acquisition and output device is connected to the system bench and the computer through hard-wired communication lines; the vehicle electrical components are deployed on the system bench; and the simulation test engineering panel is connected to the computer;

[0047] The simulation test engineering panel is used to configure the instrument test process through the computer;

[0048] The computer is used to test the electrical components of the vehicle on the system stand through the steps of the instrument detection method described in some embodiments of the present application.

[0049] On the other hand, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which implements some or all of the steps in the above method when executed by a processor.

[0050] On the other hand, an embodiment of the present application provides a computer program, including computer-readable code. When the computer-readable code is executed in a computer device, a processor in the computer device executes some or all of the steps for implementing the above method.

[0051] On the other hand, an embodiment of the present application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and when the computer program is read and executed by a computer, implements some or all of the steps in the above method.

[0052] In an embodiment of the present application, simulation messages are generated by collecting CAN bus messages of the primary controller of the instrument to be tested on the test bench. The simulation messages are used to simulate the output of the primary controller in various test scenarios to trigger the instrument functions of the instrument to be tested for instrument testing. There is no need to invest a lot of resources in simulating vehicle working scenarios and actual vehicle testing on the test bench, and various instrument functions of the vehicle instruments can be triggered, thereby reducing testing costs.

[0053] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] The drawings herein are incorporated into and constitute a part of the specification. These drawings illustrate embodiments consistent with the present application and, together with the specification, are used to illustrate the technical solutions of the present application.

[0055] Figure 1 A flow chart of an instrument testing method provided in one embodiment of the present application;

[0056] Figure 2 A schematic diagram of the structure of an instrument testing system provided in one embodiment of the present application;

[0057] Figure 3 A schematic diagram of the principle of an instrument testing method provided in one embodiment of the present application;

[0058] Figure 4 A logic diagram of an instrument testing method provided in one embodiment of the present application;

[0059] Figure 5 This is one of the interface diagrams of an instrument testing method provided in one embodiment of the present application;

[0060] Figure 6 This is a second schematic diagram of an interface of an instrument testing method provided in one embodiment of the present application;

[0061] Figure 7 A schematic diagram of the functional modules of an instrument testing device provided in one embodiment of the present application;

[0062] Figure 8 A schematic diagram of the structure of a computer device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0063] In order to make the purpose, technical solutions and advantages of this application clearer, the technical solutions of this application are further elaborated in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limiting this application. All other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0064] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0065] The terms "first / second / third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It is understandable that "first / second / third" can be interchanged with a specific order or sequence where permitted so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0066] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing this application only and are not intended to limit this application.

[0067] The embodiment of the present application provides an instrument testing method, which can be executed by a processor of a computer device. The computer device may refer to a server, a laptop, a tablet computer, a desktop computer, a smart TV, a set-top box, a mobile device (such as a mobile phone, a portable video player, a personal digital assistant, a dedicated messaging device, a portable gaming device), or other device with instrument testing capabilities. Figure 1 As shown, some embodiments of the present application provide an instrument testing method, which includes:

[0068] Step 101: Collect CAN bus messages of the primary controller corresponding to the instrument to be tested on the system test bench.

[0069] In an embodiment of the present application, a system test bench refers to a test platform built based on the electrical components of a whole vehicle, such as a yellow board test bench or a Labcar test bench, which is used to simulate the whole vehicle environment for instrument function testing. The instrument to be tested refers to an automotive instrument device that requires system-level functional testing. The original end controller refers to a controller related to the instrument display function in the CAN network topology diagram of the whole vehicle, such as the engine controller unit (BMS), the reversing radar controller (RRS), etc., which is responsible for sending control signals through the CAN bus. The CAN bus message refers to a data frame transmitted in the controller area network (CAN) bus, which contains control signals and status information and is used for communication between devices.

[0070] The system connects to the system bench via a data acquisition output device (such as SPY3.0 or Tongxing equipment) to collect real-time message data from the original controller's CAN bus. The data acquisition module records the communication data sent by the original controller, including CAN ID, signal value, and CRC checksum information, providing raw data support for subsequent simulation tests.

[0071] Step 102: Generate a simulation message based on the CAN bus message.

[0072] In the embodiment of the present application, the simulation message refers to an analog signal generated by a simulation device based on the collected original CAN bus message data, which is used to replace the message sent by the real controller.

[0073] The system inputs the collected raw CAN bus messages into the simulation test engineering panel, where they are parsed and processed by the data output module. The simulation test engineering panel adds the source controller's CAN ID to the Tx Panel module and creates functional simulation components in the Graphical panels module. Each component is associated with a specific CAN ID and signal value, generating a simulated message that functions identically to the original message. If the source controller's CAN ID includes a CRC checksum, the system also generates a corresponding CRC checksum simulation project based on industry-standard algorithms to ensure the integrity and accuracy of the simulated message.

[0074] Step 103: Utilize the simulation message to simulate the signal input of a preset test scenario for the instrument under test, trigger the display function of the instrument under test, and obtain instrument display content.

[0075] In this embodiment of the present application, the system generates simulated messages and sends them to the instrument under test via a data output device, simulating the signal input from the original controller in a real vehicle. Based on the received signals, the instrument under test triggers corresponding display functions, such as powertrain chassis system status and vehicle control system warnings. The system monitors the instrument display in real time to ensure that its response is consistent with the simulated message input.

[0076] Specifically, when the display function of the instrument under test depends on the input of a single original-end controller, it is sufficient to directly input a simulated signal input to the instrument under test. If, under a preset test scenario, the triggering of the display function of the instrument under test depends on the input signals of multiple original-end controllers, the timing configuration of the input signals of multiple simulated original-end controllers can be performed with reference to the function-dependent parameter configuration provided by the manufacturer of the instrument under test. Then, when a certain display function needs to be triggered, the timing configuration of the input signal corresponding to the display function is queried. The timing configuration contains the timing information of each original-end controller signal input. The system inputs different remote-controlled input signals to the instrument under test in sequence and at time intervals represented by the timing information, so that the instrument under test can display like the display function is triggered on a real vehicle.

[0077] For example, when a single controller triggers the display function of the instrument under test, the system successfully verifies the digital speed display function by setting the vehicle speed parameters and sending input information to the instrument. At this time, only a single signal input is required to complete the basic function verification.

[0078] When the display function of the instrument under test is triggered collaboratively by multiple controllers, the system determines, based on the parameter configuration provided by the instrument manufacturer, that triggering the instrument display function in energy recovery mode requires coordinated signals from the engine ECU, brake ECU, and battery management ECU. Specifically, these signals include three key parameters: engine torque, brake pedal opening, and battery SOC difference. Signal inputs must adhere to the strict timing sequence of brake signal → torque signal → SOC signal, with the interval between adjacent signals controlled within 50ms ± 10ms. Step 104 generates a report based on the comparison results between the instrument display content and the expected display content corresponding to the preset test scenario.

[0079] In this embodiment, the system automatically compares the actual display content of the instrument under test with the expected display content in a pre-set test scenario. If the display content matches the expected content, the system marks the test case as passed. If not, the system collects relevant data and extracts the problem information, recording it in a report. After the test is completed, the system summarizes the results of all test cases and generates a complete system-level test report for subsequent analysis and improvement.

[0080] The embodiment of the present application generates simulation messages by collecting CAN bus messages of the primary controller of the instrument to be tested on the test bench. The simulation messages simulate the output of the primary controller in various test scenarios to trigger the instrument functions of the instrument to be tested for instrument testing. There is no need to invest a lot of resources in simulating vehicle working scenarios and actual vehicle testing on the test bench, and various instrument functions of the vehicle instruments can be triggered, thereby reducing testing costs.

[0081] In some embodiments, step 101 includes: using the simulation message to sequentially simulate the signal input of multiple preset test scenarios for the instrument under test, and the predicted test scenarios include at least: simulation test scenarios of the power chassis system, the vehicle control system, and the vehicle-cloud system.

[0082] In the embodiments of this application, the power chassis system refers to the system involving the vehicle powertrain (such as the engine and transmission) and chassis control (such as ABS and ESP), which affects the vehicle's driving state. The vehicle control system refers to the vehicle control-related functions (such as door locks, windows, lights, etc.), involving the body electronic control unit (ECU). The vehicle cloud system refers to the data exchange system between the vehicle and the cloud server, involving remote control, OTA upgrades, navigation and other functions.

[0083] The system sends simulation messages to the instrument under test in sequence through the data output device, simulating the signal input of different preset test scenarios. First, the system simulates the test scenarios of the power chassis system, such as engine speed changes, transmission gear switching, or ESP intervention signals. After receiving the simulation message, the instrument under test displays the corresponding power system status information. Then, the system switches to the vehicle control system test scenario, such as door switch status, lighting control signal or air conditioning adjustment command, to verify whether the instrument can respond correctly. Finally, the system simulates the test scenarios of the vehicle cloud system, such as remote start signal, navigation data update or OTA upgrade status, to ensure that the instrument can correctly display the cloud interaction information. The simulation message for each test scenario is configured according to the preset test case to ensure that all key functional points are covered.

[0084] The embodiments of the present application simulate multiple key test scenarios through simulation messages, so that the instrument under test can complete the functional verification of the power chassis system, vehicle control system and vehicle cloud system in a test bench environment. The system can efficiently cover complex scenarios that are difficult to trigger in a real vehicle, reduce dependence on real vehicle testing, improve test coverage, and at the same time reduce test costs and time consumption.

[0085] In some embodiments, step 102 includes:

[0086] Step 1021: extract the signal value associated with the instrument display function in the CAN bus message.

[0087] In this embodiment of the present application, the instrument display function refers to the information function module that needs to be displayed on the vehicle dashboard, such as the speedometer, tachometer, fuel level indicator, fault warning light, etc. The signal value refers to the specific data field in the CAN bus message, which is used to indicate the status or value of a specific function, such as the engine speed value of 2000 rpm.

[0088] The system parses CAN bus messages through the data acquisition module and filters out signal values ​​directly related to the instrument display functions according to predefined communication protocols (such as DBC files). The parsing process includes identifying the CAN message ID, extracting the corresponding signal data, and calculating the actual physical value according to signal definitions (such as start bit, length, scaling factor, and offset). For example, it can extract the speed signal from the CAN message of the engine control unit (ECU) or the door switch status signal from the message of the body control module (BCM). The system ensures that all signal values ​​related to the instrument display are fully extracted, providing an accurate data source for the subsequent generation of simulation messages.

[0089] Step 1022: reconstruct the signal value into a simulation message.

[0090] In an embodiment of the present application, the system repackages the extracted signal value according to the message format requirements of the target simulation device. First, the system determines the CAN ID of the simulation message according to the instrument function requirements to ensure that it is consistent with the communication protocol of the instrument to be tested. Subsequently, the system fills the signal value into the corresponding data segment of the message and adds the necessary control fields (such as CRC check) according to the protocol requirements. For example, when simulating the vehicle speed display, the system will generate a CAN message containing the vehicle speed signal value, whose ID is consistent with the vehicle speed signal ID expected by the instrument, and the data field contains the correct vehicle speed value (such as 60km / h). If the original signal involves verification logic (such as CRC), the system will synchronously generate a verification field to ensure the integrity and correctness of the simulation message. Finally, the system outputs a complete simulation message for subsequent test scenario simulation.

[0091] The present embodiment achieves precise simulation of the actual vehicle CAN communication environment by accurately extracting instrument-related signal values ​​and reconstructing them into simulated messages. This enables the system to provide the instrument under test with signal input consistent with the real-world scenario without relying on the actual vehicle, ensuring the comprehensiveness and accuracy of instrument function testing. This method significantly improves test efficiency and reduces the cost of actual vehicle testing. It also covers edge scenarios that are difficult to trigger with traditional manual testing, providing reliable technical support for instrument system-level verification.

[0092] In some embodiments, step 1021 includes:

[0093] Step 10211, filtering the specific frame data containing the vehicle speed signal, engine speed signal and fault code signal in the CAN bus message.

[0094] In the embodiments of the present application, the engine speed signal is a numerical signal indicating the rotational speed of the engine crankshaft, typically measured in revolutions per minute (rpm). A fault code signal is a diagnostic code indicating a fault condition detected by the vehicle system, typically compliant with the OBD-II standard. Specific frame data refers to a data frame within a CAN bus message containing the specific signal.

[0095] The system uses a data acquisition module to monitor all messages on the CAN bus in real time. Based on predefined communication protocols (such as DBC files), the system identifies and filters specific CAN frames containing vehicle speed, engine speed, and fault code signals. This filtering is based on CAN ID matching and signal mapping confirmation. For example, the system will filter CAN frames with ID 0x123 for vehicle speed, CAN frames with ID 0x456 for engine speed, and CAN frames with ID 0x789 for fault code signals. This filtering process ensures that only critical data frames directly related to the instrument display function are retained, providing a precise data source for subsequent processing.

[0096] Step 10212: Decode the specific frame data.

[0097] In an embodiment of the present application, the system parses and processes the filtered specific frame data. First, the system determines the corresponding decoding rules based on the CAN ID. Then, according to the parameters such as the start bit, length, byte order, scaling factor and offset of the signal in the data frame, the original binary data is converted into actual physical values. For example, for the vehicle speed signal, the system reads 2 bytes starting from the 3rd byte of the data frame, applies the scaling factor 0.1 and the offset 0, and converts the original value 100 to 10.0 km / h. For the fault code signal, the system maps the binary value to a specific fault description according to the standard fault code table. The decoding process ensures that the original data is accurately converted into a usable engineering value.

[0098] Step 10213: Convert the decoded specific frame data into a signal value in a standardized data format.

[0099] In the embodiments of the present application, a standardized data format refers to a data structure organized according to a unified specification, ensuring that signal values ​​from different sources and types have a consistent representation.

[0100] The system converts the decoded data into a unified standardized format. The conversion process includes data type unification (such as conversion to floating point numbers or integers), unit unification (such as speed is unified into km / h, speed is unified into rpm), and data structure standardization (such as using JSON or a specific binary format). For example, the original vehicle speed value of 10.0km / h is converted into the standard format of {"signal_name":"vehicle_speed", "value":10.0, "unit":"km / h"}. For fault codes, the system converts them into structured data of {"signal_name":"fault_code", "value":"P0123", "description":"Throttle position sensor circuit fault"}. Standardization ensures that all signal values ​​have consistent interface specifications, which facilitates direct calling in subsequent simulation test projects.

[0101] The embodiments of the present application ensure the accuracy and consistency of signal data required for instrument testing by automatically screening specific frame data, accurately decoding original signals, and unifying data format conversion.

[0102] In some embodiments, step 10212 includes:

[0103] Step 102121: parse the physical quantity unit and data range of the specific frame data according to the communication protocol definition of the original controller.

[0104] In the present application, the communication protocol definition refers to the data format specification used by the source controller in CAN bus communication, including parameters such as signal position, data type, scaling factor, offset, etc. The physical unit refers to the unit of measurement of the actual physical quantity represented by the signal value, such as km / h (vehicle speed) or rpm (engine speed). The data range refers to the minimum and maximum values ​​allowed for the signal value in a valid state.

[0105] The system parses and processes specific frame data based on the pre-loaded original controller communication protocol (such as DBC file). First, the system identifies the signal definition corresponding to the CAN frame ID and extracts basic information such as the start bit, length (number of bits), and byte order (Intel or Motorola format) of the signal in the data frame. Then, the system applies the scaling factor (scale) and offset (offset) defined in the protocol to convert the original binary value into an engineering value. For example, for the vehicle speed signal, the system reads 16 bits of data starting from the 3rd byte of the data frame, applies a scaling factor of 0.1 and an offset of 0, and converts the original value 100 to 10.0 km / h. At the same time, the system obtains the physical unit (km / h) and valid range (0-300 km / h) of the signal from the protocol to ensure that the parsed data has the correct unit and a reasonable numerical range.

[0106] Step 102122, compare the parsed specific frame data with the preset threshold to verify the validity of the data.

[0107] In the embodiments of the present application, the preset threshold refers to the reasonable range boundary of the signal value pre-set based on system functional requirements and engineering experience. Data validity refers to whether the signal value is within the expected reasonable range and can truly reflect the actual status of the vehicle.

[0108] The system automatically compares and verifies the engineering value obtained through analysis with the preset threshold value. First, the system loads the pre-configured threshold range for each signal, including the minimum value, maximum value, and special status value (such as special coding for fault status). For example, the threshold range of the vehicle speed signal is set to 0-300km / h, and the threshold range of the engine speed signal is set to 0-8000rpm. Then, the system compares the analyzed signal values ​​with the corresponding thresholds one by one. If the signal value is within the threshold range, the system determines that the data is valid; if it exceeds the threshold range or is a special fault code, the system marks the data as abnormal. For abnormal data, the system records the specific out-of-range situation and triggers the corresponding processing flow (such as discarding the data or marking it as a test case failure). The verification process ensures that only valid data that meets expectations will be used in subsequent simulation test links.

[0109] This embodiment of the application ensures the accuracy and reliability of signal data collected from the CAN bus through a dual guarantee mechanism of precise parsing and threshold verification defined by the protocol. The system can automatically identify and filter abnormal data to prevent incorrect or distorted signal values ​​from affecting instrument function test results.

[0110] In some embodiments, step 103 includes:

[0111] Step 1031 : Based on a preset test scenario, the communication protocol and message format of the original controller are configured for the simulation message to obtain a control instruction.

[0112] In an embodiment of the present application, the system calls the corresponding scenario configuration parameters from the test case library according to the needs of the current test scenario. The system first determines the original end controller type (such as engine controller, body controller, etc.) that needs to be simulated, and then loads the corresponding communication protocol definition file (such as DBC file). According to the protocol definition, the system configures the correct frame ID, data length, signal position and other parameters for the simulation message. For example, when simulating the vehicle speed display test scenario, the system configuration frame ID is 0x123, the data length is 8 bytes, and the vehicle speed signal value is placed in the 3rd-4th bytes of the data domain. At the same time, the system adds necessary control fields, such as CRC checksums, according to the protocol requirements. After configuration is complete, the system generates standardized control instructions, which contain complete CAN message data and transmission timing requirements to ensure that the communication behavior of the original end controller can be accurately simulated.

[0113] Step 1032: Transmit the control instruction to the signal receiving port of the instrument under test through the system test bench to obtain the instrument display content of the instrument under test.

[0114] In an embodiment of the present application, the system sends the generated control instructions to the CAN bus of the system test bench through a data output device (such as SPY3.0). The communication module of the system test bench transmits the CAN data frame to the signal receiving port of the instrument to be tested according to the preset timing and baud rate. The transmission process strictly follows the vehicle communication specifications to ensure that the signal timing and electrical characteristics are consistent with the actual vehicle environment. After the instrument to be tested receives the control instruction, its internal processor parses the CAN message, extracts the relevant signal value, and drives the display module to present the corresponding information. For example, when a control instruction containing a vehicle speed signal is received, the instrument will update the displayed value of the speedometer. At the same time, the image acquisition module of the system captures the display screen of the instrument in real time and converts the display content into digital image data for subsequent analysis. The system records the complete test process data, including the timestamp of the control instruction sent and the corresponding instrument response.

[0115] The present embodiment precisely configures the communication protocol and format of the simulation message to ensure that the control instructions can accurately simulate the signal input in the actual vehicle environment. Through standardized transmission of the system test bench, the instrument under test can be tested in a near-real-world environment.

[0116] In some embodiments, the 1031 includes:

[0117] Step 10311: Create corresponding CAN IDs for the engine controller unit BMS, the reversing radar controller RRS, and the airbag controller SRS based on the preset test scenario.

[0118] In the embodiments of this application, the engine management system (BMS) refers to the control module in the vehicle responsible for managing the engine's operating status. The parking sensor controller (RRS) refers to the control module in the vehicle responsible for processing parking sensor signals. The airbag controller (SRS) refers to the control module in the vehicle responsible for managing the airbag system. A CAN ID is a unique identifier used to identify the source and type of data frames in a controller area network (CAN).

[0119] Based on the requirements of the current test scenario, the system extracts the standard CAN ID configuration for each controller from the vehicle communication protocol specification. For the engine management unit (BMS), the system assigns 0x18F00500 as its standard CAN ID; for the rear parking radar controller (RRS), the system assigns 0x18F01000; and for the airbag controller (SRS), the system assigns 0x18F02000. In the simulation test project, the system creates an independent communication channel for each controller to ensure that signal transmissions from each controller do not interfere with each other. This created CAN ID information is stored in the simulation project's configuration database and serves as the basis for subsequent message generation.

[0120] Step 10312: parse the CRC check algorithm logic corresponding to the CAN ID and generate a check rule library corresponding to the CAN ID.

[0121] In the embodiments of the present application, the CRC check algorithm refers to a cyclic redundancy check algorithm used to detect errors in data transmission or storage. The check rule base refers to a database that stores the check algorithm parameters and calculation rules corresponding to each CAN ID.

[0122] The system accesses the manufacturer's communication protocol documentation and parses the CRC checksum algorithm requirements for each CAN ID. For the engine management system (BMS) CAN ID 0x18F00500, the system identifies it as using the CRC-8 algorithm with a polynomial of 0x1D. For the parking sensor (RRS) CAN ID 0x18F01000, the system identifies it as using the CRC-16 algorithm with a polynomial of 0x1021. For the airbag (SRS) CAN ID 0x18F02000, the system identifies it as using the CRC-32 algorithm with a polynomial of 0x04C11DB7. The system stores these checksum algorithm parameters, initial values, and input / output processing rules in a structured manner, establishing a complete checksum rule base. Each record in the rule base contains complete parameters, including the CAN ID, algorithm type, polynomial, initial value, and XOR value.

[0123] Step 10313: Correct the check code of the simulation message through the check rule library to obtain a control instruction.

[0124] In an embodiment of the present application, after the system generates a simulation message, it retrieves the corresponding verification algorithm from the verification rule library according to the CAN ID in the message. The system first extracts the data part that needs to be verified in the message, excluding the verification field itself. Then, bit processing (such as inversion, padding, etc.) is performed according to the requirements of the algorithm, and the polynomial is applied to perform modulo 2 division operations to calculate the verification value. For example, for BMS messages, the system calculates the CRC-8 verification value and fills it into the specified position of the message; for SRS messages, the system calculates the CRC-32 verification value. After the calculation is completed, the system writes the verification code into the verification field of the message to form a complete control instruction that complies with the original factory communication specifications. After the system verifies the correctness of the verification code of the final message, it stores it in the instruction queue to be sent.

[0125] The embodiment of the present application ensures that the generated simulation message fully complies with the original factory communication protocol requirements through standardized CAN ID configuration, precise verification algorithm analysis and automated verification code correction.

[0126] In some embodiments, step 104 includes:

[0127] Step 1041 : Obtain difference display analysis data between the instrument display content and the expected display content corresponding to a preset test scenario.

[0128] In an embodiment of the present application, the system captures the real-time display screen of the instrument to be tested through an image acquisition device and transmits the image data to the analysis module. The analysis module first pre-processes the image, including grayscale, binarization and feature extraction. The system uses a template matching algorithm to compare the actual display content with the pre-stored expected display template pixel by pixel. For the numerical display area, the system performs OCR recognition and compares the numerical difference; for the graphic indication area, the system calculates the shape matching degree and position offset. The comparison process generates structured difference data, including difference element identification, difference type (such as numerical deviation, graphic missing, color error, etc.), and difference quantification value (such as numerical deviation, number of position offset pixels, etc.). The system classifies and stores the difference data according to the test case number to establish a complete difference analysis database.

[0129] Step 1042: Generate a standardized report document including test conclusions, a defect list, and optimization suggestions based on the display analysis data.

[0130] In the embodiments of this application, the test conclusion refers to the overall evaluation conclusion of the test results, including the pass / fail judgment and the overall compliance rate. The defect list refers to a detailed list of confirmed display problems, including the defect location, phenomenon description and severity level. Optimization suggestions refer to specific improvement suggestions for discovered defects. Standardized report documents refer to structured test report files that comply with industry standards, usually in PDF or XML format.

[0131] The system calls the data in the difference analysis database and automatically generates a test document according to the preset report template. The report generation module first counts the pass rate of all test cases and gives the overall test conclusion. For test items with differences, the system extracts the corresponding defect information, including screenshots of the display area where the defect is located, difference values, test timestamps, etc., and classifies and sorts them according to severity (such as Critical / Major / Minor). The system matches the optimization suggestions in the knowledge base according to the defect type. For example, for display delay problems, it is recommended to check the CAN communication cycle, and for graphic dislocation, it is recommended to adjust the UI coordinate parameters. The final generated report contains a complete structure including a cover page, test summary, detailed defect list, optimization suggestions and appendix, and is output as a PDF document that conforms to the ISO standard format. At the same time, structured XML data is generated for subsequent system integration.

[0132] like Figure 2 As shown, a structural diagram of an instrument test system of the present application is provided, wherein the system includes: a computer 10, a data acquisition and output device 20, a system stand 30, and a simulation test engineering panel 40;

[0133] The data acquisition and output device is connected to the system bench and the computer through hard-wired communication lines; the vehicle electrical components are deployed on the system bench; and the simulation test engineering panel is connected to the computer;

[0134] The simulation test engineering panel is used to configure the instrument test process through the computer;

[0135] The computer is used to test the electrical components of the vehicle on the system stand through the steps of the instrument detection method provided in some embodiments of the present application.

[0136] This application provides a system-level instrument display testing method that can be used to test instrument display content on a test bench, which is difficult to trigger on a real vehicle. This method is primarily used during the project development phase. Through system simulation testing, it ensures that each system-level function display is normal, providing additional assurance during the actual vehicle testing phase.

[0137] Some embodiments of the present application provide a functional simulation test system based on a system bench, including a computer, a data acquisition and output device, a system bench, a power supply, and a simulation test engineering panel.

[0138] The data acquisition and output device is connected to the test system bench via a hard-wired communication line.

[0139] The system test bench is a yellow board test bench or Labcar test bench built based on the electrical components of the entire vehicle.

[0140] The power supply is a device that provides power to the yellow board stand or Labcar stand.

[0141] The simulation test project panel is a system function test project built based on simulation equipment.

[0142] Furthermore, the data acquisition and output device includes a data acquisition module and a data output module

[0143] The data acquisition module is used to collect communication data of the original end controller for simulation test engineering verification.

[0144] The data output module is used to simulate the original end communication data and send it from the original end to the instrument under test on the system bench.

[0145] This application can realize system-level testing of the full functions of the instrument. Testers need to develop a system-level simulation test project based on the system function document. Complete the system-level test of this function on the system bench, replacing the test from the original end data to the display end in the actual vehicle. Fill the gaps in system-level simulation testing and reduce the cost of actual vehicle testing. The only difference from the actual vehicle is that the function is not triggered from the actual usage scenario, but only ensures that the system channel of the function is correct. Lay a solid foundation for actual vehicle testing.

[0146] This application is simple to use and requires writing system-level simulation test cases, setting up a system-level simulation test project, collecting source controller messages, and reviewing source controller unit test reports. This allows you to complete a full-function system test of the instrument on a test bench. This solves the difficulty of instrument system fault testing, which previously plagued multiple projects, and reduces the risk of instrument system failure throughout the vehicle.

[0147] The following describes the present application scheme in conjunction with a specific embodiment of the present application, and introduces a system-level bench test method for an instrument:

[0148] Step 1: The computer is connected to a data acquisition and output device, and the data output device simulates sending the collected communication data to control the display of the instrument.

[0149] Step 2: The power supply and rack wiring harness is used for power supply and communication of the system rack.

[0150] Step 3: The data acquisition device uses SPY3.0 or Tongxing, supporting CAN and CANFD.

[0151] Step 4: The controller function simulation project is based on the SPY3.0 device. The CAN TD of the original controller is added to the Tx Panel module of the device, and the function simulation components are created in the Graphical panels module of the device. Each component needs to be associated with the signal value under the function CAN ID to realize the simulation of the function.

[0152] Step 5: The controller CAN ID check means that part of the CAN ID of the original controller has a CRC check (CRC check logic industry algorithm). It is necessary to create a CRC check simulation project for this part of the ID to realize the CRC check simulation of the original controller.

[0153] Step 6: The primary controller refers to all CAN controllers in the vehicle CAN network topology, such as the engine control unit (BMS), the reversing radar controller (RRS), the airbag controller (SRS), etc. The primary controller has CAN bus-related display functions and is within the scope of the functional simulation test.

[0154] Step 7: The data acquisition and generation device receives messages from the source controller for verification in the simulation test project. Based on the test case, the instrument function message is simulated and sent in the simulation test project. The instrument receives the corresponding signal and displays the corresponding image content. The tester then determines whether the displayed image content meets the test case description based on the edited test case. If it does not meet the test case description, data extraction and problem analysis are required. After the test is completed, the results are entered into the test case to form a system-level test report.

[0155] Reference Figure 3 During the remote control signal acquisition and simulation preparation phase, the system uses a data acquisition device (such as SPY3.0) to capture the actual CAN messages of the original controller in a real-vehicle environment. These messages include key signals such as vehicle speed, engine speed, and fault codes. For example, the CAN ID of the engine controller (BMS) is 0x18F00500. The data acquisition module records its raw binary data, signal definitions (such as start bit, length, and scaling factor), and CRC checksum rules. The system parses the collected messages, extracts communication protocol parameters (such as a baud rate of 500kbps and a frame period of 100ms), and generates the corresponding simulation project configuration file.

[0156] During the simulation signal generation and injection phase, the system disconnects the original controller from the vehicle's CAN network to prevent interference with real-world signals. The simulation tester generates simulated messages based on the collected protocol parameters. The data output device injects these simulated messages into the system test bench's CAN bus at the same timing and baud rate as the actual vehicle. For example, the RRS (reversing radar) controller transmits messages at a 50ms period to simulate a reversing scenario.

[0157] During the instrument controller response and display verification phase, after receiving the simulated message, the instrument controller parses the CAN ID and signal value. For example, upon receiving a message with CAN ID 0x18F00500, it extracts the speed signal and drives the tachometer needle. Based on the parsed results, the display updates the displayed content, such as vehicle speed, fault warning icons, and parking radar indicators. The system automatically compares the actual display with the expected template using image processing algorithms (such as optical character recognition and template matching).

[0158] During the exception handling and data feedback phase: If the instrument display does not match expectations, the system records the discrepancy data, including the discrepancy type, location coordinates, and timestamp. If the simulated message CRC check fails, the system triggers an error frame (ErrorFrame), terminates the current message transmission, and records the exception. The discrepancy data and test case results are summarized to generate a standardized test report containing pass rate statistics, defect list, and optimization suggestions.

[0159] Reference Figure 4 The process shown includes:

[0160] Start: Start the instrument system-level test process, and clearly define the test goal as verifying the system-level display logic of the instrument's full functions.

[0161] Step A1: Write system simulation test cases based on the functional documentation: Based on the system functional documentation, design test cases that cover all display functions of the instrument, and clearly define the trigger conditions, expected display content, and judgment criteria.

[0162] Step A2, equipment acquisition system test bench primary controller data: use data acquisition output device (such as SPY3.0 or Tongxing equipment) to collect the CAN message data of the primary controller (such as BMS, RRS, SRS, etc.).

[0163] Step A3, building a simulation test project: building a test project on a simulation device (such as SPY3.0), including: adding the CAN TD (communication description file) of the original controller in the TxPanel module.

[0164] Create functional simulation components (Graphical Panels) and associate signal values ​​with CAN IDs to simulate function triggers. For CAN IDs with CRC checksums, build a CRC checksum simulation project.

[0165] Step A4, vehicle CAN protocol: define communication rules based on the vehicle CAN network protocol to ensure that the simulation data is consistent with the actual vehicle communication protocol.

[0166] Step A5, source controller unit function test report: obtain the source controller unit function test report (such as BMS, RRS) to ensure that its basic functions have been verified.

[0167] Step A6, simulation data display corresponding function: send simulation message to the system test bench through the data output module, trigger the instrument to display the corresponding content.

[0168] Step A7, instrument-side unit functional test report: Refer to the instrument's own functional test results to confirm that its hardware and basic display logic are normal.

[0169] Step A8: Determine the test conclusion based on the test case, simulation results, and unit test report: Compare the simulation results with the expected display content, and combine the unit test reports of the original controller and instrument to comprehensively determine whether the system-level function passes.

[0170] Step A9, generate a system bench test report: summarize the test results, generate a system-level test report, and record the passed / failed use cases and problem analysis.

[0171] Based on the foregoing embodiments, an embodiment of the present application provides an instrument testing device, which includes the various units included and the various modules included in each unit, and can be implemented by a processor in a computer device; of course, it can also be implemented by a specific logic circuit; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor (MPU), a digital signal processor (DSP) or a field programmable gate array (FPGA), etc.

[0172] Reference Figure 5 , users can edit the control instructions in the test project panel. The editing method can refer to the description in some embodiments of this application and will not be repeated here.

[0173] The system can be Figure 6 The test results are displayed on the interface shown.

[0174] Figure 7 A schematic diagram of the structure of an instrument testing device provided in an embodiment of the present application is shown in FIG. Figure 7 As shown, the instrument testing device 200 includes: an acquisition module 201, a testing module 202 and an output module 203, wherein:

[0175] The acquisition module 201 is used to acquire CAN bus messages of the primary controller corresponding to the instrument under test on the system test bench;

[0176] A testing module 202 is configured to generate a simulation message based on the CAN bus message;

[0177] Using the simulation message to simulate the signal input of a preset test scenario for the instrument under test, triggering the display function of the instrument under test to obtain the instrument display content;

[0178] The output module 203 is configured to generate a report based on a comparison result between the instrument display content and the expected display content corresponding to the preset test scenario.

[0179] In some embodiments, the testing module 202 is further configured to:

[0180] Based on the preset test scenario, the communication protocol and message format of the original controller are configured for the simulation message to obtain a control instruction; the control instruction is transmitted to the signal receiving port of the instrument under test through the system bench to obtain the instrument display content of the instrument under test.

[0181] In some embodiments, the test module 202 is further used to: create corresponding CAN IDs for the engine controller unit BMS, the reversing radar controller RRS, and the airbag controller SRS based on a preset test scenario; parse the CRC check algorithm logic corresponding to the CAN ID to generate a check rule library corresponding to the CAN ID; and correct the check code of the simulation message through the check rule library to obtain a control instruction.

[0182] In some embodiments, the test module 202 is further configured to: extract a signal value associated with an instrument display function in the CAN bus message; and reconstruct the signal value into a simulation message.

[0183] In some embodiments, the test module 202 is further used to: filter specific frame data containing vehicle speed signals, engine speed signals and fault code signals in the CAN bus message; decode the specific frame data; and convert the decoded specific frame data into a signal value in a standardized data format.

[0184] In some embodiments, the test module 202 is further used to: parse the physical quantity unit and data range of specific frame data according to the communication protocol definition of the original controller; and compare the parsed specific frame data with a preset threshold to verify the validity of the data.

[0185] In some embodiments, the output module 203 is further used to: obtain difference display analysis data between the instrument display content and the expected display content corresponding to the preset test scenario; and generate a standardized report document containing test conclusions, a defect list and optimization suggestions based on the display analysis data.

[0186] In some embodiments, the test module 202 is further used to: use the simulation message to sequentially simulate the signal input of multiple preset test scenarios for the instrument to be tested, and the predicted test scenarios include at least: simulation test scenarios of the power chassis system, vehicle control system, and vehicle-cloud system.

[0187] The embodiment of the present application generates simulation messages by collecting CAN bus messages of the primary controller of the instrument to be tested on the test bench. The simulation messages simulate the output of the primary controller in various test scenarios to trigger the instrument functions of the instrument to be tested for instrument testing. There is no need to invest a lot of resources in simulating vehicle working scenarios and actual vehicle testing on the test bench, and various instrument functions of the vehicle instruments can be triggered, thereby reducing testing costs.

[0188] The description of the above device embodiment is similar to the description of the above method embodiment and has similar beneficial effects as the method embodiment. In some embodiments, the functions or modules included in the device provided by the embodiments of the present disclosure can be used to perform the methods described in the above method embodiments. For technical details not disclosed in the device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0189] It should be noted that, in the embodiment of the present application, if the above-mentioned instrument test method is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for making a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a magnetic disk or an optical disk. In this way, the embodiment of the present application is not limited to any specific hardware, software or firmware, or any combination of hardware, software and firmware.

[0190] An embodiment of the present application provides a computer device, including a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the program, some or all of the steps in the above method are implemented.

[0191] The present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements some or all of the steps in the above method. The computer-readable storage medium may be transient or non-transient.

[0192] An embodiment of the present application provides a computer program, including computer-readable code. When the computer-readable code is run in a computer device, a processor in the computer device executes some or all of the steps for implementing the above method.

[0193] An embodiment of the present application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and when the computer program is read and executed by a computer, implements some or all of the steps in the above method. The computer program product can be implemented specifically by hardware, software, or a combination thereof. In some embodiments, the computer program product is embodied as a computer storage medium. In other embodiments, the computer program product is embodied as a software product, such as a software development kit (SDK), etc.

[0194] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between the various embodiments, and their similarities or similarities can be referenced to each other. The descriptions of the above device, storage medium, computer program, and computer program product embodiments are similar to the descriptions of the above method embodiments and have similar beneficial effects as the method embodiments. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the description of the method embodiments of this application for understanding.

[0195] It should be noted that Figure 8 A schematic diagram of a hardware entity of a computer device in an embodiment of the present application is shown in FIG. Figure 8 As shown, the hardware entity of the computer device 700 includes: one or more processors 701, a communication interface 702 and a memory 703, wherein:

[0196] Processor 701 generally controls the overall operation of computer device 700 .

[0197] The communication interface 702 enables the computer device to communicate with other terminals or servers through a network.

[0198] The memory 703 is configured to store instructions and applications executable by the processor 701, and can also cache data to be processed or processed by the processor 701 and various modules in the computer device 700 (for example, image data, audio data, voice communication data, and video communication data). It can be implemented using flash memory (FLASH) or random access memory (RAM). Data can be transmitted between the processor 701, the communication interface 702, and the memory 703 via a bus 704. Among them, only one processor is shown in the figure, and each processor 100 includes one or more cores.

[0199] It should be noted that the computer device may include multiple processors 701, and each processor 701 can exchange data through aggregate communication methods such as all-to-all, allgather or allreduce. Among them, the above-mentioned processor 701 can be a central processing unit (CPU), a graphics processing unit (GPU), an embedded neural network processing unit (NPU), a tensor processing unit (TPU), a data processing unit (DPU), an accelerated processing unit (APU), a floating point computing unit (FPU) or an application-specific integrated circuit (ASIC), etc. The processor can also be a single-core processor or a multi-core processor. The processor can be a combination of a CPU and a hardware chip. The above-mentioned hardware chip can be an ASIC, a PLD or a combination thereof. The above-mentioned PLD can be a complex programmable logic device (CPLD), an FPGA, a generic array logic (GAL) or any combination thereof. The processor may also be implemented solely using a logic device with built-in processing logic, such as an FPGA or a digital signal processor (DSP).

[0200] The communication interface 702 may be a wired interface or a wireless interface for communicating with other modules or devices. The wired interface may be an Ethernet interface, a local interconnect network (LIN), etc., and the wireless interface may be a cellular network interface or a wireless local area network interface. In the embodiment of the present application, the communication interface 702 may be used to obtain data sent by other computer devices, etc.

[0201] The memory 703 may be a non-volatile memory, such as a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The memory 703 may also be a volatile memory, which may be a random access memory (RAM) used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synclink DRAM (SLDRAM), direct rambus RAM (DRRAM), direct rambus DRAM (DRDRAM), and rambus DRAM.

[0202] The bus 704 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc.

[0203] In some embodiments, the computer device may further include an input / output interface, to which an input / output device is connected for receiving information input by the user, such as the compression type and mantissa compression level input by the user.

[0204] The specific implementation of various operations performed by the above-mentioned computer device may refer to the specific operations of data compression and data decoding performed by the computer device in the above-mentioned method embodiment.

[0205] It should be understood that "one embodiment" or "an embodiment" mentioned throughout the specification means that the specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned steps / processes does not mean the order of execution, and the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. The above-mentioned serial numbers of the embodiments of the present application are for description only and do not represent the advantages and disadvantages of the embodiments.

[0206] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0207] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0208] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units; they may be located in one place or distributed across multiple network units; some or all of the units may be selected according to actual needs to achieve the purpose of the scheme of this embodiment.

[0209] In addition, all functional units in the embodiments of the present application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the above-mentioned integrated units can be implemented in the form of hardware or in the form of hardware plus software functional units.

[0210] Those skilled in the art will understand that all or part of the steps of implementing the above-mentioned method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above-mentioned method embodiment; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROM), magnetic disks or optical disks, and other media that can store program codes.

[0211] Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the relevant technology, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0212] The above is only an implementation method of the present application, but the scope of protection of the present application is not limited thereto. Any technician familiar with this technical field can easily think of changes or replacements within the technical scope disclosed in this application, which should be covered by the scope of protection of the present application.

Claims

1. An instrument testing method, characterized in that: The method comprises: Collect the CAN bus messages of the primary controller corresponding to the instrument under test on the system test bench; Generate a simulation message based on the CAN bus message; Using the simulation message to simulate the signal input of a preset test scenario for the instrument under test, triggering the display function of the instrument under test to obtain the instrument display content; A report is generated based on a comparison result between the instrument display content and the expected display content corresponding to the preset test scenario.

2. The method according to claim 1, characterized in that The using of the simulation message to simulate a signal input of a preset test scenario for the instrument under test, triggering a display function of the instrument under test to obtain instrument display content, includes: Configuring the communication protocol and message format of the original controller for the simulation message based on a preset test scenario to obtain a control instruction; The control instruction is transmitted to the signal receiving port of the instrument to be tested through the system stand to obtain the instrument display content of the instrument to be tested.

3. The method according to claim 2, characterized in that The configuring the communication protocol and message format of the original controller for the simulation message based on the preset test scenario to obtain a control instruction includes: Create corresponding CAN IDs for the engine control unit BMS, reversing radar controller RRS and airbag controller SRS based on the preset test scenarios; Analyze the CRC check algorithm logic corresponding to the CAN ID and generate a check rule library corresponding to the CAN ID; The control instruction is obtained by correcting the check code of the simulation message through the check rule library.

4. The method according to claim 3, characterized in that The generating of the simulation message based on the CAN bus message includes: Extracting a signal value associated with an instrument display function from the CAN bus message; The signal value is reconstructed into a simulation message.

5. The method according to claim 4, characterized in that The extracting of a signal value associated with an instrument display function from the CAN bus message includes: Filtering specific frame data containing a vehicle speed signal, an engine speed signal, and a fault code signal in the CAN bus message; decoding the specific frame data; Convert the decoded specific frame data into a signal value in a standardized data format.

6. The method according to claim 5, characterized in that The decoding of the feature frame data includes: Parsing the physical quantity unit and data range of a specific frame data according to the communication protocol definition of the original end controller; The parsed specific frame data is compared with the preset threshold to verify the validity of the data.

7. The method according to any one of claims 1 to 6, characterized in that: The generating a report based on a comparison result between the instrument display content and the expected display content corresponding to the preset test scenario includes: Obtaining difference display analysis data between the instrument display content and the expected display content corresponding to the preset test scenario; A standardized report document including test conclusions, defect lists and optimization suggestions is generated based on the display analysis data.

8. The method according to any one of claims 1 to 6, characterized in that: The using the simulation message to simulate the signal input of a preset test scenario for the instrument under test includes: The simulation message is used to sequentially simulate the signal input of multiple preset test scenarios for the instrument under test, and the predicted test scenarios at least include: simulation test scenarios of the power chassis system, the vehicle control system, and the vehicle-cloud system.

9. An instrument testing device, characterized in that: The device comprises: The acquisition module is used to collect the CAN bus messages of the primary controller corresponding to the instrument under test on the system test bench; A test module, configured to generate a simulation message based on the CAN bus message; Using the simulation message to simulate the signal input of a preset test scenario for the instrument under test, triggering the display function of the instrument under test to obtain the instrument display content; An output module is used to generate a report based on a comparison result between the instrument display content and the expected display content corresponding to the preset test scenario.

10. An instrument testing system, characterized in that: The system includes: a computer, a data acquisition and output device, a system bench, and a simulation test engineering panel; The data acquisition and output device is connected to the system bench and the computer through hard-wired communication lines; the vehicle electrical components are deployed on the system bench; and the simulation test engineering panel is connected to the computer; The simulation test engineering panel is used to configure the instrument test process through the computer; The computer is used to test the electrical components of the vehicle on the system stand through the steps of the instrument detection method described in any one of claims 1-8.

11. A computer device comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the instrument testing method according to any one of claims 1 to 8.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the instrument testing method according to any one of claims 1 to 8 are implemented.

13. A computer program product, characterized in that The computer program product includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, the steps of the instrument testing method according to any one of claims 1 to 8 are implemented.

Images