Autonomous vehicles controlled based on edge server resources

Abstract

A computer-implemented method, system, and computer program product for reducing the load on an edge server in an autonomous driving mobile environment. The method involves estimating the load on an edge server controlling an autonomous vehicle located within the coverage area of ​​the edge server. In response to the estimated load on the edge server exceeding a threshold, actions to reduce the load on the edge server are implemented by controlling one or more vehicles in the autonomous vehicle to operate in a specific manner. Examples of controlling the autonomous vehicle to operate in a specific manner to reduce the load on the edge server include modifying the movement of the autonomous vehicle, modifying the frequency of transmitting vehicle data, offloading computations previously performed on the edge server to be performed in the autonomous vehicle, restricting lane changes, etc.

Description

Technical Field

[0001] This disclosure generally relates to autonomous mobility, and more specifically to the control of autonomous vehicles based on edge server resources. Background Technology

[0002] Autonomous mobility refers to the movement of vehicles that operate autonomously without human intervention. Autonomous vehicles are those capable of sensing their environment and operating without human involvement (e.g., cars, drones, agricultural equipment, mining equipment, etc.). Summary of the Invention

[0003] In one embodiment of this disclosure, a computer-implemented method for reducing the load on an edge server in an autonomous driving mobile environment includes estimating the load on an edge server controlling an autonomous vehicle. The method further includes, in response to the estimated load on the edge server exceeding a threshold, implementing actions to reduce the load on the edge server by controlling one or more vehicles in the autonomous vehicle to operate in a specific manner.

[0004] Other forms of embodiments of the above-described computer-implemented method are embodied in the system and computer program product.

[0005] The foregoing has broadly outlined the features and technical advantages of one or more embodiments of this disclosure in order to provide a better understanding of the detailed description of this disclosure that follows. Additional features and advantages of this disclosure will be described below, and they may form the subject matter of the claims of this disclosure. Attached Figure Description

[0006] A better understanding of this disclosure can be obtained by considering the following detailed description in conjunction with the accompanying drawings, in which: Figure 1 The following diagram illustrates the infrastructure for practicing the principles of this disclosure according to embodiments thereof; Figure 2 It is a map that dynamically displays the current location of an autonomous vehicle in relation to the coverage area of ​​an edge server, according to embodiments of this disclosure; Figure 3 Internal components of an autonomous vehicle according to embodiments of the present disclosure are shown; Figure 4 An edge server and internal components for controlling an autonomous vehicle based on edge server resources are shown according to embodiments of the present disclosure. Figure 5 An embodiment of the hardware configuration of the edge server and the edge server controller is shown, which represents a hardware environment for practicing this disclosure; Figure 6This is a flowchart of a method for processing transactions during peak hours by controlling an autonomous vehicle based on edge server resources according to embodiments of the present disclosure; and Figure 7 This is a flowchart of a method for implementing actions to reduce the load on an edge server by controlling an autonomous vehicle to operate in a specific manner, according to embodiments of the present disclosure. Detailed Implementation

[0007] As mentioned above, autonomous mobility refers to the movement of vehicles that operate autonomously without human intervention. Autonomous vehicles are those that are capable of sensing their environment and operating without human involvement (e.g., cars, drones, agricultural equipment, mining equipment, etc.).

[0008] Autonomous vehicles have the ability to continuously monitor their surroundings using sensor arrays, including cameras, radar, and lidar. These sensors provide a 360-degree view of the vehicle's environment, enabling them to detect any potential obstacles, pedestrians, or other vehicles with great precision. Advanced algorithms that interpret this data can make instantaneous decisions to avoid collisions and navigate safely through complex situations.

[0009] Autonomous mobility involving such autonomous vehicles can be achieved using edge computing. Edge computing refers to a distributed computing paradigm architecture that brings computation and data storage closer to the data source. Edge computing can be implemented using edge servers, which correspond to servers located near the network edge, close to the end user.

[0010] Such edge servers can be used to handle various tasks, such as controlling autonomous vehicles in relation to traffic congestion, optimizing routes for autonomous vehicles, adjusting their speeds, and efficiently merging autonomous vehicles. This control of autonomous vehicles requires significant computing resources.

[0011] Therefore, sometimes the load on an edge server (the amount of work it processes at a given time) can be enormous, including causing the edge server to experience peak load (the maximum amount of work it can handle at a given time). The time when an edge server experiences peak load is called the "peak period".

[0012] To address situations where edge servers may be limited in transaction processing (e.g., during peak hours), transactions can be temporarily offloaded to adjacent edge servers or cloud servers. However, this results in reduced latency and accuracy of computational analytics performed by edge servers.

[0013] Another alternative to addressing peak loads on edge servers during peak hours is to deploy additional edge servers. Unfortunately, such a solution incurs additional costs, which can be substantial.

[0014] Therefore, there is currently no method to utilize the limited computing resources of edge servers to process transactions (such as those involving autonomous vehicles) during peak hours.

[0015] Embodiments of this disclosure provide a method for utilizing the limited computing resources of edge servers to process transactions during peak periods by reducing the peak load of edge servers collaborating among multiple autonomous vehicles and multiple edge servers through edge server resource-based control of autonomous vehicles. In one embodiment, the load of the edge server controlling, for example, an autonomous vehicle in an area managed by the edge server is estimated. As used herein, “load” refers to the amount of work processed by the edge server at a given time. “Edge server,” as used herein, refers to a server located at the network edge close to the end user. “Autonomous vehicle,” as used herein, refers to a vehicle (e.g., a car, drone, agricultural equipment, mining equipment) capable of sensing its environment and operating without human intervention. After estimating the load of the edge server, the load reduction action can be achieved by controlling one or more autonomous vehicles in an area managed by the edge server to operate in a specific manner. For example, a load reduction plan associated with the autonomous vehicle can be implemented. "Load reduction plans," as used herein, refer to strategies that reduce the load on edge servers by controlling autonomous vehicles in specific ways. Examples include modifying the autonomous vehicle's route, altering its movement, changing the frequency of data transmission, offloading computations previously performed on the edge server to be performed on the autonomous vehicle, and having the autonomous vehicle join a fleet of other autonomous vehicles. In another example, the driving of an autonomous vehicle can be restricted or prohibited in a way that reduces the load on the edge server (e.g., restricting lane changes, thereby reducing driving behavior analysis). In yet another example, the autonomous vehicle is instructed to reroute to an area controlled by a neighboring edge server, thus de-utilizing the edge server experiencing peak load. Further discussion of these and other features follows.

[0016] While this disclosure has been primarily discussed below in the context of controlling autonomous vehicles corresponding to automobiles based on edge server resources, the principles of this disclosure can also be applied to controlling other types of autonomous vehicles, such as drones, agricultural equipment, mining equipment, etc. Those skilled in the art will be able to apply the principles of this disclosure to such implementations. Furthermore, embodiments applying the principles of this disclosure to such implementations will fall within the scope of this disclosure.

[0017] In some embodiments of this disclosure, the disclosure includes computer-implemented methods, systems, and computer program products for reducing the load on an edge server in an autonomous mobility environment. In one embodiment of this disclosure, the load on an edge server controlling autonomous vehicles located within the coverage area of ​​an edge server is estimated. In one embodiment, the estimated edge server load corresponds to an estimated load that the edge server will handle in the near future. In one embodiment, the estimated load is based on the current edge server load, the estimated load of neighboring edge servers, the number of autonomous vehicles entering / leaving the coverage area of ​​the edge server, and contextual information (information that a human driver typically considers when driving and adapting to his / her driving, such as weather, road conditions, other vehicles, pedestrians, road signs, etc.). In response to the estimated load on the edge server exceeding a threshold, an action to reduce the load on the edge server is implemented by controlling one or more autonomous vehicles to operate in a specific manner to reduce the load on the edge server. Examples of controlling autonomous vehicles to reduce the load on edge servers include modifying the movement of the autonomous vehicles, changing the frequency of sending vehicle data, offloading computations previously performed on edge servers to be performed on the autonomous vehicles, enabling autonomous vehicles to join platoons of other autonomous vehicles, restricting lane changes, and rerouting autonomous vehicles to areas under the control of adjacent edge servers, thus preventing edge servers with peak loads from being used. In this way, by controlling autonomous vehicles based on edge server resources, the peak load on edge servers cooperating among multiple autonomous vehicles and multiple edge servers is reduced.

[0018] In the following description, numerous specific details are set forth to provide a thorough understanding of this disclosure. However, it will be apparent to those skilled in the art that this disclosure may be practiced without these specific details. In other instances, well-known circuits are shown in block diagram form so as not to obscure this disclosure with unnecessary detail. Details such as considerations of timing have been largely omitted for the purpose of obtaining a complete understanding of this disclosure and for reasons within the skill of those skilled in the art.

[0019] Now refer to the attached diagram for details. Figure 1 An embodiment of this disclosure is illustrated, comprising an infrastructure 100 for practicing the principles of this disclosure. The infrastructure 100 includes edge servers 101A-101N (in... Figure 1The edge servers 101A-101N are respectively labeled "Edge Server A", "Edge Server B", and "Edge Server N", where N is a positive integer, and are connected to the edge server controller 103 via network 102. Edge servers 101A-101N can be collectively or individually referred to as edge server 101 or edge server 101. In this document, edge server 101 refers to a server located at the network edge, close to the end user.

[0020] In addition, such as Figure 1 As shown, infrastructure 100 includes autonomous vehicles 104A-104N, where N is a positive integer, which are connected to network 102. Autonomous vehicles 104A-104N may be collectively or individually referred to as autonomous vehicle 104 or simply autonomous vehicle 104. As used herein, autonomous vehicle 104 refers to a vehicle capable of perceiving its environment and operating without human intervention (e.g., a car, drone, agricultural equipment, mining equipment).

[0021] In one embodiment, the autonomous vehicle 104 is configured with a set of computing resources. In another embodiment, the autonomous vehicle 104 is configured to perform one or more transportation operations across various locations.

[0022] The following reference Figure 3 Descriptions of the internal components of the autonomous vehicle 104 are provided.

[0023] In one embodiment, each edge server 101 is configured to control one or more autonomous vehicles 104 residing in an area (“coverage area”) covered by edge server 101 (e.g., edge server 101A). As used herein, “coverage area” refers to the geographic area or location in which edge server 101 is responsible for controlling the autonomous vehicles 104 residing, such as… Figure 2 As shown. Examples of edge server 101 include, but are not limited to, Dell® PowerEdge® servers, NXP® EdgeVerse® platforms, etc. In one embodiment, edge server 101 corresponds to an MEC (Multi-access Edge Computing) edge server.

[0024] refer to Figure 2 , Figure 2 Map 200 dynamically displays, according to embodiments of the present disclosure, the current location of autonomous vehicles (e.g., autonomous vehicle 104) associated with the coverage area of ​​an edge server (e.g., edge server 101).

[0025] like Figure 2As shown in the diagram, map 200 illustrates that edge servers 101A and 101B are responsible for controlling autonomous vehicles 104 residing in coverage areas 201A and 201B, respectively. Coverage areas 201A-201B can be collectively or individually referred to as coverage area 201 or coverage area 201.

[0026] like Figure 2 As shown, currently no autonomous vehicle 104 is controlled by edge server 101A within coverage area 201A. However, multiple autonomous vehicles 104 are controlled by edge server 101B within coverage area 201B.

[0027] return Figure 1 , combined Figure 2 In one embodiment, one or more edge servers 101 are located in a roadside unit (RSU), which is a roadside wireless communication device that provides connectivity and information support (including safety warnings and traffic information) to passing autonomous vehicles 104. An example of such a roadside unit includes NXP® Semiconductors' CIT-N1862 Brilliant roadside unit.

[0028] Furthermore, in one embodiment, edge server 101 and edge server controller 103 are configured together to control autonomous vehicles 104 within their coverage area 201 based on their available resources. In one embodiment, edge server 101 is configured to estimate the load on edge server 101. As used herein, “load” refers to the amount of work processed by the edge server at a given time.

[0029] After estimating the load on edge server 101, actions to reduce the load on edge server 101 can be implemented via edge server 101 (including in combination with edge server controller 103), such as by controlling the autonomous vehicle 104 (e.g., an autonomous vehicle 104 located within the coverage area managed by edge server 101) to operate in a certain manner, thereby reducing the load on edge server 101. For example, a load reduction plan associated with autonomous vehicle 104 can be implemented. As used herein, a "load reduction plan" refers to a strategy to reduce the load on the edge server by controlling the autonomous vehicle in a certain manner, such as by modifying the autonomous vehicle's route, modifying the autonomous vehicle's movement, modifying the frequency of sending vehicle data, offloading computations previously performed on the edge server to be performed on the autonomous vehicle, or having the autonomous vehicle join a fleet of other autonomous vehicles, etc. In another example, the driving of autonomous vehicle 104 (e.g., an autonomous vehicle 104 located within the coverage area 201 of edge server 101) can be restricted or prohibited in a manner that reduces the load on edge server 101 (e.g., restricting lane changes to reduce driving behavior analysis). In another example, an autonomous vehicle 104 located within the coverage area of ​​edge server 101 is instructed to be rerouted to an area controlled by a neighboring edge server 101, so that edge server 101 with peak load is not used. As used herein, a “neighboring edge server” refers to an edge server (e.g., edge server 101B) located in proximity to the edge server in question (e.g., edge server 101A), such as edge server 101 (e.g., edge server 101B) having a coverage area (e.g., coverage area 201A) adjacent to the coverage area of ​​the edge server in question (e.g., edge server 101A).

[0030] The following reference Figure 4 Further descriptions are provided of the internal components of the edge server 101 used to perform this function. See below for reference. Figure 5 Further description of the hardware configuration of edge server 101 is provided.

[0031] In one embodiment, edge server controller 103 is configured to monitor edge server 101 to receive incoming messages from edge server 101. Additionally, in one embodiment, edge server controller 103 is configured to implement load balancing, a process of distributing a set of tasks across resources (edge ​​server 101) to make its overall processing more efficient. Furthermore, in one embodiment, edge server controller 103 is configured to manage autonomous vehicle 104, such as grouping autonomous vehicle 104 or joining a fleet of other autonomous vehicle 104, or rerouting autonomous vehicle 104 to travel in different coverage areas 201 controlled by different edge servers 101. Furthermore, in one embodiment, edge server controller 103 is configured to store location data, such as the locations of edge server 101 and autonomous vehicle 104. In one embodiment, edge server controller 103 resides in the cloud (a distributed collection of servers hosting software and infrastructure). References are made below. Figure 4 Further descriptions are provided of the internal components of the edge server controller 103 used to perform this function. See below for reference. Figure 5 A further description of the hardware configuration of the edge server controller 103 is provided.

[0032] Network 102 can be, for example, a local area network (LAN), a wide area network (WAN), a wireless wide area network (WAN), a circuit-switched telephone network, a Global System for Mobile Communications (GSM) network, a Wireless Application Protocol (WAP) network, a WiFi network, an IEEE 802.11 standard network, or various combinations thereof. For the sake of brevity, other networks described herein may also be used. Figure 1 The infrastructure 100 can be used together without departing from the scope of this disclosure.

[0033] The scope of infrastructure 100 is not limited to any particular network architecture. Infrastructure 100 may include any number of edge servers 101, network 102, edge server controller 103, and autonomous vehicles 104.

[0034] Now for reference Figure 3 , Figure 3 An autonomous vehicle 104 according to an embodiment of the present disclosure is shown. Figure 1 ) internal components.

[0035] like Figure 3 As shown, combined with Figure 1The autonomous vehicle 104 includes, but is not limited to, a perception and planning system 301, a vehicle control system 302, a wireless communication system 303, a user interface system 304, and a sensor system 305. The autonomous vehicle 104 may also include certain common components typically found in ordinary vehicles, such as an engine, wheels, steering wheel, transmission, etc., which can be controlled by the vehicle control system 302 and / or the perception and planning system 301 via various communication signals and / or commands (such as, for example, acceleration signals or commands, deceleration signals or commands, steering signals or commands, braking signals or commands, etc.).

[0036] Components 301-305 can be communicatively coupled to each other via interconnect, bus, network, or a combination thereof. For example, components 301-305 can be communicatively coupled to each other via a Controller Area Network (CAN) bus. The CAN bus is a vehicle bus standard designed to allow microcontrollers and devices to communicate with each other in applications without a host computer.

[0037] In one embodiment, sensor system 305 includes, but is not limited to, one or more cameras 306, a Global Positioning System (GPS) unit 307, an Inertial Measurement Unit (IMU) 308, a radar unit 309, and a Light Detection and Ranging (LiDAR) unit 310. GPS unit 307 may include a transceiver operable to provide information about the position of autonomous vehicle 104. IMU 308 may sense changes in the position and orientation of autonomous vehicle 104 based on inertial acceleration. Radar unit 309 may represent a system that uses radio waves to sense objects in the local environment of autonomous vehicle 104. In one embodiment, in addition to sensing objects, radar unit 309 may also sense the velocity and / or heading of objects. LiDAR unit 310 may use lasers to sense objects in the environment in which autonomous vehicle 104 is located. LiDAR unit 310 may include one or more laser sources, a laser scanner, and one or more detectors, as well as other system components. Camera 306 may include one or more devices for capturing images of the environment surrounding autonomous vehicle 104. Camera 306 may be a still camera and / or a video camera. The camera may be mechanically movable, for example, by mounting the camera on a rotating and / or tilting platform.

[0038] Sensor system 305 may also include other sensors, such as sonar sensors, infrared sensors, steering sensors, throttle sensors, brake sensors, and audio sensors (e.g., microphones). Audio sensors can be configured to capture sound from the environment surrounding the autonomous vehicle. Steering sensors can be configured to sense the steering angle of the steering wheel, the vehicle's wheels, or a combination thereof. Throttle and brake sensors sense the vehicle's throttle and brake positions, respectively. In some cases, the throttle and brake sensors can be integrated into an integrated throttle / brake sensor.

[0039] In one embodiment, the vehicle control system 302 includes, but is not limited to, a steering unit 311, a throttle unit 312 (also referred to as an acceleration unit), and a braking unit 313. The steering unit 311 is used to adjust the direction or heading of the vehicle. The throttle unit 312 is used to control the speed of the electric motor or engine, thereby controlling the speed and acceleration of the vehicle. The braking unit 313 is used to decelerate the vehicle by providing friction to slow down the wheels or tires.

[0040] Furthermore, in one embodiment, the wireless communication system 303 is used to allow communication between the autonomous vehicle 104 and external systems, such as edge server 101 and edge server controller 103. For example, the wireless communication system 303 can wirelessly communicate with one or more devices directly or via a communication network (such as via edge server 101 on network 102). The wireless communication system 303 can use any cellular communication network or wireless local area network (WLAN) (e.g., using WiFi to communicate with another component or system). The wireless communication system 303 can communicate directly with devices (e.g., speakers within the autonomous vehicle 104) for example using infrared links, Bluetooth, etc.

[0041] In one embodiment, the user interface system 304 is part of the peripheral devices implemented in the autonomous vehicle 104, including, for example, a keyboard, a touch screen display device, a microphone, a speaker, etc.

[0042] Some or all of the functions of the autonomous vehicle 104 can be controlled or managed by the perception and planning system 301, especially when operating in autonomous driving mode. The perception and planning system 301 includes the necessary hardware (e.g., processor, memory, storage device) and software (e.g., operating system, planning and routing program) to receive information from the sensor system 305, the vehicle control system 302, the wireless communication system 303, and / or the user interface system 304; process the received information; plan a route or path from the starting point to the destination; and then drive the autonomous vehicle 104 based on the planning and control information. Alternatively, the perception and planning system 301 can be integrated with the vehicle control system 302.

[0043] For example, edge server 101 and / or edge server controller 103 may specify the start and destination (e.g., parking space) of a trip via a user interface. The perception and planning system 301 acquires trip-related data. For example, the perception and planning system 301 may obtain location and route information from edge server 101 and / or edge server controller 103. For example, edge server 101 provides location and map services. Alternatively, this location and map service information may be cached in persistent storage of the perception and planning system 301.

[0044] As the autonomous vehicle 104 moves along the route, the perception and planning system 301 can also obtain real-time traffic information from the edge server 101 and / or the edge server controller 103, which obtains this information from a traffic information system or server (TIS). Based on the real-time traffic information, location information, and real-time local environmental data (e.g., obstacles, objects, nearby vehicles) detected or sensed by the sensor system 305, the edge server 101, the edge server controller 103, and / or the perception and planning system 301 can plan an optimal route, wherein the perception and planning system 301 drives the autonomous vehicle 104 according to the planned route, for example via the vehicle control system 302, to safely and efficiently reach the designated destination.

[0045] In one embodiment, the perception and planning system 301 includes a memory 314 for storing a positioning module 315, a perception module 316, a prediction module 317, a decision module 318, a planning module 319, a control module 320, a routing module 321, and a controller interface module 322.

[0046] In one embodiment, these modules (modules 315-322) are mounted in persistent storage device 323, loaded into memory 314, and executed by one or more processors (not shown). It should be noted that some or all of these modules can be coupled with... Figure 3 Some or all of the modules of the vehicle control system 302 are communicatively coupled or integrated. Some of the modules 315-322 can be integrated together as an integrated module.

[0047] In one embodiment, the positioning module 315 determines the current location of the autonomous vehicle 104 (e.g., using GPS unit 307) and manages any data related to the trip or route of the autonomous vehicle 104. The positioning module 315 (also referred to as the map and route module) manages any data related to the trip or route of the autonomous vehicle 104. The positioning module 315 communicates with other components (such as map and route information 324) to obtain trip-related data. For example, the positioning module 315 may obtain location and route information from the edge server 101 and / or the edge server controller 103. The edge server 101 and / or the edge server controller 103 provides location and map services, which may be cached as part of the map and route information 324. As the autonomous vehicle 104 moves along the route, the positioning module 315 may also obtain real-time traffic information from the edge server 101 and / or the edge server controller 103 and / or a traffic information system or server.

[0048] Based on sensor data provided by sensor system 305 and positioning information obtained by positioning module 315, perception module 316 determines the perception of the surrounding environment. Perception information can represent the environment surrounding the vehicle as perceived by an average driver. Perception may include lane configuration, traffic light signals, the relative positions of other vehicles, pedestrians, buildings, crosswalks, or other traffic-related signs (e.g., stop signs, yield signs), for example, in the form of objects. Lane configuration includes information describing one or more lanes, such as, for example, the shape of the lane (e.g., straight or curved), the width of the lane, the number of lanes on the road, whether it is a one-way or two-way road, merging or split lanes, exit lanes, etc.

[0049] The perception module 316 may include a computer vision system or the functionality of a computer vision system to process and analyze images captured by one or more cameras to identify objects and / or features in the environment of the autonomous vehicle 104. Objects may include traffic signals, road boundaries, other vehicles, pedestrians and / or obstacles, etc. The computer vision system may use object recognition algorithms, video tracking, and other computer vision techniques. In some embodiments, the computer vision system may map the environment, track objects, and estimate the velocity of objects, etc. The perception module 316 may also detect objects based on additional data provided by other sensors, such as radar and / or LiDAR.

[0050] For each object, prediction module 317 predicts how the object will behave in that situation. The prediction is based on the perception module 316's perception of the driving environment at a given point in time, taking into account a set of map and route information 324 and driving / traffic rules 325. For example, if the object is an oncoming vehicle and the current driving environment includes an intersection, prediction module 317 will predict whether the vehicle is likely to continue straight or turn. If the perception data indicates that there are no traffic lights at the intersection, prediction module 317 can predict that the vehicle may have to come to a complete stop before entering the intersection. If the perception data indicates that the vehicle is currently in a left-turn-only lane or a right-turn-only lane, prediction module 317 can predict that the vehicle is more likely to turn left or right, respectively.

[0051] For each object, decision module 318 makes a decision on how to handle that object. For example, given a specific object (e.g., another vehicle at an intersection) and metadata describing that object (e.g., speed, direction, steering angle), decision module 318 decides how to encounter the object (e.g., overtake, yield, stop, pass). Decision module 318 can make such decisions based on a set of rules (such as traffic rules or driving rules 325), which can be stored in persistent storage device 323.

[0052] In one embodiment, edge server 101 and / or edge server controller 103 and / or routing module 321 are configured to provide one or more routes or paths from a starting point to a destination. In one embodiment, for a given trip from a starting location to a destination location, for example, a trip received from edge server 101 and / or edge server controller 103, routing module 321 acquires map and route information 324 and determines all possible routes or paths from the starting location to the destination location. Routing module 321 may generate reference lines in the form of topographic maps for each route it determines from the starting location to the destination location. A reference line is an ideal route or path free from interference from others, such as other vehicles, obstacles, or traffic conditions. That is, if there are no other vehicles, pedestrians, or obstacles on the road, the autonomous vehicle should follow the reference line precisely or nearly. The topographic map is then provided to decision module 318 and / or planning module 319. The decision module 318 and / or planning module 319 consider other data provided by other modules (such as traffic conditions from the positioning module 315, the driving environment perceived by the perception module 316, and the traffic conditions predicted by the prediction module 317) to examine all possible routes in order to select and modify one of the optimal routes. The actual path or route used to control the autonomous vehicle 104 may be the same as or different from the reference line provided by the edge server 101 and / or the edge server controller 103 and / or the routing module 321, depending on the specific driving environment at this point in time.

[0053] Based on decisions made for each perceived object, the planning module 319 uses reference lines provided by the routing module 321 as a basis to plan the path or route of the autonomous vehicle 104 and driving parameters (e.g., distance, speed, and / or steering angle). Alternatively, such paths or routes and driving parameters (e.g., distance, speed, and / or steering angle) are received from the edge server 101 and / or the edge server controller 103.

[0054] In one embodiment, for a given object, decision module 318 decides how to handle the object, while planning module 319 determines how to perform that operation. For example, for a given object, decision module 318 may decide to pass the object, while planning module 319 may determine whether to pass to the left or right of the object. Planning and control data is generated by planning module 319 and includes information describing how the autonomous vehicle 104 moves in the next movement cycle (e.g., the next route / path segment). For example, planning and control data may instruct the autonomous vehicle 104 to move 10 meters at a speed of 30 miles per hour (mph) and then change to the right lane at a speed of 25 mph.

[0055] Based on planning and control data, control module 320 controls and drives autonomous vehicle 104 according to a route or path defined by the planning and control data by sending appropriate commands or signals to vehicle control system 302. The planning and control data includes sufficient information to drive the vehicle from one point to another along the route or path at different points in time using appropriate vehicle settings or driving parameters (e.g., throttle, braking, steering commands).

[0056] In one embodiment, the planning phase is executed over multiple planning cycles, also known as driving cycles, for example, in 100-millisecond (ms) time intervals. For each planning cycle or driving cycle, one or more control commands are issued based on planning and control data. That is, for every 100ms, planning module 319 plans the next route segment or path segment, including, for example, the target location and the time required for the autonomous vehicle 104 to reach the target location. Alternatively, planning module 319 may also specify specific speeds, directions, and / or steering angles, etc. In one embodiment, planning module 319 plans the route segment or path segment for the next predetermined time interval (e.g., 5 seconds). For each planning cycle, planning module 319 plans the target location for the current cycle (e.g., the next 5 seconds) based on the target location planned in the previous cycle. Then, control module 320 generates one or more control commands (e.g., throttle, brake, steering control commands) based on the planning and control data of the current cycle.

[0057] It should be noted that the decision module 318 and the planning module 319 can be integrated together as an integrated module. The decision module 318 / planning module 319 may include a navigation system or the functionality of a navigation system to determine the driving path of the autonomous vehicle 104. For example, the navigation system may determine a series of speeds and directions to influence the movement of the autonomous vehicle 104 along a path that substantially avoids perceived obstacles while ensuring that the autonomous vehicle 104 generally travels along a road leading to a final destination. The destination can be set based on input from the edge server 101 and / or the edge server controller 103. The navigation system can dynamically update the driving path while the autonomous vehicle 104 is running. The navigation system may combine data from a GPS system and one or more maps to determine the driving path of the autonomous vehicle 104.

[0058] In one embodiment, the controller interface module 322 is configured to communicate with the edge server 101 and / or the edge server controller 103, and to receive control commands from the edge server 101 and / or the edge server controller 103. When the edge server 101 and / or the edge server controller 103 issues commands to the autonomous vehicle 104, these commands are forwarded to the control module 320. The control module 320 can generate control signals based on the commands received from the edge server 101 and / or the edge server controller 103 to operate the autonomous vehicle 104.

[0059] As mentioned above, the following is combined Figure 4 This section provides a discussion of the internal components of edge server 101 and edge server controller 103.

[0060] Figure 4 Internal components of an edge server 101 and an edge server controller 103 for controlling an autonomous vehicle (e.g., autonomous vehicle 104) based on edge server resources, according to embodiments of the present disclosure, are shown.

[0061] refer to Figure 4 , combined Figure 1-3 Edge server 101 includes a module referred to herein as “vehicle support” 401, which is configured to establish edge server load (i.e., estimate the load of edge server 101).

[0062] As described above, load, as used herein, refers to the amount of work that edge server 101 is processing at a given time. In one embodiment, vehicle support 401 estimates the load that edge server 101 will process in the near future, for example, in the next 5 minutes.

[0063] In one embodiment, the vehicle support unit 401 obtains the current load being processed by the edge server 101 from a component referred to herein as "self-monitor" 402. In one embodiment, self-monitor 402 utilizes a resource monitor to monitor the current load being processed by the edge server 101. In one embodiment, self-monitor 402 utilizes various software tools to monitor the current load being processed by the edge server 101, including but not limited to Sematext Monitoring, SolarWinds® Server & Application Manager, Dynatrace®, Datadog®, ManageEngine® OpManager, etc.

[0064] In one embodiment, the vehicle support 401 obtains the load of the adjacent edge server 101 from the edge monitor 403 in the edge server controller 103. As used herein, "adjacent edge server" means an edge server (e.g., edge server 101B) located in proximity to the edge server in question (e.g., edge server 101A), such as edge server 101 having a coverage area (e.g., coverage area 201B) adjacent to the coverage area (e.g., coverage area 201A) of the edge server in question.

[0065] In one embodiment, edge monitor 403 utilizes a resource monitor to monitor the current load being processed by the adjacent edge server 101. In another embodiment, edge monitor 403 utilizes various software tools to monitor the current load being processed by the adjacent edge server 101, including but not limited to Sematext Monitoring, SolarWinds® Server & Application Manager, Dynatrace®, Datadog®, ManageEngine® OpManager, etc.

[0066] In one embodiment, edge monitor 403 obtains the current load being processed by the neighboring edge server 101 itself, for example, via the neighboring edge server 101's self-monitor 402.

[0067] In one embodiment, the vehicle support 401 obtains the number of autonomous vehicles 104 entering / leaving within the coverage area (e.g., coverage area 201) of the edge server 101 from the vehicle manager 404 of the edge server controller 103. In one embodiment, the vehicle manager 404 is configured to manage the routes traveled by the autonomous vehicles 104, including their destinations. By managing the routes traveled by the autonomous vehicles 104, the vehicle manager 404 obtains the number of autonomous vehicles 104 entering and leaving the coverage area 201 of the edge server 101.

[0068] In one embodiment, vehicle manager 404 uses various software tools (including but not limited to Drive AV, OnFleet, etc.). ® (IntelliShift, etc.) manage the routes traveled by autonomous vehicles 104.

[0069] Furthermore, in one embodiment, the vehicle support unit 401 receives contextual information from the environment coordinator 405 of the edge server 101. This contextual information includes information that a human driver typically considers when driving and adapting to their driving, such as weather, road conditions, other vehicles, pedestrians, road signs, etc. In one embodiment, this contextual information may exist at least in part in the form of video information obtained from the cameras (e.g., camera 306) of the autonomous vehicle 104.

[0070] In one embodiment, the vehicle supporter 401 estimates the load that the edge server 101 will handle in the near future, such as in the next 5 minutes, based on the current edge server load, the estimated load of neighboring edge servers 101, the number of autonomous vehicles 104 entering / leaving the coverage area 201 of the edge server 101, and contextual information.

[0071] For example, in order to determine an appropriate estimate of the edge server load, it is necessary to obtain the number of autonomous vehicles 104 residing within the coverage area 201 of the edge server 101 when calculating the edge server load. This information can be obtained based on the number of autonomous vehicles 104 entering / leaving the coverage area 201 of the edge server 101.

[0072] In another example, to determine an appropriate estimate of the edge server load that edge server 101 will handle in the near future, it is necessary to identify an estimate of the server load currently handled by neighboring edge servers 101, and that will have to be handled by the edge server 101 in the near future as autonomous vehicles 104 travel from the coverage area of ​​neighboring edge servers 101 (e.g., coverage area 201B) to the coverage area of ​​the edge server 101 in question (e.g., coverage area 201A). This information can be obtained based on the number of autonomous vehicles 104 entering / leaving and the estimated load of neighboring edge servers 101 (including the estimated load for handling transactions involving such autonomous vehicles 104 traveling from the coverage area of ​​neighboring edge servers 101 (e.g., coverage area 201B) to the coverage area of ​​the edge server 101 in question (e.g., coverage area 201A).

[0073] Furthermore, in order to determine an appropriate estimate of the edge server load that edge server 101 will handle in the near future, it is necessary to identify an estimate of the server load currently being handled by edge server 101, but which will no longer be required to be handled by edge server 101 as autonomous vehicle 104 travels from the coverage area of ​​edge server 101 (e.g., coverage area 201A) to the coverage area of ​​an adjacent edge server 101 (e.g., coverage area 201B). This information can be obtained based on the number of autonomous vehicles 104 entering / leaving and the estimated load of edge server 101 (including the estimated load for handling transactions involving such autonomous vehicles 104 traveling from the coverage area of ​​edge server 101 (e.g., coverage area 201A) to the coverage area of ​​an adjacent edge server 101 (e.g., coverage area 201B).

[0074] In a further example, to determine an appropriate estimate of the edge server load that edge server 101 will handle in the near future, contextual information can be used to determine how many transactions might potentially need to be processed by edge server 101. For example, if road conditions are poor, such as due to rainy weather, it can be inferred that edge server 101 will have to handle more transactions than normal. In another example, if autonomous vehicle 104 is traveling in a congested area (e.g., traffic jam), it can be inferred that edge server 101 will have to handle more transactions than normal.

[0075] In one embodiment, the vehicle support unit 401 uses various software tools (including but not limited to Sematext Monitoring, SolarWinds) based on the aforementioned information (e.g., current edge server load, estimated load of neighboring edge servers 101, number of autonomous vehicles 104 entering / leaving the coverage area 201 of edge server 101, and context information). ® Server & Application Manager, Dynatrace ® Datadog ® ManageEngine ® OpManager, etc., estimates the load that edge server 101 will handle in the near future (such as within the next 5 minutes).

[0076] In one embodiment, vehicle support 401 determines whether the estimated load of edge server 101 (e.g., edge server 101A) exceeds a threshold, which may be user-specified.

[0077] If the estimated load of edge server 101 (e.g., edge server 101A) exceeds a threshold, the self-configurer 406 of vehicle support 401 determines whether there is a load reduction plan to be applied to any autonomous vehicle 104 under the control of edge server 101 (i.e., any autonomous vehicle 104 residing within the coverage area 201 of edge server 101).

[0078] For example, in one embodiment, autonomous vehicle 104 may be associated with a load reduction plan. A “load reduction plan,” as used herein, refers to a strategy for reducing the load on edge server 101 (e.g., edge server 101A) by controlling autonomous vehicle 104 (e.g., autonomous vehicle 104A) in some way, such as modifying the route of autonomous vehicle 104, modifying the movement of autonomous vehicle 104, modifying the frequency of sending vehicle data, offloading computations previously performed in edge server 101 to be performed in autonomous vehicle 104, or having autonomous vehicle 104 join a fleet of other autonomous vehicles 104, etc.

[0079] For example, a load reduction plan could instruct the autonomous vehicle 104 to reduce the frequency of transmitting data obtained from the sensor system 305.

[0080] In another example, a load reduction plan could involve creating a fleet group (a group of autonomous vehicles 104 participating in the same activity), thereby reducing the amount of sensor data that needs to be sent and received by the edge server 101. For example, such a fleet group could correspond to autonomous vehicles 104 with similar route plans.

[0081] In another example, a load reduction plan could include a strategy to navigate autonomous vehicle 104 to other areas with less traffic, where fewer transactions need to be handled by edge server 101.

[0082] In a further example, the load reduction plan could involve reducing the amount of information that needs to be processed by the edge server 101 by lowering the required resolution of images (e.g., images captured by camera 306) sent from the autonomous vehicle 104 to the edge server 101.

[0083] In addition, another example of a load reduction plan involves having multiple autonomous vehicles 104 (such as drones) fly in formation, thereby reducing the workload (processing) on ​​the edge server 101, since the location information of a particular autonomous vehicle 104 can be found from the location information of all other autonomous vehicles 104 flying in the same formation.

[0084] In one embodiment, such load reduction plans may be stored in a data structure (e.g., a table) on the edge server 101, which may reside within the storage device of the edge server 101. In one embodiment, such a data structure includes a list of load reduction plans and the associated autonomous vehicles 104 to which such load reduction plans should be applied. For example, a particular load reduction plan may be applied to multiple autonomous vehicles 104 (e.g., autonomous vehicles 104A, 104B). After identifying the autonomous vehicles 104 within the coverage area 201 of the edge server 101, the self-configurer 406 searches the data structure for matching autonomous vehicles 104, such as by identifiers associated with these autonomous vehicles 104, and then identifies the corresponding load reduction plan to be implemented for these autonomous vehicles 104. In one embodiment, such a data structure is populated by experts.

[0085] In addition, such as Figure 4 As shown, the vehicle support unit 401 includes a load balancing coordinator 407, which is configured to determine whether the adjacent edge server 101 is capable of handling additional workloads.

[0086] If any adjacent edge server 101 (e.g., edge server 101B) is capable of handling additional workload, the load balancer coordinator 407 requests the edge load balancer 408 of the edge server controller 103 to instruct one or more autonomous vehicles 104 currently under the control of edge server 101 (e.g., edge server 101A) and possibly also under the current control of adjacent edge server 101 (e.g., edge server 101B) to be rerouted to coverage area 201 (e.g., coverage area 201B) under the control of adjacent edge server 101 (e.g., edge server 101B), so that adjacent edge server 101 has greater or complete control over autonomous vehicles 104, thereby relieving the load on edge server 101 (e.g., edge server 101A).

[0087] For example, such as Figure 2 As shown, the load balancer 407 requests the edge load balancer 408 of the edge server controller 103 to instruct the autonomous vehicle 104' to reroute from the coverage area 201 (e.g., coverage area 201B) under the control of the edge server 101B to the coverage area 201 (e.g., coverage area 201A) under the control of an adjacent edge server 101 (e.g., edge server 101A) in order to relieve the load on the edge server 101B.

[0088] Furthermore, in one embodiment, the vehicle supporter 401 is configured to restrict or prohibit the driving of one or more autonomous vehicles 104 (such as those autonomous vehicles 104 located in coverage area 201 (e.g., coverage area 201A) under the control of edge server 101 (e.g., edge server 101A)) in a manner that reduces the load on edge server 101 (e.g., edge server 101A). For example, the vehicle supporter 401 may prohibit autonomous vehicles 104 under the control of edge server 101 from making lane changes. When autonomous vehicles 104 are prevented from making lane changes, driving behavior analysis is reduced. In another example, the vehicle supporter 401 prevents autonomous vehicles 104 under the control of edge server 101 from entering areas covered by edge server 101, such as areas that may cause a greater load (e.g., a larger number of transactions) on edge server 101 (e.g., congested areas).

[0089] In one embodiment, such as Figure 2As shown, this restricted or prohibited driving is dynamically reflected on the map. For example, map 200 includes sign 202 (a do not enter sign), which indicates that the autonomous vehicle 104 must not enter such an area. In another example, map 200 includes sign 203 (a do not change lanes sign), which indicates that the autonomous vehicle 104 must not change lanes in such an area.

[0090] In addition, such as Figure 4 As shown, the edge server controller 103 stores location data, such as the location of the edge server 101 and the autonomous vehicle 104, in the database 409.

[0091] In this way, autonomous vehicles can be controlled using resources based on edge servers, and transactions (such as those involving autonomous vehicles) can be processed during peak hours using the limited computing resources of edge servers.

[0092] Further descriptions of these and other features are provided below in connection with a discussion of methods for handling transactions with the limited resources of edge servers during peak hours by controlling autonomous vehicles using edge server-based resources.

[0093] Before discussing methods for controlling autonomous vehicles using edge server resources to process transactions during peak hours, let's combine the following... Figure 5 Edge server 101 is provided Figure 1 , Figure 4 ) and Edge Server Controller 103 ( Figure 1 , Figure 4 Description of the hardware configuration.

[0094] Now for reference Figure 5 and combined Figure 1 , Figure 5 The illustration shows an embodiment of the hardware configuration of edge server 101 and edge server controller 103, representing a hardware environment for practicing the present disclosure.

[0095] Various aspects of this disclosure are described by narrative text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in embodiments of a computer program product (CPP). Regarding any flowchart, depending on the technology involved, operations may be performed in a different order than that shown in a given flowchart. For example, again according to the technology involved, two operations shown in consecutive flowchart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in a manner that at least partially overlaps in time.

[0096] Computer Program Product Embodiment (“CPP Embodiment” or “CPP”) is a term used in this disclosure to describe any collection of one or more storage media (also referred to as “media”) collectively included in a collection of one or more storage devices, the collection of one or more storage devices collectively including machine-readable code corresponding to instructions and / or data for performing computer operations specified in a given CPP claim. A “storage device” is any tangible device capable of holding and storing instructions used by a computer processor. Without limitation, a computer-readable storage medium can be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include: magnetic disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punch cards or pits / platforms formed in the main surface of the disk), or any suitable combination of the foregoing. Computer-readable storage media, as used in this disclosure, should not be construed as storing transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, optical pulses through fiber optic cables, electrical signals transmitted through wires, and / or other transmission media. As those skilled in the art will understand, data is typically moved at certain incidental points in time during the normal operation of the storage device, such as during access, defragmentation, or garbage collection; however, this does not render the storage device transient, as the data is not transient when it is stored.

[0097] The computing environment 500 includes examples of an environment for executing at least some of the computer code (stored in block 501) that involves performing the disclosed methods, such as processing transactions with the limited resources of an edge server during peak hours by controlling an autonomous vehicle using resources based on the edge server. In addition to block 501, the computing environment 500 also includes, for example, an edge server 101, an edge server controller 103, and a wide area network (WAN) 524 (in one embodiment, WAN 524 corresponds to...). Figure 1The network 102), end-user equipment (EUD) 502, remote server 503, public cloud 504, and private cloud 505 are included. In this embodiment, edge server 101 and edge server controller 103 include processor set 506 (including processing circuitry 507 and cache 508), communication structure 509, volatile memory 510, persistent storage 511 (including operating system 512 and block 501 as described above), peripheral device set 513 (including user interface (UI) device set 514, storage 515, and Internet of Things (IoT) sensor set 516), and network module 517. Remote server 503 includes remote database 518. Public cloud 504 includes gateway 519, cloud orchestration module 520, host physical machine set 521, virtual machine set 522, and container set 523.

[0098] Edge server 101 and edge server controller 103 can take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device now known or to be developed in the future capable of running programs, accessing networks, or querying databases such as remote database 518. As is well known in the field of computer technology, and depending on that technology, the execution of computer-implemented methods can be distributed among multiple computers and / or multiple locations. On the other hand, in this presentation of computing environment 500, the detailed discussion focuses on a single computer, specifically edge server 101 and edge server controller 103, to keep the presentation as simple as possible. Edge server 101 and edge server controller 103 can reside in the cloud, even... Figure 5 It is not shown in the cloud. On the other hand, unless explicitly instructed otherwise, edge server 101 and edge server controller 103 are not required to be in the cloud.

[0099] Processor set 506 includes one or more computer processors of any type now known or to be developed in the future. Processing circuitry 507 may be distributed across multiple packages, such as multiple cooperating integrated circuit chips. Processing circuitry 507 may implement multiple processor threads and / or multiple processor cores. Cache 508 is memory located within the processor chip package and is typically used for data or code that should be available for fast access by the threads or cores running on processor set 506. Cache memory is typically organized into multiple levels based on its relative proximity to the processing circuitry. Alternatively, some or all of the cache in the processor set may be located “off-chip.” In some computing environments, processor set 506 may be designed to work with qubits and perform quantum computing.

[0100] Computer-readable program instructions are typically loaded onto edge server 101 and edge server controller 103 to cause the processor set 506 of edge server 101 and edge server controller 103 to perform a series of operational steps to implement a computer-implemented method, such that the instructions thus executed instantiate the method specified in the flowcharts and / or descriptive descriptions of the computer-implemented method included in this document (collectively, the “disclosed method”). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 508 and other storage media discussed below. The program instructions and associated data are accessed by processor set 506 to control and direct the execution of the disclosed method. In computing environment 500, at least some of the instructions for performing the disclosed method may be stored in block 501 of persistent storage 511.

[0101] Communication structure 509 is a signal transmission path that allows various components of edge server 101 and edge server controller 103 to communicate with each other. Typically, this structure consists of switches and conductive paths, such as switches and conductive paths forming buses, bridges, physical input / output ports, etc. Other types of signal communication paths can be used, such as fiber optic communication paths and / or wireless communication paths.

[0102] Volatile memory 510 is any type of volatile memory now known or to be developed in the future. Examples include dynamically typed random access memory (RAM) or statically typed RAM. Typically, volatile memory is characterized by random access, but this is not necessary unless explicitly indicated. In edge server 101 and edge server controller 103, volatile memory 510 is located in a single package and is internal to edge server 101 and edge server controller 103; however, alternatively or additionally, volatile memory may be distributed across multiple packages and / or located externally relative to edge server 101 and edge server controller 103.

[0103] Persistent storage 511 is any form of non-volatile storage for a computer, now known or to be developed in the future. The non-volatility of this storage means that the stored data is retained regardless of whether power is supplied to edge server 101, edge server controller 103, and / or directly to persistent storage 511. Persistent storage 511 may be read-only memory (ROM), but typically at least a portion of persistent storage allows for data writing, data deletion, and data rewriting. Some common forms of persistent storage include disks and solid-state storage devices. Operating system 512 can take several forms, such as various known proprietary operating systems or operating systems employing an open-source portable operating system interface type with a kernel. The code included in block 501 generally includes at least some of the computer code involved in performing the methods disclosed herein.

[0104] Peripheral device set 513 includes a collection of peripheral devices for edge server 101 and edge server controller 103. Data communication connections between peripheral devices and other components of edge server 101 and edge server controller 103 can be implemented in various ways, such as Bluetooth connections, near field communication (NFC) connections, connections made by cables (such as Universal Serial Bus (USB) type cables), plug-in connections (e.g., secure digital (SD) cards), connections made through local area communication networks, and even connections made through wide area networks such as the Internet. In various embodiments, UI device set 514 may include components such as displays, speakers, microphones, wearable devices (such as glasses and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. Storage 515 is an external storage device, such as an external hard drive, or a pluggable storage device, such as an SD card. Storage 515 can be persistent and / or volatile. In some embodiments, storage 515 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where edge server 101 and edge server controller 103 require substantial storage (e.g., where edge server 101 and edge server controller 103 locally store and manage large databases), this storage can be provided by peripheral storage devices designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. The IoT sensor set 516 consists of sensors that can be used in IoT applications. For example, one sensor could be a thermometer, while another could be a motion detector.

[0105] Network module 517 is a collection of computer software, hardware, and firmware that allows edge server 101 and edge server controller 103 to communicate with other computers via WAN 524. Network module 517 may include hardware such as a modem or Wi-Fi transceiver, software for packetizing and / or depacketizing data for transmission over a communication network, and / or web browser software for transmitting data over the Internet. In some embodiments, the network control and network forwarding functions of network module 517 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software-defined networking (SDN), the control and forwarding functions of network module 517 are performed on physically separate devices, such that the control function manages several different network hardware devices. Computer-readable program instructions for performing the disclosed methods can typically be downloaded to edge server 101 and edge server controller 103 from an external computer or external storage device via a network adapter card or network interface included in network module 517.

[0106] A WAN (Wide Area Network) is any wide area network (e.g., the Internet) capable of transmitting computer data over non-local distances using any technology known now or developed in the future for transmitting computer data. In some embodiments, a WAN may be replaced by and / or supplemented by a local area network (LAN) designed to transmit data between devices located in a local area, such as a Wi-Fi network. WANs and / or LANs typically include computer hardware such as copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers.

[0107] End User Equipment (EUD) 502 is any computer system used and controlled by an end user (e.g., a customer of an enterprise operating Edge Server 101 or Edge Server Controller 103), and can take any of the forms discussed above in conjunction with Edge Server 101 and Edge Server Controller 103. EUD 502 typically receives helpful and useful data from the operation of Edge Server 101 or Edge Server Controller 103. For example, assuming that Edge Server 101 or Edge Server Controller 103 is designed to provide recommendations to end users, these recommendations are typically transmitted to EUD 502 via WAN 524 from network module 517 of Edge Server 101 or Edge Server Controller 103. In this way, EUD 502 can display or otherwise present recommendations to the end user. In some embodiments, EUD 502 can be a client device, such as a thin client, a thick client, a mainframe computer, a desktop computer, etc.

[0108] Remote server 503 is any computer system that provides at least some data and / or functionality to edge server 101 and edge server controller 103. Remote server 503 can be controlled and used by the same entity operating edge server 101 and edge server controller 103. Remote server 503 represents a machine that collects and stores helpful and useful data used by other computers such as edge server 101 and edge server controller 103. For example, if edge server 101 and edge server controller 103 are designed and programmed to provide recommendations based on historical data, that historical data can be provided to edge server 101 and edge server controller 103 from a remote database 518 of remote server 503.

[0109] Public cloud 504 is any computer system that can be used by multiple entities, providing on-demand availability of computer system resources and / or other computing capabilities (especially data storage (cloud storage) and computing power) without direct active management by the user. Cloud computing typically leverages resource sharing to achieve scalability consistency and economy. Direct and active management of the computing resources of public cloud 504 is performed by the computer hardware and / or software of cloud orchestration module 520. The computing resources provided by public cloud 504 are typically implemented by virtual computing environments running on various computers constituting host physical set 521, which is the entire domain of physical computers in and / or available to the public cloud 504. Virtual computing environments (VCEs) typically take the form of virtual machines from virtual machine set 522 and / or containers from container set 523. It should be understood that these VCEs can be stored as images and can be transferred between various physical machine hosts as images or after the VCEs are instantiated. Cloud orchestration module 520 manages the transfer and storage of images, deploys new instantiations of VCEs, and manages active instantiation of VCE deployments. Gateway 519 is a collection of computer software, hardware, and firmware that allows public cloud 504 to communicate over WAN 524.

[0110] Now, we will provide some further explanation of Virtualized Computing Environments (VCEs). A VCE can be stored as an "image." A new active instance of a VCE can be instantiated from this image. Two common types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to an operating system feature where the kernel allows multiple isolated user-space instances, called containers, to exist. From the perspective of the programs running within them, these isolated user-space instances typically appear as actual computers. Computer programs running on a regular operating system can utilize all the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running within a container can only use the contents of the container and the devices allocated to the container; this is a characteristic known as containerization.

[0111] Private cloud 505 is similar to public cloud 504, except that computing resources are available only to a single enterprise. While private cloud 505 is depicted as communicating with WAN 524, in other embodiments, private cloud may be completely disconnected from the Internet and accessible only via a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types) typically implemented by different vendors. Each of the multiple clouds remains a separate and discrete entity, but the larger hybrid cloud architecture is bound together by standardization or proprietary technology that enables orchestration, management, and / or data / application portability across the multiple component clouds. In this embodiment, public cloud 504 and private cloud 505 are both part of a larger hybrid cloud.

[0112] Block 501 also includes the above and Figure 2-4 The related software components are designed to utilize the limited resources of the edge server to handle peak-hour transactions by controlling autonomous vehicles using edge server resources. In one embodiment, such components can be implemented in hardware. The functions performed by such components are not general-purpose computer functions. Therefore, the edge server 101 and the edge server controller 103 are specific machines that result in the implementation of specific and non-general-purpose computer functions.

[0113] In one embodiment, the functionality of such software components as edge server 101 and edge server controller 103 (including the ability to utilize the limited resources of the edge server to process transactions during peak hours by controlling autonomous vehicles based on the edge server's resources) can be embodied in an application-specific integrated circuit (ASIC).

[0114] As mentioned above, autonomous vehicles have the ability to continuously monitor their surroundings using sensor arrays, including cameras, radar, and lidar. These sensors provide a 360-degree view of the vehicle's environment, enabling it to detect any potential obstacles, pedestrians, or other vehicles with high precision. Advanced algorithms interpreting this data can make instantaneous decisions to avoid collisions and safely navigate through complex situations. Autonomous vehicle movement involving this type of autonomous vehicle movement can be achieved using edge computing. Edge computing refers to an architecture of distributed computing paradigms that brings computation and data storage closer to the data source. Edge computing can be implemented using edge servers, which correspond to servers located at the network edge close to the end user. Such edge servers can be utilized to handle various tasks, such as controlling autonomous vehicles in relation to handling traffic congestion, optimizing routes for autonomous vehicles, adjusting vehicle speeds, and efficiently merging autonomous vehicles. This control of autonomous vehicles requires significant computing resources. Therefore, at certain times, the load on the edge server (the amount of work processed by the edge server at a given time) can be enormous, including periods when the edge server experiences peak load (the maximum amount of work the edge server can handle at a given time). The times when the edge server experiences peak load are called "peak hours." To address situations where edge servers may be limited in transaction processing (e.g., during peak hours), transactions can be temporarily offloaded to adjacent edge servers or cloud servers. However, this reduces the latency and accuracy of the computational analysis performed by the edge servers. Another alternative to addressing peak loads on edge servers during peak hours is to deploy additional edge servers. Unfortunately, this solution incurs additional costs, which can be substantial. Therefore, there is currently no method to utilize the limited computing resources of edge servers to process transactions during peak hours (such as transactions involving autonomous vehicles).

[0115] Embodiments of this disclosure provide a method for utilizing the limited computing resources of edge servers to process transactions during peak hours by reducing the peak load of edge servers cooperating among multiple autonomous vehicles and multiple edge servers through edge server resource control of autonomous vehicles, as follows: Figure 6-7 As discussed in the related articles. Figure 6 This is a flowchart illustrating a method for handling transactions during peak hours by utilizing the limited resources of edge servers to control autonomous vehicles based on edge server resources. Figure 7 It is a flowchart of a method for implementing actions to reduce the load on edge servers by controlling autonomous vehicles to operate in a certain way.

[0116] As mentioned above, Figure 6This is a flowchart of a method 600 for processing transactions during peak hours by utilizing the limited resources of an edge server (e.g., edge server 101) through resource control of an autonomous vehicle based on an edge server, according to embodiments of the present disclosure.

[0117] refer to Figure 6 , combined Figure 1-5 In operation 601, the vehicle support 401 of the edge server 101 estimates the load of the edge server 101 (e.g., edge server 101A), and the edge server 101 controls the autonomous vehicle 104 located in the coverage area 201 (e.g., coverage area 201A) of the edge server.

[0118] As described above, and as used herein, load refers to the amount of work processed by edge server 101 at a given time. In one embodiment, vehicle support 401 estimates the load that edge server 101 will process in the near future, for example, in the next 5 minutes.

[0119] In one embodiment, the vehicle support unit 401 obtains the current load being processed by the edge server 101 from a component called a "self-monitor" 402. In one embodiment, the self-monitor 402 utilizes a resource monitor to monitor the current load being processed by the edge server 101. In one embodiment, the self-monitor 402 utilizes various software tools to monitor the current load being processed by the edge server 101, including but not limited to Sematext Monitoring and SolarWinds. ® Server &Application Manager、Dynatrace ® Datadog ® ManageEngine ® OpManager, etc.

[0120] In one embodiment, the vehicle support 401 obtains the load of the adjacent edge server 101 from the edge monitor 403 in the edge server controller 103. "Adjacent edge server," as used herein, refers to an edge server (e.g., edge server 101B) located in proximity to the edge server in question (e.g., edge server 101A), such as edge server 101 having a coverage area (e.g., coverage area 201B) adjacent to the coverage area (e.g., coverage area 201A) of the edge server in question.

[0121] In one embodiment, edge monitor 403 utilizes a resource monitor to monitor the current load processed by adjacent edge server 101. In another embodiment, edge monitor 403 utilizes various software tools to monitor the current load processed by adjacent edge server 101, including but not limited to Sematext Monitoring and SolarWinds. ® Server &Application Manager、Dynatrace ® Datadog ® ManageEngine ® OpManager, etc.

[0122] In one embodiment, edge monitor 403 obtains the current load being processed by neighboring edge server 101 from the neighboring edge server 101 itself, for example via self-monitor 402 of neighboring edge server 101.

[0123] In one embodiment, the vehicle support unit 401 obtains the number of autonomous vehicles 104 entering / leaving within the coverage area (e.g., coverage area 201) of the edge server controller 103 from the vehicle manager 404. In one embodiment, the vehicle manager 404 is configured to manage the routes traveled by the autonomous vehicles 104, including their destinations. By managing the routes traveled by the autonomous vehicles 104, the vehicle manager 404 obtains the number of autonomous vehicles 104 entering and leaving the coverage area 201 of the edge server 101.

[0124] In one embodiment, the vehicle manager 404 uses various software tools to manage the routes traveled by the autonomous vehicle 104, including but not limited to Drive AV and OnFleet. ® IntelliShift, etc.

[0125] Furthermore, in one embodiment, the vehicle support unit 401 receives contextual information from the environment coordinator 405 of the edge server 101. Such contextual information includes information that a human driver typically considers when driving and adapting to his / her driving, such as weather, road conditions, other vehicles, pedestrians, road signs, etc. In one embodiment, such contextual information may be at least partially in the form of video information obtained from a camera (e.g., camera 306) of the autonomous vehicle 104.

[0126] In one embodiment, the vehicle supporter 401 estimates the load that the edge server 101 will handle in the near future, such as in the next 5 minutes, based on the current edge server load, the estimated load of neighboring edge servers 101, the number of autonomous vehicles 104 entering / leaving in the coverage area 201 of the edge server 101, and contextual information.

[0127] For example, to determine an appropriate estimate of the edge server load, it is necessary to obtain the number of autonomous vehicles 104 residing in the coverage area 201 of the edge server 101 at the time of calculating the edge server load. Such information can be obtained based on the number of autonomous vehicles 104 entering / leaving the coverage area 201 of the edge server 101.

[0128] In another example, to determine an appropriate estimate of the edge server load that edge server 101 will handle in the near future, it is necessary to identify an estimate of the server load currently handled by neighboring edge servers 101, and that will have to be handled by the edge server 101 in the near future as autonomous vehicles 104 travel from the coverage area of ​​neighboring edge servers 101 (e.g., coverage area 201B) to the coverage area of ​​the edge server 101 in question (e.g., coverage area 201A). Such information can be obtained based on the number of autonomous vehicles 104 entering / leaving and the estimated load of neighboring edge servers 101 (including the estimated load of processing transactions involving such autonomous vehicles 104 traveling from the coverage area of ​​neighboring edge servers 101 (e.g., coverage area 201B) to the coverage area of ​​the edge server 101 in question (e.g., coverage area 201A).

[0129] Furthermore, in order to determine an appropriate estimate of the edge server load that edge server 101 will handle in the near future, it is necessary to identify an estimate of the server load currently being handled by edge server 101, but which will no longer need to be handled by edge server 101 as autonomous vehicle 104 moves from the coverage area of ​​edge server 101 (e.g., coverage area 201A) to the coverage area of ​​an adjacent edge server 101 (e.g., coverage area 201B). Such information can be obtained based on the number of autonomous vehicles 104 entering / leaving and the estimated load of edge server 101 (including the estimated load of handling transactions involving such autonomous vehicles 104 moving from the coverage area of ​​edge server 101 (e.g., coverage area 201A) to the coverage area of ​​an adjacent edge server 101 (e.g., coverage area 201B).

[0130] In another example, to determine an appropriate estimate of the edge server load that edge server 101 will handle in the near future, contextual information can be used to determine how many transactions might potentially need to be processed by edge server 101. For example, if road conditions are poor (such as due to rainy weather), it can be inferred that edge server 101 will have to handle more transactions than normal. In another example, if autonomous vehicle 104 is driving in a congested area (e.g., traffic jam), it can be inferred that edge server 101 will have to handle more transactions than normal.

[0131] In one embodiment, the vehicle support unit 401 uses various software tools (including but not limited to Sematext Monitoring, SolarWinds) based on the information described above (e.g., current edge server load, estimated load of neighboring edge servers 101, number of autonomous vehicles 104 entering / leaving the coverage area 201 of edge servers 101, and context information). ® Server & Application Manager, Dynatrace ® Datadog ® ManageEngine ® OpManager and others estimate the load that edge server 101 will handle in the near future, for example, within the next 5 minutes.

[0132] In operation 602, the vehicle support unit 401 of the edge server 101 determines whether the estimated load of the edge server 101 (e.g., edge server 101A) exceeds a threshold, which may be specified by the user.

[0133] If the estimated load of edge server 101 (e.g., edge server 101A) does not exceed the threshold, vehicle support 401 continues to estimate the load of edge server 101 (e.g., edge server 101A) in operation 601.

[0134] However, if the estimated load of edge server 101 (e.g., edge server 101A) exceeds a threshold, in operation 603, the vehicle support 401 of edge server 101 implements an action to reduce the load (e.g., peak load) of edge server 101 (e.g., edge server 101A) by controlling the autonomous vehicle 104 to operate in a certain way.

[0135] Further discussion regarding the implementation of such actions to reduce the load on edge server 101 is below. Figure 7 Provided in conjunction with related information.

[0136] Figure 7 This is a flowchart of a method 700 for implementing actions to reduce the load on an edge server by controlling an autonomous vehicle to operate in a certain way, according to embodiments of the present disclosure.

[0137] refer to Figure 7 , combined Figure 1-6 In operation 701, the self-configurer 406 of the vehicle support 401 determines whether there is a load reduction plan to be applied to any autonomous vehicle 104 controlled by the edge server 101 (i.e., any autonomous vehicle 104 residing within the coverage area 201 of the edge server 101).

[0138] As described above, for example, in one embodiment, the autonomous vehicle 104 may be associated with a load reduction plan. As used herein, a “load reduction plan” refers to a strategy that reduces the load on the edge server 101 (e.g., edge server 101A) by controlling the autonomous vehicle 104 (e.g., autonomous vehicle 104A) in some way, such as modifying the route of the autonomous vehicle 104, modifying the movement of the autonomous vehicle 104, modifying the frequency of sending vehicle data, offloading computations previously performed in the edge server 101 to be performed in the autonomous vehicle 104, or having the autonomous vehicle 104 join a fleet of other autonomous vehicles 104, etc.

[0139] In one embodiment, such load reduction plans may be stored in a data structure (e.g., a table) of edge server 101, which may reside in storage devices of edge server 101 (e.g., storage devices 511, 515). In one embodiment, such a data structure includes a list of load reduction plans and the associated autonomous vehicles 104 to which these load reduction plans should be applied. For example, a particular load reduction plan may be applied to multiple autonomous vehicles 104 (e.g., autonomous vehicles 104A, 104B). After identifying the autonomous vehicles 104 residing within the coverage area 201 of edge server 101, self-configurer 406 performs a search in the data structure for matching autonomous vehicles 104, for example by identifiers associated with these autonomous vehicles 104, and then identifies the appropriate load reduction plan to be implemented for these autonomous vehicles 104. In one embodiment, such a data structure is populated by experts.

[0140] If there is a load reduction plan to be applied to the autonomous vehicle 104 controlled by the edge server 101, then in operation 702, the self-configurer 406 of the vehicle support 401 implements the load reduction plan for the associated autonomous vehicle 104.

[0141] As described above, the load reduction plan can instruct the autonomous vehicle 104 to reduce the frequency of transmitting data acquired from the sensor system 305.

[0142] In another example, a load reduction plan could involve creating a fleet group (a group of autonomous vehicles 104 participating in the same activity) to reduce the amount of sensor data that needs to be sent and received by the edge server 101. For example, such a fleet group could correspond to autonomous vehicles 104 with similar route plans.

[0143] In another example, a load reduction plan could include a strategy to navigate autonomous vehicle 104 to other areas with less traffic, where fewer transactions need to be handled by edge server 101.

[0144] In another example, a load reduction plan could involve reducing the amount of information that edge server 101 needs to process by lowering the resolution required for images sent from autonomous vehicle 104 to edge server 101 (e.g., images captured by camera 306).

[0145] In addition, another example of a load reduction plan involves having multiple autonomous vehicles 104 (such as drones) fly in formation, thereby reducing the workload (processing) on ​​the edge server 101, since the location information of a particular autonomous vehicle 104 can be found from the location information of all other autonomous vehicles 104 flying in the same formation.

[0146] However, if there is no load reduction plan to be applied to the autonomous vehicle 104 controlled by the edge server 101, in operation 703, the load balancer 407 of the vehicle support 401 determines whether any of the adjacent edge servers 101 is capable of handling the additional workload.

[0147] If any of the adjacent edge servers 101 (e.g., edge server 101B) is capable of handling additional workload, in operation 704, the load balancing coordinator 407 of the vehicle support 401 requests the edge load balancer 408 of the edge server controller 103 to instruct one or more autonomous vehicles 104 currently controlled by edge server 101 (e.g., edge server 101A) (and possibly currently controlled by adjacent edge server 101 (e.g., edge server 101B)) to be rerouted to coverage area 201 (e.g., coverage area 201B) controlled by adjacent edge server 101 (e.g., edge server 101B), so that adjacent edge server 101 has greater or complete control over the autonomous vehicles 104, thereby relieving the load on edge server 101 (e.g., edge server 101A).

[0148] For example, such as Figure 2 As shown, the load balancer 407 requests the edge load balancer 408 of the edge server controller 103 to instruct the autonomous vehicle 104' to reroute from the coverage area 201 (e.g., coverage area 201B) controlled by the edge server 101B to the coverage area 201 (e.g., coverage area 201A) controlled by the adjacent edge server 101 (e.g., edge server 101A) in order to relieve the load on the edge server 101B.

[0149] If neither of the adjacent edge servers 101 (e.g., edge server 101B) is capable of handling the additional workload, then in operation 705, the vehicle supporter 401 of edge server 101 restricts or disables the driving of one or more autonomous vehicles 104, such as those located in the coverage area 201 (e.g., coverage area 201A) controlled by edge server 101 (e.g., edge server 101A), in a manner that reduces the load on edge server 101 (e.g., edge server 101A).

[0150] As described above, for example, vehicle support 401 can prevent autonomous vehicle 104, controlled by edge server 101, from changing lanes. When autonomous vehicle 104 is prevented from changing lanes, driving behavior analysis is reduced. In another example, vehicle support 401 prevents autonomous vehicle 104, controlled by edge server 101, from entering areas covered by edge server 101, such as areas that might cause a greater load (e.g., a higher number of transactions) on edge server 101 (e.g., congested areas).

[0151] In one embodiment, this restricted or prohibited driving is dynamically reflected on a map, such as... Figure 2 As shown. For example, map 200 includes sign 202 (a do not enter sign), which instructs the autonomous vehicle 104 not to enter such an area. In another example, map 200 includes sign 203 (a do not change lanes sign), which instructs the autonomous vehicle 104 not to change lanes in such an area.

[0152] In this way, autonomous vehicles can be controlled by edge server resources, and the limited computing resources of the edge server can be used to process transactions during peak hours, such as transactions involving autonomous vehicles.

[0153] As a result of the above, in an autonomous driving mobile environment, peak-hour transactions can be handled with the limited computing resources of edge servers by reducing the peak load of edge servers that collaborate between multiple autonomous vehicles and multiple edge servers through resource control of autonomous vehicles via edge servers.

[0154] Furthermore, the principles of this disclosure improve upon the technologies or fields related to autonomous driving mobility.

[0155] As mentioned above, autonomous vehicles have the ability to continuously monitor their surroundings using sensor arrays including cameras, radar, and lidar. These sensors provide a 360-degree view of the vehicle's environment, enabling it to detect any potential obstacles, pedestrians, or other vehicles with high precision. Advanced algorithms interpreting this data can make instantaneous decisions to avoid collisions and safely navigate complex situations. Autonomous vehicle movement involving this type of autonomous vehicle movement can be achieved using edge computing. Edge computing refers to an architecture of distributed computing paradigms that brings computation and data storage closer to the data source. Edge computing can be implemented using edge servers, which correspond to servers located at the edge of the network, close to the end user. Such edge servers can be used to handle various tasks, such as controlling autonomous vehicles in relation to handling traffic congestion, optimizing routes, adjusting speeds, and efficiently merging autonomous vehicles. This control of autonomous vehicles requires significant computing resources. Therefore, at certain times, the load on the edge server (the amount of work the edge server is processing at a given time) can be very high, including periods when the edge server experiences peak load (the maximum amount of work the edge server can handle at a given time). The times when the edge server experiences peak load are called "peak hours." To address the potential limitations of edge servers in handling transactions, such as during peak periods, transactions can be temporarily offloaded to adjacent edge servers or cloud servers. However, this reduces the latency and accuracy of the computational analysis performed by edge servers. Another alternative to addressing peak loads on edge servers during peak periods is to deploy additional edge servers. Unfortunately, this solution incurs significant additional costs. Therefore, there is currently no means to handle transactions during peak periods using the limited computing resources of edge servers, such as those involving autonomous vehicles.

[0156] Embodiments of this disclosure improve upon this technique by estimating the load of edge servers controlling autonomous vehicles located within the coverage area of ​​edge servers. In one embodiment, the estimated load of the edge server corresponds to an estimated load that the edge server will handle in the near future. In another embodiment, the estimated load is based on the current edge server load, the estimated load of neighboring edge servers, the number of autonomous vehicles entering / leaving the coverage area of ​​the edge server, and contextual information (information that human drivers typically consider when driving and adapting to their driving, such as weather, road conditions, other vehicles, pedestrians, road signs, etc.). In response to the estimated load of the edge server exceeding a threshold, actions to reduce the load on the edge server are implemented by controlling one or more autonomous vehicles to operate in a specific manner to reduce the load on the edge server. Examples of controlling autonomous vehicles to operate in a specific manner to reduce the load on the edge server include modifying the movement of the autonomous vehicle, modifying the frequency of sending vehicle data, offloading computations previously performed by the edge server to be performed in the autonomous vehicle, joining a fleet of other autonomous vehicles, restricting lane changes, rerouting the autonomous vehicle to an area controlled by a neighboring edge server so that edge servers with peak loads are not used, etc. In this way, by controlling autonomous vehicles based on edge server resources, the peak load on edge servers that collaborate between multiple autonomous vehicles and multiple edge servers is reduced. Furthermore, this approach represents an improvement in the technology field involving autonomous mobility.

[0157] The technical solutions provided in this disclosure cannot be executed in the human brain or by a person using pen and paper. That is to say, without a computer, it is not expected in any reasonable time and with any reasonable accuracy that the technical solutions provided in this disclosure can be completed in the human brain or by a person using pen and paper.

[0158] The description of various embodiments of this disclosure is for illustrative purposes only and is not intended to be exhaustive or to limit the disclosure to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is intended to best explain the principles of the embodiments, their practical application to the technology on the market, or technical improvements, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A computer-implemented method for reducing the load on an edge server in an autonomous driving mobile environment, the method comprising: Estimate the load on the edge servers controlling autonomous vehicles; as well as In response to the estimated load of the edge server exceeding a threshold, actions to reduce the load on the edge server are implemented by controlling one or more of the autonomous vehicles to operate in a specific manner.

2. The computer-implemented method according to claim 1 further includes: In response to the estimated load of the edge server exceeding the threshold, a load reduction plan associated with one or more of the autonomous vehicles is implemented.

3. The computer-implemented method of claim 2, wherein the load reduction plan includes one or more of the following: modifying the route of the autonomous vehicle, modifying the movement of the autonomous vehicle, modifying the frequency of sending vehicle data, offloading computations previously performed in the edge server to be performed in the autonomous vehicle, and joining the autonomous vehicle into a fleet of other autonomous vehicles.

4. The computer-implemented method according to claim 1 further includes: In response to the estimated load of the edge server exceeding the threshold and in response to the neighboring edge server being able to handle additional workload, the autonomous vehicle controlled by the edge server is instructed to reroute to the area controlled by the neighboring edge server.

5. The computer-implemented method according to claim 1, further comprising: In response to the estimated load of the edge server exceeding the threshold, the driving of the autonomous vehicle is restricted or prohibited in a manner that reduces the load on the edge server.

6. The computer-implemented method of claim 5, wherein the restricted or prohibited driving includes prohibiting lane changes and preventing the autonomous vehicle from entering the area covered by the edge server.

7. The computer-implemented method of claim 6, wherein the restricted or prohibited driving is dynamically reflected on a map.

8. A computer program product for reducing the load on an edge server in an autonomous driving mobile environment, the computer program product comprising one or more computer-readable storage media having program code embodied therein, the program code including programming instructions for: Estimate the load on the edge servers controlling autonomous vehicles; and In response to the estimated load of the edge server exceeding a threshold, actions to reduce the load on the edge server are implemented by controlling one or more of the autonomous vehicles to operate in a specific manner.

9. The computer program product of claim 8, wherein the program code further comprises programming instructions for the following operations: In response to the estimated load of the edge server exceeding the threshold, a load reduction plan associated with one or more of the autonomous vehicles is implemented.

10. The computer program product of claim 9, wherein the load reduction plan includes one or more of the following: modifying the route of the autonomous vehicle, modifying the movement of the autonomous vehicle, modifying the frequency of sending vehicle data, offloading computations previously performed in the edge server to be performed in the autonomous vehicle, and joining the autonomous vehicle into a fleet of other autonomous vehicles.

11. The computer program product of claim 8, wherein the program code further comprises programming instructions for the following operations: In response to the estimated load of the edge server exceeding the threshold and in response to the neighboring edge server being able to handle additional workload, the autonomous vehicle controlled by the edge server is instructed to reroute to the area controlled by the neighboring edge server.

12. The computer program product of claim 8, wherein the program code further comprises programming instructions for the following operations: In response to the estimated load of the edge server exceeding the threshold, the driving of the autonomous vehicle is restricted or prohibited in a manner that reduces the load on the edge server.

13. The computer program product of claim 12, wherein the restricted or prohibited driving includes prohibiting lane changes and preventing the autonomous vehicle from entering the area covered by the edge server.

14. The computer program product of claim 13, wherein the restricted or prohibited driving is dynamically reflected on the map.

15. A system comprising: Memory, used to store computer programs for reducing the load on edge servers in autonomous driving mobile environments; as well as A processor connected to the memory, wherein the processor is configured to execute program instructions of the computer program, including: Estimate the load on the edge servers controlling autonomous vehicles; as well as In response to the estimated load of the edge server exceeding a threshold, actions to reduce the load on the edge server are implemented by controlling one or more of the autonomous vehicles to operate in a specific manner.

16. The system of claim 15, wherein the program instructions of the computer program further include: In response to the estimated load of the edge server exceeding the threshold, a load reduction plan associated with one or more of the autonomous vehicles is implemented.

17. The system of claim 16, wherein the load reduction plan includes one or more of the following: modifying the route of the autonomous vehicle, modifying the movement of the autonomous vehicle, modifying the frequency of transmitting vehicle data, offloading computations previously performed in the edge server to be performed in the autonomous vehicle, and joining the autonomous vehicle into a fleet of other autonomous vehicles.

18. The system of claim 15, wherein the program instructions of the computer program further include: In response to the estimated load of the edge server exceeding the threshold and in response to the neighboring edge server being able to handle additional workload, the autonomous vehicle controlled by the edge server is instructed to reroute to the area controlled by the neighboring edge server.

19. The system of claim 15, wherein the program instructions of the computer program further include: In response to the estimated load of the edge server exceeding the threshold, the driving of the autonomous vehicle is restricted or prohibited in a manner that reduces the load on the edge server.

20. The system of claim 19, wherein the restricted or prohibited driving includes prohibiting lane changes and preventing the autonomous vehicle from entering the area covered by the edge server.

Images