Automobile network multi-protocol automatic test system and method based on VSpy3

Abstract

The invention discloses an automobile network multi-protocol automatic test method based on VSpy3. The method comprises the following steps of S1, configuration and input reading, S2, data association and information extraction, S3, test case generation based on preset test logic, S4, test case formatting output, S5, test code and observation variable generation, S6, A2L file automatic generation, S7, E2E verification and S8, test instruction automatic execution. The invention further discloses an automobile network multi-protocol automatic test system based on the VSpy3. The system comprises a configuration management module, a multi-source file analysis engine, a data association and integration module, a test strategy execution module and a use case and code generation and graphical user interface. The invention provides the method and the system which can automatically, accurately and comprehensively generate the RTE related test file and execute the automatic test.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic software testing technology. Based on multiple input sources such as interface table files, network signal list files, and routing matrices, it automatically generates RTE software integration test cases, routing and forwarding test cases, test code, and XCP observation variables. Based on the VSpy3 testing platform, it realizes a system and method for automatically testing automotive CAN bus and LIN bus simultaneously using the XCP protocol through the TextAPI interface and the automatically generated test cases. This can effectively achieve fully automated testing of network communication. Background Technology

[0002] As automotive electronic architectures become increasingly complex and software scales up, the workload of software integration testing has increased dramatically. In the AUTOSAR architecture, the Real-Time Interface (RTE) is the core hub connecting application-layer software components and underlying software modules, and the correctness of its interfaces is crucial. Traditional RTE testing primarily relies on engineers manually writing test cases and test code, which has the following significant drawbacks: 1. Inefficient and error-prone: The manual writing process is tedious and time-consuming, and human negligence can easily lead to incomplete test case coverage or data errors.

[0003] 2. Poor consistency: When the interface definition or signal list (such as DBC, LDF, interface table) changes, it is difficult to ensure the consistency between the test cases and code and the latest design document when manually maintaining them, which can easily lead to omissions.

[0004] Third, coverage is difficult to guarantee: Manual programming makes it difficult to systematically cover all signals, especially for complex scenarios such as boundary values, E2E verification, routing and forwarding, network management, and NVM read and write, making it difficult to quantify the sufficiency of testing.

[0005] Fourth, dependence on specific toolchains: Some existing testing tools are often tightly bound to specific testing hardware or software platforms, lacking flexibility and unable to be deeply customized according to the specific signal routing and diagnostic needs of a project.

[0006] 5. The testing process is not repeatable: The manual testing process is difficult to fully reproduce, which is not conducive to problem identification and regression testing.

[0007] VI. Complexity of Multi-Protocol Testing: Automotive networks involve multiple communication protocols such as CAN, LIN, and XCP, making the construction of a unified testing environment technically complex.

[0008] 7. Difficulty in managing test results: Test results rely on manual recording and organization, which is inefficient and prone to errors.

[0009] While some automated testing tools exist in the existing technology, such as CANoe from Vector, these tools are usually expensive, have complex script writing, and high learning costs. Therefore, there is an urgent need in this field for a method and system that can automatically, accurately, and comprehensively generate RTE-related test files and execute automated tests. Summary of the Invention

[0010] The main objective of this invention is to overcome the shortcomings of existing automotive electronic software RTE test case writing and testing processes, which rely on manual labor, are inefficient, prone to errors, and have difficulty in ensuring coverage. This invention proposes an automated testing system and method for automotive network multi-protocol testing based on VSpy3.

[0011] To achieve the above objectives, the present invention provides the following technical solution: An automated testing method for automotive network multi-protocol systems based on VSpy3 includes the following steps: S1. Configuration and Input Reading: Receive user configuration information and load and parse multiple input source files, including software component interface table file, vehicle network signal list file, signal routing matrix file, E2E verification configuration table, and software data type definition file; S2. Data Association and Information Extraction: Association and integration of data from different input sources to build a unified signal information database containing complete context; S3. Generate test cases based on preset test logic: Based on the signal information database built in step S2, automatically generate structured test logic according to the preset test strategy; S4. Test Case Formatting Output: The test logic generated in step S3 is populated and a structured test case document is generated by filling it in according to a predefined template that is both machine-readable and easy for humans to read. S5. Test Code and Observation Variable Generation: Based on the signal list and software interface definition constructed in step S2, a test code framework matching the ECU software architecture is automatically generated. The test code is used to implement the read and write operations of the RTE interface. At the same time, an XCP variable list matching the test cases is generated for observing internal variables through the XCP protocol during the test. S6, Automatic A2L File Generation: Used to achieve real-time observation of internal variables of the ECU, generating the required A2L file based on the XCP variable table automatically generated in step S5; S7, E2E verification: Used to implement E2E verification testing of bus messages, based on the VSpy3 tool and using its C code module; S8. Automated execution of test instructions: During the operation of the embedded system, test actions are converted into instructions that VSpy3 can understand.

[0012] Preferably, in step S3, the test logic includes: Rx signal reception test: For the input signals of the ECU, generate test steps for scenarios such as normal reception of verification signals, default message loss, and event message triggering. Tx signal transmission test: This test procedure generates a verification signal for the ECU's output signal, ensuring that the signal can be correctly transmitted to the bus or internally forwarded to other software modules. E2E Verification Test: For signals configured with E2E (End-to-End) protection, generate test steps to verify the effectiveness of CRC check and Rolling Counter functions; NVM Interface Testing: For non-volatile storage interfaces, generate verification data in both "immediate write" and "sleep write" modes, and test steps to ensure that the data is correctly stored and read after power-on or wake-up from hibernation. Signal / Message Routing Test: Based on the routing matrix, generate test steps to verify that a signal or a complete message can be correctly forwarded from the source network to one or more target networks, and verify the default values ​​when routes are lost; Network management testing: Automatically embed test steps for maintaining network wake-up and sleep mode to ensure the test environment meets specifications.

[0013] Preferably, in step S6, the global variables in the use case are indexed by name and the scalar values ​​in the A2L file loaded in VSpy3, and XCP messages are sent and received through the SetValue and GetValue interfaces to automatically obtain the real-time values ​​of the specified variables.

[0014] Preferably, in step S7, the C code interface of VSpy3 defines a beforeTX interface for each Message to define the processing behavior of each message before it is sent. Before sending messages that require E2E verification, two core operations are performed: the increment operation of the rolling counter and the calculation of cyclic redundancy check (CRC) for a specified bit. The specific process is as follows: First, the system reads the DBC database file, traverses the message information in each network segment, and determines whether each message needs to be checked by CRC. For messages that need to be checked, the system extracts its CRC check bit, rolling counter bit, and data check bit, and establishes a corresponding data structure for storage. Then, for each message's beforeTX interface, the system automatically generates C language code to implement the E2E verification function according to a specific E2E verification algorithm. This code is compiled to generate an executable dynamic link library (DLL) file for VSpy3 to call and execute during bus communication.

[0015] Preferably, in step S1, dynamic column mapping parsing technology is used to process the routing matrix file, which can adaptively identify and parse the columns representing different network channels in the file without relying on fixed column positions.

[0016] Preferably, in step S3, test logic is generated using a signal grouping and parameterization method. Multiple signals under the same message are grouped, and different boundary values ​​are automatically used to test Boolean, enumerated, and numerical signals, thereby improving the coverage and generation efficiency of test cases.

[0017] Preferably, the testing method also supports the automatic insertion of the "detect Fail jump" instruction, which can monitor the test steps within a specified range. If a failure is detected, it will automatically jump to the preset step for retry, thereby enhancing the robustness of automated testing.

[0018] This invention also provides an automated testing system for automotive network multi-protocol systems based on VSpy3, comprising: Configuration management module: Supports two complementary configuration input methods, including a graphical interface interaction mode and a silent configuration file mode; Multi-source file parsing engine: used to load and parse various types of input source files and extract key information; Data association and integration module: used to associate data from different sources and build a unified signal information database; Test strategy execution module: Embedded with multiple test strategies, used to generate original test logic based on the signal information database; Test case and code generation: Used to format and output test logic as test case documents, test code files, and XCP variable tables; Graphical User Interface: Provides a visual interface for configuration, execution, and log viewing.

[0019] Among them, the graphical user interface (GUI) provides an intuitive interface to guide users in completing the input file configuration. The interface has embedded intelligent prompts and is suitable for single generation, parameter debugging and solution verification scenarios.

[0020] In addition, the silent configuration file mode supports loading all parameters through a standardized JSON format configuration file. This mode requires no manual intervention and is easy to integrate with continuous integration / continuous deployment pipelines, enabling fully automated generation of test-related documentation in daily build and code commit trigger scenarios.

[0021] The beneficial effects of this invention are: Compared with the prior art, the present invention has the following significant advantages: 1. Fully automated: It realizes one-click generation of design documents, test cases, test code and observation variables, and fully automates the execution of the test process and the storage of test results, freeing engineers from heavy manual labor and greatly improving efficiency.

[0022] 2. High accuracy and consistency: All outputs are derived from authoritative design input documents, eliminating human copying errors and ensuring strict consistency between test case documents and design documents.

[0023] 3. Comprehensive coverage: It systematically covers various typical and complex scenarios of RTE interface testing, including E2E verification, routing and forwarding, NVM operation, etc., ensuring the depth and breadth of testing.

[0024] 4. Flexible and Customizable: The system can dynamically adjust its output based on the user-provided input file combinations. When the user only provides basic interface files and a network database, the system automatically focuses on generating core RTE signal transmission and reception test cases and code. When the user further provides a routing matrix file, the system intelligently recognizes this input and automatically expands to generate complete signal routing and forwarding test case content. Similarly, when configuring an E2E verification file, the system automatically integrates security verification test scenarios. This ensures a precise match between the output content and the actual project requirements, better adapts to differences in project specifications among different OEMs, and ensures good applicability across projects and platforms.

[0025] 5. Improve software quality: By automatically generating high-coverage tests, interface and data flow issues can be identified early in the development process, significantly improving the reliability and safety of automotive electronic software.

[0026] 6. Enable unified testing of multiple protocols: Based on the VSpy3 platform, it seamlessly integrates testing of multiple automotive network protocols such as CAN, LIN, and XCP (for ECU memory access) into one system, solving the problem of traditionally requiring multiple tools and complex environment setup.

[0027] 7. Enhanced test reliability and accuracy: The correctness of the test excitation signal is ensured by automated E2E checksum and rolling counter injection, guaranteeing the reliability of the test from the source. Real-time automatic interpretation of test results avoids subjective errors and omissions caused by manual interpretation.

[0028] 8. Improve test repeatability and troubleshooting efficiency: Scripted testing processes can be accurately reproduced, facilitating regression testing and problem localization. The "automatic retest" function can automatically retry failed test sequences, saving time for manual intervention and troubleshooting. Attached Figure Description

[0029] Figure 1This is a schematic diagram illustrating the composition of the test document automatic generation module in a specific embodiment of the present invention; Figure 2 This is a flowchart illustrating the creation process of a Vspy3 project, as shown in a specific embodiment of the present invention. Figure 3 This is a flowchart illustrating the automated test execution process in a specific embodiment of the present invention; Figure 4 Examples of test case documents reflecting specific embodiments of the present invention. Figure 1 ; Figure 5 Examples of test case documents reflecting specific embodiments of the present invention. Figure 2 ; Figure 6 Examples of test case documents reflecting specific embodiments of the present invention. Figure 3 ; Figure 7 The image shown is an example of a generated test code file, representing a specific embodiment of the present invention. Detailed Implementation

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

[0031] It should be noted that in the description of this invention, all directional indications (such as up, down, forward, backward, etc.) are only used to explain the relative positional relationship and movement of the components in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indication will also change accordingly.

[0032] Furthermore, in this invention, the use of terms such as "first," "second," etc., is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. In the description of this invention, "a number" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0033] Furthermore, the technical solutions of the various embodiments of the present invention can be combined with each other, but only if they are feasible for those skilled in the art. If the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0034] like Figure 1-7 As shown, an automated testing method for multi-protocol automotive networks based on VSpy3 includes the following steps: S1. Configuration and Input Reading: Receive user configuration information and load and parse multiple input source files; the input source files include: Software component interface table files (such as BCM interface table, VCU interface table). Vehicle network signal list files (such as CAN's DBC file, LIN's LDF file); Signal routing matrix file (such as routing table); E2E Verification Configuration Table (CRC Information Table); Software data type definition files (such as Rte_Type.h, OsCore.c).

[0035] S2. Data Association and Information Extraction: By associating and integrating data from different input sources through key information such as signal name, message ID, and network channel, a unified signal information database containing complete context is constructed. The signal information includes, but is not limited to: signal name, associated message, network type, data length, byte order, start bit, transmission type (periodic / event), period time, E2E verification attribute, signal routing path, data flow direction (input / output), associated software port, etc.

[0036] S3. Generate test cases based on pre-set test logic: Based on the signal information database constructed in step S2, automatically generate structured test logic according to the preset test strategy; the test logic specifically includes: Rx signal reception test: For the input signals of the ECU, generate test steps for scenarios such as verifying normal signal reception, default message loss, and event message triggering; Tx signal transmission test: For the output signals of the ECU, generate test steps to verify that the signal can be correctly sent to the bus or internally forwarded to other software modules; E2E verification test: For signals configured with E2E (End-to-End) protection, generate verification CRC check and Rolling... The test steps for the effectiveness of the counter function include enabling / disabling verification and verification error scenarios; NVM interface testing: for non-volatile storage interfaces, generate test steps to verify that data is correctly stored and read after power-on or sleep-wake in both "immediate write" and "sleep write" modes; signal / packet routing testing: based on the routing matrix, generate test steps to verify that signals or entire packets can be correctly forwarded from the source network to one or more target networks, and verify the default values ​​when routes are lost; network management testing: automatically embed test steps for maintaining network wake-up and entering sleep mode to ensure that the test environment meets the specifications.

[0037] S4. Test Case Formatting Output: The test logic generated in step S3 is populated into a predefined, machine-readable and human-readable template to generate a structured test case document (such as Excel format). Each test case includes elements such as test items, test purpose, operation steps, expected results, and test data.

[0038] S5. Test Code and Observation Variable Generation: Based on the signal list and software interface definition constructed in step S2, a test code framework (such as C code) matching the ECU software architecture is automatically generated; the test code implements the read and write operations of the RTE interface; at the same time, an XCP variable list matching the test cases is generated for observing internal variables through the XCP protocol during the test.

[0039] S6. Automatic A2L File Generation: To achieve real-time observation of ECU internal variables, the required A2L file is generated based on the XCP variable table automatically generated in step S5. Global variables in the test case are indexed by name against the scalar values ​​in the A2L file loaded in VSpy3. XCP messages are sent and received via the SetValue and GetValue interfaces to automatically obtain the real-time values ​​of specified variables. In specific implementations, the ECU needs to integrate XCP slave software to support the host computer's memory access requests. The system first obtains the generated ELF file after the ECU code is compiled; then, a decompilation tool is used to extract DWARF debugging information from the ELF file and convert it into text format for storage. The DWARF file contains multiple Section headers, each recording the corresponding Section's name, type, offset address in the ECU, and size. The system then builds an index dictionary based on the Section header information, which allows for quick location of the Section based on the global variable name. After location, the offset address and data type information of the variable can be obtained from the corresponding Section. The system further queries the type section based on the data type name to obtain the size information of the type, and finally calculates the complete memory address and data type of each global variable, thereby automatically generating an A2L file.

[0040] S7. E2E Verification Function: To implement E2E verification testing of bus messages, this system is based on the VSpy3 tool and uses its C code module for implementation. In the VSpy3 C code interface, a `beforeTX` interface is defined for each `Message`, used to define the processing behavior of each message before transmission. The system uses this interface to perform two core operations before sending messages requiring E2E verification: incrementing the rolling counter and calculating the cyclic redundancy check (CRC) for specified bits. This process is automatically implemented in batches by system scripts. The specific process is as follows: First, the system reads the DBC database file, traverses the message information in each network segment, and determines whether each message needs CRC verification. For messages requiring verification, the system extracts its CRC check bits, rolling counter bits, and data check bits, and establishes corresponding data structures for storage. Subsequently, for each message's `beforeTX` interface, the system automatically generates C language code to implement the E2E verification function according to a specific E2E verification algorithm. The code is compiled to generate an executable dynamic link library (DLL) file, which VSpy3 can call and execute during bus communication.

[0041] S8. Automated Execution of Test Commands: This test requires translating test actions into commands that VSpy3 can understand during the embedded system's operation. VSpy3's TextAPI interface allows access to most of its functions through text editing. For example, the ECU global variable read / write described above is implemented using MEP functionality in conjunction with A2L files, and E2E verification is implemented using AppSignal and C Code configuration. Simultaneously, VSpy3's TextAPI interface provides a channel for communication with external systems. This system uses TCP / IP to establish communication between Python and the host computer, translating individual test case actions into commands for the host computer to achieve automated testing.

[0042] Furthermore, in step S1, dynamic column mapping parsing technology is used to process the routing matrix file, which can adaptively identify and parse the columns representing different network channels in the file without relying on fixed column positions.

[0043] Furthermore, in step S3, test logic is generated using a signal grouping and parameterization method. Multiple signals under the same message are grouped, and different boundary values ​​(such as 0, 1, maximum value) are automatically used to test Boolean, enumerated, and numerical signals, thereby improving test case coverage and generation efficiency.

[0044] Furthermore, the method also supports the automatic insertion of the "detect Fail jump" instruction, which can monitor test steps within a specified range and automatically jump to a preset step for retry if a failure is detected, thereby enhancing the robustness of automated testing.

[0045] The core of this method lies in its automation technology, which connects the entire process from design documents to test implementation. It can automatically parse multiple input files such as interface tables and signal lists, and based on pre-built and comprehensive test engineering theories, it systematically generates comprehensive and flexibly executable test cases that cover boundary values, as well as corresponding test code and XCP observation variable tables. The test cases decompose the macro-level test scenario into a series of fine-grained, indivisible atomic test actions. Each action, such as "writing XCP variables" or "verifying CAN messages," is defined as an independent execution unit. During automated execution, the core responsibility of the test engine is to parse and execute these atomic actions. It only needs to identify the action type and call the corresponding underlying interface to complete the operation, without needing to understand the overall functionality implemented by these actions at the business level. This fundamentally solves the potential disconnect between the testing and design phases, greatly improving the efficiency, accuracy, standardization, and reliability of test development.

[0046] This invention also provides an automated testing system for automotive network multi-protocol systems based on VSpy3, comprising: Configuration management module: Supports two complementary configuration input methods, namely graphical interface interaction mode and silent configuration file mode; The graphical user interface (GUI) provides an intuitive interface, guiding users through form-based filling, drag-and-drop file browsing, and real-time format validation to complete input file configuration. The interface includes intelligent suggestions, significantly lowering the barrier to entry and making it suitable for single-build, parameter debugging, and solution verification scenarios. The silent configuration file mode supports loading all parameters via a standardized JSON configuration file. This mode requires no manual intervention, facilitating integration with continuous integration / continuous deployment pipelines and enabling fully automated generation of test-related documentation for daily builds, code commit triggers, and other scenarios.

[0047] Multi-source file parsing engine: used to load and parse various types of input source files and extract key information.

[0048] Data association and integration module: used to associate data from different sources and build a unified signal information database.

[0049] Test strategy execution module: It embeds multiple test strategies such as Rx, Tx, E2E, NVM, and routing, and is used to generate original test logic based on the signal information database.

[0050] Test Case and Code Generation: Used to format and output test logic as test case documents, test code files, and XCP variable tables.

[0051] Graphical User Interface: Provides a visual interface for configuration, execution, and log viewing.

[0052] Specifically, the present invention aims to achieve the following sub-objectives: 1. Achieve fully automated generation of test-related documents: By building an integrated processing flow, it enables one-click generation of test cases, test code, and xcp observation variables from design input, completely freeing engineers from tedious and repetitive manual writing and verification work, and significantly reducing labor costs and the risk of human error.

[0053] 2. Ensure strict consistency between testing and design: All generated test logic is directly traced back to standard design documents (such as DBC, LDF, interface tables, and routing matrices), ensuring that test cases express the design intent unambiguously and without deviation. This effectively avoids test case errors caused by human misunderstanding or transcription mistakes, and builds a reliable closed loop from design to verification.

[0054] 3. Achieve comprehensive and systematic coverage of test depth and breadth: The embedded test strategy not only focuses on basic signal transmission and reception functions, but also comprehensively covers key and complex test scenarios in the automotive electronics field, including but not limited to E2E security verification, multi-network signal routing and gateway forwarding, successful writing and reading of non-volatile memory (NVM) data (covering immediate write and sleep write modes and corresponding power-on / off, sleep / wake-up recovery logic), event-driven message processing, message loss default value verification, and network management coordination. This method can systematically construct test scenarios to ensure comprehensive verification of RTE interface functions, data flow direction, and data parsing correctness.

[0055] 4. High Flexibility and Adaptability: This invention adopts a configuration-driven architecture, whose parsing logic and generation strategy are independent of specific projects or ECUs. By adjusting the input file path and configuration parameters (such as network channel mapping, sheet table names, signal filtering rules, etc.), it can quickly adapt to different vehicle models, different controllers, or different software architecture changes, possessing strong scalability and engineering reuse value.

[0056] 5. Enhance the intelligence and robustness of automated testing: Innovatively, control instructions such as "detect Fail jump" are automatically embedded in each test item within the generated test sequence. This instruction can monitor the execution status of the current test step interval. When an unexpected failure is encountered, a retest mechanism can be triggered to execute the preset jump logic, thereby enhancing the fault tolerance and stability of long-sequence automated testing and reducing test interruptions caused by non-product reasons.

[0057] 6. Promotes standardization and traceability of test case files: The generated test cases have a unified and standardized structured format, which facilitates team review, management, and archiving. At the same time, because the entire generation process is deterministic, any test case can be clearly traced back to its source design entry, greatly improving the reviewability and quality control level of the testing process.

[0058] 7. Enhancing Testing Process Reliability: To ensure the reliability of specific critical signals sent from the host computer (as the sending node), the system implements an end-to-end protection mechanism, namely E2E verification, designed to prevent accidental data tampering, loss, or duplication during transmission. Its implementation relies on two key technologies: a rolling counter, a sequence value that cyclically changes with a fixed step size (usually incrementing) each time a specific message is sent. The receiver checks the continuity of this value to determine whether a message has been lost or duplicated, thus ensuring the timeliness and sequence integrity of the signal; and CRC (Cyclic Redundancy Check), a checksum calculated based on the message data (including the data check bit and the rolling counter). The receiver recalculates the CRC and compares it with the received checksum to verify whether the data has been corrupted during transmission, thus ensuring signal integrity. Before signal transmission, the system first increments and updates the rolling counter, then uses the signal data and the rolling counter value as input to calculate the CRC. Finally, a complete message containing the data, the rolling counter, and the CRC result is sent. This function is implemented using the C code functionality of VSpy3.

[0059] 8. Fully Automated Testing Process: During test execution, the execution engine calls each instruction sequentially according to the test sequence. The instruction locates the physical address or message definition of the target (signal or variable) through its corresponding index, and then calls the underlying communication driver to execute the specific read and write operations, thereby achieving a fully automated testing process.

[0060] 9. Real-time and Persistent Test Data: The system integrates real-time monitoring and judgment logic for test results into each atomic test action. When a test action (such as writing a signal or reading a variable) is executed, the test engine synchronously monitors the actual value of the target signal or variable specified by the test case and compares it with the expected value, thereby automatically determining whether the execution result of the step is successful or unsuccessful. A dedicated control action is designed within the test cases. This action is defined as automatically checking the execution results of all test actions within a specific sequence range (such as from step A to step B) according to its parameter settings. If there are failed test steps within this range, the system will automatically trigger and execute repeated tests of that test sequence according to a preset strategy, achieving automatic retesting of failed items and saving time spent manually troubleshooting. The system, according to a preset configuration number (such as every 100 test cases completed), saves the execution results of all test cases during this period (including pass / fail status, measured data, timestamps, etc.) as a batch to a designated test result file, achieving phased persistent storage of test data.

[0061] In summary, this invention provides not only an efficiency-enhancing tool, but also a complete, engineering-based solution. By deeply integrating automotive electronics design knowledge with software testing theory, it achieves the intelligent and industrial transformation of test development work, which is of great significance for ensuring the quality and safety of automotive electronic software.

[0062] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A multi-protocol automated testing method for automotive networks based on VSpy3, characterized in that, Includes the following steps: S1. Configuration and Input Reading: Receive user configuration information and load and parse multiple input source files, including software component interface table file, vehicle network signal list file, signal routing matrix file, E2E verification configuration table, and software data type definition file; S2. Data Association and Information Extraction: Association and integration of data from different input sources to build a unified signal information database containing complete context; S3. Generate test cases based on preset test logic: Based on the signal information database built in step S2, automatically generate structured test logic according to the preset test strategy; S4. Test Case Formatting Output: The test logic generated in step S3 is populated and a structured test case document is generated by filling it in according to a predefined template that is both machine-readable and easy for humans to read. S5. Test Code and Observation Variable Generation: Based on the signal list and software interface definition constructed in step S2, a test code framework matching the ECU software architecture is automatically generated. The test code is used to implement the read and write operations of the RTE interface. At the same time, an XCP variable list matching the test cases is generated for observing internal variables through the XCP protocol during the test. S6, Automatic A2L File Generation: Used to achieve real-time observation of internal variables of the ECU, generating the required A2L file based on the XCP variable table automatically generated in step S5; S7, E2E verification: Used to implement E2E verification testing of bus messages, based on the VSpy3 tool and using its C code module; S8. Automated execution of test instructions: During the operation of the embedded system, test actions are converted into instructions that VSpy3 can understand.

2. The automated testing method for automotive network multi-protocol systems based on VSpy3 according to claim 1, characterized in that, In step S3, the test logic includes: Rx signal reception test: For the input signals of the ECU, generate test steps for scenarios such as normal reception of verification signals, default message loss, and event message triggering. Tx signal transmission test: This test procedure generates a verification signal for the ECU's output signal, ensuring that the signal can be correctly transmitted to the bus or internally forwarded to other software modules. E2E Verification Test: For signals configured with E2E (End-to-End) protection, generate test steps to verify the effectiveness of CRC check and RollingCounter counter functions; NVM Interface Testing: For non-volatile storage interfaces, test steps are generated to verify that data is correctly stored and read after power-on or wake-up from sleep mode in both "immediate write" and "sleep write" modes. Signal / Message Routing Test: Based on the routing matrix, generate test steps to verify that a signal or a complete message can be correctly forwarded from the source network to one or more target networks, and verify the default values ​​when routes are lost; Network management testing: Automatically embed test steps for maintaining network wake-up and sleep mode to ensure the test environment meets specifications.

3. The automated testing method for automotive network multi-protocol systems based on VSpy3 according to claim 1, characterized in that, In step S6, the global variables in the use case are indexed by name and the scalar values ​​in the A2L file loaded in VSpy3. XCP messages are sent and received through the SetValue and GetValue interfaces to automatically obtain the real-time values ​​of the specified variables.

4. The automated testing method for automotive network multi-protocol systems based on VSpy3 according to claim 1, characterized in that, In step S7, the C code interface of VSpy3 defines a beforeTX interface for each Message to define the processing behavior of each message before it is sent. Before sending messages that require E2E verification, two core operations are performed: the increment operation of the rolling counter and the calculation of cyclic redundancy check (CRC) for a specified bit. The specific process is as follows: First, the system reads the DBC database file, traverses the message information in each network segment, and determines whether each message needs to be checked by CRC. For messages that need to be checked, the system extracts its CRC check bit, rolling counter bit, and data check bit, and establishes a corresponding data structure for storage. Then, for each message's beforeTX interface, the system automatically generates C language code to implement the E2E verification function according to a specific E2E verification algorithm. This code is compiled to generate an executable dynamic link library (DLL) file for VSpy3 to call and execute during bus communication.

5. The automated testing method for automotive network multi-protocol systems based on VSpy3 according to claim 1, characterized in that, In step S1, dynamic column mapping parsing technology is used to process the routing matrix file, which can adaptively identify and parse the columns representing different network channels in the file without relying on fixed column positions.

6. The automated testing method for automotive network multi-protocol systems based on VSpy3 according to claim 2, characterized in that, In step S3, test logic is generated using a signal grouping and parameterization method. Multiple signals under the same message are grouped, and different boundary values ​​are automatically used to test Boolean, enumerated, and numerical signals, thereby improving test case coverage and generation efficiency.

7. The automated testing method for automotive network multi-protocol systems based on VSpy3 according to claim 1, characterized in that, This testing method also supports the automatic insertion of the "detect Fail jump" command, which can monitor test steps within a specified range. If a failure is detected, it will automatically jump to a preset step for retry, thereby enhancing the robustness of automated testing.

8. An automated testing system for automotive network multi-protocol testing based on VSpy3, characterized in that, include: Configuration management module: Supports two complementary configuration input methods, including a graphical interface interaction mode and a silent configuration file mode; Multi-source file parsing engine: used to load and parse various types of input source files and extract key information; Data association and integration module: used to associate data from different sources and build a unified signal information database; Test strategy execution module: Embedded with multiple test strategies, used to generate original test logic based on the signal information database; Test case and code generation: Used to format and output test logic as test case documents, test code files, and XCP variable tables; Graphical User Interface: Provides a visual interface for configuration, execution, and log viewing.

9. The automated testing system for automotive network multi-protocol systems based on VSpy3 according to claim 8, characterized in that, The graphical user interface provides an intuitive GUI that guides users through the configuration of input files. The interface features built-in intelligent prompts and is suitable for single-generation, parameter debugging, and solution verification scenarios.

10. The automated testing system for automotive network multi-protocol systems based on VSpy3 according to claim 8, characterized in that, The silent configuration file mode supports loading all parameters through a standardized JSON format configuration file. This mode requires no manual intervention and is easy to integrate with continuous integration / continuous deployment pipelines, enabling fully automated generation of test-related documentation in daily build and code commit trigger scenarios.

Images