A scheduling mechanism for intelligent networked cooperative driving applications based on geographic region networking device data

Abstract

The application relates to the technical field of data collection and processing, and more particularly discloses a scheduling mechanism for intelligent network connection cooperative driving application based on geographic region networking equipment data, which has the following processing procedure: step one, equipment real-time data access and storage according to regions: real-time equipment operation data is accessed, and the operation data is stored and indexed according to geographical positions; only the latest data of the same equipment is stored, historical data is not stored, and data is externally provided in a region-based and uniquely indexed manner; step two, regional traffic feature identification: a public identification algorithm module provides a data basis for the whole scheduling algorithm; the intelligent traffic network connection application based on the geographical region uses data collected by roadside and vehicle-mounted equipment, provides a computing unit for traffic participants to provide fusion sensing, cooperative decision-making and control services, and is a decision-making center unit for regional traffic participants to cooperate.

Description

Technical Field

[0001] This invention relates to the field of data acquisition and processing technology, and more specifically to a scheduling mechanism for intelligent connected and cooperative driving applications based on data from networked devices in a geographical area. Background Technology

[0002] The existing scheduling mechanism is applied to edge cloud computing for intelligent transportation network application scenarios based on traffic participant data in geographic areas. It aims to ensure that the computing latency of such applications is controllable, monitorable, and self-adjustable, thereby improving the computing efficiency of edge cloud applications.

[0003] Device-sensed data is accessed to the edge cloud via a gateway. Within the edge cloud, this data is provided to applications via a data bus. However, since the data bus lacks the ability to identify application-required data, it provides all device-sensed data to each application. Each application performs calculations on this data and retrieves geolocation-related data from the full data storage using spatial indexing. The calculated collaborative sensing, decision-making, and control commands are then distributed to the corresponding devices via the gateway. While the data and computation scheduling process is simple, it is inefficient. The data distribution process does not consider applicable road conditions or the application's need for geographically continuous sessions. Providing all data to each application, requiring each application to perform calculations on every single piece of data, results in relatively delayed computation of useful commands. Furthermore, due to device ID partitioning and device online / offline changes, the amount of data processed by each computation task fluctuates wildly, with uncontrollable upper limits, leading to periodic computational blockages, computational delays, reduced real-time performance, and ultimately, invalid computation results.

[0004] Vehicle data is uploaded at a frequency of 10Hz, with an average concurrent online rate of 60% and a peak concurrent online rate of 80%. There is a 5-kilometer-long road within the area, containing only one sharp turn, approximately 500 meters long; the rest is a straight section. Application A implements blind spot identification and warning functions on the sharp turn section. Under the existing processing system, application A needs to process 10,000 (vehicles) * 10 (data entries / second / vehicle) * 80% = 80,000 (data entries / second). If each task has a processing capacity of 800 data entries / second, then 100 parallel tasks are needed to handle the data. Furthermore, due to… <1> The range of key values ​​for concurrent devices within the peak period varies. <2> The current key-based partitioning is not perfectly balanced and is difficult to control. As a result, in the actual processing, some tasks are assigned far more than 800 data entries / second, while some tasks are assigned less than 800 data entries / second, resulting in an unbalanced load. Tasks with actual load exceeding the design capacity will cause computational blocking. Long-term blocking leads to uncontrollable latency, causing application failure.

[0005] The application only wants to obtain the vehicles within a 500-meter road range. Assuming that the average length of each vehicle is 5 meters and there is no gap between vehicles, and the road is a 4-lane road, then the maximum concurrent computation of this application is 4 (lanes) * 500 (meters / lane) / 5 (meters / vehicle) * 10 (vehicles / second / vehicle) = 4000 vehicles / second, which is 20 times lower than the original 80,000 vehicles / second. Summary of the Invention

[0006] In order to overcome the above-mentioned defects of the prior art, the present invention provides a scheduling mechanism for intelligent connected cooperative driving applications based on geographical area network device data, so as to solve the problems existing in the background art.

[0007] This invention provides the following technical solution: a scheduling mechanism for intelligent connected cooperative driving applications based on geographical area networked device data, the processing flow of which is as follows:

[0008] Step 1: Real-time device data access and storage by region: Access real-time device operation data and store and index the operation data according to its geographical location. Only the latest data is stored for the same device, and historical data is not stored. The data will also be provided to the outside world in a unique indexed manner by region.

[0009] Step 2, Regional Traffic Feature Identification: The public identification algorithm module provides the data foundation for the entire scheduling algorithm and includes the following basic modules: Traffic Statistics Module, which performs traffic statistics on each regional block, calculates the fluctuation range of traffic in the regional block, and determines the peak traffic of the block to provide data support for determining the application calculation scope; Traffic Condition Identification Module, which analyzes and identifies traffic conditions in the data of regional blocks and combinations of regional blocks, and classifies and labels the identified traffic conditions using traffic condition models;

[0010] Step 3, Application Scheduling Module: This module schedules applications based on factors such as application compatibility with traffic conditions, computing power, regional traffic, current process distribution of various data, application deployment status, and the usage of registered resources.

[0011] Step 4: Operation monitoring module: Monitors the operation status of the application and its operating environment, periodically generates operation status reports, and feeds them back to the application scheduling module and other application modules to form an assessment of the current operation status and help continuously optimize the operation.

[0012] Furthermore, the workflow of the operation monitoring module is as follows:

[0013] Step 1: Data storage scheduling module; This module converts the latitude and longitude of the accessed devices into one-dimensional GEOHASH values ​​based on their real-time operating data, and uses these values ​​as the basis for distributed data storage partitioning; at the same time, it registers them to the storage metadata dictionary.

[0014] Step 2: Distributed Data Cache; The distributed data cache has the following characteristics: data is stored in a distributed manner according to the regional blocks where it is located based on its latitude and longitude; each query can only retrieve the latest status of traffic data within the region, that is, there is exactly one piece of data for the same device within the same regional block, and this data is the latest data for this device, which has a certain expiration time and will be cleared after expiration; data can be read and written quickly; only the query method by regional key is provided externally, and no other data query methods are provided.

[0015] Step 3: Other data storage areas store other configuration data that the system depends on for operation;

[0016] Step 4: System Operation Data Storage Area. This module is the data support area for the entire scheduling operation, containing two important types of data storage: regional characteristic data, mainly storing the regional range data controlled by the edge cloud, data traffic in each region, traffic characteristics of regions and combinations of regions, etc., to assist the scheduling task in rationally scheduling applications; and computing task scheduling data, which caches the current scheduling information, mainly including C-Node information, C-Process information (including its synchronized regional block list), application information (including the application's computing regional blocks, monitoring regional blocks, etc.), running Task information and its scheduling information, etc.; and system data, including: a) static information of the system environment, such as available computing node resources, computing node configuration information, etc.; b) dynamic information of the system environment, such as C-Node CPU utilization, memory utilization, network I / O load, process memory usage, and application Task execution time statistics.

[0017] Step 5; Distributed Computing Module; This module is the core computing module, mainly responsible for determining the application task executor, starting the application, running the application, and stopping the application. It includes the following two types of executors (process level): System executor, which executes system tasks and does not synchronize data in the distributed data cache; Application executor, which executes application tasks and can start n tasks simultaneously, executing 1 to n identical or different application tasks. Its functions include starting and stopping tasks based on the scheduling task information given by the scheduling task, adding and deleting real-time synchronization tasks in the data area, providing real-time data in the allocated data area to the application, and monitoring the application's running status.

[0018] Furthermore, the workflow of the system task module is as follows:

[0019] Step 1, Task Scheduling Module: Based on the applications allocated by the upper-level cloud platform, the module schedules tasks and comprehensively analyzes the following factors to determine the scheduling scheme.

[0020] Step 2: The regional road condition recognition module determines the type of road condition and the regional scope (the area blocks involved) based on information such as the type of traffic participants, driving speed, driving direction, location, and elevation, combined with map information, and stores the information to provide data basis for the task scheduling module.

[0021] Step 3: Regional traffic flow monitoring, calculating and storing the traffic flow of all road users within the designated area.

[0022] Step 4: Runtime Environment Monitoring. Monitor and store the CPU, memory, and network I / O status of the runtime environment nodes to provide data for the task scheduling module.

[0023] Furthermore, the scheduling principles of the application scheduling module are as follows: ensure that the processing traffic conditions of the application are compatible with the actual traffic conditions; ensure that the peak traffic of the computing area is within the computing capacity of the application; ensure continuous coverage of adjacent areas for different processing tasks of the same application; maximize data sharing within the process; and maximize the balance of resource usage.

[0024] Furthermore, the scheduling scheme of the task scheduling module includes: the application's adapted road condition type, the application's computing power, and special limitations on the computing range; the deployment status of the current application task, including the set of areas already covered by the application's computing, the distribution of the application's computing execution area and computing monitoring area, and the set of uncovered areas; the upper limit of data area loading in C-Process, the distribution of regional data loading, and the latency of application tasks running within C-Process; the distribution of C-Process on C-Node; and the load of C-Node's CPU, memory, and network I / O.

[0025] The technical effects and advantages of this invention are as follows:

[0026] This invention relates to a geographic region-based intelligent transportation network application. It utilizes data collected from roadside and vehicle-mounted devices to provide traffic participants with fusion perception, collaborative decision-making, and control services. It serves as a central decision-making unit for regional traffic participants to collaborate, and offers the following advantages:

[0027] Firstly, the data processing frequency is high and the data volume is large. Currently, the data upload frequency of road testing equipment and vehicle-mounted equipment is generally 10Hz. Taking a typical one-way four-lane, one-kilometer road segment as an example, assuming it is in a relatively congested phase with one vehicle every 20 meters, there will be 4 (lanes) * (1000 (meters / lane) / 20 (meters / vehicle / lane)) * 10 (data / vehicle / second) = 2000 (data / second) in this area, and 7.2 million data entries per hour.

[0028] Secondly, it heavily relies on traffic information in the calculation area. Different applications are adapted to different traffic conditions. For example, blind spot warning applications only need to perform calculations in situations with potential blind spots, such as ramp merging or sharp turns. Some applications that coordinate and optimize traffic efficiency based on traffic lights only need to perform calculations within a certain range of traffic light intersections.

[0029] Third, real-time computation with high latency requirements: perception, decision-making, and control applications need to perform calculations based on the most real-time data and send control commands to the corresponding demanding devices with the lowest possible latency. If there is high latency in this entire chain, decision-making and control commands will not arrive in time, causing decision-making, control, and other related commands to fail.

[0030] Fourth, the application requires a certain spatiotemporal continuity in the computational data, and needs to maintain continuous spatiotemporal observation of specific events. The following is an illustration using a simple scenario. For example, in the application of speeding scene recognition, since there are speeding states that transition to non-speeding states and the continuous confirmation of speeding states, multiple frames of continuous observation are required for determination. Since the amount of data processed by each speeding application processing task has an upper limit, the data of traffic participants in two adjacent regions may be allocated in different process spaces, resulting in discontinuity in computation at the boundary.

[0031] This invention solves the problem of scheduling applications with low latency requirements based on geographic location computing in edge cloud systems. The key is to meet the computing resource requirements of geographic location computing applications by rationally scheduling data and applications, reduce application processing latency, reasonably control application computing blockage caused by uncontrollable factors (data volume fluctuations), and rationally organize data to facilitate application computing based on geographic data. Attached Figure Description

[0032] Figure 1 This is a flowchart of the processing of the present invention.

[0033] Figure 2 This is the edge cloud process of the present invention.

[0034] Figure 3 This is the system task module flow of the present invention.

[0035] Figure 4 This is a basic architectural diagram of the present invention.

[0036] Figure 5 This is a schematic diagram illustrating the principle of the present invention. Detailed Implementation

[0037] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. In addition, the forms of the various structures described in the following embodiments are merely illustrative. The scheduling mechanism of the intelligent connected collaborative driving application based on geographical area network device data involved in the present invention is not limited to the structures described in the following embodiments. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0038] A scheduling mechanism for intelligent connected cooperative driving applications based on geographically connected device data, the processing flow of which is as follows:

[0039] Step 1: Real-time device data access and storage by region: Access real-time device operation data and store and index the operation data according to its geographical location. Only the latest data is stored for the same device, and historical data is not stored. The data will also be provided to the outside world in a unique indexed manner by region.

[0040] Step 2, Regional Traffic Feature Identification: The public identification algorithm module provides the data foundation for the entire scheduling algorithm and includes the following basic modules: Traffic Statistics Module, which performs traffic statistics on each regional block, calculates the fluctuation range of traffic in the regional block, and determines the peak traffic of the block to provide data support for determining the application calculation scope; Traffic Condition Identification Module, which analyzes and identifies traffic conditions in the data of regional blocks and combinations of regional blocks, and classifies and labels the identified traffic conditions using traffic condition models;

[0041] Step 3, Application Scheduling Module: This module schedules applications based on factors such as application compatibility with traffic conditions, computing power, regional traffic, current process distribution of various data, application deployment status, and the usage of registered resources.

[0042] Step 4: Operation monitoring module: Monitors the operation status of the application and its operating environment, periodically generates operation status reports, and feeds them back to the application scheduling module and other application modules to form an assessment of the current operation status and help continuously optimize the operation.

[0043] Preferably, the workflow of the operation monitoring module is as follows:

[0044] Step 1: Data Storage and Scheduling Module; This module converts the latitude and longitude of the accessed devices into one-dimensional GEOHASH values ​​based on their real-time operating data (a 7-bit value can be used, representing a range of approximately 75.6m * 75.6m. The maximum number of identification devices (taking vehicles as an example) that can be generated within a single record is: assuming the longitudinal length of one unit device is 6m and the lateral length is 2m, then the total number of vehicles is (75.6 / 6) * (75.6 / 2) ≈ 476. After testing, this data size is moderate and convenient for storage scheduling and query scheduling). The value is used as the basis for distributed data storage partitioning; at the same time, it is registered to the storage metadata dictionary.

[0045] Step 2: Distributed Data Cache; The distributed data cache has the following characteristics: data is stored in a distributed manner according to the regional blocks where it is located based on its latitude and longitude; each query can only retrieve the latest status of traffic data within the region, that is, there is exactly one piece of data for the same device within the same regional block, and this data is the latest data for this device, which has a certain expiration time and will be cleared after expiration; data can be read and written quickly; only the query method by regional key is provided externally, and no other data query methods are provided.

[0046] Step 3: Other data storage areas store other configuration data that the system depends on for operation;

[0047] Step 4: System Operation Data Storage Area. This module is the data support area for the entire scheduling operation, containing two important types of data storage: regional characteristic data, mainly storing the regional range data controlled by the edge cloud, data traffic in each region, traffic characteristics of regions and combinations of regions, etc., to assist the scheduling task in rationally scheduling applications; and computing task scheduling data, which caches the current scheduling information, mainly including C-Node information, C-Process information (including its synchronized regional block list), application information (including the application's computing regional blocks, monitoring regional blocks, etc.), running Task information and its scheduling information, etc.; and system data, including: a) static information of the system environment, such as available computing node resources, computing node configuration information, etc.; b) dynamic information of the system environment, such as C-Node CPU utilization, memory utilization, network I / O load, process memory usage, and application Task execution time statistics.

[0048] Step 5; Distributed Computing Module; This module is the core computing module, mainly responsible for determining the application task executor, starting the application, running the application, and stopping the application. It includes the following two types of executors (process level): System executor, which executes system tasks and does not synchronize data in the distributed data cache; Application executor, which executes application tasks and can start n tasks simultaneously, executing 1 to n identical or different application tasks. Its functions include starting and stopping tasks based on the scheduling task information given by the scheduling task, adding and deleting real-time synchronization tasks in the data area, providing real-time data in the allocated data area to the application, and monitoring the application's running status.

[0049] Preferably, the workflow of the system task module is as follows:

[0050] Step 1, Task Scheduling Module: Based on the applications allocated by the upper-level cloud platform, the module schedules tasks and comprehensively analyzes the following factors to determine the scheduling scheme.

[0051] Step 2: The regional road condition recognition module determines the type of road condition and the regional scope (the area blocks involved) based on information such as the type of traffic participants, driving speed, driving direction, location, and elevation, combined with map information, and stores the information to provide data basis for the task scheduling module.

[0052] Step 3: Regional traffic flow monitoring, calculating and storing the traffic flow of all road users within the designated area (including peak, minimum, and time period information).

[0053] Step 4: Runtime Environment Monitoring. Monitor and store the CPU, memory, and network I / O status of the runtime environment nodes to provide data for the task scheduling module.

[0054] Preferably, the scheduling principles of the application scheduling module are as follows: ensuring that the processing traffic conditions of the application are compatible with the actual traffic conditions; ensuring that the peak traffic of the computing area is within the computing capacity of the application; ensuring continuous coverage of adjacent areas for different processing tasks of the same application; maximizing data sharing within the process; and maximizing the balance of resource usage.

[0055] Preferably, the scheduling scheme of the task scheduling module is as follows: the application's adapted road condition type, the application's computing power (measured by the number of traffic identification objects that can be processed simultaneously in a single operation; a reference value for computing power needs to be provided based on test results before the application goes online), special limitations on the computing range (such as the maximum computing length and width limits for straight lanes); the current deployment status of the application tasks, including the set of areas already covered by the application's computing, the distribution of the application's computing execution area and computing monitoring area, and the set of uncovered areas; the upper limit of the data area loading of the C-Process, the distribution of regional data loading, and the latency of the application tasks running within the C-Process; the distribution of the C-Process on the C-Node; and the load of the C-Node's CPU, memory, and network I / O.

[0056] The basic principle of this scheme is:

[0057] Real-time device data is stored in the cloud using blocks as the basic storage unit. Only one valid data record (latest data) is available for the same device across all blocks. The latest real-time data is then provided to relevant users using blocks as the basic unit.

[0058] Applications are scheduled at the thread level, and data is scheduled at the process level according to the application's needs, enabling multiple applications to share data within a process.

[0059] Finally, the following points should be noted: First, in the description of this application, it should be noted that, unless otherwise specified and limited, the terms "installation", "connection", and "linkage" should be interpreted broadly, and can be mechanical or electrical connections, or internal connections between two components, or direct connections. "Up", "down", "left", "right", etc. are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may change.

[0060] Secondly: The accompanying drawings of the embodiments disclosed in this invention only involve the structures involved in the embodiments disclosed in this invention. Other structures can refer to the general design. In the absence of conflict, the same embodiment and different embodiments of this invention can be combined with each other.

[0061] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A scheduling mechanism for intelligent connected cooperative driving applications based on geographically connected device data, characterized in that, The processing flow is as follows: Step 1: Real-time device data access and storage by region: Access real-time device operation data and store and index the operation data according to its geographical location. Only the latest data is stored for the same device, and historical data is not stored. The data will also be provided to the outside world in a unique indexed manner by region. Step 2, Regional Traffic Feature Identification: The public identification algorithm module provides the data foundation for the entire scheduling algorithm and includes the following basic modules: Traffic Statistics Module, which performs traffic statistics on each regional block, calculates the fluctuation range of traffic in the regional block, and determines the peak traffic of the block to provide data support for determining the application calculation scope; Traffic Condition Identification Module, which analyzes and identifies traffic conditions in the data of regional blocks and combinations of regional blocks, and classifies and labels the identified traffic conditions using traffic condition models; Step 3, Application Scheduling Module: This module schedules applications based on factors such as application compatibility with traffic conditions, computing power, regional traffic, current process distribution of various data, application deployment status, and the usage of registered resources. Step 4: Operation monitoring module: Monitors the operation status of the application and its operating environment, periodically generates operation status reports, and feeds them back to the application scheduling module and other application modules to form an assessment of the current operation status and help continuously optimize the operation; The workflow of the operation monitoring module is as follows: Step 1: Data storage and scheduling module; Step 2: Distributed data cache; Step 3: Other data storage areas store other configuration data that the system depends on for operation; Step 4: System running data storage area. This module is the data support area for the entire scheduling operation, containing two important types of data storage: regional characteristic data and system data. Step 5: Distributed Computing Module; This is the core computing module, mainly responsible for determining the application task executors, starting the application, running the application, and stopping the application. It includes the following two types of executors: System executor, which executes system tasks and does not synchronize data in the distributed data cache; Application executor, which executes application tasks and can start n tasks simultaneously, executing 1 to n identical or different application tasks. Its functions include starting and stopping tasks based on the scheduling task information provided by the scheduling task, adding and deleting real-time synchronization tasks in the data area, providing real-time data in the allocated data area to the application, and monitoring the application's running status.

2. The scheduling mechanism for an intelligent connected cooperative driving application based on geographical area networked device data according to claim 1, characterized in that: The data storage scheduling module converts the latitude and longitude of the access device into a one-dimensional GEOHASH value based on the device's real-time operating data, and uses this value as the basis for distributed data storage partitioning; at the same time, it registers the value to the storage metadata dictionary. The distributed data cache has the following characteristics: data is distributed and stored according to the regional blocks where it is located based on its latitude and longitude; each query can only retrieve the latest status of traffic data within the region, that is, there is one and only one piece of data for the same device within the same regional block, and this data is the latest data for this device, which has a certain expiration time and will be cleared after the data expires; data can be read and written quickly; only the query method by regional key is provided externally, and no other data query methods are provided. The system's operational data storage area also includes data on the regional scope of the main storage edge cloud control, data traffic within each region, and traffic characteristics of the region and combinations thereof, to assist in the scheduling of tasks for the rational scheduling of applications; the system data includes: a) static information of the system environment, such as available computing node resources and computing node configuration information; b) dynamic information of the system environment, such as CPU utilization, memory utilization, network I / O load, memory usage of processes, and application task execution time statistics of C-Node.

3. The scheduling mechanism for an intelligent connected cooperative driving application based on geographic area network device data according to claim 2, characterized in that, The workflow of the system task is as follows: Step 1, Task Scheduling Module: Based on the applications allocated by the upper-level cloud platform, the module schedules tasks and comprehensively analyzes the following factors to determine the scheduling scheme. Step 2: The regional road condition recognition module determines and stores information such as the type of traffic participants, driving speed, driving direction, location, and elevation in the region, combined with map information, to provide data for the task scheduling module. Step 3: Regional traffic flow monitoring, calculating and storing the traffic flow of traffic participants within the road condition area; Step 4: Monitor the runtime environment, including the CPU, memory, and network I / O of the runtime environment nodes, and store the data to provide data for the task scheduling module.

4. The scheduling mechanism for an intelligent connected cooperative driving application based on geographic area network device data according to claim 2, characterized in that: The scheduling principles of the application scheduling module are as follows: ensure that the processing traffic conditions of the application are adapted to the actual traffic conditions; ensure that the peak traffic of the computing area is within the computing capacity of the application; ensure continuous coverage of adjacent areas for different processing tasks of the same application; and maximize data sharing within the process. Try to ensure a balanced use of resources.

5. The scheduling mechanism for an intelligent connected cooperative driving application based on geographic area network device data according to claim 3, characterized in that: The scheduling scheme of the task scheduling module is as follows: the application's adaptable road condition type, the application's computing power, and special limitations on the computing range; the current deployment status of the application task, including the set of areas already covered by the application's computing, the distribution of the application's computing execution area and computing monitoring area, and the set of areas not covered; The upper limit of data area loading in C-Process, the distribution of data loading in the region, and the latency of application tasks running within C-Process; The distribution of C-Processes on C-Nodes; the CPU, memory, and network I / O load of C-Nodes.

Images