A test method of a vehicle networking protocol

Abstract

The application provides a test method of a vehicle networking protocol, which comprises the following steps: obtaining test parameters configured by a user through a user interaction layer, and converting the test parameters into structured configuration data; a protocol definition model analyzes the structured configuration data based on a pre-defined protocol specification, and generates a test case definition file; a message simulator generates simulated message data according to a message template in the test case definition file; an automatic test framework executes the simulated message data to obtain test results; and the user interaction layer formats the test results into readable reports and outputs the reports. The application realizes test automation and hardware-free, and greatly improves test efficiency, accuracy and protocol adaptability.

Description

Technical Field

[0001] This application relates to intelligent connected vehicles and the field thereof, and in particular to a testing method for a vehicle networking protocol. Background Technology

[0002] With the rapid development of intelligent connected vehicles, communication protocols within vehicles and between vehicles and the cloud are becoming increasingly complex and heterogeneous, encompassing in-vehicle bus protocols (such as CAN and LIN), diagnostic protocols (such as UDS), and numerous proprietary protocols from OEMs and terminal manufacturers. This highly fragmented protocol ecosystem presents severe challenges to system development, testing, and maintenance.

[0003] Currently, related testing mainly relies on the following technical means: First, hard-coded test scripts, requiring developers to manually write test code for each protocol, resulting in long development cycles, high maintenance costs, and difficulty in adapting to rapid protocol iterations; second, general-purpose network tools (such as Wireshark and Scapy), which can construct network packets but cannot understand complex protocol semantics and struggle to handle dynamic field dependencies or automatically calculate checksums; third, commercial testing platforms (such as CANoe), which are powerful but expensive, closed systems, and difficult to integrate and customize; fourth, open-source general-purpose frameworks (such as JMeter plugins), which only support simple communication and lack protocol semantic understanding and deep assertion capabilities; and fifth, real hardware dependency testing, which is costly, inefficient, has an uncontrollable environment, and presents security risks and scalability bottlenecks.

[0004] These existing technologies generally suffer from fundamental problems such as severe protocol coupling, lack of semantic understanding, weak assertion capabilities, low generation efficiency, and insufficient test reliability, which cannot meet the needs of efficient, accurate, and reusable automated testing of vehicle networking protocols. Summary of the Invention

[0005] In view of this, this application provides a testing method for vehicle networking protocols, which realizes test automation and hardware-free testing, greatly improving testing efficiency, accuracy and protocol adaptability.

[0006] In a first aspect, embodiments of this application provide a testing method for a vehicle-to-everything (V2X) protocol. The method is applied to a V2X protocol testing system, which includes a protocol definition model, a message simulator, an automated testing framework, and a user interaction layer. The method includes:

[0007] The user-configured test parameters are obtained through the user interaction layer, and the test parameters are converted into structured configuration data.

[0008] The protocol definition model parses the structured configuration data based on predefined protocol specifications to generate test case definition files, which include message templates, verification rules, and test logic.

[0009] The message simulator generates simulated message data based on the message template in the test case definition file;

[0010] The automated testing framework executes the simulated message data to obtain test results, which include test status, logs, and performance metrics.

[0011] The user interaction layer formats the test results into a readable report and outputs it.

[0012] In one possible implementation, the protocol definition model parses the structured configuration data based on a predefined protocol specification to generate a test case definition file, including:

[0013] The protocol specification is converted into a standardized internal protocol model using a multi-format parser; the structured configuration data is converted into standardized configuration objects.

[0014] A mapping relationship model is determined based on the standardized protocol internal model and the standardized configuration object. The mapping relationship model includes the correspondence between each test case and protocol element, as well as the test data values ​​after protocol conversion.

[0015] The message template set, the verification rule set, and the test logic set are determined based on the mapping relationship model.

[0016] A test case definition file is generated based on the message template set, the verification rule set, and the test logic set.

[0017] In one possible implementation, the message simulator generates simulated message data based on the message template in the test case definition file, including:

[0018] Parse the message template in the test case definition file to obtain a message template object, which includes the field definitions and attribute information of all fields;

[0019] The dynamic expression fields in the message template object are replaced with dynamic field values ​​by the expression evaluation engine in the message simulator; the dynamic expression fields are fields that need to be determined by calculation or reference to context variables.

[0020] The field generator in the message simulator converts the fields to be generated in the message template object into generated field values ​​according to the preset rules of the test cases; the fields to be generated are fields that need to automatically generate specific data according to test requirements.

[0021] The verification calculator in the message simulator converts the verification-related fields in the message template object into verification field values. The verification-related fields are fields used to ensure message integrity and correctness.

[0022] The message builder in the message simulator concatenates the byte sequences of each field into a complete binary message based on preset byte offsets and byte order.

[0023] In one possible implementation, replacing the dynamic expression field in the message template object with a dynamic field value through the expression evaluation engine in the message simulator includes:

[0024] The expression evaluation engine identifies the dynamic expression field in the message template object and constructs an expression syntax tree set based on the expression syntax of the dynamic expression field.

[0025] The dynamic field value of each dynamic expression field is calculated by traversing the nodes in the expression syntax tree set.

[0026] Replace the dynamic field value with the corresponding dynamic expression field of the message template object.

[0027] In one possible implementation, the step of converting the fields to be generated in the message template object into generated field values ​​by the field generator in the message simulator according to the preset rules of the test cases includes:

[0028] The field generator identifies the fields that need to be generated in the message template object, and generates a policy mapping table corresponding to the fields that need to be generated according to the preset rules of the test cases. The policy mapping table includes the generation policy, generator instance and configuration parameters for each field that needs to be generated.

[0029] The generation algorithms for each field to be generated are executed sequentially through the strategy mapping table to obtain the generated field values ​​transformed from the corresponding generated fields.

[0030] Replace the generated field value with the corresponding field that needs to be generated in the message template object.

[0031] In one possible implementation, the verification calculator in the message simulator converts the verification-related fields in the message template object into verification field values. These verification-related fields are used to ensure message integrity and correctness, and include:

[0032] The verification calculator identifies the verification-related fields in the message template object and parses them to obtain the algorithm configuration information for each verification-related field;

[0033] Perform verification calculations based on the algorithm configuration information to generate verification field values ​​corresponding to the transformation of the verification-related fields;

[0034] Replace the value of the verification field with the corresponding verification-related field of the message template object.

[0035] In one possible implementation, the automated testing framework executes the simulated message data to obtain test results, which include test status, logs, and performance metrics, including:

[0036] The automated testing framework executes the simulated message data and obtains the response data corresponding to the simulated message data. The response data includes the response message, the receiving timestamp, the response time, and performance data.

[0037] The response data is verified according to the verification rules to obtain the test results of the simulated message data.

[0038] Secondly, embodiments of this application also provide a testing system for vehicle networking protocols, the system including a protocol definition model, a message simulator, an automated testing framework, and a user interaction layer;

[0039] The user interaction layer is used to obtain the test parameters configured by the user and convert the test parameters into structured configuration data;

[0040] The protocol definition model is used to parse the structured configuration data based on predefined protocol specifications and generate test case definition files, which include message templates, verification rules, and test logic.

[0041] The message simulator is used to generate simulated message data based on the message template in the test case definition file.

[0042] The automated testing framework is used to execute the simulated message data to obtain test results, which include test status, logs, and performance metrics.

[0043] The user interaction layer is used to format the test results into a readable report and output it.

[0044] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor and the memory communicate via the bus, and the machine-readable instructions are executed by the processor to perform the steps of the test method for the vehicle networking protocol of the first aspect.

[0045] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when run by a processor, executes the steps of the test method for the vehicle networking protocol described in the first aspect.

[0046] This application provides a testing method for a vehicle-to-everything (V2X) protocol. The method includes: obtaining user-configured test parameters through a user interaction layer and converting the test parameters into structured configuration data; a protocol definition model parsing the structured configuration data based on predefined protocol specifications to generate a test case definition file; a message simulator generating simulated message data according to message templates in the test case definition file; an automated testing framework executing the simulated message data to obtain test results; and the user interaction layer formatting the test results into a readable report and outputting it. This application achieves test automation and hardware-free testing, greatly improving testing efficiency, accuracy, and protocol adaptability.

[0047] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0048] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0049] Figure 1 A flowchart illustrating a testing method for a vehicle networking protocol provided in an embodiment of this application is shown;

[0050] Figure 2 This application provides a flowchart illustrating the generation process of test case definition files.

[0051] Figure 3 A flowchart illustrating the generation process of simulated message data provided in an embodiment of this application is shown;

[0052] Figure 4 A schematic diagram of the structure of a test system for a vehicle networking protocol provided in an embodiment of this application is shown;

[0053] Figure 5 A schematic diagram of the structure of the computer device provided in the embodiments of this application is shown. Detailed Implementation

[0054] The terms "first," "second," and "third," etc., used in this application specification, claims, and the aforementioned drawings are used to distinguish different objects, not to limit a specific order.

[0055] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner to facilitate understanding.

[0056] In the description of this application, unless otherwise stated, " / " indicates that the objects before and after it are in an "or" relationship. For example, A / B can mean A or B. "And / or" in this application is merely a description of the relationship between the related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone, where A and B can be singular or plural. Furthermore, in the description of this application, unless otherwise stated, "multiple" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0057] In the embodiments of this application, at least one can also be described as one or more, and multiple can be two, three, four or more, and this application does not impose any restrictions.

[0058] like Figure 1 As shown in the figure, this application provides a flowchart of a testing method for a vehicle-to-everything (V2X) protocol. This method is applied to a testing system for V2X protocols, which includes a protocol definition model, a message simulator, an automated testing framework, and a user interaction layer. The testing method for V2X protocols provided in this application may include:

[0059] S101. Obtain the test parameters configured by the user through the user interaction layer, and convert the test parameters into structured configuration data.

[0060] In this embodiment, the user inputs test parameters to the user interaction layer through a visual parameter configuration interface or command line. These parameters include: protocol type (e.g., CAN, FlexRay, SOME / IP), test scenario (e.g., normal communication, error injection, performance testing), target device address (e.g., IP address, port number), test case selection (e.g., specific message ID or service), and other configurations (e.g., timeout, number of repetitions). The user interaction layer receives the user-input test parameters, validates them, and converts them into structured configuration data (e.g., JSON or XML format) to ensure parameter validity and completeness. For example, it checks whether the protocol type is supported and whether the device address format is correct. The user interaction layer then passes the converted structured configuration data to the next step, the protocol definition model.

[0061] S102. The protocol definition model parses the structured configuration data based on the predefined protocol specifications and generates a test case definition file, which includes message templates, verification rules, and test logic.

[0062] In this application, the protocol specification is a collection of formal technical documents describing the standardized features and behaviors of vehicle network communication protocols. It defines the data exchange format, timing requirements, state transition rules, and error handling mechanisms between communication entities. In this application, the protocol specification adopts a structured description method, specifically including: (1) Communication protocol metadata: protocol name, version identifier, applicable scenarios, compatibility description; (2) Message / frame format definition: frame header structure, identifier rules, data length, control bit definition; (3) Signal / field specification: physical location of data fields, data type, scaling factor, offset, valid value range, unit information; (4) Timing and behavioral constraints: transmission cycle, response timeout, retry mechanism, state transition rules; (5) Service interface definition: service identifier, method parameters, response format, service quality requirements.

[0063] A message template is a standardized message structure definition generated based on protocol specifications. It specifies the components and filling rules of a test message. A message template is not a specific message instance, but a blueprint describing how to construct a message. Core components: (1) Message structure definition: The hierarchical structure of the message, including components such as header, payload, and trailer; (2) Field template: The position, size, data type, and encoding method of each field; (3) Data filling rules: The source of field values ​​(fixed values, expressions, generation rules, and related calculations); (4) Dynamic element definition: The calculation method of dynamically generated fields such as timestamp, sequence number, and checksum; (5) Format conversion instructions: Conversion rules for various representation formats such as binary, hexadecimal, and Base64.

[0064] Verification rules are a set of criteria used to evaluate the correctness and compliance of the response of the system under test. They define the evaluation dimensions and judgment conditions of the test results. Core components: (1) Data correctness verification rules: a. Exact match verification: The response data must be completely consistent with the expected value; b. Range matching verification: The response data must be within the specified valid range; c. Pattern matching verification: The response data must conform to a specific format or pattern; d. Existence verification: Specific fields or flags must exist; (2) Timing performance verification rules: a. Response time verification: The response must be completed within the specified time; b. Timing relationship verification: The time interval between multiple responses must meet the requirements; c. Real-time verification: Key responses must meet real-time constraints; (3) Protocol compliance verification rules: a. Message structure verification: The response message format must conform to the protocol specification; b. State transition verification: The transition of the protocol state machine must be correct; c. Error handling verification: Error responses must conform to the protocol definition; (4) Business logic verification rules: a. Functional correctness verification: The system function must be executed as expected; b. Data consistency verification: Related data must be logically consistent; c. Boundary condition verification: Boundary value handling must be correct.

[0065] Test logic is the control logic definition that describes the execution flow, step sequence, condition judgment, and exception handling of test cases. It specifies the execution path and behavior of the test. Core components: (1) Test execution flow control: a. Linear execution flow: Steps are executed in sequence; b. Branch execution flow: Different execution paths are selected according to conditions; c. Loop execution flow: Some steps are repeatedly executed until the conditions are met; d. Parallel execution flow: Multiple steps are executed simultaneously; (2) Test step definition: a. Precondition setting step: Prepare the test execution environment; b. Test action execution step: Send request, receive response, and process data; c. Verification judgment step: Execute verification rules and record results; d. Cleanup and recovery step: Restore the system to the initial state; (3) State management logic: a. Test state initialization: Set the initial test state; b. State transition control: Update the state according to the test results; c. State dependency management: Handle the state dependency relationship between steps; (4) Exception handling logic: a. Exception detection mechanism: Identify the exception situation in the test execution; b. Exception recovery strategy: Define the handling method after the exception occurs; c. Error retry mechanism: Specify the retryable operation and retry strategy; (5) Data management logic: a. Test data preparation: Generate or obtain test data; b. Data flow control: Manage the flow and transformation of test data; c. Result data recording: Save the test process and result data.

[0066] Here, the protocol specification is the technical foundation, defining the standards and constraints of communication. Message templates are blueprints for message construction based on the protocol specification; verification rules are response evaluation criteria based on the protocol specification; test logic is test execution control based on business requirements; the protocol definition model combines structured configuration data with the protocol specification to generate test case definition files containing message templates, verification rules, and test logic, forming a complete testing solution. This separation of concerns design allows each component to be developed, maintained, and reused independently, while also effectively collaborating to complete complex vehicle-to-everything (V2X) protocol testing tasks.

[0067] Specifically, refer to Figure 2 The diagram shown is a flowchart of the test case definition file generation process provided in this application embodiment. The specific implementation steps are as follows:

[0068] S201. Convert the protocol specification into a standardized protocol internal model through a multi-format parser; convert structured configuration data into standardized configuration objects.

[0069] In this embodiment, the multi-format parser converts the protocol specification file into a standardized internal protocol model using a corresponding parser according to the protocol specification format (such as DBC, ARXML, etc.). This internal protocol model contains all elements defined by the protocol, such as messages, signals, and services, and their attributes (such as message ID, signal length, offset, scaling factor, etc.). The multi-format parser parses the structured configuration data and extracts test requirements, including the protocol elements to be tested (e.g., message ID or signal name), test scenario types (e.g., normal, abnormal, boundary), test data (e.g., signal values), and expected results.

[0070] Among them, the protocol specification document is a digital carrier that stores and describes the technical specifications of the vehicle-to-everything (V2X) communication protocol. It comprehensively records the technical details, data formats, and behavioral rules of the communication protocol in a standardized file format. The protocol specification document is the core input of the protocol definition model, providing authoritative technical basis for automated testing.

[0071] S202. Determine the mapping relationship model based on the standardized protocol internal model and standardized configuration objects. The mapping relationship model includes the correspondence between each test case and protocol element, as well as the test data values ​​after protocol conversion.

[0072] In this embodiment, the protocol elements specified in the configuration object (e.g., by message name or ID) are matched and associated with corresponding elements in the protocol's internal model. Simultaneously, the test data provided in the configuration is converted into raw values ​​in the protocol's internal model (e.g., physical values ​​are converted to raw values, taking into account scaling and offset). This step ensures that each test case is bound to the correct protocol element and that the test data conforms to the protocol definition.

[0073] S203. Determine the message template set, verification rule set, and test logic set based on the mapping relationship model.

[0074] In this embodiment, the message template set includes request message templates and expected response message templates. The construction of the message template set is directly based on each test case in the mapping relationship model, its associated protocol elements, and the converted test data values. The mapping relationship model is traversed, and for each test case, its corresponding test data values ​​are extracted and filled in according to the field positions and formats specified in the protocol to form a request message template. Simultaneously, based on the response rules defined in the protocol specification and combined with the expected output of the test case, the expected response message template is automatically derived and generated. The message template fully defines the overall architecture of the message, covering the generation rules and filling logic of static fields (such as protocol identifiers, frame types, and other fixed information) and dynamic fields (such as timestamps, sequence numbers, checksums, and other data that need to be generated at runtime), thereby ensuring that the generated message not only conforms to the protocol format requirements but also supports dynamic adaptation to test scenarios.

[0075] The generation of the verification rule set integrates constraints from the protocol specification and verification requirements from user-configured test parameters. For each test case, inherent constraints such as signal validity range and response format are extracted from the protocol specification, while user-defined specific verification conditions (such as custom timeout times and field mask rules) are obtained from the configuration. These are then combined to create multi-dimensional verification rules, including field value comparison, timing checks, and sequence integrity. Verification rules are generated for each test case based on the verification requirements in the protocol specification and configuration. These rules include, but are not limited to: field value verification of response messages (equal to, range, mask, etc.), response time verification, and message sequence verification. Verification rules can be extracted from the protocol specification (e.g., the valid value range of signals) or obtained from the configuration (e.g., user-specified special verification rules).

[0076] The test logic set is generated based on the test scenarios and test case execution requirements described in the user-configured test parameters. It parses the process description of the test scenario, combines the test case dependencies and conditions in the mapping model, automatically arranges the execution order of test steps, embeds conditional judgments, loop control, and exception handling mechanisms, and generates corresponding preconditions, cleanup operations, and other logical fragments, thereby ensuring that each test case is executable and adaptable to the scenario.

[0077] S204. Generate test case definition files based on the message template set, verification rule set, and test logic set.

[0078] In this embodiment, message templates, verification rules, and test logic are integrated according to test cases to form a complete test case definition structure. This structure is then serialized into a file in a target format (such as XML or JSON). This file contains the complete definition of all test cases and can be read and executed by an automated testing framework.

[0079] Here, the Protocol Definition Model (PDM) is used to describe the metadata of the vehicle-to-everything (V2X) protocol in a structured format (JSON / YAML). The metadata includes at least: a protocol unique identifier, a field definition array, a verification algorithm definition, and a byte order. Each field in the field definition array contains a field name, data type, byte offset, field length expression, conditional expression, etc.

[0080] S103. The message simulator generates simulated message data based on the message template in the test case definition file.

[0081] In the embodiments of this application, reference is made to Figure 3 The diagram shown is a flowchart illustrating the generation process of simulated message data provided in an embodiment of this application.

[0082] S301. Parse the message template in the test case definition file to obtain the message template object. The message template object includes the field definitions and attribute information of all fields.

[0083] In this embodiment, the format and structure of the message template are parsed, the message type (such as CAN frame, Ethernet frame, UDS message, etc.) is identified, and the message header field definitions are extracted, including fixed values ​​and variable definitions. The data payload field definitions in the message template are extracted, including field position, size, data type, initial value, or generation rule. The message tail field definitions in the message template are extracted, including the verification field position and calculation rule. Based on all the extracted content, a message template object is constructed, containing hierarchical field definitions and relationships. The parsed message template object contains a tree structure composed of complete field definitions, with each field containing attribute information such as position, size, data type, and value description.

[0084] S302. Replace the dynamic expression fields in the message template object with dynamic field values ​​using the expression evaluation engine in the message simulator.

[0085] In this application's implementation, a dynamic expression field refers to a field whose value needs to be determined by calculating or referencing context variables. The values ​​of these fields are not fixed but are calculated at runtime based on the expression. Expressions can contain variables, functions, operators, etc., used to simulate dynamically changing data in actual communication. The value of a dynamic expression field is calculated by an expression evaluation engine. The specific process is as follows: Parse the expression: identify variables, functions, and operators in the expression; Evaluate: calculate the result of the expression based on the current context (such as environment variables, system state, values ​​of other fields, etc.); Assign the value: assign the calculated result to the field. Example: Suppose there is a field representing the current timestamp, with the expression timestamp(). During evaluation, the expression evaluation engine calls the timestamp function to obtain the current time and assigns the result to the field. Specifically:

[0086] Step 1: The expression evaluation engine identifies the dynamic expression fields in the message template object and constructs an expression syntax tree set based on the expression syntax of the dynamic expression fields.

[0087] In this embodiment, the message template object is traversed, and the expression syntax of the fields marked as dynamic expressions is identified. The variable references, function calls, operators and constants are identified. Based on the variable references, function calls, operators and constants, an expression syntax tree is constructed to clarify the calculation priority and dependency of each element.

[0088] Optionally, each expression syntax tree is bound to an execution context, specifically: variable resolution: retrieving variable values ​​from the test environment, global configuration, and preceding results; function registration: loading available built-in function libraries and custom functions; and context binding: associating symbols in the expression with specific values ​​or functions.

[0089] Step 2: Calculate the dynamic field value of each dynamic expression field by traversing the nodes in the expression syntax tree set.

[0090] In this implementation, each expression syntax tree is traversed recursively from the root node. For variable nodes, the variable value is obtained from the binding context. For function nodes, the corresponding function is called, and the result is calculated with the passed parameters. For operator nodes, the corresponding mathematical or logical operation is performed. For constant nodes, the constant value is returned directly. Additionally, data type conversion and error handling during the calculation process need to be handled; intermediate calculation results are cached to optimize the evaluation performance of complex expressions; and the calculation process and results are recorded for debugging and traceability.

[0091] Step 3: Replace the dynamic field values ​​with the corresponding dynamic expression fields in the message template object.

[0092] In this embodiment, the dynamic expression field is removed from the field definition of the message template object, the calculated dynamic field value is assigned to the corresponding field, and the corresponding field type label is changed from "dynamic expression" to "static value". In addition, the replaced field value needs to be verified: check whether the value meets the data type requirements of the field; verify whether the value is within the valid range of the field; ensure that the value meets the constraint relationship with other fields; generate a replacement report to record the changes before and after the replacement and the verification results.

[0093] S303. The field generator in the message simulator converts the fields to be generated in the message template object into generated field values ​​according to the preset rules of the test cases.

[0094] In this application's implementation, the fields to be generated are those that require automatic generation of specific data based on testing needs. The values ​​of these fields are not calculated through expressions, but rather generated according to certain rules (such as random generation, sequence generation, boundary value generation, etc.). The purpose of generating these fields is to cover various testing scenarios, such as normal values, boundary values, and outliers. The values ​​of the fields to be generated are generated through a field value generator. The specific process is as follows: generate data according to the field's generation rules (such as random range, sequence step size, boundary conditions, etc.); ensure that the generated values ​​conform to the field's constraints (such as data type, range, enumeration, etc.); assign the generated values ​​to the field. Example: Suppose there is a field representing vehicle speed, whose generation rule is "randomly generate an integer between 0 and 200". The field value generator will randomly select an integer between 0 and 200 and assign it to the field. Specifically:

[0095] Step 1: The field generator identifies the fields that need to be generated in the message template object and generates a policy mapping table corresponding to the fields that need to be generated according to the preset rules of the test case. The policy mapping table includes the generation policy, generator instance and configuration parameters for each field that needs to be generated.

[0096] In this implementation, the message template object is traversed to identify fields marked as needing generation; the generation rule description for each field is parsed to extract the rule type and parameter configuration; and the corresponding generation strategy is selected based on the rule type. Random generation strategy: configures the random range and distribution type; sequence generation strategy: configures the starting value, step size, and loop mode; boundary generation strategy: configures the boundary value type (minimum, maximum, critical); enumeration generation strategy: configures the enumeration value and selection weight; association generation strategy: configures the associated fields and calculation relationship; generator instances are initialized and parameters are configured; a mapping relationship between generation strategies and fields is established; finally, the generated strategy mapping table is output, containing the generation strategy, generator instance, and configuration parameters for each field. A generation strategy refers to a strategic scheme for selecting and defining the data generation method for a specific field. It describes "what kind of data should be generated" and "why it should be generated this way," and is a high-level data generation guideline based on test objectives, protocol constraints, and scenario requirements. A generator instance is the concrete execution entity of the generation strategy, a software component object that implements a specific generation algorithm. It is responsible for transforming the generation strategy into actual data generation operations. Configuration parameters are specific numerical settings that control the behavior of the generator. They define the specific details of "how to generate" and serve as a bridge connecting the generation strategy and the generator instance.

[0097] Step 2: Execute the generation algorithms for each field to be generated sequentially through the strategy mapping table to obtain the generated field values ​​transformed from the corresponding generated fields.

[0098] In the implementation of this application, (1) constraints are extracted from the field definition and applied to the generation strategy: value range constraint: ensure that the generated value is between the minimum and maximum value; data type constraint: ensure that the generated value meets the field data type requirements; format constraint: apply specific encoding and unit conversion requirements; association constraint: handle the dependency relationship between fields; (2) the generation algorithm of each field is executed according to the strategy mapping table: random generation: generate random values ​​within the constraint range, supporting multiple distributions; sequence generation: generate ordered sequence values ​​based on the starting value and step size; boundary generation: generate boundary values, critical values ​​or special test values; enumeration generation: select values ​​from the enumeration set according to rules; association generation: calculate the generated value based on other field values; (3) record the generation process and algorithm parameters; (4) apply constraints to adjust and verify the values; finally, the original generated value set is output, which includes the generated value and generated metadata of each field.

[0099] Step 3: Replace the generated field value with the corresponding field to be generated in the message template object.

[0100] In this embodiment, the original generated values ​​are mapped back to the corresponding field positions; format conversion is performed to convert the values ​​into the format required by the fields; the message template object is updated, replacing the generation rules of the fields to be generated with the generated values; final verification is performed: verifying that each generated field value is within the valid range of the field; verifying that the generated field values ​​meet the data type requirements of the field; verifying that the constraint relationships between fields are satisfied; verifying that the format of the generated field values ​​conforms to the protocol specification; and generating a generation report to record the generation process and final value of each field.

[0101] S304. Use the verification calculator in the message simulator to convert the verification-related fields in the message template object into verification field values.

[0102] In this application's implementation, verification-related fields refer to fields used to ensure message integrity and correctness, such as CRC, checksum, and length fields. The values ​​of these fields depend on the values ​​of other fields in the message and are typically calculated according to algorithms specified in the protocol. The values ​​of verification-related fields are calculated using a checksum calculator. The specific process is as follows: According to the protocol specifications, determine the verification algorithm (such as CRC, checksum, etc.) and the calculation range (such as the entire message or some fields). Extract the data within the calculation range. Execute the verification algorithm to obtain the checksum value. Assign the checksum value to the field. Example: Suppose there is a CRC field with the algorithm CRC8, and the calculation range includes all fields in the message except the CRC field. The checksum calculator will extract the values ​​of these fields, calculate CRC8, and assign the result to the CRC field. Specifically:

[0103] Step 1: The verification calculator identifies the verification-related fields in the message template object and parses them to obtain the algorithm configuration information for each verification-related field.

[0104] In this embodiment, the verification-related fields in the message template object are identified; the algorithm type and calculation parameters of each verification field are parsed; the verification-related fields are extracted from the message template object according to the calculation range; and the data and configuration required for verification calculation are prepared. The algorithm configuration information includes the calculation parameters and extracted data for each verification-related field. Calculation parameters refer to the configuration parameters and control options required when executing the verification algorithm; these parameters define the specific method and behavior rules of the verification calculation. Extracted data refers to the actual data content extracted from the message template object that needs to participate in the verification calculation. This data is a specific portion extracted from the complete message according to the calculation range parameters.

[0105] Step 2: Perform verification calculations according to the algorithm configuration information to generate the verification field values ​​corresponding to the transformation of the verification-related fields.

[0106] In this embodiment, the algorithm configuration information is traversed, and the corresponding verification algorithm is selected; the extracted data is used to perform verification calculation; the calculation results are post-processed according to the algorithm requirements to obtain the verification field value; and the calculation process and intermediate results are recorded.

[0107] Step 3: Replace the verification field values ​​with the corresponding verification-related fields in the message template object.

[0108] In this embodiment, each verification field value is filled into the specified position of the corresponding field of the message template object; the format conversion requirements during filling are processed; and the verification value is recalculated to verify the correctness of the filling.

[0109] S305. The message builder in the message simulator concatenates the byte sequences of each field into a complete binary message according to the preset byte offset and byte order.

[0110] In the embodiments of this application, the message builder performs the final assembly of the message according to the format definition of the protocol specification. Specifically, the builder encodes each determined field value (including fixed values, expression evaluation results, and generated test data) into corresponding binary data according to its specified data type (such as integer, floating-point number, enumeration, string, etc.) according to the field order and structure specified by the protocol. In this process, the builder strictly follows the preset byte offset (determining the starting position of the field in the message buffer) and byte order rules (big-endian or little-endian), handles bit field alignment and padding across bytes, and sequentially concatenates all binary fragments into a contiguous memory buffer, thereby constructing a raw binary message that conforms to the protocol specification. This binary message, as an intermediate product, can be further converted into hexadecimal strings, Base64 encoding, or other formats that are easy to transmit and view, as needed, to form the final simulated message data.

[0111] Here, the message simulator is used to dynamically generate binary messages conforming to the protocol specification based on the PDM and externally input test cases. The core components of the message simulator include: an expression evaluation engine, used to parse and calculate context references in field length expressions and conditional expressions, where the context references include references to other field values; a field value generator, used to generate specific values ​​for fields based on test case inputs or preset rules (such as fixed values, random values, or sequence values); a checksum calculator, used to automatically calculate and inject checksums into specified positions in the message according to the checksum algorithm defined in the PDM; and a message builder, used to concatenate the byte sequences of each field into a complete binary message according to the byte offsets and byte order defined in the PDM.

[0112] S104. The automated testing framework executes simulated message data to obtain test results, which include test status, logs, and performance metrics.

[0113] Step 1: The automated testing framework executes the simulated message data and obtains the response data corresponding to the simulated message data. The response data includes the response message, the receiving timestamp, the response time, and performance data.

[0114] In this embodiment, simulated message data is received as input, the test execution environment is initialized, a communication connection with the system under test is established, and simulated message data is sent to the system under test after recording the sending timestamp. The system listens for and receives response messages from the system under test, records the receiving timestamp, collects performance data, and generates response data records.

[0115] Step 2: Verify the response data according to the verification rules to obtain the test results of the simulated message data.

[0116] In this embodiment, the response data is verified according to preset verification rules; the test execution status (pass / fail / error) is determined; log information during the test execution process is organized; performance index data is summarized; a structured test result report is generated; the test environment is cleaned up and the communication connection is closed.

[0117] The testing framework provided in this application embodiment can drive the entire testing process, including loading test cases, executing tests, verifying results, and generating reports. The automated testing framework further includes: a test case loader for loading test cases from external files (YAML / JSON), wherein the test cases contain input field values ​​and expected verification results; a test execution engine for controlling the execution mode of the tests, supporting serial or concurrent modes, and managing timeout, delay, and retry policies; an assertion verification engine for performing multi-dimensional verification on received response messages, device status, system logs, or timing information to determine whether they meet the expected results defined in the test cases; a transmission client for encapsulating underlying communication protocols (TCP / UDP / MQTT / WebSocket), sending messages generated by a message simulator to the system under test, and receiving responses; and a test report generator for summarizing the test execution results and generating standardized test reports, with report formats including HTML, JSON, or console text.

[0118] S105, The user interaction layer formats the test results into a readable report and outputs it.

[0119] When dividing each function into modules according to its corresponding function. Figure 4 A schematic diagram of the test system for the vehicle networking protocol involved in the above and embodiment is shown, as follows: Figure 4 As shown, the testing system for the vehicle networking protocol may include: a protocol definition model 401, a message simulator 402, an automated testing framework 403, and a user interaction layer 404;

[0120] The user interaction layer 404 is used to obtain the test parameters configured by the user and convert the test parameters into structured configuration data;

[0121] The protocol definition model 401 is used to parse the structured configuration data based on the predefined protocol specifications and generate a test case definition file, which includes message templates, verification rules and test logic.

[0122] The message simulator 402 is used to generate simulated message data according to the message template in the test case definition file;

[0123] The automated testing framework 403 is used to execute the simulated message data to obtain test results, which include test status, logs, and performance metrics.

[0124] The user interaction layer 404 is used to format the test results into a readable report and output it.

[0125] For specific system limitations, please refer to the testing method limitations for the vehicle-to-everything (V2X) protocol mentioned above, which will not be repeated here. Each module in the aforementioned device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0126] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a test method for a vehicle networking protocol.

[0127] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0128] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above.

[0129] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A testing method for a vehicle networking protocol, characterized in that, The method is applied to a testing system for vehicle-to-everything (V2X) protocols. The system includes a protocol definition model, a message simulator, an automated testing framework, and a user interaction layer. The method includes: The user-configured test parameters are obtained through the user interaction layer, and the test parameters are converted into structured configuration data. The protocol definition model parses the structured configuration data based on predefined protocol specifications to generate test case definition files, which include message templates, verification rules, and test logic. The message simulator generates simulated message data based on the message template in the test case definition file; The automated testing framework executes the simulated message data to obtain test results, which include test status, logs, and performance metrics. The user interaction layer formats the test results into a readable report and outputs it. The protocol definition model parses the structured configuration data based on a predefined protocol specification to generate message templates in the test case definition file, including: The protocol specification is converted into a standardized internal protocol model using a multi-format parser; the structured configuration data is converted into standardized configuration objects; the protocol specification defines the data exchange format, timing requirements, state transition rules, and error handling mechanisms between communication entities; the protocol specification includes communication protocol metadata, message / frame format definitions, signal / field specifications, timing and behavior constraints, and service interface definitions. The protocol elements specified in the standardized configuration object are matched and associated with the corresponding elements in the standardized protocol internal model, and the test data in the standardized configuration object is converted into the original values ​​in the standardized protocol internal model to obtain a mapping relationship model. The mapping relationship model includes the correspondence between each test case and the protocol element, as well as the test data values ​​after protocol conversion. The message template set is determined according to the mapping relationship model; the message template specifies the constituent elements and filling rules of the test message, and describes how to construct the message; the message template includes message structure definition, field template, data filling rules, dynamic element definition and format conversion instructions.

2. The method according to claim 1, characterized in that, The method further includes: The set of verification rules and the set of test logic are determined based on the mapping relationship model. A test case definition file is generated based on the message template set, the verification rule set, and the test logic set.

3. The method according to claim 2, characterized in that, The message simulator generates simulated message data based on the message template in the test case definition file, including: Parse the message template in the test case definition file to obtain a message template object, which includes the field definitions and attribute information of all fields; The dynamic expression fields in the message template object are replaced with dynamic field values ​​by the expression evaluation engine in the message simulator; the dynamic expression fields are fields that need to be determined by calculation or reference to context variables. The field generator in the message simulator converts the fields to be generated in the message template object into generated field values ​​according to the preset rules of the test cases; the fields to be generated are fields that need to automatically generate specific data according to test requirements. The verification calculator in the message simulator converts the verification-related fields in the message template object into verification field values. The verification-related fields are fields used to ensure message integrity and correctness. The message builder in the message simulator concatenates the byte sequences of each field into a complete binary message based on preset byte offsets and byte order.

4. The method according to claim 3, characterized in that, The step of replacing the dynamic expression fields in the message template object with dynamic field values ​​through the expression evaluation engine in the message simulator includes: The expression evaluation engine identifies the dynamic expression field in the message template object and constructs an expression syntax tree set based on the expression syntax of the dynamic expression field. The dynamic field value of each dynamic expression field is calculated by traversing the nodes in the expression syntax tree set. Replace the dynamic field value with the corresponding dynamic expression field of the message template object.

5. The method according to claim 3, characterized in that, The step of converting the fields to be generated in the message template object into generated field values ​​using the field generator in the message simulator according to the preset rules of the test cases includes: The field generator identifies the fields that need to be generated in the message template object, and generates a policy mapping table corresponding to the fields that need to be generated according to the preset rules of the test cases. The policy mapping table includes the generation policy, generator instance and configuration parameters for each field that needs to be generated. The generation algorithms for each field to be generated are executed sequentially through the strategy mapping table to obtain the generated field values ​​transformed from the corresponding generated fields. Replace the generated field value with the corresponding field that needs to be generated in the message template object.

6. The method according to claim 3, characterized in that, The verification calculator in the message simulator converts the verification-related fields in the message template object into verification field values. These verification-related fields are used to ensure message integrity and correctness, including: The verification calculator identifies the verification-related fields in the message template object and parses them to obtain the algorithm configuration information for each verification-related field; Perform verification calculations based on the algorithm configuration information to generate verification field values ​​corresponding to the transformation of the verification-related fields; Replace the value of the verification field with the corresponding verification-related field of the message template object.

7. The method according to any one of claims 1-6, characterized in that, The automated testing framework executes the simulated message data to obtain test results, which include test status, logs, and performance metrics, including: The automated testing framework executes the simulated message data and obtains the response data corresponding to the simulated message data. The response data includes the response message, the receiving timestamp, the response time, and performance data. The response data is verified according to the verification rules to obtain the test results of the simulated message data.

8. A testing system for a vehicle-to-everything (V2X) protocol, the system comprising a protocol definition model, a message simulator, an automated testing framework, and a user interaction layer; The user interaction layer is used to obtain the test parameters configured by the user and convert the test parameters into structured configuration data; The protocol definition model is used to parse the structured configuration data based on predefined protocol specifications and generate test case definition files, which include message templates, verification rules, and test logic. The message simulator is used to generate simulated message data based on the message template in the test case definition file. The automated testing framework is used to execute the simulated message data to obtain test results, which include test status, logs, and performance metrics. The user interaction layer is used to format the test results into a readable report and output it. The protocol definition model parses the structured configuration data based on a predefined protocol specification to generate message templates in the test case definition file, including: The protocol specification is converted into a standardized internal protocol model using a multi-format parser; the structured configuration data is converted into standardized configuration objects; the protocol specification defines the data exchange format, timing requirements, state transition rules, and error handling mechanisms between communication entities; the protocol specification includes communication protocol metadata, message / frame format definitions, signal / field specifications, timing and behavior constraints, and service interface definitions. The protocol elements specified in the standardized configuration object are matched and associated with the corresponding elements in the standardized protocol internal model, and the test data in the standardized configuration object is converted into the original values ​​in the standardized protocol internal model to obtain a mapping relationship model. The mapping relationship model includes the correspondence between each test case and the protocol element, as well as the test data values ​​after protocol conversion. The message template set is determined according to the mapping relationship model; the message template specifies the constituent elements and filling rules of the test message, and describes how to construct the message; the message template includes message structure definition, field template, data filling rules, dynamic element definition and format conversion instructions.

9. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the test method for the vehicle networking protocol as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the test method for the vehicle networking protocol as described in any one of claims 1 to 7.

Images