A communication signal test method and device based on a CAN network

Abstract

The application relates to a communication signal test method and device based on a CAN network and belongs to the field of vehicle-mounted ECU node signal testing. The test method comprises the following steps: in step one, the related attributes of a to-be-tested signal are acquired, intermediate variables are acquired in combination with the related attributes, and intermediate variable address information is searched according to the intermediate variables. In step two, based on the related attributes, the intermediate variables and the intermediate variable address information, a CAN communication stack and an XCP protocol stack are called, setting values and receiving values are acquired, and the receiving values are compared with the setting values or standard values. According to the application, the related attributes of a to-be-tested signal are first extracted, then the intermediate variables of the to-be-tested signal are extracted in combination with the related attributes, and the intermediate variable address information is searched according to the intermediate variables, so that the test device can automatically extract a large number of communication signal attributes in an ECU node, the CAN communication stack and the XCP protocol stack of the ECU node are borrowed, and the software of the ECU node does not need additional development.

Description

Technical Field

[0001] This invention belongs to the field of vehicle ECU node signal testing, specifically relating to a communication signal testing method and apparatus based on a CAN network. Background Technology

[0002] In the software development of modern automotive electronic control unit (ECU) nodes, CAN (Controller Area Network) communication is a key technology for enabling information transfer between different modules. Current communication signal testing methods primarily rely on manual testing. This method typically involves using specialized testing equipment to simulate the ECU's signal inputs, observe its response to CAN messages, and verify the transmission accuracy of each signal. While these manual testing processes can ensure signal validity to some extent, in complex ECU systems, due to the large number of messages and signals involved, manual testing is extremely tedious and error-prone. Furthermore, existing testing equipment often lacks automation capabilities, making the testing process inefficient and unable to meet the demands of rapid iteration and high-quality verification.

[0003] Existing communication signal testing methods and devices have significant shortcomings. First, manual testing is not only time-consuming and labor-intensive, but also easily affected by human factors, leading to inconsistent and unreliable test results. Second, with the continuous increase in the functions of ECU nodes, the number of CAN messages and signals that need to be tested has risen sharply. Manual testing methods cannot cover all signals and are prone to overlooking potential problems. Finally, manual testing lacks systematization and standardization, making it difficult to adapt to the rapidly developing automotive electronics technology and increasingly complex testing requirements. In the software development of onboard ECU nodes, such as BMS nodes, dozens of CAN messages and thousands of signals need to be sent and received. Each signal requires the configuration of numerous attributes, such as byte format, start bit, bit length, conversion coefficient, offset, initial value, etc. In total, an ECU node has several thousand to tens of thousands of attribute configurations related to CAN communication signals. Performing signal testing manually to fully test and verify the signal of each CAN message would be an extremely large and difficult testing project. Therefore, there is an urgent need for a communication signal testing method and device based on CAN networks to achieve more efficient and reliable automated testing and ensure the performance and stability of ECU nodes. Summary of the Invention

[0004] The purpose of this invention is to provide a communication signal testing method and apparatus based on a CAN network in order to solve the above-mentioned problems.

[0005] The present invention achieves the above objectives through the following technical solutions:

[0006] A communication signal testing method based on a CAN network, used to test multiple signals to be tested on an ECU node, includes the following steps:

[0007] S1. Obtain relevant attributes of the signal under test by parsing the communication protocol metadata; parse the source code data in combination with the relevant attributes to obtain a specific prefix of the signal under test, and extract intermediate variables of the signal under test from the source code data based on the specific prefix; search for intermediate variable address information from the memory mapping metadata based on the intermediate variables.

[0008] S2. Based on the relevant attributes, intermediate variables, and intermediate variable address information of the signal under test, call the CAN communication stack and XCP protocol stack in the ECU node to obtain the set value and the received value, compare the received value with the set value or standard value, and complete the test of the signal under test.

[0009] In the process of obtaining the setting value and the received value in S2, the type of the signal to be tested is determined. If the signal to be tested is a transmitting signal, the XCP protocol stack is called in sequence for the intermediate value test, the maximum value boundary test and the minimum value boundary test. The setting value is established by modifying the intermediate variable in the ECU node, the CAN communication stack is called, the CAN message data of the setting value is read from the ECU node, and the received value is calculated.

[0010] If the signal to be tested is a received signal, then for the intermediate value test, maximum value boundary test and minimum value boundary test in sequence, the CAN communication stack is called, the setting value is established by modifying the intermediate variable in the ECU node, the CAN communication stack is called, CAN message data is sent to the ECU node, the intermediate variable is modified, the XCP protocol stack is called to mark the intermediate variable, and the received value is formed.

[0011] The CAN communication stack is a communication stack used to handle data interaction between ECU nodes and other nodes. ECU nodes are connected to other nodes via the CAN bus. The XCP protocol stack is a standard protocol for ECU nodes, designed to support ECU calibration, diagnosis, and testing.

[0012] As a further optimization of the present invention, when the signal to be tested is a transmitted signal, the intermediate value test process is as follows:

[0013] Based on the relevant attributes, intermediate variables, and intermediate variable address information of the transmitted signal, the XCP protocol stack in the ECU node is invoked to modify the intermediate variables in the ECU node, thereby establishing the intermediate setting value SettedMidValue of the transmitted signal.

[0014] The CAN communication stack in the ECU node is invoked to read the CAN message data corresponding to the intermediate settedMidValue from the ECU node, and the intermediate received value ReceivedMidValue is calculated by combining the relevant attributes of the transmitted signal.

[0015] The intermediate setting value SettedMidValue of the transmitted signal is compared with the intermediate receiving value ReceivedMidValue. If the intermediate setting value SettedMidValue is the same as the intermediate receiving value ReceivedMidValue, the intermediate value test passes; otherwise, the intermediate value test fails.

[0016] As a further optimization of the present invention, when the signal to be tested is a received signal, the intermediate value test process is as follows:

[0017] Based on the relevant attributes, intermediate variables, and intermediate variable address information of the received signal, the CAN communication stack in the ECU node is called to modify the intermediate variables in the ECU node, thereby establishing the intermediate setting value SettedMidValue of the received signal. The message value corresponding to the intermediate setting value SettedMidValue is calculated in combination with the relevant attributes of the received signal, and the message value is filled into the CAN message data where the received signal is located.

[0018] The CAN communication stack in the ECU node is invoked to send CAN message data to the ECU node, intermediate variables are modified, and the XCP protocol stack in the ECU node is invoked to mark the intermediate variables, forming the intermediate received value ReceivedMidValue of the received signal.

[0019] The intermediate setting value SettedMidValue of the received signal is compared with the intermediate receiving value ReceivedMidValue. If the intermediate setting value SettedMidValue is the same as the intermediate receiving value ReceivedMidValue, the intermediate value test passes; otherwise, the intermediate value test fails.

[0020] As a further optimization of the present invention, the process of the maximum value test is as follows:

[0021] Establish the maximum settable value SettedMaxValue and the maximum received value ReceivedMaxValue of the signal under test. The maximum received value ReceivedMaxValue is established in the same way as the intermediate received value ReceivedMidValue. The signal under test has a maximum standard value MaxValue. Determine whether the maximum standard value MaxValue is the maximum expressible value of the signal under test.

[0022] If the judgment result is "yes", then set SettedMaxValue = MaxValue and analyze whether ReceivedMaxValue and SettedMaxValue are the same; if the judgment result is "no", then set SettedMaxValue = MaxValue + 1 and analyze whether ReceivedMaxValue and SettedMaxValue are the same.

[0023] As a further optimization of the present invention, the minimum value test process is as follows:

[0024] Establish the minimum set value SettedMinValue and the minimum received value ReceivedMinValue of the signal under test. The minimum received value ReceivedMinValue is established in the same way as the intermediate received value ReceivedMidValue. The signal under test has a minimum standard value MinValue. Determine whether the minimum standard value MinValue is the minimum expressible value of the signal under test.

[0025] If the judgment result is "yes", then set SettedMinValue = MinValue and analyze whether ReceivedMinValue and SettedMinValue are the same; if the judgment result is "no", then set SettedMinValue = MinValue - 1 and analyze whether ReceivedMinValue and SettedMinValue are the same.

[0026] As a further optimization of the present invention, the detection of the signal to be tested further includes an initial value test, the process of which is as follows:

[0027] When the signal to be tested is a transmit signal, after the ECU node is powered on, it calls the CAN communication stack to parse the initial receive value ReceivedInitValue of the transmit signal and determines whether the initial receive value ReceivedInitValue is the same as the initial standard value InitValue of the transmit signal.

[0028] When the signal to be tested is the received signal, after the ECU node is powered on, it calls the XCP protocol stack to read the value of the intermediate variable of the received signal and determines whether the value of the intermediate variable is the same as the initial standard value InitValue of the received signal.

[0029] A communication signal testing device based on a CAN network is used to test multiple signals to be tested on an ECU node, including:

[0030] The information extraction module is used to obtain relevant attributes of the signal under test; obtain a specific prefix of the signal under test by combining the relevant attributes, and extract intermediate variables of the signal under test based on the specific prefix; and search for intermediate variable address information based on the intermediate variables.

[0031] The test module is invoked to call the CAN communication stack and XCP protocol stack in the ECU node according to the relevant attributes, intermediate variables and intermediate variable address information of the signal under test, obtain the set value and the received value, compare the received value with the set value or standard value, and complete the test of the signal under test.

[0032] As a further optimization of the present invention, the invocation of the test module includes:

[0033] The CAN driver unit is used to interact with the ECU node via the CAN bus;

[0034] The communication stack calling unit is used to coordinate with the CAN driver unit to call the CAN communication stack of the ECU node;

[0035] The protocol stack calling unit is used to cooperate with the CAN driver unit to call the XCP protocol stack of the ECU node;

[0036] The data processing unit is used to process and analyze the data of the signal under test.

[0037] The beneficial effects of this invention are as follows:

[0038] 1) During testing, the present invention first extracts the relevant attributes of the signal under test, then extracts the intermediate variables of the signal under test in combination with the relevant attributes, and searches for the address information of the intermediate variables based on the intermediate variables, so that the testing device can automatically extract the attributes of a large number of communication signals in the ECU node, with fast testing speed and error-free and full coverage of signal testing;

[0039] 2) When testing the transmitted signal, the present invention uses the method of "XCP protocol stack modification - CAN communication stack reading - verification" for detection. When testing the received signal, the method of "CAN communication stack modification - XCP protocol stack readback - verification" for detection is adopted. The test device calls the existing CAN communication stack and XCP protocol stack of the ECU node, without the need for additional software development of the ECU node. Attached Figure Description

[0040] Figure 1 This is a flowchart of the testing method of the present invention;

[0041] Figure 2 This is a schematic diagram of the testing device structure of the present invention;

[0042] Figure 3 This is a screenshot of the signal attributes in the DBC file. Detailed Implementation

[0043] The present application will now be described in further detail with reference to the accompanying drawings. It should be noted that the following specific embodiments are only used to further illustrate the present application and should not be construed as limiting the scope of protection of the present application. Those skilled in the art can make some non-essential improvements and adjustments to the present application based on the above application content.

[0044] First Embodiment

[0045] like Figure 1 and Figure 2 As shown, this embodiment relates to a communication signal testing method based on a CAN network. This testing method is used to test multiple signals to be tested on an ECU node. The ECU node is connected to a testing device via a CAN bus. The testing device tests the signals to be tested one by one according to their alphabetical order of name. The ECU node internally includes the following modules: a runtime environment system signal module, a communication management module, a PDU routing module, a CAN interface module, a driver module, and an XCP protocol stack. These modules correspond to... Figure 2 The ECU node's CAN communication stack consists of the RTE_SystemSignal module, COM module, PduR module, CANIf module, CAN module, and XCP protocol stack. The COM module, PduR module, CANIf module, and CAN module together constitute the CAN communication stack of the ECU node. The COM module comprises a transmit signal management unit, a receive signal management unit, a transmit PDU unit, and a receive PDU unit. Above the RTE_SystemSignal module, the SWC layer (Software Component) is the application layer.

[0046] The RTE_SystemSignal module generates intermediate variables within the RTE (Run-Time Environment) of the ECU node. The Com module manages the mapping of signals to PDUs (Protocol Data Units) and the transmission of signals under test in the network, providing packetization and depackaging functions between signals and PDUs. The PduR module routes PDUs between different communication modules, ensuring that PDUs from different buses (such as CAN, LIN, and FlexRay) are correctly routed to the target module. The CanIf module provides a CAN bus interface for upper-layer communication modules (such as the Com module), handling the transmission and reception of CAN data frames and managing basic CAN communication services. The Can module handles the actual physical transmission of CAN bus data, executing the sending and receiving of CAN bus frames.

[0047] In addition, the four units within the Com module correspond to Figure 2 The CAN module comprises the ComTxSignal, ComRxSignal, ComTxIPdu, and ComRxIPdu units. The ComTxSignal unit manages signals to be transmitted from the application layer, passing them to the lower layer for packaging and transmission. The ComRxSignal unit manages received signals, unpacking them and passing them to the application layer. The ComTxIPdu unit packages signals to be transmitted into PDUs (Protocol Data Units) and passes them to lower-layer modules (such as the PduR or CanIf modules) for transmission on the CAN network. The ComRxIPdu unit extracts signals from the PDUs received from lower-layer modules (such as the CanIf module), unpacks them into individual signals, and passes them to upper-layer modules (such as the RTE_SystemSignal module).

[0048] The signal under test is divided into a transmitted signal and a received signal. This embodiment takes the transmitted signal as an example. The test method includes the following steps:

[0049] Step S1: Receive communication protocol metadata, source code data, and memory mapping metadata through the data calculation module. Specifically, obtain the DBC file, Rte.c file, and Map file through the test device. The DBC (Database CAN) file is a standard file format for describing communication protocol metadata in the CAN network. RTE is short for Runtime Environment. The Rte.c file is a C code file generated based on the AUTOSAR (Automotive Open System Architecture) model, which is the source code data responsible for implementing communication and data exchange between functional components within the ECU. The Map file is a mapping file, which is memory mapping metadata used to describe the memory distribution and variable allocation of software modules or ECU functions.

[0050] The testing equipment extracts the data received by the data receiving module through its built-in information extraction module. Specifically, it extracts relevant attributes, intermediate variables, and address information of each signal under test from communication protocol metadata, source code data, and memory mapping metadata. These relevant attributes, intermediate variables, and address information constitute the key information of the signal under test. The extraction of this key information involves the following steps:

[0051] 1) Obtain the relevant attributes of the signal under test by parsing the DBC file.

[0052] 2) Combine relevant attributes to parse the Rte.c file, obtain the specific prefix of the signal under test, and extract the intermediate variables of the signal under test from the Rte.c file based on the specific prefix.

[0053] 3) Search for the address information of intermediate variables in the Map file based on the intermediate variables.

[0054] The specific prefixes mentioned above are obtained by the RTE tool that generates the Rte.c file. The RTE tool has corresponding prefix rules when generating specific prefixes. In the actual testing of vehicle ECU node signals, the appropriate RTE tool can be selected to parse the Rte.c file according to the manufacturer's requirements.

[0055] After extracting the key information from the transmitted signal, the following test steps are performed:

[0056] Step S2: Determine the type of the signal under test, clarifying whether it is a transmitting signal or a receiving signal. Based on the relevant attributes, intermediate variables, and intermediate variable address information of the signal under test, call the CAN communication stack and XCP protocol stack in the ECU node to process and analyze the signal under test, obtaining the set value and received value. In this embodiment, a transmitting signal is used as an example, and each signal under test is determined to be a transmitting signal after judgment. The received value is compared with the set value or standard value to complete the test of one signal under test. Then, repeat step S2 above to perform numerical detection on other signals under test. It should be noted that the above received values ​​include the intermediate received value ReceivedMidValue, the maximum received value ReceivedMaxValue, and the minimum received value ReceivedMinValue. The initial received value ReceivedInitValue parsed by the CAN communication stack and the value of the intermediate variable of the received signal read by the XCP protocol stack are also considered received values. The above set values ​​include the intermediate set value SettedMidValue, the maximum set value SettedMaxValue, and the minimum set value SettedMinValue. The above standard values ​​include the maximum standard value MaxValue, the minimum standard value MinValue, and the initial standard value InitValue.

[0057] The numerical detection of the signal under test includes intermediate value testing. During the numerical detection process in step S2, the intermediate value of the transmitted signal is detected using the method of "XCP protocol stack modification - CAN communication stack reading - verification".

[0058] The following example, using the signal SignalTxA, illustrates the entire testing process:

[0059] In step S1, the DBC file, Rte.c file, and Map file are first input into the test device, which consists of a data receiving module, an information extraction module, and a test calling module. The data receiving module receives the DBC file, Rte.c file, and Map file.

[0060] Next, key information from the transmitted signal SignalTxA is extracted. The extraction process is as follows:

[0061] 1) The information extraction module of the test device parses the DBC file and extracts NameA, StartBitA, BitLengthA, FactorA, OffsetA, ByteOrderA, MaxValueA, MinValueA, ValueTypeA, and InitValueA from SignalTxA.

[0062] Wherein, NameA is the signal name of the transmitted signal SignalTxA, StarBitA is the start bit of the transmitted signal SignalTxA, BitLengthA is the bit length of the transmitted signal SignalTxA, FactorA is the conversion factor of the transmitted signal SignalTxA, OffsetA is the offset of the transmitted signal SignalTxA, ByteOrderA is the byte order of the transmitted signal SignalTxA, MaxValueA is the maximum standard value of the transmitted signal SignalTxA, MinValueA is the minimum standard value of the transmitted signal SignalTxA, ValueTypeA is the numeric type of the transmitted signal SignalTxA, and InitValueA is the initial standard value of the transmitted signal SignalTxA.

[0063] 2) The information extraction module uses NameA in conjunction with the Rte.c file to find the intermediate variable RteNameA in the corresponding Rte for the sent signal SignalTxA.

[0064] 3) The information extraction module uses the intermediate variable RteNameA in the Rte and the map file to find the address information RteNameA_Address of the intermediate variable in the Rte.

[0065] In step S2, the signal to be tested is determined to be a transmitted signal, and the transmitted signal SignalTxA is tested as follows:

[0066] ① Testing the median value

[0067] ② Boundary test of maximum value

[0068] ③ Boundary test of minimum value

[0069] ④ Initial value testing

[0070] The intermediate value of SignalTxA can verify the following parameters: StartBitA, BitLengthA, FactorA, OffsetA, ValueTypeA, and ByteOrderA.

[0071] The testing process for intermediate values ​​is as follows:

[0072] 1) The test device, in conjunction with the following relevant attributes of the extracted transmitted signal SignalTxA, RteNameA, RteNameA_Address, BitLengthA, ValueTypeA, confirms the data type of RetNameA (such as uint8 / uint16 / uint32 / sint8 / sin16 / sint32 / float32, etc.), and modifies the intermediate variable RteNameA in the ECU to the intermediate setting value SettedMidValueA by calling the XCP protocol stack;

[0073] 2) The test device calls the test module and the CAN bus to call the CAN communication stack, so that the intermediate setting value SettedMidValueA of the transmitted signal SignalTxA passes through the RTE_SystemSignal module, Com module, PduR module, CanIf module, Can module and CAN bus in sequence before reaching the test device;

[0074] 3) The test device reads the CAN message data where SignalTxA is located, and calculates the intermediate received value ReceivedMidValueA of SignalTxA by combining the attributes StartBitA, BitLengthA, FactorA, OffsetA, ValueTypeA, and ByteOrderA.

[0075] 4) Compare the intermediate setting value SettedMidValueA of the transmitted signal with the intermediate receiving value ReceivedMidValueA. If the intermediate setting value SettedMidValueA is the same as the intermediate receiving value ReceivedMidValueA, the intermediate value test passes; otherwise, the intermediate value test fails.

[0076] The boundary test for the maximum value is as follows:

[0077] Since the dbc file describes the MaxValueA of SignalTxA, which is the maximum value, this property cannot be covered in the test of intermediate values ​​and needs to be tested separately.

[0078] The specific testing process is as follows:

[0079] 1) Establish the maximum settable value SettedMaxValueA and the maximum received value ReceivedMaxValueA of the transmitted signal SignalTxA. The maximum received value ReceivedMaxValueA is established in the same way as the intermediate received value ReceivedMidValueA of the transmitted signal SignalTxA. The signal under test has a maximum standard value MaxValueA. Determine whether the maximum standard value MaxValueA is the maximum expressible value of the signal under test.

[0080] 2) If the judgment result is "yes", then set SettedMaxValueA = MaxValueA, and compare and analyze whether ReceivedMaxValueA and SettedMaxValueA are the same; if the judgment result is "no", then set SettedMaxValueA = MaxValueA + 1, and compare and analyze whether ReceivedMaxValueA and SettedMaxValueA are the same. In the above comparison and analysis, when the analysis result is "the same", the maximum value boundary test passes; when the analysis result is "different", the maximum value boundary test fails.

[0081] The boundary test for the minimum value is as follows:

[0082] Since the dbc file describes the MinValueA of SignalTxA, which is the minimum value, this property cannot be covered in the test of intermediate values ​​and needs to be tested separately.

[0083] The specific testing process is as follows:

[0084] 1) Establish the minimum set value SettedMinValueA and the minimum received value ReceivedMinValueA for the transmitted signal SignalTxA. The method for establishing the minimum received value ReceivedMinValueA is the same as the method for establishing the intermediate received value ReceivedMidValueA of the transmitted signal SignalTxA. The signal under test has a minimum standard value MinValueA. Determine whether the minimum standard value MinValueA is the minimum expressible value of the signal under test.

[0085] 2) If the judgment result is "yes", then set SettedMinValueA = MinValueA, and compare and analyze whether ReceivedMinValueA and SettedMinValueA are the same; if the judgment result is "no", then set SettedMinValueA = MinValueA - 1, and compare and analyze whether ReceivedMinValueA and SettedMinValueA are the same. In the above comparison analysis, when the analysis result is "the same", the maximum value boundary test passes; when the analysis result is "different", the maximum value boundary test fails.

[0086] The initial value test is as follows:

[0087] The initial value InitValueA of SignTxA also needs to be tested separately.

[0088] The specific testing process is as follows:

[0089] After the ECU node is powered on, no XCP calibration is performed. The test device calls the test module and the CAN bus to call the CAN communication stack. It only parses the initial received value ReceivedInitValueA of the transmitted signal through the CAN communication stack and compares it with the initial standard value InitValueA. If the analysis result is "same," the initial value test passes; if the analysis result is "different," the initial value test fails. The order of the test items—intermediate value test, maximum value boundary test, minimum value boundary test, and initial value test—can be adjusted according to actual needs. In actual testing, only some of the above test items can be performed. Then, other signals to be tested are tested according to step S2.

[0090] Second Embodiment

[0091] Please see Figure 1 and Figure 2 This embodiment relates to a communication signal testing method based on a CAN network. Taking the received signal as an example, the first two steps of this embodiment are the same as the previous embodiment. In the third step, the intermediate value of the received signal is detected by the method of "CAN communication stack modification - XCP protocol stack readback - verification".

[0092] The following example, using the received signal SignalRxB, illustrates the entire testing process:

[0093] In step S1, the DBC file, Rte.c file, and Map file are first input into the test device, which consists of a data receiving module, an information extraction module, and a test calling module. The data receiving module receives the DBC file, Rte.c file, and Map file.

[0094] Next, after determining that the signal to be tested is a received signal, key information from the received signal SignalRxB is extracted. The extraction process is as follows:

[0095] 1) The information extraction module of the test device parses the DBC file and extracts the NameB, StartBitB, BitLengthB, FactorB, OffsetB, ByteOrderB, MaxValueB, MinValueB, ValueTypeB, and InitValueB of SignalRxB.

[0096] Wherein, NameB is the signal name of the received signal SignalRxB, StarBitB is the start bit of the received signal SignalRxB, BitLengthB is the bit length of the received signal SignalRxB, FactorB is the conversion factor of the received signal SignalRxB, OffsetB is the offset of the received signal SignalRxB, ByteOrderB is the byte order of the received signal SignalRxB, MaxValueB is the maximum standard value of the received signal SignalRxB, MinValueB is the minimum standard value of the received signal SignalRxB, ValueTypeB is the numeric type of the received signal SignalRxB, and InitValueB is the initial standard value of the received signal SignalRxB.

[0097] 2) The information extraction module uses NameB in conjunction with the Rte.c file to find the intermediate variable RteNameB in the corresponding Rte of the received signal SignalRxB.

[0098] 3) The information extraction module uses the intermediate variable RteNameB in the Rte and the map file to find the address information RteNameB_Address of the intermediate variable in the Rte.

[0099] In step S2, SignalRxB is tested as follows:

[0100] ① Testing the median value

[0101] ② Boundary test of maximum value

[0102] ③ Boundary test of minimum value

[0103] ④ Initial value testing

[0104] The intermediate values ​​of SignalRxB can be used to verify the following parameters: StartBitB, BitLengthB, FactorB, OffsetB, ValueTypeB, and ByteOrderB.

[0105] The testing process for intermediate values ​​is as follows:

[0106] 1) The test device combines the following related attributes of the extracted received signal SignalRxB: RteNameB, RteNameB_Address, BitLengthB, and ValueTypeB, and confirms the data type of RetNameB (such as uint8 / uint16 / uint32 / sint8 / sin16 / sint32 / float32, etc.). First, SignalRxB is set to the physical value SettedMidValueB. Then, combined with the attributes StartBitB, BitLengthB, FactorB, OffsetB, ValueTypeB, and ByteOrderB, the message value of SignalRxB is calculated as SignalTxB_MessageValueB, and filled into the CAN message data where SignalRxB is located.

[0107] 2) The test device calls the CAN communication stack in the ECU node by calling the test module and the CAN bus. SignalTxB_MessageValueB passes through the CAN bus, CAN module, CANIf module, PduR module and COM module, and then reaches the RTE_SystemSignal module to modify the intermediate variable RteNameB.

[0108] 3) The test device reads the value of the intermediate variable RteNameB by calling the test module and the XCP protocol stack in the ECU node through the CAN bus, and marks it as the intermediate received value ReceivedMidValueB;

[0109] 4) Compare the intermediate setting value SettedMidValueB of the received signal with the intermediate receiving value ReceivedMidValueB. If the intermediate setting value SettedMidValueB is the same as the intermediate receiving value ReceivedMidValueB, the intermediate value test passes; otherwise, the intermediate value test fails.

[0110] The boundary test for the maximum value is as follows:

[0111] Since the dbc file describes the MaxValueB of SignalTxB, which is the maximum value, this property cannot be covered in the test of intermediate values ​​and needs to be tested separately.

[0112] The specific testing process is as follows:

[0113] 1) Establish the maximum settable value SettedMaxValueB and the maximum received value ReceivedMaxValueB of the received signal SignalRxB. The maximum received value ReceivedMaxValueB is established in the same way as the intermediate received value ReceivedMidValueB of the received signal SignalRxB. The signal under test has a maximum standard value MaxValueB. Determine whether the maximum standard value MaxValueB is the maximum expressible value of the signal under test.

[0114] 2) If the judgment result is "yes", then set SettedMaxValueB = MaxValueB and compare ReceivedMaxValueB with SettedMaxValueB to see if they are the same; if the judgment result is "no", then set SettedMaxValueB = MaxValueB + 1 and compare ReceivedMaxValueB with SettedMaxValueB to see if they are the same. In the above comparison analysis, when the analysis result is "the same", the maximum value boundary test passes; when the analysis result is "different", the maximum value boundary test fails.

[0115] The boundary test for the minimum value is as follows:

[0116] Since the dbc file describes the MinValueB of SignalTxB, which is the minimum value, this property cannot be covered in the test of intermediate values ​​and needs to be tested separately.

[0117] The specific testing process is as follows:

[0118] 1) Establish the minimum set value SettedMinValueB and the minimum received value ReceivedMinValueB of the received signal SignalRxB. The method for establishing the minimum received value ReceivedMinValueB is the same as the method for establishing the intermediate received value ReceivedMidValueB of the received signal SignalRxB. The signal under test has a minimum standard value MinValueB. Determine whether the minimum standard value MinValueB is the minimum expressible value of the signal under test.

[0119] 2) If the judgment result is "yes", then set SettedMinValueB = MinValueB, and compare and analyze whether ReceivedMinValueB and SettedMinValueB are the same; if the judgment result is "no", then set SettedMinValueB = MinValueB - 1, and compare and analyze whether ReceivedMinValueB and SettedMinValueB are the same. In the above comparison analysis, when the analysis result is "the same", the maximum value boundary test passes; when the analysis result is "different", the maximum value boundary test fails.

[0120] The initial value test is as follows:

[0121] The initial value InitValueB of SignTxB also needs to be tested separately.

[0122] The specific testing process is as follows:

[0123] After the ECU node is powered on, the test device calls the test module and the XCP protocol stack via the CAN bus to read the value of the intermediate variable RteNameB of the received signal and determines whether the value of the intermediate variable RteNameB is the same as the initial standard value InitValueB of the received signal. If the result is "yes", the initial value test passes; if the result is "no", the initial value test fails. Then, other signals to be tested are tested according to step S2.

[0124] Figure 3 The DBC file displays the relevant attributes of the signal under test, where "Name" is the signal name, "Length [Bit]" is the bit length, "Byte Order" is the byte order, "Unit" is the physical unit of the signal or parameter, "Value Type" is the value type, "Init.Value" is the initial value, "Factor" is the conversion factor, "Offset" is the offset, "Minimum" is the minimum value, "Maximum" is the maximum value, and "Value Table" is the value lookup table. In existing technologies, the signals under test in the vehicle CAN network are generally tested one by one through manual search and manual inspection. The shortcomings of this testing scheme are analyzed as follows:

[0125] The number of signals to be tested in an automotive CAN network is large, and each signal has numerous attributes. Manual testing is tedious, time-consuming, and labor-intensive, making it difficult to achieve complete coverage under manual testing conditions. Taking a recent vehicle project's BMS node as an example, there were approximately 2000 signals to be tested, each with about 10 attributes, totaling approximately 20,000 attributes to be tested. If each attribute requires 5 seconds to test manually, it would take approximately 100,000 seconds, or 27 hours. This technical solution also avoids the problems of missed tests and testing errors that are prone to occur in manual testing. In summary, compared with existing manual testing methods, the first and second embodiments have the following advantages:

[0126] 1) Automatic attribute extraction and testing, fast speed, comprehensive coverage, and error-free;

[0127] 2) By leveraging the existing CAN communication stack and XCP protocol stack of the ECU node, no additional software development is required for the ECU node.

[0128] Third Embodiment

[0129] like Figure 2 As shown, this embodiment relates to a communication signal testing device based on a CAN network, which is applicable to the communication signal testing methods in the previous two embodiments. The testing device includes:

[0130] The data receiving module is used to receive DBC files, Rte.c files, and Map files;

[0131] The information extraction module parses the DBC file, Rte.c file, and Map file to extract key information about the signal under test. The module consists of a DBC parsing unit, a variable extraction unit, and an address extraction unit. The DBC parsing unit obtains relevant attributes of the signal under test from the DBC file. The variable extraction unit parses the Rte.c file based on these attributes to obtain a specific prefix of the signal under test and extracts intermediate variables from the Rte.c file based on this prefix. The address extraction unit searches the Map file for the address information of the intermediate variables.

[0132] The test module is invoked to combine key information to call the CAN communication stack and XCP protocol stack in the ECU node to perform numerical detection on the signal under test. The internal structure of the ECU node is described in the first embodiment and will not be elaborated further.

[0133] The signal under test is divided into transmitted and received signals. The numerical detection of the signal under test includes intermediate value testing, maximum value boundary testing, minimum value boundary testing, and initial value testing. During the numerical detection process of calling the test module:

[0134] When the signal being measured is a transmitted signal, the test module is invoked to detect the intermediate value of the transmitted signal using the "XCP protocol stack modification - CAN communication stack reading - verification" method.

[0135] When the measured signal is a received signal, the test module is invoked to detect the intermediate value of the received signal using the method of "CAN communication stack modification - XCP protocol stack readback - verification".

[0136] The test module includes a CAN driver unit, a communication stack invocation unit, a protocol stack invocation unit, and a data processing unit. The CAN driver unit interacts with the ECU node via the CAN bus. The communication stack invocation unit works with the CAN driver unit and the CAN bus to communicate with the ECU node, enabling the invocation of the ECU node's CAN communication stack. The protocol stack invocation unit works with the CAN driver unit and the CAN bus to communicate with the ECU node, enabling the invocation of the ECU node's XCP protocol stack. The data processing unit performs data processing and analysis on the signal under test.

[0137] In the two embodiments described above, during the testing of the transmitted signal SignalTxA, the testing device parses the DBC file, Rte.c file, and Map file through the information extraction module. The communication stack calling unit calls the XCP protocol stack to modify the intermediate variable RteNameA of the transmitted signal SignalTxA to establish a setting value. In each test item, the data processing unit can calculate the intermediate received value ReceivedMidValueA, the maximum received value ReceivedMaxValueA, and the minimum received value ReceivedMinValueA of the transmitted signal SignalTxA. The data processing unit can also compare and analyze the setting values ​​and received values ​​in the intermediate value test, the maximum value boundary test, and the minimum value boundary test, and can compare and analyze the standard value and received value in the initial value test.

[0138] During the testing of the received signal SignalRxB, the testing device parses the DBC file, Rte.c file, and Map file through the information extraction module. The data processing unit, combining the relevant attributes of the received signal SignalRxB, sets the received signal SignalRxB to a physical value and calculates the message value. This message value is then filled into the CAN message data containing SignalRxB. By calling the test module and the CAN bus to access the CAN communication stack in the ECU node, this message value reaches the RTE_SystemSignal module, forming an intermediate variable. This intermediate variable is read through the XCP protocol stack to obtain the received value. By comparing the set value and the received value, the test's success is determined. During the initial value test, the data processing unit only needs to compare the received value with a standard value; this received value is the value of the intermediate variable of the received signal under test read by the XCP protocol.

[0139] The embodiments described above are merely examples of several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention.

Claims

1. A communication signal testing method based on a CAN network, wherein the method is used to test multiple signals to be tested on an ECU node, characterized in that, Includes the following steps: S1. Obtain the relevant attributes of the signal under test; combine the relevant attributes to obtain the specific prefix of the signal under test, and extract the intermediate variables of the signal under test based on the specific prefix; search for the intermediate variable address information based on the intermediate variables; S2. Based on the relevant attributes, intermediate variables, and intermediate variable address information of the signal under test, call the CAN communication stack and XCP protocol stack in the ECU node to obtain the set value and the received value, compare the received value with the set value or standard value, and complete the test of the signal under test. In the process of obtaining the setting value and the received value in S2, the type of the signal to be tested is determined. If the signal to be tested is a transmitting signal, the XCP protocol stack is called in sequence for the intermediate value test, the maximum value boundary test and the minimum value boundary test. The setting value is established by modifying the intermediate variable. The CAN communication stack is called to read the CAN message data of the setting value and calculate the received value. If the signal to be tested is a received signal, then the CAN communication stack is called sequentially for intermediate value testing, maximum value boundary testing, and minimum value boundary testing. The intermediate variables are modified to establish the setting value, the CAN communication stack is called again, CAN message data is sent and the intermediate variables are modified, and the XCP protocol stack is called to mark the intermediate variables to form the received value.

2. The communication signal testing method according to claim 1, characterized in that: When the signal to be tested is a transmitted signal, the intermediate value test procedure is as follows: Based on the relevant attributes, intermediate variables, and intermediate variable address information of the transmitted signal, the XCP protocol stack in the ECU node is invoked to modify the intermediate variables in the ECU node, thereby establishing the intermediate setting value SettedMidValue of the transmitted signal. The CAN communication stack in the ECU node is invoked to read the CAN message data corresponding to the intermediate settedMidValue from the ECU node, and the intermediate received value ReceivedMidValue is calculated by combining the relevant attributes of the transmitted signal. The intermediate setting value SettedMidValue of the transmitted signal is compared with the intermediate receiving value ReceivedMidValue. If the intermediate setting value SettedMidValue is the same as the intermediate receiving value ReceivedMidValue, the intermediate value test passes; otherwise, the intermediate value test fails.

3. The communication signal testing method according to claim 2, characterized in that, When the signal to be tested is a received signal, the intermediate value test procedure is as follows: Based on the relevant attributes, intermediate variables, and intermediate variable address information of the received signal, the CAN communication stack in the ECU node is called to modify the intermediate variables in the ECU node, thereby establishing the intermediate setting value SettedMidValue of the received signal. The message value corresponding to the intermediate setting value SettedMidValue is calculated in combination with the relevant attributes of the received signal, and the message value is filled into the CAN message data where the received signal is located. The CAN communication stack in the ECU node is invoked to send CAN message data to the ECU node, intermediate variables are modified, and the XCP protocol stack in the ECU node is invoked to mark the intermediate variables, forming the intermediate received value ReceivedMidValue of the received signal. The intermediate setting value SettedMidValue of the received signal is compared with the intermediate receiving value ReceivedMidValue. If the intermediate setting value SettedMidValue is the same as the intermediate receiving value ReceivedMidValue, the intermediate value test passes; otherwise, the intermediate value test fails.

4. The communication signal testing method according to claim 3, characterized in that, The process for the maximum value boundary test is as follows: Establish the maximum settable value SettedMaxValue and the maximum received value ReceivedMaxValue of the signal under test. The maximum received value ReceivedMaxValue is established in the same way as the intermediate received value ReceivedMidValue. The signal under test has a maximum standard value MaxValue. Determine whether the maximum standard value MaxValue is the maximum expressible value of the signal under test. If the judgment result is "yes", then set SettedMaxValue = MaxValue and analyze whether ReceivedMaxValue and SettedMaxValue are the same; if the judgment result is "no", then set SettedMaxValue = MaxValue + 1 and analyze whether ReceivedMaxValue and SettedMaxValue are the same.

5. The communication signal testing method according to claim 3, characterized in that, The process for the minimum boundary test is as follows: Establish the minimum set value SettedMinValue and the minimum received value ReceivedMinValue of the signal under test. The minimum received value ReceivedMinValue is established in the same way as the intermediate received value ReceivedMidValue. The signal under test has a minimum standard value MinValue. Determine whether the minimum standard value MinValue is the minimum expressible value of the signal under test. If the judgment result is "yes", then set SettedMinValue = MinValue and analyze whether ReceivedMinValue and SettedMinValue are the same; if the judgment result is "no", then set SettedMinValue = MinValue - 1 and analyze whether ReceivedMinValue and SettedMinValue are the same.

6. The communication signal testing method according to claim 3, characterized in that, The testing of the signal under test also includes an initial value test, the process of which is as follows: When the signal to be tested is a transmit signal, after the ECU node is powered on, it calls the CAN communication stack to parse the initial receive value ReceivedInitValue of the transmit signal and determines whether the initial receive value ReceivedInitValue is the same as the initial standard value InitValue of the transmit signal. When the signal to be tested is the received signal, after the ECU node is powered on, it calls the XCP protocol stack to read the value of the intermediate variable of the received signal and determines whether the value of the intermediate variable is the same as the initial standard value InitValue of the received signal.

7. A communication signal testing device based on a CAN network, the device being used to test multiple signals to be tested on an ECU node, characterized in that, include: The information extraction module is used to obtain the relevant attributes of the signal under test; A specific prefix of the signal under test is obtained by combining the relevant attributes, and intermediate variables of the signal under test are extracted based on the specific prefix; the address information of the intermediate variables is searched based on the intermediate variables. The test module is invoked to call the CAN communication stack and XCP protocol stack in the ECU node according to the relevant attributes, intermediate variables and intermediate variable address information of the signal under test, obtain the set value and the received value, compare the received value with the set value or standard value, and complete the test of the signal under test. In the process of obtaining the setting value and the received value, the type of the signal to be tested is determined. If the signal to be tested is a transmitting signal, the XCP protocol stack is called in turn for intermediate value testing, maximum value boundary testing and minimum value boundary testing. The setting value is established by modifying the intermediate variable. The CAN communication stack is called to read the CAN message data of the setting value and calculate the received value. If the signal to be tested is a received signal, then the CAN communication stack is called sequentially for intermediate value testing, maximum value boundary testing, and minimum value boundary testing. The intermediate variables are modified to establish the setting value, the CAN communication stack is called again, CAN message data is sent and the intermediate variables are modified, and the XCP protocol stack is called to mark the intermediate variables to form the received value.

8. The communication signal testing device according to claim 7, characterized in that, The invocation of the test module includes: The CAN driver unit is used to interact with the ECU node via the CAN bus; The communication stack calling unit is used to coordinate with the CAN driver unit to call the CAN communication stack of the ECU node; The protocol stack calling unit is used to cooperate with the CAN driver unit to call the XCP protocol stack of the ECU node; The data processing unit is used to process and analyze the data of the signal under test.

Images