Vehicle-mounted network end-to-end test method and system based on CANoe

Abstract

The invention relates to the technical field of automobile testing, and particularly discloses a CANoe-based vehicle-mounted network end-to-end testing method and system, and the method comprises the steps: obtaining a to-be-tested demand of a target vehicle, and formulating a test case according to the to-be-tested demand; a test script is written according to the test case, the test script is used for simulating operation changes in the test, and sending, receiving, judgment verification and problem positioning of test data are automatically completed; carrying out an E2E-based automatic test according to the test script, wherein the E2E-based automatic test is used for carrying out encryption protection on test data; and importing a dynamic link library into an E2E-based automatic test for performing test verification on the encrypted test data, calling a CRC calculation method and an adaptive key consistent with the target vehicle through the dynamic link library, generating a security ciphertext for test verification, and outputting a test report after the test is completed. According to the invention, the message data of the target vehicle does not need to be decrypted before the test, and the test efficiency is improved while the security of the message data is protected.

Description

Technical Field

[0001] The present invention relates to the technical field of automotive testing, and particularly to an in-vehicle network end-to-end testing method and system based on CANoe. Background Art

[0002] In today's rapidly evolving automotive industry, the concept of "Software-Defined Vehicle" (SDV) is gradually becoming a key driving force shaping the future. As the role of software technology in vehicle design, development, and user experience optimization becomes increasingly prominent, and the demand from end-users for personalized features and seamless connectivity experiences continues to climb, the SDV concept has received unprecedented attention and development. Against this backdrop, the automotive industry is undergoing four revolutionary trends: electrification, connectivity, intelligence, and sharing. These trends together are driving the industry towards a more sustainable and efficient future. To adapt to and lead this transformation, the automotive electronic and electrical architecture (E / E architecture) is undergoing a profound transformation - from the existing prevalent distributed architecture to a more integrated domain centralized architecture. A key feature of this transformation is the introduction of in-vehicle Ethernet technology, which not only supports higher data transfer rates but also lays the foundation for implementing complex and interconnected intelligent transportation systems. However, as the complexity of in-vehicle networks increases, especially when open standards such as Ethernet are adopted, ensuring the security of communication data has become particularly urgent. In-vehicle Ethernet faces challenges from diverse protocol clusters and has also become a target for potential network security threats. Therefore, the security of communication data in in-vehicle Ethernet is of particular importance.

[0003] The most commonly used communication protocol for vehicle information communication is CAN bus communication. This communication protocol is a single network bus without built-in encryption capabilities. All messages are transmitted in plain text, making them easily intercepted and tampered with, and having a low security level. Since the CAN bus protocol is an ISO international standard serial communication protocol, it has a wide range of applications. To further improve the security of CAN bus communication, two common methods are used in vehicle communication to protect communication security: encrypting message data and performing ECU identity authentication. However, this can only protect data from being tampered with and has relatively low real-time performance, and it cannot identify data duplication and signal sequence errors during transmission.

[0004] Such as in the prior art, such as the automated testing method, device and platform for automobiles with patent application number CN202110995950.2, or a CAN communication automated testing method with patent application number CN202310458605.4. The aforementioned patents all generate automated test cases and write automated test scripts based on current test requirements. At the same time, they also need to decrypt the message data or complete ECU authentication before testing can be performed. From test requirements to writing automated test scripts, in this process, since each brand of vehicle has different ways of encrypting message data and performing ECU authentication, when writing automated test scripts, the vehicle's message data needs to be decrypted, which is time-consuming. Summary of the invention

[0005] The present invention aims to provide an end-to-end vehicle network testing method and system based on CANoe, which can improve the testing efficiency while protecting the security of the message data without decrypting the message data of the target vehicle before testing.

[0006] In order to achieve the above object, the present invention adopts the following technical scheme:

[0007] The first solution is to use the CANoe-based end-to-end vehicle network test method to obtain the test requirements of the target vehicle and formulate test cases based on the test requirements; write test scripts based on the test cases, and the test scripts are used to simulate the operation changes in the test, and automatically complete the sending, receiving, judgment and verification of test data and problem location; carry out E2E-based automated testing according to the test scripts, and the E2E-based automated testing is used to encrypt and protect the test data; import the dynamic link library in the E2E-based automated testing to test and verify the encrypted test data, call the CRC calculation method and adaptation key consistent with the target vehicle through the dynamic link library, and generate a secure ciphertext for test verification, and output the test report after the test is completed.

[0008] Beneficial effects: First, the existing technology needs to decrypt the message data of the target vehicle before testing, which is not only time-consuming, but may also cause test delays due to errors in the decryption process. This solution avoids the decryption step by directly verifying the encrypted test data, thereby greatly shortening the test preparation time. By writing test scripts and using the E2E automated testing mechanism, the test operation is automated. The test script can simulate various operational changes and automatically complete the entire process of sending, receiving, judging and verifying data messages, locating problems, etc., reducing manual intervention and improving test efficiency.

[0009] Secondly, during the testing process, the test data is encrypted and protected through the E2E communication mechanism, avoiding the risk of being intercepted or tampered with during transmission. This encryption mechanism is particularly suitable for complex network environments such as in-vehicle Ethernet, ensuring the security and integrity of the test data. By calling the CRC calculation method and the adaptation key consistent with the target vehicle through dynamic link libraries, secure ciphertext is generated for test verification. This method not only protects the confidentiality of the encryption algorithm but also ensures that the test data verification process is consistent with the actual vehicle operating environment, further enhancing data security.

[0010] Meanwhile, the test scripts avoid the need for direct code modification through system environment variables and various parametric designs. This design enables the test scripts to quickly adapt to different DUTs (Devices Under Test), enhancing the versatility and adaptability of the test system.

[0011] Moreover, the test content is grouped and tested according to the E2E sender, receiver, and state machine, making the testing more systematic and modular. This classification method is not only convenient for management and execution but also enables quick localization of the module where the problem lies, further optimizing the test time and resource allocation. The test report covers the test background, test time, pass / fail statistical information, specific test case details, comparison between the actual and expected results, etc. This detailed report format is not only convenient for testers to analyze the test results but also enables quick identification of problem points, providing a basis for subsequent optimization and repair.

[0012] Subsequently, through automated testing and parametric design, the manual intervention during the testing process is reduced, lowering the labor cost. The systematic testing method and detailed test report can ensure the comprehensiveness and accuracy of the testing, reducing rework caused by test omissions, thus indirectly reducing the testing cost.

[0013] Finally, the E2E communication mechanism based on the AUTOSAR standard protocol conforms to the development trend of the automotive industry. This standardized testing method can better meet the needs of different vehicle models and manufacturers, with broad applicability and promotion value.

[0014] Preferably, the E2E-based automated tests are classified and tested in groups by grouping and testing according to the E2E sender, E2E receiver, and E2E state machine. The E2E-based automated tests are classified and tested in groups by grouping and testing according to the E2E sender, E2E receiver, and E2E state machine; the E2E sender corresponds to the E2E sending test, and the E2E receiver corresponds to the E2E receiving test; among them, the E2E sending test includes CRC&Counter start bit test, Counter initial value test, Counter logic test, Counter boundary test, and CRC algorithm test; the E2E receiving test includes initialization test, forward acceptance test, Counter boundary reception test, Counter boundary overrun reception test, Counter boundary repeated reception test, Counter abnormal loss test, and Counter abnormal loss test.

[0015] Beneficial effects: By classifying the E2E-based automated tests into groups and further refining them into E2E sender tests, E2E receiver tests, and E2E state machine tests, the test process becomes more systematic and modular. This classification method not only facilitates management and execution but also quickly locates the module where the problem lies, further optimizing the test time and resource allocation. At the same time, a variety of specific test items are designed for the sender and receiver respectively, such as CRC&Counter start bit test, Counter initial value test, Counter boundary test, etc., which can comprehensively cover the key links of the E2E communication mechanism, ensuring the comprehensiveness and accuracy of the test, thereby effectively improving the security and reliability of in-vehicle network communication.

[0016] Preferably, an XML document is written according to the test cases, and the XML document is used to classify and display the test cases in a tree structure.

[0017] Beneficial effects: By writing an XML document and classifying and displaying the test cases in a tree structure, visual management of the test cases can be achieved, greatly improving the readability and operability of the test cases. Testers can quickly locate and select the required test cases through the intuitive tree structure, flexibly specify the test scope, thereby improving the flexibility and efficiency of the test. At the same time, it also helps to better organize and manage complex test scenarios, ensuring the systematicness and comprehensiveness of the test work.

[0018] Preferably, a first parameter is set in the test script, and the first parameter includes the observed message ID, in-vehicle bus activation type, network management message ID, partner node message ID, diagnostic message ID and diagnostic response message ID, fault code, and E2E boundary value.

[0019] Beneficial effects: First, by setting a first parameter containing various key parameters in the test script, the test script can be flexibly configured according to different test requirements. These parameters include the observation message ID, in-vehicle bus activation type, network management message ID, partner node message ID, diagnostic message ID and diagnostic response message ID, fault code, and E2E boundary value, etc. This parametric design avoids the need to directly modify the code. Testers can adapt to different test scenarios by simply adjusting the parameter values, greatly improving the generality and flexibility of the test script. There may be differences in communication protocols, message formats, and function implementations among components of different vehicles. By setting the first parameter, the test script can quickly adapt to these differences, ensuring that the test process can accurately test different components, thereby improving the adaptability of the test.

[0020] Second, the first parameter covers the key information that needs to be concerned during the test process. For example, the observation message ID is used to specify the message to be detected, the diagnostic message ID and diagnostic response message ID are used to configure the diagnostic module to read the fault code, and the fault code is used to judge the correctness of the test sample at the receiving end during the test, etc. The setting of these parameters enables the test script to comprehensively cover the test requirements and ensure that no key link is missed during the test process. By configuring these parameters in detail, the test script can accurately locate problems during the test process. For example, through the setting of the observation message ID and E2E boundary value, the test script can accurately detect abnormal phenomena during the message transmission process, such as repeated sending, abnormal sending, and missing sending, etc., so as to quickly discover problems and conduct analysis.

[0021] Moreover, since the test script adapts to different test requirements through parametric configuration, testers do not need to directly modify the code. They only need to adjust the parameter values through the configuration file or system environment variables. This method greatly reduces the workload of code modification and reduces the error risk caused by code modification, thereby improving the test efficiency. When the test requirements change, for example, when testing new vehicle components or adjusting the test scope, testers can quickly adapt to the new requirements by simply modifying the parameter configuration without having to rewrite the test script. This quick adaptation ability makes the test process more efficient and can better meet the rapidly iterative test requirements.

[0022] At the same time, the first parameter is managed through system environment variables, and these variables can be used globally without being restricted by the function scope. This global parameter management method makes the configuration and modification of parameters more centralized and convenient, enhancing the maintainability of the test script. By abstracting the test requirements into parameters, the code structure of the test script is clearer and the logic is more concise. Testers can set parameters through the configuration file or parameter panel without delving into the code details, which not only reduces the complexity of the code but also makes the test script easier to understand and maintain.

[0023] Subsequently, testers can set parameters through the configuration file or the parameter panel of CANoe. These tools provide an intuitive interface, making parameter configuration more visual and convenient to operate. Testers can easily view and modify parameter values without directly editing the code, which greatly improves the user experience of testing.

[0024] Preferably, the method of converting a string to an array is adopted to configure the first parameter. The array length is dynamically set in the corresponding test script according to the observed message ID in the test case. The array length is used to adapt to the number of observed message IDs in the components of different target vehicles.

[0025] Beneficial effects: First, in actual in-vehicle network testing, components of different vehicles may have different numbers and types of observed message IDs. By adopting the method of converting a string to an array, the array length can be dynamically adjusted according to the number of observed message IDs in the test case, ensuring that the test script can flexibly adapt to various vehicle components. This dynamic adaptation ability enables the test script to avoid modifying the code separately for each component, greatly improving the generality of the script. Preferably, the dynamic link library is used to call the CRC calculation method and adaptation key consistent with the target vehicle. The cyclic redundancy check code CRC is generated by combining the adaptation key and the calculation data generated using the CRC calculation method. The CRC is used to verify whether the CRC bit data of the test data is consistent. If the CRC bit data is consistent, the data is correctly transferred during the transmission process; otherwise, if it is inconsistent, the data transfer is incorrect. Since the test script can adapt to different test requirements by dynamically configuring parameters, the repetitive development work caused by vehicle component differences is reduced. Testers only need to adjust the setting of the observed message ID through the configuration file or parameter panel without having to rewrite or modify the test script, thus saving time and effort.

[0026] Second, adopting the method of converting a string to an array allows testers to define the observed message ID in the configuration file in string form and automatically convert it to an array by the program. This configuration method is more flexible and concise than hard-coding the array directly in the code, simplifying the parameter configuration process. By dynamically setting the array length, the test script can automatically adjust the parameter configuration according to the actual test requirements without having to pre-define an array with a fixed length. This flexibility enables the test script to better handle complex test scenarios, such as verifying multiple observed message IDs simultaneously, without worrying about insufficient or redundant array lengths.

[0027] Meanwhile, during the testing process, test requirements may change. For example, some observation message IDs may need to be added or deleted. Testers are allowed to quickly adjust the parameter configuration by simply modifying the strings in the configuration file without modifying the code and recompiling the test script. This quick adaptation ability significantly improves the testing efficiency and shortens the test preparation time. Since the test script can adapt to different test requirements by dynamically configuring parameters, the workload of script maintenance caused by changes in test requirements is reduced. Testers can centrally manage parameters through the configuration file without delving into the code for modification, thus reducing the maintenance cost.

[0028] Finally, the use of dynamic arrays makes it more convenient to expand the functions of the test script. For example, when new test functions need to be added or new message formats need to be supported, testers only need to add the corresponding observation message IDs in the configuration file without modifying the core logic of the script, thereby enhancing the scalability of the test system.

[0029] Preferably, the CRC algorithm is designed according to Counter, DataID, and the data field; among them, Counter is used to count the sending behavior of the message data of the target vehicle in automated testing, and initialize the count for the first sending behavior of the target vehicle. Then, each time the target vehicle performs a sending behavior, the count increases by the same value successively on the basis of the initial count; Counter has a maximum value. When the count reaches the maximum value, the next time the target vehicle performs a sending behavior, it starts to loop back to the initial count, and the first abnormal phenomenon of the test data is monitored through the Counter count.

[0030] Beneficial effects: First, by calling the CRC calculation method and the adapted key consistent with the target vehicle, a cyclic redundancy check code (CRC) is generated to verify whether the CRC bit data of the test data is consistent. This method can ensure the accuracy and consistency of the data during the testing process. Only when the CRC bit data is consistent is the data transmission considered correct, thus effectively avoiding possible errors in data transmission. Using the CRC calculation method and key consistent with the target vehicle makes the test verification process highly consistent with the actual vehicle operation environment. This consistency ensures the reliability and effectiveness of the test results, enabling the test to truly reflect the communication status of the vehicle during actual operation.

[0031] Secondly, the CRC calculation method is called through a dynamic link library, encapsulating the algorithm logic in the dynamic link library, which protects the confidentiality of the encryption algorithm. This approach makes the algorithm unviewable and editable, thus preventing the risk of algorithm tampering or leakage and further enhancing data security. The CRC verification mechanism can detect whether the data has been tampered with or forged during transmission. If the data is tampered with during transmission, the CRC check will fail, enabling the timely detection of data anomalies and ensuring the integrity and reliability of the test data.

[0032] Meanwhile, by calling the CRC calculation method through a dynamic link library, the test script can automatically complete the verification of encrypted data. This automated verification mechanism reduces manual intervention, improves test efficiency, and avoids verification errors caused by human mistakes. The CRC verification mechanism can quickly detect errors in data transmission, helping testers quickly locate the problem. For example, if the CRC check fails, testers can immediately know that there is a problem in the data transmission process and further analyze the cause, thereby improving the accuracy and efficiency of the test.

[0033] Subsequently, the CRC verification mechanism meets the requirements for the E2E communication mechanism in the AUTOSAR (Automotive Open System Architecture) standard protocol. This standardized verification method not only ensures the compatibility and generality of the test system but also conforms to the development trend of the automotive industry, enabling the test system to better adapt to the needs of different vehicle models and manufacturers.

[0034] Finally, through the CRC verification mechanism, the test system can quickly detect errors in data transmission at an early stage, thus avoiding unnecessary subsequent test steps and resource waste. This efficient error detection mechanism enables more reasonable allocation of test resources and improves the overall test efficiency. Since CRC verification can ensure the correctness of data transmission, testers can perform subsequent test steps with more confidence, reducing repeated tests caused by data errors and thus saving time and resources.

[0035] Preferably, the first abnormal phenomenon includes repeated sending, abnormal sending, and sending omission.

[0036] Beneficial effects: Counter is not only used to count the sending behavior of the target vehicle message data but can also quickly locate potential problems by detecting abnormal changes in the count value (such as phenomena like repeated sending, abnormal sending, and sending omission), thus ensuring the integrity and accuracy of data transmission. This mechanism can effectively prevent data tampering and transmission errors, especially in complex in-vehicle network environments with high security requirements, providing an important guarantee for vehicle network security.

[0037] Preferably, the test report includes the test background, test time, total number of passes and fails, pass and fail ratios, specific test case details, actual test results, expected results, problem point location, name of the sample under test, test time, test personnel, test case name, test case duration, comparison between test expectations and actual test results, and test pass / fail items.

[0038] Beneficial effects: By specifying the detailed content of the test report, including the test background, time, pass rate, test case details, comparison between actual and expected results, problem point location, etc., it provides a comprehensive and detailed basis for test result analysis for testers. This detailed report format not only facilitates testers to quickly understand the overall situation of the test but also accurately locates problem points, thereby improving test efficiency, ensuring the comprehensiveness and accuracy of the test, and providing strong support for subsequent optimization and repair work.

[0039] Second solution, a vehicle network end-to-end test system based on CANoe, characterized in that it is used to execute the vehicle network end-to-end test method based on CANoe described in the first solution, including: an acquisition module, which writes test cases according to industry standards and enterprise specifications and forms a test case set; a test script generation module, which converts the test cases generated by the use case specification module into executable test scripts; the script module supports parameterized configuration to adapt to the test scenarios of vehicle components from different manufacturers; a vehicle communication test module, which performs end-to-end communication security tests on the CAN bus through an automated test process; a test data analysis module, which collects the message data generated by the test module in real time during the test, parses and determines whether the test cases pass; a report output module, which automatically generates a test report according to the results of the data problem analysis module. Description of the Drawings

[0040] Figure 1 It is a schematic diagram of the vehicle network end-to-end test method based on CANoe in Embodiment 1; Figure 2 It is a schematic diagram (a) of setting up a test environment in Embodiment 3; Figure 3 It is a schematic diagram (b) of setting up a test environment in Embodiment 3. Detailed Embodiments

[0041] Next, embodiments of the technical solution of the present invention will be described in detail with reference to the drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, so they are only examples and cannot be used to limit the protection scope of the present invention.

[0042] It should be noted that unless otherwise specified, the technical terms or scientific terms used in this application should have the ordinary meaning understood by those skilled in the art to which the present invention belongs.

[0043] Markings in the drawings of the specification:

[0044] Test computer 1, CANoe device 2, programmable power supply 3, DUT (Device Under Test) 4, DB9 interface 5, resistor 6.

[0045] A further description of the embodiment is as follows:

[0046] The AUTOSAR (Automotive Open System Architecture) standard protocol proposes an in-vehicle Ethernet end-to-end communication mechanism (E2E). E2E can protect safety-related data exchanges and avoid errors caused by the communication link during data exchange. It adds functions such as counting, timeout detection, and CRC cyclic redundancy check, and solves security problems such as data duplication and signal sequence errors during signal transmission.

[0047] Embodiment 1

[0048] This embodiment provides an in-vehicle network end-to-end test method based on CANoe, including the following content;

[0049] As Figure 1 shown, obtain the test requirements of the target vehicle, and formulate test cases according to the test requirements. The test requirements of the target vehicle can be obtained according to test standards, enterprise specifications for manufacturing the target vehicle, or user requirements. In this embodiment, test cases are formulated according to the AUTOSAR Specification of SW-C End to-End Communication Protection Library standard, and written into test cases according to the E2E message control field format and related requirements of the standard.

[0050] Write an XML document according to the test cases. The XML document is used to display the test cases in a tree structure. Specifically, group the test cases in a master-slave mode. Under one main test case, there are multiple sub-test cases. Write the XML document in a tree structure mode. The visual interface for inputting test cases displays each main test case and the multiple sub-test cases included below in a tree form. The tester checks the test cases through the visual operation interface and specifies the test scope separately. This improves test flexibility, operation convenience, saves test time, and improves efficiency.

[0051] Write a test script according to the test case. The test script is used to simulate the operation changes in the test, and the operation changes are used to analyze the test data and locate problems. Specifically, in one implementation, the test script is developed according to the test case operation process by CAPL language. The test script participates in the entire process of the actual test operation, and the entire process of the test operation includes the sending, receiving, judgment and verification of passing conditions, data analysis, problem location, summarizing the test result pass / fail, and outputting the test report.

[0052] In this embodiment, a first parameter is set in the test script. The first parameter includes the observation message ID, in-vehicle bus activation type, network management message ID, partner node message ID, diagnostic message ID, diagnostic response message ID, fault code, and E2E boundary value. Among them, the observation message ID refers to the E2E message sent by the DUT (Device Under Test), and this E2E message is detected; the in-vehicle bus activation type is divided into two types. The first type is represented by K15 (key ignition (ACC) signal) activation, and the second type is represented by network management message activation. Different activation methods are performed according to the setting of the activation type. For example, for K15 activation, the program-controlled power supply interface is called to power on the power supply, and for network management message activation, the ignition activation is completed by periodically sending network management messages; the diagnostic message ID and diagnostic response message ID are used to configure the diagnostic module to read the fault code, and the fault code can judge the correctness of the DUT during the receiver test. For example, if the DUT receives an incorrect E2E message and reaches the condition for triggering the fault code, check whether the fault code exists through the diagnostic response message, which is considered a test pass. Set the above-mentioned first parameter in the configuration file, set the corresponding second parameter in the corresponding variable configuration panel, assign the first parameter of the configuration file to the system environment variable through CAPL code, and set the corresponding second parameter by the system environment variable. The advantage of extracting the first parameter into the system environment variable is that it can be used globally without being affected by the function scope, and the system environment variable has a separate parameter panel in CANoe, where the data type, maximum and minimum values, initial value, etc. are set on the panel, making it more operable; secondly, the tester configures the project test data through the configuration file. This method avoids directly modifying the code in subsequent tests, improves code security, and at the same time, the test script adapts to different actual DUTs by modifying the first parameter. The DUT can be a specific component on the target vehicle.

[0053] One of the keys to the E2E automated test system is the first parameter configuration. Only when the process of the first parameter configuration is simpler can convenient automated testing be achieved. E2E testing first needs to observe the message ID. The observed message IDs and quantities of different samples to be tested are different. In this embodiment, the method of converting a string to an array is adopted to configure the observed message ID, and the array length can be dynamically set according to the observed message ID configured in the configuration file to adapt to the different requirements of the observed message ID quantities of different vehicle parts. The first step is to assign a single or multiple observed message IDs to the observed message variable in the first parameter in the form of a string in the configuration file of the ini file type. Multiple observed message IDs are separated by an English comma. The second step is to read the observed message variable through the file parameter reading function in the CAPL code. The third step is to call the function of the string conversion array method. The input parameters of this function are the input string, the result array, and the special delimiter. The output of this function is the length of the result array; the string read in the second step is used as the first sub-parameter, the array storing the observed message ID is used as the second sub-parameter, and the special delimiter is the English comma as the third sub-parameter. Through the calculation of the function, the string is cut with the English comma as the delimiter, and the cut data IDs are sequentially stored in the result array. Finally, the obtained result array is traversed, and the corresponding E2E test is performed on each observed message ID in the array. The above method can effectively match the E2E test requirements of different vehicle parts. For the samples to be tested with multiple observed message IDs, multiple observed message IDs can be verified simultaneously during the test, greatly reducing the test time cost. The message IDs are separated by an English comma in the form of a string in the configuration file and converted into a dynamic array in the code, optimizing the configuration method of multiple observed message IDs, making the ID configuration method more accurate, reducing the parameter configuration time, improving the test efficiency, reducing the subsequent code changes of the test system, and better adapting to various samples to be tested.

[0054] Carry out E2E-based automated testing according to the test script. The E2E-based automated testing is used to encrypt and protect the test data. Specifically, running the test engineering file containing the test script can perform the automated testing of the E2E communication security mechanism for the CAN bus. The test data recorded during the test will be stored in the corresponding files respectively at the start and end of each test case, named according to the test case and the test time. During the process of carrying out the E2E-based automated testing, the test data is collected and parsed in real time. The test data is message data and is analyzed according to the passing standard of the test case to judge whether this test case passes. If it does not pass, problem analysis and positioning will also be carried out to achieve an accurate and rapid test effect.

[0055] In the E2E-based automated testing, a dynamic link library is imported to test and verify the encrypted test data, and a test report is output after the test is completed. Specifically, in the E2E-based automated testing, by importing the dynamic link library, the algorithm functions in the test script can be dynamically compiled. By using the dynamic link library to adapt to various environments and call conditions, the logic of function calls is simplified, and the algorithm is protected so that it cannot be viewed or edited. In this embodiment, the test data is encoded and encrypted by the CRC algorithm, and the encryption algorithm is compiled to generate a dynamic link library. Subsequent test verification can be completed by adding the dynamic link library.

[0056] Specifically, three parameters are used in the CRC algorithm function. The first parameter is the enterprise-specified key, which can be adapted to different vehicle factory suppliers. When different keys are input for the first parameter, the calculated ciphertexts are all different; the second parameter is the plaintext to be spliced for algorithm calculation. The CRC calculation requires Counter, DataID, and the data field. Counter is a counter used to count the sending behavior of the signal group. For the sending end, after initialization, when transmitting for the first time, the Counter value should be initialized to 0x00; after each sending, the Counter value is incremented by 1; when the Counter value reaches the maximum value of 0xE, the next sending should start from 0x0 and loop (i.e., 0xF will be skipped). E2E compares the current data with the Counter value in the last valid data received to monitor whether the data is resent, abnormally sent, or missing. DataID is a specific ID for the protected signal. This element will not be reflected in the data field of the message but will be used in the CRC calculation. Finally, the ciphertext is in the form of a pointer, and the function outputs the ciphertext in digital form.

[0057] The E2E-based automated testing is classified and tested by group. Group testing is performed according to the E2E sender, E2E receiver, and E2E state machine. The E2E sender corresponds to the E2E send test, the E2E receiver corresponds to the E2E receive test, and the E2E state machine corresponds to the E2E State Machine test.

[0058] The E2E send test includes the CRC&Counter start bit test, Counter initial value test, Counter logic test, Counter boundary test, and CRC algorithm test.

[0059] The E2E receive test includes the initialization test, forward acceptance test, Counter boundary receive test, Counter boundary overrun receive test, Counter boundary duplicate receive test, Counter abnormal loss test, and Counter abnormal loss test.

[0060] The E2E State Machine tests include E2E_SM_NODATA test, E2E_SM_INIT test, E2E_SM_VALID test, and E2E_SM_INVALID test.

[0061] Specifically, the CRC&Counter start bit test is used to verify whether the data matrix information of crcOffset and counterOffset is correct during the E2E data transmission process. The Counter initial value test is used to verify whether the initial value of Counter in the E2E data sender is correct. The Counter logic test is used to verify whether the Counter increment logic during the E2E data transmission process is correct. The CRC algorithm test is used to verify whether the CRC content is correct during the E2E data transmission.

[0062] The initialization test is used to confirm the initialization state of the receiver. The forward acceptance test is used to verify the forward acceptance mechanism of Counter and CRC during the E2E data transmission process. The Counter boundary reception test is used to verify the boundary reception of the Counter data segment in the transceiver messages under the E2E mechanism. The Counter boundary overrun reception test is used to verify the boundary overrun reception of the Counter data segment in the transceiver messages under the E2E mechanism. The Counter boundary repeated reception test is used to verify the repeated reception of the Counter data segment in the transceiver messages under the E2E mechanism. The Counter abnormal loss test is used to verify the reception logic of the Counter abnormal loss frame number less than maxDeltaCounter during the E2E data transmission process. The CRC error reception test is used to verify the error reception logic of CRC during the E2E data transmission process.

[0063] The test report includes the test background, test time, total number of passes and fails, pass and fail ratios, specific test case details, actual test results, expected results, problem point location, name of the tested sample, test time, test personnel, test case name, test case duration, comparison between test expectations and actual test results, and test pass / fail item.

[0064] Beneficial effects of this embodiment

[0065] This embodiment does not require decrypting the message data of the target vehicle. It can call the message data for corresponding tests when the message data of the target vehicle is in an encrypted state, which not only protects the encryption algorithms of each vehicle enterprise of different brands for the corresponding message data, but also does not require the vehicle enterprise to provide corresponding decryption tools for testing, ensuring the security of data encryption in the stages of layer-by-layer development, use, and testing, and fundamentally protecting the encryption of different data messages of each vehicle model. At the same time, it can achieve accurate and efficient testing without cracking its encryption algorithm, and is applicable to the end-to-end testing of in-vehicle networks based on CANoe for vehicles of multiple different brand vehicle enterprises.

[0066] First of all, the prior art needs to decrypt the message data of the target vehicle before testing, which not only takes time but also may cause test delays due to errors in the decryption process. This embodiment directly verifies the encrypted test data, avoiding the decryption step, thus significantly shortening the test preparation time.

[0067] Secondly, by writing test scripts and using the E2E automated test mechanism, the automation of test operations is achieved. The test scripts can simulate various operation changes and automatically complete all process operations such as sending, receiving, judgment verification, and problem location of data messages, reducing manual intervention and improving test efficiency.

[0068] Moreover, the test contents are grouped and tested according to the E2E sender, receiver, and state machine, making the test more systematic and modular. This classification method is not only convenient for management and execution, but also can quickly locate the module where the problem lies, further optimizing the test time and resource allocation. At the same time, during the test process, the test data is encrypted and protected through the E2E communication mechanism, avoiding the risk of being intercepted or tampered with during transmission. This encryption mechanism is especially suitable for complex network environments such as in-vehicle Ethernet, ensuring the security and integrity of the test data. Then, the CRC calculation method and adaptation key consistent with the target vehicle are called through dynamic link libraries to generate secure ciphertext for test verification. This method not only protects the confidentiality of the encryption algorithm, but also ensures that the verification process of the test data is consistent with the actual vehicle operating environment, further enhancing data security.

[0069] Immediately afterwards, the test cases are written as XML documents and classified and displayed in a tree structure, making the management and selection of test cases more intuitive and convenient. Testers can check the test cases through the visual operation interface and specify the test scope separately, improving the flexibility of the test and the convenience of operation. Moreover, the test scripts are parameterized designed through system environment variables and configuration files, avoiding the need to directly modify the code. This design enables the test scripts to quickly adapt to different tested samples, enhancing the versatility and adaptability of the test system.

[0070] Then, by using Counter to count and monitor the sending behavior of test data, abnormal phenomena during data transmission can be effectively detected, such as repeated sending, abnormal sending, and missing sending, etc. This mechanism provides strong support for quickly locating problems, helping to promptly discover and solve potential problems. At the same time, the test report covers test background, test time, passing and failing statistical information, specific test case situations, comparison between actual and expected results, etc. This detailed report format not only facilitates testers to analyze test results but also quickly locates problem points, providing a basis for subsequent optimization and repair.

[0071] Moreover, through automated testing and parameterized design, manual intervention in the testing process is reduced, and labor costs are lowered. The systematic testing method and detailed test report can ensure the comprehensiveness and accuracy of testing, reduce rework caused by missed testing, and thus indirectly reduce testing costs.

[0072] Finally, the E2E communication mechanism based on the AUTOSAR standard protocol conforms to the development trend of the automotive industry. This standardized testing method can better meet the needs of different vehicle models and manufacturers, and has wide applicability and promotion value. With the increasing complexity of in-vehicle networks, especially the introduction of in-vehicle Ethernet, network security threats have become increasingly prominent. In this embodiment, through technical means such as encryption protection and dynamic link libraries, network security challenges are effectively addressed, providing strong guarantee for the security of in-vehicle network communication.

[0073] Embodiment 2

[0074] This embodiment provides an in-vehicle network end-to-end test system based on CANoe, which is used to execute the in-vehicle network end-to-end test method based on CANoe described in Embodiment 1, and includes: an acquisition module, which writes test cases according to industry standards and enterprise specifications and forms a test case set; a test script generation module, which converts the test cases generated by the use case specification module into executable test scripts; the script module supports parameterized configuration to adapt to the test scenarios of in-vehicle parts from different manufacturers; a vehicle communication test module, which conducts end-to-end communication security testing on the CAN bus through an automated testing process; a test data analysis module, which collects the message data generated by the test module in real time during the testing process, parses and determines whether the test cases pass; a report output module, which automatically generates a test report according to the results of the data problem analysis module.

[0075] In this embodiment, by integrating an acquisition module, a test script generation module, a vehicle communication test module, a test data analysis module, and a report output module, the entire process automation from test case writing to test report generation is achieved, significantly improving the efficiency and accuracy of end-to-end communication security testing for in-vehicle networks. At the same time, it supports parameterized configuration to adapt to test scenarios of different manufacturers, enhancing the flexibility and versatility of testing, and effectively ensuring the security and reliability of in-vehicle communication systems.

[0076] Embodiment III

[0077] This embodiment provides a test circuit module, which can only carry out corresponding tests after being connected. Specifically, as Figure 2 and Figure 3 , a test environment is set up. The CANoe device is connected to a test computer with a test system and the device under test. At the same time, the device under test is connected to a programmable power supply. The CANoe unit has two wires, CAN-H and CAN-L, through a DB9 interface, which are connected in parallel with the high and low interfaces of the device under test, and both ends are connected through a resistor with a resistance value of 120 ohms. The device under test is respectively connected in parallel with relays K30 and K15 to the positive pole of the programmable power supply, and the ground wire is connected to the negative pole of the programmable power supply.

[0078] In this specification, a large number of specific details are described. However, it can be understood that the embodiments of the present invention can be practiced without these specific details. In some instances, well-known methods, systems, and technologies are not shown in detail so as not to obscure the understanding of this specification. In the description of this specification, the description with reference to terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, methods, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of this specification.

[0079] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered by the scope of the claims and the specification of the present invention.

Claims

1. An end-to-end testing method for in-vehicle networks based on CANoe, characterized in that obtain the test requirements of the target vehicle, and formulate test cases according to the test requirements; write a test script according to the test cases, and the test script is used to simulate the operation changes in the test, and automatically complete the sending, receiving, judgment verification and problem location of the test data; carry out E2E-based automated testing according to the test script, and the E2E-based automated testing is used to encrypt and protect the test data; import a dynamic link library in the E2E-based automated testing, which is used to test and verify the encrypted test data, call the same CRC calculation method and adaptation key as the target vehicle through the dynamic link library, and generate a secure ciphertext for test verification. After the test is completed, a test report is output.

2. The method for end-to-end testing of in-vehicle networks based on CANoe according to claim 1, wherein The E2E-based automated testing is classified and tested by group; specifically, it is grouped and tested according to the E2E sender, E2E receiver and E2E state machine; the E2E sender corresponds to the E2E send test, and the E2E receiver corresponds to the E2E receive test; among them, the E2E send test includes CRC&Counter start bit test, Counter initial value test, Counter logic test, Counter boundary test and CRC algorithm test; The E2E receive test includes initialization test, forward acceptance test, Counter boundary receive test, Counter boundary overrun receive test, Counter boundary repeated receive test, Counter abnormal loss test and Counter abnormal loss test.

3. The vehicle network end-to-end test method based on CANoe according to claim 1, wherein A first parameter is set in the test script, and the first parameter includes an observed message ID, an in-vehicle bus activation type, a network management message ID, a partner node message ID, a diagnostic message ID and a diagnostic response message ID, a fault code and an E2E boundary value.

4. The vehicle network end-to-end test method based on CANoe according to claim 3, wherein, The method of converting a string to an array is adopted to configure the first parameter, and the array length is dynamically set in the corresponding test script according to the observed message ID in the test case, and the array length is used to correspondingly adapt to the number of observed message IDs in the parts of different target vehicles.

5. The vehicle network end-to-end test method based on CANoe according to claim 1, wherein, The dynamic link library is used to call the same CRC calculation method and adaptation key as the target vehicle, and combine the calculation data generated by using the CRC calculation method according to the adaptation key to generate a cyclic redundancy check code CRC. The CRC is used to verify whether the CRC bit data of the test data is consistent. If the CRC bit data is consistent, the data is correctly transmitted during the transmission process; otherwise, if it is inconsistent, the data is transmitted incorrectly.

6. The method for end-to-end testing of in-vehicle networks based on CANoe according to claim 5, wherein The CRC algorithm is designed according to Counter, DataID and the data field; Among them, Counter is used to count the sending behavior of the message data of the target vehicle in the automated test, and initialize the count for the first sending behavior of the target vehicle, and then each time the target vehicle executes a sending behavior, the same value is incremented in sequence on the initialized count; The Counter count is assigned a maximum value. When the count reaches the maximum value, the next time the target vehicle performs a sending action, the loop restarts and returns to the initial count. The Counter count is used to monitor whether there is a first abnormal phenomenon in the test data.

7. The vehicle network end-to-end test method based on CANoe according to claim 6, wherein The first abnormal phenomenon includes repeated sending, abnormal sending, and sending omission.

8. The method for end-to-end testing of in-vehicle networks based on CANoe according to claim 1, wherein, The test report includes the test background, test time, total number of passes and fails, pass and fail ratios, specific test case details, actual measurement results, expected results, problem point location, name of the sample under test, test time, test personnel, test case name, test case duration, comparison between test expectations and actual measurement results, and test pass / fail item.

9. The end-to-end test method for in-vehicle network based on CANoe according to claim 1, characterized in that An XML document is written according to the test case, and the XML document is used to display the test cases in a tree structure.

10. An in-vehicle network end-to-end test system based on CANoe, characterized in that, For implementing the CANoe-based in-vehicle network end-to-end test method according to any one of claims 1-9, it includes: An acquisition module, which writes test cases according to industry standards and enterprise specifications and forms a test case set; A test script generation module, which converts the test cases generated by the use case specification module into executable test scripts; the script module supports parameterized configuration and adapts to the test scenarios of in-vehicle components from different manufacturers; A vehicle communication test module, which performs end-to-end communication security tests on the CAN bus through an automated test process; A test data analysis module, which collects the message data generated by the test module in real time during the test process, parses and determines whether the test case passes; A report output module, which automatically generates a test report according to the results of the data problem analysis module.

Images