An unmanned vehicle multi-task scheduling and endurance optimization system for underway environmental monitoring

Abstract

The present application relates to a kind of unmanned vehicle multi-task scheduling and endurance optimization system for sailing environment monitoring, four technical links of endurance feasibility evaluation, multi-objective vehicle optimization, task conflict detection and quantitative resolution, sailing task generation and issue are sequentially executed by task management layer collection vehicle real-time state data.The present application establishes endurance feasibility evaluation model based on SOC method 100km energy consumption benchmark calculation superimposed environmental temperature segmented correction;Three scoring indexes are constructed with response time, task interruption cost, endurance margin matching degree as target, and weighted ordering according to fixed weight;Priority tensor index query mechanism and differential resolution strategy based on covered grid ratio are established.

Description

Technical Field

[0001] This invention relates to the field of environmental monitoring resource scheduling technology, and in particular to a multi-task scheduling and endurance optimization system for unmanned vehicles for mobile environmental monitoring. Background Technology

[0002] Mobile atmospheric particulate matter monitoring is a technology that uses vehicles equipped with mobile monitoring equipment to travel along roads within a target area and collect real-time data on atmospheric pollutant concentrations. Unmanned vehicles are equipped with third-party environmental monitoring equipment (including PM2.5). 2.5 PM 10 The system includes particulate matter monitoring sensors such as TSP and supporting gas circuits and sampling pumps. During the mobile operation, it continuously collects pollutant data at a sampling frequency of seconds and transmits it back to the monitoring platform in real time via 4G / 5G communication links. The data is used for pollution hotspot identification, source tracing analysis, and regulatory decision-making.

[0003] Mobile monitoring tasks are divided into two categories: The first is routine patrol tasks, which involve periodically patrolling key areas along pre-set routes, requiring full coverage of a designated hexagonal grid set. These tasks are characterized by fixed routes, fixed frequencies, and high requirements for coverage integrity. The second is emergency high-value dispatch tasks, which involve dispatching unmanned vehicles (UAVs) to quickly reach the site for targeted mobile monitoring when fixed monitoring stations or higher-level systems detect abnormally high pollutant concentrations in a certain area. These tasks are characterized by their suddenness, high response time requirements, and concentrated patrol areas. The two types of tasks have significantly different requirements for sampling frequency, mobile routes, and response speed.

[0004] When a fully electric autonomous vehicle performs mobile monitoring tasks, its battery power simultaneously supplies the vehicle's drive system, onboard environmental monitoring equipment (including sensor sampling pumps, air circuit systems, and data acquisition modules), and 4G / 5G communication modules. The high-frequency data stream generated by the second-level sampling puts significant pressure on communication power consumption, and ambient temperature has a non-linear impact on the discharge efficiency of lithium batteries. These two factors make range prediction in mobile monitoring scenarios more complex than in conventional driving scenarios: in low-temperature environments, the internal resistance of lithium batteries increases and the available capacity decreases, while the constant power consumption of onboard equipment further compresses the available power for the drive. If an autonomous vehicle with insufficient range is dispatched to complete the mobile monitoring task, it will directly lead to mobile monitoring interruption, missing grid coverage, and a break in the second-level sampling data link. Pollution hotspots may spread or dissipate during this period, resulting in irrecoverable loss of monitoring data.

[0005] Existing unmanned vehicle dispatching technology has the following three main technical shortcomings: First, there is a lack of integrated scheduling mechanisms tailored to the heterogeneous characteristics of mobile monitoring tasks. Existing solutions focus on scenarios such as logistics and distribution, and mining transportation, with scheduling objectives based solely on the shortest path or optimal transfer efficiency. They do not address atmospheric environmental monitoring scenarios and fail to consider the technical requirements for full grid coverage during routine mobile monitoring patrols, as well as the special requirements for second-level sampling density during emergency high-value scheduling. Consequently, they cannot simultaneously handle periodic grid coverage tasks and sudden targeted mobile monitoring tasks.

[0006] Second, the current vehicle selection phase lacks a range feasibility assessment based on an energy consumption coupling model. Existing scheduling schemes only consider vehicle driving energy consumption and driving distance during vehicle selection, failing to incorporate the continuous operating power consumption of onboard environmental monitoring equipment and the real-time communication power consumption of second-level sampling data back to the energy consumption model. Furthermore, they do not include the nonlinear effects of battery health (SOH), real-time state of charge (SOC), and ambient temperature on discharge efficiency as constraints. The fixed range estimation methods used in existing schemes (such as nominal range minus driving distance) exhibit significant deviations in low-temperature environments or long-duration driving scenarios, leading to range assessment results that deviate from reality and a high risk of mission termination mid-journey.

[0007] Third, the conflict resolution lacks a quantitative decision-making model linked to mobile monitoring operations. Existing solutions do not establish a mathematical mapping between emergency task warning levels and daily patrol grid coverage priorities, nor do they formulate differentiated resolution strategies based on the coverage ratio of mobile monitoring tasks. Conflict resolution relies on manual experience for vehicle assignment and route adjustments, making it difficult to guarantee both grid coverage integrity and emergency response timeliness in multi-vehicle, multi-task scenarios. Summary of the Invention

[0008] The purpose of this invention is to provide a multi-task scheduling and range optimization system for pure electric unmanned vehicles used for mobile environmental monitoring, and to solve the following three specific technical problems: (1) In the existing technology, periodic grid coverage inspection tasks and sudden high-value target mobile inspection tasks cannot be modeled in the same scheduling framework, which leads to the reliance on manual arbitration when the two types of tasks compete for vehicle resources, and the response time and coverage integrity cannot be guaranteed at the same time. (2) The fixed driving range estimation method used in the vehicle selection stage in the prior art does not consider the nonlinear effect of ambient temperature on battery discharge efficiency, nor does it couple the operating power consumption of on-board monitoring equipment, resulting in the driving range evaluation results deviating from reality and a high rate of termination of the driving mission midway. (3) In the existing technology, the task conflict resolution lacks a quantitative decision-making model based on the characteristics of mobile navigation business, and no mathematical correlation is established between the emergency task warning level and the proportion of grid covered by the patrol task. The conflict resolution results are not reproducible and cannot achieve Pareto optimality of grid coverage integrity and emergency response timeliness in multi-vehicle scenarios.

[0009] To achieve the above objectives, this invention provides a multi-task scheduling and range optimization system for unmanned vehicles (UAVs) oriented towards mobile environmental monitoring. Relying on an intelligent monitoring and traceability platform for UAVs, the system collects real-time vehicle status data through a task management layer and sequentially executes four technical stages: range feasibility assessment, multi-target vehicle selection, task conflict detection and quantification resolution, and mobile task generation and distribution. The technical architecture of this method consists of five interrelated functional modules, and the data flow and control flow relationships between the modules are as follows: Module 1: Data Acquisition Layer. This layer interacts with the autonomous vehicle's onboard system via multiple physical communication links: It reads battery capacity C (in kWh, taken from the nameplate or BMS calibration value) and battery health status SOH (in %), calculated by the BMS based on charge / discharge cycles and internal resistance changes, and real-time remaining charge SOC (in %), estimated by the BMS based on current voltage and current integration, through the API interface; it reads the vehicle's real-time latitude and longitude coordinates and instantaneous speed at a 1Hz frequency through the GPS module; it reads the ambient temperature T (in °C) through the temperature sensor; it reads the online status (normal / fault / offline) of the onboard environmental monitoring equipment and the signal strength of the 4G / 5G communication module through the device management module; and it receives external high-value scheduling requests through the 4G / 5G communication link.

[0010] After the aforementioned multi-source heterogeneous data is fused on the platform side, it forms the state vector S_v=[C,SOH,SOC,lat,lon,v,T,device_status,signal_strength] for each autonomous vehicle. The state vector is written to the time-series database every 10 seconds for subsequent modules to query and call in real time.

[0011] The state vector parameters are shown in the table below:

[0012] It should be noted that the Time Series Database (TSDB) described in this invention belongs to a specific category of database technology designed for time-series data. Time-series data refers to a series of data points generated in chronological order, with each data point containing a timestamp and a corresponding measurement value. Time-series databases are a well-known category of database technology and are used only as a data storage implementation means in the technical solution of this invention.

[0013] Module 2: Range Feasibility Assessment Module. This module reads the state vectors of candidate vehicles from the time-series database, extracts the energy-related parameters [C, SOH, SOC, T], and sequentially performs three sub-steps: baseline calculation of energy consumption per 100 kilometers, ambient temperature correction, and range feasibility judgment. It outputs the range feasibility judgment result and the corrected energy consumption per 100 kilometers. This module has a data interface with Module 3: V_feasible (set of range-feasible vehicles) and E_corr(v) (corrected energy consumption per 100 kilometers) are transmitted to Module 3.

[0014] Module 3: Multi-target vehicle selection module. This module receives V_feasible and E_corr(v) output from Module 2, reads the position, speed, and task status of each vehicle from the time-series database, calculates the response time by combining the target position in the high-value scheduling request, reads the priority and covered grid ratio of the current task from the daily patrol task database, calculates three scoring indicators, sorts them according to fixed weights, and selects the vehicle with the best comprehensive score. This module has a control interface with Module 4: the optimal vehicle v* and its current task status are transmitted to Module 4 for conflict detection.

[0015] Explanation of the daily patrol task database: This is a database in the system that stores "templates" for daily patrol tasks. It is specifically used to manage and maintain patrol tasks that are performed daily, with fixed routes and established procedures. Its specific functions include the following three: Function 1: Generating "blueprints" for daily patrol tasks. Every morning, the system dispatches vehicles for patrols, not by creating routes on the spot, but by directly retrieving templates from this database and generating specific task packages based on the vehicle's status that day. Without this database, the system wouldn't know which routes to take or which grids to cover that day.

[0016] Function 2: "Judgment Basis" for Conflict Resolution. When an emergency high-value dispatch task arrives, and the system selects a vehicle that is currently performing a routine patrol, it needs to determine whether to interrupt / delay / split this patrol task. Where does the judgment basis come from? It is obtained by checking the priority weight (priority_j) and the proportion of covered grids (grid_ratio) of this route from the task database.

[0017] For example, route B has a priority of 1.0 (high). The system knows that this route is important and will try to protect it in case of conflict. Route A has a priority of 0.8 (medium). If an orange alert is issued, the orange alert can override the 0.8 priority (by checking the priority tensor), so it can be interrupted.

[0018] Function 3: A "metric" for grid coverage integrity. When the system calculates the grid_ratio (the proportion of covered grids) of a vehicle, it uses the grid_set_j (the total number of grids that should be covered) stored in the task library as the denominator, and matches it with the actual trajectory traveled by the vehicle's GPS to calculate how many grids have been covered.

[0019] This ratio directly determines which strategy to use when resolving conflicts: 70% or more coverage → postpone (the process is almost finished, continue running later); 30%-70% coverage → split (completed data is retained, the remaining part is redistributed); less than 30% coverage → take over from the nearest location (don't let other vehicles make a wasted trip, find a nearby vehicle to take over).

[0020] Module 4: Conflict Quantization and Resolution Module. This module receives the optimal vehicle v* output by Module 3 and queries whether the vehicle is currently performing a mobile task. If a conflict exists, it loads a pre-stored priority tensor, performs an index query to obtain an arbitration decision, and selects a differentiated resolution strategy based on the proportion of covered grid cells. This module has a task interface with Module 5: the final scheduling scheme after resolution is transmitted to Module 5.

[0021] Module 5: Mobile Task Generation and Distribution Module. This module receives the final scheduling scheme output by Module 4, combines it with parameters from the daily patrol task library or emergency high-value scheduling request, instantiates it into a mobile task package, and distributes it to the unmanned vehicle's onboard control terminal via a 4G / 5G communication link, triggering task status tracking and execution monitoring.

[0022] The specific technical implementation includes the following steps: Step 1: Establish a daily patrol task database for mobile monitoring.

[0023] The periodic mobile patrol routes, grid coverage requirements, frequency, time windows, and sampling parameters are entered into the system to form a standardized set of mobile patrol task templates. Each task template is denoted as: R_j={grid_set_j,route_points_j,period_j,sample_freq_j,target_pollutants_j,time_window_j,priority_j}.

[0024] Where: grid_set_j is the set of hexagonal grids to be covered, each grid is identified by an H3 index. The reason for choosing the H3 hexagonal grid is that: hexagons have 6 equidistant neighbors, and spatial adjacency judgment is simplified to an index lookup operation, which is more accurate than square grids; hexagons have the best approximation of circular pollution diffusion areas, and the drawn hotspot boundaries are closer to the physical reality; H3 supports the direct conversion of latitude and longitude to integer indices, and the grid matching computation complexity is O(1), which is 2 to 3 orders of magnitude faster than storing polygons for spatial intersection queries; at the same time, H3 supports multi-level nested scaling, so there is no need to re-divide historical data when adjusting the grid resolution in the future. route_points_j is the waypoint sequence connecting each grid, consisting of longitude and latitude coordinates, forming a complete fixed route from the starting point to the end point; period_j is the inspection cycle (e.g., daily); sample_freq_j is the second-level sampling frequency configuration (e.g., 5 seconds / time); target_pollutants_j is the marker of the pollutant types to be monitored during this patrol; time_window_j is the expected execution time window; priority_j∈{0.8,0.9,1.0} is the route priority weight.

[0025] Explanation of route priority: A value of 1.0 represents high priority, a key route to be protected, and should be prioritized in case of conflict; a value of 0.9 represents medium priority, a regular patrol route, which can be disregarded in emergencies; a value of 0.8 represents low priority, a general patrol route, which should be prioritized for emergency coverage.

[0026] Step 2: Receive the mobile high-value scheduling request.

[0027] Parse the high-value scheduling request from the external input, E_i={target_loc_i,pollutant_i,alert_level_i,time_limit_i,scan_radius_i}, where: target_loc_i is the latitude and longitude of the target area center; pollutant_i is the type of pollutant that triggers the high value; alert_level_i∈{blue, yellow, orange, red} is the warning level; time_limit_i is the hard constraint on response time; and scan_radius_i is the target mobile coverage radius.

[0028] Step 3: Range feasibility assessment and multi-objective vehicle selection.

[0029] Sub-phase A – Range Feasibility Assessment: Step 3.1: Calculation of energy consumption baseline per 100 kilometers. For candidate vehicle v, read the SOC change and driving distance of its most recent complete journey from the time-series database, and calculate the energy consumption baseline value E_base(v) per 100 kilometers using the SOC method. The calculation formula is: E_base(v)=[SOC_start(v)-SOC_end(v)]×C(v) / S(v)×100; Wherein: SOC_start(v) is the SOC value (%) at the start of the current trip, recorded by the BMS at the departure time; SOC_end(v) is the SOC value (%) at the end of the current trip, recorded by the BMS at the arrival time; C(v) is the battery capacity (kWh), taken from the BMS calibration value; S(v) is the actual driving distance (km) of the current trip, which is obtained by accumulating the calculation results of the Haversine formula based on the GPS track point sequence. This reference value reflects the energy consumption per unit distance of the vehicle under the comprehensive working condition of performing the mobile monitoring task (including vehicle driving and on-board equipment operation).

[0030] Further, in addition to the SOC method, a power integration method may be adopted for calculating the reference of energy consumption per 100 kilometers: the driving motor power P_motor(t), the power consumption P_device(t) of the on-board environmental monitoring equipment, and the power consumption P_comm(t) of the 4G / 5G communication module are collected in real time through the CAN bus, and integrated over time to obtain E_actual=∫[P_motor(t)+P_device(t)+P_comm(t)]dt, and the energy consumption per 100 kilometers=E_actual / S×100. This method has higher accuracy but requires the CAN bus to open a real-time power data interface.

[0031] Step 3.2: Environmental temperature correction. The current environmental temperature T(v) is read from the time series database, and the correction coefficient α(v) is queried according to a preset temperature correction coefficient table: T(v)<-10°C: α(v)=1.35, extremely cold in winter; -10°C≤T(v)<0°C: α(v)=1.20, cold in winter; 0°C≤T(v)<10°C: α(v)=1.10, normal in winter; 10°C≤T(v)<20°C: α(v)=1.05, cool in spring and autumn; 20°C≤T(v)≤25°C: α(v)=1.00, reference temperature; 25°C<T(v)≤30°C: α(v)=1.05, normal in summer; 30°C<T(v)≤35°C: α(v)=1.15, hot in summer; T(v)>35°C: α(v)=1.25, extremely hot in summer; The calculation formula for the corrected value of energy consumption per 100 kilometers is: E_corr(v)=E_base(v)×α(v).

[0032] Furthermore, in addition to fixed segmented table lookup, the temperature correction coefficient can be obtained by using an energy consumption prediction model based on random forest, with ambient temperature, humidity, wind speed, and vehicle load as input features, and dynamically outputting the correction coefficient.

[0033] Step 3.3: Range Feasibility Assessment. Calculate the safe available battery capacity E_safe(v): E_safe(v) = C(v) × SOH(v) × SOC_current(v) - C(v) × SOH(v) × 10%; where SOC_current(v) is the vehicle's real-time remaining battery percentage, updated by the BMS every 100ms, taking the latest value at the time of task scheduling. The second term, C(v) × SOH(v) × 10%, is the minimum safe battery capacity threshold, reserving 10% of the battery capacity to prevent over-discharge and ensure the vehicle's basic needs for returning to the charging point.

[0034] Calculate the safe power requirement E_need(v): E_need(v)=E_corr(v)×D_total(v) / 100×β; Where: D_total(v) is the planned total travel distance (km) for this mobile patrol mission. For routine patrol missions, the fixed total mileage of the route is directly read from the routine patrol mission database; for emergency high-value dispatch missions, the platform calls the map route planning API to automatically calculate the total distance based on the vehicle's current location, target area, and return point. β=1.15 is a safety factor used to cover energy consumption uncertainties caused by route planning deviations, congestion detours, and wind speed-induced drag.

[0035] The condition for determining range feasibility is: E_safe(v) ≥ E_need(v). Vehicles that meet this condition are marked as range-feasible vehicles and form the candidate set V_feasible. Vehicles that do not meet the condition are directly eliminated and do not enter the subsequent selection process.

[0036] Sub-stage B – Multi-objective vehicle selection: Step 3.4: Define three scoring metrics. For each candidate vehicle v in the feasible range vehicle set V_feasible, calculate three scoring metrics: (1) Response time score s1(v): s1(v) = T_resp(v) / T_limit; where T_resp(v) is the estimated time (in minutes) for vehicle v to travel from its current location to the target area in one trip, calculated by the map path planning API based on the complete path; T_limit is the hard constraint (in minutes) on the response time of this emergency high-value scheduling task.

[0037] (2) Interruption cost score s2(v): s2(v) = interrupt_flag(v) × priority_current(v) × (1 - grid_ratio(v)); where interrupt_flag(v) ∈ {0,1} is the interrupt flag (0 = idle, 1 = currently executing a mobile task); priority_current(v) is the route priority weight of the currently executing mobile task; grid_ratio(v) ∈ [0,1] is the proportion of the number of grids covered by the current mobile task to the total number of grids to be covered, calculated by spatial matching between the vehicle's GPS trajectory and the grid_set. If the vehicle is idle, s2(v) = 0.

[0038] (3) Battery life rating s3(v): s3(v) = [E_safe(v) - E_need(v)] / E_need(v), which represents the redundancy multiple of the battery life exceeding the safety requirements.

[0039] Step 3.5: Determine the weighting coefficients. Based on the mobile monitoring business requirements, pre-set the weighting coefficients for the three indicators: w1=0.60 (response time has the highest weight, ensuring emergency response timeliness), w2=0.25 (interruption cost is secondary, ensuring daily coverage integrity), and w3=0.15 (endurance margin has the lowest weight, serving as a safety redundancy reference). The weighting coefficients are pre-configured by the system administrator according to actual business needs and stored in the system parameter table.

[0040] Step 3.6: Overall Scoring and Ranking. Calculate the overall score (Score(v)) for each candidate vehicle: Score(v)=w1×s1(v)+w2×s2(v)-w3×s3(v); Sort by score(v) in ascending order and select the vehicle ranked first as the optimal dispatch vehicle v*.

[0041] Scoring rules: Smaller values ​​for s1(v) and s2(v) are better, as they contribute positively to the total score when multiplied by a positive weight; larger values ​​for s3(v) are better (meaning ample battery life), as they negatively lower the total score when multiplied by a negative weight, hence the use of a minus sign.

[0042] When calculating the overall score Score(v) for each candidate vehicle, the constraints for the optimization solution are as follows: g1(v): T_resp(v)≤T_limit, a hard constraint on response time; g2(v): E_safe(v)≥E_need(v), a hard constraint on battery life; g3(v): comm_status(v) = online, communication status constraint; g4(v): device_status(v) = Normal, vehicle environment monitoring equipment operating condition constraints; If the vehicle ranked first is eliminated in the subsequent conflict resolution, the second and third ranked vehicles will be selected in turn as the optimal scheduling vehicle v*.

[0043] Step 4: Detect conflict during mobile navigation missions.

[0044] Read the current task status of the optimal vehicle v* from the time-series database: If v*'s task status is idle, it is determined that there is no conflict, and proceed directly to step 6. If v* is executing the mobile task R_j, compare the spatiotemporal conflict degree between the emergency high-value scheduling task E_i and the current mobile task R_j: Time-domain conflict: Determine whether the expected execution time window of E_i [T_start(E_i),T_end(E_i)] overlaps with the remaining execution time window of R_j [now,T_end(R_j)], where T_start(E_i)=now+T_resp(v*); T_end(E_i)=T_start(E_i)+T_execute(E_i); T_execute(E_i) is the expected execution time of the entire navigation route.

[0045] Spatial conflict: Calculate the spatial distance between the target region of E_i and the remaining uncovered grid set of R_j. If the minimum distance is greater than 5km, it is determined that the spatial deviation is too large. If the temporal domain overlaps and the spatial deviation is greater than the threshold, it is marked as a conflicting task pair (E_i,R_j) and proceeds to step 5. Otherwise, it is determined that there is no conflict and proceeds to step 6.

[0046] Furthermore, in the conflict resolution mode selection rules, the coverage grid ratio threshold (30%, 70%) and the nearest takeover distance threshold (2km) can be dynamically adjusted according to the fleet size and road network density.

[0047] Step 5: Quantitatively resolve conflicts in mobile navigation missions.

[0048] Step 5.1: Load the priority tensor. Load the pre-stored priority tensor P∈R^(M×N) from the system configuration library, where M=4 is the warning level dimension (blue=1, yellow=2, orange=3, red=4), and N=3 is the patrol route priority dimension (high=1 corresponds to priority_j=1.0, medium=2 corresponds to priority_j=0.9, low=3 corresponds to priority_j=0.8). The tensor element p_{m,n}∈{0,1} represents the coverage permission identifier of the m-th type of emergency high-value task on the n-th type of daily patrol and mobile task.

[0049] The priority tensor assignment logic is based on the principle of balancing the timeliness and data continuity of environmental monitoring operations: Red alerts are at the highest alert level and must complete on-site mobile source tracing in the shortest possible time, allowing coverage of any priority daily patrol tasks, corresponding to tensor row [1,1,1]; Orange alerts correspond to significant high pollution values ​​and have high response time requirements, allowing coverage of medium and low priority daily patrol tasks, but if they conflict with high priority daily patrol tasks (such as routes around national control points), they are not allowed to be covered in order to ensure the continuity of national control data, corresponding to tensor row [0,1,1]; Yellow alerts correspond to relatively high pollution concentrations and have medium response time requirements, only allowing coverage of low priority daily patrol tasks, corresponding to tensor row [0,0,1]; Blue alerts correspond to mild anomalies and have lower response time requirements, prioritizing the continuity of daily patrol data, and are not allowed to cover any priority daily patrol tasks, corresponding to tensor row [0,0,0].

[0050] Complete tensor assignment: P=[000;001;011;111].

[0051] Furthermore, the priority tensor P can be extended to four dimensions, adding a "time period sensitivity" dimension (such as assessment period, heavy pollution weather warning period) to achieve more refined conflict arbitration.

[0052] Step 5.2: Tensor Index Query. Determine the dimension index m based on the alert_level_i of the emergency task, and determine the dimension index n based on the priority_j of the current patrol task. Query the priority tensor P through index (m,n) to obtain the arbitration decision: If p_{m,n}=1: the emergency task has a higher priority than the daily patrol task, execute the conflict resolution strategy in Step 5.3; if p_{m,n}=0: the emergency task has a lower priority than or equal to the daily patrol task, mark v* as unavailable, and return to Step 3.6 to select the second-best vehicle for replacement; if all candidate vehicles cannot satisfy the constraints under conflict-free conditions, trigger the manual review process and report it.

[0053] Step 5.3: Execution of conflict resolution strategy. When p_{m,n}=1, read the covered grid ratio (grid_ratio(v*)) of the current mobile task from the time series database, and select the resolution mode according to the following rules: Rule 1: If grid_ratio(v*) < 30% and there are other vehicles k that are in an idle state and whose distance from the center point d_k of the starting grid of the segment to be executed is < 2km, then mode 3 (nearest vehicle takes over) is adopted. The method for determining the takeover vehicle k is as follows: Calculate the Euclidean distance d_k = Haversine(lat_k,lon_k,lat_start,lon_start) from all idle vehicles in the platoon to the center point of the starting grid of the segment R_j^todo, and select the vehicle with the smallest d_k as the takeover vehicle. A new navigation path is planned for the takeover vehicle so that it can detour and cover the uncovered grid sequence in R_j^todo after completing its original task.

[0054] Rule 2: If 30% ≤ grid_ratio(v*) < 70%, then Mode 2 (mobile patrol task splitting) is adopted. The daily patrol mobile patrol task R_j is split into an executed segment R_j^done and an unexecuted segment R_j^todo based on the covered and uncovered grids: the executed segment contains the grids in grid_set_j that have been covered by the GPS track, and their mobile patrol data is retained; the unexecuted segment contains the grids in grid_set_j that have not been covered, and is entered into the task pool as an independent mobile patrol task to await reallocation.

[0055] Rule 3: If grid_ratio(v) ≥ 70%, then Mode 1 (postponement of mobile monitoring tasks) is adopted. The overall execution time window of the routine patrol mobile monitoring task R_j is shifted backward, with a shift duration ΔT = T_resp(v) + T_execute(E_i) + T_margin, where T_execute(E_i) is the estimated execution time of the emergency high-value mobile monitoring task (calculated from the area of ​​the mobile monitoring area and the sampling density), and T_margin is the buffer time (taken as 10 minutes). The new time window after the shift is [T_end(E_i) + T_margin, T_end(E_i) + T_margin + T_rem(R_j)], where T_rem(R_j) is the remaining estimated execution time of R_j.

[0056] Step 6: Mobile Task Generation and Distribution. The finalized scheduling scheme is instantiated as a mobile task packet (Task_Packet). The structure and content of the task packet are generated differently based on the task type: (1) If it is an emergency high-value dispatch task, the task package includes: nav_path: the navigation path from the current location of the vehicle to the target area and covering all specified grids, generated by the map path planning API; grid_sequence: the hexagonal grid coverage sequence within the radius scan_radius_i centered on the target point, sorted by spatial proximity to reduce backtracking; sample_freq: the second-level sampling frequency configuration, the sampling frequency of emergency high-value mobile tasks is higher than that of daily patrols (e.g., from 5 seconds / time to 3 seconds / time); target_pollutants: the pollutants that need to be focused on are marked according to the type of triggering pollutants (e.g., if the triggering pollutant is PM10, then PM10, PM2.5, and TSP are marked as objects of focus); est_duration: the estimated execution time, estimated by dividing the fixed total mileage of the route by the average vehicle speed; status_rules: the task status transition rules (standby → proceed → mobile → return → completed).

[0057] (2) If it is a routine patrol and navigation task (including the adjustment task after the extension or takeover), the task package includes: nav_path: the updated grid coverage navigation path; grid_sequence: the adjusted hexagonal grid coverage sequence; sample_freq: the standard sampling frequency for routine patrol (e.g., 5 seconds / time); target_pollutants: the pollutant attention list preset for the patrol route; est_duration: the updated estimated execution time; status_rules: the task status transition rules.

[0058] The task package is sent to the unmanned vehicle's onboard control terminal via a 4G / 5G communication link. Upon receiving the package, the unmanned vehicle automatically switches to the corresponding mobile mode based on the task type: the emergency high-value mode enables high-frequency sampling and real-time data enhancement and backhaul, while the routine patrol mode enables standard sampling and timed batch backhaul. During the mobile operation, the sampled data is transmitted back to the platform in real time at the second level, and the platform performs subsequent processes such as data cleaning, high-value identification, and hotspot analysis.

[0059] Based on the above technical solution, the advantages of the present invention are: (1) In view of the technical defects of the existing technology, which uses a fixed driving range estimation method in the vehicle selection stage and does not consider the nonlinear effect of ambient temperature on battery discharge efficiency, the present invention establishes a driving range feasibility assessment model based on the SOC method energy consumption benchmark calculation per 100 kilometers and superimposed with ambient temperature segment correction in the technical solution.

[0060] Existing fixed-range estimation methods use the vehicle's nominal range minus the distance traveled as the criterion. This method implicitly assumes that the battery capacity remains constant at all temperatures and supplies only the vehicle's drive system. However, lithium batteries experience a significant increase in internal resistance and a decrease in usable capacity at low temperatures (e.g., usable capacity is approximately 70%-80% of the nominal value at -15°C). Simultaneously, the constant power consumption of onboard environmental monitoring equipment (sampling pump, air circuit, communication module) continuously diverts battery power. These two factors lead to a systematic overestimation of fixed-range estimation in low-temperature or long-duration driving scenarios. When a vehicle with an inflated range is assigned to the vehicle, the battery is depleted prematurely during actual driving, resulting in driving interruption.

[0061] This invention calculates the baseline energy consumption per 100 kilometers under comprehensive operating conditions using the SOC method (this baseline inherently includes drive energy consumption and equipment operating power consumption), and introduces a segmented correction coefficient for ambient temperature (the correction coefficient is 1.35 at -15℃) to quantify the coupled impact of low temperature on battery discharge efficiency degradation and equipment power consumption into the energy consumption model. Furthermore, by comparing the safe available power (minus 10% of the minimum safety threshold) with the safe required power (including a safety factor of 1.15), vehicles with unfeasible range are filtered out during the vehicle selection phase.

[0062] Beneficial effects: Verified by actual platform operation, in low temperature (<-10℃) scenarios, the mid-journey termination rate of the mobile mission decreased from 8.0% of the existing solution to 0.5% of the present invention, a reduction of 93.8%; in normal temperature scenarios, the termination rate decreased from 2.1% to 0.5%, a reduction of 76.2%.

[0063] (2) In view of the technical defects of low vehicle utilization caused by the use of single-objective optimization (such as only considering the shortest distance or only considering the response time) in the multi-task scheduling of the prior art, the present invention constructs three scoring indicators with response time, task interruption cost and range margin matching degree as objectives in the technical solution, and sorts them by weight with fixed weights.

[0064] Existing single-objective optimization schemes use the distance between vehicles and target points or the estimated response time as the sole ranking criterion, implicitly assuming that all vehicles are identical except for distance. However, in real-world mobile monitoring scenarios, the closest vehicle may be performing a high-priority daily patrol task (containing a large number of uncovered grid cells), and a forced interruption would result in missing grid coverage for the day; the second closest vehicle may be idle, with zero interruption cost; and the furthest vehicle may have ample remaining range. Single-objective optimization cannot balance these three dimensions, leading to either selecting vehicles with excessively high interruption costs (damaging coverage integrity), selecting vehicles with insufficient remaining range (risk of task termination), or leaving idle vehicles idle while occupying vehicles performing tasks (low utilization).

[0065] This invention incorporates response time, task interruption cost (quantified by the proportion of uncovered grid cells), and range redundancy into the scoring system, calculating a comprehensive score using fixed weights (w1=0.60, w2=0.25, w3=0.15). Idle vehicles naturally receive a higher ranking due to s2=0; vehicles performing tasks have their interruption cost calculated based on the proportion of uncovered grid cells, with vehicles having a high proportion of uncovered cells ranked lower to avoid disrupting coverage integrity; vehicles with ample range redundancy receive bonus points due to a larger s3. The scoring results directly reflect a comprehensive trade-off between three business dimensions: emergency response timeliness, daily coverage integrity assurance, and range redundancy safety.

[0066] Beneficial effects: Actual platform operation verification shows that the average daily vehicle utilization rate has increased from 62% in the existing solution to 81% in this invention, an increase of 30.6%; the daily patrol grid coverage rate has increased from 85% to 96%, an increase of 11.8%.

[0067] (3) In view of the technical defects of existing technologies, which rely on human experience and lack quantitative decision-making models for task conflict resolution, this invention establishes a priority tensor index query mechanism and a differentiated resolution strategy based on the proportion of covered grids in the technical solution.

[0068] When emergency missions conflict with routine patrol missions, the existing solution relies on dispatchers to manually determine which mission takes priority and whether to interrupt the current patrol. This manual judgment is influenced by subjective experience and is not reproducible. Furthermore, dispatchers cannot simultaneously access multi-dimensional information such as the real-time location, remaining range, and current mission progress of all vehicles, leading to significant variance in the timeliness and coverage completeness of the arbitration results.

[0069] This invention maps emergency task warning levels and daily patrol route priorities to mathematical coverage permission decisions (0 / 1 values) using a predefined priority tensor P∈R^(4×3). Resolution arbitration is automatically completed by tensor index queries, eliminating subjective judgment differences. Furthermore, the resolution strategy is selected based on the coverage ratio of the current mobile task: a continuation strategy is used when the coverage ratio is high (≥70%) to ensure the integrity of covered data while releasing vehicles; a splitting strategy is used when the coverage ratio is medium (30%-70%) to retain completed grid data and redistribute remaining tasks; and a takeover strategy is used when the coverage ratio is low (<30%) and there is a nearby takeover vehicle to avoid canceling all initiated tasks.

[0070] Beneficial effects: Verified by actual platform operation, the average emergency response time was shortened from 45 minutes in the existing solution to 28 minutes in this invention, a reduction of 37.8% in response time; the integrity rate of second-level sampling data was increased from 91% to 99.2%, an improvement of 8.2%. Attached Figure Description

[0071] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings: Figure 1 Workflow diagram for multi-task scheduling and range optimization system for unmanned vehicles. Detailed Implementation

[0072] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0073] This invention provides a multi-task scheduling and range optimization system for unmanned vehicles (UAVs) for mobile environmental monitoring, such as... Figure 1 As shown, it includes: The data acquisition layer interacts with the unmanned vehicle's onboard system through multiple physical communication links, including battery capacity C, battery health status SOH, real-time remaining power SOC, real-time vehicle latitude and longitude coordinates and instantaneous vehicle speed, ambient temperature T, online status of onboard environmental monitoring equipment, and signal strength of 4G / 5G communication modules. It also receives external high-value scheduling requests through the 4G / 5G communication link.

[0074] The range feasibility assessment module reads the state vectors of candidate vehicles from the time-series database, extracts the energy-related parameters [C,SOH,SOC,T], and sequentially performs three sub-steps: energy consumption benchmark calculation per 100 kilometers, ambient temperature correction, and range feasibility judgment. It then outputs the range feasibility judgment result and the corrected energy consumption value per 100 kilometers.

[0075] The multi-target vehicle selection module receives the range feasibility judgment result and the corrected energy consumption value per 100 kilometers. It reads the position, speed and task status of each vehicle v from the time series database, calculates the response time by combining the target position in the high-value scheduling request, reads the priority and coverage ratio of the current task from the daily patrol task library, calculates three scoring indicators and selects the vehicle v* with the best comprehensive score by weighting and sorting them according to fixed weights. The three scoring indicators are response time score, interruption cost score and range margin score.

[0076] The conflict quantification and resolution module receives the optimal vehicle v* information, queries whether the vehicle is currently performing a mobile task, and if a conflict exists, loads the pre-stored priority tensor to perform an index query to obtain an arbitration decision, and selects a differentiated resolution strategy based on the proportion of covered grids to obtain the final scheduling scheme.

[0077] The mobile mission generation and distribution module receives the final scheduling plan, combines it with parameters from the daily patrol mission library or emergency high-value scheduling requests, instantiates it into a mobile mission package, and distributes it to the unmanned vehicle's onboard control terminal via a 4G / 5G communication link, triggering mission status tracking and execution monitoring.

[0078] Furthermore, taking the application of the unmanned vehicle multi-task scheduling and endurance optimization system of the present invention in a certain area as an example, a fleet of five pure electric unmanned vehicles equipped with nine atmospheric particulate matter monitoring devices is deployed to achieve integrated management of daily patrol and emergency high-value patrol through the unmanned vehicle intelligent monitoring and traceability platform.

[0079] The specific deployment and data flow of the five modules in the platform are as follows: The data acquisition layer reads battery parameters from each vehicle's BMS via an API interface at 100ms intervals, location coordinates via GPS at 1Hz frequency, ambient temperature via a temperature sensor, and the online status of nine-parameter monitoring devices via the device management module. This data is then fused to form a state vector S_v, which is written to the platform's time-series database (using InfluxDB) at 10-second intervals.

[0080] The range feasibility assessment module reads the state vectors of each vehicle from the time-series database every 30 seconds, performs the range feasibility assessment in steps 3.1-3.3, and writes V_feasible and E_corr(v) into the cache for use by the multi-target vehicle selection module.

[0081] The multi-objective vehicle selection module is triggered when it receives an emergency high-value dispatch request. It reads V_feasible and E_corr(v), and executes steps 3.4-3.6 in combination with the request parameters to output the optimal vehicle v*.

[0082] The conflict quantification and resolution module receives v*, performs conflict detection and resolution in steps 4 and 5, and outputs the final scheduling scheme.

[0083] The mobile task generation and distribution module instantiates the scheduling scheme into task packages and distributes them to the vehicle-mounted terminal of the unmanned vehicle via MQTT over 4G / 5G.

[0084] Furthermore, the technical solution of the present invention will be described below using two more specific implementation scenarios as examples: Example 1: Optimal vehicle direct deployment for emergency high-value mobile monitoring under normal temperature conditions Step 1: Parse the high-value scheduling request E_i={target_loc=(116.52,39.79),pollutant=PM10,alert_level=orange,time_limit=60 minutes,scan_radius=500 meters}.

[0085] Step 2: The task management layer obtains the state vectors of the five autonomous vehicles via API and GPS: Unmanned vehicle 1: S1=[60,90%,30%,…,22℃,normal,strong]——is currently performing routine patrol and navigation on route B (40% of the grid has been covered); Driverless car 2: S2=[60,95%,85%,…,22℃,Normal,Strong]——Parking lot is empty; Unmanned vehicle 3: S3=[60,92%,45%,…,22℃,Normal,Strong]——is currently performing routine patrol and navigation on route C (70% of the grid has been covered); Unmanned vehicle 4: S4=[60,88%,15%,…,22℃,normal,weak]——Returning to charge, communication signal is weak; Unmanned vehicle 5: S5=[60,96%,75%,…,22℃,Normal,Strong]——is currently performing routine patrol and navigation on route A (10% of the grid has been covered).

[0086] Step 3: Range feasibility assessment and multi-objective vehicle selection.

[0087] Sub-phase A – Range Feasibility Assessment: If an autonomous vehicle has a State of Charge (SOC) of 15% and is in a charging state, it will be directly eliminated; if the communication signal is weak and does not meet constraint g4, it will be eliminated even if the SOC is sufficient.

[0088] The ambient temperature is 22℃. From the temperature correction factor table, α = 1.00.

[0089] Driverless car 2 (idle, parking lot): Most recent complete cruise trip: SOC_start=90%, SOC_end=78%, travel distance: S=20km-E_base=(90-78)×60 / 20×100=18kWh / 100km; E_corr=18×1.00=18kWh / 100km.

[0090] This is an emergency high-value dispatching task. D_total is calculated to be 29km by the map API.

[0091] E_safe=60×95%×85%-60×95%×10%=48.45-5.70=42.75kWh.

[0092] E_need=18×29 / 100×1.15=6.00kWh.

[0093] Judgment: 42.75 ≥ 6.00, the feasibility condition for extended range is met. Driverless car 3 (in progress on route C): The most recent complete mobile survey calibration results in E_base = 19 kWh / 100 km; E_corr = 19 × 1.00 = 19 kWh / 100 km.

[0094] This is an emergency high-value dispatching task. D_total is calculated to be 31km by the map API.

[0095] E_safe=60×92%×45%-60×92%×10%=24.84-5.52=19.32kWh; E_need=19×31 / 100×1.15=6.77kWh.

[0096] Judgment: 19.32≥6.77, satisfied.

[0097] Driverless vehicle 1 (in operation of route B): E_base=20kWh / 100km, E_corr=20kWh / 100km; D_total≈38km, E_need≈8.74kWh; E_safe=60×90%×30%-5.40=10.80kWh; Judgment: 10.80 ≥ 8.74, the critical condition is met.

[0098] Driverless car 5 (starting section of route A): E_base=18.5kWh / 100km, E_corr=18.5kWh / 100km; D_total≈35km, E_need≈7.45kWh; E_safe = 37.44 kWh; Judgment: 37.44 ≥ 7.45, satisfied.

[0099] Sub-stage B – Multi-objective vehicle selection: The weighting coefficients are w1=0.60, w2=0.25, and w3=0.15.

[0100] Driverless car 2 (idle): T_resp = 35 minutes, s1 = 35 / 60 = 0.583; interrupt_flag=0, s2=0; R_margin=(42.75-6.00) / 6.00=6.13, s3=6.13; Score=0.60×0.583+0.25×0-0.15×6.13=0.350+0-0.920=-0.570.

[0101] Driverless car 3 (in progress on route C): T_resp = 50 minutes, s1 = 50 / 60 = 0.833; interrupt_flag=1, priority=0.9, grid_ratio=0.70, s2=0.9×(1-0.70)=0.270R_margin=(19.32-6.77) / 6.77=1.85, s3=1.85; Score=0.60×0.833+0.25×0.270-0.15×1.85=0.500+0.068-0.278=0.290.

[0102] Driverless car 5 (starting section of route A): T_resp = 110 minutes, s1 = 110 / 60 = 1.833; interrupt_flag=1, priority=0.8, grid_ratio=0.10, s2=0.8×(1-0.10)=0.720; R_margin=(37.44-7.45) / 7.45=4.02, s3=4.02; Score=0.60×1.833+0.25×0.720-0.15×4.02=1.100+0.180-0.603=0.677.

[0103] Driverless vehicle 1 (in operation of route B): T_resp = 75 minutes, s1 = 1.250; interrupt_flag=1, priority=1.0, grid_ratio=0.40, s2=1.0×0.60=0.600; R_margin=(10.80-8.74) / 8.74=0.236, s3=0.236; Score=0.60×1.250+0.25×0.600-0.15×0.236=0.750+0.150-0.035=0.865.

[0104] Overall ranking (ascending): Driverless car 2 (-0.570) > Driverless car 3 (0.290) > Driverless car 5 (0.677) > Driverless car 1 (0.865). Optimal scheduling vehicle v* = Driverless car 2.

[0105] Step 4: Conflict Detection. Unmanned vehicle 2 is currently idle and there are no ongoing conflicts. In the scheduled task list, there is a routine patrol on Route B at 14:00, but the emergency patrol is expected to be completed within 45 minutes. The vehicle can be released before 14:00, and there is no time overlap, so no conflict is determined.

[0106] Step 5: Proceed directly to Step 6.

[0107] Step 6: Generate and distribute the mobile monitoring task package. The task package contains: {nav_path: parking lot → target area (116.52, 39.79), with complete path planning by the map API; grid_sequence: 7 H3 hexagonal grids within a 500-meter radius centered on the target point, sorted by proximity; sample_freq: 3 seconds / time (higher than the daily patrol's 5 seconds / time); target_pollutants: [PM10, PM2.5, TSP] (PM10 is the trigger pollutant); est_duration: 45 minutes; status_rules: standby → proceed → mobile monitoring → return → completed} The task package is distributed to unmanned vehicle 2 via MQTT over 4G / 5G. Unmanned vehicle 2 switches to emergency high-value mobile monitoring mode and performs second-level sampling mobile monitoring according to grid_sequence, with data transmitted back to the platform in real time.

[0108] Example 2: Low-temperature environment battery life filtration + suboptimal compensation + conflict resolution The technical solution used in this embodiment is similar to that in Embodiment 1, except that: Ambient temperature -15℃ (extremely cold winter), same emergency high-value dispatch request arrives: Step 3: Range feasibility assessment.

[0109] α = 1.35 (extremely cold).

[0110] Driverless car 2 (idle): E_corr=18×1.35=24.3kWh / 100km; D_total=29km, E_need=24.3×29 / 100×1.15=8.11kWh; E_safe = 42.75 kWh, 42.75 ≥ 8.11, which satisfies the condition.

[0111] Driverless car 3 (in progress on route C): SOC_current drops to 35% due to accelerated power loss at low temperatures; E_corr=19×1.35=25.65kWh / 100km; D_total=31km, E_need=25.65×31 / 100×1.15=9.14kWh; E_safe = 60 × 92% × 35% - 5.52 = 13.80 kWh, 13.80 ≥ 9.14, the critical value is satisfied.

[0112] Driverless vehicle 1 (in operation of route B): SOC_current=25% (low temperature decay); E_corr=20×1.35=27kWh / 100km; D_total≈38km, E_need=27×38 / 100×1.15=11.80kWh; E_safe=60×90%×25%-5.40=8.10kWh; Judgment: 8.10 < 11.80, does not meet the feasibility conditions for battery life, therefore eliminated.

[0113] Driverless car 5 (starting section of route A): E_corr=18.5×1.35=24.98kWh / 100km; D_total≈35km, E_need≈10.05kWh; E_safe = 37.44 kWh, which is satisfied.

[0114] Multi-objective vehicle selection: Driverless car 2: Score = 0.60 × 0.583 + 0 - 0.15 × (42.75 - 8.11) / 8.11 = 0.350 - 0.641 = -0.291; Driverless car 3: Score = 0.60 × 0.833 + 0.25 × 0.270 - 0.15 × (13.80 - 9.14) / 9.14 = 0.500 + 0.068 - 0.076 = 0.492; Driverless car 5: Score = 0.60 × 1.833 + 0.25 × 0.720 - 0.15 × (37.44 - 10.05) / 10.05 = 1.100 + 0.180 - 0.409 = 0.871; Sorting: Driverless car 2 (-0.291) > Driverless car 3 (0.492) > Driverless car 5 (0.871).

[0115] Assume that driverless car 2 is offline and unavailable due to a communication failure, then v* = driverless car 3.

[0116] Step 4: Unmanned vehicle 3 is executing route C (70% grid coverage), which conflicts with the emergency mission.

[0117] Step 5: Query the priority tensor. The orange alert (m=3) has a priority of 1 for route C (n=2), p_{3,2}=1, allowing coverage. 70% of the grid is already covered. Select Mode 1 (delayed mobile task): Unmanned vehicle 3 continues to complete the remaining 30% of the grid on route C (estimated 20 minutes). After completion, it proceeds to the emergency area (30 minutes of travel). Emergency mobile navigation will begin 50 minutes after the request is sent, meeting the 60-minute response time constraint of the orange alert.

[0118] In this scenario, unmanned vehicles with insufficient range are filtered out through initial screening of range 1, unmanned vehicles 2 are eliminated offline, and suboptimal unmanned vehicles 3 are selected as replacements. Then, conflicts are resolved by extending the mobile mission. This achieves dual protection of emergency response and daily coverage under the constraint of range safety in extremely cold environments.

[0119] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them; although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications can still be made to the specific implementation of the present invention or equivalent substitutions can be made to some technical features without departing from the spirit of the technical solutions of the present invention, and all such modifications and substitutions should be covered within the scope of the technical solutions claimed in the present invention.

Claims

1. A multi-task scheduling and range optimization system for unmanned vehicles (UAVs) for mobile environmental monitoring, characterized in that: include: The data acquisition layer interacts with the vehicle's onboard system through multiple physical communication links, including battery capacity C, battery health status SOH, real-time remaining power SOC, real-time vehicle latitude and longitude coordinates and instantaneous vehicle speed, ambient temperature T, online status of onboard environmental monitoring equipment and signal strength of 4G / 5G communication modules, and receives external high-value scheduling requests through 4G / 5G communication links. The range feasibility assessment module reads the state vectors of candidate vehicles from the time-series database, extracts the energy-related parameters [C,SOH,SOC,T], and sequentially performs three sub-steps: energy consumption benchmark calculation per 100 kilometers, ambient temperature correction, and range feasibility judgment. It outputs the range feasibility judgment result and the corrected energy consumption value per 100 kilometers. The multi-target vehicle selection module receives the range feasibility judgment result and the corrected energy consumption value per 100 kilometers. It reads the position, speed and task status of each vehicle v from the time series database, calculates the response time by combining the target position in the high-value scheduling request, reads the priority and coverage ratio of the current task by combining the daily patrol task library, calculates three scoring indicators and selects the vehicle v* with the best comprehensive score by weighting and sorting them according to fixed weights. The three scoring indicators are response time score, interruption cost score and range margin score. The conflict quantification and resolution module receives the optimal vehicle v* information, queries whether the vehicle is currently performing a mobile task, and if a conflict exists, loads the pre-stored priority tensor to perform an index query to obtain an arbitration decision, and selects a differentiated resolution strategy based on the proportion of covered grids to obtain the final scheduling scheme. The mobile mission generation and distribution module receives the final scheduling plan, combines it with parameters from the daily patrol mission library or emergency high-value scheduling requests, instantiates it into a mobile mission package, and distributes it to the unmanned vehicle's onboard control terminal via a 4G / 5G communication link, triggering mission status tracking and execution monitoring.

2. The unmanned vehicle multi-task scheduling and range optimization system according to claim 1, characterized in that: The multi-source heterogeneous data acquired by the data acquisition layer is fused on the platform side to form the state vector S of each autonomous vehicle. v =[C,SOH,SOC,lat,lon,v,T,device_status,signal_strength], the state vector is written to the time series database with a period of 10 seconds.

3. The unmanned vehicle multi-task scheduling and range optimization system according to claim 1, characterized in that: The daily patrol task database is a standardized collection of mobile patrol task templates formed by inputting periodic mobile patrol routes, grid coverage requirements, frequency, time windows, and sampling parameters into the system. Each task template is denoted as R. j ={grid_set_j,route_points_j,period_j,sample_freq_j,target_pollutants_j,time_window_j,priority_j}; Wherein: grid_set_j is the set of hexagonal grids to be covered, each grid is identified by an H3 index; route_points_j is the waypoint sequence connecting each grid, consisting of longitude and latitude coordinates, forming a complete fixed route from the start point to the end point; period_j is the patrol cycle; sample_freq_j is the second-level sampling frequency configuration; target_pollutants_j is the marker of the pollutant types to be monitored during this patrol; time_window_j is the expected execution time window; priority_j∈{0.8,0.9,1.0} is the route priority weight, with a value of 1.0 representing high priority, a key route to be protected, and protected in case of conflict; a value of 0.9 representing medium priority, a regular patrol route, which can be given priority in emergencies; and a value of 0.8 representing low priority, a general patrol route, which is prioritized for emergency coverage.

4. The unmanned vehicle multi-task scheduling and range optimization system according to claim 1, characterized in that: The high-value scheduling request parsing externally input high-value scheduling request E_i={target_loc_i,pollutant_i,alert_level_i,time_limit_i,scan_radius_i}; where: target_loc_i is the longitude and latitude of the center of the target area; pollutant_i is the type of pollutant triggering a high value; alert_level_i ∈ {blue, yellow, orange, red} is the alert level; time_limit_i is the hard constraint of response timeliness; scan_radius_i is the coverage radius of targeted cruise.

5. The unmanned vehicle multi-task scheduling and endurance optimization system according to claim 1, characterized in that: The steps for calculating the reference 100-kilometer energy consumption include: for a candidate vehicle v, reading the SOC change and driving distance of the latest complete cruise trip from the time series database, and calculating the reference 100-kilometer energy consumption value E_base(v) using the SOC method, with the calculation formula being: E_base(v)=[SOC_start(v)-SOC_end(v)]×C(v) / S(v)×100; where: SOC_start(v) is the SOC value (%) at the start of the trip, recorded by the BMS at the departure moment; SOC_end(v) is the SOC value (%) at the end of the trip, recorded by the BMS at the arrival moment; C(v) is the battery capacity (kWh), taken from the BMS calibrated value; S(v) is the actual driving distance (km) of the trip, obtained by accumulating the calculation results of the Haversine formula on the GPS track point sequence; The steps for environment temperature correction include: reading the current environment temperature T(v) from the time series database, and querying the correction coefficient α(v) according to the preset temperature correction coefficient table: T(v)<-10℃: α(v)=1.35, extremely cold in winter; -10℃≤T(v)<0℃: α(v)=1.20, cold in winter; 0℃≤T(v)<10℃: α(v)=1.10, normal in winter; 10℃≤T(v)<20℃: α(v)=1.05, cool in spring and autumn; 20℃≤T(v)≤25℃: α(v)=1.00, reference temperature; 25℃<T(v)≤30℃: α(v)=1.05, normal in summer; 30℃<T(v)≤35℃: α(v)=1.15, hot in summer; T(v)>35℃: α(v)=1.25, extremely hot in summer; The calculation formula for the corrected 100-kilometer energy consumption is: E_corr(v)=E_base(v)×α(v); The steps for endurance feasibility judgment include: calculating the safely available electric quantity E_safe(v): E_safe(v)=C(v)×SOH(v)×SOC_current(v)-C(v)×SOH(v)×10%; where: SOC_current(v) is the real-time remaining power percentage of the vehicle, updated by the BMS every 100ms, and the latest value at the task scheduling moment is taken; C(v)×SOH(v)×10% is the minimum safe power threshold; Calculate the safely required electric quantity E_need(v): E_need(v)=E_corr(v)×D_total(v) / 100×β; Where: D_total(v) is the planned total driving distance (km) for this mobile patrol mission; for routine patrol missions, the fixed total mileage of the route is directly read from the routine patrol mission database; for emergency high-value dispatch missions, the platform calls the map path planning API to automatically calculate the total distance based on the vehicle's current location, target area, and return point; β=1.15 is the safety factor; The condition for judging the feasibility of the driving range is: E_safe(v)≥E_need(v). Vehicles that meet this condition are marked as driving range feasible vehicles and form a candidate set V_feasible. Vehicles that do not meet the condition are directly eliminated.

6. The unmanned vehicle multi-task scheduling and range optimization system according to claim 5, characterized in that: The steps for calculating the three scoring indicators and selecting the vehicle with the best overall score (v*) by weighting them according to fixed weights include: (1) Define three scoring metrics: For each candidate vehicle v in the set of feasible vehicles with range V_feasible, calculate three scoring metrics: Response time score s1(v): s1(v) = T_resp(v) / T_limit; where T_resp(v) is the estimated time for vehicle v to travel from its current location to the target area in one trip, calculated by the map path planning API based on the complete path; T_limit is the hard constraint (minutes) on the response time of this emergency high-value dispatch task. Interruption cost score s2(v): s2(v) = interrupt_flag(v) × priority_current(v) × (1 - grid_ratio(v)); where interrupt_flag(v) ∈ {0,1} is the interruption flag (0 = idle, 1 = currently executing mobile task); priority_current(v) is the route priority weight of the currently executing mobile task; grid_ratio(v) ∈ [0,1] is the proportion of the number of grids covered by the current mobile task to the total number of grids to be covered, which is calculated by spatial matching of the vehicle GPS trajectory and grid_set. If the vehicle is idle, s2(v) = 0; Battery life rating s3(v): s3(v) = [E_safe(v) - E_need(v)] / E_need(v); (2) Determine the weighting coefficients: Based on the needs of mobile monitoring business, the weighting coefficients of the three indicators are pre-set: w1=0.60, w2=0.25, w3=0.15; the weighting coefficients are pre-configured by the system administrator according to the actual business needs and stored in the system parameter table; (3) Overall scoring and ranking: Calculate the overall score Score(v) for each candidate vehicle: Score(v)=w1×s1(v)+w2×s2(v)-w3×s3(v); Sort by score(v) in ascending order and select the vehicle ranked first as the optimal dispatch vehicle v*.

7. The unmanned vehicle multi-task scheduling and range optimization system according to claim 6, characterized in that: When calculating the overall score Score(v) for each candidate vehicle, the constraints for the optimization solution are as follows: g1(v): T_resp(v)≤T_limit, a hard constraint on response time; g2(v): E_safe(v)≥E_need(v), a hard constraint on battery life; g3(v): comm_status(v) = online, communication status constraint; g4(v): device_status(v) = Normal, vehicle environment monitoring equipment operating condition constraints; If the vehicle ranked first is eliminated in the subsequent conflict resolution, the second and third ranked vehicles will be selected in turn as the optimal scheduling vehicle v*.

8. The unmanned vehicle multi-task scheduling and range optimization system according to claim 1, characterized in that: The steps for quantitatively resolving conflicts in the mobile mission include: Step 5.1, Load the priority tensor: Load the pre-stored priority tensor P∈R^(M×N) from the system configuration library; where M=4 is the warning level dimension, blue=1, yellow=2, orange=3, red=4; N=3 is the patrol route priority dimension, high=1 corresponds to priority_j=1.0, medium=2 corresponds to priority_j=0.9, low=3 corresponds to priority_j=0.8; the tensor element p_{m,n}∈{0,1} represents the coverage permission identifier of the m-th type of emergency high-value task to the n-th type of daily patrol and mobile task; Step 5.2: Tensor Index Query: Determine the dimension index m based on the alert_level_i of the emergency task, and determine the dimension index n based on the priority_j of the current patrol task. Query the priority tensor P through index (m,n) to obtain the arbitration decision: If p_{m,n}=1: the emergency task has a higher priority than the daily patrol task, and the conflict resolution strategy is executed; if p_{m,n}=0: the emergency task has a lower priority than or equal to the daily patrol task, mark v* as unavailable, and return to select the second-best vehicle for replacement; if all candidate vehicles cannot satisfy the constraints under conflict-free conditions, trigger the manual review process and report it. Step 5.3: Execution of conflict resolution strategy: When p_{m,n}=1, read the covered grid ratio grid_ratio(v*) of the current mobile task from the time series database, and select the resolution mode according to the preset rules.

9. The unmanned vehicle multi-task scheduling and range optimization system according to claim 8, characterized in that: The preset rules include: Rule 1: If grid_ratio(v*) < 30% and there are other vehicles k that are in an idle state and whose distance from the center point d_k of the starting grid of the segment to be executed is < 2km, then the nearest vehicle will take over. The method for determining the takeover vehicle k includes: calculating the Euclidean distance from all idle vehicles in the platoon to the center point of the starting grid of the segment to be executed R_j^todo, d_k = Haversine(lat_k,lon_k,lat_start,lon_start), and selecting the vehicle with the smallest d_k as the takeover vehicle; replanning the navigation path for the takeover vehicle so that it can detour and cover the uncovered grid sequence in R_j^todo after the original task is completed. Rule 2: If 30% ≤ grid_ratio(v*) < 70%, then the mobile patrol task will be split. The daily patrol mobile task R_j will be split into an executed segment R_j^done and an unexecuted segment R_j^todo based on the covered and uncovered grids. The executed segment contains the grids in grid_set_j that have been covered by the GPS track, and their mobile patrol data is retained. The unexecuted segment contains the uncovered grids in grid_set_j and will be entered into the task pool as an independent mobile patrol task to await reallocation. Rule 3: If grid_ratio(v) ≥ 70%, the mobile patrol task will be postponed; the overall execution time window of the daily patrol mobile patrol task R_j will be shifted backward, with a shift duration ΔT = T_resp(v) + T_execute(E_i) + T_margin; where T_execute(E_i) is the estimated execution time of the emergency high-value mobile patrol task, calculated from the area of ​​the patrol area and the sampling density; T_margin is the buffer duration, taken as 10 minutes; the new time window after the postponement is [T_end(E_i) + T_margin, T_end(E_i) + T_margin + T_rem(R_j)], where T_rem(R_j) is the remaining estimated execution time of R_j.

10. The unmanned vehicle multi-task scheduling and range optimization system according to claim 1, characterized in that: The structure and content of the mobile mission package are generated differently according to the mission type, including: If it is an emergency high-value dispatching task, the mobile task package includes: nav_path: The navigation path from the vehicle's current location to the target area and covering all specified grids, generated by the map path planning API; grid_sequence: The sequence of hexagonal grid coverage within a radius scan_radius_i centered on the target point, sorted by spatial proximity to reduce backtracking. sample_freq: Second-level sampling frequency configuration. The sampling frequency for emergency high-value mobile monitoring missions is higher than that for routine patrols. target_pollutants: Marks pollutants that require special attention based on the type of pollutant that triggered the event; est_duration: Estimated execution time, calculated by dividing the fixed total mileage of the route by the average vehicle speed; status_rules: Rules for task status transition. If it is a routine patrol and navigation mission, including adjustments after extension or takeover, the navigation mission package includes: nav_path: The updated mesh coverage navigation path; grid_sequence: The adjusted hexagonal grid cover sequence; sample_freq: Standard sampling frequency for daily inspections; target_pollutants: The pre-defined list of pollutants to be monitored along this patrol route; est_duration: The updated estimated execution time; status_rules: Rules for task status transition.

Images