Vehicle testing method, electronic device, and storage medium

Abstract

The application provides a vehicle testing method, an electronic device and a storage medium, and relates to the technical field of vehicle testing. The method comprises the following steps: in response to receiving testing demand information of a vehicle, searching a vehicle testing knowledge base related to the vehicle to obtain a target knowledge segment associated with a target testing demand, the testing demand information being information describing the target testing demand based on a natural language; generating target testing instructions of the target testing demand according to the target knowledge segment and the testing demand information; controlling a stream computing platform to generate a testing operation specification according to the target testing instructions, so that the stream computing platform acquires target testing data streams associated with the target testing demand from the vehicle according to the testing operation specification, and performs testing analysis for the target testing demand according to the target testing data streams. The application effectively improves the configuration efficiency and iterative testing efficiency of the vehicle in the research and development testing process.

Description

Technical Field

[0001] This application relates to the field of vehicle testing technology, specifically to a vehicle testing method, electronic device, and storage medium. Background Technology

[0002] Vehicle R&D testing, through systematic verification, ensures vehicle safety and is an indispensable and crucial process from vehicle design to mass production. With the development of electrification and intelligence, the focus of testing has expanded to the three core electric systems (battery, motor, and electronic control), advanced driver assistance systems (ADAS), and autonomous driving, widely employing scenario-based simulation, real-vehicle road testing, and data-driven closed-loop iteration.

[0003] Currently, the parameter configuration and rule modification of relevant testing solutions heavily rely on professional programming skills. Personnel need to adjust monitoring strategies in real-time based on testing requirements across multiple iterations, making rapid iterative loops impossible and thus hindering vehicle development progress. Therefore, it is urgent to address the problem of low iterative testing efficiency in vehicle development and testing. Summary of the Invention In view of the above-mentioned shortcomings of related technologies, this application provides a vehicle testing method, electronic device and storage medium, which effectively improves the efficiency of iterative testing of vehicles in the research and development testing process.

[0004] Firstly, this application provides a vehicle testing method, including: In response to receiving test requirement information for a vehicle, a search is performed in a vehicle test knowledge base related to the vehicle to obtain a target knowledge fragment associated with the target test requirement, wherein the test requirement information is information describing the target test requirement based on natural language. Based on the target knowledge fragment and the test requirement information, generate the target test instruction corresponding to the target test requirement; According to the target test instruction, the control flow computing platform generates a test job specification, so that the flow computing platform can obtain a target test data stream associated with the target test requirement from the vehicle according to the test job specification, and perform test analysis for the target test requirement based on the target test data stream.

[0005] In an optional implementation, generating the target test instruction for the target test requirement based on the target knowledge fragment and the test requirement information includes: The target knowledge fragments and the test requirement information are structured and assembled to obtain target prompt words; The target prompt word is input into a large language model for semantic information parsing to obtain the semantic parsing result; Based on the semantic parsing results, the target test instructions corresponding to the target test requirements are generated.

[0006] In an optional implementation, the step of inputting the target prompt word into a large language model for semantic information parsing to obtain the semantic parsing result includes: The target prompt words are used to identify the target operational intent of the target test requirement; Test entity extraction is performed on the target prompt words to obtain the target test entities of the target test requirements; Based on the target prompt words, knowledge signal mapping is performed on the target test entity to obtain the underlying system information; The semantic parsing results include the target operation intent, the target test entity, and the underlying system information.

[0007] In an optional implementation, before the control flow computing platform generates the test job specification according to the target test instruction, the method further includes: The target test command is validated and canary release verified, and the target test command is sent to the stream computing platform based on the verification results.

[0008] In an optional implementation, the step of performing instruction verification and canary release verification on the target test instruction, and sending the target test instruction to the stream computing platform based on the verification results, includes: Perform syntax and permission checks on the target test instructions; If the target test instruction passes the verification, the stream computing platform is controlled to generate a grayscale operation process, so that the stream computing platform performs grayscale test analysis on at least one of the vehicles according to the grayscale operation process. If the grayscale test analysis meets the preset test conditions, the target test instruction is sent to the stream computing platform.

[0009] In an optional implementation, the step of responding to receiving test requirement information for a vehicle by retrieving a target knowledge fragment associated with the target test requirement from a vehicle test knowledge base related to the vehicle includes: Based on the test requirement information, the embedded model is invoked to perform vector transformation to obtain the query vector; Using the query vector as input, an approximate nearest neighbor search is performed in the vehicle test knowledge base to obtain at least one target knowledge block that is most similar to the query vector; The target knowledge blocks are sorted and concatenated according to their similarity to obtain the target knowledge fragment associated with the target testing requirement.

[0010] In an optional implementation, before retrieving a target knowledge fragment associated with the target test requirement from a vehicle-related vehicle test knowledge base in response to receiving test requirement information for the vehicle, the method further includes: The vehicle testing knowledge base is constructed based on multi-source heterogeneous data related to vehicle testing.

[0011] In an optional implementation, constructing the vehicle testing knowledge base based on multi-source heterogeneous data related to vehicle testing includes: Knowledge extraction and cleaning are performed on the multi-source heterogeneous data to obtain knowledge text; Based on the knowledge text, knowledge is divided into blocks according to semantic boundaries to obtain multiple knowledge blocks; By embedding the knowledge blocks into vectors, multiple high-dimensional vectors are obtained. Each of the high-dimensional vectors is stored in a vector database, and an approximate nearest neighbor index of each of the high-dimensional vectors is constructed to obtain the vehicle test knowledge base.

[0012] In a second aspect, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the vehicle testing method as described in the first aspect of this application.

[0013] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the vehicle testing method as described in the first aspect of this application.

[0014] The vehicle testing method, electronic device, and storage medium provided in this application, in response to receiving test requirement information for a vehicle, retrieves target knowledge fragments associated with the target test requirements from a vehicle-related test knowledge base; generates target test instructions for the target test requirements based on the target knowledge fragments and test requirement information; and, based on the target test instructions, controls the flow computing platform to generate test job specifications, enabling the flow computing platform to obtain target test data streams associated with the target test requirements from the vehicle according to the test job specifications, and executes test analysis for the target test requirements based on the target test data streams. This application realizes a shift from professional coding configuration to natural language interaction, accurately understanding user intent based on test requirement information and converting it into machine-executable target test instructions. Simultaneously, it utilizes the configuration management capabilities of the flow computing platform to construct a fully automated closed-loop process from test requirements to test configuration activation, effectively improving the configuration efficiency and iterative testing efficiency of vehicles during the R&D testing process. Attached Figure Description

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

[0016] Figure 1 This is a first schematic diagram of the vehicle testing method flow provided in the embodiments of this application; Figure 2 This is a second schematic diagram of the vehicle testing method flow provided in the embodiments of this application; Figure 3 This is a third schematic diagram of the vehicle testing method flow provided in the embodiments of this application; Figure 4 This is the fourth schematic diagram of the vehicle testing method flow provided in the embodiments of this application; Figure 5 This is the fifth schematic diagram of the vehicle testing method flow provided in the embodiments of this application; Figure 6 This is the sixth schematic diagram of the vehicle testing method flow provided in the embodiments of this application; Figure 7 This is a schematic diagram of the vehicle testing process provided in the embodiments of this application; Figure 8 This is a schematic diagram of the vehicle testing device structure provided in the embodiments of this application; Figure 9 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application.

[0017] Explanation of key component symbols: 800. Vehicle testing device; 810. Knowledge retrieval module; 820. Instruction generation module; 830. Test analysis module; 900. Electronic equipment; 910. Processor; 920. Communication interface; 930. Memory; 940. Communication bus. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be further described clearly and completely below with reference to the accompanying drawings of the embodiments. It should be noted that the described embodiments are merely some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0019] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of this application.

[0021] Currently, the parameter configuration and rule modification of vehicle R&D testing solutions heavily rely on professional programming skills. Functions such as customized real-time monitoring dashboards, configured data query interfaces, and set anomaly warning rules all require modification of backend database configuration files, writing application programming interface (API) call code, or adjusting algorithm parameters. System configuration requires mastery of computer technology knowledge such as signal naming conventions, database table structures, and API call protocols. If test engineers need to add monitoring signals, modify warning thresholds, or adjust dashboard display content, they must submit a work order, which is then implemented by design or data engineers. This process is cumbersome and has long response times, hindering the rapid implementation of requirements.

[0022] Furthermore, vehicle development and testing involves multiple iterations: identifying problems, adjusting testing strategies, re-collecting data, and verifying optimization effects. Each iteration requires personnel to adjust monitoring strategies in real time based on testing needs, hindering rapid iteration and significantly extending the iteration cycle, thus restricting vehicle development progress. Therefore, it is urgent to address the problem of low iterative testing efficiency in vehicle development and testing.

[0023] To address the aforementioned problems in related technologies, this application provides a vehicle testing method that effectively improves the efficiency of iterative testing during vehicle research and development. The vehicle testing method provided in this application can be applied to electronic devices, such as computer terminals or servers. Figure 1 As shown, the vehicle testing method may include steps S110 to S130.

[0024] S110. In response to receiving test requirement information for the vehicle, retrieve the target knowledge fragment associated with the target test requirement from the vehicle-related vehicle test knowledge base.

[0025] In this embodiment, the vehicle can be a private car, such as a sedan, sports / utility vehicle (SUV), multi-purpose vehicle (MPV), or pickup truck. The vehicle can also be a commercial vehicle, such as a van, bus, small truck, or large semi-trailer. The vehicle can be a gasoline-powered vehicle or a new energy vehicle. When the vehicle is a new energy vehicle, it can be a hybrid vehicle or a pure electric vehicle.

[0026] Among them, the test requirement information is information describing the target test requirements based on natural language. These target test requirements are business requirements for testing and verifying vehicles, including but not limited to signal or data monitoring, dynamic configuration of warning parameters, and real-time addition of monitoring signals.

[0027] As an optional implementation, the test requirement information can be obtained through a user interface based on a large language model as the core of the interaction. This user interface can be a graphical interface or a command-line interface, etc. This user interface allows relevant testers to directly describe the target test requirements using natural language, thereby obtaining the test requirement information. For example, relevant testers can input test requirement information such as "Please monitor the motor temperature in the Controller Area Network (CAN) signal when the vehicle speed exceeds 120km / h in real time, and pop up an alarm if it exceeds 100 degrees", or "Monitor the motor speed fluctuation when the vehicle speed is greater than 100km / h".

[0028] Understandably, the user interface with natural language interaction enables a shift from professional coding configuration to natural language interaction, breaking down professional knowledge barriers and allowing relevant testers to directly raise requirements using business terminology they are familiar with, thus eliminating or reducing reliance on technical professionals.

[0029] Furthermore, a vehicle testing knowledge base specifically for equipment testing is pre-built for vehicles. This vehicle testing knowledge base is constructed by continuously collecting and organizing structured and unstructured data such as historical test cases, equipment signal definition tables, API interface documents, and expert rules, and then vectorizing and indexing them.

[0030] Specifically, based on the test requirement information, the system can retrieve the most relevant signal, interface, and rule information from the vehicle test knowledge base, thereby obtaining target knowledge fragments associated with the target test requirement. First, the test requirement information is vectorized. Then, using this vector as the query condition, the system retrieves multiple most relevant target knowledge fragments from the vehicle test knowledge base. These target knowledge fragments may include, but are not limited to, knowledge information such as signal mapping relationships, API call specifications, and historical similar requirements. These target knowledge fragments provide accurate and up-to-date test domain knowledge context for the subsequent large language model, ensuring that it can accurately map the ambiguous natural language test requirement information from relevant testers into specific target test instructions.

[0031] S120. Based on the target knowledge fragments and test requirement information, generate target test instructions corresponding to the target test requirements.

[0032] In this embodiment, a large language model agent is introduced. This large language model has the ability to recognize semantics, transform logic, and automatically generate instructions. It can accurately understand user intent and generate target test instructions for target test requirements, thereby accurately converting business requirements into executable test instructions for standardized interfaces.

[0033] Understandably, target knowledge fragments and test requirement information can be structurally assembled according to a pre-defined prompt word template to form a complete target prompt word. This target prompt word explicitly tells the large language model its role as an instruction generator and constrains the output format to be a directly executable system instruction. The assembled target prompt word is input into the pre-trained large language model. The large language model uses its powerful semantic understanding and code generation capabilities to parse the user's intent and prioritizes referencing accurate knowledge from the target knowledge fragment to generate the corresponding target test instruction. For example, for the following test requirement information: "Change the waiting time of car 0421(P145) to 15 seconds", the large language model can generate the following target test instruction: "UPDATE guiya_num SET times = 15 WHERE vehicle_id = '0421(P145)'".

[0034] The target test instructions, depending on the interface of the receiving system, can be any one or more of the following types: Structured Query Language (SQL) statements, Application Programming Interface (API) call parameters, and configuration code snippets. For example, for update (UPDATE), insert (INSERT), or delete (DELETE) operations on a configuration database, a SQL statement can be used; for a RESTful API request body encapsulated in a lightweight data exchange format (JavaScript Object Notation, JSON), API call parameters can be used; and for parameter update scripts for stream computing jobs, configuration code snippets can be used.

[0035] S130. According to the target test instructions, the control flow computing platform generates test job specifications so that the flow computing platform can obtain the target test data stream associated with the target test requirements from the vehicle according to the test job specifications, and perform test analysis for the target test requirements according to the target test data stream.

[0036] In this embodiment of the application, the stream computing platform serves as the core of the test processing, responsible for receiving and executing the target test instructions sent by the large language model, and performing millisecond-level or second-level processing and analysis on the continuously generated data stream.

[0037] It should be noted that the device generating the target test instructions and the stream computing platform can be the same electronic device or different electronic devices. When the stream computing platform is deployed separately, it can be deployed via an electronic device or the cloud. This stream computing platform can be built based on the open-source stream processing framework (Apache Flink).

[0038] Optionally, a standardized configuration interface layer can be built for the stream computing platform. This layer abstracts adjustable monitoring parameters in stream computing jobs (such as alert thresholds, monitoring signal lists, judgment logic conditions, and time window sizes) into programmable API interfaces and database table structures. This transforms configuration changes that previously required manual code modification into actions that can be accomplished through standardized Structured Query Language (SQL) statements or API calls. For example, the monitoring signal subscription list corresponds to the `signal_subscription` table in the database, the alert rule configuration corresponds to the `alert_rules` table, and the Flink job parameters correspond to the API interfaces.

[0039] In this embodiment, when the large language model sends a target test instruction to the stream computing platform, the stream computing platform obtains the target test data stream associated with the target test requirements from the vehicle according to the test job specification, and performs test analysis for the target test requirements based on the target test data stream. The test job specification is the relevant rules and job flow automatically generated and deployed by the stream computing platform based on the updated configuration file in the new version of the stream computing job.

[0040] Optionally, the stream computing platform can also be configured with an automated configuration executor. This executor is responsible for receiving and executing target test commands. For example, when receiving SQL or API commands from a large language model, it automatically updates the database configuration tables. It can also automatically restart stream computing jobs to execute test job specifications. For instance, after parameter configuration changes, it automatically calls the API, triggering a safe restart of the corresponding stream computing job. After a new stream computing job starts, the original stream computing job is smoothly taken offline, ensuring the complete update of the test logic. Status verification and feedback can also be performed. For example, after confirming that the stream computing job has restarted successfully and the new test job specifications have taken effect, the results are fed back to the user interface.

[0041] Furthermore, the stream computing platform can trigger early warnings and provide feedback during the testing process. When the early warning conditions are met (e.g., the motor temperature exceeds 100°C), the stream computing platform automatically triggers early warning actions (e.g., pop-ups and push notifications) and sends them to the user interface of the relevant testers. Based on the feedback results, the relevant testers can submit new adjustment requests (e.g., modifying thresholds and adding monitoring signals) through the dialog interface at any time, thereby enabling rapid iterative testing adjustments.

[0042] Based on this, the system accurately understands user intent according to test requirements and converts it into machine-executable target test instructions. At the same time, the automatic instruction generation is deeply integrated with the configuration management capabilities of the stream computing platform, which transforms the test strategy adjustment that originally took several hours to complete into an automated operation that users can complete in minutes using natural language. This greatly improves the configuration efficiency and testing efficiency in vehicle R&D testing.

[0043] In some implementations, the user's test requirements information and retrieved target knowledge fragments are used together as target prompts, which are then input into a large language model. The large language model utilizes its semantic understanding and code generation capabilities to generate target test instructions for the target test requirements. For example... Figure 2 As shown, generating target test instructions corresponding to target test requirements based on target knowledge fragments and test requirement information may include steps S210 to S230.

[0044] S210. The target knowledge fragments and test requirement information are structured and assembled to obtain target prompt words.

[0045] In this embodiment, a predefined structured prompt word template can be used to structurally assemble target knowledge fragments and test requirement information. In this way, the large language model can directly reference the retrieved accurate knowledge during subsequent parsing and generation processes, significantly improving the accuracy of signal mapping and the reliability of instruction generation.

[0046] For example, a structured prompt word template contains four semantic blocks: system roles, reference knowledge, user requirements, and output constraints. First, the retrieved target knowledge fragments are filled into the reference knowledge block in text block order; then, the user's test requirement information is directly filled into the user requirement block; each block can be explicitly separated using specific delimiters or Extensible Markup Language (XML) tags to prevent semantic confusion. The assembled target prompt words serve as the complete input to the large language model.

[0047] S220. Input the target prompt word into the large language model for semantic information parsing to obtain the semantic parsing result.

[0048] Understandably, the target prompt words are passed as input to the large language model, which first identifies key entities in the test requirement information. These entities may include the names of the physical quantities to be tested or the vehicle components to be tested, such as vehicle speed, motor temperature, and battery.

[0049] Secondly, based on the knowledge base mapping relationship embedded in the target prompt words, the large language model converts the above joint entities into precise signal identifiers that can be recognized by the streaming computing platform. For example, it maps vehicle speed to the Vehicle_Speed ​​signal and motor temperature to the VCU_Motor_Temp signal.

[0050] In addition, large language models can further extract logical conditions from test requirement information, such as numerical comparison operators and thresholds, i.e., judgment benchmarks such as exceeding 120 or exceeding 100, and extract corresponding action instructions, such as pop-up alarms or logging.

[0051] Finally, the large language model outputs structured semantic parsing results, which encapsulate information such as signal or device component names, logical operators, thresholds, and action types in a preset format, providing a foundation for subsequent instruction generation.

[0052] S230. Based on the semantic parsing results, generate target test instructions corresponding to the target test requirements.

[0053] In this embodiment, the large language model can generate target test instructions that can be executed by the stream computing platform according to the semantic parsing results, corresponding to the target test requirements, and supports the generation of multiple types of target test instructions.

[0054] For example, regarding changes to monitoring logic thresholds, corresponding SQL statements can be generated based on test requirements. The user's test requirement is: "Please change the monitoring logic of the fuel injector monitoring model for vehicle 0421 (P145) to: record the rail pressure baseline value 15 seconds after engine shutdown, and trigger an alarm when the rail pressure value drops by more than 1 MPa." The large language model can generate the following SQL statement based on the obtained semantic parsing results: "UPDATE guiya_num" SET times= 15, threshold = 1 WHERE vehicle_id = '0421(P145)';".

[0055] Based on this, a large language model was used to achieve a dimensional improvement from fixed rule execution to intelligent semantic understanding and test instruction generation, effectively realizing the transformation of test requirements and configurations. The entire process is fully automated, requiring no manual programming or parameter configuration, and directly converting the business natural language of test-related personnel into accurate and executable target test instructions, effectively improving vehicle testing efficiency.

[0056] In some implementations, after receiving a target prompt word containing target knowledge fragments and test requirement information, the large language model performs an internal semantic understanding and information extraction process to obtain a semantic parsing result. This semantic parsing result may include the target operation intent, the target test entity, and underlying system information. For example... Figure 3 As shown, the target prompt word is input into the large language model for semantic information parsing to obtain the semantic parsing result, which may include steps S310 to S330.

[0057] Step S310: Identify the test intent of the target prompt words to obtain the target operation intent of the target test requirement.

[0058] In this embodiment, test intent is identified based on target prompt words. A large language model is used to understand the semantic direction of user needs and classify target test needs into preset operation categories, including but not limited to configuration updates, rule operations, status queries, or job control, thereby obtaining clear target operation intents and providing a basis for the generation of subsequent target test instructions.

[0059] For example, rule operations for status monitoring can include the following target operation intentions: adding a rule to create a new monitoring and alerting rule; modifying a rule to adjust the threshold or conditions of an existing rule; and deleting a rule to stop a monitoring rule.

[0060] Step S320: Extract test entities from the target prompt words to obtain the target test entities for the target test requirements.

[0061] Furthermore, test entity extraction is performed on the target prompt words. The named entity recognition method is used to extract key elements from the target test requirements, including but not limited to signal or device component names, comparison thresholds, time window lengths, and device identification information. These elements are integrated into target test entities for the target test requirements and used for subsequent instruction construction.

[0062] Optionally, the target test entity may include, but is not limited to, signal entities, condition entities, and threshold entities. For example, signal entities may include elements such as vehicle speed, motor temperature, and battery; condition entities may include elements such as greater than, exceeding, less than, and continuous; and threshold entities may include elements such as 120 km / h and 100°C.

[0063] Step S330: Map knowledge signals to the target test entity based on the target prompt words to obtain the underlying system information.

[0064] In this embodiment, knowledge signal mapping is performed on the extracted target test entities based on the target prompt words. Specifically, pre-stored signal mapping knowledge is read from the target knowledge fragment, which records the correspondence between business signal names and underlying system signal names. For each business signal name in the target test entity, the corresponding underlying system signal identifier can be obtained by matching it through the corresponding signal mapping knowledge. For example, the signal entity "vehicle speed" is mapped to the underlying system signal "Vehicle_Speed", and the signal entity "motor temperature" is mapped to the underlying system signal "VCU_Motor_Temp".

[0065] Understandably, after mapping, complete underlying system information, including signal names, data types, and value ranges, can be obtained, allowing for direct invocation in the generation of subsequent target test instructions. This mapping process ensures that business concepts described in the user's natural language can be accurately converted into technical parameters that the stream computing platform can recognize and process.

[0066] Based on this, a large language model is used to efficiently convert natural language requirements into structured semantic information, significantly improving the accuracy of understanding user testing intentions. Entity recognition and signal mapping avoid ambiguity and errors inherent in manual parsing, providing standardized input for subsequent instruction generation, thereby reducing the cost of manual intervention and enhancing the automation level and response efficiency of vehicle testing.

[0067] In some implementations, after the target test instruction is generated and before the stream computing platform generates the test job specification according to the target test instruction, the target test instruction can be verified and gray-scale released. Based on the verification results, the target test instruction is sent to the stream computing platform to ensure that the target test instruction is correct and reliable before it is executed by the stream computing platform.

[0068] Optionally, the target test instructions may be validated using methods including but not limited to syntax validation and permission validation. Syntax validation is used to check whether the target test instructions conform to the language specifications of the stream computing platform, and permission validation is used to verify whether the relevant testers have the corresponding permissions to execute the relevant tests.

[0069] Furthermore, for testing multiple vehicles, after the command verification is passed, the system enters the canary release verification phase. Following a preset canary release strategy, the target test command can be applied to only a subset of vehicles or within a limited time window for initial testing and verification. The canary release strategy can be based on device identifier suffixes, test task groups, or device regions.

[0070] Understandably, the decision to send the target test command is based on the verification results of the command verification and canary release verification. If both command verification and canary release verification pass, the target test command can be fully deployed to the stream computing platform for testing and analysis of all vehicles, triggering corresponding deployment actions. If any verification step fails, the deployment process of the target test command can be terminated, a feedback report containing the reason for the failure can be generated, and the report can be pushed to the user interface for relevant testers to analyze. Simultaneously, automatic rollback operations can be configured to restore the configuration of vehicles undergoing canary release verification to their state before the change.

[0071] Based on this, the automated verification and validation process replaces manual item-by-item checking or manual small-scale trial runs, which significantly shortens the cycle from the submission of requirements to the full implementation of rules, while reducing the probability of human error and effectively improving vehicle testing efficiency.

[0072] In some implementations, such as Figure 4 As shown, performing instruction verification and gray-scale release verification on the target test instruction, and sending the target test instruction according to the verification result, may include steps S410 to S430.

[0073] S410. Perform syntax and permission checks on the target test instructions.

[0074] Optionally, syntax validation can include syntax correctness validation and semantic validity validation. Syntax correctness validation primarily checks the syntax of the target test instruction, such as whether a structured query statement conforms to basic syntax rules and whether there are any keyword spelling errors or field type mismatches. Semantic validity validation determines whether the signal names, table fields, and threshold ranges referenced in the target test instruction belong to the predefined set of valid values ​​in the stream computing platform, avoiding execution failures due to referencing non-existent resources. For example, it verifies whether the signal name in a conditional expression exists in the signal definition table of the knowledge base, or checks whether the threshold type matches the signal unit; for example, the engine speed threshold cannot be negative.

[0075] In this embodiment of the application, permission verification may be to verify whether the relevant testers have the authority to create or modify the relevant type of test rules, and at the same time check whether the requested test requirements are within the authorized scope.

[0076] Understandably, if all syntax and permission checks fail, the error reason will be returned directly to the user interface, and subsequent testing steps will be terminated.

[0077] S420. If the target test instruction passes the verification, the control flow computing platform generates a grayscale operation process so that the flow computing platform can perform grayscale test analysis on at least one vehicle according to the grayscale operation process.

[0078] In this embodiment of the application, if the syntax and permission verification of the target test instruction passes, a grayscale job creation request is submitted to the stream computing platform. The grayscale job creation request may include the target test instruction, the grayscale object identifier list, and grayscale observation window parameters.

[0079] Furthermore, after receiving a request, the stream computing platform initiates an independent canary job process from the latest save point in the currently running stream computing job process. This canary job process inherits all data streams from the main job process and loads the target test instructions to perform test configuration changes. Simultaneously, within the canary job process, a subset of vehicles or a single edge computing node is selected as canary test devices based on a list of canary object identifiers. Only data streams from these canary test devices are received; for example, only status signals reported by specific devices or edge devices are received.

[0080] Once the grayscale process job is triggered to start running, the health status of the grayscale process job is continuously monitored within the preset grayscale observation window, including but not limited to whether the configuration has been successfully updated, whether the stream computing job has been restarted normally and the job delay, and whether the monitoring alarms are triggered as expected and the alarm frequency.

[0081] S430. If the grayscale test analysis meets the preset test conditions, then send the target test command to the stream computing platform.

[0082] If all the status monitoring indicators in the grayscale observation window are within the normal range, the grayscale test analysis is determined to meet the preset test conditions. At this point, preparations can be made to extend the configuration changes corresponding to the target test command to all vehicles, i.e., send the target test command to the stream computing platform to execute the test analysis for all vehicles. If the grayscale test analysis fails, the stream computing platform directly terminates the grayscale operation process, and the original stream computing job continues to run, achieving zero-impact rollback.

[0083] As an optional implementation, after the canary release verification is passed, the stream computing platform will initiate a standardized test job specification update process to ensure business continuity and data consistency.

[0084] The update process can be triggered by calling the cloud platform's job management API or sending an internal message. Based on Flink's holdpoint mechanism, the update process first performs a global state snapshot of the currently running stream computing job and persists it. Then, the current stream computing job is stopped, and a new stream computing job is started based on the new test job specifications. Finally, all stream computing states are precisely restored from the snapshot point. The entire update process can be completed in a very short time, ensuring no data loss and no duplication; the business layer perceives only a brief delay.

[0085] It should be noted that after the API call of the stream computing platform, you can listen for the returned configuration status. If the configuration test is successful, a configuration success message will be returned to the front-end user interface. If the configuration test fails, an error message will be returned, prompting the relevant testers to check the requirements or contact the administrator.

[0086] Based on this, syntax errors and illegal parameters are filtered out before test analysis through instruction verification, avoiding system crashes or data pollution caused by direct full implementation due to configuration errors, and significantly improving the security of vehicle test instruction execution. Gray-scale release verification restricts the new target test instructions to a minimum scope of application. Even if anomalies are found during verification, the impact is limited to a small number of gray-scale test objects. Combined with an automatic rollback mechanism, the impact of faults can be controlled within an effective recovery range.

[0087] In some implementations, a retrieval-enhanced generation architecture can be employed, using vector retrieval to provide device testing domain knowledge support for the large language model, ensuring the accuracy of the generated target test instructions. For example... Figure 5 As shown, in response to receiving test requirement information for a vehicle, a search is conducted in a vehicle-related vehicle test knowledge base to obtain a target knowledge fragment associated with the target test requirement, which may include steps S510 to S530.

[0088] S510. Based on the test requirement information, call the embedded model to perform vector transformation and obtain the query vector.

[0089] In this embodiment of the application, upon receiving natural language testing requirement information input by relevant testers... Q At that time, the same embedding model used when building the vehicle test knowledge base is directly invoked to store the test requirement information. Q Convert to query vector q ,Right now q =Embedding(Q) ,in Embedding This represents the embedded model.

[0090] S520. Using the query vector as input, perform an approximate nearest neighbor search in the vehicle test knowledge base to obtain at least one target knowledge block that is most similar to the query vector.

[0091] In this embodiment of the application, a query vector is used. q As input, an approximate nearest neighbor search is performed in a pre-built vehicle test knowledge base to find the nearest neighbor that matches the query vector. q semantically most similar K There are several target knowledge blocks. The query vector can be represented using cosine similarity. q The cosine similarity between the data and each knowledge block is calculated as follows:

[0092] In the above formula, Represents the query vector q With the i Vector of knowledge blocks cosine similarity, The closer the value is to 1, the more relevant the target knowledge block is to the test requirements information.

[0093] S530. Sort and concatenate the target knowledge blocks according to their similarity to obtain the target knowledge fragments related to the target testing requirements.

[0094] Understandably, the original text content of each retrieved target knowledge block is sorted and concatenated according to its similarity from high to low to form a target knowledge fragment associated with the target testing requirement. This target knowledge fragment may include, but is not limited to, API interface specifications and configuration examples of historical similar testing requirements.

[0095] Based on this, by retrieving the target knowledge fragments most relevant to the current user's testing needs from the vehicle testing knowledge base, the corresponding knowledge basis is provided for the large language model to generate target test instructions, avoiding the illusion problem and ensuring the accuracy of instruction generation.

[0096] In some implementations, before retrieving the target knowledge fragment associated with the target test requirement from the vehicle-related vehicle test knowledge base in response to receiving test requirement information for the vehicle, a vehicle test knowledge base can also be constructed based on multi-source heterogeneous data related to vehicle testing.

[0097] In this embodiment, a vehicle testing knowledge base is constructed by collecting and organizing multi-source knowledge data in the field of equipment testing. This multi-source knowledge data includes, but is not limited to, equipment signal definition files, historical test cases and test requirement records, API interface documents of the data acquisition platform, and expert experience rules. Specifically, the equipment signal definition files record information such as signal names, communication codes, and parsing rules, while expert experience rules refer to typical fault modes and their corresponding data characteristics.

[0098] Based on this, the vehicle testing knowledge base built on multi-source knowledge data provides high-precision and traceable domain knowledge support for the large language model, enabling the large language model to understand the professional terminology and signal mapping relationships in the equipment testing field. This is the foundation for the accurate execution of subsequent intelligent conversion of test requirement information.

[0099] In some implementations, the construction of the vehicle test knowledge base can be a preprocessing step, such as... Figure 6 As shown, constructing a vehicle testing knowledge base based on multi-source heterogeneous data related to vehicle testing may include steps S610 to S640.

[0100] S610. Extract and clean knowledge from multi-source heterogeneous data to obtain knowledge text.

[0101] In this embodiment, knowledge can be extracted from multi-source heterogeneous data to obtain structured data, semi-structured data, and unstructured data. Structured data includes, but is not limited to, device signal definition tables, API interface documents, and database structure information; semi-structured data includes, but is not limited to, historical test cases, fault reports, historical monitoring requirements, and early warning rule configuration records; and unstructured data includes, but is not limited to, expert experience documents and test specification manuals.

[0102] Understandably, the extracted structured, semi-structured, and unstructured data undergo separate cleaning processes. This may include removing redundant whitespace characters, standardizing terminology abbreviations, and filling in missing field type labels. Noise data irrelevant to the stream computing configuration, such as comment lines or version markers, should also be removed. The cleaned data is then converted into knowledge text in a unified format. Each knowledge text entry contains structured fields such as signal name, data type, value range, and operational constraints, and is stored in blocks based on semantic relevance. S620. Based on the knowledge text, divide the knowledge into blocks according to semantic boundaries to obtain multiple knowledge blocks.

[0103] Optionally, to avoid retrieving target knowledge fragments that exceed the context window limit of a large language model, the knowledge text can be segmented into knowledge blocks according to semantic boundaries. Typical strategies include one or more of the following methods: Blocking can be done by data entry, for example, for a device signal definition file, each device signal definition can be treated as an independent knowledge block, containing information such as signal name, communication code, parsing formula, and units. Blocking can also be done by API interface, with each API interface and its parameter description treated as an independent block; for example, the rule creation interface and the signal query interface and their corresponding parameter descriptions can be treated as two different knowledge blocks. Blocking can also be done by paragraph, allowing overlapping windows to maintain contextual continuity. Finally, blocking can be done by test requirement type, such as categorizing test requirements based on vehicle speed threshold adjustment, fuel rail pressure threshold adjustment, battery state of charge monitoring threshold adjustment, and alarm notification object changes to obtain different knowledge blocks.

[0104] S630. Vector transformation is performed on each knowledge block through the embedding model to obtain multiple high-dimensional vectors.

[0105] In the embodiments of this application, vectorized embedding processing can be performed on knowledge blocks by loading a pre-trained embedding model, which can adopt a general semantic embedding model, such as a high-performance text vector model (BAAI GeneralEmbedding, BGE) or a third-generation text embedding model (text-embedding-3).

[0106] In this process, each knowledge block is passed as input to an embedding model. The embedding model uses a deep neural network to map the variable-length text sequence into a fixed-dimensional high-dimensional vector, which captures the semantic features of the knowledge text. By performing this transformation on each knowledge block one by one, multiple high-dimensional vectors are generated, resulting in a high-dimensional vector set. In this high-dimensional vector set, knowledge blocks with similar semantics have smaller distances between their vector representations, while knowledge blocks with different semantics have larger distances.

[0107] S640. Store each high-dimensional vector in a vector database and construct an approximate nearest neighbor index for each high-dimensional vector to obtain the vehicle test knowledge base.

[0108] As an optional implementation, the high-dimensional vectors can be stored in a vector database and an efficient index can be built to obtain a vehicle testing knowledge base, which may include the following: First, select a vector database that supports large-scale vector storage and retrieval, such as Milvus, an open-source vector database designed for developers; Qdrant, an open-source vector database based on Rust; or Elasticsearch, an open-source distributed search and analysis engine. Write each high-dimensional vector representation and its corresponding original text metadata into the database.

[0109] Secondly, construct an approximate nearest neighbor index based on a hierarchical navigable small world on the vector field: first determine the distance metric, such as cosine similarity or inner product; then set the index parameters, including the maximum number of connections per layer and the search range during construction; finally, divide the vector space into a multi-layer graph structure, with sparse nodes in the upper layer for fast navigation and dense nodes in the lower layer for accurate search.

[0110] Finally, after the approximate nearest neighbor index is constructed, it is persistently stored and supports the dynamic addition of new vectors without requiring a full reconstruction. This index structure enables millisecond-level approximate nearest neighbor retrieval even with millions of vectors, providing efficient retrieval capabilities for subsequent knowledge block searches.

[0111] Based on this, by extracting knowledge, segmenting text, embedding vectors, and building indexes, unstructured knowledge is transformed into semantically searchable vector blocks, which effectively improves the relevance and efficiency of knowledge retrieval, supports large-scale real-time retrieval and matching, enhances the accuracy of instructions generated by large language models, and enables efficient reuse and dynamic updating of vehicle testing knowledge.

[0112] As an exemplary implementation of this application, the vehicle testing method provided in this application embodiment will be illustrated using vehicle research and development testing as an example. Figure 7 As shown, vehicle test analysis is achieved through a closed-loop test processing flow that features high availability, high throughput, and low latency.

[0113] The vehicle's telematics box (T-Box), serving as the data acquisition terminal, is deployed within the vehicle's embedded terminal. It is responsible for collecting various controller data (such as engine speed, vehicle speed, throttle opening, braking status, and battery voltage), vehicle positioning information, and various sensor data (such as accelerometer and gyroscope data) from the vehicle's internal CAN bus. The T-Box has a built-in communication module that serializes and compresses the collected raw vehicle data. Through IoT communication protocols such as Message Queuing Telemetry Transport (MQTT) and Hypertext Transfer Protocol Secure (HTTPS), the data packets are transmitted in real-time to the cloud service cluster via the T-Box's own 4G / 5G mobile network. This process ensures the breadth and real-time nature of the data source.

[0114] As the sole entry point for cloud services, the intelligent connected gateway primarily performs security authentication, secure transmission, protocol conversion, and load balancing.

[0115] Among these measures, security authentication verifies the identity of each connected vehicle T-Box device, checking its device ID and certificate to prevent unauthorized access and ensure the trustworthiness of the data source. Secure transmission employs Transport Layer Security (TLS) or Secure Socket Layer (SSL) encrypted tunnels to ensure the confidentiality and integrity of data transmitted over public networks. Protocol conversion and load balancing transform IoT protocols such as MQTT from a massive number of vehicles into more efficient intranet communication protocols for the backend big data platform, and load balances data requests across multiple downstream processing nodes to avoid single-point overload and achieve high system availability.

[0116] Message middleware acts as a data buffer, decoupling the data acquisition and processing ends to handle data surges. For example, a distributed stream processing platform (Apache Kafka) can be used as the message middleware. Data processed by the intelligent connected gateway is published to specific topics in the Kafka message middleware. Kafka's high throughput, low latency, and persistent storage characteristics ensure that the system will not lose data due to insufficient processing capacity when tens of millions of vehicles report data simultaneously. Downstream processing systems pull data from Kafka according to their own consumption capacity, achieving asynchronous decoupling of production and consumption, and peak shaving.

[0117] The stream computing platform is the core of real-time testing. This stream computing platform can be deployed in a cloud-based Flink cluster as a consumer of the message middleware, continuously consuming data streams, executing target test instructions for large language models, and returning test results to the user interface.

[0118] It should be noted that this stream computing platform possesses functions such as real-time consumption, time window aggregation, complex event processing, state storage, and dynamic logic updates. Real-time consumption is based on Flink Jobs subscribing to the Kafka vehicle_data Topic in real time through a SourceConnector, forming an uninterrupted data stream. Time window aggregation utilizes Flink's event time feature to handle out-of-order data, defining rolling or sliding windows for metric calculation. Complex event processing primarily focuses on test analysis of the aforementioned vehicle testing methods. State storage utilizes Flink's state backend to maintain long-term vehicle state information for trend prediction. Dynamic logic updates employ Flink's checkpoint automatic state persistence mechanism, preserving vehicle state and computation progress during stream computing job restarts, thereby achieving secure and controllable updates of test rules and improving the flexibility and maintainability of vehicle testing.

[0119] Understandably, the results processed by the stream computing platform are output in real time. For ordinary test aggregate data, it can be written to a time-series database. For abnormal test events detected in real time, alarms are immediately triggered and pushed to the user interface. The user interface can be a natural language-driven graphical interface. This graphical interface is the human-computer interaction entry point for the intelligent scheduling of the large language model, and also the direct channel for relevant testers to input natural language requirements into the large language model.

[0120] For example, the following complete operation example demonstrates how testers can configure monitoring test requirements using a graphical user interface (GUI). First, testers log in and access the interface via a web browser or app, entering the main interface after authentication. The core area of ​​the GUI is a conversational interactive panel with example input prompts (e.g., "Please change the 0421 (P145) speed alarm to 81 km / h"). Next, the tester inputs the monitoring test requirement in natural language in the bottom dialog input area of ​​the GUI: "Please change the 0421 (P145) speed alarm to 130 km / h." Finally, the test is processed. The GUI sends the requirement information to a large language model, which, after knowledge base retrieval and large language model parsing, generates the target test command and sends it to the stream computing platform for test analysis. If the test analysis is successful, "Operation successful!" is output. This indicates that the monitoring test requirement has been successfully executed, and the cloud monitoring module has also been successfully updated.

[0121] The details of the large language model and vehicle test knowledge base have been described in the above implementation methods and will not be repeated here.

[0122] As an exemplary implementation of this application, the vehicle testing method provided in this application can be used to monitor the health status of vehicle parts. The fuel injector leakage monitoring test is used as an example for specific explanation.

[0123] In vehicle durability testing, the health status of fuel injectors needs to be monitored in real time. The monitoring logic is as follows: when the engine speed drops to 0, the injector rail pressure value is recorded as a baseline after a specified time (e.g., 5 seconds) following engine shutdown. The rail pressure value is then continuously monitored, and a leak risk alarm is triggered when the rail pressure value drops below a threshold (e.g., 2 MPa). In actual monitoring tests, test engineers need to flexibly adjust the monitoring parameters under different operating conditions and software versions. For example, the shutdown waiting time may be changed from 5 seconds to 15 seconds, or the rail pressure drop threshold may be changed from 2 MPa to 1 MPa.

[0124] Specifically, the vehicle testing method using the embodiments of this application may include the following steps: First, the test engineer logs in and enters the user interface. After completing the identity authentication, the test engineer enters the main interface, which is a conversational interactive panel.

[0125] Next, input the monitoring requirements. The test engineer enters the natural language test requirements information in the bottom dialog input area: "Please change the monitoring logic of the fuel injector monitoring model of vehicle 0421(P145) to: record the rail pressure reference value 15 seconds after the engine stops, and trigger an alarm when the rail pressure value drops by more than 1 MPa." Following the monitoring and testing requirements from the test engineer, the following processing flow is executed: First, query vectorization is performed, converting the user's test requirement information into query vectors through an embedded model. Then, the query vectors are used to retrieve target knowledge fragments such as historical configuration records, signal mapping relationships, and API interface specifications of the injector monitoring model for this vehicle (i.e., 0421 / P145) from the vector database. Finally, target test instructions are generated. The large language model automatically generates SQL statements based on the test requirement information and the target knowledge fragments, as follows: "UPDATE guiya_num" SET times= 15, threshold = 1 WHERE vehicle_id = '0421(P145)'".

[0126] Then, the rules are automatically applied and executed, and the generated SQL statement is sent to the stream computing platform. This platform dynamically loads and applies the monitoring rules without manual intervention. The stream computing platform automatically performs the following sequence of operations: calls the data acquisition and monitoring module's interface via a standardized API; verifies the SQL statement and performs canary release verification; automatically executes the SQL statement, updating the configuration parameters in the database; automatically restarts the stream computing job containing the monitoring logic, making the new parameters effective; and outputs a success response in the user interface's dialog history area: "Operation successful! Injector monitoring logic updated."

[0127] Finally, the testing and verification begins. After the monitoring test rules take effect, the test engineer can drive the vehicle to start the monitoring test. When the actual operation meets the new rule conditions (for example, the rail pressure drops by more than 1 MPa after 15 seconds of shutdown), an alarm is automatically triggered and a notification is pushed. The test engineer can be informed of the risk of injector leakage in a timely manner and complete the injector leakage monitoring test.

[0128] The vehicle testing method provided in this application realizes the transformation from professional coding configuration to natural language interaction. Based on test requirement information, it accurately understands the user's intent and converts it into machine-executable target test instructions. At the same time, it utilizes the configuration management capabilities of the stream computing platform to build a fully automated closed-loop process from test requirements to test configuration taking effect, effectively improving the configuration efficiency and iterative testing efficiency of vehicles in the R&D testing process.

[0129] Based on the same technical concept as the above embodiments, the vehicle testing method provided in this application can be executed by a vehicle testing device. This application uses the example of a vehicle testing device executing the vehicle testing method to illustrate the vehicle testing device provided in this application. Figure 8 As shown, the vehicle testing device 800 includes: The knowledge retrieval module 810 is used to retrieve, in response to receiving test requirement information for a vehicle, a vehicle-related vehicle test knowledge base to obtain target knowledge fragments associated with the target test requirement. The test requirement information is information describing the target test requirement based on natural language. The instruction generation module 820 is used to generate target test instructions corresponding to the target test requirements based on the target knowledge fragments and the test requirement information. The test analysis module 830 is used to control the flow computing platform to generate test job specifications according to the target test instructions, so that the flow computing platform can obtain the target test data stream associated with the target test requirements from the vehicle according to the test job specifications, and perform test analysis for the target test requirements based on the target test data stream.

[0130] In some implementations, the instruction generation module 820 is specifically used to generate target test instructions corresponding to the target test requirements based on the target knowledge fragment and test requirement information, including: The target knowledge fragments and test requirement information are structured and assembled to obtain target prompt words. The target prompt words are input into a large language model for semantic information parsing to obtain the semantic parsing results; Based on the semantic parsing results, target test instructions corresponding to the target test requirements are generated.

[0131] In some implementations, the instruction generation module 820 is specifically used to input the target prompt word into a large language model for semantic information parsing, and obtain the semantic parsing result, including: The target prompt words are used to identify the test intent, thereby obtaining the target operation intent of the target test requirement; The target prompt words are used to extract test entities to obtain the target test entities for the target test requirements. Based on the target prompt words, knowledge signals are mapped to the target test entity to obtain the underlying system information; The semantic parsing results include the target operation intent, the target test entity, and the underlying system information.

[0132] In some implementations, before the control flow computing platform generates the test job specifications according to the target test instructions, the vehicle testing device 800 is also specifically used for: The target test command undergoes command verification and canary release verification, and is sent to the stream computing platform based on the verification results, including: Perform syntax and permission checks on the target test commands; If the target test instruction passes the verification, the control flow computing platform generates a grayscale operation process so that the flow computing platform can perform grayscale test analysis on at least one vehicle according to the grayscale operation process. If the grayscale test analysis meets the preset test conditions, the target test command is sent to the stream computing platform.

[0133] In some implementations, the knowledge retrieval module 810 is further specifically configured to, in response to receiving test requirement information for a vehicle, retrieve from a vehicle-related vehicle test knowledge base to obtain target knowledge fragments associated with the target test requirement, including: Based on the test requirements information, the embedded model is invoked to perform vector transformation to obtain the query vector; Using the query vector as input, an approximate nearest neighbor search is performed in the vehicle test knowledge base to obtain at least one target knowledge block that is most similar to the query vector. The target knowledge blocks are sorted and concatenated according to their similarity to obtain target knowledge fragments that are related to the target testing requirements.

[0134] In some embodiments, before retrieving a target knowledge fragment associated with the target test requirement from a vehicle test knowledge base related to the vehicle in response to receiving test requirement information for the vehicle, the vehicle test device 800 is further specifically used for: Based on multi-source heterogeneous data related to vehicle testing, a vehicle testing knowledge base is constructed, including: Knowledge extraction and cleaning are performed on multi-source heterogeneous data to obtain knowledge text; Based on the semantic boundaries of the knowledge text, knowledge is divided into blocks to obtain multiple knowledge blocks; By embedding the model, each knowledge block is transformed into a vector, resulting in multiple high-dimensional vectors; Each high-dimensional vector is stored in a vector database, and an approximate nearest neighbor index is constructed for each high-dimensional vector to obtain the vehicle test knowledge base.

[0135] The vehicle testing apparatus provided in this application embodiment constructs an end-to-end automated closed-loop process for requirements testing. This process effectively shortens the effective cycle of testing strategies, enabling testers to quickly verify assumptions and improve the efficiency of iterative vehicle testing.

[0136] It is understood that the implementation methods of the vehicle testing method in the above method embodiments are also applicable to the device embodiments and can achieve the same technical effect, so they will not be described again here.

[0137] Based on the same technical concept, embodiments of this application also provide an electronic device, such as... Figure 9 As shown, the electronic device 900 may include a processor 910, a communication interface 920, a memory 930, and a communication bus 940, wherein the processor 910, the communication interface 920, and the memory 930 communicate with each other through the communication bus 940. The processor 910 can call logical instructions in the memory 930 to execute the steps of the vehicle testing method as described in the above method embodiment.

[0138] The processor 910 can be a central processing unit (CPU). The processor can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips.

[0139] Furthermore, the logical instructions in the aforementioned memory 930 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or a portion 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 described in the various embodiments of this application. 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.

[0140] The memory 930 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the processor, etc. Furthermore, the memory may include high-speed random access memory and non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory may optionally include memory remotely located relative to the processor, which can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0141] Based on the same concept, embodiments of this application also provide a computer-readable storage medium storing a computer program containing at least one piece of code that can be executed by a master control device to control the master control device to implement the steps of the vehicle testing method as described in the above method embodiments.

[0142] Based on the same technical concept, this application also provides a computer program, which, when executed by a main control device, is used to implement the vehicle testing method described in the above method embodiments. This computer program may be stored wholly or partially on a computer-readable storage medium packaged with a processor, or it may be stored wholly or partially on a memory not packaged with a processor.

[0143] Based on the same technical concept, this application also provides a computer program product, wherein when the instructions in the computer program product are executed by the processor of an electronic device, the electronic device implements the steps of the vehicle testing method in the above method embodiments.

[0144] Based on the same technical concept, embodiments of this application also provide a processor for implementing the steps of the vehicle testing method in the above method embodiments. The processor can be a chip.

[0145] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0146] The functional blocks shown in the structural block diagrams of the above embodiments can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave. Machine-readable media can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

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

[0148] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A vehicle testing method, characterized in that, include: In response to receiving test requirement information for a vehicle, a search is performed in a vehicle test knowledge base related to the vehicle to obtain a target knowledge fragment associated with the target test requirement, wherein the test requirement information is information describing the target test requirement based on natural language. Based on the target knowledge fragment and the test requirement information, generate the target test instruction corresponding to the target test requirement; According to the target test instruction, the control flow computing platform generates a test job specification, so that the flow computing platform can obtain a target test data stream associated with the target test requirement from the vehicle according to the test job specification, and perform test analysis for the target test requirement based on the target test data stream.

2. The vehicle testing method according to claim 1, characterized in that, The step of generating target test instructions corresponding to the target test requirements based on the target knowledge fragment and the test requirement information includes: The target knowledge fragments and the test requirement information are structured and assembled to obtain target prompt words; The target prompt word is input into a large language model for semantic information parsing to obtain the semantic parsing result; Based on the semantic parsing results, the target test instructions corresponding to the target test requirements are generated.

3. The vehicle testing method according to claim 2, characterized in that, The step of inputting the target prompt word into a large language model for semantic information parsing to obtain the semantic parsing result includes: The target prompt words are used to identify the target operational intent of the target test requirement; Test entity extraction is performed on the target prompt words to obtain the target test entities of the target test requirements; Based on the target prompt words, knowledge signal mapping is performed on the target test entity to obtain the underlying system information; The semantic parsing results include the target operation intent, the target test entity, and the underlying system information.

4. The vehicle testing method according to claim 1, characterized in that, Before the control flow computing platform generates the test job specification according to the target test instruction, the process also includes: The target test command is validated and canary release verified, and the target test command is sent to the stream computing platform based on the verification results.

5. The vehicle testing method according to claim 4, characterized in that, The step of performing instruction verification and canary release verification on the target test instruction, and sending the target test instruction to the stream computing platform based on the verification results, includes: Perform syntax and permission checks on the target test instructions; If the target test instruction passes the verification, the stream computing platform is controlled to generate a grayscale operation process, so that the stream computing platform performs grayscale test analysis on at least one of the vehicles according to the grayscale operation process. If the grayscale test analysis meets the preset test conditions, the target test instruction is sent to the stream computing platform.

6. The vehicle testing method according to claim 1, characterized in that, In response to receiving test requirement information for a vehicle, the system retrieves target knowledge fragments associated with the target test requirement from a vehicle test knowledge base related to the vehicle, including: Based on the test requirement information, the embedded model is invoked to perform vector transformation to obtain the query vector; Using the query vector as input, an approximate nearest neighbor search is performed in the vehicle test knowledge base to obtain at least one target knowledge block that is most similar to the query vector; The target knowledge blocks are sorted and concatenated according to their similarity to obtain the target knowledge fragment associated with the target testing requirement.

7. The vehicle testing method according to claim 1, characterized in that, Before responding to receiving test requirement information for a vehicle and retrieving a target knowledge fragment associated with the target test requirement from a vehicle test knowledge base related to the vehicle, the method further includes: The vehicle testing knowledge base is constructed based on multi-source heterogeneous data related to vehicle testing.

8. The vehicle testing method according to claim 7, characterized in that, The construction of the vehicle testing knowledge base based on multi-source heterogeneous data related to vehicle testing includes: Knowledge extraction and cleaning are performed on the multi-source heterogeneous data to obtain knowledge text; Based on the knowledge text, knowledge is divided into blocks according to semantic boundaries to obtain multiple knowledge blocks; By embedding the knowledge blocks into vectors, multiple high-dimensional vectors are obtained. Each of the high-dimensional vectors is stored in a vector database, and an approximate nearest neighbor index of each of the high-dimensional vectors is constructed to obtain the vehicle test knowledge base.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the vehicle testing method as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the vehicle testing method as described in any one of claims 1 to 8.

Images