An autonomous driving simulation test system and device

Abstract

This invention relates to the field of autonomous driving technology and discloses an autonomous driving simulation testing system and equipment. The system allows end-users to configure an interface that sends simulation tasks with target scenarios to a central scheduler and visualizes the process. The central scheduler receives the simulation tasks and, via a message middleware, sends them to distributed simulation computing nodes, building a global task scheduling engine to automate the entire testing process. The message middleware uses an asynchronous communication mechanism to provide message transmission channels. The terminal scene database writes the entire simulation task process data and encrypts scene resources from a cloud data management platform. After confirming receipt of the simulation task via a vehicle-to-everything (V2X) interaction module, the distributed simulation computing nodes retrieve the corresponding target scenario data from the terminal scene database, call the simulation engine to load the target scenario, and execute it. This invention solves the technical problems of insufficient flexibility and scalability, chaotic scene management, low automation, and weak security in existing systems.

Description

Technical Field

[0001] This invention relates to the field of autonomous driving technology, and more specifically to an autonomous driving simulation testing system and equipment. Background Technology

[0002] With the rapid development of Advanced Driver Assistance Systems (ADAS) technology, functional safety, scenario coverage, and testing efficiency have become core industry demands. ADAS systems need to verify the effectiveness of their algorithms in a vast number of complex scenarios, but physical testing is limited by cost, time, and safety, making it difficult to cover critical testing needs such as extreme conditions and long-tail scenarios. Therefore, sandbox simulation testing has become a core part of ADAS R&D.

[0003] However, existing ADAS sandbox simulation systems have significant drawbacks in terms of flexibility, scalability, scene management, data efficiency, process automation, and security, failing to meet the requirements for high reliability and high accuracy testing. The specific problems and causes are as follows:

[0004] Insufficient flexibility and scalability: The existing system has weak adaptability to multiple simulation engines (such as VTD and Carla), and switching engines requires refactoring the core code; module function expansion relies on hard-coded modifications, and adding new test scenario types or hardware terminals (such as tablets) requires large-scale adjustments to the system logic. The existing system adopts a monolithic architecture or a tightly coupled design, with components directly relying on hard-coded calls, lacking a standardized interface abstraction layer, and deeply binding business logic to specific engine APIs and hardware interfaces, resulting in a domino effect when expanding.

[0005] The management of scenarios is chaotic: there is no traceability mechanism for scenario versions, making it difficult to roll back to previous versions after modifications, and version conflicts are prone to occur in different testing phases; multi-terminal scenario push relies on manual operation, resulting in resource synchronization delays and inconsistent performance; scenario resources are easily tampered with or leaked, and intellectual property protection is weak. There is a lack of a standardized scenario version management system, and version control concepts have not been introduced; scenario push is not centrally managed in the cloud, and the transmission process is not encrypted; the industry has not yet established unified standards for scenario resource security management.

[0006] The process suffers from low automation: after simulation, data needs to be manually exported and evaluation software called, resulting in a very high percentage of time spent on manual operations per test; evaluation reports rely on manual compilation, are prone to errors, and are difficult to generate in batches, failing to meet the needs of large-scale regression testing. The interface between the simulation and evaluation modules is not standardized, lacking an automated triggering mechanism; the entire process lacks a unified scheduling logic, with each step relying on manual coordination.

[0007] Weak security: Scene resources are transmitted and stored in plaintext, making them vulnerable to unauthorized copying or tampering; the intellectual property rights of core test scenes are at risk of leakage. No scene resource encryption mechanism has been established, and access control is lacking in the transmission and storage stages; insufficient attention is paid to the security protection of scene resources, making rapid traceability impossible. Summary of the Invention

[0008] The present invention aims to provide an autonomous driving simulation testing system and equipment to solve the technical problems of insufficient flexibility and scalability, chaotic scene management, low degree of process automation, and weak security of existing ADAS sandbox simulation systems.

[0009] The basic solution provided by this invention is: an autonomous driving simulation test system, including a terminal that is different from a cloud server and distributed simulation computing nodes;

[0010] The terminal deployment includes a user configuration interface, a central scheduling program, a message middleware, a vehicle-to-everything (V2X) interaction module, and a terminal scenario database.

[0011] The user configuration interface is used to send simulation tasks with target scenarios to the central scheduler and to receive and visualize the simulation process results.

[0012] The central scheduler receives and distributes simulation tasks to the distributed simulation computing nodes that have been configured with the terminals via the message middleware. It also builds a global task scheduling engine to automate the entire simulation testing process, including scene loading, simulation running, data storage, evaluation triggering, report generation, and front-end visualization. The configuration includes determining the simulation engine pre-deployed on the distributed simulation computing node as the simulation engine used for this simulation task.

[0013] Message middleware is used to provide a message passing channel, including task assignment, status synchronization, and result feedback, using an asynchronous communication mechanism.

[0014] The terminal scenario database is used for writing data throughout the entire simulation task process; it is also used to encrypt and obtain scenario resources from the cloud data management platform, which serves as a centralized storage and traceability management platform for scenario resources throughout their entire lifecycle.

[0015] The distributed simulation computing node is used to retrieve the corresponding data of the target scene from the terminal scene database after confirming receipt of the simulation task through a pre-deployed or vehicle-to-everything (V2X) interaction module pushed from the terminal, call the pre-deployed simulation engine to load the target scene to perform a complete simulation calculation, and write the simulation results into the terminal scene database.

[0016] The present invention also provides an autonomous driving simulation test system and device for executing / utilizing an autonomous driving simulation test system and device, including a memory and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors to operate an autonomous driving simulation test system.

[0017] The working principle and advantages of this invention are as follows:

[0018] This invention breaks through the inherent architecture of traditional centralized cloud simulation platforms, constructing a distributed, high-concurrency, cloud-collaborative, and dynamically responsive simulation task scheduling and execution network. By integrating the user configuration interface, central scheduler, message middleware, vehicle-to-everything (V2X) interaction module, and terminal scene database onto the terminal, and coordinating with distributed simulation computing nodes, a highly cohesive and loosely coupled autonomous driving simulation testing system is formed. On the terminal side, the central scheduler uniformly schedules and drives task distribution, engine invocation, data storage, evaluation triggering, and visualization, achieving closed-loop automation of the entire simulation task process. This avoids the problems of fragmented multiple systems and frequent manual intervention in traditional solutions, improving testing efficiency. Simulation task execution and result feedback are performed on distributed computing nodes, achieving decentralized computing and enabling the system to scale elastically, supporting the simultaneous deployment of tens of thousands of simulation tasks on distributed computing nodes. This high deployment flexibility solves the performance bottleneck problem of a single cloud server. Simultaneously, the terminal scene database serves as both a local execution cache on the terminal and an encrypted link with the cloud platform, ensuring both data security and resource reuse. Combined with the asynchronous mechanism provided by the message middleware, reliable communication and state synchronization under high-concurrency tasks are guaranteed. This architecture significantly improves testing efficiency, traceability, and deployment flexibility, providing a low-cost, highly consistent, standardized simulation environment for the verification of algorithms such as AEB and LKA.

[0019] At the level of process automation, a global task scheduling engine is built through the terminal center scheduler Simulation, which integrates the entire process of scenario loading, simulation execution, result evaluation and even report generation into an automated workflow. This achieves end-to-end automated processing from task issuance to final visualization, greatly reducing manual intervention and significantly improving testing efficiency and the reliability of results.

[0020] In terms of system flexibility and scalability, 1) through the collaborative design of terminals and distributed nodes, elastic allocation and efficient utilization of computing resources are achieved; 2) the central scheduling program Simulation integrated on the terminal side and the message middleware Kafka together constitute the intelligent hub of the system, which not only realizes the dynamic scheduling of simulation tasks, but also enables the system to flexibly adapt to multiple simulation engines through the gRPC and Protobuf standardized interface design of the vehicle-to-everything (V2X) interaction module Carlink. This effectively solves the problems of poor scalability and long adaptation cycle caused by the tight coupling of software and hardware in traditional systems. By shielding the differences in engine APIs such as VTD and Carlink at the IEngineAdapter abstract layer, multiple engines can be flexibly adapted. Adding a new engine only requires developing an adaptation plugin, while traditional systems require modification of the core logic. The adaptation cycle is shortened from 2 weeks to 1-2 days; 3) the asynchronous communication mechanism based on the message middleware Kafka completely decouples the front end, the central scheduling program Simulation, the V2X interaction module Carlink, and the evaluation algorithm, avoiding direct dependence and achieving flexible expansion.

[0021] In terms of scene data management, 1) a two-tier architecture of unified cloud management and local terminal storage is adopted, which not only realizes centralized control and consistency of scene versions, but also ensures the integrity and timeliness of scene data in a distributed environment through encrypted retrieval and incremental synchronization mechanisms, providing reliable data support for high-frequency iterative development and solving the problems of multi-terminal synchronization latency and poor consistency; 2) The terminal scene database adopts the non-relational document database MongoDB, which builds a version chain based on SHA-256 hash and version tags (v1, v2, etc.), supports scene rollback (such as rolling back from v3 to v2), realizes fine-grained version management of scenes, and solves the problems of chaotic traditional scene management and non-rollback of versions; 3) An event-driven push mechanism is introduced into the terminal scene database to realize automatic push updates, reducing the push latency from hours in traditional manual operation to seconds, and ensuring the consistency of scene resources across all terminals through terminal consistency verification.

[0022] In terms of security, 1) from the encrypted distribution of cloud-based scenario resources and the identity authentication of terminal access, to the data return communication and secure storage during the simulation process, a multi-layered security strategy ensures the security and privacy of test assets; 2) a protection system that runs through the entire data flow cycle has been built. Through customer identifier salt value embedding and multi-layer encryption, accurate traceability and security protection of scenario resources are achieved, traceability accuracy is improved, and traceability time is shortened from several days to minutes, solving the problem that traditional systems cannot achieve accurate traceability.

[0023] In summary, the system's comprehensive advantages in flexibility, intelligent management, full-process automation, and all-round safety enable it to better meet the complex needs of rapid iteration and large-scale testing in modern autonomous driving systems. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the structure of an autonomous driving simulation test system provided in an embodiment of the present invention;

[0025] Figure 2 This is a flowchart illustrating an execution method for an autonomous driving simulation testing system provided in an embodiment of the present invention. Detailed Implementation

[0026] The following detailed explanation illustrates the specific implementation methods:

[0027] The basic implementation examples are as follows: Figure 1 and Figure 2 As shown: An autonomous driving simulation testing system includes a terminal, which is distinct from a cloud server, and distributed simulation computing nodes;

[0028] The terminal deployment includes a user configuration interface, a central scheduling program, a message middleware, a vehicle-to-everything (V2X) interaction module, and a terminal scenario database.

[0029] The user configuration interface is used to send simulation tasks with target scenarios to the central scheduler and to receive and visualize the simulation process results.

[0030] The central scheduler receives and distributes simulation tasks to the distributed simulation computing nodes that have been configured with the terminals via the message middleware. It also builds a global task scheduling engine to automate the entire simulation testing process, including scene loading, simulation execution, data storage, evaluation triggering, report generation, and front-end visualization. The configuration includes determining the simulation engine pre-deployed on the distributed simulation computing node as the simulation engine used for this simulation task.

[0031] Message middleware is used to provide a message passing channel, including task assignment, status synchronization, and result feedback, using an asynchronous communication mechanism.

[0032] The terminal scenario database is used for writing data throughout the entire simulation task process; it is also used to encrypt and obtain scenario resources from the cloud data management platform, which serves as a centralized storage and traceability management platform for scenario resources throughout their entire lifecycle.

[0033] The distributed simulation computing node is used to retrieve the corresponding data of the target scene from the terminal scene database after confirming receipt of the simulation task through a pre-deployed or vehicle-to-everything (V2X) interaction module pushed from the terminal, call the pre-deployed simulation engine to load the target scene to perform a complete simulation calculation, and write the simulation results into the terminal scene database.

[0034] Specifically:

[0035] This system adopts a layered architecture design. Simulation tasks are built on the terminal and then distributed to distributed simulation computing nodes through four core components deployed on the terminal: a central scheduler (Simulation), a vehicle-to-everything (Carlink) module, a message middleware (Kafka), and a data management platform (MongoDB). This forms a closed-loop system architecture of "decision-execution-communication-storage-display".

[0036] In practical applications: the terminal can be any tablet computer. The distributed simulation computing node can be any client simulation computer.

[0037] The central scheduler (Simulation) uses Java 18, Spring Boot 3.1, and QuartzScheduler as its technology stack. It employs a fully automated scheduling mechanism, building a global task scheduling engine based on Quartz Scheduler. The entire simulation testing process is broken down into automatically executable nodes (scenario loading → simulation execution → data storage → evaluation triggering → report generation), resulting in fully automated simulation execution. From front-end task submission to report generation, the entire process is driven by the Quartz scheduling engine and Kafka events, eliminating the need for manual data export or evaluation triggering, significantly reducing manual intervention and improving testing efficiency.

[0038] The message queue middleware (Kafka) uses Kafka message queue technology to process data streams and reduce direct coupling between systems. Specifically, it uses Kafka 3.4 + AVRO serialization for message delivery. Through Kafka's asynchronous communication mechanism, the frontend, Simulation, Carlink, and evaluation algorithm are completely decoupled, avoiding direct dependencies and enabling flexible expansion.

[0039] The Carlink vehicle-to-everything (V2X) module uses C++20, gRPC, and Protobuf as its technology stack and is responsible for interacting with Simulation. This module employs the gRPC framework and defines standardized communication interfaces based on the Protobuf protocol to adapt to multiple simulation engines such as VTD and Carla. Upgrading a single module or adding a new engine requires no modification to the logic of other components, enabling flexible expansion.

[0040] In practical applications, the terminal stores the Carlink vehicle connectivity module. Before the central scheduler Simulation issues simulation tasks, it checks whether the distributed simulation computing nodes have deployed the Carlink vehicle connectivity module. If not, the terminal's Carlink vehicle connectivity module is pushed to the distributed simulation computing nodes for installation (specifically, the Carlink program package is pushed via SSH). If it has already been deployed, no push is needed, ensuring that the distributed simulation computing nodes have the Carlink vehicle connectivity module deployed to accurately execute the corresponding functions in the subsequent simulation execution process.

[0041] The terminal scene database (MongoDB) uses a non-relational document database, such as MongoDB 6.0. Scene resources are uniformly pushed to the terminal through the scene library in the cloud data management platform and stored in the terminal scene database. All scenes are encrypted and will be retrieved and used by the distributed simulation computing nodes during the simulation execution process.

[0042] The main execution process of this system is as follows:

[0043] Before the simulation begins, the terminal and distributed simulation nodes are configured. This configuration includes determining the pre-deployed simulation engine on each distributed simulation computing node as the simulation engine to be used in this simulation task, such as VTD or CarLink. It also includes configuring the simulation node's IP address, username, and password to facilitate pushing CarLink packages via SSH.

[0044] 1. Scene selection and task creation

[0045] Users select the scenario to simulate in the front-end UI (user configuration interface). The scenario includes preset parameters (such as rainfall of 50mm / h and visibility of 200m), lane parameters (such as 3 lanes and a speed limit of 120km / h), and information such as the trajectory of vehicles changing lanes suddenly. Then, a task is created, and the front-end encapsulates the task data into JSON, as shown in the example below:

[0046] {

[0047] "taskId": "ADAS-Task-20250710-001",

[0048] "sceneId": "Scene-Rain-Collision-002",

[0049] "testFunctions": ["AEB", "LKA"],

[0050] "vehicleType": "SUV",

[0051] "sensors": ["LiDAR", "MillimeterWaveRadar"],

[0052] "repeatCount": 3,

[0053] "createTime": "2025-07-10T09:30:00Z",

[0054] "userId": "Tester-001"

[0055] }

[0056] The task data in JSON format is sent to the backend Simulation module via an HTTP POST request. The frontend displays "Task submitted" and waits for the backend to send back confirmation that "Task has been received" before sending back "Task has entered the queue".

[0057] It should be noted that the simulation scenarios actually executed can only be those stored in the terminal scenario database. If the planned simulation scenario is not stored in the terminal scenario database but in the cloud, the cloud data management platform will push the planned simulation scenario to the terminal. At this time, the terminal will receive an update prompt message. After clicking to confirm the update, the pushed scenario will be updated on the terminal, and then the scenario selection and subsequent simulation can be performed.

[0058] 2. Task scheduling and message passing

[0059] After a front-end task is submitted, feedback is sent to Simulation. Upon receiving a new simulation task, Simulation persists the simulation task information to the "task_queue" collection in the terminal scenario database MongoDB and adds it to the task queue via QuartzScheduler. Simulation monitors the task queue and, at an appropriate time (after detecting a ready task in the queue), encapsulates the simulation task information into a message (TaskMessage) and publishes it to a predefined task message queue. This allows distributed simulation computing nodes to asynchronously subscribe to and execute the message, i.e., by sending the message to the specified "task-topic" via Kafka Producer. This method enables asynchronous distribution of simulation tasks to task topics through message middleware, allowing multiple distributed simulation computing nodes to pull and execute tasks in parallel, achieving load balancing and high-availability scheduling. The message uses AVRO serialization format and includes the task ID, scenario ID, execution priority (high), and data retrieval address, as shown in the example below.

[0060] {

[0061] "taskId": "ADAS-Task-20250710-001",

[0062] "sceneId": "Scene-Rain-Collision-002",

[0063] "priority": "high",

[0064] "dataSource": "MongoDB: / / db-server / scene_data / Scene-Rain-Collision-002",

[0065] "timestamp": 1688962200000

[0066] }

[0067] The distributed simulation computing nodes are pre-deployed or pushed from the terminal. The Carlink deployed on the distributed simulation computing nodes acts as a Kafka Consumer to listen to the "task-topic". After receiving the message, it sends a confirmation to the Simulation module via the gRPC interface that "the task has been received".

[0068] 3. Scene data loading and simulation execution

[0069] Upon receiving the message, the Carlink node in the distributed simulation computing node pulls the corresponding data for the target scene from the "scene_data" collection in the terminal scene database MongoDB, and calls its pre-deployed simulation engine to load the scene and execute the simulation. During the process, the Carlink node monitors the simulation progress and transmits the monitoring data back to Simulation in real time via Kafka. Simulation then transmits the data back to the front-end user configuration interface to display the simulation process with a progress bar and event logs.

[0070] 4. Data storage and evaluation execution

[0071] After the simulation is completed, the CarLink distributed simulation computing nodes write all simulation result data (such as AEB, LKA steering angle, etc.) into the terminal scene database MongoDB for storage.

[0072] The simulation calls the evaluation software and reads the simulation results from the terminal scene database MongoDB. Then, it executes the evaluation algorithm to extract indicators (such as AEB indicator, minimum braking distance, number of triggers and LKA indicator, lane departure correction magnitude, steering wheel angle change rate, etc.) for evaluation, and automatically generates evaluation results and evaluation reports. After the evaluation is completed, the evaluation results are written back to the terminal scene database MongoDB in JSON format.

[0073] After detecting the evaluation results, Simulation updates the task status to "Completed" and sends the data back to the front-end user configuration interface for display. The user selects a task on the front-end page, which then requests the Simulation service's API. Simulation retrieves the result data from MongoDB, processes it, and returns it to the front-end page in JSON format. The front-end page displays the simulation and evaluation results in charts, tables, and other formats, as shown in the example below:

[0074] {

[0075] "taskId": "ADAS-Task-20250710-001",

[0076] "aebResults": {

[0077] "responseTime": [0.42, 0.45, 0.43],

[0078] "brakeDistance": [62, 58, 65],

[0079] "falseTrigger": 0

[0080] },

[0081] "lkaResults": {

[0082] "deviationCorrection": [0.3, 0.2, 0.4],

[0083] "steeringRate": [4.2, 3.8, 4.5]

[0084] },

[0085] "passStatus": "pass"

[0086] }

[0087] In practical applications, the terminal scene database solves the scene management problem: It leverages MongoDB's `scene_versions` collection to build a complete version record. Each scene version (v1, v2, etc.) is linked by `versionId`, `parentVersion`, and `versionHash`, with the `parentVersion` field precisely pointing to the parent version (e.g., v3's `parentVersion` is v2), fully recording the entire lifecycle of the scene from creation to iteration. Through MongoDB's `$graphLookup` aggregation query, it's possible to trace back to the initial version (v1) based on any version tag (e.g., v5), clearly presenting the time of each modification, the modifier, and the changed content (stored in the `changeLog` field), achieving visualized tracing of the version trajectory.

[0088] When a rollback to a historical version is required, the system implements the following process: Based on the target version tag (e.g., v2), the system queries the corresponding versionHash and file storage path in the scene_versions collection; it calls MongoDB's GridFS interface to read the encrypted scene file for that version, and then decrypts it using the key management service to reconstruct the complete scene; the rollback operation generates a new version record (e.g., v6), with its parentVersion set to v2 and changeLog marked as "rollback to v2," preserving the traceability of the rollback operation while avoiding disruption of the original version chain; and it prevents conflicts through MongoDB's unique indexes and transaction mechanisms by creating a composite unique index {sceneId: 1, versionId: 1} in the scene_versions collection, ensuring that only one record exists for the same version tag in the same scene, avoiding duplicate creation.

[0089] In practical applications, the synergy between the terminal scenario database and the cloud data management platform also enables centralized cloud control and automatic push notifications. Through MongoDB centralized storage and an event-driven push mechanism, it solves the problems of multi-terminal synchronization latency and poor consistency: Global resources are managed uniformly, with all scenario versions centrally stored in a cloud-based MongoDB cluster. A globally unique index is built using sceneId and versionId, ensuring that all terminals access the same data source and eliminating version inconsistencies caused by traditional manual push notifications. Simultaneously, an event-driven push trigger mechanism is introduced: when a new version is released in the cloud (status: "released"), the terminal's MongoDB change stream captures update events in the scene_versions collection in real time. After receiving and confirming the update message, the terminal automatically triggers the cloud data management platform to push incremental updates (transmitting only the differences from the previous version) to the associated terminal tablet via a TLS 1.3 encrypted channel, avoiding the latency of full file transfers and reducing push latency from hours to seconds in traditional manual operations. Terminal consistency verification: after receiving incremental updates, the terminal verifies file integrity through hash comparison and automatically completes missing versions, ensuring resource consistency across all terminals.

[0090] In practical applications, the synergy between the terminal scenario database and the cloud data management platform also solves the security problem: all scenario resources are stored in encrypted form in the cloud, and the process of pushing them to the terminal adopts an encrypted transmission protocol. That is, the terminal (such as a tablet) receives scenario resources uniformly pushed through the cloud platform scenario library, and all scenarios are encrypted.

[0091] In the scenario file encryption system, a customer identifier salt value embedding mechanism is introduced to achieve accurate tracing after scenario leakage: For different customers (such as Changan Automobile, identified as CHxxx), the system automatically generates a unique salt value bound to the customer's unique identifier before encrypting the scenario file.

[0092] The salt value employs a composite structure of "customer ID + device fingerprint + random number" (e.g., CH001-HW202305-7a3f9d), hashed using the HMAC-SHA256 algorithm to generate a fixed-length 256-bit salt value. During encryption, the salt value and the scene file content are encrypted together using the AES-256-CBC algorithm (the salt value is part of the initialization vector IV), and an 8-byte feature identifier of the salt value is reserved in the header of the encrypted file (not a complete salt value, used only for traceability verification). When a suspected leaked scene file is discovered, the salt value feature identifier in the header of the encrypted file is extracted and compared with the customer salt value feature database stored in the system to quickly locate the corresponding customer identifier (e.g., matching the feature code segment of customer CHxxx). Combined with file metadata, the scope is further narrowed down to specific authorized devices or users, realizing a three-level traceability closed loop of "customer-device-user". The salt value is only used in the encryption process and is not stored directly in plaintext in the file. Furthermore, the feature identifier is anonymized (excluding complete customer information), thus avoiding the risk of encryption cracking due to salt value leakage and ensuring the accuracy of tracing. By embedding customer identifier salt values ​​and using multi-layered encryption, precise tracing and security protection of scenario resources are achieved, improving tracing accuracy. This mechanism reduces the time for tracing leaked scenario files from several days in traditional solutions to minutes, without increasing encryption time, thus solving the problem of traditional systems being unable to achieve precise tracing.

[0093] This embodiment also provides an electronic device, including a memory and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors to operate an autonomous driving simulation test system.

[0094] This embodiment provides an autonomous driving simulation testing system and equipment. By integrating a user configuration interface, a central scheduler, a message middleware, a vehicle-to-everything (V2X) interaction module, and a terminal scene database into the terminal, and coordinating with distributed simulation computing nodes, a highly cohesive and loosely coupled autonomous driving simulation testing system is constructed. The system achieves closed-loop automation of the entire simulation task process on the terminal side. From task issuance, engine invocation, data storage to evaluation triggering and visualization, everything is driven by a unified scheduling engine, avoiding the problems of fragmented multiple systems and frequent manual intervention in traditional solutions. Simultaneously, the terminal scene database serves as both a local execution cache and an encrypted link with the cloud platform, ensuring both data security and resource reuse. Combined with asynchronous message middleware, reliable communication and state synchronization are guaranteed under high-concurrency tasks. This architecture significantly improves testing efficiency, traceability, and deployment flexibility, providing a low-cost, highly consistent, standardized simulation environment for the verification of algorithms such as AEB and LKA.

[0095] The above descriptions are merely embodiments of the present invention. Commonly known structures and characteristics of the solutions are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are aware of all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can, under the guidance of this application, improve and implement this solution in combination with their own capabilities. Some typical known structures or methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention. These should also be considered within the scope of protection of the present invention, and will not affect the effectiveness of the implementation of the present invention or the practicality of the patent.

Claims

1. An autonomous driving simulation testing system, characterized in that, This includes terminals and distributed simulation computing nodes, which are distinct from cloud servers; The terminal deployment includes a user configuration interface, a central scheduling program, a message middleware, a vehicle-to-everything (V2X) interaction module, and a terminal scenario database. The user configuration interface is used to send simulation tasks with target scenarios to the central scheduler and to receive and visualize the simulation process results. The central scheduler receives and distributes simulation tasks to the distributed simulation computing nodes that have been configured with the terminals via the message middleware. It also builds a global task scheduling engine to automate the entire simulation testing process, including scene loading, simulation running, data storage, evaluation triggering, report generation, and front-end visualization. The configuration includes determining the simulation engine pre-deployed on the distributed simulation computing node as the simulation engine used for this simulation task. Message middleware is used to provide a message passing channel, including task assignment, status synchronization, and result feedback, using an asynchronous communication mechanism. The terminal scenario database is used for writing data throughout the entire simulation task process; it is also used to encrypt and obtain scenario resources from the cloud data management platform, which serves as a centralized storage and traceability management platform for scenario resources throughout their entire lifecycle. The distributed simulation computing node is used to retrieve the corresponding data of the target scene from the terminal scene database after confirming that the simulation task has been received through the vehicle-to-everything (V2X) interaction module that is pre-deployed or pushed from the terminal, call the pre-deployed simulation engine to load the target scene to perform a complete simulation calculation, and write the simulation results into the terminal scene database. The terminal and cloud data management platform adopts a two-tier architecture of unified cloud control and local terminal storage in terms of scenario data management.

2. The autonomous driving simulation testing system according to claim 1, characterized in that, The central scheduler builds a global task scheduling engine based on Quartz Scheduler. After receiving a new simulation task, the central scheduler writes the simulation task information into the terminal scene database and adds it to the task queue through Quartz Scheduler. At the same time, it monitors the task queue and, after detecting that there is a ready task in the queue, encapsulates the simulation task information into a message and publishes it to a preset task message queue for distributed simulation computing nodes to subscribe to and execute asynchronously.

3. The autonomous driving simulation testing system according to claim 1, characterized in that, The central scheduler is used to obtain simulation results from the terminal scene database, retrieve the evaluation algorithm to perform evaluation, write the evaluation results into the terminal scene database, and update the task status and send it back to the user configuration interface for visualization.

4. The autonomous driving simulation testing system according to claim 1, characterized in that, The message middleware builds a message queue based on Kafka and uses the AVRO serialization protocol to serialize and deserialize the transmitted messages.

5. The autonomous driving simulation testing system according to claim 1, characterized in that, The vehicle connectivity module adopts the gRPC framework and defines a standardized communication interface based on the Protobuf protocol to adapt to various simulation engines.

6. The autonomous driving simulation testing system according to claim 1, characterized in that, The vehicle-to-everything (V2X) interaction module, which is pre-deployed on the distributed simulation computing nodes or pushed from the terminal, is also used to monitor the simulation progress and transmit the monitoring data back to the central scheduling program in real time through the message middleware. The central scheduling program then transmits the data back to the user configuration interface for visualization.

7. The autonomous driving simulation testing system according to claim 1, characterized in that, The terminal scenario database adopts a non-relational document database. It uses its scenario version set to build a full record of versions to achieve visual traceability of the version chain. In the rollback operation, it generates new version records and builds a new version chain with the target query version tag.

8. The autonomous driving simulation testing system according to claim 1, characterized in that, All scene resources are encrypted and stored on a cloud-based data management platform. A customer identifier salt value embedding mechanism is introduced into the scene file encryption system to enable traceability after scene leakage. The salt value only participates in the calculation during the encryption process and does not participate in the storage.

9. The autonomous driving simulation testing system according to claim 1, characterized in that, An event-driven push triggering mechanism is introduced into the terminal scenario database. When a new version of the cloud scenario is released, the change stream of the terminal scenario database captures the update event in real time. After confirmation, it automatically triggers the cloud data management platform to push incremental updates to the terminal through an encrypted channel.

10. An autonomous driving simulation testing device, characterized in that, It includes a memory and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors to perform the functions of an autonomous driving simulation test system according to any one of claims 1-9.

Images