Chassis domain electric control system test scene generation method and device, equipment and medium

Abstract

The application relates to a chassis domain electric control system test scene generation method, device, equipment and medium. Including: obtaining a requirement document and a communication matrix, using a large language model to analyze requirements to extract function logic elements, analyzing a communication matrix to extract signal definition information, establishing a requirement-signal mapping and converting a natural language condition into a signal condition expression, constructing a prompt engineering template based on multi-source information, and inputting a large language model to generate a structured test scene list. End-to-end automatic generation from requirements to executable test scenes is realized, cumbersome work of manually checking a communication matrix and manually writing a signal condition is eliminated, and human conversion errors are avoided.

Description

Technical Field

[0001] This invention relates to the field of testing technology for intelligent vehicle electronic control systems, specifically to a method, apparatus, equipment, and medium for generating test scenarios for chassis domain electronic control systems. Background Technology

[0002] Against the backdrop of the rapid development of new energy and intelligent connected vehicles, the functional complexity of chassis domain electronic control systems (such as electromechanical braking (EMB), electronic stability program (ESP), and electric power steering (EPS)) has significantly increased, and their control strategies are frequently iterated, placing higher demands on testing and verification. HiL testing, as a key link in the functional safety verification of control software, highly relies on high-quality test case design.

[0003] Current HiL test scenario design primarily relies on manual processes. Although some tools attempt to incorporate Natural Language Processing (NLP) technology to assist in requirements parsing, their capabilities are quite limited.

[0004] Therefore, existing HiL test scenario designs cannot accurately parse the complex logic in unstructured requirements documents, resulting in incomplete test coverage and omission of boundary conditions or abnormal combinations, which are technical problems that urgently need to be solved in this field. Summary of the Invention

[0005] One of the objectives of this invention is to provide a method, apparatus, equipment, and medium for generating test scenarios for chassis domain electronic control systems, in order to solve the problem that existing HiL test scenario designs cannot accurately parse the complex logic in unstructured requirement documents, resulting in incomplete test coverage and omission of boundary conditions or abnormal combinations.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] A method for generating test scenarios for a chassis domain electronic control system includes:

[0008] Obtain unstructured functional requirements documents and communication matrix files;

[0009] The functional requirements document is semantically parsed using a large language model to identify and extract functional logic elements.

[0010] Parse the communication matrix file and extract the signal definition information;

[0011] Based on the semantic association between the functional logic elements and the signal definition information, a mapping relationship is established, and the natural language descriptions of the conditions in the functional logic elements are converted into signal condition expressions according to the mapping relationship.

[0012] Based on the functional logic elements, the signal definition information, the mapping relationship, and the signal condition expression, a prompting engineering template for the large language model is constructed.

[0013] The prompt engineering template is input into the large language model to generate a list of structured test scenarios, where each test scenario includes preconditions, triggering conditions, expected behavior, and related signals.

[0014] Based on the above technical means, end-to-end automated generation from unstructured requirement documents to executable test scenarios is achieved. By establishing a mapping relationship between requirements and communication matrix signals and converting them into signal condition expressions, the inefficiency and human error of manually consulting the communication matrix and manually writing signal conditions are eliminated.

[0015] Furthermore, the step of semantically parsing the functional requirements document using a large language model to identify and extract functional logical elements includes:

[0016] The functional requirements document is divided into paragraphs, and the large language model is used to perform intent recognition and key information extraction on each paragraph to obtain the basic fields corresponding to each paragraph. The basic fields include the function name or ID, preconditions, triggering conditions, expected behavior, exit conditions, and related signals.

[0017] For paragraphs containing multiple conditional logical combinations, temporal dependencies, lookup table mechanisms, or state transition relationships, the contextual understanding capability of the large language model is used to parse the natural language logical description and generate structured logical condition expressions. These logical condition expressions are used to characterize the AND / OR relationships, temporal constraints, or state transition paths between conditions.

[0018] The logical condition expression is integrated with the basic field to form the functional logic element.

[0019] Based on the aforementioned technical means, through segmented intent recognition, key information extraction, and contextual reasoning for complex logic, unstructured natural language requirements are transformed into structured basic fields and logical conditions, providing an accurate data foundation for subsequent signal mapping and scene generation.

[0020] Furthermore, the step of parsing the communication matrix file and extracting signal definition information includes:

[0021] The signals contained in each communication message and the signal attributes corresponding to each signal are parsed from the communication matrix file. The signal attributes include signal name, data type, value range, unit, physical conversion rule, transmission period and initial value. The value range includes enumerated state values ​​and corresponding semantic descriptions.

[0022] Each signal and its corresponding signal attributes are organized into a structured data model to form the signal definition information.

[0023] Based on the above technical means, complete signal definition information is extracted by traversing the communication matrix file, covering signal name, value range, physical conversion rules, etc., providing complete data support for establishing a precise mapping between natural language conditions and electronic signals.

[0024] Furthermore, the step of establishing a mapping relationship based on the semantic association between the functional logic elements and the signal definition information, and converting the natural language descriptions of the conditions in the functional logic elements into signal condition expressions according to the mapping relationship, includes:

[0025] Identify the physical quantities, state variables, or operation instructions in the functional logic elements, search for signal names and value ranges with the same or similar semantics in the signal definition information, and establish a mapping relationship between the natural language description items in the functional logic elements and the communication signals.

[0026] Based on the mapping relationship, the physical quantities or state descriptions in the functional logic elements are replaced with the corresponding signal names and value conditions to generate the signal condition expressions.

[0027] Based on the above technical means, by integrating functional logic elements and signal definition information, physical quantities or states are automatically identified and matched with corresponding signals. Natural language conditions are replaced with precise signal expressions, replacing the step of manually consulting the communication matrix and writing signal conditions, thus eliminating mapping errors.

[0028] Furthermore, the step of constructing a prompting engineering template for the large language model based on the functional logic elements, the signal definition information, the mapping relationship, and the signal condition expression includes:

[0029] Analyze the functional logic elements to identify whether they include table lookup logic;

[0030] If the table lookup logic is identified, the input signal, output signal and mapping rule corresponding to the table lookup logic are extracted, and the table lookup logic is marked as a prompt message in a structured form.

[0031] The prompt information, the signal definition information, the mapping relationship, and the signal condition expression are integrated to obtain the prompt engineering template.

[0032] Based on the above technical means, by identifying and marking the lookup logic and recording the relationship between its input and output signals, the large model can correctly handle complex conditions involving lookup when generating test scenarios, ensuring that such scenarios are not omitted or generated incorrectly.

[0033] Furthermore, before constructing the prompt project template, the method further includes:

[0034] The key semantics in the functional logic elements are vectorized and encoded to obtain semantic vector representations;

[0035] Based on the semantic vector representation, similarity retrieval is performed in a pre-built general test case library to obtain matching historical test scenario fragments;

[0036] The historical test scenario fragments are embedded as context examples in the prompt project template.

[0037] Based on the above technical means, by retrieving similar scenarios from the historical use case library and incorporating them into the prompt engineering template, historical experience references are provided for large models, improving the generation quality of boundary conditions and complex scenarios, while realizing the effective reuse of historical test assets.

[0038] Furthermore, before constructing the prompt project template, the method further includes:

[0039] The system retrieves the preset vehicle system basic information database and obtains the state machine definition, mode switching logic, and control architecture information of the relevant electronic control unit based on the function name in the functional logic element. The vehicle system basic information database is built based on the MCP model and stores the state machine definition, mode switching logic, and hierarchical control architecture information of the electronic control unit.

[0040] The state machine definition, mode switching logic, and control architecture information are integrated into the prompt project template as contextual knowledge.

[0041] Based on the above technical means, by introducing system-level knowledge such as ECU state machine and mode switching logic in the MCP model, the large model can accurately understand the system control architecture when generating test scenarios, and avoid generating invalid scenarios that do not conform to the actual logic of the system.

[0042] Furthermore, the method also includes:

[0043] Based on the preconditions, triggering conditions, and expected behaviors of each test scenario, and combined with the parameter range and data type in the signal definition information, test cases with specific numerical configurations are automatically instantiated.

[0044] The test cases are converted into a scripting language that the test platform can recognize, generating executable test scripts;

[0045] The executable test script is controlled to run on the hardware loop-in-the-loop test platform of the chassis domain controller, and the control logic of each test scenario is determined to pass based on the matching degree between the output signal and the expected behavior in the test scenario.

[0046] Based on the above technical means, by deriving specific test cases from abstract test scenarios and generating executable scripts, the entire process from scenario to executable test is automated, significantly shortening the test development cycle.

[0047] Furthermore, the method also includes:

[0048] For test scenarios that pass verification, the test scenarios and their corresponding tags are stored in a general test case library;

[0049] For test scenarios that fail to be verified, a corrected test scenario is generated by combining the test execution log, and the corrected test scenario and its failure-repair record are updated to the general test case library.

[0050] Based on the above technical means, by feeding back valid and failed scenarios to a general test case library, the continuous accumulation of test knowledge and the iterative optimization of scenario generation quality can be achieved.

[0051] A chassis domain electronic control system test scenario generation device, comprising:

[0052] The acquisition module is used to acquire unstructured functional requirements documents and communication matrix files;

[0053] Extraction module, used for:

[0054] The functional requirements document is semantically parsed using a large language model to identify and extract functional logic elements.

[0055] Parse the communication matrix file and extract the signal definition information;

[0056] A module is established to establish a mapping relationship between the functional logic elements and the signal definition information, and to convert the natural language conditions in the functional logic elements into signal condition expressions based on the mapping relationship.

[0057] Build modules are used for:

[0058] Based on the semantic association between the functional logic elements and the signal definition information, a mapping relationship is established, and the natural language descriptions of the conditions in the functional logic elements are converted into signal condition expressions according to the mapping relationship.

[0059] Based on the functional logic elements, the signal definition information, the mapping relationship, and the signal condition expression, a prompting engineering template for the large language model is constructed.

[0060] The generation module is used to input the prompt engineering template into the large language model to generate a list of structured test scenarios, wherein each test scenario includes preconditions, triggering conditions, expected behavior and related signals.

[0061] An electronic device includes: a memory and a processor;

[0062] The memory stores computer-executed instructions;

[0063] The processor executes the computer execution instructions stored in the memory to implement the chassis domain electronic control system test scenario generation method described above.

[0064] A computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the chassis domain electronic control system test scenario generation method as described in any of the preceding claims.

[0065] A computer program product includes a computer program that, when executed by a processor, implements the chassis domain electronic control system test scenario generation method described in any of the preceding claims.

[0066] The beneficial effects of this invention are:

[0067] 1) It adopts an automatic parsing and generation method (minute-level) to replace the traditional manual reading of requirements and writing of mind maps (which takes several hours to several days);

[0068] 2) Automatically uncover potential scenarios based on semantic reasoning, replacing traditional methods that easily overlook boundaries / abnormal scenarios;

[0069] 3) The model output is unified and highly consistent, while traditional methods suffer from inconsistencies due to differences in engineer skill level, knowledge structure, etc.

[0070] 4) By adopting a knowledge base accumulation + configuration-based adaptation approach, the problems of difficult reuse and large-scale modifications between projects in the traditional way are solved;

[0071] 5) Use template constraints and range validation to reduce the probability of errors, while traditional methods rely on manual coding, which is prone to errors;

[0072] 6) Once the control strategy changes, it supports rapid regeneration and agile development, while traditional methods require redesign.

[0073] In summary, it achieves end-to-end automation from "natural language requirements" to "structured test scenarios"; improves test design efficiency by more than 50% and significantly shortens the HiL test preparation cycle; supports cross-vehicle and cross-platform reuse, reducing the cost of repetitive development; and the output results can be directly used for automated test sequence generation, connecting the entire testing process. Attached Figure Description

[0074] Figure 1 This is the application system architecture diagram for this solution;

[0075] Figure 2 Example 1 of the method for generating test scenarios for the chassis domain electronic control system provided in this solution;

[0076] Figure 3 Example 2 of the method for generating test scenarios for the chassis domain electronic control system provided in this solution;

[0077] Figure 4 Example 3 of the method for generating test scenarios for the chassis domain electronic control system provided in this solution;

[0078] Figure 5 Example 4 of the method for generating test scenarios for the chassis domain electronic control system provided in this solution;

[0079] Figure 6 Example 5 of the method for generating test scenarios for the chassis domain electronic control system provided in this solution;

[0080] Figure 7 A schematic diagram of the chassis domain electronic control system test scenario generation device provided in this solution;

[0081] Figure 8 A schematic diagram of the electronic device structure provided for this solution. Detailed Implementation

[0082] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0083] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0084] Figure 1 This is the application system architecture diagram for this solution, such as... Figure 1 As shown, the entire system consists of five main modules, among which:

[0085] The requirements input module is used to receive the raw text of the requirements document as input.

[0086] The communication analysis module is used to parse the dbc or xls file corresponding to the requirements.

[0087] The knowledge base management module is used to manage and maintain the MCP model and historical use case library.

[0088] A large model inference engine for performing semantic understanding and scene generation.

[0089] The test scenario generation module is used to organize and output structured results according to rules.

[0090] Figure 2 Example 1 of the method for generating test scenarios for the chassis domain electronic control system provided in this solution. Figure 2 As shown, the method includes the following steps:

[0091] S201: Obtain unstructured functional requirements documents and communication matrix files.

[0092] This step provides the raw input data for subsequent semantic parsing and signal mapping. The functional requirements document provides a logical description of the function under test, and the communication matrix file provides the definition information of the electronic signals. Together, they form the data foundation for generating the test scenario.

[0093] Specifically, read the unstructured functional requirements document, which can be in FRS (Functional Requirements Specification) or NFRS (Non-Functional Requirements Specification) format. For example, taking PCA (ABS pre-control) function verification as an example, the functional requirements document contains complete content such as requirement ID, requirement name, requirement description, activation conditions, and observation signals. The requirement description explains the operating scenario of the PCA function: when it is detected that the wheels are about to lock up and before the ABS is activated, the PCA function should be activated to release part of the braking force in advance and keep the wheels rolling. When the ABS is activated, the PCA should disengage control in a timely manner. There are seven activation conditions, including: the controller is powered on without faults, the vehicle is moving forward, it is not on a bad road or a washboard road, the vehicle speed is greater than 7 meters per second and this value can be calibrated, the wheel-end braking force is greater than 279,000 Newtons and this value can be calibrated, the actual wheel-end slip ratio is greater than the lookup table threshold and this threshold is related to the lateral acceleration and can be calibrated, and the ABS is not activated. The observation signals include the four-wheel PCA activation indicator, the EMB pre-braking request and slope output, and whether the PCA disengages in a timely manner after the ABS is activated.

[0094] Simultaneously, the communication matrix file is read. This file, in DBC or XLS format, defines all messages and signals in the vehicle network. Each signal includes information such as name, data type, value range, unit, physical conversion rule, transmission period, and initial value. Both files are loaded into memory, awaiting processing in subsequent steps.

[0095] S202: Use a large language model to perform semantic parsing on functional requirements documents to identify and extract functional logic elements.

[0096] This step transforms unstructured natural language requirements documents into structured functional logic elements, including basic fields and logical conditions, providing a precise data foundation for subsequent signal mapping and scene generation.

[0097] Specifically, the functional requirements document is segmented using a large language model. Intent recognition and key information extraction are performed on each paragraph to extract the basic fields corresponding to each paragraph. For paragraphs containing multiple conditions, temporal premises, lookup mechanisms, or state dependencies, the contextual reasoning of the large language model is used to further understand them and transform the natural language logical descriptions in the paragraphs into structured logical conditions.

[0098] S203: Parse the communication matrix file and extract signal definition information.

[0099] This step extracts complete signal definition information from the communication matrix file, including name, data type, value range, physical conversion rules, etc., and organizes it into a structured signal context to provide data support for establishing demand-signal mapping.

[0100] Specifically, all messages and signals in the communication matrix file are traversed, and the name, data type, value range, unit, physical conversion rule, transmission period, and initial value information of each signal are extracted. The extracted information of each signal is then organized into a structured signal context to obtain the signal definition information.

[0101] S204: Based on the semantic association between functional logic elements and signal definition information, establish a mapping relationship, and convert the natural language descriptions of the conditions in the functional logic elements into signal condition expressions according to the mapping relationship.

[0102] This step establishes a precise correspondence between each physical quantity or state in the functional requirements and the specific signals in the communication matrix, and converts the conditions described in natural language into machine-executable signal condition expressions, replacing the traditional work of manually consulting the communication matrix and manually writing signal conditions, thus eliminating human conversion errors.

[0103] Specifically, the functional logic elements are fused with signal definition information to identify each physical quantity or state mentioned in the functional logic elements. The corresponding signal name and value range are matched in the communication matrix file to establish a mapping relationship between each physical quantity or state in the functional logic elements and the signals in the communication matrix file. Based on the mapping relationship, the natural language conditions in the functional logic elements are replaced with the corresponding signal names and value conditions to generate signal condition expressions.

[0104] S205: Based on functional logic elements, signal definition information, mapping relationships, and signal condition expressions, construct a prompting engineering template for large language models.

[0105] This step integrates multi-source information such as functional logic elements, signal definition information, mapping relationships, and signal condition expressions to construct a structured prompt engineering template, which serves as input for the large language model to generate test scenarios, enabling the model to generate scenarios based on complete and accurate engineering information.

[0106] Specifically, based on the functional logic elements generated in S202, the signal definition information generated in S203, the mapping relationship established in S204, and the signal condition expression, the prompt engineering template is constructed by organizing them according to the predefined template structure.

[0107] In one implementation, the functional logic elements are first identified by a lookup table before the template is constructed.

[0108] The system iterates through the functional logic elements extracted from S202, checking for the presence of a lookup table mechanism. In the requirements document, lookup table logic typically manifests as a description of a threshold that needs to be dynamically obtained through a lookup table, such as statements like "the slip ratio threshold is related to lateral acceleration and can be calibrated by a lookup table," "the target braking force is obtained by looking up the table based on the current vehicle speed," or "the correction coefficient is determined by looking up the table based on the yaw rate." For the PCA function example, the system recognizes the natural language description "actual wheel slip ratio > lookup table threshold (related to lateral acceleration, can be calibrated by a lookup table)" in the trigger condition, determining that this trigger condition contains lookup table logic.

[0109] If a lookup logic is identified, the condition is marked as a lookup logic type, and the relationship between the corresponding input and output signals is recorded. In the PCA function example, the input signal for this lookup logic is identified as lateral acceleration, and the output signal is the slip ratio threshold. The relationship between the two is as follows: based on the current value of the lateral acceleration signal, the corresponding slip ratio threshold is obtained through a lookup table, and then this threshold is compared with the current actual wheel end slip ratio to determine whether the trigger condition is met. The lookup logic's tagging information is generated, which includes the name of the input signal (lateral acceleration), the name of the output signal (slip ratio threshold), and a description of the lookup correspondence between the input and output signals.

[0110] Subsequently, all information, including lookup logic flags, is organized into a prompt engineering template. The template adopts a structure of role definition, multi-source information input, task instructions, and output format.

[0111] In the role definition section, role instructions are written at the beginning of the template, enabling the large language model to perform tasks as an expert in automotive chassis system testing. The model is set as an expert role that is proficient in hardware-in-the-loop testing and familiar with the working principles and signal interactions of chassis domain electronic control systems.

[0112] In the functional logic element section, the basic fields and logical conditions extracted from S202 are written into the template. Taking the PCA function as an example, the basic fields include: function name PCA (ABS pre-control) function verification; requirement ID SysRS-0009; preconditions: controller powered on and system fault-free; vehicle moving forward; not on a bad road or washboard road; trigger conditions: vehicle speed greater than 7 m / s and this value can be calibrated; wheel-end braking force greater than 279,000 Newtons and this value can be calibrated; actual wheel-end slip ratio greater than the lookup table threshold and this threshold is related to lateral acceleration; ABS not activated; expected behavior: PCA function activated; partial braking force released in advance; maintaining wheel rolling state; reducing brake dive; exit condition: PCA exits after ABS activation; observed signal: four-wheel PCA activation flag; EMB pre-braking request and slope output; and whether PCA exits in time after ABS activation. The logical conditions include the logical relationship between the four triggering conditions, the timing prerequisite that ABS is not activated for PCA activation, and the lookup relationship between the slip ratio threshold and the lateral acceleration.

[0113] In the signal definition information section, the signal definition information extracted from S203 is written into the template. Taking the PCA function as an example, the vehicle speed signal definition includes the signal name, data type, value range of 0 to 40, unit of meters per second, physical conversion rule (multiplying the original value by 0.01 to obtain the actual vehicle speed value), transmission cycle, and initial value information. The wheel-end braking force signal definition includes the value range of 0 to 500,000, unit of Newtons, and physical conversion rule (multiplying the original value by 2.0). The ABS status signal definition includes the value range of 0x0 corresponding to the inactive state and 0x1 corresponding to the active state. The four PCA activation flag signal definitions include the signal name, data type, and value range corresponding to the left front wheel, right front wheel, left rear wheel, and right rear wheel, respectively. The lateral acceleration signal definition includes the value range of -20 to 20, unit of meters per second squared.

[0114] In the mapping section, the correspondence between physical quantities or states and signals established in S204 is written into the template. Vehicle speed corresponds to vehicle speed signal, wheel-end braking force corresponds to wheel-end braking force signal, ABS not activated corresponds to ABS state signal equal to 0x0, and four-wheel PCA activation flags correspond to four PCA activation flag signals.

[0115] In the signal condition expression section, the fixed threshold signal condition expressions transformed in S204 are written into the template. For fixed threshold conditions, the system writes precise signal condition expressions such as vehicle speed signal greater than 7.0, wheel-end braking force signal greater than 279000, and ABS status signal equal to 0x0. For lookup table logic conditions, the system writes lookup table logic marking information, including the lookup input signal being the lateral acceleration signal, the output signal being the slip ratio threshold, and special processing instructions for obtaining the slip ratio threshold based on the lateral acceleration signal, so that the large language model can understand that the processing method for this condition is different from that for fixed threshold conditions.

[0116] In the task instruction section, specific task requirements are written in the template, instructing the large language model to generate a hardware-in-the-loop test scenario list based on the functional requirements, signal definitions, mapping relationships, signal condition expressions, and lookup table logic marking information provided above, and specifying that each test scenario must include four elements: preconditions, triggering conditions, expected behavior, and related signals.

[0117] In the output format section, the template specifies a list of test scenarios in JSON format. Each scenario includes five fields: description, preconditions, triggering conditions, expected behavior, and related signals. It also states that the scenario is an abstract test scenario layer and does not contain specific executable parameters.

[0118] The final completed prompt engineering template integrates multi-source information such as functional logic elements, signal definition information, mapping relationships, fixed threshold signal condition expressions, and lookup logic marking information into a complete prompt text. It can be directly input into a large language model for reasoning to generate a list of structured test scenarios covering different working conditions such as normal triggering, boundary conditions, lookup logic, and abnormal scenarios.

[0119] In this embodiment, before step S205, a step of reusing historical test scenarios based on semantic retrieval may also be included:

[0120] The key semantics in the functional logic elements are vectorized and encoded to obtain semantic vector representations; based on the semantic vector representations, similarity retrieval is performed in a pre-built general test case library to obtain matching historical test scenario fragments; the historical test scenario fragments are embedded as context examples into the prompt project template.

[0121] Before building the prompt engineering template, key phrases in the functional logic elements are vectorized, and historical test scenario texts similar to the current requirements are retrieved from the general test case library. The retrieved historical scenario texts are then added to the prompt engineering template as reference experience. This allows the large language model to draw on effective scenario designs from historical projects when generating test scenarios, thereby improving the generation quality and enabling the reuse of historical assets.

[0122] Specifically, this step is an optional enhancement operation prior to S205. After completing the extraction of functional logic elements in S202 and before building the prompt project template, the following operations can be performed.

[0123] The key phrases extracted from the functional logic elements in S202 are vectorized. These key phrases can be selected from function names, core physical quantities in trigger conditions, key actions of expected behavior, etc. Taking the PCA function as an example, key phrases can include phrases representing the core features and testing focus of the function, such as "ABS pre-control," "PCA," "slip ratio," "locked," and "ABS not activated." These key phrases are converted into high-dimensional vectors using an embedding model, making semantically similar texts closer together in the vector space.

[0124] The search is performed in a general test case library. This library stores test scenario texts from historical projects, each of which has been vectorized and indexed. The similarity between the key phrase vectors and the vectors of each historical scenario in the test case library is calculated, returning the historical test scenario text that is semantically most similar to the key phrase. Taking the PCA function as an example, the search results might return a historical test scenario described as verifying whether ABS is properly activated during emergency braking on a high-friction surface. Although this scenario tests ABS activation rather than the PCA function, it shares similarities with the PCA function in terms of slip ratio judgment and verification logic for the critical state of wheel lockup. This can provide a reference for large language models to understand the boundary conditions of near-lockup without ABS activation.

[0125] The retrieved historical test scenario texts are added to the prompt project template as reference experience. When building the prompt project template in S205, the retrieved historical test scenario texts are written into the template as additional reference information, so that the large language model can refer to the design ideas and verification logic of historical scenarios when generating test scenarios for the current requirements.

[0126] This step allows historically validated test cases from the general test case library to be reused in new projects, avoiding the repetitive work of designing test cases from scratch each time. Simultaneously, experiential knowledge such as boundary condition settings and verification logic from these historical scenarios is passed to the large language model through a retrieval-enhanced generation mechanism, enabling the model to generate more accurate test cases when faced with similar functional requirements.

[0127] In this embodiment, before step S205, a step of introducing system-level context knowledge may be included, which includes:

[0128] The system retrieves the pre-defined vehicle system basic information database and obtains the state machine definition, mode switching logic, and control architecture information of the relevant electronic control unit based on the function name in the functional logic element. The state machine definition, mode switching logic, and control architecture information are then integrated into the prompt project template as contextual knowledge.

[0129] Before constructing the prompt engineering template, the system retrieves the state machine definition, mode switching logic, and control architecture information of the relevant electronic control unit by searching the vehicle system basic information database based on the MCP model. This system-level knowledge is then added to the prompt engineering template, enabling the large language model to accurately understand the system architecture and control logic of the controlled object when generating test scenarios, thus avoiding the generation of invalid test scenarios that do not conform to the actual electronic control unit state transition rules.

[0130] Specifically, this step is performed after the functional logic elements of S202 are extracted and before the prompt engineering template is built, in order to enhance the large language model's ability to understand domain test patterns.

[0131] Using the function names in the functional logic elements as search indexes, the basic information database of the vehicle system built based on the MCP model is accessed and retrieved. The MCP model is a system-level description model of the vehicle electronic control unit, covering the functional definition, state machine, mode switching logic, and control architecture relationships between modules of the electronic control unit.

[0132] Taking the PCA function as an example, the function name in the functional logic element is "PCA (ABS Pre-Control) Function Verification". Using this function name as a search keyword, a matching query is performed in the MCP model library. The search returns the system-level definition information of the electronic control unit associated with this function name.

[0133] Regarding state machine definition, the state machine definition information of the electronic control unit to which the PCA function belongs is obtained. The state machine definition describes the state transition rules of the electronic control unit under different conditions, such as the transition conditions between the inactive state, standby state, active state, and fault state. For the PCA function, the state machine definition clarifies that the PCA can only enter the active state when the ABS state is inactive.

[0134] Regarding mode switching logic, information related to the PCA function is acquired. The mode switching logic describes the switching conditions and actions of the electronic control unit between different operating modes, including control strategies in normal mode and degradation strategies in fault mode.

[0135] Regarding control architecture information, the system obtains the architectural location information of the PCA function within the vehicle control system. This control architecture information clarifies that the PCA control module is located before the ABS main control module. In the braking control chain, the PCA acts as a pre-control link before ABS. When the system detects that a wheel is about to lock up and ABS has not yet been activated, the PCA intervenes first to pre-adjust the braking force.

[0136] The acquired state machine definitions, mode switching logic, and control architecture information are used as system-level background knowledge and added to the context of the S205 construction prompt engineering template. Upon receiving this system-level knowledge, the large language model can understand the precise location of the PCA in the vehicle control architecture (before the ABS main controller), the state dependency between the PCA and ABS (the PCA works when ABS is inactive and exits when ABS is activated), and the PCA's own state transition rules. This allows it to avoid generating erroneous scenarios that contradict the actual control logic when generating test scenarios, ensuring the generated test scenarios are engineering-feasible.

[0137] S206: Input the prompt engineering template into the large language model to generate a list of structured test scenarios.

[0138] This step takes the prompt project template built by S205 as input and uses the semantic understanding and reasoning capabilities of the large language model to generate a list of structured test scenarios covering normal triggers, boundary conditions, and abnormal scenarios, ensuring that the test scenarios fully cover all situations in the functional requirements.

[0139] Specifically, the prompt engineering template constructed by S205 is input into the large language model for inference. During the inference process, the large language model generates a structured list of test scenarios according to the output format requirements, based on the original functional requirements, signal definition information, mapping relationships, signal condition expressions, and lookup table logic markers provided in the template.

[0140] Taking the PCA function as an example, the large language model first understands the complete logic of the PCA function: the preconditions are that the controller is powered on and the system is fault-free, the vehicle is moving forward and is not on a bad road or washboard road; the triggering condition is that the four conditions of vehicle speed, wheel-end braking force, slip ratio and ABS status are met at the same time and the timing premise is that ABS is not activated; the expected behavior is that PCA is activated, the braking force is released in advance and the wheels are kept rolling; the exit condition is that PCA exits after ABS is activated.

[0141] Then, based on understanding the above logic, the model generates multiple test scenarios covering different working conditions.

[0142] For a normal triggering scenario, the model generates a test scenario described as follows: when a vehicle travels at a speed of 8 meters per second on a high-friction surface, the PCA is normally activated. The preconditions are that the controller is powered on without faults, the vehicle is moving forward, and the road surface is a high-friction surface. The triggering conditions are that the vehicle speed is greater than 7 meters per second, the wheel-end braking force is greater than 279,000 Newtons, the slip ratio is greater than the lookup table threshold, and the ABS is not activated. The expected behavior is that the PCA activation flag is set, the EMB pre-braking request is output, and the brake dive is reduced. The signals involved include vehicle speed signal, wheel-end braking force signal, ABS status signal, PCA activation flag signal, and EMB pre-braking request signal.

[0143] For boundary condition scenarios, the model generates a test scenario, which is described as whether PCA is activated when the vehicle is traveling at a critical speed of 7 meters per second. The trigger condition is that the vehicle speed is equal to 7 meters per second. This is used to verify the boundary conditions of the vehicle speed calibration threshold. The signals involved are the same as those in the normal trigger scenario.

[0144] For timing-based scenarios, the model generates a test scenario described as follows: PCA should not be started when ABS is activated. The trigger condition is that ABS is activated, and the expected behavior is that PCA is not activated. The signals involved include ABS status signals and PCA activation flag signals.

[0145] For lookup table logic coverage scenarios, the model generates multiple test scenarios for different lateral acceleration values ​​based on the lookup table logic tag information. For example, the slip ratio thresholds corresponding to lateral accelerations of -10, -5, 0, 5, and 10 m / s squared are used to verify the correctness of the lookup table relationship under various working conditions. The lateral acceleration signal is added to the signal involved.

[0146] For exit condition scenarios, the model generates a test scenario, which is described as PCA exiting promptly when ABS intervenes after PCA activation. The triggering condition is that the ABS state changes from never being activated to being activated, and the expected behavior is PCA exit. The signals involved include the ABS state signal and the PCA activation flag signal.

[0147] For abnormal conditions, the model generates a test scenario, which is described as the PCA function not being triggered when the sensor signal is invalid. The triggering condition includes the sensor fault state, the expected behavior is that the PCA is not activated, and the signals involved include system fault state signals.

[0148] Each generated test scenario is output in a structured JSON format, containing five fields: description, preconditions, triggering conditions, expected behavior, and related signals. Each scenario is an abstract test scenario layer, without specific executable parameters, facilitating the flexible derivation of specific test cases in subsequent steps based on different project requirements. The test scenario list output by the large language model covers various operating conditions, including normal triggering, critical boundaries, timing prerequisites, table lookup logic, exit conditions, and abnormal conditions, achieving comprehensive verification of the PCA functional logic.

[0149] The chassis domain electronic control system test scenario generation method provided in this application embodiment obtains unstructured functional requirement documents and communication matrix files. It uses a large language model to perform semantic parsing on the functional requirement documents, extracting functional logic elements. It also parses the communication matrix file, extracting signal definition information, establishing a mapping relationship between functional logic elements and signal definition information, and converting natural language conditions in the functional logic elements into signal condition expressions based on this mapping relationship. Based on the functional logic elements, signal definition information, mapping relationship, and signal condition expressions, a prompt engineering template is constructed. This prompt engineering template is then input into the large language model to generate a structured test scenario list. This method parses the requirement document and integrates communication matrix signals using a large language model, establishing an automatic mapping from natural language conditions to signal expressions. It combines historical use cases and MCP system knowledge to construct prompt engineering templates and generate a structured test scenario list, achieving end-to-end automated generation from requirements to executable test scenarios. This eliminates the tedious work of manually consulting the communication matrix and manually writing signal conditions, avoids human error in conversion, and ensures that the scenarios conform to the actual vehicle control architecture through system-level knowledge injection.

[0150] Figure 3 Example 2 of the method for generating test scenarios for the chassis domain electronic control system provided in this solution, such as Figure 3 As shown, based on the above embodiment, step S202 includes:

[0151] S301: Divide the functional requirements document into paragraphs and use a large language model to perform intent recognition and key information extraction on each paragraph to obtain the basic fields corresponding to each paragraph.

[0152] This step performs intent recognition and key information extraction on each segment after the large language model is segmented. Basic fields such as function name or ID, preconditions, trigger conditions, expected behavior, exit conditions, and observation signals are extracted from each segment. The natural language description segments are transformed into structured basic fields, providing a structured data foundation for subsequent logical condition extraction and signal mapping.

[0153] Specifically, S301 is the first level of semantic parsing of the functional requirements document by the large language model. In S202, the functional requirements document has been input into the large language model and segmented. This step then performs intent recognition and key information extraction on each segment.

[0154] The large language model first identifies the intent type of each paragraph, determining which type of information it belongs to. Taking the PCA functional requirements document as an example, it includes various types such as requirement ID paragraphs, requirement name paragraphs, requirement description paragraphs, activation condition paragraphs, and observation signal paragraphs. The model determines what information each paragraph carries based on keywords at the beginning of the paragraph or the semantic context.

[0155] After completing intent recognition, the model extracts key information based on paragraph type. For the requirement ID paragraph and the requirement name paragraph, the model identifies and extracts the function name and function ID, resulting in a function name of "PCA (ABS pre-control) function verification" and a function ID of "SysRS-0009".

[0156] For the requirement description paragraph, the model identifies and extracts the expected behavior and exit conditions. The expected behavior is extracted from "PCA should be activated, releasing some braking force in advance to maintain wheel rolling and prevent complete locking. This process reduces brake dive." The exit condition is extracted from "When ABS is activated, PCA should exit control promptly."

[0157] For the precondition paragraph, the model identifies and extracts the preconditions. From "Controller is powered on, system is fault-free", the model extracts "Controller is powered on and fault-free", from "Vehicle is moving forward", the model extracts "Vehicle is not on a bad road or washboard road", and from "Not on a bad road or washboard road", the model extracts "Road conditions".

[0158] For the activation condition paragraph, the model identifies and extracts the trigger conditions. The vehicle speed condition is extracted from "vehicle speed > 7 m / s", the braking force condition is extracted from "wheel-end braking force > 279000 N", the slip ratio condition is extracted from "actual wheel-end slip ratio > lookup table threshold", and the ABS status condition is extracted from "ABS not activated".

[0159] For the observed signal segment, the model identifies and extracts the observed signal elements. The wheel PCA flag signal is extracted from "PCA activation flag: ABS03PCACtrlFL_uls_b etc. (four wheels)", the EMB related signal is extracted from "EMB pre-braking request and slope output", and the exit verification signal is extracted from "whether PCA exits in time after ABS activation".

[0160] Finally, the large language model summarizes the information extracted from each paragraph into structured basic fields. For the PCA function, the basic fields include the function name "PCA (ABS pre-control) function verification", the function ID "SysRS-0009", the preconditions "controller powered on and system fault-free", "vehicle moving forward", "not on a bad road or washboard road", the trigger conditions "vehicle speed greater than 7 m / s and this value can be calibrated", "wheel-end braking force greater than 279,000 N and this value can be calibrated", "actual wheel-end slip ratio greater than the lookup table threshold and this threshold is related to lateral acceleration and can be calibrated", "ABS not activated", the expected behavior is "PCA function activated, partial braking force released in advance, wheel rolling state maintained, braking dive reduced", the exit condition is "PCA exits after ABS activation", and the observed signals are "four-wheel PCA activation flag, EMB pre-braking request and slope output, whether PCA exits in time after ABS activation".

[0161] S302: For paragraphs containing multiple conditional logical combinations, temporal dependencies, lookup table mechanisms, or state transition relationships, the contextual understanding capability of the large language model is used to parse the natural language logical description and generate structured logical conditional expressions.

[0162] This step targets complex logical paragraphs containing multiple conditional AND / OR combinations, temporal prerequisites, lookup table mechanisms, or state dependencies. Building upon the basic field extraction completed by the large language model, it further deepens the understanding of the natural language logical descriptions in the paragraphs through contextual reasoning. This transforms the logical relationship types between conditions, the temporal sequence, the input-output relationship of the lookup table function, and the state transition dependency into structured logical conditions, enabling the complex logical relationships to be accurately understood and processed by subsequent steps.

[0163] Specifically, S302 is the second level of semantic parsing of functional requirement documents by the large language model. Based on the basic field extraction completed in S301, it further performs in-depth reasoning on paragraphs containing complex logic.

[0164] The large language model first identifies which paragraphs contain complex logic. In the PCA functional requirements document, the activation condition paragraph contains a multi-condition description of "satisfying all of the following," which includes a combination of four conditions: vehicle speed, wheel-end braking force, slip ratio, and ABS status. It also includes a temporal premise description of "before ABS activation" and a table lookup mechanism description of "the slip ratio threshold being related to lateral acceleration." The requirements description paragraph contains a state dependency description of "PCA deactivating after ABS activation." The model identifies these paragraphs as containing complex logic, requiring further contextual reasoning.

[0165] For the activation condition paragraph, the model first identifies the type of logical relationship between the conditions. The paragraph begins by explicitly stating "all of the following must be satisfied," and the model identifies an "AND" logical relationship between the four triggering conditions: vehicle speed greater than 7 meters per second and this value is calibrable; wheel-end braking force greater than 279,000 Newtons and this value is calibrable; actual wheel-end slip ratio greater than a lookup table threshold and this threshold is related to lateral acceleration and is calibrable; and ABS is not activated. All four conditions must be met simultaneously to trigger PCA activation.

[0166] The model then identifies the timing prerequisites. The paragraph describes "before the system detects that the wheels are about to lock up and the ABS is not activated." Through contextual reasoning, the model understands that "ABS not activated" is a timing prerequisite for PCA activation. That is, the PCA must activate within the time window when the ABS remains inactive. This reflects the system design logic of the PCA as a pre-control link before ABS intervention; the PCA works before ABS intervention. The model translates this understanding into a timing-related logical condition.

[0167] The model then identifies the lookup table mechanism. For the condition "actual wheel-end slip ratio > lookup table threshold (related to lateral acceleration, which can be calibrated by lookup table)," the model recognizes through contextual reasoning that the slip ratio threshold cannot be treated as a fixed value, but needs to be dynamically obtained by looking up a table based on the current value of lateral acceleration. The input signal of the lookup table function is lateral acceleration, and the output signal is the slip ratio threshold. The model transforms this understanding into structured information regarding the lookup table logic.

[0168] Regarding the state dependencies in the requirements description paragraph, the model identified the state transition dependency description: "When ABS is activated, PCA should exit control promptly." Through contextual reasoning, the model understands that there is a state dependency between PCA and ABS; the working state of PCA depends on the state of ABS, and when ABS transitions from an inactive state to an active state, PCA needs to exit accordingly.

[0169] The model transforms the various logical relationships identified through contextual reasoning into structured logical conditions. These include an AND relationship among the four triggering conditions, the fact that ABS inactivation is a temporal prerequisite for PCA activation, a lookup table relationship between the slip ratio threshold and lateral acceleration (with lateral acceleration as the input signal and slip ratio threshold as the output signal), and a state dependency between PCA and ABS (PCA exits when ABS is activated). These logical conditions, together with the basic fields extracted by S301, constitute the complete PCA functional logic elements, providing subsequent steps for establishing a precise mapping between requirements and signals and generating accurate test scenarios.

[0170] S303: Integrate logical condition expressions with basic fields to form functional logic elements.

[0171] This step integrates the basic fields extracted in S301 with the structured logic condition expressions generated in S302 to form a complete functional logic element covering the basic fields and logical relationships, which can be used for subsequent establishment of requirement-signal mapping, construction of prompt engineering templates, and generation of test scenarios.

[0172] Specifically, taking the PCA function as an example, the basic fields extracted by S301 and the logical condition expressions generated by S302 are integrated into a unified functional logic element data structure. This functional logic element includes a basic field part and a logical condition part. The basic field part includes the function name "PCA (ABS pre-control) function verification", function ID "SysRS-0009", preconditions "controller powered on and system fault-free", "vehicle moving forward", "not on a bad road or washboard road", trigger conditions "vehicle speed greater than 7 m / s and this value can be calibrated", "wheel-end braking force greater than 279000 Newtons and this value can be calibrated", "actual wheel-end slip ratio greater than the lookup table threshold and this threshold is related to lateral acceleration and can be calibrated", "ABS not activated", expected behavior "PCA function activated, partial braking force released in advance, wheel rolling state maintained, braking dive reduced", exit condition "PCA exits after ABS activation" and related signals "four-wheel PCA activation flag", "EMB pre-braking request and slope output", "whether PCA exits in time after ABS activation". The logic condition section includes four trigger conditions that have a logical AND relationship, ABS inactivation being a timing prerequisite for PCA activation, a lookup table relationship between the slip ratio threshold and lateral acceleration, with the input signal being lateral acceleration and the output signal being the slip ratio threshold, and a state dependency relationship between PCA and ABS, with PCA exiting when ABS is activated.

[0173] After the basic fields and logical conditions are integrated, the functional logic elements contain both basic information such as "what elements are there" and a structured description of "what are the logical relationships between the elements". This can be used by S204 to determine which physical quantities need to be mapped to which signals when establishing demand-signal mapping, and by S205 to provide complete context information when building prompt engineering templates.

[0174] The chassis domain electronic control system test scenario generation method provided in this application divides the functional requirement document into paragraphs and uses a large language model to perform intent recognition and key information extraction on each paragraph, obtaining the basic fields corresponding to each paragraph. For paragraphs containing multi-condition logical combinations, timing dependencies, lookup mechanisms, or state transition relationships, the large language model's contextual understanding capability is used to parse the natural language logical description, generating structured logical condition expressions. These logical condition expressions are then integrated with the basic fields to form functional logical elements. This method uses a large language model to segment the requirement document for intent recognition and key information extraction, extracting structured basic fields. It also performs contextual reasoning for complex logic such as multi-condition AND / OR combinations, timing prerequisites, and lookup mechanisms, transforming natural language logical descriptions into structured logical conditions. This converts unstructured requirement documents into complete, computable functional logical elements, providing an accurate data foundation for subsequent requirement-signal mapping and test scenario generation.

[0175] Figure 4 Example 3 of the method for generating test scenarios for the chassis domain electronic control system provided in this solution, such as Figure 4 As shown, based on the above embodiments, step S203 includes:

[0176] S401: Parse the signals contained in each communication message and the signal attributes corresponding to each signal from the communication matrix file.

[0177] This step iterates through all messages and signals defined in the communication matrix file, extracting the name, data type, value range, unit, physical conversion rule, transmission period, and initial value information of each signal. This provides complete signal definition data for the subsequent establishment of the demand-signal mapping. The value range includes enumerated state values ​​and corresponding semantic descriptions.

[0178] Specifically, S401 is the data extraction stage of communication matrix parsing. After reading the communication matrix file in DBC or XLS format, it iterates through all the messages defined in the file. For each message, it further iterates through all the signals it contains and extracts the complete definition information of each signal.

[0179] Taking the PCA function-related signals as an example, the definition entry for the vehicle speed signal is located in the communication matrix file. The name field of this signal is recorded as "VehicleSpeed", the data type is unsigned integer, the value range is recorded as 0 to 40, the unit field is recorded as meters per second, the physical conversion rule is recorded as multiplying the original value by 0.01 to obtain the actual vehicle speed value, the transmission period is recorded as 10 milliseconds, and the initial value is recorded as 0.

[0180] For the wheel-end braking force signal, its name is extracted as "WheelBrakeForce", the data type is unsigned integer, the value range is 0 to 500000, the unit is Newton, the physical conversion rule is to multiply the original value by 2.0 to obtain the actual braking force value, the transmission period is 10 milliseconds, and the initial value is 0.

[0181] For the ABS status signal, its name is extracted as "IBCU_AbsActv", the data type is enumeration, and the value range is recorded as two status values: 0x0 and 0x1. 0x0 corresponds to the "Not active" status, and 0x1 corresponds to the "active" status. The unit is none. The physical conversion rule is direct mapping, the transmission period is 20 milliseconds, and the initial value is 0x0.

[0182] For the four-wheel PCA activation flag signals, the names of the left front wheel signal "ABS03PCACtrlFL_uls_b", the right front wheel signal "ABS03PCACtrlFR_uls_b", the left rear wheel signal "ABS03PCACtrlRL_uls_b", and the right rear wheel signal "ABS03PCACtrlRR_uls_b" are extracted respectively. The data type is Boolean, the value range is 0 or 1, the unit is none, the physical conversion rule is direct mapping, the transmission period is 10 milliseconds, and the initial value is 0.

[0183] For the lateral acceleration signal, its name is "LateralAccel", the data type is signed integer, the value range is -20 to 20, the unit is meters per second squared, the physical conversion rule is to multiply the original value by 0.01 to obtain the actual lateral acceleration value, the transmission period is 10 milliseconds, and the initial value is 0.

[0184] The above extraction operation is performed on each signal in the communication matrix file. After obtaining the complete definition information of each signal, all extraction results are temporarily stored in memory, waiting to be organized in S402.

[0185] S402: Organize each signal and its corresponding signal attributes into a structured data model to form signal definition information.

[0186] This step organizes the name, data type, value range, unit, physical conversion rule, transmission period, and initial value information of each signal extracted by S401 into a structured signal context according to a unified data structure, generating signal definition information that can be directly called by subsequent steps.

[0187] Specifically, S402 is the data organization stage of communication matrix parsing. All field information of each signal extracted in S401 is organized uniformly according to a predefined data structure to generate a structured signal context.

[0188] For each signal, its name, data type, value range, unit, physical conversion rule, transmission period, and initial value information are integrated into a complete signal definition record. Taking the vehicle speed signal as an example, its name "VehicleSpeed", data type "unsigned integer", value range "0 to 40", unit "meters per second", physical conversion rule "original value multiplied by 0.01", transmission period "10 milliseconds", and initial value "0" are organized into an independent signal definition record.

[0189] For the ABS status signal, its name "IBCU_AbsActv", data type "enumerated type", value range "0x0 and 0x1" and its corresponding status meaning "0x0 corresponds to Not active, 0x1 corresponds to active", physical conversion rule "direct mapping", transmission period "20 milliseconds" and initial value "0x0" are organized into an independent signal definition record.

[0190] After organizing all the extracted signals one by one in the above manner, they are stored as a structured signal context. This signal context is indexed by the signal name, and each record contains the complete definition attributes of the signal, forming a structured dataset that allows for quick lookup of signal definition information by signal name, which is the signal definition information in step S203.

[0191] This signal definition information can be quickly queried in subsequent steps when establishing the demand-signal mapping: When step S204 needs to confirm the signal corresponding to "vehicle speed", the signal definition record named "VehicleSpeed" can be directly searched in the signal context to obtain its value range, unit, physical conversion rules, and other information, completing the accurate matching from physical quantity to signal. For querying the value range, when the "ABS inactive" state is identified, the inactive state corresponding to 0x0 can be found in the value range record of the ABS state signal, thereby establishing the correct mapping relationship. For querying the physical conversion rules, when it is necessary to verify the wheel-end braking force threshold, the original threshold can be converted into the corresponding physical value according to the physical conversion rules of the braking force signal.

[0192] The chassis domain electronic control system test scenario generation method provided in this application embodiment traverses all messages and signals in the communication matrix file, extracts the name, data type, value range, unit, physical conversion rule, transmission period, and initial value information of each signal, and organizes the extracted information into a structured signal context to obtain signal definition information. This method, by traversing the communication matrix file to extract the name, data type, value range, unit, physical conversion rule, transmission period, and initial value information of each signal and organizing it into a structured signal context, provides complete and queryable signal definition data support for subsequently establishing a precise mapping from natural language conditions to signal expressions.

[0193] Figure 5 Example 4 of the method for generating test scenarios for the chassis domain electronic control system provided in this solution, such as Figure 5 As shown, based on the aforementioned embodiments, step S204 specifically includes:

[0194] S501: Identify physical quantities, state variables, or operation instructions in functional logic elements, search for signal names and value ranges with the same or similar semantics in signal definition information, and establish a mapping relationship between natural language description items in functional logic elements and communication signals.

[0195] This step matches each physical quantity or state mentioned in the functional logic element with the corresponding signal name and value range in the communication matrix file, establishing a precise mapping relationship between each physical quantity or state in the functional logic element and the signal in the communication matrix file. This enables the natural language description of the requirement elements to correspond with the underlying electronic signals, providing a mapping basis for the subsequent conversion of natural language conditions into signal expressions.

[0196] Specifically, S501 is the core step in establishing the demand-signal mapping. It integrates the functional logic elements generated in S202 with the signal context generated in S402, identifies each physical quantity or state mentioned in the functional logic elements, and matches the corresponding signal name and value range in the communication matrix file.

[0197] Taking the PCA function as an example, the system first iterates through the fields of trigger conditions, preconditions, and observed signals in the functional logic elements to identify all physical quantities or states that appear therein. In the trigger conditions, the system identifies physical quantities or states such as "vehicle speed," "wheel-end braking force," "slip ratio threshold," "lateral acceleration," and "ABS not activated." In the preconditions, the system identifies physical quantities or states such as "controller powered on," "system fault-free," "vehicle moving forward," "bad road," and "washboard road." In the observed signals, the system identifies physical quantities or states such as "PCA activation flag" and "EMB pre-braking request."

[0198] For each identified physical quantity or state, a matching query is performed in the signal context generated by S402 to find the corresponding signal name and value range. For the physical quantity "vehicle speed", the signal named "VehicleSpeed" is matched in the signal context, with a value range of 0 to 40, and the unit is meters per second. For the physical quantity "wheel-end braking force", the signal named "WheelBrakeForce" is matched, with a value range of 0 to 500,000, and the unit is Newtons. For the state "ABS not activated", the system matches the signal named "IBCU_AbsActv", with a value range of 0x0 corresponding to the "Not active" state and 0x1 corresponding to the "active" state. For the physical quantity "lateral acceleration", the system matches the signal named "LateralAccel", with a value range of -20 to 20, and the unit is meters per second squared. For the physical quantity "PCA activation flag", the system matches four signals named "ABS03PCACtrlFL_uls_b", which correspond to the left front wheel, right front wheel, left rear wheel and right rear wheel respectively, with a value range of 0 or 1.

[0199] For the physical quantity "slip rate threshold," which is related to a lookup table, the threshold needs to be dynamically obtained based on the lateral acceleration, and is not a fixed value. The system records this physical quantity as the lookup output, with the corresponding input signal being "LateralAccel" and the output signal being the slip rate threshold obtained from the lookup table. The system also marks this mapping as a lookup logic type.

[0200] A mapping record is established for each identified physical quantity or state. The record includes the name of the physical quantity or state, the name of the matched signal, the signal value range, the signal unit, the physical conversion rule, and a flag indicating whether it is a lookup table. Taking the mapping record for "vehicle speed" as an example, it includes the physical quantity name "vehicle speed", the signal name "VehicleSpeed", the value range of 0 to 40, the unit "meters per second", the physical conversion rule "original value multiplied by 0.01", and the lookup table flag "no".

[0201] Finally, all mapping records are summarized to form a complete mapping table between each physical quantity or state in the functional logic element and the signal in the communication matrix file. This mapping table covers all physical quantities or states involved in the triggering conditions, preconditions, and observed signals, and is used by S502 to convert natural language conditions into signal expressions.

[0202] S502: Based on the mapping relationship, replace the physical quantities or state descriptions in the functional logic elements with the corresponding signal names and value conditions to generate signal condition expressions.

[0203] Based on the mapping relationship established in S501, this step replaces the natural language conditions in the functional logic elements with the corresponding signal names and value conditions, generating precise signal condition expressions. This transforms the conditions originally described in natural language into signal-level condition descriptions that can be directly used for subsequent test scenario generation.

[0204] Specifically, S502 is the step of converting natural language conditions into signal expressions. Based on the mapping relationship established in S501, each natural language condition in the functional logic element is converted into a corresponding signal condition expression.

[0205] First, identify the natural language conditions that need to be transformed in the functional logic elements. Taking the PCA function as an example, the trigger conditions include four natural language conditions: "vehicle speed > 7 m / s", "wheel-end braking force > 279000 N", "actual wheel-end slip ratio > lookup table threshold", and "ABS not activated".

[0206] For the natural language condition "vehicle speed > 7 m / s", based on the mapping relationship established in S501, the signal name corresponding to "vehicle speed" is found to be "VehicleSpeed", with the unit being "meters per second". The physical quantity "vehicle speed" in the natural language condition is replaced with the signal name "VehicleSpeed", and the threshold "7 m / s" is converted to "7.0", generating the signal condition expression "VehicleSpeed ​​> 7.0".

[0207] For the natural language condition "Wheel-end braking force > 279000 N", based on the mapping relationship, the signal name corresponding to "Wheel-end braking force" is found to be "WheelBrakeForce", with the unit being "Newtons". The system replaces the physical quantity "Wheel-end braking force" with the signal name "WheelBrakeForce", converts the threshold "279000 N" to "279000", and generates the signal condition expression "WheelBrakeForce > 279000".

[0208] For the state condition "ABS not activated", based on the mapping relationship, the signal name corresponding to "ABS not activated" is found to be "IBCU_AbsActv", and the value range for "not activated" is "0x0". Replace the state description "ABS not activated" with the signal condition expression "IBCU_AbsActv == 0x0".

[0209] For the natural language condition "actual wheel end slip ratio > lookup table threshold", based on the lookup table mapping relationship established in S501, the system identifies that the condition contains lookup table logic. The input signal for this condition is recorded as "LateralAccel", and the output signal is the slip ratio threshold obtained from the lookup table. Since the condition itself cannot be directly converted into a signal expression with a fixed threshold, the system generates the corresponding lookup table logic marker information.

[0210] The natural language descriptions in the preconditions are also converted. For "controller powered on," it is converted into the corresponding power status signal condition expression according to the mapping relationship. For "vehicle moving forward," it is converted into the corresponding vehicle driving direction signal condition expression according to the mapping relationship. For "not on a bad road or washboard road," it is converted into the corresponding road surface status signal condition expression according to the mapping relationship.

[0211] Finally, all natural language conditions are converted into signal condition expressions. For fixed threshold conditions, precise numerical comparison expressions are generated; for state conditions, state value comparison expressions are generated; and for lookup logic conditions, corresponding lookup logic marker information is generated. These signal condition expressions and lookup logic marker information, along with other mapping information, are used in subsequent construction of prompt engineering templates.

[0212] The chassis domain electronic control system test scenario generation method provided in this application integrates functional logic elements with signal definition information, identifies each physical quantity or state mentioned in the functional logic elements, matches the corresponding signal name and value range in the communication matrix file, establishes a mapping relationship between each physical quantity or state in the functional logic elements and the signals in the communication matrix file, and, based on the mapping relationship, replaces the natural language conditions in the functional logic elements with the corresponding signal names and value conditions to generate signal condition expressions. This method, by establishing a precise mapping between the physical quantities or states in the functional logic elements and the signals in the communication matrix, and automatically replacing the natural language conditions with signal names and value conditions to generate signal condition expressions, replaces the traditional steps of manually consulting the communication matrix and manually writing signal conditions, eliminating human error in conversion and providing accurate signal-level condition input for subsequent test scenario generation.

[0213] Figure 6 Example 5 of the method for generating test scenarios for the chassis domain electronic control system provided in this solution, such as Figure 6 As shown, based on the foregoing embodiments, the method further includes:

[0214] S601: Based on the preconditions, triggering conditions, and expected behaviors of each test scenario, and combined with the parameter range and data type in the signal definition information, it automatically instantiates test cases with specific numerical configurations.

[0215] This step instantiates specific test cases for each test scenario in the abstract test scenario list generated by S206 according to its parameter range, generating specific test cases covering different combinations of parameter values, providing parameterized test input for subsequent generation of executable scripts.

[0216] Specifically, S601 is the transformation step from the abstract layer to the concrete instantiation layer of the test scenario. The test scenario generated in S206 is the abstract test scenario layer, in which the triggering conditions, preconditions, etc., are described in the form of parameter ranges, without containing specific executable parameters. This step instantiates the abstract scenario into concrete test cases based on the parameter ranges in each test scenario.

[0217] Taking the PCA function as an example, the abstract test scenario includes the trigger condition "vehicle speed greater than 7 meters per second (calibrable)". The parameter range of this condition is all vehicle speed values ​​greater than 7 meters per second. The system determines the combination of vehicle speed values ​​to be covered according to the test requirements. For example, it selects multiple specific values ​​such as vehicle speed of 8, 9, 10, 12, and 15 meters per second, and generates corresponding specific test cases for each.

[0218] For test scenarios involving road surface adhesion coefficient, different road surface conditions that need to be covered are determined according to the parameter range, such as high-adhesion road surfaces and low-adhesion road surfaces, and corresponding specific test cases are instantiated respectively.

[0219] For the lookup table logic test scenario, based on the parameter range of the lookup table input signal "lateral acceleration", determine the lateral acceleration values ​​that need to be covered, such as lateral acceleration of -10, -5, 0, 5, 10 m / s squared, etc., and instantiate the corresponding specific test cases to verify whether the lookup table threshold is correct under different lateral accelerations.

[0220] For timing-based scenarios, based on the exit condition "PCA exits after ABS activation", specific test cases are instantiated to verify the timing of PCA exit. The test cases are set to trigger ABS activation when PCA is in an active state, and the PCA exits in a timely manner.

[0221] Perform the instantiation operation described above on each test scenario in the test scenario list to generate one or more concrete test cases for each abstract scenario. Each concrete test case contains specific executable parameter values, such as specific vehicle speed values, specific braking force values, specific lateral acceleration values, etc., for S602 to use in generating executable scripts.

[0222] S602: Converts test cases into a scripting language that the test platform can recognize, generating executable test scripts.

[0223] This step converts the specific test cases generated by S601 instantiation into automated scripts executable by the corresponding test platform, enabling the test cases to be automatically executed on the hardware ring test bench, thus achieving automated conversion from test cases to executable scripts.

[0224] Specifically, S602 is the step of converting test cases into executable scripts. Based on the requirements of the target testing platform, the specific test cases generated in S601 are converted into executable scripts for the corresponding platform.

[0225] Different HiL testing platforms support different scripting languages ​​and testing frameworks. For example, some platforms support CAPL scripts, some support Python scripts, and some support either Python or C# scripts. Select the appropriate script generation template based on the target testing platform type, fill in the parameter values ​​from the specific test cases into the template, and generate an executable script.

[0226] Taking the PCA functional test of a certain platform as an example, a corresponding script is generated based on the parameter values ​​in the specific test cases. The script first initializes the test environment, including signal initialization, variable definition, and simulation step size settings. Then, it configures the signal values ​​according to the preconditions defined in the test cases, such as setting the vehicle speed signal to 8.0, the wheel-end braking force signal to 280000, and the ABS status signal to 0x0. Next, it excites the signals according to the trigger conditions, for example, triggering the test conditions at a specified time point according to the test steps defined in the test cases. The script also includes checkpoint logic to monitor whether the PCA activation flag signal is set at the expected time point, and result determination logic to compare the monitored signal values ​​with the expected results to determine whether the test passed or failed.

[0227] Generate a corresponding executable script for each specific test case, and organize all scripts into a complete test script set for S603 to execute on the HiL bench.

[0228] S603: Controls the executable test script to run on the hardware loop-in-the-loop test platform of the chassis domain controller, and determines whether the control logic of each test scenario passes based on the matching degree between the output signal and the expected behavior in the test scenario.

[0229] The executable script generated by S602 is executed on the hardware on the test bench. By injecting analog signals into the electronic control unit under test and collecting its response signals, the correctness of the control logic is verified, and the pass or failure result of each test case is recorded.

[0230] Specifically, S603 is the actual execution verification step of the test script. The executable script generated by S602 is deployed to the HiL bench for hardware-in-the-loop testing of the electronic control unit under test.

[0231] In the PCA function test, taking the "PCA normally activated at a vehicle speed of 8 meters per second" test case as an example, the signal board of the HiL bench injects a simulated signal into the electronic control unit. According to the timing set in the script, the vehicle speed signal is set to 8.0, the wheel end braking force signal is set to 280000, and the ABS status signal is set to 0x0, simulating the vehicle being in a critical state of imminent lock-up.

[0232] During script execution, the response signals of the electronic control unit are acquired in real time. For this test case, the PCA activation flag signal is monitored to change from 0 to 1 within the expected time window, and the EMB pre-braking request signal is also monitored for output.

[0233] The result determination logic in the script compares the collected actual response signal with the expected result. If the PCA activation flag signal is set within the expected time window and the EMB pre-braking request signal is output correctly, the system determines that the test case has passed. If the PCA activation flag signal is not set within the expected time window, or the EMB pre-braking request signal is not output correctly, the test case is determined to have failed.

[0234] Perform the above verification operations on each test case one by one, record the pass or fail result of each test case, and generate a complete test execution report for feedback and learning in subsequent steps.

[0235] S604: For test scenarios that pass verification, store the test scenario and its corresponding tag in the general test case library.

[0236] This step stores the test scenarios that have passed verification in S603, along with their corresponding tags, into a general test case library. This makes the scenarios that have been verified as effective through actual hardware-in-the-loop testing historical assets, which can be retrieved and reused in future projects, thus achieving continuous accumulation of test knowledge.

[0237] Specifically, S604 is the step of storing verified scenarios into the database. When a test case in S603 passes verification, the abstract test scenario corresponding to that test case and its related tags are stored in the general test case library.

[0238] Taking the PCA (Pressure Capability Assist) function as an example, a specific test case verifies that "PCA is normally activated on a high-friction surface at a vehicle speed of 8 meters per second," and the test passes. The system locates the abstract test scenario corresponding to this test case (i.e., the scenario where PCA is normally activated when a vehicle travels at a speed greater than 7 meters per second on a high-friction surface), and adds tags describing the characteristics and applicable scope of this scenario. Tags can include a function name tag to identify the functional module to which the scenario belongs, a test type tag to identify whether the scenario belongs to the normal trigger class, boundary condition class, or abnormal scenario class, a verification conclusion tag to indicate that the scenario has been verified and is effective through actual hardware-in-the-loop testing, and an operating condition tag to indicate the specific operating conditions to which the scenario applies.

[0239] Abstract test scenarios and all their tags are stored together in a general test case library. Once stored, the scenario becomes a historical asset. When other projects need to test similar functionality in the future, the scenario can be found and reused through tags or semantic search without redesigning it.

[0240] S605: For test scenarios that fail to be verified, generate corrected test scenarios based on the test execution logs, and update the corrected test scenarios to the general test case library.

[0241] For test scenarios that fail to be verified in S603, analyze the reasons for the failure and correct the test scenarios. Update the corrected test scenarios to the general test case library so that subsequent projects can avoid the verified failed scenarios or directly use the corrected scenarios when encountering similar requirements, thereby continuously improving the quality of the test case library.

[0242] Specifically, S605 is the step for correcting and updating verification failure scenarios. When a test case fails to verify in S603, the system analyzes the failure scenario and records the corrected scenario.

[0243] Taking the PCA function as an example, a test case verified that "PCA is activated normally on a low-friction surface at a vehicle speed of 15 meters per second," but the test failed. The system analyzed the collected response signals and found that the failure was caused by the slip rate rising too quickly under low-friction surface conditions, exceeding the response time window of the lookup table threshold, causing the PCA activation timing to deviate from the expectation.

[0244] Based on the above analysis, the corrected test scenarios were recorded, and the parameter ranges in the trigger conditions were adjusted. For example, the vehicle speed trigger threshold was adjusted from greater than 7 meters per second to greater than 10 meters per second to adapt to the slip ratio characteristics under low-friction road surfaces, or a lookup table-specific threshold correction coefficient for low-friction road surfaces was added. The corrected scenarios reflect the boundary conditions found in actual testing.

[0245] The revised test scenario will be updated to the general test case library, with a revision description tag attached, indicating the revisions and reasons for the revisions compared to the original scenario. When future projects need to test PCA functionality under similar low-adhesion road conditions, the revised scenario can be used directly, avoiding the need to go through the same verification failure process again.

[0246] The chassis domain electronic control system test scenario generation method provided in this application instantiates specific test cases based on the parameter ranges of each test scenario in the test scenario list. Based on these specific test cases, an executable script for the test platform is generated. The executable script is executed to verify the control logic, and pass or fail results are recorded. For test scenarios that pass verification, the test scenario and its corresponding tag are stored back in a general test case library. For test scenarios that fail verification, the corrected test scenario is recorded and the general test case library is updated. This method allows the general test case library to continuously accumulate verified and valid scenarios and eliminate or correct failed scenarios as each project's testing is executed, achieving continuous accumulation of test knowledge and iterative improvement in quality.

[0247] Figure 7 A schematic diagram of the chassis domain electronic control system test scenario generation device provided in this solution is shown below. Figure 7 As shown, the chassis domain electronic control system test scenario generation device 70 specifically includes:

[0248] Module 71 is used to acquire unstructured functional requirements documents and communication matrix files;

[0249] Extraction module 72 is used for:

[0250] Semantic analysis of functional requirements documents is performed using a large language model to identify and extract functional logic elements.

[0251] Parse the communication matrix file and extract signal definition information;

[0252] Module 73 is established to establish the mapping relationship between functional logic elements and signal definition information, and to convert the natural language conditions in the functional logic elements into signal condition expressions based on the mapping relationship.

[0253] Module 74 is used for:

[0254] Based on the semantic association between functional logic elements and signal definition information, a mapping relationship is established, and the conditions described in natural language in the functional logic elements are converted into signal condition expressions according to the mapping relationship.

[0255] Based on functional logic elements, signal definition information, mapping relationships, and signal condition expressions, a prompting engineering template for large language models is constructed.

[0256] The generation module 75 is used to input the prompt engineering template into the large language model and generate a list of structured test scenarios, where each test scenario includes preconditions, triggering conditions, expected behavior and related signals.

[0257] Furthermore, the extraction module 72 specifically includes:

[0258] The functional requirements document is divided into paragraphs, and the intent recognition and key information extraction of each paragraph are performed using a large language model to obtain the basic fields corresponding to each paragraph. The basic fields include the function name or ID, preconditions, trigger conditions, expected behavior, exit conditions and related signals.

[0259] For paragraphs containing multiple conditional logical combinations, temporal dependencies, lookup table mechanisms, or state transition relationships, the contextual understanding capability of the large language model is used to parse the natural language logical description and generate structured logical condition expressions. The logical condition expressions are used to represent the AND / OR relationship, temporal constraints, or state transition paths between conditions.

[0260] Logical conditional expressions are integrated with basic fields to form functional logic elements.

[0261] Furthermore, the extraction module 72 also includes:

[0262] The signals contained in each communication message and the corresponding signal attributes of each signal are parsed from the communication matrix file. The signal attributes include signal name, data type, value range, unit, physical conversion rule, transmission period and initial value. The value range includes enumerated state values ​​and corresponding semantic descriptions.

[0263] Each signal and its corresponding signal attributes are organized into a structured data model to form signal definition information.

[0264] Furthermore, module 73 is established, specifically including:

[0265] Identify physical quantities, state variables, or operation instructions in functional logic elements; search for signal names and value ranges with the same or similar semantics in signal definition information; and establish a mapping relationship between natural language description items in functional logic elements and communication signals.

[0266] Based on the mapping relationship, the physical quantities or state descriptions in the functional logic elements are replaced with the corresponding signal names and value conditions to generate signal condition expressions.

[0267] Furthermore, module 73 is established, specifically including:

[0268] Analyze the functional logic elements to identify whether table lookup logic is included;

[0269] If a lookup logic is detected, the input signal, output signal, and mapping rule corresponding to the lookup logic are extracted, and the lookup logic is marked as a prompt message in a structured form.

[0270] By integrating the prompt information, signal definition information, mapping relationships, and signal condition expressions, a prompt project template is obtained.

[0271] Furthermore, the chassis domain electronic control system test scenario generation device 70 also includes:

[0272] The first retrieval module 76 is used for:

[0273] The key semantics in the functional logic elements are vectorized and encoded to obtain semantic vector representations;

[0274] Based on semantic vector representation, similarity retrieval is performed in a pre-built general test case library to obtain matching historical test scenario fragments;

[0275] Embed historical test scenario snippets as contextual examples in the prompt project template.

[0276] Furthermore, the chassis domain electronic control system test scenario generation device 70 also includes:

[0277] The second retrieval module 77 is used for:

[0278] The system retrieves the preset vehicle system basic information database and obtains the state machine definition, mode switching logic, and control architecture information of the relevant electronic control unit based on the function name in the functional logic element. The vehicle system basic information database is built based on the MCP model and stores the state machine definition, mode switching logic, and hierarchical control architecture information of the electronic control unit.

[0279] The state machine definition, mode switching logic, and control architecture information are integrated into the prompt project template as contextual knowledge.

[0280] Furthermore, the chassis domain electronic control system test scenario generation device 70 also includes:

[0281] Test module 78 is used for:

[0282] Based on the preconditions, triggering conditions, and expected behaviors of each test scenario, and combined with the parameter range and data type in the signal definition information, test cases with specific numerical configurations are automatically instantiated.

[0283] Convert test cases into a scripting language that the test platform can recognize, and generate executable test scripts;

[0284] The executable test script is run on the hardware loop test platform of the chassis domain controller, and the control logic of each test scenario is determined to pass based on the degree of matching between the output signal and the expected behavior in the test scenario.

[0285] Furthermore, test module 78 is also used for:

[0286] For test scenarios that pass verification, the test scenarios and their corresponding tags are stored in the general test case library;

[0287] For test scenarios that fail to be verified, a corrected test scenario is generated by combining the test execution logs, and the corrected test scenario is updated to the general test case library.

[0288] Figure 8 A schematic diagram of the structure of the electronic device provided in this application. Figure 8 As shown, the electronic device 800 provided in this embodiment includes at least one processor 801 and a memory 802. Optionally, the electronic device 800 further includes a communication component 803. The processor 801, memory 802, and communication component 803 are connected via a bus 804.

[0289] In a specific implementation, at least one processor 801 executes computer execution instructions stored in memory 802, causing at least one processor 801 to perform the above-described method.

[0290] The specific implementation process of processor 801 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0291] In the above embodiments, it should be understood that the electronic control unit can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0292] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0293] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0294] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0295] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0296] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0297] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0298] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0299] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0300] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0301] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0302] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0303] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. A method for generating test scenarios for a chassis domain electronic control system, characterized in that, include: Obtain unstructured functional requirements documents and communication matrix files; The functional requirement document is semantically parsed using a large language model to identify and extract functional logic elements. These elements include basic fields and logical condition expressions. The basic fields are obtained by performing intent recognition and key information extraction on the functional requirement document. The logical condition expressions are obtained by parsing the logical description of the functional requirement document and are used to characterize the logical relationships between the items in the basic fields. The communication matrix file is parsed to extract signal definition information, which is a set of attribute information of signals in the communication matrix. Based on the semantic association between the functional logic elements and the signal definition information, a mapping relationship is established, and the natural language descriptions of the conditions in the functional logic elements are converted into signal condition expressions according to the mapping relationship. Based on the functional logic elements, the signal definition information, the mapping relationship, and the signal condition expression, a prompting engineering template for the large language model is constructed. The prompt engineering template is input into the large language model to generate a list of structured test scenarios, where each test scenario includes preconditions, triggering conditions, expected behavior, and related signals.

2. The method according to claim 1, characterized in that, The step of semantically parsing the functional requirements document using a large language model to identify and extract functional logic elements includes: The functional requirements document is divided into paragraphs, and the large language model is used to perform intent recognition and key information extraction on each paragraph to obtain the basic fields corresponding to each paragraph. The basic fields include the function name or ID, preconditions, triggering conditions, expected behavior, exit conditions, and related signals. For paragraphs containing multiple conditional logical combinations, temporal dependencies, lookup table mechanisms, or state transition relationships, the contextual understanding capability of the large language model is used to parse the natural language logical description and generate structured logical condition expressions. These logical condition expressions are used to characterize the AND / OR relationships, temporal constraints, or state transition paths between conditions. The logical condition expression is integrated with the basic field to form the functional logic element.

3. The method according to claim 1, characterized in that, The step of parsing the communication matrix file and extracting signal definition information includes: The signals contained in each communication message and the signal attributes corresponding to each signal are parsed from the communication matrix file. The signal attributes include signal name, data type, value range, unit, physical conversion rule, transmission period and initial value. The value range includes enumerated state values ​​and corresponding semantic descriptions. Each signal and its corresponding signal attributes are organized into a structured data model to form the signal definition information.

4. The method according to claim 1, characterized in that, The step of establishing a mapping relationship based on the semantic association between the functional logic elements and the signal definition information, and converting the natural language descriptions of the conditions in the functional logic elements into signal condition expressions according to the mapping relationship, includes: Identify the physical quantities, state variables, or operation instructions in the functional logic elements, search for signal names and value ranges with the same or similar semantics in the signal definition information, and establish a mapping relationship between the natural language description items in the functional logic elements and the communication signals. Based on the mapping relationship, the physical quantities or state descriptions in the functional logic elements are replaced with the corresponding signal names and value conditions to generate the signal condition expressions.

5. The method according to claim 1, characterized in that, The construction of a prompting engineering template for the large language model based on the functional logic elements, the signal definition information, the mapping relationship, and the signal condition expression includes: Analyze the functional logic elements to identify whether they include table lookup logic; If the table lookup logic is identified, the input signal, output signal and mapping rule corresponding to the table lookup logic are extracted, and the table lookup logic is marked as a prompt message in a structured form. The prompt information, the signal definition information, the mapping relationship, and the signal condition expression are integrated to obtain the prompt engineering template.

6. The method according to claim 1, characterized in that, Before constructing the aforementioned prompt project template, the method further includes: The key semantics in the functional logic elements are vectorized and encoded to obtain semantic vector representations; Based on the semantic vector representation, similarity retrieval is performed in a pre-built general test case library to obtain matching historical test scenario fragments; The historical test scenario fragments are embedded as context examples in the prompt project template.

7. The method according to claim 1, characterized in that, Before constructing the aforementioned prompt project template, the method further includes: The system retrieves the preset vehicle system basic information database and obtains the state machine definition, mode switching logic, and control architecture information of the relevant electronic control unit based on the function name in the functional logic element. The vehicle system basic information database is built based on the MCP model and stores the state machine definition, mode switching logic, and hierarchical control architecture information of the electronic control unit. The state machine definition, mode switching logic, and control architecture information are integrated into the prompt project template as contextual knowledge.

8. The method according to claim 1, characterized in that, The method further includes: Based on the preconditions, triggering conditions, and expected behaviors of each test scenario, and combined with the parameter range and data type in the signal definition information, test cases with specific numerical configurations are automatically instantiated. The test cases are converted into a scripting language that the test platform can recognize, generating executable test scripts; The executable test script is controlled to run on the hardware loop-in-the-loop test platform of the chassis domain controller, and the control logic of each test scenario is determined to pass based on the matching degree between the output signal and the expected behavior in the test scenario.

9. The method according to claim 8, characterized in that, The method further includes: For test scenarios that pass verification, the test scenarios and their corresponding tags are stored in a general test case library; For test scenarios that fail to be verified, a corrected test scenario is generated by combining the test execution log, and the corrected test scenario is updated to the general test case library.

10. A chassis domain electronic control system test scenario generation device, characterized in that, include: The acquisition module is used to acquire unstructured functional requirements documents and communication matrix files; Extraction module, used for: The functional requirement document is semantically parsed using a large language model to identify and extract functional logic elements. These elements include basic fields and logical condition expressions. The basic fields are obtained by performing intent recognition and key information extraction on the functional requirement document. The logical condition expressions are obtained by parsing the logical description of the functional requirement document and are used to characterize the logical relationships between the items in the basic fields. The communication matrix file is parsed to extract signal definition information, which is a set of attribute information of signals in the communication matrix. A module is established to establish a mapping relationship between the functional logic elements and the signal definition information, and to convert the natural language conditions in the functional logic elements into signal condition expressions based on the mapping relationship. Build modules are used for: Based on the semantic association between the functional logic elements and the signal definition information, a mapping relationship is established, and the natural language descriptions of the conditions in the functional logic elements are converted into signal condition expressions according to the mapping relationship. Based on the functional logic elements, the signal definition information, the mapping relationship, and the signal condition expression, a prompting engineering template for the large language model is constructed. The generation module is used to input the prompt engineering template into the large language model to generate a list of structured test scenarios, wherein each test scenario includes preconditions, triggering conditions, expected behavior and related signals.

11. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 9.

Images