Sandbox depth test system, method, apparatus, and medium for a vehicle

Abstract

The application provides a sandbox deep test system, method, equipment and medium of a vehicle, which determines the danger level of a test scene through a supervision and scheduling hub, generates a scene code from a cloud-end encrypted scene library; after the mobile test equipment is authenticated, the supervision and scheduling hub generates a dynamic key seed and distributes it; the cloud-end scene library splits scene data according to the danger level, encrypts the scene data using a session key generated from the key seed, and sends the scene data to the mobile test equipment in the form of fragments; the mobile test equipment decrypts the data and performs black box testing on the automatic driving system, and generates a standardized test report. Through the dynamic encryption and data fragmentation transmission mechanism of the danger level linkage, the application prevents the test scene from being leaked from the source, ensures the reliability and data security of the black box testing, and at the same time guarantees the fairness and authority of the test results, fully meets the strict requirements of the automatic driving sandbox supervision.

Description

Technical Field

[0001] This application relates to the field of autonomous driving technology, and more specifically, to a sandbox depth testing system, method, device, and medium for vehicles. Background Technology

[0002] With the rapid development of autonomous driving technology, Level 2 and above autonomous driving systems are gradually becoming more widespread. To ensure their safety, regulatory agencies often adopt the "sandbox regulatory" model, which involves conducting in-depth testing of cutting-edge technologies in a controlled environment.

[0003] However, traditional simulation testing often sends the complete test scenario file to the test terminal, which allows the tested autonomous driving system to potentially obtain the full picture of the scenario through technical means, thereby performing targeted optimizations. This distorts the test results and fails to expose real risks. Furthermore, the data transmission process lacks security, posing a risk of data leakage. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a sandbox depth testing system, method, device and medium for vehicles to overcome the problems in the prior art.

[0005] In a first aspect, embodiments of this application provide a sandbox deep testing system for vehicles, including a monitoring and dispatching center, mobile testing equipment, a cloud-based encrypted scenario library, and a vehicle under test equipped with an autonomous driving system; The monitoring and scheduling center is used to respond to the test scenario input operation, determine the danger level of the test scenario, and send the test scenario and the corresponding danger level to the cloud-encrypted scenario library. The cloud-based encrypted scenario library is used to generate scenario codes for the test scenarios and send them to the monitoring and scheduling center. The mobile testing device is used to generate identity verification requests and scene loading requests, and send them to the monitoring and scheduling center. The monitoring and scheduling center is used to generate a dynamic key seed for scenario loading based on the scenario code, the danger level and the corresponding dynamic encryption strategy after the identity verification is passed, and send the dynamic key seed to the mobile testing device and the cloud-based encrypted scenario library. The cloud-based encrypted scenario library is used to split the scenario data of the test scenario based on the data segmentation strategy corresponding to the danger level, obtain multiple data segments, and send the scenario segment data encrypted based on the session key to the mobile test device; wherein, the session key is generated by the dynamic key seed; The mobile testing equipment is used to test the autonomous driving system of the vehicle under test by decrypting the scene fragment data based on the session key, obtain the response data of the vehicle under test, and generate a standardized test report based on the response data.

[0006] In some technical solutions of this application, after the test is completed, the monitoring and scheduling center is used to send a data retrieval instruction to the mobile test device; The mobile testing device is used to clean up the test data related to this test.

[0007] In some technical solutions of this application, the aforementioned regulatory and scheduling center determines the hazard level of the test scenario through the following methods, including: The core parameters of the test scenario are analyzed using a preset scenario risk assessment algorithm to calculate its collision risk value; based on the collision risk value, the test scenario is automatically classified into one of several preset danger levels.

[0008] In some technical solutions of this application, the aforementioned cloud-based encrypted scene library generates the scene code in the following manner: The real-time geographic location information and component temperature information of the mobile testing device are obtained, and the real-time state factor of the device is calculated. The scenario code is generated based on the timestamp, random hash value, enterprise identifier of the company to which the tested vehicle belongs, and real-time status factor of the equipment.

[0009] In some technical solutions of this application, the aforementioned monitoring and scheduling center generates the dynamic key seed in the following way: upon receiving the scenario loading request, a test session is generated; The dynamic key seed is generated based on the test session, the scenario code, the current timestamp, and the danger level.

[0010] In some technical solutions of this application, the aforementioned cloud-based encrypted scenario library splits the scenario data of the test scenario in the following way: The scenario data of the test scenario of the first hazard level is split based on the first time length; The scenario data of the test scenario at the second hazard level is split based on the second time length; wherein the first hazard level is higher than the second hazard level, and the first time length is shorter than the second time length.

[0011] In some technical solutions of this application, the aforementioned mobile testing device includes an evaluation module; the evaluation module is encrypted by a storage encryption algorithm preset by the monitoring and scheduling center and then stored in the mobile testing device; wherein the storage encryption algorithm cannot be modified locally.

[0012] Secondly, embodiments of this application provide a sandbox depth testing method for vehicles, applied to the aforementioned testing system, the testing method comprising: The monitoring and scheduling center responds to the test scenario input operation, determines the danger level of the test scenario, and sends the test scenario and the corresponding danger level to the cloud-encrypted scenario library. The test scenario's scenario code is generated through the cloud-based encrypted scenario library and sent to the monitoring and scheduling center. The mobile testing device generates an identity verification request and a scene loading request, which are then sent to the monitoring and scheduling center. After identity verification is passed, the monitoring and scheduling center generates a dynamic key seed for scene loading based on the scene code, the danger level and the corresponding dynamic encryption strategy, and sends the dynamic key seed to the mobile testing device and the cloud-based encrypted scene library. The cloud-based encrypted scenario library splits the scenario data of the test scenario into multiple data fragments based on the data fragment splitting strategy corresponding to the danger level, and sends the scenario fragment data encrypted with a session key to the mobile test device; wherein, the session key is generated by the dynamic key seed; The mobile testing device tests the autonomous driving system of the vehicle under test using the scene fragment data decrypted based on the session key, obtains the response data of the vehicle under test, and generates a standardized test report based on the response data.

[0013] Thirdly, embodiments of this application provide an electronic device, a processor, a memory, and a bus. The memory stores machine instructions executed by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine instructions are executed by the processor, the steps of the aforementioned vehicle sandbox depth testing method are performed.

[0014] Fourthly, embodiments of this application provide a computer storage medium storing a computer program, which, when run by a processor, executes the steps of the aforementioned vehicle sandbox depth testing method.

[0015] The technical solutions provided by the embodiments of this application may include the following beneficial effects: This application provides a sandbox depth testing system for vehicles, including a monitoring and dispatching center, mobile testing equipment, a cloud-based encrypted scenario library, and a vehicle under test equipped with an autonomous driving system. The monitoring and dispatching center is used to respond to a test scenario input operation, determine the danger level of the test scenario, and send the test scenario and its corresponding danger level to the cloud-based encrypted scenario library. The cloud-based encrypted scenario library is used to generate a scenario code for the test scenario and send it to the monitoring and dispatching center. The mobile testing equipment is used to generate an identity verification request and a scenario loading request and send them to the monitoring and dispatching center. After successful identity verification, the monitoring and dispatching center is used to, based on the scenario code, the danger level, and the corresponding dynamic encryption... The strategy generates a dynamic key seed for scenario loading and sends the dynamic key seed to the mobile testing device and the cloud-based encrypted scenario library. The cloud-based encrypted scenario library is used to split the scenario data of the test scenario based on the data segmentation strategy corresponding to the danger level, obtain multiple data segments, and send the scenario segment data encrypted based on a session key to the mobile testing device. The session key is generated by the dynamic key seed. The mobile testing device is used to test the autonomous driving system of the vehicle under test using the scenario segment data decrypted based on the session key, obtain the response data of the vehicle under test, and generate a standardized test report based on the response data.

[0016] This application eliminates the leakage and prediction of test scenarios from the source. Through dynamic keys and fragmented transmission, it ensures that even if the data is intercepted, the complete scenario logic cannot be restored. It achieves precise traceability and closed-loop management of the test process. While improving test security, it fully meets the strict requirements of autonomous driving sandbox supervision for in-depth exploration, fair evaluation and mobility testing.

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

[0018] 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.

[0019] Figure 1 A schematic diagram of a sandbox depth testing system for a vehicle provided in an embodiment of this application is shown; Figure 2A schematic flowchart of a sandbox depth testing method for a vehicle provided in an embodiment of this application is shown. Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0021] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0022] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0023] With the rapid development of autonomous driving technology and the increasing prevalence of L2-level combined driver assistance systems, the demand for testing their safety and reliability is becoming increasingly urgent. However, existing testing methods have many problems and are difficult to meet the stringent requirements of sandbox regulation.

[0024] In terms of scenario simulation, there are many real-world scenarios that are difficult to simulate through real-vehicle testing, such as extremely dangerous scenarios (like chain accidents involving multiple vehicles rear-ending each other in heavy rain, or sudden landslides causing road closures). Traditional real-vehicle testing is limited by safety risks and costs, making it impossible to fully test these scenarios and achieve sufficient scenario coverage. This directly leads to the inability to detect potential risks such as decision-making loopholes and response delays in autonomous driving systems in these high-risk scenarios, seriously threatening the safety of actual road driving.

[0025] Regarding equipment mobility, many current testing devices are bulky and complex to install, making them inconvenient to carry to the customer's site for testing. Often, the vehicle under test needs to be driven to a fixed testing site, which not only increases testing costs and time, but may also affect the accuracy of the test due to the difference between the site environment and the actual use environment.

[0026] Traditional real-vehicle testing has inherent limitations in terms of scenario coverage (extreme scenarios cannot be reproduced) and test execution flexibility (poor equipment mobility and low environmental compatibility). This makes black-box simulation testing the only necessary technical path to overcome these limitations. Through a virtual environment, all extreme and dangerous scenarios can be reproduced without risk and at low cost. Relying on highly mobile testing equipment, testing can be carried out in the customer's actual use scenarios. Only by combining the two can the potential risks of the system be fully exposed and the comprehensiveness, accuracy, and reliability of the test results be ensured.

[0027] Regarding data security, on the one hand, test scenario files lack dedicated encryption protection mechanisms during transmission, loading, and use, making them easily accessible. This allows the tested vehicles to optimize their response logic accordingly, rather than truly exposing potential risks, severely undermining the core value of the sandbox's "deep probing" capabilities. For example, if details of an extremely dangerous scenario (such as a sudden mudslide causing multi-vehicle obstacle avoidance conflicts) are leaked in advance, the tested autonomous driving system may be pre-programmed with targeted strategies, making the test results unable to reflect its true safety level. On the other hand, existing technologies do not strictly control the lifecycle of scenario files. After testing, scenario data can easily remain on the testing equipment or the tested vehicle, posing a risk of secondary extraction and reuse. Some testing systems even store scenario files directly in plaintext, further exacerbating the risk of leakage.

[0028] Regarding evaluation algorithms and indicators, there is currently a lack of a unified and standardized system, which fails to meet the requirements of Level 2 combined assisted driving. Different testing organizations use different evaluation indicators and algorithms, resulting in inconsistent evaluation results for the same tested vehicle, making it difficult to ensure the fairness of the test and posing challenges to the technical assessment by regulatory authorities.

[0029] Based on this, this application provides a sandbox depth testing system, method, device, and medium for vehicles, which are described below through embodiments.

[0030] Figure 1 The illustration shows a schematic diagram of a sandbox depth testing system for a vehicle provided in an embodiment of this application, including a monitoring and dispatching center, mobile testing equipment, a cloud-based encrypted scene library, and a vehicle under test equipped with an autonomous driving system; The monitoring and scheduling center is used to respond to the test scenario input operation, determine the danger level of the test scenario, and send the test scenario and the corresponding danger level to the cloud-encrypted scenario library. The cloud-based encrypted scenario library is used to generate scenario codes for the test scenarios and send them to the monitoring and scheduling center. The mobile testing device is used to generate identity verification requests and scene loading requests, and send them to the monitoring and scheduling center. The monitoring and scheduling center is used to generate a dynamic key seed for scenario loading based on the scenario code, the danger level and the corresponding dynamic encryption strategy after the identity verification is passed, and send the dynamic key seed to the mobile testing device and the cloud-based encrypted scenario library. The cloud-based encrypted scenario library is used to split the scenario data of the test scenario based on the data segmentation strategy corresponding to the danger level, obtain multiple data segments, and send the scenario segment data encrypted based on the session key to the mobile test device; wherein, the session key is generated by the dynamic key seed; The mobile testing equipment is used to test the autonomous driving system of the vehicle under test by decrypting the scene fragment data based on the session key, obtain the response data of the vehicle under test, and generate a standardized test report based on the response data.

[0031] This application prevents the leakage of test scenarios from the source by using a dynamic encryption and data fragmentation transmission mechanism linked to hazard levels, ensuring the reliability and data security of black-box testing, while also guaranteeing the fairness and authority of test results, and fully meeting the stringent requirements of autonomous driving sandbox regulation.

[0032] The following describes some embodiments of this application in detail. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0033] The aforementioned regulatory dispatch center is a core control and data processing hardware platform, physically manifested as a server or server cluster deployed in the regulatory data center. This central hardware integrates a high-performance processor, a large-capacity memory, and a high-speed network communication module, used to perform scenario risk assessments, manage the whitelist of mobile test device identities, generate test session IDs and dynamic key seeds, and undertake the entire process of data monitoring and command issuance tasks.

[0034] The mobile testing equipment is a lightweight, highly mobile portable hardware terminal. It features a suitcase-style integrated shell, with an overall weight kept below 6 kg, and boasts a waterproof, dustproof, and shockproof physical structure. The equipment hardware integrates a testing host, a vehicle interaction interface module, a wireless communication module, a GPS positioning module, a temperature sensor, and an encryption chip. Its design supports rapid deployment at customer sites and can directly start and run tests within an ambient temperature range of -30℃ to 70℃.

[0035] The cloud-based encrypted scenario library is a cloud-based hardware infrastructure, physically based on a server cluster consisting of network devices, storage servers, and security hardware (such as encryption machines). This hardware platform is specifically designed for the secure storage and management of diverse test scenario data, and can respond to commands to perform hardware-level processing tasks such as scenario encoding generation, data fragment splitting, and encryption operations. Mobile testing devices seamlessly interface directly with the cloud-based scenario library, eliminating the need for enterprises to deploy additional scenario storage modules. They can download the required scenario files through a terminal interface and quickly begin testing. The cloud-based scenario library covers diverse types, including basic regulatory scenarios, extreme danger scenarios, and user-defined scenarios, and can be continuously updated and expanded in terms of the number and dimensions of scenarios to fully match the personalized testing needs of different enterprises, significantly improving the efficiency of scenario acquisition and application.

[0036] The test vehicle equipped with an autonomous driving system is a physical vehicle with a complete autonomous driving hardware system, which integrates an autonomous driving domain controller, perception sensors (such as cameras and radar), and actuators. The vehicle establishes a physical connection with the mobile test equipment through its standardized vehicle interaction interface (such as a CAN bus or Ethernet interface) to receive test stimuli and feed back its response data.

[0037] The test scenario entry operation here refers to the process by which regulatory personnel input and submit new test scenarios (including scenario parameters, environmental conditions, traffic participant behavior, etc.) to the system through the human-computer interaction interface of the regulatory dispatch center. The hazard level of the test scenario refers to the automated classification of the complexity and potential risk of the test scenario through a preset quantitative assessment model. The system typically divides scenarios into multiple preset levels, such as L1 (normal), L2 (medium risk), and L3 (extremely dangerous).

[0038] When determining the hazard level, the process includes: analyzing the core parameters of the test scenario using a preset scenario risk assessment algorithm to calculate its collision risk value; and automatically classifying the test scenario into one of multiple preset hazard levels based on the collision risk value.

[0039] For example, when a supervisor logs into the web management interface of the supervisory dispatch center and clicks the "Add Test Scenario" button, this action triggers a test scenario entry operation. In the subsequent scenario editing interface, the supervisor fills in or configures the core parameters of the scenario according to the standard format. Key parameters include: Environmental parameters: set to "nighttime, heavy rain," with visibility below 50 meters. Road parameters: set to "the leftmost lane of the highway, with a construction cone-closed area 500 meters ahead." Traffic flow parameters: set the vehicle speed to 90 km / h, with a slow-moving truck ahead in the same lane and a rapidly approaching vehicle from the side and rear. Critical event: set the truck to suddenly brake as it approaches the construction area.

[0040] Automatic Determination of Hazard Level: After the supervisor completes the parameter configuration and clicks "Submit," the supervisory dispatch center responds to this operation, and its built-in scenario risk assessment algorithm is automatically invoked. This algorithm begins to analyze and calculate the following core parameters: Environmental Interference Coefficient: Based on the conditions of "nighttime" and "heavy rain," this coefficient is matched from a preset database and set to 0.9 (extremely high interference). Vehicle Interaction Count: Analyzing vehicles in the scenario that have potential interaction with this vehicle (trucks in front, vehicles to the side and rear), the interaction count is determined to be 2. Reaction Time Threshold: Combining the conditions of "high-speed vehicle" and "heavy rain and low visibility," a safe reaction time threshold of 1.2 seconds is calculated. Subsequently, its determination logic is executed as follows, with the core formula: The collision risk value is calculated as (environmental interference coefficient × number of vehicle interactions) / reaction time threshold. Substituting the parameters above, the collision risk value is (0.9 × 2) / 1.2 = 1.5. The monitoring and dispatch center has pre-set mapping rules between hazard levels and risk values: L1 (normal): collision risk value < 0.5; L2 (medium risk): 0.5 ≤ collision risk value < 1.0; L3 (extremely dangerous): collision risk value ≥ 1.0. According to this rule, the calculated risk value of 1.5 is automatically classified as L3 (extremely dangerous).

[0041] Once the hazard level determination is complete, the monitoring and scheduling center will generate a complete data packet. This data packet contains: complete test scenario configuration data and the determined hazard level identifier ("L3"). Subsequently, the monitoring and scheduling center will send this data packet to the cloud-based encrypted scenario library via the secure HTTPS communication protocol. Upon successful receipt, the cloud-based scenario library will return an acknowledgment receipt, indicating that the scenario has been officially added to the library and can be used by subsequent test tasks.

[0042] The scenario code in this embodiment is a four-dimensional regulatory scenario code, a composite code automatically generated by a cloud-based encrypted scenario library, used to uniquely identify test scenarios and achieve end-to-end traceability. This code is strongly bound to the core parameters of the test scenario, possessing immutability and uniqueness.

[0043] After successfully receiving and storing the test scenario and hazard level data, the cloud-based encrypted scenario library automatically triggers the scenario coding generation program. The program first obtains the basic information dimensions required for coding generation: Timestamp: Retrieves the current UTC (Coordinated Universal Time) time, accurate to milliseconds. For example, a timestamp of 20250826143045123 (August 26, 2025, 2:30:45:123 PM). This ensures the uniqueness of the encoding on the timeline.

[0044] Random hash value: A cryptographically secure random number generator is invoked to generate a random number, which is then used to generate a 32-bit hash value using the SM3 hash algorithm, for example, 7F1C3DA... (32 bits in total). This dimension is used to prevent the code from being forged or guessed.

[0045] Tested Company Identifier (Company to which the tested vehicle belongs): The registration ID of the tested company with the regulatory agency, such as QY202501. This dimension clarifies the responsible party for the test.

[0046] Device real-time state factor: an identifier of the physical world. The device real-time state factor is obtained in the following way: The cloud-based encrypted scenario library sends a request to an authorized mobile testing device to obtain its real-time status data. For example, the mobile testing device is located at Automaker A's testing site and has been powered on and initialized. Upon receiving the request, the mobile testing device collects two types of real-time data using its built-in hardware sensors: GPS coordinates: obtaining the device's current latitude and longitude information accurate to 10 meters, for example (39.9042°N, 116.4074°E). Core chip temperature: reading data from the device's main processor's temperature sensor, accurate to 0.1°C, for example, 47.8°C. The device concatenates these two types of data into a string, for example, in the format "GPS(39.9042,116.4074)_T47.8". Subsequently, the device uses the SM3 hash algorithm to calculate this string, generating a hash value, and takes the first 16 bits of this hash value as the device's real-time status factor, for example, "E5A3B2C4D8F109A7".

[0047] After obtaining the basic dimensional information, it will be concatenated according to a preset format to form the original encoded string: Format: timestamp + random hash value + tested enterprise identifier + device real-time status factor. For example: The string "20250826143045123-7F1C3DA...-QY202501-E5A3B2C4D8F109A7" has been identified as the four-dimensional monitoring scenario code for this test scenario. It is then sent to the monitoring and dispatch center.

[0048] More importantly, by employing encryption methods (such as RSA asymmetric encryption + SM4 symmetric encryption), this code is forcibly bound to the core parameters of the scenario (such as rainstorms, construction zones, vehicle interactions, etc.), forming an immutable "code-scenario" mapping relationship. This means that any tampering with the scenario parameters will lead to the failure of its verification with the code. By generating this four-dimensional code that integrates time, randomness, responsible party, and the real-time physical state of the equipment, traceability capabilities surpassing traditional coding methods are achieved. In the event of a scenario data breach, regulators can not only trace back to the associated companies but also accurately pinpoint the specific physical location (GPS coordinates) of the test equipment at the time of the breach and its hardware operating status (chip temperature) through the real-time device status factor in the code. This achieves end-to-end controllability and traceability of the "scenario-device-environment" chain, greatly enhancing the security and accountability of the testing process.

[0049] An identity verification request is a data packet automatically generated and sent to the monitoring and dispatch center by the mobile testing device before the testing process begins. Its purpose is to verify the legitimacy and permissions of the device itself and its operating environment. This request typically includes the device's unique hardware identifier (such as CPU serial number and MAC address) and the tested company's registration ID.

[0050] A scenario loading request is a data packet triggered by a mobile testing device (usually via a tester operating its web interface) after identity verification, used to request data for a specific test scenario. This request marks the official start of a specific testing task.

[0051] For example, a simulation test team arrives at an automaker's open parking lot with mobile testing equipment, preparing to conduct a compliance check test on its Level 2 autonomous driving system. The testers open the portable case of the mobile testing equipment and connect it to power. After completing its hardware self-test, the equipment automatically runs its built-in "regulatory identity verification module." This module then generates an identity verification request. This request is a structured data message whose core content includes: a unique hardware identifier for the device: the CPU serial number (e.g., CPU-A01) and MAC address read from the device firmware; the identifier of the company being tested: the automaker's registration ID on the regulatory platform (e.g., QY202502); and initial location information: the current approximate location coordinates obtained in real-time by the device's built-in GPS module. After this request data message is generated internally, it is immediately encrypted using HTTPS and sent to the regulatory dispatch center via the device's wireless communication module (e.g., a 4G / 5G module).

[0052] Upon receiving a request, the monitoring and dispatch center verifies whether the device identifier is on its whitelist and whether the association between the enterprise ID and the device is legitimate. Once verification is successful, the center returns an "identity verification successful receipt" to the mobile testing device.

[0053] Once the mobile testing device receives the confirmation, the "Scene Loading" function on its Web UI is activated. Testers log in to the Web UI via a browser and select the scene to be tested from the cloud scene library list (e.g., "Passing through urban road construction area" scene).

[0054] When the tester clicks the "Start Test" button, the mobile test device immediately generates a scenario loading request. This request is also a structured data packet, typically encapsulated in JSON format. Its core content includes: the identity verification receipt received in the previous step (serving as proof of the validity of this request), the device number, the unique identifier of the target test scenario (such as the scenario name or pre-assigned ID), and a real-time timestamp. This scenario loading request is also sent to the monitoring and scheduling center via an HTTPS encrypted channel, formally requesting the loading of test scenario data.

[0055] By automatically generating and sending these two types of requests using mobile testing equipment, a "one-click" secure initiation of testing tasks at the customer's site is achieved. This process ensures that only authorized and legitimate devices can initiate tests at designated physical locations and clearly communicates the testing intent to the central monitoring system. This lays a secure and trustworthy foundation for subsequent key steps such as dynamic key distribution and security scenario loading, fully demonstrating the system's integrated design of "high mobility" and "strong monitoring."

[0056] Dynamic key seed: This refers to a core cryptographic data segment generated by the monitoring and scheduling center, serving as the common basis for both the cloud-based encryption scenario library and the mobile testing device to independently generate the same session key. Essentially, it is a composite input parameter containing multiple variables, ensuring the uniqueness and dynamism of the final session key.

[0057] Dynamic encryption strategy: This refers to a set of encryption rules that are linked to the danger level of the test scenario. It not only specifies the encryption algorithm (such as AES-256), but more importantly, it specifies the key update frequency and generation logic. For example, this strategy requires that the session key update frequency in L3 (extremely dangerous) scenarios be three times that in L1 (normal) scenarios.

[0058] Once the monitoring and scheduling center confirms the successful identity verification of the mobile test device, it immediately generates a globally unique test session ID (e.g., SID001) for this round of testing. This ID will be used to uniquely identify this test task in all subsequent processes. Subsequently, the monitoring and scheduling center obtains all the input parameters required to generate the dynamic key seed: Test Session ID (SID001): Binds to this test session. Scene Code (e.g., SC20250826-HASH123-ENT-A-GPS(22.54°N,114.05°E)_T35℃): Binds to the specific scene and device environment of this test. Current Timestamp (e.g., 20250826143045123): Binds to the time the key was generated, ensuring uniqueness. Risk Level Identifier (e.g., L3): Binds to the preset dynamic encryption strategy.

[0059] The monitoring and dispatch center concatenates the four input parameters into a composite string according to predetermined synthesis rules. For example: "SID001-SC20250826-HASH123-ENT-A-GPS(22.54°N,114.05°E)_T35℃-20250826143045123-L3".

[0060] This final string is defined as the dynamic key seed for this test session. Through this synthesis method, the seed becomes a unique credential integrating four dimensions: session, scenario, time, and risk. After generating the seed, the monitoring and dispatch center obtains the digital certificates and public keys of the cloud-based encrypted scenario library and the mobile testing device, respectively. The dynamic key seed is encrypted using the public key from the cloud-based encrypted scenario library, and similarly, the same dynamic key seed is encrypted again using the public key from the mobile testing device. This generates two different data packets, each decryptable only by a specific recipient. The monitoring and dispatch center then sends these two encrypted data packets to the cloud-based encrypted scenario library and the mobile testing device, respectively, via a secure network link.

[0061] This step generates a dynamic key seed strongly bound to the test session, specific scenario, precise time, and risk level, and securely distributes it using asymmetric encryption. This ensures that the encryption key source (seed) used for each test is unique. Even if the key for a particular session is cracked, the seed contains a timestamp and session ID, preventing attackers from deducing the keys for past or future sessions. Asymmetric encryption ensures that the key seed cannot be decrypted even if intercepted during transmission, achieving secure sharing of key materials.

[0062] The data segmentation strategy refers to pre-setting rules for the time granularity of data segmentation based on the hazard level of the test scenario. The core principle of this strategy is that the higher the hazard level, the finer the data segmentation granularity, to ensure that the tested vehicle cannot predict subsequent scenario logic in high-risk scenarios.

[0063] Scene data fragments: These refer to short data blocks formed by cutting a complete test scene into segments according to chronological order and a splitting strategy. Each fragment contains only scene parameters (such as vehicle location and weather conditions) within that time period and does not contain any logical information about the future development of the scene.

[0064] Session key: refers to a symmetric encryption key (such as an AES-256 key) generated by a dynamic key seed through a preset key derivation function. It is used to encrypt and decrypt single or multiple scene data fragments, and its lifecycle is associated with the test session.

[0065] Specifically, the splitting includes splitting the scene data of the test scenario of the first hazard level based on the first time length; The scenario data of the test scenario at the second hazard level is split based on the second time length; wherein the first hazard level is higher than the second hazard level, and the first time length is shorter than the second time length.

[0066] For the test scenario of a multi-vehicle rear-end collision in heavy rain, which has been classified as Level 3 (extremely dangerous), after receiving the dynamic key seed in the cloud-based encrypted scenario library, the danger level identifier (e.g., L3) of the test scenario is read, and the splitting rules are determined according to a preset data segmentation strategy. For example, the strategy stipulates that Level 3 scenarios are split at a granularity of 5 seconds per segment, while Level 1 scenarios are split at a granularity of 10 seconds per segment. The complete multi-vehicle rear-end collision scenario in heavy rain (assuming a total duration of 60 seconds) is divided into 12 consecutive scenario data segments (0-5 seconds, 5-10 seconds, ..., 55-60 seconds). Each generated scenario data segment only contains real-time parameters within that 5-second time window. For example: Segment 1 (0-5 seconds): contains parameters such as a base vehicle speed of 100 km / h, rainfall intensity of 10 mm / h, and distance to the vehicle in front of it of 80 m. Segment 2 (5-10 seconds): contains parameters such as rainfall intensity increasing to 15 mm / h and the vehicle in front of it starting to brake. Each segment does not include the parameter change trends of subsequent segments (e.g., it does not disclose that a second car will cut in at the 15th second). This fragmented, ignorant design is the core of ensuring the effectiveness of black-box testing.

[0067] While splitting the data, the cloud-based encryption scenario library uses the same key derivation function as the mobile test device to process the received dynamic key seed and derive the current AES-256 session key. For L3 scenarios, a timer is started to update the session key according to a dynamic encryption strategy (e.g., every 10 seconds). This means that in this test, the first 10 seconds (covering fragment 1 and fragment 2) use session key K1, the next 10 seconds use session key K2, and so on. Using the currently valid session key (e.g., K1), the first scenario data fragment (0-5 seconds) is encrypted using AES-256 to generate a ciphertext data packet. After encryption, the cloud-based encryption scenario library immediately sends this encrypted data fragment to the mobile test device via HTTPS.

[0068] After receiving, decrypting, and consuming the data segment, the mobile test device requests the next segment from the cloud-based encryption scenario library. After verifying the request's validity, the cloud-based encryption scenario library repeats the process: encrypting the second segment using the currently valid session key (K1 for 5-10 second segments) and sending it. When the timer reaches the 10-second threshold, the cloud-based encryption scenario library derives a new session key (K2) based on the original dynamic key seed and the new time factor, and immediately applies it to the encryption of the third segment (10-15 seconds) and subsequent segments until the next update.

[0069] This step, through data segmentation linked to risk levels and dynamic key encryption, achieves fragmented data transmission, ensuring that the tested autonomous driving system can only respond based on the input at the current moment. It prevents targeted optimization for the complete scenario, thus truly exposing its potential risks. Dynamically updated session keys mean that even if communication is compromised within a short period, attackers can only obtain data fragments from that very short timeframe, unable to reconstruct the complete scenario or decrypt communication data from other time periods. By adapting processing intensity according to risk level, higher security resources (fineer segmentation granularity, faster key updates) are allocated to high-risk scenarios, achieving an optimal balance between security and transmission efficiency.

[0070] Response data: refers to the vehicle control commands and status feedback generated by the internal algorithm of the tested autonomous driving system after receiving real-time interactive data, including but not limited to key behavioral data such as braking response time, steering angle, acceleration changes, and warning signal triggering.

[0071] Upon receiving an encrypted scene data fragment, the mobile testing device immediately uses the session key valid within the current session period (this key is synchronously derived locally by the device based on the dynamic key seed issued by the monitoring and scheduling center) to decrypt the data and restore the plaintext scene fragment.

[0072] The simulation engine of the mobile testing equipment parses the segment (e.g., a 0-5 second segment), but does not directly transmit the segment information to the vehicle under test. It strictly follows black-box testing logic, extracting real-time interactive data. For example, the simulation engine feeds parameters such as "vehicle speed 100km / h, distance to the target vehicle 50m, current rainfall intensity 10mm / h" into the autonomous driving system of the vehicle under test in real time through the vehicle's interaction interface (such as the CAN bus). Throughout this process, the vehicle under test is completely unaware of subsequent logic such as "this is a multi-vehicle rear-end collision scenario in heavy rain" and "the rainfall will increase to 15mm / h in 5 seconds."

[0073] The autonomous driving system of the vehicle under test acts as a black box, running its internal control algorithms based on received real-time interactive data and outputting corresponding response data. Mobile testing equipment continuously collects this response data through the vehicle-to-everything (V2X) interface. Typical data includes: control commands such as brake pedal opening and steering wheel angle; system status such as whether forward collision warning (FCW) has been triggered; and timing metrics such as the response time from sensing the braking of the vehicle ahead to the system initiating braking. All this response data is bound to the test session ID and scenario code of this test upon collection and synchronized in real-time to the monitoring platform of the supervisory dispatch center via an HTTPS encrypted link, forming an immutable test process log.

[0074] After the test, the evaluation module built into the mobile testing equipment, pre-installed by the regulator and with its algorithm kernel encrypted and locked, is automatically activated. This module automatically analyzes all collected response data according to the indicators and calculation methods defined in standards (e.g., GB / T 39263-2020). Its evaluation system includes: safety indicators such as Time to Collision (TTC), minimum safe distance, and emergency braking response time; compliance indicators such as lane keeping deviation and traffic sign compliance rate; and comfort indicators such as rate of change of acceleration. A scenario-adaptive dynamic weighting model is used for calculation. For example, for Level 3 extremely dangerous scenarios, the evaluation model automatically assigns higher weights to safety indicators (e.g., safety 0.6, compliance 0.3, comfort 0.1).

[0075] Before generating the final report, the module performs three levels of verification: indicator threshold verification (comparing to national standard limits), data integrity verification (checking data collection rate), and algorithm compliance verification (verifying that the algorithm version has not been tampered with using the regulatory key). Upon successful verification, a standardized test report is generated. This report includes a regulatory traceability area (session ID, standard clause reference), a result details area (raw data summary, non-compliance items), and a digital signature anti-counterfeiting area generated based on device hardware identification and regulatory timestamps. Finally, it is uploaded to the regulatory dispatch center, completing the regulatory closed loop.

[0076] On the monitoring and scheduling center side, the original code and algorithm logic of the evaluation module undergo a complete set of storage encryption algorithms. This process includes not only encrypting the module file itself using a strong encryption algorithm (such as AES-256), but also a crucial digital signature step. The monitoring and scheduling center uses its held monitoring private key to generate a digital signature for the encrypted version of the evaluation module. This signature is strongly associated with the module content; any minor modification to the module data will cause signature verification to fail. The encrypted and signed evaluation module is then downloaded or pre-installed on a designated secure storage area of ​​the mobile testing device via a secure channel. This area is typically a security chip (TPM) bound to the device's main processor or an encrypted eMMC storage partition, with access permissions protected at the hardware level.

[0077] Boot-time verification: Whenever the mobile test device boots up or the evaluation module is invoked, the device firmware first executes a secure boot process. This process uses the public key of the supervisory scheduling center to verify the digital signature of the evaluation module. If the signature is invalid, it indicates that the module has been tampered with, the device will refuse to load the module and trigger a security alarm, while also reporting to the supervisory platform.

[0078] Runtime code protection: When the evaluation module is running, its decrypted code exists only in the processor's protected memory area and is not written to the device's ordinary hard drive in plaintext. This means that even if someone attempts to extract physical memory, it will be difficult to obtain the complete and analyzable algorithm logic.

[0079] Hardware-level locking: Device operating system permissions are strictly limited, and necessary system calls for write or debug operations on the evaluation module's storage area are removed. From a software perspective, there is no way to modify this module.

[0080] Data retrieval command: This refers to the control command automatically generated and issued to the mobile test device by the monitoring and scheduling center after the test session ends. The command contains a unique identifier for this test (such as the test session ID and scenario code) and the type of media to be cleaned up, and is used to trigger the data security cleanup process on the device.

[0081] Cleanup: Specifically refers to a systematic and thorough data destruction process. Its goal is not only to delete file indexes, but also to ensure that the physical media storing the data is overwritten multiple times, so that the residual data cannot be recovered by any technical means.

[0082] Test data related to this test: refers to all data generated and temporarily stored throughout the entire test lifecycle, including but not limited to: decrypted scene data fragments, response data of the system under test, intermediate calculation variables of the simulation engine, and any temporary or log files stored in memory, local hard drive, or offline cache.

[0083] Once the monitoring and scheduling center confirms that the test session has ended (e.g., upon receiving a test completion signal or reaching a preset timeout), it automatically generates a data retrieval instruction. This instruction is a structured security message, the core content of which includes: Test Session ID (e.g., SID20250826001): Precisely locates the current test task that needs to be cleaned up.

[0084] Four-dimensional encoding of scenarios to be recycled: associated with specific test scenarios.

[0085] List of media types to be cleaned: Explicitly specify the storage media that need to be cleaned, such as ["Memory", "Local Storage", "Offline Cache"].

[0086] The instruction is sent from the monitoring and dispatch center to the corresponding mobile test device via an HTTPS encrypted link. The issuance of the instruction is mandatory; the device cannot refuse or ignore it. Upon receiving the instruction, the mobile test device's built-in full-media cleanup module is immediately activated and executes cleanup tasks in a preset sequence: a. Memory Cleanup: The module iterates through all the device's runtime memory space, and uses a scene coding matching algorithm to locate and forcibly release all cached variables, arrays, and data structures (such as temporary objects storing rainstorm parameters and vehicle trajectories) related to the target test session. The released memory addresses are marked as overwriteable to prevent data residue.

[0087] b. Local Storage Cleanup: Scan the device's local hard drive or solid-state storage, locate and delete all temporary files, log files, and configuration caches containing the test session ID. Then, perform a file shredding algorithm on the disk sectors originally occupied by the files (e.g., perform 3 random data overwrites and 1 zero-value fill) to ensure the original data cannot be recovered by professional tools.

[0088] c. Offline cache cleanup: The module checks all removable storage media (such as SD cards and external USB flash drives) and deletes all data files created in the past 4 hours that are related to this test session.

[0089] AI Verification and Regulatory Inspection: After basic cleanup is completed, the device automatically activates the AI ​​residual data intelligent verification module. This module uses a pre-trained deep learning model to scan the device's memory fragments and hidden storage partitions, looking for any fragmented scene parameters that were not cleared by the aforementioned process (e.g., a data fragment of t=25s, vehicle speed 95km / h remaining in a memory block). If residual data is identified (match rate ≥90%), the AI ​​module will automatically trigger a secondary cleanup.

[0090] Finally, the mobile testing device encrypted and uploaded a detailed log of the cleanup operation and an AI verification report to the regulatory dispatch center. The regulatory dispatch center verified the integrity of the data recovery by comparing the report with the original records in the cloud. Only after the verification was passed was the testing task marked as completely completed, forming a secure regulatory loop.

[0091] This step, through a command-based, automated, and intelligent data recycling mechanism, goes beyond simple file deletion. By strengthening data shredding and AI verification, it reduces the risk of data residue to an extremely low level, completely eliminating the possibility of data leakage in test scenarios through data residue. By incorporating the data lifecycle into the regulatory scope, it achieves full-process control from scenario deployment to data destruction, demonstrating the rigor and depth of sandbox regulation. The entire recycling process is proactively triggered by the regulator and automatically executed on the device, reducing human intervention, avoiding the risk of data leakage due to human negligence, and improving regulatory efficiency.

[0092] Figure 2 The diagram illustrates a flowchart of a sandbox depth testing method for vehicles according to an embodiment of this application, applied to the aforementioned testing system. The method includes steps S101-S106; specifically: S101. The monitoring and scheduling center responds to the test scenario input operation, determines the danger level of the test scenario, and sends the test scenario and the corresponding danger level to the cloud-encrypted scenario library. S102. Generate the scenario code of the test scenario through the cloud-based encrypted scenario library and send it to the monitoring and scheduling center; S103. Generate an identity verification request and a scene loading request through the mobile testing device and send them to the monitoring and scheduling center; S104. After identity verification is passed, the monitoring and scheduling center generates a dynamic key seed for scene loading based on the scene code, the danger level and the corresponding dynamic encryption strategy, and sends the dynamic key seed to the mobile testing device and the cloud-based encrypted scene library. S105. The scenario data of the test scenario is split into multiple data segments by the cloud-based encrypted scenario library based on the data segmentation strategy corresponding to the danger level, and the scenario data segments encrypted with the session key are sent to the mobile test device; wherein, the session key is generated by the dynamic key seed; S106. The mobile testing device tests the autonomous driving system of the vehicle under test using the scene fragment data decrypted based on the session key, obtains the response data of the vehicle under test, and generates a standardized test report based on the response data.

[0093] After the test is completed, the monitoring and scheduling center sends a data retrieval command to the mobile test device. The mobile testing equipment is used to clean up the test data related to this test.

[0094] The hazard level of a test scenario is determined using the following methods: The core parameters of the test scenario are analyzed using a preset scenario risk assessment algorithm to calculate its collision risk value; based on the collision risk value, the test scenario is automatically classified into one of several preset danger levels.

[0095] The scene code is generated in the following manner: The real-time geographic location information and component temperature information of the mobile testing device are obtained, and the real-time state factor of the device is calculated. The scenario code is generated based on the timestamp, random hash value, enterprise identifier of the company to which the tested vehicle belongs, and real-time status factor of the equipment.

[0096] The dynamic key seed is generated as follows: upon receiving the scene loading request, a test session is generated; The dynamic key seed is generated based on the test session, the scenario code, the current timestamp, and the danger level.

[0097] The scenario data for the test scenario is split in the following way: The scenario data of the test scenario of the first hazard level is split based on the first time length; The scenario data of the test scenario at the second hazard level is split based on the second time length; wherein the first hazard level is higher than the second hazard level, and the first time length is shorter than the second time length.

[0098] like Figure 3 As shown, this application provides an electronic device for executing the vehicle sandbox depth testing method of this application. The device includes a memory, a processor, a bus, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the vehicle sandbox depth testing method.

[0099] Specifically, the aforementioned memory and processor can be general-purpose memory and processor, without any specific limitations. When the processor runs the computer program stored in the memory, it can execute the aforementioned vehicle sandbox depth testing method.

[0100] Corresponding to the vehicle sandbox depth testing method in this application, this application embodiment also provides a computer storage medium storing a computer program, which is executed by a processor to perform the steps of the above-described vehicle sandbox depth testing method.

[0101] Specifically, the storage medium can be a general-purpose storage medium, such as a removable disk or hard disk. When the computer program on the storage medium is run, it can execute the aforementioned vehicle sandbox depth testing method.

[0102] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interface; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

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

[0104] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0105] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they 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 the prior art, 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, a monitoring and dispatch center, or a 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.

[0106] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0107] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, 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. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A sandbox depth testing system for vehicles, characterized in that, This includes a regulatory dispatch center, mobile testing equipment, a cloud-based encrypted scenario library, and test vehicles equipped with autonomous driving systems; The monitoring and scheduling center is used to respond to the test scenario input operation, determine the danger level of the test scenario, and send the test scenario and the corresponding danger level to the cloud-encrypted scenario library. The cloud-based encrypted scenario library is used to generate scenario codes for the test scenarios and send them to the monitoring and scheduling center. The mobile testing device is used to generate identity verification requests and scene loading requests, and send them to the monitoring and scheduling center. The monitoring and scheduling center is used to generate a dynamic key seed for scenario loading based on the scenario code, the danger level and the corresponding dynamic encryption strategy after the identity verification is passed, and send the dynamic key seed to the mobile testing device and the cloud-based encrypted scenario library. The cloud-based encrypted scenario library is used to split the scenario data of the test scenario based on the data segmentation strategy corresponding to the danger level, obtain multiple data segments, and send the scenario segment data encrypted based on the session key to the mobile test device; wherein, the session key is generated by the dynamic key seed; The mobile testing equipment is used to test the autonomous driving system of the vehicle under test by decrypting the scene fragment data based on the session key, obtain the response data of the vehicle under test, and generate a standardized test report based on the response data.

2. The testing system according to claim 1, characterized in that, After the test is completed, the monitoring and scheduling center is used to send a data retrieval instruction to the mobile test device; The mobile testing device is used to clean up the test data related to this test.

3. The testing system according to claim 1, characterized in that, The monitoring and dispatch center determines the danger level of the test scenario through the following methods: The core parameters of the test scenario are analyzed using a pre-defined scenario risk assessment algorithm to calculate its collision risk value. Based on the collision risk value, the test scenario is automatically classified into one of several preset danger levels.

4. The testing system according to claim 1, characterized in that, The cloud-based encrypted scene library generates the scene code in the following way: The real-time geographic location information and component temperature information of the mobile testing device are obtained, and the real-time state factor of the device is calculated. The scenario code is generated based on the timestamp, random hash value, enterprise identifier of the company to which the tested vehicle belongs, and real-time status factor of the equipment.

5. The testing system according to claim 1, characterized in that, The monitoring and scheduling center generates the dynamic key seed in the following manner: Upon receiving the scene loading request, a test session is generated; The dynamic key seed is generated based on the test session, the scenario code, the current timestamp, and the danger level.

6. The testing system according to claim 1, characterized in that, The cloud-based encrypted scenario library splits the scenario data of the test scenario in the following way: The scenario data of the test scenario of the first hazard level is split based on the first time length; The scenario data of the test scenario at the second hazard level is split based on the second time length; wherein the first hazard level is higher than the second hazard level, and the first time length is shorter than the second time length.

7. The testing system according to claim 1, characterized in that, The mobile testing device includes an evaluation module; the evaluation module is encrypted by a storage encryption algorithm preset by the monitoring and scheduling center and then stored in the mobile testing device; wherein the storage encryption algorithm cannot be modified locally.

8. A method for testing the sandbox depth of a vehicle, characterized in that, The test method, applied to the test system according to any one of claims 1 to 7, comprises: The monitoring and scheduling center responds to the test scenario input operation, determines the danger level of the test scenario, and sends the test scenario and the corresponding danger level to the cloud-encrypted scenario library. The test scenario's scenario code is generated through the cloud-based encrypted scenario library and sent to the monitoring and scheduling center. The mobile testing device generates an identity verification request and a scene loading request, which are then sent to the monitoring and scheduling center. After identity verification is passed, the monitoring and scheduling center generates a dynamic key seed for scene loading based on the scene code, the danger level and the corresponding dynamic encryption strategy, and sends the dynamic key seed to the mobile testing device and the cloud-based encrypted scene library. The cloud-based encrypted scenario library splits the scenario data of the test scenario into multiple data segments based on the data segmentation strategy corresponding to the danger level, and sends the scenario segment data encrypted with a session key to the mobile test device; wherein, the session key is generated by the dynamic key seed; The mobile testing device tests the autonomous driving system of the vehicle under test using the scene fragment data decrypted based on the session key, obtains the response data of the vehicle under test, and generates a standardized test report based on the response data.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine instructions that the processor executes. When the electronic device is running, the processor communicates with the memory via the bus. When the machine instructions are executed by the processor, the steps of the sandbox depth testing method for a vehicle as described in claim 8 are performed.

10. A computer storage medium, characterized in that, The computer storage medium stores a computer program that, when executed by a processor, performs the steps of the sandbox depth testing method for a vehicle as described in claim 8.

Images