Vehicle cloud communication method and system, electronic equipment and computer readable storage medium

Abstract

The embodiment of the invention provides a vehicle cloud communication method and system, electronic equipment and a computer readable storage medium, relates to the field of communication, and is applied to a vehicle cloud communication system.The method comprises the steps that target information and the priority of the target information are determined; sending a target processing request to a receiving module; the target processing request comprises a vehicle identifier and a priority of the target vehicle; if the number of the received requests in the preset time period does not exceed a preset number threshold value, receiving a target processing request, and sending the target processing request to message middleware; determining a target theme corresponding to the target processing request according to the priority, determining a target partition according to the vehicle identifier, and storing the processing request to the target partition of the target theme; and obtaining a target processing request from the target partition of the target theme, and processing the target processing request based on the load. According to the invention, the overload risk of the system is reduced, stable transmission is ensured, and the transmission of other requests is prevented from being blocked when the request with heavy load is processed.

Description

Technical Field

[0001] The present application relates to the field of communication technology. Specifically, the present application relates to a vehicle-cloud communication method, system, electronic device and computer-readable storage medium. Background Art

[0002] In vehicle-to-cloud communication, the stability of message transmission is crucial. In the traditional vehicle-to-cloud communication mode, there are some limitations. Especially in high-concurrency scenarios, the processing module on the cloud platform may be paralyzed due to instantaneous high load, making it impossible to process all requests and causing message loss. Therefore, there is a risk of cloud platform overload, unstable message transmission, and blocking of other message transmissions. Summary of the invention

[0003] The embodiments of the present application provide a vehicle-cloud communication method, system, electronic device and computer-readable storage medium, which are used to solve the problems of cloud platform overload risk, unstable message transmission and blocking of other message transmissions.

[0004] According to a first aspect of an embodiment of the present application, a vehicle-cloud communication method is provided, which is applied to a vehicle-cloud communication system, wherein the vehicle-cloud communication system includes: an on-board terminal of a target vehicle and a cloud platform, wherein the cloud platform includes: a receiving module, a Kafka message middleware and a processing module, and the method includes: The vehicle-mounted terminal determines the target information and the priority of the target information; The vehicle terminal sends a target processing request to the receiving module; the target processing request includes a vehicle identification and a priority of the target vehicle; When the receiving module determines that the number of received requests within the preset time period does not exceed the preset number threshold, the target processing request is received and sent to the Kafka message middleware; The Kafka message middleware determines the target topic corresponding to the target processing request based on the priority, determines the target partition based on the vehicle identification, and stores the processing request in the target partition of the target topic; The processing module that subscribes to the target topic and is assigned a target partition obtains a target processing request from the target partition of the target topic, and processes the target processing request based on the current load of the vehicle-cloud communication system.

[0005] In a possible implementation, the processing module collects current performance indicators of the vehicle-cloud communication system; the performance indicators are used to characterize the current load conditions; The processing module determines the target number of service instances currently required based on performance indicators and preset scaling strategies; The processing module evenly distributes processing requests to the target number of service instances for processing.

[0006] In another possible implementation, the processing module sends a get request to the Kafka message middleware; the get request is used to request to obtain a new processing request; The Kafka messaging middleware determines the topics to which the processing module has subscribed and the partitions in each topic that are assigned to the processing module; For each subscribed topic, the Kafka message middleware determines whether there are unprocessed processing requests in each partition based on the offset of each partition stored; the offset is used to record the position of the processing request that has been processed by the processing module in the partition; When the Kafka message middleware determines that there are unprocessed processing requests in at least one partition, it sends the unprocessed processing requests to the processing module.

[0007] In yet another possible implementation, if the processing module successfully processes the target processing request, the current offset is sent to the Kafka message middleware; If the processing module fails to process the target processing request, the target processing request is processed again; If the number of times the processing module fails to process the target processing request is greater than the preset failure threshold, the target processing request is sent to the dead letter queue and the current offset is sent to the Kafka message middleware; the dead letter queue is used to store requests that cannot be processed; The Kafka message middleware updates the stored offset of the target partition of the target topic to the current offset.

[0008] In yet another possible implementation, the vehicle terminal defines a processing request as a target transmission quality level according to the MQTT protocol; The vehicle terminal sends a target processing request to the receiving module based on the target transmission quality level.

[0009] In another possible implementation, the Kafka message middleware includes multiple topics, each topic includes multiple partitions, and each partition pulls and processes requests according to its corresponding queue strategy; A queue strategy includes at least one of the following: Pull processing requests in the order they first entered the partition; Pull requests are processed in the order they last entered the partition.

[0010] In yet another possible implementation, the target processing request is processed, the processing module determines a processing result, and generates a control instruction according to the processing result; The processing module sends an instruction message to the Kafka message middleware; the instruction message is used to instruct the Kafka message middleware to store the control instruction in the first topic subscribed by the vehicle terminal; The Kafka message middleware determines the first partition in the first topic allocated to the vehicle terminal, and stores the control instruction in the first partition of the first topic; The vehicle-mounted terminal obtains the control instruction from the first partition of the first topic through the receiving module, and performs corresponding operations according to the control instruction.

[0011] In another possible implementation, The processing request also includes target information, which is at least one type of sub-information related to the target vehicle and the environment in which the target vehicle is located: Vehicle operation status sub-information; Environmental information; Vehicle failure information; Vehicle location information; Processing of the request, followed by: The processing module determines the category of each sub-information in the target information; For each type of sub-information, the processing module stores the sub-information in a storage area corresponding to the category. In another possible implementation, the information is stored in a storage area corresponding to the category, and the processing module updates the model set according to the stored sub-information; A model set includes at least one of the following: Prediction model: The prediction model is used to predict whether the target vehicle has a problem based on the vehicle operation status information; Obstacle avoidance model: The obstacle avoidance model is used to determine the obstacle avoidance route of the target vehicle based on environmental information; Path planning model: The path planning model is used to determine the driving path of the target vehicle based on the vehicle position information and environmental information.

[0012] In another possible implementation, the target vehicle is a plurality of vehicles, and the processing module determines the driving priority corresponding to each vehicle according to the acquired vehicle operation status information of each vehicle; The processing module processes the processing request corresponding to each vehicle based on the driving priority of each vehicle.

[0013] In yet another possible implementation, the vehicle-mounted terminal obtains sensor information; the sensor information is obtained by a sensor installed on the target vehicle; The vehicle-mounted terminal determines the target information based on the preset algorithm and sensor information.

[0014] In yet another possible implementation, the target processing request includes at least one of the following: Path planning request; Scheduling requests; Environmental testing requests; Fault detection request.

[0015] According to a second aspect of an embodiment of the present application, a vehicle-cloud communication system is provided, wherein communication information includes: an on-board terminal of a target vehicle and a cloud platform, the cloud platform includes: a receiving module, a Kafka message middleware, and a processing module; The vehicle-mounted terminal is used to determine target information and the priority of target information; The vehicle-mounted terminal is used to send a target processing request to the receiving module; the target processing request includes a vehicle identification and a priority of the target vehicle; A receiving module is used to receive a target processing request when determining that the number of received requests within a preset time period does not exceed a preset number threshold, and send the target processing request to the Kafka message middleware; Kafka message middleware is used to determine the target topic corresponding to the target processing request according to the priority. Kafka message middleware determines the target partition according to the vehicle identification and stores the processing request in the target partition of the target topic; The processing module is used to obtain the target processing request from the target partition of the target topic and process the target processing request based on the current load of the vehicle-cloud communication system.

[0016] According to a third aspect of an embodiment of the present application, an electronic device is provided, which includes a memory, a processor, and a computer program stored in the memory, and when the processor executes the program, the steps of the method provided in the first aspect are implemented.

[0017] According to a fourth aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the method provided in the first aspect are implemented.

[0018] According to the fifth aspect of the embodiment of the present application, a computer program product is provided, which includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. When a processor of a computer device reads the computer instructions from the computer-readable storage medium, the processor executes the computer instructions, so that the computer device executes the steps of implementing the method provided in the first aspect.

[0019] The beneficial effects of the technical solution provided by the embodiment of the present application are: The vehicle-to-cloud communication method applied to the vehicle-to-cloud communication system provided in the embodiment of the present application determines the priority of the target information after determining the target information through the vehicle-mounted terminal, and then sends a target processing request including the target vehicle identification and priority to the receiving module. The receiving module will receive the target processing request only when it determines that the number of requests received within the preset time period does not exceed the preset number threshold, and send the target processing request to the Kafka message middleware. The Kafka message middleware determines the target topic corresponding to the target processing request based on the priority and the target partition determined based on the vehicle identification, thereby storing the target processing request in the target partition of the target topic, so that the processing module that subscribes to the target topic and is assigned the target partition can obtain the processing request from the target partition of the target topic, and then processes the processing request based on the current load of the vehicle-to-cloud communication system. This application performs flow control on received requests through the receiving module, ensuring that the request rate entering the processing module is controllable, effectively avoiding overload of the processing module, thereby improving the responsiveness and reliability of the processing module. The target processing request is placed in the target topic and target partition corresponding to the Kafka message middleware through the receiving module, avoiding overload caused by directly sending the request to the processing module, reducing the risk of overload, ensuring stable transmission of requests, and also avoiding blocking the transmission of other requests for time-consuming processing. The processing module processes the target processing request according to the load of the current vehicle-cloud communication system, maintaining efficient operation of the system without wasting processing resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in describing the embodiments of the present application are briefly introduced below.

[0021] Figure 1 A schematic diagram of the system architecture for implementing a vehicle-to-cloud communication method provided in an embodiment of the present application; Figure 2 A flow chart of a vehicle-to-cloud communication method applied to a vehicle-to-cloud communication system provided in an embodiment of the present application; Figure 3 A schematic diagram of the architecture of a vehicle-to-cloud communication system provided in an embodiment of the present application; Figure 4 A schematic diagram of a process for obtaining a target processing request in a vehicle-to-cloud communication method provided in an embodiment of the present application; Figure 5 A flowchart of a method for updating an offset in a vehicle-to-cloud communication method provided in an embodiment of the present application; Figure 6 A flowchart of a method for sending a control instruction in a vehicle-to-cloud communication method provided in an embodiment of the present application; Figure 7A schematic diagram of the interaction process between a mining vehicle and a cloud platform to perform a vehicle-cloud communication method provided in an embodiment of the present application; Figure 8 A schematic diagram of the structure of a vehicle-to-cloud communication system provided in an embodiment of the present application; Fig. 9 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0022] The embodiments of the present application are described below in conjunction with the drawings in the present application. It should be understood that the implementation methods described below in conjunction with the drawings are exemplary descriptions for explaining the technical solutions of the embodiments of the present application and do not constitute a limitation on the technical solutions of the embodiments of the present application.

[0023] It will be understood by those skilled in the art that, unless specifically stated, the singular forms "one", "an" and "the" used herein may also include plural forms. It should be further understood that the terms "including" and "comprising" used in the embodiments of the present application refer to that the corresponding features can be implemented as the presented features, information, data, steps, operations, elements and / or components, but do not exclude the implementation as other features, information, data, steps, operations, elements, components and / or combinations thereof supported by the technical field. It should be understood that when we call an element "connected" or "coupled" to another element, the one element can be directly connected or coupled to the other element, or it can refer to that the one element and the other element establish a connection relationship through an intermediate element. In addition, the "connection" or "coupling" used here may include wireless connection or wireless coupling. The term "and / or" used here indicates at least one of the items defined by the term, for example, "A and / or B" can be implemented as "A", or as "B", or as "A and B".

[0024] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0025] The following is an explanation of the terms and related technologies involved in this application: Spring Cloud Stream: is a framework for building event-driven microservices that allows developers to access external messaging systems such as RabbitMQ and Kafka through messaging. It provides simple APIs and configuration options to facilitate the sending and receiving of messages, and supports the binding and management of multiple transport middleware.

[0026] Kafka: is a distributed stream processing platform, which is similar to a message queue or enterprise messaging system. Producers in Kafka can send messages to Kafka topics, and multiple consumers subscribing to Kafka topics can read these messages simultaneously under certain configurations.

[0027] The following describes several exemplary embodiments to illustrate the technical solutions of the embodiments of the present application and the technical effects produced by the technical solutions of the present application. It should be noted that the following embodiments can refer to, draw on or combine with each other, and the same terms, similar features and similar implementation steps in different embodiments will not be described repeatedly.

[0028] Figure 1 A schematic diagram of the system architecture for implementing the vehicle-cloud communication method provided in an embodiment of the present application, wherein the system architecture includes: a vehicle-mounted terminal 120 and a cloud platform 140, and the cloud platform includes: a receiving module 140-1, a Kafka message middleware 140-2 and a processing module 140-3.

[0029] The vehicle-mounted terminal 120 installs and runs an application program having a vehicle-cloud communication method, and the vehicle-mounted terminal 120 is used to send a target processing request to the receiving module 140 - 1 of the cloud platform.

[0030] The vehicle terminal 120 is connected to the cloud platform 140 via a wireless network or a wired network.

[0031] The cloud platform 140 includes at least one of a server, multiple servers, a cloud computing platform, and a virtualization center. The cloud platform 140 is used to provide background services for the application of the vehicle-cloud communication method. Optionally, the cloud platform 140 undertakes the main computing work, and the vehicle terminal 120 undertakes the secondary computing work; or, the cloud platform 140 undertakes the secondary computing work, and the vehicle terminal 120 undertakes the main computing work; or, the cloud platform 140 and the vehicle terminal 120 adopt a distributed computing architecture for collaborative computing.

[0032] Those skilled in the art will appreciate that the number of the vehicle-mounted terminals may be more or less. For example, the terminal may be only one, or the terminal may be dozens or hundreds, or more. The embodiment of the present application does not limit the number and device type of the terminals.

[0033] The embodiment of the present application provides a vehicle-cloud communication method, which is applied to a vehicle-cloud communication system. The vehicle-cloud communication system includes: an on-board terminal of a target vehicle and a cloud platform. The cloud platform includes: a receiving module, a Kafka message middleware and a processing module. The specific process is as follows Figure 2 As shown, the method includes: S101, the vehicle-mounted terminal determines target information and the priority of the target information.

[0034] In the embodiment of the present application, the vehicle-to-cloud communication system implementing the embodiment of the present application is as follows: Figure 3 As shown, it includes a vehicle-mounted terminal 310 and a cloud platform 311, and the cloud platform is composed of a receiving module 311-1, a Kafka message middleware 311-2 and a processing module 311-3, wherein the vehicle-mounted terminal is connected to the receiving module of the cloud platform through the MQTT protocol; the receiving module is composed of the Spring Cloud Stream framework, which serves as an intermediary for information transmission, receives information transmitted by the vehicle-mounted terminal through MQTT, and pushes the received information to the Kafka message middleware; the Kafka message middleware is used to provide high-throughput message queue services, support multiple consumers to process information in parallel, receive information from the receiving module, and transmit the information to the processing module; the processing module is used to process the information and provide it to the corresponding service, and obtain the information to be processed from the Kafka message middleware.

[0035] It should be noted that the framework for building the receiving module includes but is not limited to the Spring Cloud Stream framework. The specific framework to be used to build the receiving module can be selected based on the specific usage scenarios and usage requirements of the vehicle-cloud communication method provided in this application.

[0036] In the embodiment of the present application, the target vehicle refers to a vehicle having an on-board terminal installed inside, which can interact with the cloud platform. The target vehicle can be a mining car, a smart car, an autonomous driving vehicle, or other vehicle.

[0037] In an embodiment of the present application, the target information is determined by the vehicle-mounted terminal. The target information may be any information related to the target vehicle. The target information may be vehicle location and navigation information, such as positioning information, route planning, and historical trajectory; the target information may also be vehicle status information, such as engine status, fuel consumption information, tire pressure, vehicle speed, and temperature; the target information may also be vehicle safety information, such as collision information and door and window information.

[0038] In one example, the target information may be information related to the target vehicle, such as the current location of the target vehicle, the current driving direction of the target vehicle, and the vehicle operating status of the target vehicle. The target information may be information related to the environment in which the vehicle is located, such as the environment around the target vehicle and whether there are obstacles around the target vehicle.

[0039] In the embodiment of the present application, the type of target information can be determined based on the currently acquired target information, and the target information can be divided into emergency alarm information, real-time status update information, and non-emergency information. For example, if the target information is fault reporting information, the target information can be defined as emergency alarm information; if the target information is driving direction information, the target information can be defined as real-time status update information; if the target information is regularly reported status information, the information can be defined as non-emergency information. By setting different priorities for different types of data, it can be ensured that important information that needs to be processed quickly can be processed first.

[0040] In an embodiment of the present application, the vehicle terminal determines the target information based on the currently collected information, determines the type of the target information based on the pre-defined relationship between each target information and the type, and finally determines the priority of the target information based on the correspondence between the pre-defined type and priority.

[0041] S102, the vehicle-mounted terminal sends a target processing request to the receiving module.

[0042] In an embodiment of the present application, the target processing request includes a vehicle identification and a priority of the target vehicle, and the target processing request is used to request processing of the target information.

[0043] In an embodiment of the present application, the target processing request generated by the vehicle-mounted terminal can be used to request planning of the driving path of the target vehicle based on the target information, can also be used to request generation of scheduling instructions for the target vehicle based on the target information, and can also be used to request detection and analysis of the environment around the target vehicle based on the target information.

[0044] In an embodiment of the present application, the vehicle terminal generates a target processing request including a vehicle identification and a priority through the MQTT client, and then sends the target processing request to the receiving module through the MQTT protocol.

[0045] In the embodiment of the present application, the vehicle identification refers to an identification composed of at least one symbol, letter, or number, and the vehicle identification is used to identify different vehicles. In other words, the vehicle identification is proof of the vehicle's identity, and each vehicle has its corresponding and unique vehicle identification. The vehicle identification cloud platform can conveniently process and manage the relevant information of each vehicle.

[0046] S103, when the receiving module determines that the number of received requests within the preset time period does not exceed the preset number threshold, it receives the target processing request and sends the target processing request to the Kafka message middleware.

[0047] In an embodiment of the present application, the receiving module pre-configures the maximum request rate through FlowLimiter, that is, the preset number threshold of requests received within a preset time period, for example, a maximum of 10 processing requests are received per second. The maximum request rate can be dynamically adjusted according to the traffic conditions. By setting the maximum request rate, it can be ensured that the request rate entering the processing module is controllable, effectively avoiding overload of the processing module, thereby improving the responsiveness and reliability of the entire system.

[0048] In an embodiment of the present application, after detecting the target processing request sent by the vehicle-mounted terminal, the receiving module will determine the number of requests that have been received within a preset time period. If the number of requests that have been received does not exceed the preset number threshold, it means that the current request rate is not large and throttling is not required. Therefore, the target processing request is received and sent to the Kafka message middleware.

[0049] In an example, the maximum request rate set according to the current traffic conditions is to receive 10 requests per second. After the receiving module detects the target processing request sent by the vehicle-mounted terminal, if it is determined that 8 requests have been received within one second, the maximum request rate has not been exceeded and the target processing request can be received; if it is determined that 11 requests have been received within one second, the maximum request rate has been exceeded, and the target processing request will be received with a delay.

[0050] In an embodiment of the present application, the receiving module can be a module based on the Spring Cloud Stream framework. The receiving module utilizes the asynchronous processing capabilities of Spring Cloud Stream to significantly shorten the response time when processing time-consuming requests, and can greatly improve the user experience under high traffic and high load conditions. Thanks to the decoupling characteristics of Spring Cloud Stream, the maintenance cost of the cloud platform when replacing or upgrading the message queue will also be reduced, allowing the development and operation and maintenance teams to respond to technological changes more quickly.

[0051] In an embodiment of the present application, the Kafka message middleware serves as a buffer layer, that is, a cache layer before the processing request enters the processing module, to avoid directly sending the request to the processing module and causing the processing module to overload. Subsequently, the Kafka message middleware is responsible for pushing the received target processing request to the processing module.

[0052] S104, Kafka message middleware determines the target topic corresponding to the target processing request according to the priority, determines the target partition according to the vehicle identification, and stores the processing request in the target partition of the target topic. In the embodiment of the present application, Kafka message middleware includes multiple topics. Consumers obtain processing requests from the subscribed topics by subscribing to the topics of Kafka message middleware. Different topics can be used for processing requests of different priorities. Therefore, different topics corresponding to different processing priorities are pre-defined, and then consumers with higher processing efficiency are allowed to subscribe to topics with higher priorities, thereby ensuring that processing requests with higher priorities will be processed first.

[0053] In the embodiment of the present application, since the target processing request includes a priority, the Kafka message middleware can determine the target topic corresponding to the target processing request according to the priority.

[0054] In an embodiment of the present application, each topic can be composed of one or more partitions, each partition is an ordered, immutable message sequence. Dividing multiple partitions in the same topic can ensure that multiple consumers subscribed to the same topic can consume the messages in the topic at the same time. In order to ensure that the same request is consumed only once, the Kafka message middleware will evenly distribute multiple partitions in the same topic to each consumer who has subscribed to the topic.

[0055] In an embodiment of the present application, the Kafka message middleware pre-stores the correspondence between the vehicle identification and the partition. Therefore, the target partition corresponding to the target processing request can be determined according to the vehicle identification. The target partition is determined by the vehicle identification, thereby ensuring that processing requests with the same source will be sent to the same partition, thereby facilitating consumption by consumers.

[0056] In an embodiment of the present application, after determining the target topic and the target partition in the target topic corresponding to the target processing request, the target processing request is stored in the target partition of the target topic. When a consumer who subscribes to the target topic and is assigned the target partition sends a get request, the target processing request is sent to the consumer.

[0057] S105, the processing module that subscribes to the target topic and is assigned the target partition obtains the target processing request from the target partition of the target topic, and processes the target processing request based on the current load of the vehicle-cloud communication system.

[0058] In an embodiment of the present application, the processing service of the cloud platform can be set as a consumer group, and each processing module in the consumer group is equivalent to a consumer. Consumers who subscribe to the Kafka message middleware topic can obtain pending processing requests, that is, the processing module can obtain new processing requests from the subscribed specific topic for processing.

[0059] In an embodiment of the present application, since there may be multiple consumers subscribing to the same topic and each topic is composed of multiple partitions, in order to ensure that each consumer can process at the same time and does not process the same request, the processing module can only obtain the target processing request from the assigned partition in the subscribed topic.

[0060] In an embodiment of the present application, after the processing module obtains the target processing request from the target partition of the target topic, the processing module dynamically adjusts the processing rate based on the real-time load of the current system, and processes the target processing request according to the adjusted processing rate to ensure stable processing.

[0061] The vehicle-to-cloud communication method applied to the vehicle-to-cloud communication system provided in the embodiment of the present application determines the priority of the target information based on the type of the target information after the on-board terminal determines the target information, and then sends a target processing request including the target vehicle identification, target information and priority to the receiving module. The receiving module will receive the target processing request only when it determines that the number of requests received within the preset time period does not exceed the preset number threshold, and send the target processing request to the Kafka message middleware. The Kafka message middleware determines the target topic corresponding to the target processing request based on the priority and the target partition determined based on the vehicle identification, thereby storing the target processing request in the target partition of the target topic, so that the processing module that subscribes to the target topic and is assigned the target partition can obtain the processing request from the target partition of the target topic, and then processes the processing request based on the current load of the vehicle-to-cloud communication system. This application performs flow control on received requests through the receiving module, ensuring that the request rate entering the processing module is controllable, effectively avoiding overload of the processing module, thereby improving the responsiveness and reliability of the processing module. The receiving module places the target processing request in the target topic and target partition corresponding to the Kafka message middleware, avoiding overload caused by directly sending the request to the processing module, reducing the risk of overload of the processing module, ensuring stable transmission of requests, and also avoiding blocking the transmission of other requests for time-consuming processing. The processing module processes the target processing request according to the load of the current vehicle-cloud communication system, maintaining efficient operation of the system without wasting processing resources.

[0062] Based on the above embodiments, as an optional embodiment, the processing module collects the current performance indicators of the vehicle-cloud communication system; the performance indicators are used to characterize the current load conditions; the processing module determines the target number of service instances currently required based on the performance indicators and preset scaling strategies; the processing module evenly distributes the processing requests to the target number of service instances for processing.

[0063] In the embodiment of the present application, tools Prometheus and Grafana are used to monitor the CPU, memory, network bandwidth and other performance indicators of the processing module of the cloud platform in real time, and the current load of the processing module is determined according to each performance indicator.

[0064] In an embodiment of the present application, container orchestration tools such as Kubernetes can be used to automatically adjust the number of service instances in the processing module according to the current load conditions. The service instances are used to process the requests obtained by the processing module. When the load is high, the number of service instances can be increased to meet the needs of high concurrent requests. When the load is low, processing resources can be saved by reducing the number of service instances.

[0065] In an embodiment of the present application, the preset scaling strategy is used to define the number of service instances under different load conditions. For example, according to the performance indicators, it can be concluded that the current load is high and high-concurrency requests need to be processed. The corresponding target number of service instances is 10. According to the performance indicators, the current traffic is at a low point, so the corresponding target number of service instances is 4. In other words, the greater the current workload and the greater the request volume, the more service instances are required, and vice versa.

[0066] In an embodiment of the present application, after determining the target number of service instances required to process the current target processing request, the target processing request can be evenly distributed to the target number of service instances for processing through a load balancer, thereby ensuring high availability and performance of the system.

[0067] In the above scheme, the service instances are dynamically adjusted according to the real-time load conditions to meet the needs of high-concurrency requests, and the target processing requests are evenly distributed to the target number of service instances, avoiding overload of a single service instance and ensuring high availability and performance of the system.

[0068] Based on the above embodiments, as an optional embodiment, the method for obtaining the target processing request is as follows: Figure 4 The specific contents include: S201, the processing module sends a request to the Kafka message middleware; S202, the Kafka message middleware determines the topics to which the processing module has subscribed and the partitions in each topic that are allocated to the processing module; S203, the Kafka message middleware determines whether there are unprocessed processing requests in each partition according to the offset of each partition stored for each subscribed topic; S204, when the Kafka message middleware determines that there are unprocessed processing requests in at least one partition, the unprocessed processing requests are sent to the processing module.

[0069] In S201 of the embodiment of the present application, the acquisition request is used to request a new processing request; the processing module sends the acquisition request to the Kafka message middleware to request a new processing request to be processed.

[0070] In S202 of the embodiment of the present application, after receiving the acquisition request, the Kafka message middleware will first determine the topics to which the processing module that sends the processing request has subscribed and the partitions in each topic that are assigned to the processing module, and then check each partition to see if there are any unprocessed processing requests that need to be processed.

[0071] In S203 of the embodiment of the present application, the offset is used to record the position of the processing request that has been processed by the processing module in the partition. Therefore, the Kafka message middleware can determine whether there are unprocessed processing requests in each partition based on the stored offset of each partition for each subscribed topic.

[0072] In S204 of the embodiment of the present application, when the Kafka message middleware determines that at least one partition has an unprocessed processing request, the unprocessed processing request is sent to the processing module for processing by the processing module.

[0073] In the above scheme, the processing module obtains new processing requests by sending a request to the Kafka message middleware. When it is determined according to the offset that there is a new processing request in the partition to which the processing module has been subscribed and assigned to the processing module, the latest processing request will be obtained according to the currently stored offset and sent to the processing module to ensure that all processing requests that have not been processed can be processed. Since each topic can have multiple partitions, messages will be evenly distributed to these partitions, and load balancing and high availability will also be achieved.

[0074] Based on the above embodiments, as an optional embodiment, the method for updating the offset is as follows: Figure 5 The specific contents include: 301-1, if the processing module successfully processes the target processing request, it sends the current offset to the Kafka message middleware; S301-2, if the processing module fails to process the target processing request, reprocess the target processing request; S302: If the number of times that the processing module fails to process the target processing request is greater than a preset failure threshold, the target processing request is sent to a dead letter queue, and the current offset is sent to the Kafka message middleware; S303, the Kafka message middleware updates the offset of the stored target partition of the target topic to the current offset.

[0075] In S301-1 of the embodiment of the present application, after the processing module successfully processes the target processing request, it will send the current offset to the Kafka message middleware. The current offset is used to characterize the position of the target processing request currently processed by the processing module in the target partition of the target topic, so that the Kafka message middleware will not send the target processing request again the next time it sends an unprocessed request in the target partition of the target topic to the processing module.

[0076] In S301-2 of the embodiment of the present application, since the processing module may not be able to successfully process the target processing request due to temporary network problems, resource limitations, etc., there is a situation where the processing module fails to process the target processing request. After the target processing request fails, in order to ensure the reliability and fault tolerance of the system, the target processing request will be reprocessed, thereby reducing the risk of interruption of the entire system or service due to a single failure, ensuring that the system can continue to operate stably in the face of fluctuating network conditions, instantaneous peak loads, unavailability of dependent services, etc., and avoiding direct failure or data loss. In S302 of the embodiment of the present application, during the process of the processing module reprocessing the target processing request, each processing failure will be counted. When the number of times the processing module fails to process the target processing request is greater than the preset failure threshold, the target processing request will be sent to a dead letter queue for storing unprocessed requests, so that developers or operation and maintenance personnel can extract the target processing request from the dead letter queue for analysis and processing, and then send the current offset to the Kafka message middleware.

[0077] In the embodiment of the present application, a preset failure threshold is set, and the target processing request is placed in a dead letter queue when the preset failure threshold is reached, in order to prevent endless repeated processing when a persistent failure occurs in the system, consuming a large amount of computing resources.

[0078] In S303 of the embodiment of the present application, after the Kafka message middleware receives the current offset sent by the processing module, it will update the offset of the target partition of the stored target topic to the current offset, thereby ensuring that when the acquisition request sent by the processing module is obtained, the target processing request will no longer be sent to the processing module.

[0079] In the above scheme, the offset is sent to the consumer Kafka message middleware only after the target processing request is successfully processed, or it is determined that it will no longer be processed after multiple processing failures, to ensure that the request that needs to be processed will be sent to the processing module. At the same time, it also avoids that the request that has been processed or is determined not to be processed will not be sent to the processing module again, so that the processing module can continue to process other requests, and the entire processing process will not be blocked due to the failure of individual requests.

[0080] Based on the above embodiments, as an optional embodiment, the vehicle terminal defines the target processing request as a target transmission quality level according to the MQTT protocol; the vehicle terminal sends the target processing request to the receiving module based on the target transmission quality level.

[0081] In an embodiment of the present application, before sending a target processing request, the vehicle-mounted terminal sets different transmission level qualities according to the importance and real-time nature of the target processing request.

[0082] In the embodiment of the present application, the transmission quality level is divided into three levels, and the sending mode corresponding to each transmission level is as follows: QoS0: Messages are sent at most once, and delivery is not guaranteed (suitable for unimportant messages); QoS1: Messages are sent at least once, ensuring delivery, but may be repeated (suitable for important status updates); QoS2: The message is sent only once to ensure absolute delivery (applicable to key control instructions); In an embodiment of the present application, after determining the target transmission quality level based on the MQTT protocol, the vehicle-mounted terminal sends a target processing request to the receiving module based on the sending mode corresponding to the target transmission quality level.

[0083] In the above scheme, before sending the target processing request to the receiving module, by setting the target transmission quality level, it can be ensured that the important message is transmitted in place.

[0084] Based on the above embodiments, as an optional embodiment, the Kafka message middleware includes multiple topics, each topic includes multiple partitions, and each partition pulls and processes requests according to its corresponding queue strategy; A queue strategy includes at least one of the following: Pull processing requests in the order they first entered the partition; Pull requests are processed in the order they last entered the partition.

[0085] In an embodiment of the present application, a topic is equivalent to a classification unit of a message, and messages can be classified according to actual conditions, such as different message producers correspond to different topics, or different processing priorities correspond to different topics. Each topic includes multiple partitions, and a partition is a storage unit for processing requests. After a consumer subscribes to a topic, the Kafka message middleware assigns the corresponding partition to the consumer. For example, consumer A and consumer B both subscribe to topic A, which includes partition 1, partition 2, partition 3, and partition 4. The Kafka message middleware assigns partition 1 and partition 2 to consumer A, and partition 3 and partition 4 to consumer B.

[0086] In an embodiment of the present application, the messages in each partition are stored in order. The queue strategy refers to the order of processing requests in the consumption partition. The queue strategy includes pulling processing requests in the order of first entering the partition, that is, the earlier the processing request enters the partition, the earlier it will be processed, that is, it will be processed in the order of the time of entering the partition. The queue strategy also includes pulling processing requests in the order of last entering the partition. The request that enters the partition last is the latest processing request, that is, the queue strategy is to pull the processing request that enters the partition last first.

[0087] In an embodiment of the present application, since different processing requests have different business requirements, different queue strategies can be selected according to the business requirements of the processing requests, and different partitions can be set to adopt different queue strategies, so that the processing requests can be stored in the corresponding partitions according to actual business requirements. For processing requests that require a quick response, such as task assignment requests, an immediate response is required. Therefore, a queue strategy is adopted to pull the processing requests in the order of the last partition entered, and the target partition that executes the above queue strategy is selected in the target topic, and then the task assignment request is stored in the above target partition; for requests that do not require a quick response, such as status update requests, a queue strategy can be adopted to pull the processing requests in the order of the first partition entered, and the target partition that executes the above queue strategy is selected in the target topic, and then the status update request is stored in the above target partition.

[0088] In the above solution, different queue strategies are set for different partitions according to business needs, which can ensure that processing requests with high real-time requirements can be processed immediately.

[0089] Based on the above embodiments, as an optional embodiment, the method of sending the control instruction is as follows: Figure 6 , the specific contents include: S401, the processing module determines the processing result and generates a control instruction according to the processing result; S402, the processing module sends an instruction message to the Kafka message middleware; the instruction message is used to instruct the Kafka message middleware to store the control instruction in the first topic subscribed by the vehicle terminal; S403, the Kafka message middleware determines the first partition in the first topic allocated to the vehicle terminal, and stores the control instruction in the first partition of the first topic; S404, the vehicle-mounted terminal obtains a control instruction from the first partition of the first topic through a receiving module, and performs a corresponding operation according to the control instruction.

[0090] In S401 of the embodiment of the present application, the processing result refers to the result obtained after processing the target processing request, such as requesting obstacle detection and obtaining an obstacle detection result. The control instruction is obtained based on the processing result. For example, the obstacle avoidance instruction obtained according to the obstacle detection result is the control instruction, and the control instruction is used to instruct the vehicle to avoid obstacles.

[0091] In one example, a target processing request is used to request planning of a driving path. The driving path obtained by the processing module based on the target information in the target processing request is equivalent to the above processing result. A control instruction is determined based on the driving path. The control instruction is used to instruct the target vehicle to travel according to the obtained driving path.

[0092] In S402 of the embodiment of the present application, the control instructions that the processing module feeds back to the vehicle terminal also need to be stored in the Kafka message middleware first. The processing module sends an indication message to the Kafka message middleware, indicating that the recipient of the control instruction is the above-mentioned vehicle terminal. Therefore, the Kafka message middleware will store the control instruction in the first topic subscribed by the vehicle terminal, so that when the vehicle terminal sends a message acquisition request to the server for obtaining the latest message, the Kafka message middleware will obtain the control instruction from the first topic and send it to the vehicle terminal.

[0093] In S403 of the embodiment of the present application, since the same topic may be subscribed to by multiple consumers, different partitions in the same topic are assigned to different consumers by the Kafka message middleware. Therefore, after the Kafka message middleware determines the first topic to be subscribed, it also needs to determine the first partition assigned to the vehicle terminal, and then store the control instructions in the first partition of the first topic.

[0094] In S404 of the embodiment of the present application, the corresponding operation of the control instruction includes but is not limited to: controlling the target vehicle to travel, starting the corresponding function according to the control instruction, avoiding obstacles according to the control instruction, etc. The vehicle terminal can send a message to the Kafka message middleware through the receiving module, and can also obtain the message of the subscribed topic from the Kafka message middleware through the receiving module. After the vehicle terminal obtains the control instruction from the first partition of the first topic, it performs the corresponding operation according to the control instruction.

[0095] In one example, while the mine car is driving, it sends a continuous exception detection request containing real-time operating status and location information to the processing module. After the processing module processes the sent information, if it is determined that the mine car has an abnormality, such as obstacle detection and equipment failure, the processing module will immediately send a stop instruction to the Kafka message middleware, so that the mine car can obtain the stop instruction from the Kafka message middleware in time and take parking measures.

[0096] In the above scheme, the target vehicle can obtain control instructions corresponding to the processing results from the cloud platform according to the uploaded target processing request, and adjust the behavior of the target vehicle itself according to the control instructions, ensuring the real-time response capability of the system.

[0097] Based on the above embodiments, as an optional embodiment, the processing request further includes target information, and the target information is at least one type of sub-information related to the target vehicle and the environment in which the target vehicle is located: Vehicle operating status information; Environmental information; Vehicle failure information; Vehicle location information; Processing of the request, followed by: The processing module determines the category of each sub-information in the target information; For each category of sub-information, the processing module stores the sub-information in a storage area corresponding to the category.

[0098] In an embodiment of the present application, since the target information in the processing request includes at least one type of sub-information related to the target vehicle and the environment in which the target vehicle is located, in order to facilitate the subsequent retrieval and analysis of various types of sub-information of the target vehicle, the category of each sub-information in the target information will be determined first, and then the sub-information will be stored in the storage area corresponding to the type according to the category of the sub-information, so as to facilitate subsequent analysis and use.

[0099] In the embodiment of the present application, the categories of sub-information include vehicle operating status information, which is used to characterize the current operating status of the vehicle, and can be divided into running and stopped, and can also be further divided according to the speed of the vehicle and other contents; the categories of sub-information also include environmental information, which refers to information about the current environment of the vehicle; the categories of sub-information also include vehicle fault information, which is information related to the occurrence of a fault, such as information such as the vehicle's engine temperature is too high; the categories of sub-information also include vehicle position information, which is used to characterize the current location of the vehicle, and the vehicle position information can provide the processing module with the required information for planning the vehicle's driving path.

[0100] In the above scheme, by classifying and storing the target information, it is possible to facilitate subsequent retrieval and analysis of the acquired information.

[0101] In an embodiment of the present application, the target information can also be classified and stored according to its format, and the target information can be organized and stored in a predefined format. The information stored in the preset format makes the reading and writing of data efficient and easy, and the data can also be quickly retrieved and processed through query languages ​​such as SQL.

[0102] Based on the above embodiments, as an optional embodiment, the processing module updates the model set according to various types of sub-information that have been stored.

[0103] In an embodiment of the present application, each model in the model set can be updated according to the target information contained in the processed target processing request, that is, the model can be iterated and optimized according to historical data and implementation feedback data to ensure that the functions corresponding to each model can maintain efficient operation in a dynamically changing environment.

[0104] A model set includes at least one of the following: Prediction model: The prediction model is used to predict whether the target vehicle has a problem based on the vehicle operation status information; Obstacle avoidance model: The obstacle avoidance model is used to determine the obstacle avoidance route of the target vehicle based on environmental information; Path planning model: The path planning model is used to determine the driving path of the target vehicle based on the vehicle position information and environmental information.

[0105] In an embodiment of the present application, the prediction model is used to predict whether there is a problem with the target vehicle based on the vehicle operating status information. The processing module can iteratively update the prediction model based on a large amount of vehicle operating status information and corresponding health or problem information received to improve the prediction accuracy of the model, and can also help the prediction model identify new problem types.

[0106] In an embodiment of the present application, the obstacle avoidance model is used to determine the obstacle avoidance route of the target vehicle based on environmental information. The processing module can ensure that the obstacle avoidance model can reflect the latest environmental status based on the large amount of environmental information received, compare the actual obstacle avoidance process of the vehicle with the route of the obstacle avoidance model, and update the obstacle avoidance model based on the difference.

[0107] In the embodiment of the present application, the path planning model is used to determine the driving path of the target vehicle based on the vehicle position information and environmental information. The processing module can update the map in the path planning model based on the received large amount of vehicle position information and environmental information, use machine learning technology to analyze historical data and path information, and continuously optimize the path selection strategy through supervised learning or reinforcement learning. Design an adaptive model to adjust relevant parameters according to environmental changes and behavioral feedback to improve the efficiency and accuracy of path planning.

[0108] In the embodiment of the present application, the communication strategy of the system can also be optimized by collecting the status and processing requests of each vehicle in real time, analyzing the load and response time of the system.

[0109] In the embodiment of the present application, the performance of the algorithm and scheduling strategy can also be evaluated regularly, and loop optimization can be achieved through a continuous feedback mechanism to ensure the efficient operation of the system in a dynamically changing environment.

[0110] In the embodiment of the present application, a special data analysis and algorithm optimization team can also be formed to hold regular meetings to share analysis results and optimization strategies to ensure the team's full understanding and response capabilities to the system status.

[0111] Based on the above embodiments, as an optional embodiment, the target vehicle is multiple vehicles, and the processing module determines the driving priority corresponding to each vehicle based on the vehicle operation status information obtained from each vehicle; the processing module processes the processing request corresponding to each vehicle based on the driving priority of each vehicle.

[0112] In an embodiment of the present application, due to different vehicle operating states caused by terrain or vehicle performance, some vehicles may currently have malfunctions and need to stop, while some vehicles are currently in good operating state. In order to avoid the impact of vehicles with problems on vehicles in good operating state, the corresponding driving priority of each vehicle can be determined according to the operating state of each vehicle. For vehicles with higher driving priorities, they can be processed first when processing the corresponding target processing requests, or for vehicles with higher priorities, the driving requirements of vehicles with higher driving priorities can be given priority in the process of driving route planning.

[0113] In the above scheme, the driving priority of each vehicle is determined based on the received target information to ensure efficient use of resources.

[0114] Based on the above embodiments, as an optional embodiment, the vehicle-mounted terminal obtains sensor information; the sensor information is obtained by a sensor installed on the target vehicle; the vehicle-mounted terminal determines the target information according to a preset algorithm and the sensor information.

[0115] In an embodiment of the present application, the vehicle-mounted terminal obtains sensor information collected from sensors installed on the target vehicle, and the sensors include: GPS, laser radar, camera and other sensors.

[0116] In an embodiment of the present application, the local processing unit on the vehicle terminal performs a preliminary analysis of the sensor information, and obtains the target information including the current position of the target vehicle, the driving direction of the target vehicle, and obstacle information based on the preset algorithms and the required sensor information corresponding to each type of information.

[0117] Based on the above embodiments, as an optional embodiment, the target processing request includes at least one of the following: Path planning request; Scheduling requests; Environmental testing requests; Fault detection request.

[0118] In an embodiment of the present application, the target processing request sent to the processing module may include at least one request at the same time: a path planning request is used to request the processing module to plan a recommended path based on the current position information and environmental information; a scheduling request is used to request the processing module to determine the scheduling instructions for the target vehicle based on the currently uploaded target information; an environmental detection request is used to request the processing module to determine whether the surrounding environment is suitable for the vehicle to continue driving based on the currently uploaded position information and obstacle information; and a fault detection request is used to request the processing module to determine whether the vehicle currently has a fault based on the uploaded information related to the vehicle status.

[0119] Based on the above embodiments, as an optional embodiment, the vehicle-mounted terminal formats the target processing request data, generates a unified information structure, and marks the target processing request. The marking content includes: timestamp and vehicle identification, to ensure that the corresponding target vehicle can be traced back during subsequent processing.

[0120] Based on the above embodiments, as an optional embodiment, after the receiving module obtains the target processing request, it serializes the target processing request, and then sends the serialized target processing request to the Kafka message middleware through the Kafka Producer, and the processing module asynchronously consumes the processing request from the Kafka queue through the Kafka Consumer.

[0121] In an embodiment of the present application, after the vehicle-mounted terminal sends the target processing request to the Kafka message middleware through the receiving module, the vehicle-mounted terminal can continue to perform local operations without waiting for the response information returned by the processing module.

[0122] In an embodiment of the present application, an alarm threshold is set in advance, and the load condition is determined based on real-time monitored performance indicators of the cloud service such as CPU, memory, network bandwidth, etc. When the load condition exceeds the alarm threshold, an alarm message is issued and corresponding adjustment measures are executed.

[0123] In the embodiment of the present application, the processing module can store the received target information in a distributed data lake for subsequent analysis. The processing module can also use Apache Spark, Hadoop and other big data processing frameworks to analyze historical data and mine operating modes and potential problems.

[0124] In the embodiment of the present application, all processing processes are performed asynchronously to ensure that the vehicle is not blocked due to waiting for a response. The cloud service dynamically adjusts the processing strategy according to the specific load conditions to ensure the efficient operation of the system.

[0125] In the embodiment of the present application, the present application can be applied to the interaction between the mine autonomous driving vehicle and the cloud platform, aggregating the target information of multiple mine vehicles to the cloud platform, and importing the target information obtained by the sensor into the cloud for analysis, so as to achieve a global view and optimize task scheduling and writing. By applying the vehicle-cloud communication method provided by the present application in mine autonomous driving, efficient and stable vehicle-cloud communication can be achieved while maintaining the flexibility and scalability of the system, which not only improves the autonomous driving capability of the mine vehicle, but also enhances the safety and efficiency of mine operations.

[0126] refer to Figure 7 As shown, a flowchart of the interaction between a mining vehicle and a cloud platform in executing a vehicle-cloud communication method is specifically shown, and the specific contents are as follows: S701, the vehicle-mounted terminal of the mining vehicle obtains sensor information collected by the sensor, analyzes the sensor information, determines target information and the priority of the target information, generates a target processing request including the target information, vehicle identification and priority, and sets a target transmission level of the target processing request; S702, the vehicle terminal sends a target processing request to the receiving module based on the target transmission level; S703: When the receiving module determines that the number of requests received within the preset time period does not exceed the preset number threshold, the target processing request is received and the target processing request is serialized; S704, the receiving module sends the serialized target processing request to the Kafka message middleware; S705, the Kafka message middleware determines the target topic corresponding to the target processing request according to the priority included in the target processing request, determines the target partition according to the vehicle identification, and stores the processing request to the target partition of the target topic; S706, the processing module sends a request to the Kafka message middleware; S707, if the Kafka message middleware determines that the processing module that sends the acquisition request has subscribed to the target topic and has been assigned a target partition, it sends a target processing request to the processing module according to the currently stored offset; S708, the processing module collects the current performance indicators of the vehicle-cloud communication system, determines the target number of service instances currently required according to the performance indicators and the preset scaling strategy, and evenly distributes the target processing requests to the target number of service instances for processing; S709: If the processing module successfully processes the target processing request, a control instruction is generated according to the processing result, and a current offset is determined; S710, the processing module sends the current offset and indication information including control instructions to the Kafka message middleware; S711, the Kafka message middleware updates the offset of the stored target partition of the target topic to the current offset, and then stores the control instruction in the first partition of the first topic subscribed by the vehicle terminal according to the instruction information; S712. The vehicle-mounted terminal obtains a control instruction from the first partition of the first topic through a receiving module.

[0127] S713: The vehicle-mounted terminal performs corresponding operations according to the control instruction.

[0128] The vehicle-cloud communication method provided in the embodiment of the present application, by introducing the Spring Cloud Stream framework, the Kafka message middleware and the FlowLimiter, achieves a greatly reduced system crash rate in high-concurrency scenarios, greatly reduces the risk of message loss due to high load, and thanks to the decoupling characteristics of Spring Cloud Stream, the system also reduces maintenance costs when replacing or upgrading message queues, allowing the development and operation teams to respond to technology changes more quickly. By introducing FlowLimiter, the request rate entering the processing module is ensured to be controllable, effectively avoiding system overload, thereby improving the responsiveness and reliability of the system; the present application utilizes the asynchronous processing function of Spring Cloud Stream, and the system greatly shortens the response time when processing long-term tasks under high traffic conditions, greatly improving the user experience; the present application combines the high throughput and distributed characteristics of Kafka, greatly improving the data processing efficiency, and can efficiently cope with the challenges of large-scale message flows, ensuring the stable operation of the system under high load; in the embodiment of the present application in high-concurrency scenarios, experimental data show that the system crash rate is reduced by about 60%, greatly reducing the risk of message loss due to high load.

[0129] The present application embodiment provides a vehicle-to-cloud communication system, such as Figure 8 As shown, the vehicle-cloud communication system 80 may include: a vehicle-mounted terminal 801, a receiving module 802, a Kafka message middleware 803 and a processing module 804.

[0130] Specifically, the vehicle terminal 801 is used to determine the target information and the priority of the target information; The vehicle terminal 801 is used to send a target processing request to the receiving module; the target processing request includes a vehicle identification and priority of the target vehicle; The receiving module 802 is used to receive a target processing request and send the target processing request to the Kafka message middleware when determining that the number of received requests within a preset time period does not exceed a preset number threshold; Kafka message middleware 803, used to determine the target topic corresponding to the target processing request according to the priority, the Kafka message middleware determines the target partition according to the vehicle identification, and stores the processing request in the target partition of the target topic; The processing module 804 is used to obtain a target processing request from a target partition of a target topic, and process the target processing request based on a current load of the vehicle-to-cloud communication system.

[0131] The device of the embodiments of the present application can execute the method provided by the embodiments of the present application, and the implementation principles are similar. The actions performed by each module in the device of each embodiment of the present application correspond to the steps in the method of each embodiment of the present application. For the detailed functional description of each module of the device, please refer to the description in the corresponding method shown in the previous text, which will not be repeated here.

[0132] An electronic device (computer device / equipment / system) is provided in an embodiment of the present application, including a memory, a processor and a computer program stored in the memory, and the processor executes the above-mentioned computer program to implement the steps of the vehicle-cloud communication method. Compared with the related art, it can achieve: the flow control of the received request is performed by the receiving module to ensure that the request rate entering the processing module is controllable, and the overload of the processing module is effectively avoided, thereby improving the responsiveness and reliability of the processing module; the target processing request is placed in the target topic and target partition corresponding to the Kafka message middleware through the receiving module, avoiding overload caused by directly sending the request to the processing module, reducing the risk of overload, ensuring the stable transmission of the request, and also avoiding blocking the transmission of other requests for time-consuming processing requests. The processing module processes the target processing request according to the load situation of the current vehicle-cloud communication system, and maintains the efficient operation of the system without wasting processing resources.

[0133] In an alternative embodiment, an electronic device is provided, such as Fig. 9 As shown, Fig. 9 The electronic device 4000 shown includes: a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, such as through a bus 4002. Optionally, the electronic device 4000 may also include a transceiver 4004, which may be used for data interaction between the electronic device and other electronic devices, such as data transmission and / or data reception. It should be noted that in actual applications, the transceiver 4004 is not limited to one, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present application.

[0134] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It may implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of this application. Processor 4001 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0135] The bus 4002 may include a path to transmit information between the above components. The bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus 4002 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig. 9 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0136] The memory 4003 may be a ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, a RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory) or other optical disk storage, optical disk storage (including compressed optical disk, laser disk, optical disk, digital versatile disk, Blu-ray disk, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium that can be used to carry or store computer programs and can be read by a computer, without limitation herein.

[0137] The memory 4003 is used to store the computer program for executing the embodiment of the present application, and the execution is controlled by the processor 4001. The processor 4001 is used to execute the computer program stored in the memory 4003 to implement the steps shown in the above method embodiment.

[0138] Among them, the electronic equipment package may include but is not limited to mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Fig. 9 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0139] The embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps and corresponding contents of the aforementioned method embodiment can be implemented. Compared with the prior art, it can be achieved that: the flow control of the received request is performed by the receiving module, so as to ensure that the request rate entering the processing module is controllable, and the overload of the processing module is effectively avoided, thereby improving the responsiveness and reliability of the processing module, and the target processing request is placed in the target topic and target partition corresponding to the Kafka message middleware through the receiving module, so as to avoid directly sending the request to the processing module to cause overload, reduce the risk of overload, ensure the stable transmission of the request, and also avoid blocking the transmission of other requests for time-consuming processing requests. The processing module processes the target processing request according to the load of the current vehicle-cloud communication system, and maintains the efficient operation of the system without wasting processing resources.

[0140] It should be noted that the computer-readable medium mentioned above in the present disclosure may be a computer-readable signal medium or a computer-readable medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present disclosure, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer readable signal media may also be any computer readable medium other than computer readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0141] The present application also provides a computer program product, including a computer program, which can implement the steps and corresponding contents of the above method embodiments when executed by a processor. Compared with the prior art, it can achieve: The receiving module controls the flow of received requests to ensure that the request rate entering the processing module is controllable, effectively avoiding overload of the processing module, thereby improving the responsiveness and reliability of the processing module. The receiving module places the target processing request in the target topic and target partition corresponding to the Kafka message middleware to avoid overload caused by directly sending the request to the processing module, reducing the risk of overload and ensuring the stable transmission of requests. At the same time, it also avoids blocking the transmission of other requests for time-consuming processing. The processing module processes the target processing request according to the current load of the vehicle-cloud communication system, maintaining the efficient operation of the system without wasting processing resources.

[0142] The terms "first", "second", "third", "fourth", "1", "2", etc. (if any) in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than that shown or described in the drawings.

[0143] It should be understood that, although each operation step is indicated by arrows in the flowchart of the embodiment of the present application, the implementation order of these steps is not limited to the order indicated by the arrows. Unless clearly stated herein, in some implementation scenarios of the embodiment of the present application, the implementation steps in each flowchart can be performed in other orders according to demand. In addition, some or all of the steps in each flowchart may include multiple sub-steps or multiple stages based on actual implementation scenarios. Some or all of these sub-steps or stages may be executed at the same time, and each sub-step or stage in these sub-steps or stages may also be executed at different times respectively. In different scenarios of execution time, the execution order of these sub-steps or stages may be flexibly configured according to demand, and the embodiment of the present application does not limit this.

[0144] The above are only optional implementation methods for some implementation scenarios of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the technical concept of the scheme of the present application, other similar implementation methods based on the technical ideas of the present application are also within the protection scope of the embodiments of the present application.

Claims

1. A vehicle-cloud communication method, characterized in that: Applied to a vehicle-cloud communication system, the vehicle-cloud communication system comprises: an on-board terminal of a target vehicle and a cloud platform, the cloud platform comprises: a receiving module, a Kafka message middleware and a processing module; the method comprises: The vehicle-mounted terminal determines target information and a priority of the target information; The vehicle-mounted terminal sends a target processing request to the receiving module; the target processing request includes the vehicle identification and the priority of the target vehicle; When the receiving module determines that the number of received requests within a preset time period does not exceed a preset number threshold, the target processing request is received and the target processing request is sent to the Kafka message middleware; The Kafka message middleware determines the target topic corresponding to the target processing request according to the priority, determines the target partition according to the vehicle identification, and stores the processing request in the target partition of the target topic; The processing module subscribes to the target topic and is assigned the target partition, obtains the target processing request from the target partition of the target topic, and processes the target processing request based on the current load of the vehicle-cloud communication system.

2. The method according to claim 1, characterized in that The processing of the target processing request based on the current load of the vehicle-to-cloud communication system includes: The processing module collects the current performance indicators of the vehicle-to-cloud communication system; the performance indicators are used to characterize the current load conditions; The processing module determines the target number of service instances currently required according to the performance indicator and the preset scaling strategy; The processing module evenly distributes the target processing request to a target number of service instances for processing.

3. The method according to claim 1, characterized in that The processing module subscribing to the target topic and being assigned the target partition obtains the target processing request from the target partition of the target topic, which includes: The processing module sends a request to the Kafka message middleware; the request is used to request a new processing request; The Kafka message middleware determines the topics subscribed by the processing module and the partitions in each topic allocated to the processing module; The Kafka message middleware determines, for each subscribed topic, whether there is an unprocessed processing request in each partition according to the stored offset of each partition; the offset is used to record the position of the processing request processed by the processing module in the partition; When the Kafka message middleware determines that there is an unprocessed processing request in at least one partition, the unprocessed processing request is sent to the processing module.

4. The method according to claim 3, characterized in that The method further comprises: If the processing module successfully processes the target processing request, the current offset is sent to the Kafka message middleware; If the processing module fails to process the target processing request, reprocess the target processing request; If the number of times that the processing module fails to process the target processing request is greater than a preset failure threshold, the target processing request is sent to a dead letter queue, and the current offset is sent to the Kafka message middleware; the dead letter queue is used to store requests that cannot be processed; The Kafka message middleware updates the stored offset of the target partition of the target topic to the current offset.

5. The method according to claim 1, characterized in that The vehicle-mounted terminal sends a target processing request to the receiving module, including: The vehicle terminal defines the target processing request as a target transmission quality level according to the MQTT protocol; The vehicle-mounted terminal sends the target processing request to the receiving module based on the target transmission quality level.

6. The method according to claim 1, characterized in that The Kafka message middleware includes multiple topics, each topic includes multiple partitions, and each partition pulls and processes requests according to its corresponding queue strategy; The queue strategy includes at least one of the following: Pull processing requests in the order they first entered the partition; Pull requests are processed in the order they last entered the partition.

7. The method according to claim 1, characterized in that The processing of the target processing request further includes: The processing module determines a processing result and generates a control instruction according to the processing result; The processing module sends instruction information to the Kafka message middleware; the instruction information is used to instruct the Kafka message middleware to store the control instruction in the first topic subscribed by the vehicle terminal; The Kafka message middleware determines the first partition in the first topic allocated to the vehicle terminal, and stores the control instruction in the first partition of the first topic; The vehicle-mounted terminal obtains the control instruction from the first partition of the first topic through the receiving module, and performs corresponding operations according to the control instruction.

8. The method according to claim 1, characterized in that The processing request further includes the target information, and the target information includes at least one type of sub-information related to the target vehicle and the environment in which the target vehicle is located: Vehicle operating status information; Environmental information; Vehicle failure information; Vehicle location information; The processing request further includes: The processing module determines the category of each sub-information in the target information; For each category of sub-information, the processing module stores the sub-information into a storage area corresponding to the category.

9. The method according to claim 8, characterized in that The step of storing the information in a storage area corresponding to the category further includes: The processing module updates the model set according to various types of sub-information stored; The model set includes at least one of the following: Prediction model; the prediction model is used to predict whether the target vehicle has a problem based on the vehicle operation status information; Obstacle avoidance model: The obstacle avoidance model is used to determine the obstacle avoidance route of the target vehicle according to the environmental information; Path planning model: The path planning model is used to determine the driving path of the target vehicle based on the vehicle position information and the environmental information.

10. The method according to claim 8, characterized in that The target vehicle is a plurality of vehicles; the method further comprises: The processing module determines the driving priority corresponding to each vehicle according to the acquired vehicle running status information of each vehicle; The processing module processes the processing request corresponding to each vehicle based on the driving priority of each vehicle.

11. The method according to claim 1, characterized in that: The vehicle-mounted terminal determines the target information, including: The vehicle-mounted terminal obtains sensor information; the sensor information is obtained by a sensor installed on the target vehicle; The vehicle-mounted terminal determines the target information according to a preset algorithm and the sensor information.

12. The method according to claim 1, characterized in that The target processing request includes at least one of the following: Path planning request; Scheduling requests; Environmental testing requests; Fault detection request.

13. A vehicle-cloud communication system, characterized in that: The vehicle-cloud communication system includes: an on-board terminal of the target vehicle and a cloud platform, and the cloud platform includes: a receiving module, a Kafka message middleware and a processing module; The vehicle-mounted terminal is used to determine target information and the priority of the target information; The vehicle-mounted terminal is used to send a target processing request to the receiving module; the target processing request includes the vehicle identification of the target vehicle and the priority of the target information; The receiving module is used to receive the target processing request and send the target processing request to the Kafka message middleware when determining that the number of received requests within a preset time period does not exceed a preset number threshold; The Kafka message middleware is used to determine the target topic corresponding to the target processing request according to the priority, the Kafka message middleware determines the target partition according to the vehicle identification, and stores the processing request in the target partition of the target topic; The processing module is used to obtain the target processing request from the target partition of the target topic, and process the target processing request based on the current load of the vehicle-cloud communication system.

14. An electronic device comprising a memory, a processor and a computer program stored in the memory, characterized in that: The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 12.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 12 are implemented.

16. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 12 are implemented.

Images