A test method and system for controller can signals

Abstract

The present application relates to the technical field of vehicle engineering, and discloses a kind of about the test method of controller CAN signal, comprising the following steps: S1: import test CAN signal;S2: test CAN signal is parsed, and the test data of test CAN signal is obtained;S3: test data is converted into CAN message;S4: API is provided by CAN signal sending of transmission tool, and CAN message is sent to the controller to be measured through CAN bus;S5: the CAN message sent by transmission tool is received by the controller to be measured, and after its processing, it is published;S6: the signal value of the CAN signal published by the controller to be measured is compared with the test CAN signal parsed in step S2, if the result is same, the link of the controller to be measured is not problematic, if the result is different, the link of the controller to be measured has problem.The test method provided by the present application is high in adaptability and flexibility.The present application also provides a kind of about the test system of controller CAN signal.

Description

Technical Field

[0001] This invention relates to the field of vehicle engineering technology, and in particular to a test method and system for controller CAN signals. Background Technology

[0002] The CAN bus boasts advantages such as high reliability, good real-time performance, and reasonable cost, making it widely used in automotive and other fields. The controller, as one of the most critical components of a vehicle, plays a crucial role in determining the vehicle's operational status, which in turn relies on thousands of CAN signals on the CAN bus. The correctness of each signal is critical to the vehicle's driving safety. Therefore, the controller's ability to correctly receive, process, and transmit CAN signals is paramount. Consequently, testing the controller's CAN signals is necessary in automotive manufacturing. Currently, the testing of controller CAN signals typically involves generating scripts from the CAN protocol dbc file corresponding to the test CAN signal, importing the scripts into simulation testing tools to send simulated CAN data. However, for sensors using the CAN link, such as the whole vehicle CAN, front radar, and corner radar, the generated scripts from the CAN protocol dbc file and the simulation testing tools differ, resulting in insufficient automation in the testing process. This makes it difficult to embed the tools and scripts into an automated testing framework for future testing.

[0003] Existing technology provides a method for testing controller CAN signals, comprising: generating a cmm script file from a CAN protocol dbc file using a Perl script file; importing the cmm script file into a simulation testing tool and sending simulated CAN data according to the cmm script file; receiving the simulated CAN data sent by the controller under test through a network analysis testing tool, and using the CAN protocol dbc file to determine whether the received simulated CAN data sent by the controller under test is consistent with the simulated CAN data sent by the cmm script file; wherein, generating the cmm script file from the CAN protocol dbc file using a Perl script file includes: converting the CAN protocol dbc file into an XML file; obtaining the CAN message name and CAN signal name from the XML file; establishing a test window using the CAN message name and adding test signal data using the CAN signal name; wherein, the test signal data includes at least one of the maximum value, minimum value, and median value of the CAN signal; and writing the test window and the test signal data corresponding to the CAN signal name into the cmm script to generate the cmm script file. For sensors that use the CAN link, such as the whole vehicle CAN, front radar, and corner radar, there are differences in the scripts generated by the CAN protocol dbc file and the simulation test tools, resulting in insufficient automation of the test. It is difficult to embed the tools and scripts into the automation framework for testing in the future. Summary of the Invention

[0004] The purpose of this invention is to provide a testing method and system for controller CAN signals, in order to solve the problem of low automation in existing technologies and provide a flexible and highly integrated testing method and system for controller CAN signals.

[0005] To achieve the above objectives, the present invention provides a method for testing controller CAN signals, comprising the following steps: S1: Import test CAN signal; S2: Analyze the test CAN signal to obtain the test data of the test CAN signal; S3: Convert test data into CAN messages; S4: Call the CAN signal transmission API provided by the transmission tool to send the CAN message to the controller under test via the CAN bus; S5: The controller under test receives CAN messages sent by the transmission tool, processes them, and then publishes them. S6: Compare the CAN signal emitted by the controller under test with the signal value of the test CAN signal parsed in step S2. If the results are the same, the link of the controller under test is fine; if the results are different, the link of the controller under test is faulty.

[0006] As a preferred embodiment, in step S1, the dbc file corresponding to the test CAN signal is imported; in step S2, based on the dbc file, the upper and lower limits of the physical value of the test CAN signal are obtained, and test data within the range is generated by random number generation. The test data within the range is within and includes the upper and lower limits of the physical value of the test CAN signal, and the test data is written into the corresponding structure.

[0007] As a preferred embodiment, in step S2, the upper and lower limits of the physical value of the test CAN signal are determined based on the signal value range of the test CAN signal. If the signal value range of the test CAN signal changes, the macro definition of the upper and lower limits of the physical value of the test CAN signal is modified according to the signal value range of the test CAN signal.

[0008] As a preferred embodiment, in step S3, the start bit and length of the test CAN signal are extracted from the dbc file corresponding to the test CAN signal. Based on the start bit and length of the test CAN signal, the binary number corresponding to the test data is shifted and concatenated to generate a CAN message.

[0009] As a preferred embodiment, in step S1, there are two or more test signals; in step S3, the binary number corresponding to the test signal is shifted left to remove the highest bit, and for the second and subsequent signals, the last bit of the previous signal is used as the starting bit, and the left-shifted binary number with the highest bit removed is concatenated to the last bit of the previous signal to form several bytes. If the bytes are incomplete, the binary number of each signal is shifted left until several complete bytes are formed. As a preferred embodiment, in step S5, after the message receiving module of the controller under test receives the CAN message, it forwards it to the data service module of the controller under test. After the data service module processes the data, it publishes it to the outside world. Subscribe to the data published by the data service module, process it to obtain the signal value processed by the controller under test, and compare the signal value processed by the controller under test with the signal value of the test CAN signal parsed in step S2.

[0010] As a preferred embodiment, in step S5, the controller under test publishes protobuf type data, and the data published by the controller under test is subscribed to through the DDS protocol and processed to obtain the signal value of the test signal.

[0011] As a preferred approach, the subscribed protobuf type data is deserialized, converting the buffer and length subscribed through the DDS protocol into a message object, whose members are the final processed signal values.

[0012] The present invention also provides a test system for controller CAN signals, comprising: The message generation tool is used to import test CAN signals, parse the test CAN signals to obtain test data of the test CAN signals, and convert the test data into CAN messages. A transmission tool used to send CAN messages to the controller under test; Analysis tools are used to subscribe to the processed CAN signals published by the controller under test (DUT) and compare the signal values ​​of the processed CAN signals published by the DUT with the test CAN signals.

[0013] As a preferred embodiment, the transmission tool is a KVASER device.

[0014] Compared with the prior art, the beneficial effects of the present invention are as follows: The testing method provided by this invention imports and parses the test CAN signal to obtain test data, converts the test data into messages, and sends them to the controller under test (DUT). The method analyzes whether there are problems with the DUT's CAN link by comparing the CAN signal values ​​sent by the DUT with the test CAN signal. This invention eliminates the need for script generation and simulation testing tools based on different test CAN signals. When testing the CAN signals of different devices, only the corresponding CAN signal needs to be input to test the CAN signal transmission from different devices to the controller. It offers high adaptability, flexibility, and integration. This invention also provides a testing system for controller CAN signals, which has the above-mentioned beneficial effects, and will not be elaborated further here. Attached Figure Description

[0015] Figure 1 This is a flowchart of a test method for the controller CAN signal according to Embodiment 1 of the present invention.

[0016] Figure 2 This is a flowchart of a test method for the controller CAN signal according to Embodiment 2 of the present invention.

[0017] Figure 3 This is a flowchart of the CAN message generation method according to an embodiment of the present invention.

[0018] Figure 4 This is a schematic diagram of the CAN link of the test system for the controller CAN signal according to an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Example 1 like Figure 1 As shown, a preferred embodiment of the present invention provides a method for testing the CAN signal of a controller, comprising the following steps: S1: Import test CAN signal; S2: Analyze the test CAN signal to obtain the test data of the test CAN signal; S3: Convert test data into CAN messages; S4: Call the CAN signal transmission API (Application Programming Interface) provided by the transmission tool to send the CAN message to the controller under test via the CAN bus; S5: The controller under test receives CAN messages sent by the transmission tool, processes them, and then publishes them. S6: Compare the CAN signal emitted by the controller under test with the signal value of the test CAN signal parsed in step S2. If the results are the same, the link of the controller under test is fine; if the results are different, the link of the controller under test is faulty.

[0021] The testing method provided in this embodiment imports and parses the test CAN signal to obtain test data. This test data is then converted into a message and sent to the controller under test (DUT). The CAN signal value sent by the DUT is compared with the test CAN signal to analyze whether there is a problem with the DUT's CAN link. This invention eliminates the need for script generation and simulation testing tools based on different test CAN signals. When testing the CAN signals of different devices, only the corresponding CAN signal needs to be input to test the CAN signal transmission from different devices to the controller. It offers high adaptability, flexibility, and integration. This embodiment only requires obtaining the signal value of the test CAN signal, converting it into a message and sending it to the DUT. The signal value of the CAN signal sent by the DUT after processing is compared with the obtained CAN signal value to determine whether there is a problem with the DUT's CAN link.

[0022] Example 2 The difference between this embodiment and Embodiment 1 is that, based on Embodiment 1, this embodiment provides further explanation of each step of the testing method.

[0023] like Figure 2 As shown, this embodiment of a test method for controller CAN signals includes the following steps: S1: Import test CAN signal.

[0024] Specifically, in step S1, the dbc files corresponding to the test CAN signals are imported. There are two or more test CAN signals; in this embodiment, three test CAN signals are used, namely test signals A, B, and C. Test signals A, B, and C are written into files A, B, and C respectively. Then, the corresponding dbc files for test signals A, B, and C are generated.

[0025] S2: Analyze the test CAN signal to obtain the test data of the test CAN signal.

[0026] Specifically, based on the dbc file, the upper and lower limits of the physical value of the test CAN signal are obtained. Test data within the range is generated by random number generation. The test data within the range is within and includes the upper and lower limits of the physical value of the test CAN signal. The test data is then written into the corresponding structure.

[0027] The upper and lower limits of the physical value of the CAN signal can be used for boundary value testing. If the test data is within the upper and lower limits of the physical value of the CAN signal, it is considered a normal value test. If the test data is outside the upper and lower limits, it is considered an abnormal value test, or an abnormal test case. For example, if a signal represents temperature with upper and lower limits of -50 to 100 degrees Celsius, and the test data is 120 degrees Celsius, it is outside the normal upper and lower limits. This simulates whether the controller performs abnormal handling if the sensor malfunctions and provides an abnormal value.

[0028] Step S2 involves writing the generated test data into the corresponding structure and processing the generated test data to generate a CAN message.

[0029] Generating test data within a range using random numbers is intended to better cover the completeness of test cases and provide flexibility. Specifically, in step S2, the upper and lower limits of the physical value of the test CAN signal are determined based on the signal value range of the test CAN signal. If the signal value range of the test CAN signal changes, the macro definition of the upper and lower limits of the physical value of the test CAN signal is modified accordingly. If the signal value range changes in subsequent new projects, only the macro definition of the effective value upper and lower limits needs to be modified. This embodiment generates test data within a range using random numbers, which is an optimization based on the random function, determining the upper and lower limits of the physical value of the CAN signal and the number of generated test cases.

[0030] S3: Convert test data into CAN messages.

[0031] Step S3, converting test data into CAN messages, mainly involves converting the signal values ​​of the test CAN signals into CAN messages. In this embodiment, the binary numbers of the test CAN signal values ​​are converted into messages. It should be noted that converting the decimal numbers of the test CAN signal values ​​is also acceptable.

[0032] Specifically, such as Figure 3As shown, in step S3, the start bit and length of the test CAN signal are extracted from the dbc file corresponding to the test CAN signal. Based on the start bit and length of the test CAN signal, the binary numbers corresponding to the test data are shifted and concatenated to generate a CAN message. The dbc file corresponding to the test CAN signal is translated to extract the start bit and length of test CAN signals A, B, and C. The test data is then shifted using binary number shifting operations, and the binary numbers corresponding to each signal value are concatenated to their corresponding lengths, thereby converting the simulated test data into a CAN message.

[0033] Specifically, in step S3, the binary number corresponding to the test signal is shifted left to remove the highest bit. For the second and subsequent signals, the last bit of the previous signal is used as the starting bit. The binary number after shifting left and removing the highest bit is concatenated to the last bit of the previous signal to form several bytes. If the bytes are incomplete, the binary number of each signal is shifted left until several complete bytes are formed.

[0034] For example: Signal A starts at bit 0 in the dbc, has a length of 7, and the analog data is 123; Signal B starts at bit 7 in the dbc, has a length of 3, and the analog data is 5. Neither signal is a full byte. The binary number of signal A is 01111011. By shifting it left and removing the high-order 0, we get the result 1111011. For signal B, the binary number is 0101. We take the last bit of signal A as the starting bit of signal B, shift it left by one bit to remove the high-order 0, and then concatenate it to the last bit of signal A to get the first complete byte buf[0] = 11110111. The extra two bits are the second byte buf[1] = 01. Subsequent signals are processed according to this rule.

[0035] The binary value of the CAN signal being tested is converted into a message. The purpose of this is to align the test data of the signal with the byte bits of the DBC database through a shift operation.

[0036] S4: Call the CAN signal transmission API provided by the transmission tool to send the CAN message to the controller under test via the CAN bus.

[0037] The simulated test data is converted into a CAN message and sent to the CAN bus. This includes opening the CAN channel, setting CAN transmission parameters, opening the CAN bus, sending the CAN message, setting the asynchronous signal transmission processing time, closing the CAN bus, and closing the CAN channel. Specifically, this embodiment uses a Kvaser device as the transmission tool. It should be noted that any CAN-related test device that provides the corresponding API can be used as the transmission tool. The function of the transmission tool is simply to send the CAN message converted in step S3 to the controller under test.

[0038] S5: The controller under test receives CAN messages sent by the transmission tool, processes them, and then publishes them.

[0039] In step S5, after the message receiving module of the controller under test (DUT) receives the CAN message, it forwards it to the data service module of the DUT. The data service module processes the data and publishes it externally. The DUT also subscribes to the data published by the data service module and processes the data to obtain the processed signal value. The processed signal value of the DUT is then compared with the signal value of the test CAN signal parsed in step S2. Both the message receiving module and the data service module are part of the DUT. The message receiving module uses an MCU, and the DUT includes an MPU (Microprocessor Unit). The MPU includes the data service module and the driving application terminal. After receiving the CAN message, the message receiving module publishes it via the DDS protocol. The data service module subscribes to the agreed-upon topic 1, obtains the DBC forwarded by the message receiving module, parses the subscribed DBC, and then publishes the parsed data to the corresponding topic 2 via the DDS protocol. The driving application terminal subscribes to the data on topic 2 via the DDS protocol to obtain the data processed by the data service module. Similarly, in this embodiment, the data on topic 2 is also subscribed to for step S6.

[0040] In this embodiment, in step S5, the controller under test (DUT) publishes protobuf type data. The DDS protocol is used to subscribe to this data, and the data is processed to obtain the signal values ​​of the test signals. The processing procedure is as follows: the subscribed protobuf type data is deserialized, that is, the protobuf library provided by Google is called to convert the buffer and length subscribed through the DDS protocol into a message object. The members of this object are the final processed signal values. Each specific signal value is obtained by calling methods, and each obtained signal value is stored sequentially into the corresponding file. , , .

[0041] S6: Compare the CAN signal emitted by the controller under test with the signal value of the test CAN signal parsed in step S2. If the results are the same, the link of the controller under test is fine; if the results are different, the link of the controller under test is faulty.

[0042] This embodiment compares each signal data line by line in sequence between the two files, comparing file A with file B. Compare the data, and pair file B with file B. Compare the data between file C and file C. The data is compared. If the results are different, the corresponding signal value for each line is printed out and a prompt is given; if the results are the same, a prompt indicating that the test results are the same is given. Furthermore, if the data in the files is inconsistent, it indicates that there is a problem with the data processing of the data service. If no data is subscribed, it indicates that every module in the entire controller may have a problem and needs to be checked one by one.

[0043] Example 3 like Figure 4 As shown, this embodiment provides a test system for controller CAN signals, including: The message generation tool is used to import test CAN signals, parse the test CAN signals to obtain test data of the test CAN signals, and convert the test data into CAN messages. A transmission tool used to send CAN messages to the controller under test; Analysis tools are used to subscribe to the processed CAN signals published by the controller under test (DUT) and compare the signal values ​​of the processed CAN signals published by the DUT with the test CAN signals.

[0044] Specifically, the message generation tool imports the dbc file corresponding to the test CAN signal and writes each signal into the corresponding file. Then, based on the dbc file, it obtains the upper and lower limits of the physical value of the test CAN signal, parses it to obtain the original test data, writes the original test data into the corresponding structure, extracts the start bit and length of the test CAN signal from the dbc file corresponding to the test CAN signal, and shifts and concatenates the binary number corresponding to the test data based on the start bit and length of the test CAN signal to generate a CAN message.

[0045] Optionally, the transmission tool is a KVASER device. It should be noted that any CAN-related test device capable of providing the corresponding API can be used as the transmission tool. The function of the transmission tool is simply to send the converted CAN message to the controller under test. The message generation and analysis tools are integrated into the computer; the message generation tool consists of DBC parsing code and the SDK provided by KVASER, and the analysis tool consists of protobuf deserialization code. Therefore, the test system in this embodiment consists of a computer, a KVASER device, and the controller under test connected in a loop. Figure 4 The test system of this embodiment provides a CAN link, and the data comparison and conversion into CAN messages are performed on a computer that integrates message generation and analysis tools. The KVASER driver is called to use the KVASER device, and the MCU and MPU are both part of the controller under test.

[0046] The working process of this invention is as follows: Each test signal is written to its corresponding file. Then, the dbc file corresponding to the test CAN signal is imported. Based on the dbc file, the upper and lower limits of the physical values ​​of the test CAN signal are obtained. The original test data is obtained through parsing and written into a defined structure. The dbc file is translated using code to extract the start bit and length of the test CAN signal from the dbc file corresponding to the test CAN signal. Based on the start bit and length of the test CAN signal, the binary number corresponding to the test data is shifted and concatenated to generate a CAN message. The CAN transmission-related API of Kvaser is called to simulate data transmission, sending the CAN message to the controller under test (DUT). The DUT subscribes to the protobuf type data published after processing by the DUT's data service module to obtain the signal values ​​acquired and processed by the DUT. Each acquired signal value is stored sequentially in its corresponding file. Each signal data in the two files is compared line by line sequentially. If the results are different, the corresponding signal value for each line is printed and a prompt is given; if the results are the same, a prompt indicating that the test results are the same is given.

[0047] In summary, this invention provides a method for testing controller CAN signals. It imports and parses the test CAN signal to obtain test data, converts the test data into messages, and sends them to the controller under test (DUT). The method compares the CAN signal values ​​sent by the DUT with the test CAN signal to analyze whether there are problems with the DUT's CAN link. This invention eliminates the need for script generation and simulation testing tools based on different test CAN signals. When testing the CAN signals of different devices, only the corresponding CAN signal needs to be input to test the CAN signal transmission from different devices to the controller. It offers high adaptability, flexibility, and integration. This invention also provides a testing system for controller CAN signals, which has the above-mentioned beneficial effects, and will not be elaborated further here.

[0048] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be found in the method section.

[0049] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of the invention.

[0050] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0051] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and substitutions can be made without departing from the technical principles of the present invention, and these improvements and substitutions should also be considered within the scope of protection of the present invention.

Claims

1. A test method for controller CAN signals, characterized in that, The steps include the following: S1: Import test CAN signal; S2: Analyze the test CAN signal to obtain the test data of the test CAN signal; S3: Convert test data into CAN messages; S4: Call the CAN signal transmission API provided by the transmission tool to send the CAN message to the controller under test via the CAN bus; S5: The controller under test (DUT) receives the CAN message sent by the transmission tool, processes it, and then publishes it. In step S5, after receiving the CAN message, the message receiving module of the DUT forwards it to the data service module of the DUT. After processing the data, the data service module publishes it externally. Subscribing to the data published by the data service module and processing it to obtain the signal value processed by the DUT is also performed. The signal value processed by the DUT is then compared with the signal value of the test CAN signal parsed in step S2. The message receiving module uses an MCU. After receiving the CAN message, the message receiving module publishes it through the DDS protocol. S6: Compare the CAN signal emitted by the controller under test with the signal value of the test CAN signal parsed in step S2. If the results are the same, the link of the controller under test is fine; if the results are different, the link of the controller under test is faulty.

2. The test method for controller CAN signals according to claim 1, characterized in that, In step S1, the dbc file corresponding to the test CAN signal is imported; in step S2, based on the dbc file, the upper and lower limits of the physical value of the test CAN signal are obtained, and test data within the range is generated by random number generation. The test data within the range is within and includes the upper and lower limits of the physical value of the test CAN signal, and the test data is written into the corresponding structure.

3. The test method for controller CAN signals according to claim 2, characterized in that, In step S2, the upper and lower limits of the physical value of the test CAN signal are determined based on the signal value range of the test CAN signal. If the signal value range of the test CAN signal changes, the macro definition of the upper and lower limits of the physical value of the test CAN signal is modified according to the signal value range of the test CAN signal.

4. The test method for controller CAN signals according to claim 1, characterized in that, In step S3, the start bit and length of the test CAN signal are extracted from the dbc file corresponding to the test CAN signal. Based on the start bit and length of the test CAN signal, the binary number corresponding to the test data is shifted and concatenated to generate a CAN message.

5. The test method for controller CAN signals according to claim 4, characterized in that, In step S1, there are two or more test signals; in step S3, the binary number corresponding to the test signal is shifted left to remove the highest bit, and for the second and subsequent signals, the last bit of the previous signal is used as the starting bit, and the binary number after shifting left and removing the highest bit is concatenated to the last bit of the previous signal to form several bytes. If the bytes are incomplete, the binary number of each signal is shifted left until several complete bytes are formed.

6. The test method for controller CAN signals according to claim 1, characterized in that, In step S5, the controller under test publishes protobuf type data. The data published by the controller under test is subscribed to through the DDS protocol and processed to obtain the signal value of the test signal.

7. A test method for controller CAN signals according to claim 6, characterized in that, The subscribed protobuf data is deserialized, converting the buffer and length subscribed through the DDS protocol into a message object. The members of this object are the final processed signal values.

8. A test system for controller CAN signals, based on the test method for controller CAN signals according to any one of claims 1-7, characterized in that, include: The message generation tool is used to import test CAN signals, parse the test CAN signals to obtain test data of the test CAN signals, and convert the test data into CAN messages. A transmission tool used to send CAN messages to the controller under test; Analysis tools are used to subscribe to the processed CAN signals published by the controller under test (DUT) and compare the signal values ​​of the processed CAN signals published by the DUT with the test CAN signals.

9. A test system for controller CAN signals according to claim 8, characterized in that, The transmission tool is a KVASER device.

Images