Communication method and system based on bench test
By converting CANFD signals into CAN signals through software, the communication incompatibility problem between the test bench equipment and CANFD equipment is solved, and a low-cost compatible and reliable test process is achieved.
Patent Information
- Application Number
- CN202510692678.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-27
- Publication Date
- 2025-09-19
AI Technical Summary
Existing test bench equipment only supports the traditional CAN protocol and cannot communicate with the object under test using the CANFD bus, which makes equipment testing difficult and the modification cost high.
The CANFD signal is converted into a CAN signal through software methods, and a target message compatible with the CAN protocol is generated. The conversion rules and configuration files are used to realize the communication between the test bench and the CANFD device.
It achieves compatibility between bench equipment that only supports CAN protocol and CANFD equipment, reduces hardware modification costs and testing costs, and ensures communication reliability and smooth testing process.
Smart Images
Figure CN120676069A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of vehicle testing technology, and in particular to a communication method and system based on bench testing. Background Art
[0002] With the rapid development of automotive electronics, the traditional CAN (Controller Area Network) bus, due to its bandwidth limitations, is increasingly unable to meet the data transmission rate and capacity requirements of modern vehicles. Therefore, an enhanced CAN FD (CAN with Flexible Data-Rate) bus standard has been introduced, capable of supporting higher data transmission rates and larger data payloads. With the rapid advancement of smart car technology, more and more smart car bus communication protocols have shifted from the traditional CAN protocol to the CAN FD protocol in recent years.
[0003] Before leaving the factory, major automotive OEMs or testing organizations must conduct bench testing on controllers, sensors, and other devices. However, current test benches only support CAN protocol data and are incompatible with the CANFD protocol. Therefore, they cannot communicate with test objects using the CANFD bus, making device testing difficult. Furthermore, due to the high cost of test bench equipment, even modifying the equipment would incur significant costs. Therefore, the challenge is to cost-effectively enable test bench equipment that only supports the CAN protocol to read and interpret CANFD signals. Summary of the Invention
[0004] In view of this, the present application aims to propose a communication method and system based on bench testing, so as to enable bench equipment that only supports the CAN protocol to read and parse CANFD signals while saving costs.
[0005] To achieve the above objectives, the technical solutions of this application are as follows:
[0006] In a first aspect, an embodiment of the present application provides a communication method based on bench testing, which is applied to a processor. The method includes:
[0007] Receiving a first target message carrying original test information sent by a test object; the first target message includes a first CANFD signal; the original test information includes: a target physical quantity of a response test of the test object;
[0008] Converting the first CAN FD signal into at least one first CAN signal according to a conversion rule;
[0009] Based on all first CAN signals corresponding to the first CAN FD signal, a second target message is generated, and the second target message is sent to the test bench, so that the test bench uses the first configuration file to parse the second target message to obtain the original test information; the first configuration file matches the conversion rule and is used to indicate the mapping relationship information between the first CAN signal and the original test information.
[0010] Optionally, converting the first CAN FD signal into at least one first CAN signal according to a conversion rule includes:
[0011] Obtain a parameter field and a corresponding first data field of the first CANFD signal; the parameter field includes: a frame start field, an identifier field, a remote transmission request field, a control field, a check field, a reception confirmation field, and a frame end field;
[0012] Sequentially splitting the first data field according to a target length and assigning corresponding signal IDs to obtain at least one second data field; the target length is less than or equal to the maximum length of a data field specified by the CAN protocol;
[0013] On the basis of the parameter field of the first CAN FD signal, based on each second data field and the corresponding signal ID, in accordance with the data format specified by the CAN protocol, respectively generate a parameter field corresponding to each second data field;
[0014] combining each second data field with a corresponding parameter field to generate a corresponding first CAN signal;
[0015] Generating a second target message based on all first CAN signals corresponding to the first CAN FD signal specifically includes: combining the first CAN signals in ascending order of signal ID to obtain the second target message.
[0016] Optionally, based on the parameter field of the first CAN FD signal, based on each second data field and the corresponding signal ID, and in accordance with the data format specified by the CAN protocol, generating a parameter field corresponding to each second data field, specifically including:
[0017] generating an identifier field in the parameter field based on the signal ID corresponding to the second data field;
[0018] Remove the BRS bit, the ESI bit, and the FDF bit in the control field of the first CAN FD signal, set the EDL bit to 0, and update the DLC bit according to the target length to obtain the control field in the parameter field of the first CAN signal;
[0019] Calculate the check field and the frame start field in the parameter field of the first CAN signal based on the second data field;
[0020] The remote transmission request field, reception confirmation field and frame end field in the parameter field of the first CAN FD signal are used as the remote transmission request field, reception confirmation field and frame end field in the parameter field of the first CAN signal.
[0021] Optionally, the method further includes:
[0022] Follow these steps to build the first configuration file:
[0023] Obtain a second configuration file; the second configuration file is used to indicate the mapping relationship information between the CAN FD signal and the original test information;
[0024] Extracting mapping relationship information between description information and CANFD signals from the second configuration file; the description information includes: signal ID, start frame, data length, parameter name and physical quantity;
[0025] Based on the data structure of the CAN signal, adjusting the mapping relationship information between the description information in the second configuration file and the CAN FD signal to obtain the mapping relationship information between the description information in the first configuration file and the CAN signal;
[0026] defining a length of the second data field in the first configuration file based on the target length;
[0027] Specify the alignment of the second data field from the big-endian alignment and the little-endian alignment;
[0028] Adjusting a scaling factor and an offset in the first configuration file based on a difference between a data field length of a CAN FD signal and a data field length of a CAN signal, and specifying a verification method for a physical quantity range, so that a physical quantity obtained by parsing the first CAN FD signal using the second configuration file is the same as a physical quantity obtained by parsing the first CAN signal using the first configuration file;
[0029] A second transmission rate corresponding to the second target message is defined; the second transmission rate is less than or equal to the maximum data transmission rate specified by the CAN protocol.
[0030] Optionally, the method further includes:
[0031] The first configuration file is sent to the rack, so that the rack loads the first configuration file and adjusts the data transmission rate of sending the second target message to a second transmission rate based on the first configuration file.
[0032] Optionally, before sending the second target message to the rack, the method further includes:
[0033] Parsing the first target message using the second configuration file to obtain the original test information;
[0034] Parsing the second target message using the first configuration file to obtain test information to be verified;
[0035] Comparing the original test information with the test information to be verified, and generating an error log if the original test information is different from the test information to be verified;
[0036] Sending the second target message to the rack includes: sending the second target message to the rack when the original test information is the same as the test information to be verified.
[0037] According to a second aspect of an embodiment of the present application, a communication method based on bench testing is provided, which is applied to a bench. The method comprises:
[0038] A second target message sent by the receiving processor is obtained by converting a first target message based on the CAN FD protocol sent by the object under test, and includes: at least one first CAN signal;
[0039] The second target message is parsed using the first configuration file to obtain original test information; the original test information includes: the target physical quantity of the response test of the object under test.
[0040] Optionally, the second target message is parsed using the first configuration file to obtain original test information, including:
[0041] Based on the mapping relationship information between the description information in the first configuration file and the CAN signal, and the parameter field of each first CAN signal, the corresponding parameters are parsed to obtain the corresponding parameters, including: signal ID, start frame, data length, parameter name and physical quantity;
[0042] Based on the alignment, scaling factor, and offset of the second data field in the first configuration file, the physical quantities corresponding to the first CAN signals are combined in ascending order of the signal IDs to obtain a target physical quantity of the response test of the object under test;
[0043] The original test information is obtained based on the target physical quantity and the description information.
[0044] Optionally, before receiving the second target message sent by the processor, the method further includes:
[0045] receiving a first configuration file sent by the processor and loading the configuration file;
[0046] Based on the first configuration file, the data transmission rate for receiving the second target message is modified to a second transmission rate.
[0047] According to a third aspect of an embodiment of the present application, a bench test system is provided, comprising: a processor, a bench, and an interface module;
[0048] The processor is provided with a signal conversion module for executing the steps of the method provided in the first aspect of the embodiment of the present application;
[0049] The test bench is used to perform the steps of the method provided in the second aspect of the embodiment of the present application, obtain the target physical quantity of the test object in response to the test; and execute the test process of the test object based on the target physical quantity;
[0050] The interface module is connected to the object under test, the processor and the test bench respectively, and is used to perform digital-to-analog conversion on the first CAN FD signal and the first CAN signal.
[0051] Using the communication method based on bench testing provided by the present application, the processor converts the first target message based on the CAN FD protocol sent by the object under test into a second target message based on the CAN protocol according to a pre-set conversion rule. Specifically, the first CAN FD signal in the first target message is converted into one or more first CAN signals. The first CAN FD signal carries the target physical quantity (such as pressure, temperature, speed, etc.) to which the object under test (such as the electronic control unit of a vehicle) responds during the test. All the first CAN signals corresponding to the first CAN FD signal are packaged to obtain a second target message, and sent to the bench, so that the bench that only supports the CAN protocol can read and parse the second target message based on the CAN protocol, and complete the subsequent test process for the object under test. Specifically, after receiving the second target message, the bench uses the first configuration file that matches the conversion rule to parse the second target message, thereby obtaining the target physical quantity of the test response of the object under test.
[0052] The bench test-based communication method provided in this application uses software to convert CAN FD signals through a controller, enabling communication between CAN FD devices and CAN devices without modifying or replacing the bench test hardware. Furthermore, based on conversion rules and a second configuration file corresponding to the CAN FD signal, a first configuration file corresponding to the first CAN signal is constructed. This enables the bench to parse the second target message based on the first configuration file and restore the test information (including the target physical quantity of the test object's response to the test) carried in the original first target message, thereby ensuring the reliability of communication between the bench and the test object. BRIEF DESCRIPTION OF THE DRAWINGS
[0053] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments of the present application. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0054] Figure 1 This is one of the flow charts of a communication method based on bench testing proposed in one embodiment of the present application;
[0055] Figure 2 2 is a schematic diagram of converting a first CAN FD signal into a first CAN signal in one embodiment of the present application;
[0056] Figure 3 This is the second flow chart of the communication method based on bench testing proposed in one embodiment of the present application;
[0057] Figure 4 Schematic diagram of a bench test system proposed in one embodiment of the present application. DETAILED DESCRIPTION
[0058] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.
[0059] It should be understood that references throughout this specification to "one embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic associated with the embodiment is included in at least one embodiment of the present application. Therefore, the appearances of "in one embodiment" or "in an embodiment" throughout this specification do not necessarily refer to the same embodiment. Furthermore, these particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0060] In the various embodiments of the present application, it should be understood that the size of the serial numbers of the following processes does not mean the order of execution. The execution order of each 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.
[0061] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. When the following description refers to the drawings, identical numerals in different figures represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatuses and methods consistent with certain aspects as detailed herein.
[0062] It should be noted that, unless there is any conflict, the embodiments and features in the embodiments of this application can be combined with each other.
[0063] CAN is a serial communication protocol used in automotive electronic systems, primarily for communication between electronic control units (ECUs) and data exchange between various electronic devices and systems. CAN FD is an extension of the traditional CAN protocol, offering improvements such as higher data rates and larger packet sizes. This protocol was designed to meet the growing data transmission needs of modern automotive systems. However, current test benches only support the traditional CAN protocol, making testing of automotive devices using the CAN FD bus difficult.
[0064] This embodiment converts CAN FD signals through software methods, converts the data field of a CAN FD signal into one or more CAN signal data fields, and generates corresponding CAN protocol message data and sends it to the test bench, thereby achieving compatibility of the test bench that only supports the CAN protocol with CAN FD bus devices.
[0065] The present application will be described in detail below with reference to the accompanying drawings and in combination with embodiments.
[0066] Figure 1 This is one of the flow charts of the communication method based on bench testing proposed in one embodiment of the present application. Figure 1 As shown, the method is applied to a processor, comprising:
[0067] S11: receiving a first target message carrying original test information sent by a test object; the first target message includes a first CANFD signal; the original test information includes: a target physical quantity of a response test of the test object;
[0068] S12: Convert the first CAN FD signal into at least one first CAN signal according to a conversion rule;
[0069] S13: Based on all first CAN signals corresponding to the first CAN FD signal, generate a second target message, and send the second target message to the test bench, so that the test bench uses the first configuration file to parse the second target message to obtain the original test information; the first configuration file matches the conversion rule and is used to indicate the mapping relationship information between the first CAN signal and the original test information.
[0070] The embodiment of the present application realizes the communication between the test bench that only supports the CAN protocol and the object under test of the CANFD bus by software. The object under test, such as the TCU (Transmission Control Unit), ECU (Electronic Control Unit), temperature sensor, pressure sensor, etc. of the car, feeds back the target physical quantity of the test process, such as speed, torque, temperature, pressure and other data, to the test bench during the test. The processor monitors the CANFD message sent by the object under test, and when it receives the first target message (including the first CANFD signal) sent by the object under test, it converts the first CANFD signal in the first target message according to the pre-set conversion rules, and converts one first CANFD signal into one or more first CAN signals. Then, a second target message is generated based on the converted first CAN signal and sent to the test bench.
[0071] Since the second target message is a CAN message, the test bench that supports the CAN protocol can correctly read and parse the message to obtain the corresponding test information. Specifically, the test bench is loaded with a first configuration file that matches the conversion rule, and the first configuration file includes mapping relationship information between the CAN signal and the original test information. In an embodiment of the present application, the first CAN signal is parsed by the first configuration file to obtain the corresponding test information. When the test bench receives the second target message sent by the processor, the test bench calls the loaded first configuration file to parse all the first CAN signals in the second target message, thereby obtaining the original test information. Furthermore, the test bench executes the test process for the object under test based on the original test information obtained by the analysis.
[0072] In the embodiment of the present application, the type of CAN FD signal is converted by pure software, so that the test bench that only supports CAN signals is compatible with the object under test using the CAN FD bus. CAN FD to CAN backward compatibility can be achieved without replacing existing hardware devices, which greatly reduces the cost of equipment upgrades, the testing cost of CAN FD equipment, and the time cost of equipment debugging.
[0073] Based on the same inventive concept, an embodiment of the present application provides a communication method based on bench testing, which is applied to a bench. Figure 3 , Figure 3 This is the second flow chart of the communication method based on bench testing proposed in one embodiment of the present application. Figure 3 As shown, the method includes:
[0074] S21: Receive a second target message sent by the processor; the second target message is obtained by converting a first target message based on the CAN FD protocol sent by the object under test, including: at least one first CAN signal;
[0075] S22: Use the first configuration file to parse the second target message to obtain original test information; the original test information includes: the target physical quantity of the test object in response to the test.
[0076] In this embodiment of the present application, the test bench receives a second target message sent by the processor and obtains the first CAN signal in the message. Then, the test bench uses the first configuration file to parse all first CAN signals in the second target message. Because the first configuration file matches the conversion rule, the first CAN signal converted from the first CAN FD signal can be parsed using the first configuration file to correctly restore the original test information carried by the first CAN FD signal, ensuring the reliability of communication between the test bench and the object under test.
[0077] As an implementation manner of the present application, converting the first CAN FD signal into at least one first CAN signal according to a conversion rule includes:
[0078] Obtain a parameter field and a corresponding first data field of the first CANFD signal; the parameter field includes: a frame start field, an identifier field, a remote request field, a control field, a check field, a reception confirmation field, and a frame end field;
[0079] Sequentially splitting the first data field according to a target length and assigning corresponding signal IDs to obtain at least one second data field; the target length is less than or equal to the maximum length of a data field specified by the CAN protocol;
[0080] On the basis of the parameter field of the first CAN FD signal, based on each second data field and the corresponding signal ID, in accordance with the data format specified by the CAN protocol, respectively generate a parameter field corresponding to each second data field;
[0081] combining each second data field with a corresponding parameter field to generate a corresponding first CAN signal;
[0082] Generating a second target message based on all first CAN signals corresponding to the first CAN FD signal specifically includes: combining the first CAN signals in ascending order of signal ID to obtain the second target message.
[0083] In an embodiment of the present application, after the processor reads the first CAN FD signal from the first target message, it parses the CAN FD signal to obtain various parameter fields and the first data field. Specifically, the parameter fields of the CAN FD signal include: a start-of-frame field (SOF), an identifier field (ID), a remote request field (RTR), a control field (Control), a checksum field (CRC), a reception confirmation field (ACK), and an end-of-frame field (EOF). The difference between the data structure of the CAN FD signal and the CAN signal is that the CAN FD signal has a higher maximum transmission rate and a longer single-frame data field.
[0084] To convert the first CAN FD signal into a CAN signal, the first data field of the first CAN FD signal must be split according to the data field length required by the CAN protocol, and the parameter field of the first CAN FD signal must be converted into the parameter field of the first CAN signal. Before splitting the first data field of the CAN FD signal, the length of the second data field to be obtained by splitting is first determined, and the first data field is split according to the target length.
[0085] For example, the first data field of the original CAN FD signal is defined as follows:
[0086] SG_LargeSignal:0|96@1+(1,0)[0|1e6]"Value"Receiver
[0087] / / From left to right, "0" indicates the starting frame is 0, "96" indicates the length is 96 bits (12 bytes), and "@1" indicates the alignment is "big endian";
[0088] When the target length is 4 bytes, the first data field is split into three second data fields as follows:
[0089] SG_LargeSignal_Part1:0|32@1+(1,0)[0|4294967295]"Value"Receiver
[0090] / / From left to right, "0" indicates the starting frame is 0, "32" indicates the length is 32it (4Byte), and "@1" indicates the alignment is "big endian";
[0091] SG_LargeSignal_Part2:32|32@1+(1,0)[0|4294967295]"Value"Receiver
[0092] / / From left to right, "32" indicates the starting frame is 32, "32" indicates the length is 32 bits (4 bytes), and "@1" indicates the alignment is "big endian";
[0093] SG_LargeSignal_Part3:64|32@1+(1,0)[0|4294967295]"Value"Receiver
[0094] / / From left to right, "64" indicates the starting frame is 64, "32" indicates the length is 32 bits (4 bytes), and "@1" indicates the alignment is "big endian".
[0095] Optionally, the maximum length of the data field specified by the CAN protocol, 8 bytes, is set as the target length. If the first data field of a CAN FD signal spans 8 bytes, the first data field is split according to the standard information segment length of 8 bytes, resulting in multiple second data fields. A corresponding signal ID is assigned to each split second data field. A first CAN signal is then combined based on each second data field, its corresponding signal ID, and the parameter field. Furthermore, based on all first CAN signals converted from the first CAN FD signal, a second target message is constructed, ordered by signal ID from smallest to largest, and sent to the test bench.
[0096] It is worth noting that if a first target message includes multiple first CAN FD signals and the length of the first data field is not an integer multiple of the target length, the conversion process needs to be completed by truncation and data reorganization to fill the data field gaps in the middle of the message that are less than the target length, ensuring that in the second target message after conversion, only the data field of the last first CAN signal is allowed to be less than the target length. For example, the first data field (DLC=16) of the CAN FD signal in the first target message is defined as follows:
[0097] BO_2000LongDataFrame:16ECU_FD
[0098] SG_Signal1:0|32@1+(0.1,0)[0|100]"Unit"NodeA
[0099] / / From left to right, "0" indicates the starting frame is 0, "32" indicates the length is 32 bits (4 bytes), and "@1" indicates the alignment is "big endian";
[0100] SG_Signal2:32|64@1+(0.01,0)[0|200]"Unit"NodeB
[0101] / / From left to right, "32" indicates the starting frame is 32, "64" indicates the length is 64 bits (8 bytes), and "@1" indicates the alignment is "big endian".
[0102] The message "BO_2000LongDataFrame" includes two first data fields "SG_Signal1" and "SG_Signal2". When the target length is 8 bytes (i.e., the data field of the CAN signal is 8 bytes), since the first first data field "SG_Signal1" is less than 8 bytes, the second first data field "SG_Signal2" needs to be split to make up for it. Specifically, the second first data field is split into two 4-byte data pieces, and the first 4 bytes are concatenated with the first first data field "SG_Signal1" to form an 8-byte length. The second data field (DLC=8) in the converted second target message is as follows:
[0103] BO_2000LongDataFrame_Part1:8ECU_FD
[0104] SG_Signal1_Low:0|32@1+(0.1,0)[0|100]"Unit"NodeA BO_2001LongDataFrame_Part2:8ECU_FD
[0105] SG_Signal1_High:0|32@1+(0.1,0)[0|100]"Unit"NodeA
[0106] SG_Signal2:32|32@1+(0.01,0)[0|200]"Unit"NodeB
[0107] After conversion, the first second data field "SG_Signal1" consists of two parts: the low-order 4-byte "SG_Signal1_Low" and the high-order 4-byte "SG_Signal1_High"; the second second data segment "SG_Signal2" becomes 4 bytes in length, meeting the target length requirement of 8 bytes.
[0108] As an embodiment of the present application, based on the parameter field of the first CAN FD signal, based on each second data field and the corresponding signal ID, according to the data format specified by the CAN protocol, the parameter field corresponding to each second data field is generated respectively, specifically including:
[0109] generating an identifier field in the parameter field based on the signal ID corresponding to the second data field;
[0110] Remove the BRS bit, the ESI bit, and the FDF bit in the control field of the first CAN FD signal, set the EDL bit to 0, and update the DLC bit according to the target length to obtain the control field in the parameter field of the first CAN signal;
[0111] Calculate the check field and the frame start field in the parameter field of the first CAN signal based on the second data field;
[0112] The remote transmission request field, reception confirmation field and frame end field in the parameter field of the first CAN FD signal are used as the remote transmission request field, reception confirmation field and frame end field in the parameter field of the first CAN signal.
[0113] In the embodiment of the present application, based on the parameter field of the first CAN FD signal, generating the parameter fields corresponding to the second data fields specifically includes the following steps:
[0114] (1) Obtaining the signal ID corresponding to each second data field, and generating the ID field in the parameter field of the first CAN signal in ascending order of the signal ID based on the ID field format required by the CAN protocol;
[0115] (2) Remove or adapt the unique fields of the CAN FD signal. Specifically, since the classic CAN protocol does not support switching the data transmission rate, it is necessary to delete the BRS bit (control data high-speed transmission) in the CAN FD signal control field. In addition, according to the control field format requirements of the CAN signal, the ESI bit (indicating error status) and the FDF bit (indicating CAN FD message) in the CAN FD signal control field must be deleted, and the EDL bit (indicating extended data length) is set to 0. In addition, the DLC bit (data length code) is updated according to the target length of the split data field (for example, 8 bytes);
[0116] (3) Based on the second data field, a checksum algorithm is used to generate a corresponding checksum and update the checksum field (CRC) in the parameter field, and the frame start bit corresponding to the second data field is calculated and the frame start field (SOF) is updated. For example, the original CAN FD signal is as follows:
[0117] SG_SignalX:70|16@1+(1,0)[0|65535]"Unit"Node
[0118] / / The signal starts at bit 70 and is 16 bytes long, which exceeds the maximum data bit range of the CAN signal "0-63":
[0119] SG_SignalX:32|16@1+(1,0)[0|65535]"Unit"Node
[0120] / / After adjustment and reorganization, the starting bit of the data segment is 32, which is within the maximum data bit range of the CAN signal "0-63" and meets the requirements of the CAN protocol;
[0121] (4) Since the data structures of the CAN FD signal and the CAN signal both contain the RTR field, ACK field, and EOF field, the RET field, ACK field, and EOF field in the first CAN FD signal are directly retained as the corresponding parameter fields in the new first CAN signal.
[0122] Figure 2 Schematic diagram of converting a first CAN FD signal into a first CAN signal in one embodiment of the present application. Figure 2 As shown, the processor converts the first CAN FD signal based on the conversion rule. First, the processor reads each parameter field and the first data field from the first CAN FD signal, splits the first data field based on the target length of the data field in the first CAN signal (for example, 8 bytes), and assigns a corresponding signal ID to each second data field in sequence according to the splitting order (for example, Figure 2 "ID+0, ID+1, ID+2"), and calculate the corresponding CRC check code (8Byte) according to each second data field. That is, Date (0-64B) is split into multiple Date (0-8Byte) and a new signal ID and DLC length are generated in sequence, and then the IDE bit is added before Date (0-8Byte) and set to 0 to obtain the second data field. Based on the second data field, the corresponding CRC check code is regenerated by the verification algorithm and filled into the verification field. Optionally, the verification algorithm can select the general CRC8 algorithm. Then, the unique fields in the first CANFD signal parameter field are removed, including the BRS bit, ESI bit and FDF bit, and the EDL position is set to 0 as the IDE bit (identifying the frame type) in the first CAN signal, and the SOF field, RTR field, ACK field and EOF field are retained, and finally the corresponding multiple first CAN signals are generated.
[0123] As an implementation manner of the present application, the method further includes: constructing the first configuration file according to the following steps:
[0124] Obtain a second configuration file; the second configuration file is used to indicate the mapping relationship information between the CAN FD signal and the original test information;
[0125] Extracting mapping relationship information between description information and CANFD signals from the second configuration file; the description information includes: signal ID, start frame, data length, parameter name and physical quantity;
[0126] Based on the data structure of the CAN signal, adjusting the mapping relationship information between the description information in the second configuration file and the CAN FD signal to obtain the mapping relationship information between the description information in the first configuration file and the CAN signal;
[0127] defining a length of the second data field in the first configuration file based on the target length;
[0128] Specify the alignment of the second data field from the big-endian alignment and the little-endian alignment;
[0129] Adjusting a scaling factor and an offset in the first configuration file based on a difference between a data field length of a CAN FD signal and a data field length of a CAN signal, and specifying a verification method for a physical quantity range, so that a physical quantity obtained by parsing the first CAN FD signal using the second configuration file is the same as a physical quantity obtained by parsing the first CAN signal using the first configuration file;
[0130] A second transmission rate corresponding to the second target message is defined; the second transmission rate is less than or equal to the maximum data transmission rate specified by the CAN protocol.
[0131] In the embodiment of the present application, in order to enable the test bench to correctly parse the second target message sent by the processor, a first configuration file that matches the conversion rules is modified based on the second configuration file, so that the test bench can use the first configuration file to parse the second target message and restore the original test information originally sent by the test object. The specific steps of constructing the first configuration file are as follows:
[0132] (1) Analyze the original DBC file of the CANFD signal (i.e., the second configuration file) and extract the mapping relationship information between the relevant descriptive information and the CANFD signal, such as signal ID, start frame, data length, parameter name, and physical quantity. According to the conversion rules and the data structure of the converted first CAN signal, adjust the mapping relationship information in the second configuration file to generate the mapping relationship information between the CAN signal and the relevant descriptive information. For example, if the length of the parameter field of the signal changes, adjust the symbol sequence corresponding to the relevant descriptive information in the second configuration file, and delete the mapping relationship information of the specific field related to CANFD in the second configuration file;
[0133] (2) Based on the target length of the second data field split in the conversion rule, define the length of the data field of the first CAN signal (e.g., 8 bytes) in the first configuration file;
[0134] (3) Based on the alignment of the second data field after splitting in the conversion rule, define the same alignment in the first configuration file. Optionally, the alignment includes: Motorola (big endian) alignment and Intel (little endian) alignment. Based on the alignment that is the same as the conversion rule, the test bench can correctly parse the first CAN signal according to the first configuration file;
[0135] (4) According to the length of the first data field in the first CANFD signal before splitting and the length of the second data field in the first CAN signal after splitting, adjust the scaling factor and offset of the physical quantity calculation in the CAN signal DBC file (i.e., the first configuration file). Since the length of the data field of the CAN signal is much smaller than the length of the data field of the CANFD signal, the value range of the physical quantity that the first CAN signal can represent is much smaller than the value range of the physical quantity that the first CANFD signal can represent. Based on this, it is necessary to adjust the corresponding scaling factor and offset according to the position of each second data field in the original first data field, so that the test bench can correctly restore the original target physical quantity based on the multiple physical quantities obtained by parsing the second target message. For example, the original CANFD signal (64 bits) is:
[0136] SG_HighPrecision:0|64@1-(0.0001,-1000)[-1000|1000]"m / s 2 "Node
[0137] / / The value range of the physical quantity is "(0.0001,-1000)[-1000|1000]m / s 2 ”
[0138] The converted CAN signal (32 bits) is:
[0139] SG_HighPrecision:0|32@1-(0.001,-100)[-100|100]"m / s 2 "Node
[0140] / / The value range of the physical quantity is "(0.001,-100)[-100|100]m / s 2 ", because the original signal is split due to DLC restrictions, its physical value range may be reduced, so it is necessary to adjust the corresponding scaling factor and offset to restore the original value range;
[0141] (5) Specify the verification method of the physical quantity range to ensure that the target physical quantity obtained by parsing the second configuration file is within a reasonable range, thereby ensuring the normal progress of the subsequent bench test process;
[0142] (6) Since the split first CAN signal is sent by the processor, in order to meet the data transmission rate requirements of the CAN protocol, the sender / receiver of the signal needs to unify the data transmission rate of sending / receiving the first CAN signal. It is worth noting that the sending and receiving rate of the second target message (the second transmission rate) cannot be greater than the maximum data transmission rate specified by the CAN protocol. When the controller sends the second target message and the test bench receives the second target message, the same data transmission rate is used. Optionally, in this embodiment, the second transmission rate (baud rate) is set to 500kbps.
[0143] This embodiment modifies the CAN FD signal's second configuration file to generate a corresponding first configuration file, enabling the test bench to directly use the first configuration file to parse the first CAN signal, thereby improving system interoperability. Furthermore, the standardized first configuration file facilitates rapid deployment and adaptation of the first configuration file to various test bench devices, improving the efficiency of testing of test objects using the CAN FD bus and simplifying the debugging process of the test equipment.
[0144] As an embodiment of the present application, the method further includes:
[0145] The first configuration file is sent to the rack, so that the rack loads the first configuration file and adjusts the data transmission rate of sending the second target message to a second transmission rate based on the first configuration file.
[0146] In this embodiment of the present application, the processor pre-sends a first configuration file to the gantry and adjusts its own data transmission rate for sending CAN signals to the second transmission rate. The gantry then loads the received first configuration file and adjusts its own CAN signal reception rate to the second transmission rate. Based on this, after the processor converts the first target message into the second target message, it sends the second target message at the second transmission rate (e.g., a baud rate of 500 kbps), and the gantry also receives the signal at the same baud rate (500 kbps).
[0147] As an implementation manner of the present application, before sending the second target message to the stand, the method further includes:
[0148] Parsing the first target message using the second configuration file to obtain the original test information;
[0149] Parsing the second target message using the first configuration file to obtain test information to be verified;
[0150] Comparing the original test information with the test information to be verified, and generating an error log if the original test information is different from the test information to be verified;
[0151] Sending the second target message to the rack includes: sending the second target message to the rack when the original test information is the same as the test information to be verified.
[0152] In an embodiment of the present application, after the processor converts the first CANFD signal in the first target message into the corresponding first CAN signal and reconstructs the second target message, before sending the second target message to the test bench, the processor uses the first configuration file to parse the second target message to obtain the test information to be verified. In addition, the first target message is parsed using the second configuration file (DBC file) of the CANFD protocol to obtain the original test information sent by the object under test. The original test information is compared with the test information to be verified to determine whether the second target message currently converted correctly carries the original test information sent by the object under test. When the original test information is the same as the test information to be verified, it is determined that the verification is passed and the second target message is sent to the test bench. By pre-parsing and verifying the converted second target message in the processor, the reliability of the communication between the object under test and the test bench can be ensured, and the probability of the test bench reporting an error is reduced, thereby improving the test efficiency.
[0153] As an implementation manner of the present application, the second target message is parsed using the first configuration file to obtain original test information, including:
[0154] Based on the mapping relationship information between the description information in the first configuration file and the CAN signal, and the parameter field of each first CAN signal, the corresponding parameters are parsed to obtain the corresponding parameters, including: signal ID, start frame, data length, parameter name and physical quantity;
[0155] Based on the alignment, scaling factor, and offset of the second data field in the first configuration file, the physical quantities corresponding to the first CAN signals are combined in ascending order of the signal IDs to obtain a target physical quantity of the response test of the object under test;
[0156] The original test information is obtained based on the target physical quantity and the description information.
[0157] In this embodiment of the present application, after receiving the second target message, the test bench uses the first configuration file to parse the first CAN signal therein. Specifically, the parameter field and second data field in the first CAN signal are read. Based on the mapping relationship between the descriptive information in the first configuration file and the CAN signal, each parameter field and the second data field are parsed to determine the parameter corresponding to the parameter field (for example, the parameter "engine speed") and the physical quantity corresponding to the data field. The physical quantity corresponding to each second data field in the second message is calculated based on the alignment, scaling factor, and offset specified in the first configuration file, along with all the physical quantities corresponding to the CAN FD signal, and then combined to restore the target physical quantity corresponding to the test response of the test subject. For example, if a first CAN FD signal is split into two first CAN signals, the physical quantities parsed from these two first CAN signals are combined and calculated to restore the original test information carried in the first CAN FD signal. Furthermore, based on the obtained target physical quantity and the parameters corresponding to each parameter field, the original test information sent by the test subject is restored. For example, the parsed original test information may be: engine speed 1550 RPM.
[0158] As an implementation manner of the present application, before receiving the second target message sent by the processor, the method further includes:
[0159] receiving a first configuration file sent by the processor and loading the configuration file;
[0160] Based on the first configuration file, the data transmission rate for receiving the second target message is modified to a second transmission rate.
[0161] In one embodiment, the gantry receives a first configuration file from the processor and directly loads it. Based on the data rate defined in the first configuration file, the gantry adjusts the data rate of its own received signals to match that of the processor. After loading, the gantry continuously monitors CAN signals and waits for the second target message from the processor.
[0162] Based on the same inventive concept, an embodiment of the present application provides a bench test system. Figure 4 , Figure 4 Schematic diagram of a bench test system proposed in one embodiment of the present application. Figure 4 As shown, the system includes:
[0163] Including: processor, test bench, and interface module;
[0164] The processor is provided with a signal conversion module for executing the method provided in the above embodiment;
[0165] The test bench is used to perform the method provided in the above embodiment to obtain the target physical quantity of the test object in response to the test; based on the target physical quantity, the test process of the test object is performed;
[0166] The interface module is connected to the object under test, the processor and the test bench respectively, and is used to perform digital-to-analog conversion on the first CAN FD signal and the first CAN signal.
[0167] In an embodiment of the present application, a bench test system includes a processor equipped with a signal conversion module, a bench device for testing, and an interface module for converting analog signals into digital signals. In one embodiment, the processor is a PC and the interface module is a Vector hardware device. The processor is equipped with a signal conversion module written in the CAPL language to convert CANFD messages and generate CAN messages. Optionally, the processor is equipped with a CANoe tool compatible with the Vector hardware device, and the signal conversion module is built based on the CANoe tool.
[0168] The interface module is connected to the object under test, the processor and the test bench respectively, converts the CANFD signal (analog signal) sent by the object under test into a digital signal and sends it to the processor. The signal conversion module in the processor continuously monitors the CANFD message from the interface module during operation, and converts the first target message into a second target message that conforms to the traditional CAN protocol. During the conversion process, the signal conversion module truncates, splits and reorganizes the CANFD signal according to the format restrictions of the CAN protocol to match the data format required by the CAN protocol. The processor sends the second target message at the set data transmission rate, and the interface module converts the first CAN signal (digital signal) sent by the processor into an analog signal and sends it to the test bench.
[0169] In one embodiment, a conversion rule code is written using a CANoe tool to convert a first CAN FD signal into one or more first CAN signals. Some steps are as follows:
[0170] Define variables to store data received from CANFD messages;
[0171] Listen for a specific CANFD message ID;
[0172] Get the data length of the CANFD message;
[0173] Copy data: Repackage the CAN FD message into a standard CAN message according to the 8-byte data length and use the appropriate CAN message ID;
[0174] Copy the data segments into new CAN messages and ensure that the copied data length does not exceed 8 bytes;
[0175] Based on the data field length of the CAN signal, set the DLC (Data Length Code)
[0176] The newly generated first CAN signal is packaged into a CAN message and sent out.
[0177] Regarding the system in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.
[0178] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.
[0179] For the sake of simplicity, the method embodiments are described as a series of action combinations. However, those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all preferred embodiments, and the actions and components involved are not necessarily required by this application.
[0180] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, devices, or computer program products. Therefore, the embodiments of the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the embodiments of the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0181] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.
[0182] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.
[0183] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.
[0184] Although preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they become aware of the underlying inventive concepts. Therefore, this application is intended to include the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.
[0185] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that includes 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 terminal device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or terminal device that includes the element.
[0186] The above is a detailed introduction to the communication method and system based on bench testing provided by the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for general technical personnel in this field, based on the ideas of the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.
Claims
1. A communication method based on bench testing, characterized in that: Applicable to processors, including: Receiving a first target message carrying original test information sent by a test object; the first target message includes a first CANFD signal; the original test information includes: a target physical quantity of a response test of the test object; Converting the first CAN FD signal into at least one first CAN signal according to a conversion rule; Based on all first CAN signals corresponding to the first CAN FD signal, a second target message is generated, and the second target message is sent to the test bench, so that the test bench uses the first configuration file to parse the second target message to obtain the original test information; the first configuration file matches the conversion rule and is used to indicate the mapping relationship information between the first CAN signal and the original test information.
2. The communication method based on bench testing according to claim 1, characterized in that: Converting the first CAN FD signal into at least one first CAN signal according to a conversion rule includes: Obtain a parameter field and a corresponding first data field of the first CANFD signal; the parameter field includes: a frame start field, an identifier field, a remote transmission request field, a control field, a check field, a reception confirmation field, and a frame end field; Sequentially splitting the first data field according to a target length and assigning corresponding signal IDs to obtain at least one second data field; the target length is less than or equal to the maximum length of a data field specified by the CAN protocol; On the basis of the parameter field of the first CAN FD signal, based on each second data field and the corresponding signal ID, in accordance with the data format specified by the CAN protocol, respectively generate a parameter field corresponding to each second data field; combining each second data field with a corresponding parameter field to generate a corresponding first CAN signal; Generating a second target message based on all first CAN signals corresponding to the first CAN FD signal specifically includes: combining the first CAN signals in ascending order of signal ID to obtain the second target message.
3. The communication method based on bench testing according to claim 2, characterized in that: On the basis of the parameter field of the first CAN FD signal, based on each second data field and the corresponding signal ID, according to the data format specified by the CAN protocol, a parameter field corresponding to each second data field is generated, specifically including: generating an identifier field in the parameter field based on the signal ID corresponding to the second data field; Remove the BRS bit, the ESI bit, and the FDF bit in the control field of the first CAN FD signal, set the EDL bit to 0, and update the DLC bit according to the target length to obtain the control field in the parameter field of the first CAN signal; Calculate the check field and the frame start field in the parameter field of the first CAN signal based on the second data field; The remote transmission request field, reception confirmation field and frame end field in the parameter field of the first CAN FD signal are used as the remote transmission request field, reception confirmation field and frame end field in the parameter field of the first CAN signal.
4. The communication method based on bench testing according to claim 2, characterized in that: Also includes: Follow these steps to build the first configuration file: Obtain a second configuration file; the second configuration file is used to indicate the mapping relationship information between the CAN FD signal and the original test information; Extracting mapping relationship information between the description information and the CANFD signal from the second configuration file; The description information includes: signal ID, start frame, data length, parameter name and physical quantity; Based on the data structure of the CAN signal, adjusting the mapping relationship information between the description information in the second configuration file and the CAN FD signal to obtain the mapping relationship information between the description information in the first configuration file and the CAN signal; defining a length of the second data field in the first configuration file based on the target length; Specify the alignment of the second data field from the big-endian alignment and the little-endian alignment; Adjusting a scaling factor and an offset in the first configuration file based on a difference between a data field length of a CAN FD signal and a data field length of a CAN signal, and specifying a verification method for a physical quantity range, so that a physical quantity obtained by parsing the first CAN FD signal using the second configuration file is the same as a physical quantity obtained by parsing the first CAN signal using the first configuration file; A second transmission rate corresponding to the second target message is defined; the second transmission rate is less than or equal to the maximum data transmission rate specified by the CAN protocol.
5. The communication method based on bench testing according to claim 4, characterized in that: Also includes: The first configuration file is sent to the rack, so that the rack loads the first configuration file and adjusts the data transmission rate of sending the second target message to a second transmission rate based on the first configuration file.
6. The communication method based on bench testing according to claim 4 or 5, characterized in that: Before sending the second target message to the rack, the method further includes: Parsing the first target message using the second configuration file to obtain the original test information; Parsing the second target message using the first configuration file to obtain test information to be verified; Comparing the original test information with the test information to be verified, and generating an error log if the original test information is different from the test information to be verified; Sending the second target message to the rack includes: sending the second target message to the rack when the original test information is the same as the test information to be verified.
7. A communication method based on bench testing, characterized in that: Applicable to benches, including: A second target message sent by the receiving processor is obtained by converting a first target message based on the CAN FD protocol sent by the object under test, and includes: at least one first CAN signal; The second target message is parsed using the first configuration file to obtain original test information; the original test information includes: the target physical quantity of the response test of the object under test.
8. The communication method based on bench testing according to claim 7, characterized in that: The second target message is parsed using the first configuration file to obtain original test information, including: Based on the mapping relationship information between the description information in the first configuration file and the CAN signal, and the parameter field of each first CAN signal, the corresponding parameters are parsed to obtain the corresponding parameters, including: signal ID, start frame, data length, parameter name and physical quantity; Based on the alignment, scaling factor, and offset of the second data field in the first configuration file, the physical quantities corresponding to the first CAN signals are combined in ascending order of the signal IDs to obtain a target physical quantity of the response test of the object under test; The original test information is obtained based on the target physical quantity and the description information.
9. The communication method based on bench testing according to claim 7 or 8, characterized in that: Before receiving the second target message sent by the processor, the method further includes: receiving a first configuration file sent by the processor and loading the configuration file; Based on the first configuration file, the data transmission rate for receiving the second target message is modified to a second transmission rate.
10. A bench test system, characterized in that: include: processors, gantry, and interface modules; The processor is provided with a signal conversion module for executing the method according to any one of claims 1 to 6; The test bench is used to perform the method according to any one of claims 7 to 9 to obtain a target physical quantity of a test object in response to a test; and to perform a test process on the test object based on the target physical quantity; The interface module is connected to the object under test, the processor and the test bench respectively, and is used to perform digital-to-analog conversion on the first CAN FD signal and the first CAN signal.