Internet of vehicles testing system and method

Abstract

The invention relates to the field of testing, and particularly discloses an Internet of Vehicles testing system and method, so as to improve the testing accuracy. The system comprises a sensing layer used for acquiring device state data of a plurality of Internet of Vehicles devices in a current time period; the edge computing layer is used for acquiring test context information corresponding to a current time period through a pre-trained first network model, generating a first test case based on the equipment state data and the test context information, and distributing the first test case to an edge computing module; the platform layer is used for generating a second test case according to the historical test data through a pre-trained second network model, and distributing the second test case to the edge computing module and / or the cloud equipment; the application layer is used for generating and displaying a visual test result according to test data generated by the edge calculation module and / or the cloud equipment for the test case; wherein the model parameters of the network model are dynamically adjusted by adjusting the penalty coefficient.

Description

Technical Field

[0001] The present disclosure relates to the field of testing, and in particular to a vehicle networking testing system and method. Background Art

[0002] The Internet of Vehicles (IoV) system uses an onboard terminal device installed on the vehicle dashboard to collect, store, and transmit all vehicle operating conditions and static and dynamic information. IoV systems typically provide real-time, live-viewing capabilities, leveraging mobile networks to enable human-vehicle interaction.

[0003] Typically, the system consists of three main components: an onboard terminal, a cloud computing processing platform, and a data analysis platform. These platforms are designed to effectively monitor and manage vehicles based on the diverse functional requirements of different industries. Vehicle operation often involves multiple switching values, sensor analog values, CAN signal data, and more. As drivers operate their vehicles, the generated data is continuously sent back to a backend database. The cloud computing platform filters and cleans the data, and the data analysis platform generates reports for management personnel to review. However, this approach does not allow for quick and efficient testing of connected vehicle devices. Summary of the Invention

[0004] To this end, the present disclosure provides a vehicle networking testing system and method to quickly and efficiently perform testing on vehicle networking devices.

[0005] In order to achieve the above-mentioned object, the first aspect of the present disclosure provides a vehicle network testing system, the system comprising: a perception layer, an edge computing layer, a platform layer and an application layer; wherein,

[0006] The perception layer is used to obtain device status data of multiple Internet of Vehicles devices in a current period;

[0007] The edge computing layer is configured to obtain test context information corresponding to the current time period through a pre-trained first network model, generate a first test case based on the device status data and the test context information, and assign the first test case to an edge computing module;

[0008] The platform layer is configured to generate a second test case based on historical test data using a pre-trained second network model, and distribute the second test case to the edge computing module and / or cloud device;

[0009] The application layer is used to generate and display visual test results based on the test data generated by the edge computing module and / or cloud device for the test case;

[0010] The parameter magnitude of the first network model is smaller than the parameter magnitude of the second network model; and the first network model and / or the second network model are trained in the following manner: by calculating the difference between the candidate test case and the historical case, adjusting the penalty coefficient, so as to dynamically adjust the model parameters of the network model by the penalty coefficient.

[0011] A second aspect of the present disclosure provides a testing method based on the above-mentioned Internet of Vehicles testing system, the method comprising:

[0012] Obtain device status data of multiple Internet of Vehicles devices within the current period through the perception layer;

[0013] Calling, through the edge computing layer, a pre-trained first network model, obtaining test context information corresponding to the current time period, generating a first test case based on the device status data and the test context information, and assigning the first test case to an edge computing module;

[0014] Through the platform layer, calling a pre-trained second network model, generating a second test case based on historical test data, and distributing the second test case to the edge computing module and / or cloud device;

[0015] Through the application layer, visual test results are generated and displayed based on the test data generated by the edge computing module and / or cloud device for the test case.

[0016] The present disclosure has the following advantages:

[0017] In the Internet of Vehicles test system provided by the embodiment of the present disclosure, efficient test processing of the Internet of Vehicles system can be achieved through the mutual cooperation between the perception layer, the edge computing layer, the platform layer and the application layer. Among them, through the edge computing layer, it is possible to generate a first test case with higher real-time performance in combination with the test context information; through the platform layer, it is possible to generate a second test case with lower real-time performance based on historical test data, and through the application layer, it is possible to achieve visual presentation of the test results. Among them, since the parameter magnitude of the first network model is smaller than the parameter magnitude of the second network model, the edge computing layer can quickly generate the first test case to meet the real-time requirements. Moreover, since the model parameters of the network model can be dynamically adjusted according to the difference between the candidate test case and the historical case, the accuracy of the test case can be ensured. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings are used to provide further understanding of the present disclosure and constitute a part of the specification. Together with the following detailed description, they are used to explain the present disclosure, but do not constitute a limitation of the present disclosure.

[0019] Figure 1 A framework diagram of a vehicle networking test system provided in an embodiment of the present disclosure;

[0020] Figure 2 A flow chart of a vehicle networking testing method provided by an embodiment of the present disclosure is shown;

[0021] Figure 3 The following is an architecture diagram of the Internet of Vehicles test platform system in this example;

[0022] Figure 4 shows a schematic diagram of the structure of the perception layer;

[0023] Figure 5 The figure shows the process flow of the AI ​​engine module processing abnormal data;

[0024] Figure 6 The working flow diagram of the semantic intelligent gateway module is shown;

[0025] Figure 7 A flowchart of a dynamic penalty mechanism driven by multi-dimensional differences is shown;

[0026] Figure 8 A schematic diagram of the system architecture of the bypass platform layer is shown. DETAILED DESCRIPTION

[0027] The following describes the specific embodiments of the present disclosure in detail with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only used to illustrate and explain the present disclosure and are not intended to limit the present disclosure.

[0028] As used in this disclosure, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0029] The terms used in the present disclosure are only used to describe specific embodiments and are not intended to limit the present disclosure.As used in the present disclosure, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0030] When the terms “comprising” and / or “made of…” are used in the present disclosure, it specifies the existence of the stated features, integers, steps, operations, elements and / or components, but does not preclude the existence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof.

[0031] The embodiments of the present disclosure may be described with reference to plan views and / or cross-sectional views by way of ideal schematic views of the present disclosure. Therefore, the exemplary illustrations may be modified according to manufacturing techniques and / or tolerances.

[0032] Unless otherwise defined, all terms (including technical and scientific terms) used in this disclosure have the same meanings as those commonly understood by those skilled in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning unless expressly defined in this disclosure.

[0033] In a first aspect, an embodiment of the present disclosure provides a vehicle networking testing system. Figure 1 This is a framework diagram of a vehicle networking test system provided by an embodiment of the present disclosure, referring to Figure 1 The Internet of Vehicles testing system includes: a perception layer 11, an edge computing layer 12, a platform layer 13 and an application layer 14; wherein the perception layer 11 is used to obtain device status data of multiple Internet of Vehicles devices in a current time period; the edge computing layer 12 is used to obtain test context information corresponding to the current time period through a pre-trained first network model, generate a first test case based on the device status data and the test context information, and assign the first test case to the edge computing module; the platform layer 13 is used to generate a second test case based on historical test data through a pre-trained second network model, and assign the second test case to the edge computing module and / or cloud device; the application layer 14 is used to generate and display visual test results based on the test data generated by the edge computing module and / or cloud device for the test case; wherein the parameter magnitude of the first network model is smaller than the parameter magnitude of the second network model; and the first network model and / or the second network model are trained in the following manner: by calculating the difference between the candidate test case and the historical case, adjusting the penalty coefficient, so as to dynamically adjust the model parameters of the network model through the penalty coefficient.

[0034] This embodiment utilizes the perception layer to collect multi-source device status data in real time, and dynamically generates first test cases using a lightweight AI model (first network model) at the edge computing layer, achieving low-latency response and adaptive testing capabilities for the connected vehicle testing system. This system integrates multimodal data from onboard sensors, communication protocols, and environmental perception, and generates context-aware test cases based on pre-trained models. Device status data can be a set of dynamic parameters generated by connected vehicle devices during operation, including: onboard terminal data such as engine speed, battery SOC, and fault codes (DTCs); communication status data such as V2X signal strength and network latency; and environmental perception data such as millimeter-wave radar point clouds and camera frame data. Test context information can include various test-related information, such as real-time test phase markers (e.g., "emergency brake verification"), current resource load status (CPU / GPU utilization), historical test coverage gap data, and update frequency.

[0035] In addition, the intelligent generation of complex test scenarios is achieved through the full-parameter large model of the platform layer (i.e., the second network model), and combined with the multi-dimensional visualization of the application layer, a closed-loop optimization system for vehicle network testing is constructed. Among them, a high-coverage test case set can be generated based on historical data mining, and the edge or cloud execution can be dynamically selected according to the complexity of the test. Moreover, multi-dimensional displays such as test progress, coverage, and abnormal alarms can also be provided. Among them, historical test data can include various types, such as original test logs (including timestamps, device IDs, and test results), protocol compatibility reports (such as DSRC and LTE-V2X interoperability records), three-dimensional scene parameters (weather, road conditions, and traffic flow simulation data), etc.

[0036] It can be seen that in the present disclosure, efficient test processing of the Internet of Vehicles system can be achieved through the mutual cooperation between the perception layer, the edge computing layer, the platform layer and the application layer. Among them, through the edge computing layer, it is possible to generate a first test case with higher real-time performance in combination with the test context information; through the platform layer, it is possible to generate a second test case with lower real-time performance based on historical test data, and through the application layer, it is possible to achieve visual presentation of the test results. Among them, since the parameter magnitude of the first network model is smaller than the parameter magnitude of the second network model, the edge computing layer can quickly generate the first test case to meet the real-time requirements. Moreover, since the model parameters of the network model can be dynamically adjusted according to the difference between the candidate test case and the historical test case, the accuracy of the test case can be ensured.

[0037] In addition, in order to achieve better technical effects, those skilled in the art may also make various changes and modifications to the above embodiments:

[0038] In an optional implementation, the platform layer is also used to obtain and store test data generated by the edge computing module in the edge computing layer; and the system also includes: a bypass control module, wherein, when the bypass control module is in a first working mode, the application layer is connected to the platform layer, and the application layer is used to obtain test data generated by the edge computing module and / or cloud device for the test case from the platform layer; when the bypass control module is in a second working mode, the application layer is connected to the edge computing layer, and the application layer is used to obtain test data generated by the edge computing module for the test case from the edge computing layer.

[0039] The above approach resolves the conflict between real-time performance requirements and data analysis depth in connected vehicle testing systems by introducing platform-layer data persistence and an intelligent bypass control mechanism. The platform layer centrally stores test data from edge computing modules and intelligently selects data flow paths based on system status to achieve load balancing between real-time testing and analysis processing. In traditional testing architectures, all test data must be processed at the platform layer before being forwarded to the application layer. This results in high latency in displaying critical real-time test results (such as collision warnings), failing to meet the real-time response requirements of connected vehicle scenarios. The bypass control module is an intelligent routing component that dynamically manages the flow of test data. In the first operating mode (platform path mode), data is processed at the platform layer before being forwarded to the application layer. In the second operating mode (direct-to-edge mode), data is transmitted directly from the edge computing layer to the application layer. For example, the first operating mode is suitable for scenarios such as non-real-time test data analysis and long-term trend statistics; the second operating mode is suitable for scenarios with high real-time requirements, such as emergency braking testing and collision warnings.

[0040] In an optional implementation, the perception layer includes: multiple sensor modules for collecting device status information of multiple Internet devices; wherein the device status information of multiple Internet devices corresponds to multiple different network protocols; an artificial intelligence engine module for performing data cleaning and anomaly detection on the collected device status information; and a semantic gateway module for performing protocol conversion processing on the device status information detected by the artificial intelligence engine module, so that the device status data after protocol conversion processing is transmitted to the edge computing layer.

[0041] The above-mentioned approach builds a data collection and preprocessing system for heterogeneous Internet of Vehicles devices through the collaborative work of multiple modules in the perception layer. It mainly has the following functions: (1) Multi-protocol compatible collection: supports simultaneous collection of multiple vehicle bus protocols such as CAN, LIN, and FlexRay; (2) Intelligent data governance: achieves real-time data quality control through the AI ​​engine; (3) Seamless protocol conversion: uniformly converts heterogeneous protocols into a standardized format that can be processed by the edge computing layer.

[0042] Among them, in traditional Internet of Vehicles systems, devices from different manufacturers use private protocols to communicate, which requires the test system to develop independent acquisition modules for each protocol, making the system complexity increase exponentially (N types of devices require N development modules). 2 The aforementioned approach, using a semantic gateway module, effectively addresses these issues. The core algorithm of the AI ​​engine module uses a lightweight LSTM network to detect time series anomalies. The semantic gateway module enables lossless protocol conversion based on semantic mapping.

[0043] In an optional implementation, the first test case corresponds to a first type of test task, the second test case corresponds to a second type of test task, and the real-time requirement of the first type of test task is higher than the real-time requirement of the second type of test task; and the second test case includes: functional test cases, protocol test cases and exception test cases; the platform layer is specifically used to: generate functional test cases based on the acquired functional description information; generate protocol test cases based on the acquired protocol state machine data; and generate exception test cases based on the exception data in the acquired historical data.

[0044] By defining test task types in a hierarchical manner and establishing a targeted test case generation mechanism, this approach ensures precise coverage of diverse testing requirements within the connected vehicle (IoV) testing system. This approach specifically addresses issues such as test task clutter. In traditional testing systems, test tasks with varying real-time requirements share the same generation pipeline, resulting in high-real-time tasks often being blocked by lower-priority tasks and failing to meet the timeliness requirements of testing critical IoV functions. Furthermore, single-dimensional test case generation methods only cover a limited number of test scenarios, particularly protocol compatibility and exception scenarios, posing significant safety risks. This approach effectively addresses these issues. The first type of test tasks can be used to verify safety-critical functions such as emergency braking response and obstacle avoidance, typically executed by edge computing modules. The second type of test tasks can include functional tests verifying the functionality specified in device specifications, protocol test cases verifying the compatibility and robustness of communication protocols, and exception test cases simulating system behavior under abnormal scenarios.

[0045] In an optional implementation, the first network model is trained specifically by: generating candidate test cases; calculating a first degree of difference between the candidate test cases and historical cases corresponding to a semantic level; calculating a second degree of difference between the candidate test cases and historical cases corresponding to a text level; adjusting a penalty coefficient based on the first degree of difference and the second degree of difference, and dynamically adjusting the model parameters of the network model through the penalty coefficient.

[0046] The above method achieves precise optimization of the test case generation model by establishing a multi-dimensional difference evaluation system and a dynamic penalty mechanism. Specifically, it can simultaneously evaluate differences at the semantic and textual levels, and adaptively modify the model based on the difference analysis results to effectively suppress the generation of repetitive test cases. Traditional single text similarity evaluation methods are unable to identify logically equivalent test cases with different expressions, resulting in serious functional redundancy in the generated test case set. The above method can effectively solve the above problems. Specifically, the first difference (semantic level) can be achieved by generating semantic embedding vectors based on pre-trained models such as BERT and calculating cosine similarity, which is used to evaluate the equivalence of test logic and the consistency of parameter constraints. The second difference (textual level) can be determined based on the Jaccard similarity algorithm of n-gram overlap rate to evaluate the degree of repetition of surface text. The basis for dynamic adjustment of the penalty coefficient may include: the current training round, the historical difference mean, the coverage gap, etc.

[0047] In an optional implementation, the second network model is trained specifically in the following manner: candidate test cases are generated based on model prompt information, the candidate test cases including boundary conditions and / or abnormal scenarios; the test cases are executed, and based on the test case execution results and scenario coverage, whether the test cases meet the preset conditions is determined; if not, the second network model is iteratively adjusted until the candidate test cases generated by the adjusted second network model meet the preset conditions. The above method realizes the intelligent generation and optimization of complex test scenarios through a closed-loop feedback training mechanism. Boundary conditions and abnormal scenario use cases can be generated simultaneously, and the model can be dynamically corrected based on actual test results. The model prompt information includes various contents such as functional requirements summary, protocol specification highlights, historical defect patterns, etc. Boundary condition test cases can cover the minimum / maximum critical values ​​of input parameters. The quantitative standards of the preset conditions can be characterized by coverage indicators, defect detection rate indicators, execution pass rate indicators, etc.

[0048] In an optional implementation, the application layer includes: a test console module, which is used to display the device communication status in the test results through a three-dimensional topology map; a test pipeline module, which is used to trigger multi-protocol compatibility testing; a risk warning module, which is used to push the health score of the IoT device in real time based on the classifier; and a visual interface management module, which is used to display the visual test report in the test results.

[0049] The above approach builds a comprehensive visual monitoring system for Internet of Vehicles testing through the collaboration of multiple modules at the application layer, which can achieve the following functions: (1) Three-dimensional status display: 3D topology presents the communication relationship between devices; (2) Automated test scheduling: One-click triggering of multi-protocol collaborative verification; (3) Intelligent risk assessment: Real-time quantification of device health status; (4) Structured report generation: Multi-dimensional visual analysis of test results. Among them, the display dimensions of the 3D topology map can include spatial coordinates, signal strength heat map, protocol type labeling, etc. The test scope of multi-protocol compatibility testing can cover at least 3 communication protocols (such as CAN, LIN, FlexRay) at the same time, and can be started with one click through API or graphical button, and supports sequential execution and parallel testing.

[0050] In an optional implementation, the test context information includes: multimodal test context information; and the multimodal test context information includes at least two of the following: requirement document data, historical test cases, runtime coverage data, and code data.

[0051] In a second aspect, an embodiment of the present disclosure provides a vehicle networking testing method. Figure 2 A flow chart of a vehicle networking testing method provided by an embodiment of the present disclosure is shown. Figure 2 , the method comprising:

[0052] Step S210: obtaining device status data of multiple Internet of Vehicles devices in the current time period through the perception layer;

[0053] Step S220: Calling the pre-trained first network model through the edge computing layer, obtaining test context information corresponding to the current time period, generating a first test case based on the device status data and the test context information, and assigning the first test case to the edge computing module;

[0054] Step S230: calling the pre-trained second network model through the platform layer, generating a second test case based on the historical test data, and distributing the second test case to the edge computing module and / or cloud device;

[0055] Step S240: Generate and display visual test results through the application layer based on the test data generated by the edge computing module and / or cloud device for the test case.

[0056] In an optional implementation, when the system also includes a bypass control module, the method also includes: when it is detected that a preset switching condition is met, controlling the bypass control module to switch from the first working mode to the second working mode; wherein, in the first working mode, the application layer is connected to the platform layer; in the second working mode, the application layer is connected to the edge computing layer across the platform layer.

[0057] Among them, the dynamic optimization configuration of the test data path is realized through the intelligent bypass control mechanism. Among them, the preset switching condition can be a real-time condition, which is used to verify the delay requirements of the test task. The preset switching condition can also be a data sensitivity condition, such as switching in cases involving personal privacy or security-critical data. The preset switching condition can also be a resource load condition, such as switching when the platform layer CPU utilization continues to be ≥90% for 30 seconds. Among them, the data flow direction of the first working mode (platform path) is: edge computing layer → platform layer → application layer, and typical uses include: non-real-time test data analysis, long-term trend statistics, etc. The data flow direction of the second working mode (direct connection to the edge) is: edge computing layer → application layer, and typical uses include: real-time scenarios such as emergency braking testing and collision warning.

[0058] For ease of understanding, the following describes the test method in this application in detail using a specific example. This example belongs to the field of vehicle networking testing technology and involves an intelligent vehicle networking testing platform system that integrates a large language model (LLM), edge computing, and cloud collaborative architecture. Specifically, it includes multi-protocol compatibility testing, dynamic test case generation, intelligent analysis of test results, and visualization. With the rapid development of vehicle networking technology, various types of vehicle networking devices have sprung up and are widely used in industrial manufacturing, smart homes, smart transportation, medical health, and other fields. However, before these devices are put into use on a large scale, comprehensive and accurate testing is the key prerequisite to ensure their stable performance, reliable operation, and good compatibility. In contrast, traditional vehicle networking testing methods have many drawbacks that need to be addressed, and the existing technology has the following defects: (1) Insufficient test coverage: Traditional testing methods rely on manual writing of test cases, which makes it difficult to cover complex scenarios. (2) Poor protocol compatibility: Existing platforms require manual configuration for multi-protocol adaptation such as MQTT / CoAP / Zigbee and lack adaptive capabilities. (3) Low level of intelligence: 95% of vehicle networking tests still rely on manual labor, and AI is only used for local optimization. (4) Insufficient dynamic load handling: Resource allocation is rigid during high-concurrency testing, resulting in decreased testing efficiency.

[0059] To address these issues, this example provides an intelligent, automated, and efficient IoV test platform system. The core purpose of this example is to provide an innovative IoV test platform system. By introducing large models, it aims to thoroughly address prominent issues inherent in traditional testing methods, such as insufficient test coverage, poor protocol compatibility, unbalanced dynamic loads, low efficiency, and low intelligence. This provides strong support for high-quality testing of IoV devices.

[0060] Figure 3 The architecture diagram of the Internet of Vehicles test platform system in this example is shown in FIG. Figure 3As shown in Figure 1, the architecture of the IoV test platform system is divided into four layers: the perception layer, edge computing layer, platform layer, and application layer. These layers work together to comprehensively test, monitor, and evaluate the performance of IoV devices. The perception layer is primarily responsible for multimodal data acquisition and protocol adaptation, providing raw data for subsequent testing. It primarily includes sensor modules, an AI engine module, a device management module, and a semantic intelligent gateway module. The edge computing layer deploys lightweight, large-model inference nodes. Their primary task is to process data from the perception layer in real time, distribute test instructions, and achieve load balancing between edge nodes based on the current load conditions, ensuring efficient and real-time testing. It primarily includes a dynamic load scheduler module, a lightweight large-model module, a protocol data conversion module, and an edge computing module. The platform layer is the core of the system, providing a test case generation engine, a protocol adaptation engine, and data storage, processing, and management capabilities. This ensures the automatic generation of comprehensive and targeted test case sets and adaptability to multiple protocols, ensuring that the test system can effectively communicate and test connected vehicle devices using different protocols. It primarily includes a large-model test engine module, a protocol adaptation module, a storage module, a resource management module, a device management module, and an intelligent analysis module. The application layer is the interface between the system and the user, primarily responsible for presenting test results to the user in a visual manner and providing feedback on optimization recommendations based on the test analysis results. Through intuitive visual reports, users can easily understand the test status and make appropriate decisions. It primarily includes an intelligent test console module, an automated test pipeline module, a risk warning module, and a visual interface management module.

[0061] The main working principles of each layer are introduced below:

[0062] 1. Perception Layer

[0063] The perception layer is mainly responsible for multimodal data acquisition and protocol adaptation. It integrates a variety of sensors, such as vibration, temperature, and gas sensors. These sensors can access the network through different communication protocols such as Zigbee and LoRa to provide raw data for subsequent tests. Figure 4 The schematic diagram of the perception layer is shown in FIG. Figure 4 As shown in the figure, the perception layer mainly includes the following functional modules:

[0064] (1) Sensor module: Its components are multimodal sensor arrays that integrate temperature, vibration, gas, image, audio, video and other sensors to collect multimodal data.

[0065] (2) AI engine module (i.e. Figure 4 AI engine model in ): Deploy lightweight AI models to perform preliminary data cleaning and anomaly detection.

[0066] (3) Equipment management module: responsible for the status monitoring and coordination of multimodal sensor equipment, such as abnormal equipment status alarm information, etc.

[0067] (4) Semantic intelligent gateway module: Based on the semantic parsing of large models, it automatically matches the device protocol to achieve protocol conversion (such as CoAP to HTTP), data compression and encryption.

[0068] Figure 4 The data flow between modules is also shown. The sensor module collects multimodal data and sends it to the AI ​​engine module and intelligent gateway module. The AI ​​engine module deploys AI models to cleanse data and detect anomalies. The semantic intelligent gateway module automatically matches device protocols based on a historical knowledge base and large-scale semantic parsing to implement protocol conversion, as well as perform data compression and encryption. The device management module monitors and queries the status of each sensor in real time, issuing alarms if anomalies are detected, ensuring the proper operation of sensor devices.

[0069] Among them, the AI ​​engine module locally deploys a lightweight AI model to perform preliminary data cleaning and anomaly detection, providing effective and compliant test data for testing. Figure 5 The figure shows the flow chart of AI engine module processing abnormal data. Figure 5 As shown in the figure, the AI ​​engine module processes abnormal data in the following stages:

[0070] (1) Cleaning and standardizing the collected multimodal data:

[0071] The collected multimodal data is cleaned to remove invalid data, such as missing values ​​or noise, to ensure data integrity and accuracy. The data is then normalized, mapping data collected by different sensors to the same scale to make them comparable and lay the foundation for subsequent model processing.

[0072] (2) Feature extraction:

[0073] According to the specific application scenarios and data characteristics, feature extraction and selection are performed on the data to extract features related to anomaly detection, such as time series features, frequency domain features, etc., to reduce data dimensions, reduce noise and redundant information, and improve the performance and generalization ability of the model.

[0074] (3) AI model reasoning:

[0075] If abnormal data is found, an early warning message will be generated. Regarding the selection of models, the appropriate AI model can be selected based on the data characteristics and task requirements.

[0076] During the model training process, historical data can be used to train the selected model, allowing the model to learn the patterns and characteristics of normal data and the manifestations of abnormal data. During the training process, the model parameters are continuously adjusted to optimize the model's performance so that it can accurately identify abnormal data.

[0077] During the model inference stage, multimodal data can be inferred based on the trained AI model to identify abnormal data.

[0078] (4) Anomaly detection and early warning:

[0079] Anomaly detection: The real-time processed data is input into the trained AI model. The model analyzes and judges the data based on the learned normal patterns. Once abnormal behavior that deviates significantly from the normal pattern is detected in the data, it is identified as abnormal data.

[0080] Early warning and response: When abnormal data is detected, the system will promptly issue an early warning and notify relevant personnel via email, SMS, and alert boxes. At the same time, appropriate response measures will be initiated, such as automatically recording abnormal data and notifying business departments, to quickly respond to and handle abnormal situations and minimize the impact on the system and business.

[0081] The semantic intelligent gateway module has a built-in lightweight large model, which contains a historical matching knowledge base. In addition, it can be combined with the powerful semantic analysis of the large model to achieve automatic matching, thereby achieving fast and efficient protocol conversion and improving the efficiency and accuracy of conversion. Figure 6 The workflow diagram of the semantic intelligent gateway module is shown in Figure 6 As shown in the figure, the large model parses the source protocol semantic input and searches through the knowledge base. It then determines whether there is a match based on the search results. If there is a match, the output is based on the target protocol. Otherwise, knowledge fusion and large model generation process are carried out.

[0082] The contents of the knowledge base include: (1) parameters of the source protocol: data format, message structure, key fields, header information, methods, body content, etc.; (2) parameters of the target protocol: data format, message structure, header information, methods, body content, etc. In order to improve the performance and accuracy of the large model, the large model can also be trained and fine-tuned. Based on data and feedback from actual applications, the knowledge base and large model parameters can be updated in real time.

[0083] 2. Edge Computing Layer

[0084] The edge computing layer deploys lightweight large-model inference nodes, which are mainly responsible for real-time processing of data from the perception layer, distributing test instructions, and achieving load balancing between edge nodes based on the current load situation to ensure the efficiency and real-time performance of the test process. It mainly includes the following functional modules:

[0085] (1) Dynamic load scheduler: Real-time comprehensive analysis makes quick decisions and pushes them to the cloud or edge computing module to run test tasks.

[0086] (2) Lightweight large model module (i.e., the first network model): For real-time test scenarios, corresponding test cases are generated based on test data and test requirements.

[0087] (3) Protocol data conversion module: responsible for converting different protocol data formats into the data format required for testing.

[0088] (4) Edge computing module: The real-time test execution engine handles high-efficiency test tasks.

[0089] The interaction process between the modules in the edge computing layer is as follows:

[0090] First, the test data collected by the perception layer is transmitted to the protocol data conversion module in the edge computing layer. The protocol data conversion module is responsible for converting different protocol data formats into the data format required for the test.

[0091] Then, the protocol data conversion module sends the test data to the local large model inference module, and the lightweight large model module generates corresponding test cases based on the test data and test requirements.

[0092] Next, the dynamic load scheduler module makes quick decisions based on the current load situation and pushes the test cases to the cloud or edge computing module.

[0093] Finally, the edge computing module executes high-timeliness test tasks based on the test cases pushed by the dynamic load scheduler module.

[0094] The lightweight large model module generates test cases based on multimodal test data and test requirements in real-time test scenarios. A dynamic, context-aware generation strategy is introduced to the lightweight large model module to ensure that test case coverage is expanded to cover boundaries and exceptions, and to address the convergence problem that exists when generating test cases. The dynamic, context-aware generation strategy includes the following two aspects:

[0095] (1) Multimodal Input Fusion

[0096] The model's input includes not only the code under test but also integrates fragments of requirement documents, such as Text-to-Test, historical test cases, and runtime coverage data, to form multimodal prompts. For example, when coverage is insufficient, the model prioritizes generating test cases for uncovered paths.

[0097] (2) Dynamic penalty mechanism driven by multi-dimensional differences

[0098] To address the convergence problem of traditional LLM when generating test cases (i.e., high repetition rate and lack of diversity in generated results), a dynamic penalty mechanism driven by multi-dimensional difference is proposed. By combining n-gram surface repetition detection with deep similarity analysis of semantic embedding, a difference quantification indicator is constructed, and the generation weights are dynamically adjusted to force the model to explore low-frequency paths.

[0099] Figure 7 The flowchart of the dynamic penalty mechanism driven by multi-dimensional difference is shown. Figure 7 As shown, it mainly includes the following processes:

[0100] First, generate candidate use cases: Lightweight LLM generates a set of candidate use cases based on multimodal input (code, requirement documents, coverage data).

[0101] Then, the difference calculation is performed: on the one hand, the n-gram set of the candidate use case is extracted, matched with the historical use case library, and the number of repetitions (corresponding to Figure 7 On the other hand, the cosine similarity between the candidate use case and the historical set is calculated by the semantic encoding model (corresponding to Figure 7 "Semantic Embedding Similarity Computation" in .

[0102] Next, penalty fusion is performed: it is specifically divided into two parts: surface repetition penalty and semantic repetition penalty.

[0103] Dynamically adjust λ1 and λ2 according to the current exploration stage (early / late):

[0104]

[0105] Initially, semantic diversity is emphasized (high λ2), while later local optimization (high λ1) is emphasized. λ1 is the N-gram penalty weight coefficient, which controls the suppression of surface text repetition and can be linearly increased with training progress. λ2 is the semantic penalty weight coefficient, which constrains the generation of logically equivalent use cases and can be linearly decreased with training progress. Current epoch / total epochs represents a training progress factor, for example, a normalized training stage indicator in the range [0, 1].

[0106] Finally, perform probability correction: impose a penalty on the logits of the candidate use case and adjust the formula to:

[0107] logits new =logits original -∑(NgramPenalty+SemanticPenalty)

[0108] NgramPenalty represents the text-level penalty. The n-gram duplication penalty based on Jaccard similarity is calculated as: λ1 × (number of repeated n-grams / total number of n-grams). SemanticPenalty represents the semantic-level penalty. The semantic duplication penalty based on cosine similarity is calculated as: λ2 × max (cosine similarity of historical use cases).

[0109] The final output is filtered through Top-k or Nucleus sampling. Top-k sampling retains only the k candidate tokens with the highest probability and is suitable for scenarios with high determinism requirements (such as safety-critical testing). Nucleus sampling dynamically selects the minimum set of tokens whose cumulative probability exceeds a threshold p and is suitable for scenarios with high creativity requirements (such as exploring unusual paths).

[0110] By integrating n-gram statistical penalty and semantic embedding difference calculation, we can suppress generation convergence at multiple granularities and force the model to explore uncovered code paths and abnormal scenarios.

[0111] In addition, in order to improve timeliness, Figure 3 The system can also be designed as a bypassable architecture. For example, for real-time test cases, a bypassable platform layer design can speed up testing and ensure test efficiency. In the bypass mode, the application layer module directly calls the test output results of the edge computing module in the edge computing layer through an interface to perform operations such as real-time test result visualization. The interface includes information such as the data structure {test name, test ID, test status, test progress, test results, timestamp}.

[0112] Figure 8 Figure 2 shows a schematic diagram of the system architecture of the bypass platform layer. Figure 8 As shown, Figure 3 The difference between the two systems is that the application layer has added an API interface management module for direct communication with the edge computing layer. In the edge computing layer, the lightweight large model module is further split into two modules: the local large model inference module and the real-time analysis module to meet real-time processing requirements.

[0113] 3. Platform Layer

[0114] This layer is the core of the test platform system, providing the test case generation engine, data storage, processing, and management capabilities for non-real-time test scenarios. This ensures the automatic generation of comprehensive and targeted test case sets and adaptability to multiple protocols, ensuring that the test system can effectively communicate and test connected vehicle devices using different protocols. It mainly includes the following functional modules:

[0115] (1) Large model test engine module: Utilizing its powerful language understanding and generation capabilities, it automatically generates a comprehensive and targeted test case set based on the input device function description, protocol specifications, and historical data, targeting scenarios with low real-time requirements.

[0116] (2) Storage module: stores original test data and annotated data sets, and provides data support for the artificial intelligence image platform and 3D reconstruction platform.

[0117] (3) Resource management module: responsible for managing various resources at the platform layer, such as AI large model resources, storage resources, computing resources, etc.

[0118] (4) Device management module: responsible for coordinating device access and life cycle management.

[0119] (5) Intelligent analysis module: Use AI and big data analysis to mine data correlations and ensure the completeness and consistency of test data.

[0120] The interaction between the large model test engine module and other modules is as follows: The large model test engine module needs to obtain unified test format data from the storage module. The intelligent analysis module obtains the test format data from the storage module and obtains information such as the completeness and consistency of the test data to ensure the completeness and accuracy of the generated test cases. Furthermore, the generation of test cases requires integrating content such as device manuals, protocol state machine diagrams, and historical data generation test scripts to analyze and determine data correlation results. In response, the intelligent analysis module sends the data correlation results to the large model test engine module.

[0121] The detailed process of generating test cases by the large model test engine module is as follows:

[0122] During the data preparation phase, first, data is collected: various manuals for the equipment, including user manuals, technical manuals, and operating manuals, are organized to extract key information, such as the equipment's functional description, interface parameters, operating procedures, and error handling mechanisms. Next, structured processing is performed: the extracted information is structured, and the interface parameters are organized into a table format to facilitate the understanding and use of subsequent large models. For protocol state machine information, it is necessary to compile information such as the state machine's status, state transition conditions, and events. In the text description, key information, important state transitions, and exception handling status are marked. Next, data cleaning is performed: historical test data and operation logs related to the equipment are collected, and the historical data is cleaned to remove noise and invalid data.

[0123] In addition, regarding the selection of large models, you can choose a suitable large model based on the complexity and requirements of the task. The large model has strong language understanding and generation capabilities and can handle complex text tasks.

[0124] Next, in the test case generation phase, the following three types of test cases can be generated:

[0125] Functional test cases: Functional descriptions extracted from the device manual are fed into the macromodel, which is then asked to generate corresponding functional test cases based on the functional descriptions. The test cases generated by the model may be broad and require further refinement to clarify the test steps, expected results, and input data. For example, if a device has a data upload function, the test cases might include uploading data of varying sizes and formats and checking whether the upload was successful.

[0126] Protocol test cases: Input the text description of the protocol state machine diagram into the model, and let the model generate protocol test cases based on the state transition conditions. Focus on the boundary conditions of state transitions, such as the critical value of state transitions and the handling of abnormal events.

[0127] Abnormal test cases: Based on the common error types and abnormal conditions analyzed in historical data, relevant information is input into the model to allow the model to generate abnormal test cases. The test cases should include simulations of various abnormal scenarios, such as network outages, power failures, data errors, etc., to check the device's recovery capabilities and error handling mechanisms under abnormal conditions.

[0128] Finally, when generating test scripts, first, choose a scripting language: Based on the characteristics of the test environment and equipment, choose an appropriate scripting language, such as Python, Java, or C#. Then, convert the test cases into scripts. Furthermore, regarding integrated testing frameworks, the generated test scripts can be integrated into testing frameworks such as pytest and JUnit. The testing framework can provide test case management, execution, and result reporting.

[0129] Furthermore, to address common issues with semantic understanding bias and lack of contextual awareness in test cases generated by large-scale test engine modules, a unique dynamic optimization solution can be introduced to ensure semantic correctness and, therefore, the accuracy of generated test cases. This dynamic optimization solution primarily includes a code preprocessing mechanism to enhance contextual awareness and a dynamic feedback iterative generation mechanism, both of which work together to ensure semantic correctness.

[0130] First, let's introduce the code preprocessing enhancement context awareness mechanism:

[0131] Code preprocessing involves cleaning, compressing, and extracting information from the original code through a series of operations. This reduces noise, highlights the core code logic, and helps the large model better understand the code semantics, ensuring the semantic correctness of the generated test cases. Specifically, a series of operations, including code cleaning, context compression, and semantic information extraction, are performed on the original code to produce the processed code.

[0132] Code cleanup (removing comments and blank lines): Comments and blank lines are intended to improve code readability, but they don't help large models understand code logic and may even introduce noise. Removing these allows large models to focus on the core code, avoiding irrelevant information and allowing them to more accurately grasp the code's semantics.

[0133] Context compression (retaining focused method bodies and key variables): Large code bases often contain a large amount of code, but when generating test cases, they often focus only on specific functional modules or methods. By extracting the focused method bodies and key variables, the scope of code processed by large models is narrowed, allowing them to more closely analyze the core logic and accurately understand the code's semantics.

[0134] Semantic Information Extraction (Method Signatures, Variable Types): Method signatures and variable types are crucial components of code semantics. Method signatures specify the method's name, parameters, and return value, while variable types define the variable's usage and scope. Extracting this information provides more semantic clues for large models, helping them better understand the code's functionality and input / output requirements.

[0135] Then, the dynamic feedback iterative generation mechanism is introduced:

[0136] The dynamic feedback-based iterative generation mechanism continuously interacts with the large model, adjusting and optimizing based on feedback from the generated results, gradually improving the semantic correctness of the test cases. Specifically, prompts and guidance are first provided based on the preprocessed code and expected behavior, and test cases are generated based on the results of the prompts and guidance. The generated test cases are then executed and evaluated, and the evaluation results determine whether the test cases meet the requirements. If they do, the final test cases are generated; if not, feedback is provided, which is then used to implement subsequent prompts and guidance.

[0137] Hint guidance: Key information such as pre-processed code and expected behavior is fed into the large model as hints to guide the large model in generating initial test cases. Hints should be as detailed and accurate as possible to ensure the large model understands the code's functionality and test requirements.

[0138] Test case generation: The large model generates test cases based on the prompt information. These test cases may include boundary conditions, abnormal scenarios, etc. to fully verify the correctness of the code.

[0139] Execution and Evaluation: Execute the generated test cases and evaluate the results. During the evaluation process, check whether the test cases cover all expected scenarios and whether there are any semantic errors or logical loopholes.

[0140] Feedback and Iteration: Issues and improvement suggestions discovered during the evaluation process are fed back into the larger model as feedback. The larger model adjusts its generation strategy based on this feedback to generate test cases that better meet the requirements. This process continues iteratively until the generated test cases achieve a high level of semantic correctness.

[0141] Preferably, the two mechanisms described above can be combined to ensure semantic correctness. In this combined process, the original code is first preprocessed. Based on the preprocessing results, a dynamic feedback iterative generation mechanism is executed to generate test cases. The generated test cases are then executed and evaluated. If the evaluation results determine that the requirements are met, the final test cases are generated. If not, feedback is generated, which feeds into subsequent dynamic feedback iterative generation processes.

[0142] This demonstrates that the code preprocessing-enhanced context-awareness mechanism provides high-quality input for the dynamic feedback-based iterative generation mechanism, enabling the large model to understand code semantics in a clearer context. The dynamic feedback-based iterative generation mechanism, through continuous interaction and optimization, further ensures the semantic correctness of the generated test cases. These two mechanisms work together to form a closed-loop process, gradually improving the quality of test cases.

[0143] 4. Application Layer

[0144] The application layer is the interface between the system and the user. It is primarily responsible for presenting test results to the user in a visual manner and providing feedback on optimization suggestions based on the test analysis results. Through intuitive visual reports, users can easily understand the test status and make appropriate decisions. Its main functional modules include:

[0145] (1) Intelligent test console module: provides a 3D topology map to display the device communication status, supports VR / AR interaction, visual operation and other functions.

[0146] (2) Automated test pipeline module: Integrates the CI / CD tool chain to trigger full-link testing of multi-protocol compatibility with one click.

[0147] (3) Risk warning module: pushes device health scores in real time based on classifiers in machine learning.

[0148] (4) Visual interface management module: provides visual interface API interface management, which is used to display some visual test reports, such as charts and report styles.

[0149] The 3D topology and VR / AR design solutions are used to collect and process device communication status and test data, converting them into intuitive 3D topology diagrams for display. Furthermore, VR / AR technology enables users to view and manipulate 3D topology diagrams in a more immersive and interactive way, thereby better understanding the communication relationships and status between devices.

[0150] In the overall VR / AR interaction process, data collection and processing are first performed, and a 3D topology map is generated based on the processing results. Then, based on the 3D topology map, the VR / AR scene is built. The built VR / AR scene needs to be interactively designed to enable user interaction. This specifically includes the following stages:

[0151] (1) Data collection and processing:

[0152] Data collection: Collect communication status data from each device. This data may include the device's connection status (connected, disconnected), communication bandwidth, signal strength, packet loss rate, etc.

[0153] Data processing: Clean, convert and analyze the collected data and organize it into a format suitable for 3D topology display.

[0154] (2) 3D topology map generation:

[0155] Model construction: Build a basic model of the 3D topology map based on the physical layout and communication relationships of the devices.

[0156] State mapping: Map the processed data onto a 3D model and use visual effects such as color, transparency, size, and flashing to indicate the communication status of the device.

[0157] (3) VR / AR integration and interaction:

[0158] VR / AR scene construction: Integrate the generated 3D topology map into the VR / AR environment. In VR, users can fully immerse themselves in the virtual 3D scene through a headset. In AR, the 3D topology map is superimposed on the real scene and can be viewed through mobile devices or AR glasses.

[0159] Interaction design: Design various interaction methods to enable users to interact with the 3D topology map. For example, users can use gestures, voice commands, and controller operations to select devices, view detailed information, and adjust viewing angles.

[0160] In addition, VR / AR integration and interaction design can also be performed. In order to provide users with a richer, more natural and efficient VR / AR interaction experience and improve the ability to manage and understand the communication status of devices, the VR / AR integration and interaction methods can be processed as follows:

[0161] (1) Expansion of natural interaction methods

[0162] Gesture and Posture Recognition: Breaking through traditional controller operation, high-precision gesture recognition technology allows users to interact with the 3D topology map through natural gestures. For example, users can tap to select a device, pinch to zoom to adjust the map size, and wave to switch perspectives.

[0163] Deep application of voice interaction: Beyond simple voice command queries, voice control can also be used to control complex operational processes. For example, a user can say, "View all disconnected devices and highlight them," and the system will accurately understand and execute the corresponding action. Furthermore, speech synthesis technology can be combined to provide users with voice feedback, making the interaction more fluid.

[0164] (2) Multimodal interactive fusion

[0165] Vision and touch fusion: In a VR environment, tactile feedback devices (such as tactile gloves) are combined to allow users to feel the corresponding touch when touching virtual devices.

[0166] Combining auditory and visual interaction: Enhance the interactive experience through sound effects. Different sound effects are emitted when the device's communication status changes. For example, a cheerful sound effect plays when the device is successfully connected, and a warning sound effect plays when the connection is disconnected, allowing users to understand the device status in real time without looking at the screen.

[0167] (3) Social interaction function

[0168] Multi-person collaborative interaction: Multiple users can simultaneously access the same VR / AR environment for collaborative device management and troubleshooting. Users can see each other's avatars, communicate via voice or text chat, and collaborate on 3D topology maps. For example, when troubleshooting a network problem, technicians in different locations can simultaneously analyze and manipulate the topology map in a VR environment.

[0169] (4) Context-aware interaction

[0170] Environmental awareness: The system can sense the user's physical environment and automatically adjust the VR / AR interactive experience based on environmental changes. For example, it can automatically increase the brightness of the 3D topology map in a dimly lit environment or increase the volume of voice prompts in a noisy environment.

[0171] (5) User state perception: The interaction mode is adjusted by monitoring the user's physiological state (such as heart rate, eye movement, etc.). If the user is in a state of tension for a long time, the system can automatically provide some auxiliary operation prompts to reduce the user's burden.

[0172] The VR / AR interaction design process includes the following stages:

[0173] (1) Preparation phase: First, prepare the 3D topology map, including data collection, processing, and model construction. Build a VR / AR environment to provide a foundation for subsequent interactions. Initialize various interaction methods, such as starting modules such as gesture recognition and voice recognition.

[0174] (2) Interaction phase: The interaction type is determined based on the user's operation, which may be gesture interaction, voice interaction, tactile interaction, or social interaction. Different interaction types are processed accordingly, such as gesture recognition and voice command understanding. The parsed operation instructions are executed on the 3D topology map to enable operations such as viewing and modifying the device status.

[0175] (3) Feedback and update phase: Provide feedback to users on the interaction results, such as voice prompts, visual effects, etc. Update the display of the 3D topology map based on the interaction results to ensure that users see the latest device status.

[0176] (4) Loop judgment phase: Determine whether the user continues to interact. If yes, return to the interaction type judgment phase and continue the interaction; if not, end the entire process.

[0177] Among them, any network model or module deployed at the edge computing layer can be regarded as a specific form of the first network model mentioned above, and any network model or module deployed at the platform layer can be regarded as a specific form of the second network model mentioned above.

[0178] In summary, the Internet of Vehicles test platform system in this example has at least the following characteristics:

[0179] (1) Deep coupling of large models and edge computing: Edge nodes run lightweight LLM to achieve real-time test case generation, and the cloud-based large model provides global optimization.

[0180] (2) Design a dynamic context-aware generation strategy: ensure that when generating test cases, the large model expands the test case coverage boundaries and exceptions, and solves the convergence problem that exists when generating test cases.

[0181] (3) Dynamic protocol adaptation technology: Breaking through the traditional manual configuration mode, it automatically generates protocol test cases through semantic analysis to dynamically adapt to multiple protocols, and combines historical knowledge graphs to achieve fast and accurate protocol adaptation.

[0182] (4) Four-layer elastic architecture: The four-layer architecture of the integrated large model LLM, with end-to-end AI design in each layer, enables end-to-end management.

[0183] (5) Bypassable design: For real-time scenario testing, the platform layer can be bypassed to improve the running speed and efficiency of real-time test cases.

[0184] (6) Dynamic optimization design: Code preprocessing enhances context awareness and dynamic feedback iterative generation mechanism to ensure the semantic correctness of test cases and the generated test cases are more accurate and comprehensive.

[0185] (7) Full-link visualization: Integrates innovative display methods such as 3D topology and VR / AR interaction, surpassing traditional application layer design.

[0186] Accordingly, at least the following beneficial effects can be achieved:

[0187] (1) Intelligence: Through large models and AI technology, intelligent analysis and prediction of Internet of Vehicles devices are achieved, improving the accuracy and reliability of testing.

[0188] (2) Automation: Automated testing processes greatly reduce manual intervention, improve testing efficiency, and reduce testing costs.

[0189] (3) Efficiency: Distributed computing and parallel processing technologies enable the test platform to quickly handle a large number of test tasks, thereby improving the test speed.

[0190] (4) Accuracy: The test method based on simulating real scenarios can more realistically evaluate the performance of Internet of Vehicles equipment and provide a more valuable reference for equipment optimization and improvement.

[0191] It will be appreciated by those skilled in the art that all or some of the steps, systems, and functional modules / units in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. In hardware implementations, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium). As is well known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable, and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, it is well known to those skilled in the art that communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0192] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0193] Those skilled in the art will understand that although some embodiments described herein include certain features included in other embodiments but not other features, the combination of features from different embodiments is meant to be within the scope of the present embodiment and to form different embodiments.

[0194] It is understood that the above embodiments are merely exemplary embodiments for illustrating the principles of the present disclosure, and the present disclosure is not limited thereto. Those skilled in the art may make various modifications and improvements without departing from the spirit and substance of the present disclosure, and such modifications and improvements are also considered to be within the scope of protection of the present disclosure.

Claims

1. A vehicle networking test system, characterized in that: The system includes: a perception layer, an edge computing layer, a platform layer, and an application layer; wherein, The perception layer is used to obtain device status data of multiple Internet of Vehicles devices in a current period; The edge computing layer is configured to obtain test context information corresponding to the current time period through a pre-trained first network model, generate a first test case based on the device status data and the test context information, and assign the first test case to an edge computing module; The platform layer is configured to generate a second test case based on historical test data using a pre-trained second network model, and distribute the second test case to the edge computing module and / or cloud device; The application layer is used to generate and display visual test results based on the test data generated by the edge computing module and / or cloud device for the test case; The parameter magnitude of the first network model is smaller than the parameter magnitude of the second network model; and the first network model and / or the second network model are trained in the following manner: by calculating the difference between the candidate test case and the historical case, adjusting the penalty coefficient, so as to dynamically adjust the model parameters of the network model by the penalty coefficient.

2. The system according to claim 1, wherein: The platform layer is also used to obtain and store test data generated by the edge computing module in the edge computing layer; Furthermore, the system further comprises a bypass control module, wherein: When the bypass control module is in the first working mode, the application layer is connected to the platform layer, and the application layer is used to obtain test data generated by the edge computing module and / or cloud device for the test case from the platform layer; When the bypass control module is in the second working mode, the application layer is connected to the edge computing layer, and the application layer is used to obtain test data generated by the edge computing module for the test case from the edge computing layer.

3. The system according to claim 1, wherein: The perception layer includes: Multiple sensor modules are used to collect device status information of multiple Internet devices; wherein the device status information of the multiple Internet devices corresponds to multiple different network protocols; Artificial intelligence engine module, used for data cleaning and anomaly detection based on collected device status information; The semantic gateway module is used to perform protocol conversion processing on the device status information detected by the artificial intelligence engine module, so that the device status data after protocol conversion processing is transmitted to the edge computing layer.

4. The system according to claim 1, wherein: The first test case corresponds to a first type of test task, the second test case corresponds to a second type of test task, and the real-time requirement of the first type of test task is higher than the real-time requirement of the second type of test task; Furthermore, the second test cases include: functional test cases, protocol test cases and exception test cases; The platform layer is specifically used to: generate the functional test case according to the acquired functional description information; generate the protocol test case according to the acquired protocol state machine data; and generate the abnormal test case according to the abnormal data in the acquired historical data.

5. The system according to claim 1, wherein: The first network model is specifically trained in the following manner: Generate candidate test cases; Calculating a first difference between the candidate test case and the historical test case corresponding to the semantic level; Calculating a second difference degree corresponding to a text level between the candidate test case and the historical case; According to the first difference and the second difference, a penalty coefficient is adjusted, and the model parameters of the network model are dynamically adjusted by the penalty coefficient.

6. The system according to claim 1, wherein: The second network model is specifically trained in the following manner: Generate candidate test cases based on model prompt information, wherein the candidate test cases include boundary conditions and / or abnormal scenarios; Execute the test case, and determine whether the test case meets the preset conditions based on the execution result and scenario coverage of the test case; If not, the second network model is iteratively adjusted until the candidate test cases generated by the adjusted second network model meet the preset conditions.

7. The system according to claim 1, wherein: The application layer includes: A test console module, configured to display the device communication status in the test results through a three-dimensional topology diagram; Test pipeline module, used to trigger multi-protocol compatibility testing; Risk warning module, used to push the health score of IoT devices in real time based on the classifier; The visual interface management module is used to display the visual test report in the test results.

8. The system according to any one of claims 1 to 7, characterized in that: The test context information includes: multimodal test context information; and the multimodal test context information includes at least two of the following: requirement document data, historical test cases, runtime coverage data, and code data.

9. A testing method implemented based on the system according to any one of claims 1 to 8, characterized in that: The method comprises: Obtain device status data of multiple Internet of Vehicles devices within the current period through the perception layer; Calling, through the edge computing layer, a pre-trained first network model, obtaining test context information corresponding to the current time period, generating a first test case based on the device status data and the test context information, and assigning the first test case to an edge computing module; Through the platform layer, calling a pre-trained second network model, generating a second test case based on historical test data, and distributing the second test case to the edge computing module and / or cloud device; Through the application layer, visual test results are generated and displayed based on the test data generated by the edge computing module and / or cloud device for the test case.

10. The method according to claim 9, characterized in that In the case where the system further includes a bypass control module, the method further includes: When it is detected that a preset switching condition is met, controlling the bypass control module to switch from the first working mode to the second working mode; Wherein, in the first working mode, the application layer is connected to the platform layer; In the second working mode, the application layer is connected to the edge computing layer across the platform layer.

Images