A container-based distributed clouded unmanned system

Abstract

The application discloses a kind of container-based distributed cloud unmanned system, comprising: vehicle information upload module, with the signal connection of vehicle information upload module distributed sensing information receiving module, with the signal connection of distributed sensing information receiving module message general control, with the signal connection of message general control distributed trajectory control module and multiple algorithm modules, with the signal connection of multiple algorithm modules message confirmation module and with the signal connection of distributed trajectory control module car end control quantity receiving module;Distributed trajectory control module, message general control, message confirmation module, multiple algorithm modules and distributed sensing information receiving module are all in the network environment of cloud end.According to the application, data storage security can be supported \ high availability and data sharing collaboration under scalability.

Description

Technical Field

[0001] This invention relates to the field of autonomous driving technology, and in particular to a container-based distributed cloud-based autonomous driving system. Background Technology

[0002] Before large-scale deployment and operation, autonomous driving systems must combine multi-vehicle intelligence with single-vehicle intelligence. However, under the current vehicle-side deployment setup, data sharing and collaboration are difficult, hindering macro-level control. Furthermore, vehicles are vulnerable to hacking attacks, leading to the loss of stored private information, which is detrimental to single-vehicle intelligence. Moreover, the limited computing resources of vehicles restrict the real-time performance of tasks such as decision-making and control, thus inhibiting single-vehicle intelligence. Therefore, adopting a container-based distributed cloud-based autonomous driving system has become a necessary foundation for the development of autonomous driving systems. In summary, existing vehicle-side autonomous driving systems have the following shortcomings:

[0003] 1. Limited computing resources

[0004] In the current deployment of autonomous vehicles, these vehicles integrate perception, decision-making, and control, and have high requirements for real-time performance. However, the limitations of onboard computing resources inevitably lead to resource contention, causing process waiting and increasing latency, thus creating a performance bottleneck for various tasks.

[0005] 2. Data security gaps

[0006] In existing autonomous vehicle deployments, critical privacy information is stored in the onboard industrial control computer's memory or written directly to the disk. However, under the influence of hacker attacks or physical factors, memory corruption or disk damage can cause the autonomous driving system controller to fail to retrieve information, leading to process crashes.

[0007] 3. Inability to achieve data sharing and collaboration

[0008] In existing autonomous vehicle deployments, the vehicle itself establishes a local area network. Information between autonomous driving system processes is transmitted via User Datagram Protocol (UDP) or Inter-Process Communication (IPC). However, multi-vehicle intelligence requires a data hub to issue control commands to the vehicles, enabling data sharing and collaboration among them. Summary of the Invention

[0009] To address the shortcomings of existing technologies, the present invention aims to provide a container-based distributed cloud-based autonomous driving system that supports data sharing and collaboration under conditions of data storage security, high availability, and scalability. To achieve the above-mentioned objectives and other advantages of the present invention, a container-based distributed cloud-based autonomous driving system is provided, comprising:

[0010] The system includes a vehicle information uploading module, a distributed sensing information receiving module connected to the vehicle information uploading module, a message control module connected to the distributed sensing information receiving module, a distributed trajectory control module connected to the message control module, a multi-algorithm module, a message confirmation module connected to the multi-algorithm module, and a vehicle-end control quantity receiving module connected to the distributed trajectory control module.

[0011] The distributed trajectory control module, message control module, message confirmation module, multiple algorithm modules, and distributed sensing information receiving module are all located in a cloud-based network environment.

[0012] The vehicle information upload module is used to receive perceived information through sensors and transmit it to the cloud.

[0013] The distributed perception information receiving module is used to receive perception information from autonomous vehicles. By deploying it in a distributed container, scheduling and load balancing can be achieved, alleviating the pressure of high concurrency.

[0014] The message master controller is responsible for decoupling and asynchronously completing message passing;

[0015] The message confirmation module is used to prevent system crashes or message transmission channel storms caused by duplicate message consumption.

[0016] Multiple algorithm modules have been improved from the original vehicle-side algorithm responsible for single-vehicle intelligence to a multi-vehicle intelligence algorithm based on multi-vehicle data. The cloud system has given each algorithm the ability to share data collaboratively.

[0017] The distributed trajectory control module is used to transmit vehicle control quantities to each autonomous vehicle to obtain cooperative control capabilities.

[0018] The vehicle-side control quantity receiving module is used to obtain the vehicle control quantities that the vehicle ultimately needs to execute from the cloud to complete the actual road driving process.

[0019] Preferably, the message master control uses the built-in publish-subscribe message transmission mode of the Redis cluster, which includes the following steps: messages generated by various algorithm modules are published to the Redis cluster in the form of binary serialized information. The Redis cluster forwards the message according to the channel into which the published message is passed, so that all modules subscribed to the channel can obtain the message.

[0020] Preferably, the message confirmation module utilizes a MongoDB cluster to offload the load from the Redis cluster. The specific steps include: introducing the binary serialized message into the MongoDB cluster for message registration and generating a record; the MongoDB engine setting a TTL index for this record; the message waiting to be verified by the corresponding algorithm; if an algorithm initiates the message verification mechanism, the MongoDB engine atomically checks the existence of the message record and deletes it; if the operation is successful, it returns a success flag for the corresponding algorithm; otherwise, it returns a failure flag. If no algorithm initiates the message verification mechanism, it proceeds to the next step; it determines whether the record has reached the expiration time set by the TTL index; if so, the record is deleted; otherwise, it returns to the message verification judgment step.

[0021] Preferably, the distributed trajectory control module includes two stages: message reception and message processing. The message reception stage includes the following steps: the binary serialized message is obtained by the algorithm module by subscribing to a Redis channel; each distributed sub-algorithm verifies the message and sends a command to the message confirmation module before proceeding to the next step; the message reception module waits for the return from the message confirmation module. If the return fails, the message is discarded and the process ends; otherwise, the message is passed to the distributed message processing module.

[0022] Preferably, the message processing stage includes the following steps: the message is load-balanced through a K8S Service and distributed to one of the processing programs; the processing program processes the message and generates the final control quantity, which is then sent to the vehicle-side control quantity receiving module.

[0023] Compared with existing technologies, the advantages of this invention are as follows: It implements independent algorithm modules, a message control component, and a message acknowledgment component based on distributed container deployment, ensuring data storage security, high availability, and scalability. It implements an asynchronous, decoupled publish-subscribe message transmission mechanism based on Redis, ensuring low transmission latency, high module scalability, and high system concurrency. It implements a transmission method based on binary serialization and deserialization, ensuring data transmission security. It implements a message acknowledgment mechanism based on MongoDB, using atomic operations to ensure that the message acknowledgment process is not interrupted, while also distributing the load on the Redis message control cluster. Attached Figure Description

[0024] Figure 1 This is a block diagram of a container-based distributed cloud-based autonomous driving system according to the present invention;

[0025] Figure 2 A schematic diagram of the distributed perception information receiving module of the container-based distributed cloud-based unmanned driving system according to the present invention;

[0026] Figure 3This is a schematic diagram of the message control system for a container-based distributed cloud-based autonomous driving system according to the present invention.

[0027] Figure 4 A schematic diagram of the message confirmation module of the container-based distributed cloud-based autonomous driving system according to the present invention;

[0028] Figure 5 This is a schematic diagram of the distributed trajectory control module of the container-based distributed cloud-based unmanned driving system according to the present invention. Detailed Implementation

[0029] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0030] Reference Figure 1-5 A container-based distributed cloud-based autonomous driving system includes: a vehicle information uploading module, a distributed perception information receiving module connected to the vehicle information uploading module, a message control module connected to the distributed perception information receiving module, a distributed trajectory control module and multiple algorithm modules connected to the message control module, a message confirmation module connected to the multiple algorithm modules, and a vehicle-end control quantity receiving module connected to the distributed trajectory control module.

[0031] The distributed trajectory control module, message control module, message confirmation module, multiple algorithm modules, and distributed sensing information receiving module are all located in a cloud-based network environment.

[0032] The vehicle information upload module is used to receive perceived information through sensors and transmit it to the cloud.

[0033] The distributed perception information receiving module is used to receive perception information from autonomous vehicles. By deploying it in a distributed container, scheduling and load balancing can be achieved, alleviating the pressure of high concurrency.

[0034] The message master controller is responsible for decoupling and asynchronously completing message transmission. It is the hub of the entire cloud message transmission and has high availability and high scalability.

[0035] The message confirmation module is used to prevent system crashes or message transmission channel storms caused by duplicate message consumption.

[0036] Multiple algorithm modules have been improved from the original vehicle-side algorithm responsible for single-vehicle intelligence to a multi-vehicle intelligence algorithm based on multi-vehicle data. The cloud system has given each algorithm the ability to share data collaboratively.

[0037] The distributed trajectory control module is used to transmit vehicle control quantities to each autonomous vehicle to obtain cooperative control capabilities.

[0038] The vehicle-side control quantity receiving module is used to obtain the vehicle control quantities that the vehicle ultimately needs to execute from the cloud to complete the actual road driving process.

[0039] like Figure 2 As shown, the distributed perception information receiving module uses Kubernetes (K8S) for load balancing. Large-scale deployment of autonomous vehicles inevitably leads to high concurrency pressure. Load balancing effectively alleviates this pressure, providing a foundation for system stability.

[0040] Specifically, the distributed sensing information receiving module is implemented as follows:

[0041] First, the perception information of multiple vehicles is transmitted from the vehicle to the K8S Service via RESTful API or GRPC. This component autonomously performs load balancing and distributes the vehicle perception information to one of the next steps.

[0042] Next, the sensed information is processed by the sensed signal receiving program to generate the sensed message required for cloud transmission, and then published to the corresponding message channel in the cloud. Before being published to the message channel, the message is first transmitted to the message confirmation module for message registration. Before being published to the message channel, the message content is processed using binary serialization to ensure secure information transmission.

[0043] like Figure 3 As shown, the message control system uses a Redis cluster. Redis comes with a publish-subscribe message transmission mode, facilitating the asynchronous and decoupled operation of the entire message transmission system and flexible expansion of algorithm modules. Redis itself is an in-memory database, ensuring low latency and providing a functional foundation for the real-time performance requirements of autonomous driving. The Redis cluster has a disaster recovery mechanism, maintaining high availability, making it suitable as the message transmission hub for the entire cloud-based system.

[0044] Specifically, the message master control is implemented as follows:

[0045] First, the messages generated by each algorithm are published to the Redis cluster in the form of binary serialized information;

[0046] Next, the Redis cluster forwards the message according to the channel through which it was published, so that all modules subscribed to that channel can obtain the message.

[0047] like Figure 4As shown, the message confirmation module uses a MongoDB cluster. The MongoDB cluster can share the load of the Redis cluster, further ensuring high availability. MongoDB itself has atomic checks and record deletion functions to ensure that the message verification process is not interrupted, thus guaranteeing the uniqueness of message consumption. MongoDB comes with a TTL index, which allows setting the message expiration time, ensuring that MongoDB storage capacity will not increase indefinitely.

[0048] Specifically, the message confirmation module is implemented as follows:

[0049] First, the binary serialized message is introduced into the MongoDB cluster for message registration, generating records;

[0050] Next, the MongoDB engine sets a TTL index for the record and proceeds to the next step;

[0051] Next, the message waits to be verified by the corresponding algorithm. If an algorithm has started the message verification mechanism, the MongoDB engine atomically checks the existence of the message record and deletes it. If the operation is successful, it returns a success flag for the corresponding algorithm; otherwise, it returns a failure flag for the corresponding algorithm. If no algorithm has started the message verification mechanism, it proceeds to the next step.

[0052] Finally, determine if the record has reached the expiration time set by the TTL index. If so, delete the record; otherwise, return to the message verification and judgment step.

[0053] like Figure 5 As shown, the distributed trajectory control module adopts a two-stage approach: message reception and message processing. Both stages utilize a distributed architecture to ensure load balancing and high availability.

[0054] Specifically, the message receiving phase of the distributed trajectory control module is implemented as follows:

[0055] First, the binary serialized message is obtained by the algorithm module by subscribing to a Redis channel, and then proceeds to the next step;

[0056] Next, each distributed sub-algorithm performs message verification, sends a command to the message confirmation module, and then proceeds to the next step.

[0057] Next, the message receiving module waits for the message confirmation module to return. If the return fails, the message is discarded and the process ends; otherwise, the message is passed to the distributed message processing module.

[0058] Specifically, the message processing phase of the distributed trajectory control module is implemented as follows:

[0059] First, the message is load-balanced through a Kubernetes Service and distributed to one of the handlers.

[0060] Next, the program processes the message and generates the final control quantity, which is then sent to the vehicle-side control quantity receiving module.

[0061] A detailed diagram of the message processing phase of the distributed trajectory control module is shown below. Figure 2 The difference is that the distributed trajectory control module, as the final output of the cloud, will directly transmit the control quantity to the vehicle, instead of sending it to the cloud.

[0062] In the overall architecture of this invention, the distributed perception information receiving module, message control module, message confirmation module, other algorithm modules, and distributed trajectory control module are all located in the cloud network environment. The message transmission between the vehicle-side perception information uploading module and the distributed perception information receiving module, and the message transmission between the distributed trajectory control module and the vehicle-side control quantity receiving module, use network tunneling technology to embed into the cloud network to further enhance message transmission security, while forming isolation to prevent network fluctuations from directly affecting vehicle-side behavior.

[0063] The number of devices and processing scale described herein are for the purpose of simplifying the description of the invention, and applications, modifications and variations thereof will be apparent to those skilled in the art.

[0064] Although embodiments of the present invention have been disclosed above, they are not limited to the applications listed in the specification and embodiments. They can be applied to various fields suitable for the present invention. For those skilled in the art, other modifications can be easily made. Therefore, without departing from the general concept defined by the claims and their equivalents, the present invention is not limited to the specific details and illustrations shown and described herein.

Claims

1. A container-based distributed cloud-based autonomous driving system, characterized in that, include: The system includes a vehicle information uploading module, a distributed sensing information receiving module connected to the vehicle information uploading module, a message control module connected to the distributed sensing information receiving module, a distributed trajectory control module connected to the message control module, a multi-algorithm module, a message confirmation module connected to the multi-algorithm module, and a vehicle-end control quantity receiving module connected to the distributed trajectory control module. The distributed trajectory control module, message control module, message confirmation module, multiple algorithm modules, and distributed sensing information receiving module are all located in a cloud-based network environment. The vehicle information upload module is used to receive perceived information through sensors and transmit it to the cloud. The distributed perception information receiving module is used to receive perception information from autonomous vehicles. By deploying it in a distributed container, scheduling and load balancing can be achieved, alleviating the pressure of high concurrency. The message master controller is responsible for decoupling and asynchronously completing message passing; The message control module utilizes the built-in publish-subscribe message transmission mode of the Redis cluster, which includes the following steps: Messages generated by various algorithm modules are published to the Redis cluster in binary serialized form. The Redis cluster forwards the messages according to the channel through which they are sent, ensuring that all modules subscribed to that channel can obtain the message. The message confirmation module uses a MongoDB cluster to share the load of the Redis cluster. Its specific steps include: registering the binary serialized message with the MongoDB cluster and generating a record; setting a TTL index for the record in the MongoDB engine; waiting for the message to be verified by the corresponding algorithm. If an algorithm initiates the message verification mechanism, the MongoDB engine atomically checks the existence of the message record and deletes it. If the operation is successful, it returns a success flag for the corresponding algorithm; otherwise, it returns a failure flag. If no algorithm initiates the message verification mechanism, it proceeds to the next step; it checks whether the record has reached the expiration time set by the TTL index. If so, the record is deleted; otherwise, it returns to the message verification judgment step. The message confirmation module is used to prevent system crashes or message transmission channel storms caused by duplicate message consumption. Multiple algorithm modules have been improved from the original vehicle-side algorithm responsible for single-vehicle intelligence to a multi-vehicle intelligence algorithm based on multi-vehicle data. The cloud system has given each algorithm the ability to share data collaboratively. The distributed trajectory control module is used to transmit vehicle control quantities to each autonomous vehicle to obtain cooperative control capabilities. The vehicle-side control quantity receiving module is used to obtain the vehicle control quantities that the vehicle ultimately needs to execute from the cloud to complete the actual road driving process.

2. The container-based distributed cloud-based autonomous driving system as described in claim 1, characterized in that, The distributed trajectory control module consists of two phases: message reception and message processing. The message reception phase includes the following steps: binary serialized messages are obtained by the algorithm module by subscribing to a Redis channel; each distributed sub-algorithm verifies the message and sends a command to the message confirmation module before proceeding to the next step; the message reception module waits for the return from the message confirmation module. If the return fails, the message is discarded and the process ends; otherwise, the message is passed to the distributed message processing module.

3. The container-based distributed cloud-based autonomous driving system as described in claim 2, characterized in that, The message processing phase includes the following steps: the message is load-balanced through a K8S Service and distributed to one of the processing programs; the processing program processes the message and generates the final control quantity, which is then sent to the vehicle-side control quantity receiving module.

Images