An airport-oriented cloud-edge collaborative scheduling system

Abstract

The application provides an airport-oriented cloud-edge collaborative scheduling system, and relates to the technical field of vehicle scheduling. The system comprises: a cloud shared operation platform, which is used to acquire airport operation data and an airport dynamic constraint map, and service request object data; a demand prediction module, which is used to predict demand prediction data of multiple future time windows according to the airport operation data and the airport dynamic constraint map; a priority evaluation module, which is used to determine the service priority order of the service request object data; a multi-target vehicle dispatching module, which is used to perform scheduling optimization to obtain a vehicle scheduling strategy; a vehicle end, which is used to control the operation of each vehicle according to the vehicle scheduling strategy, and feed back the operation state data of each vehicle to the cloud shared operation platform in real time; and an edge security supervision module, which is locally deployed in an airport area and is used to control the vehicle to complete a vehicle order in the vehicle scheduling strategy when the cloud shared operation platform fails. The application can realize the vehicle scheduling of the airport and guarantee the stable and continuous service.

Description

Technical Field

[0001] This invention relates to the field of vehicle dispatching technology, and more specifically, to a cloud-edge collaborative dispatching system for airports. Background Technology

[0002] During peak hours (morning and evening), holidays, periods of concentrated international flight arrivals, peak transit passenger transfers, the end of remote gate shuttle services, or temporary gate adjustments, demand for airport passenger mobility services at certain stations may surge within a short period. At other times or at other stations, vehicles may remain idle. Currently, the manual wheelchair service at airports relies on staff dispatch, and response time is affected by staff location and workload. Autonomous shared mobility vehicles primarily operate on fixed routes and cannot be freely dispatched.

[0003] In related technologies, existing vehicle dispatching technologies are mostly geared towards short-distance shuttle scenarios in urban roads or industrial parks, and are relatively simple, usually simplifying order allocation to the problem of matching the location between vehicles and users. However, airport scenarios are subject to multiple rigid constraints, including strong time constraints due to the risk of missing flights, boarding deadlines, and transfer requirements; spatial permission constraints defined by the boundaries of security checks, customs, international / domestic isolation areas, and employee access channels; and operational constraints such as station capacity, elevator windows, temporary barriers, congestion in commercial areas, cleaning operations, and security management. In addition, the dispatching objectives must also take into account accessibility and fairness, and cannot be solely guided by commercial benefits or the shortest waiting time. These complex factors together make it difficult for existing vehicle dispatching technologies to be directly applied to airport passenger transportation services. Summary of the Invention

[0004] The problem this invention addresses is how to implement vehicle scheduling at airports.

[0005] To address the above problems, this invention provides a cloud-edge collaborative scheduling system for airports, comprising: The cloud-based shared operation platform is used to acquire airport operation data and airport dynamic constraint maps, and encapsulate the multi-source service requests in the airport operation data into service request object data respectively; The demand forecasting module is used to predict demand forecast data for multiple future time windows based on the airport operation data and the airport dynamic constraint map. The priority evaluation module is used to determine the service priority ranking of the service request object data based on passenger condition data in the airport operation data and fairness constraints. The multi-target vehicle dispatch module is used to perform dispatch optimization based on the service request object data, the demand prediction data, the service priority ranking, and the vehicle status in the airport operation data to obtain a vehicle dispatch strategy. On the vehicle side, it is used to control the operation of each vehicle according to the vehicle scheduling strategy and to feed back the operating status data of each vehicle to the cloud-based shared operation platform in real time. The edge security monitoring module is deployed locally in the airport area to receive the airport operation data, the vehicle dispatching strategy, and the operation status data. When the cloud-based shared operation platform fails, it controls the vehicles to complete the vehicle orders in the vehicle dispatching strategy.

[0006] Optionally, the cloud-based shared operation platform includes: The airport data access layer is used to acquire initial airport operation data and the airport dynamic constraint map, and to perform time synchronization, desensitization and anomaly filtering on the initial airport operation data to obtain the airport operation data. The airport data access layer is also used to acquire MAC address connection count and signal strength, site monitoring radar data, and vehicle speed data; estimate regional passenger flow based on the MAC address connection count and signal strength, count the current number of people queuing and the inspection rate based on the site monitoring radar data, and calculate the traffic flow speed of local road sections based on the vehicle speed data distribution; align the regional passenger flow, the current number of people queuing and the inspection rate, and the traffic flow speed of local road sections with timestamps, and filter out noise using a weighted fusion algorithm to generate real-time personnel density and flow rate characteristics for different channels and waiting areas; input the real-time personnel density and flow rate characteristics into a pre-trained passenger flow status assessment model to generate passenger flow density heatmap values ​​in the airport operation data; extract high-density areas from the passenger flow density heatmap values ​​and map the high-density areas onto the airport dynamic constraint map; The service request layer is used to encapsulate the multi-source service requests into service request object data.

[0007] Optionally, the demand forecasting module includes: The prediction unit is used to construct a model input feature vector based on historical order sequences, real-time flight plans, weather influencing factors, and station congestion index in the airport operation data; based on the model input feature vector and the airport dynamic constraint map, it uses a neural network prediction model based on a spatiotemporal attention mechanism to predict passenger arrivals in multiple future time windows; based on the passenger arrivals, idle vehicle data, and empty vehicle data en route, it determines the supply-demand gap, and generates the demand prediction data based on the supply-demand gap; The pre-scheduling unit is used to pre-call idle vehicles to the standby area adjacent to the demand area in the demand forecast data based on the demand forecast data.

[0008] Optionally, the multi-target vehicle dispatch module includes: The vehicle dispatching unit is used to filter candidate dispatching vehicles based on the service request object data and the vehicle status, and to perform vehicle dispatching optimization based on the objective function and the candidate dispatching vehicles to obtain the vehicle dispatching decision of the vehicle dispatching strategy. The route optimization unit is used to optimize the route based on the vehicle dispatch decision, the service request object data, the demand prediction data, and the service priority ranking, so as to obtain the vehicle running route in the vehicle scheduling strategy.

[0009] Optionally, the cloud-based shared operation platform is also used for: Obtain the vehicle health status of vehicles without assigned tasks whose vehicle orders have been completed; When the vehicle health status is normal, the long-term overall revenue of the unattended vehicle is determined by the revenue calculation method, and the task instruction of the unattended vehicle is generated based on the long-term overall revenue. When the vehicle's health status is abnormal, a vehicle return command is generated.

[0010] Optionally, the airport-oriented cloud-edge collaborative scheduling system further includes: The operation evaluation closed-loop module is used to acquire actual operation indicators at preset cycles, determine the deviation between the actual operation indicators and the target expected indicators, and adjust system parameters according to the deviation.

[0011] Optionally, the airport-oriented cloud-edge collaborative scheduling system further includes: The remote takeover module provides a remote control and emergency command interface for manual intervention when the vehicle is not operating normally.

[0012] Optionally, the airport-oriented cloud-edge collaborative scheduling system further includes: The maintenance work order module is used to integrate the vehicle's hardware health indicators, emergency stop alarm records, and mileage data, and generate maintenance work orders with different priorities.

[0013] Optionally, the airport-oriented cloud-edge collaborative scheduling system further includes: The closed-loop operation and maintenance module is used to generate operation and maintenance work orders based on the vehicle's fault codes, emergency stop frequency, sensor obstruction, wheel set temperature, battery health, passenger complaints and mileage, and adjust the subsequent dispatch strategy for the vehicle based on the operation and maintenance work orders.

[0014] Optionally, the cloud-based shared operation platform further includes: The vehicle status layer is used to record the current vehicle status and receive the operating status data; The airport constraint layer models the airport topology as a graph structure with permission, time window, and capacity constraints, and dynamically sets the graph nodes and edges of the graph structure to obtain the dynamic constraint map of the airport.

[0015] The beneficial effects of the cloud-edge collaborative scheduling system for airports of the present invention are: By acquiring airport operation data and dynamic constraint maps through a cloud-based shared operation platform, and encapsulating multi-source service requests into a unified object, this approach overcomes the limitations of existing technologies that rely on single data sources and fail to match requests within the context of multi-dimensional airport constraints. It achieves the integration of multi-source airport data and constraints, and standardizes requests, laying a unified foundation for scheduling under complex constraints. Furthermore, by leveraging a demand forecasting module that combines airport operation data and dynamic constraint maps to predict future demand across multiple time windows, it adapts to strong time constraints such as missed flights and boarding deadlines, overcoming the shortcomings of existing technologies that lack demand prediction and are prone to supply-demand imbalances. Finally, by employing a priority evaluation module that determines service priority based on passenger conditions and fairness constraints, it avoids the shortcomings of existing technologies that are solely driven by commercial benefits or minimum waiting time, and instead considers... Fairness between accessible services and services for general passengers; Through a multi-target dispatch module that integrates service requests, demand forecasting, priority ranking, and vehicle status for optimal dispatching, it overcomes the limitations of simple location matching in existing technologies, adapts to multiple operational constraints such as airport station capacity and temporary barriers, and improves dispatching accuracy; Vehicle operation is controlled by the vehicle terminal according to the dispatching strategy, and the operating status is fed back in real time, allowing dispatching to dynamically adapt to the ever-changing constraints of the airport, avoiding the dispatching rigidity caused by the lag in vehicle status feedback in existing technologies; Relying on a locally deployed edge security monitoring module to receive data, policies, and status, it controls vehicles to complete orders when cloud services fail, solving the problem of existing technologies relying on the cloud and lacking local backup, which easily leads to service interruptions, and ensuring the stable and continuous operation of airport transportation services. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the structure of a cloud-edge collaborative scheduling system for airports provided in an embodiment of the present invention. Detailed Implementation

[0017] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Although some embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present invention. It should be understood that the accompanying drawings and embodiments of the present invention are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.

[0018] It should be understood that the various steps described in the method embodiments of the present invention may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0019] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to"; the term "based on" means "at least partially based on"; the term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments"; and the term "optionally" means "optional embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first," "second," etc., mentioned in this invention are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0020] It should be noted that the terms "a" and "a plurality of" used in this invention are illustrative rather than restrictive. Those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0021] The names of the messages or information exchanged between the multiple devices in the embodiments of the present invention are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0022] like Figure 1 As shown in the figure, an embodiment of the present invention provides a cloud-edge collaborative scheduling system for airports, comprising: The cloud-based shared operation platform is used to acquire airport operation data and airport dynamic constraint maps, and encapsulates the multi-source service requests in the airport operation data into service request object data.

[0023] Specifically, the cloud-based shared operation platform, as the core of the system's overall control, continuously accesses full-scenario operational data of the airport during actual deployment. This data covers various types of information, including flight dynamics, boarding gate change information, security checkpoint congestion, station queue lengths, various passenger reservation information (such as multi-source service requests), real-time vehicle location, remaining battery power, health status, terminal temporary enclosure status, elevator operation status, and vehicle cleaning and maintenance status. At the same time, the platform synchronously acquires the completed airport dynamic constraint map, which is a dynamic topology map adapted to the complex space and operational rules of the airport. For multi-source service requests from various channels, including passenger requests for transportation via mobile app, service requests registered manually at airport service counters, passenger transportation reservations pushed by airline systems, terminal touchscreen call requests, voice call service requests, airport staff requesting services on behalf of passengers, and service requests initiated by vehicle-based reuse, the cloud-based shared operation platform will uniformly encapsulate each type of request into standardized service request object data. This object data clearly includes key information such as passenger type, departure station, destination, latest arrival time, number of passengers, number of luggage, whether assistance is needed, whether group booking is possible, language preference, and privacy authorization status, ensuring that all types of requests can be uniformly identified and processed by the system. This embodiment can achieve unified aggregation of multi-source heterogeneous data at the airport and standardized processing of service requests, breaking down data barriers between different service channels, providing a unified and standardized data foundation for subsequent demand forecasting, priority evaluation, and vehicle dispatching, and ensuring the consistency and efficiency of the overall system dispatching.

[0024] The demand forecasting module is used to predict demand forecast data for multiple future time windows based on the airport operation data and the airport dynamic constraint map.

[0025] Specifically, during actual operation, the demand forecasting module uses airport operation data and airport dynamic constraint maps output by the cloud-based shared operation platform as core inputs to conduct multi-dimensional demand forecasting. The module first extracts key information from the airport operation data, including historical order sequences, flight schedules, real-time flight status, weather conditions, holiday types, security check queue times, boarding announcements, and real-time queue conditions at each station. This information is then combined with the spatial topology, traffic efficiency, and regional constraint information marked on the airport dynamic constraint map to construct a spatiotemporal feature sequence. Subsequently, relying on a spatiotemporal network model adapted to the airport scenario, the module accurately predicts the transportation demand at each airport station within multiple future time windows (e.g., 15 minutes, 30 minutes). Simultaneously, it calculates the supply-demand gap at each station by combining the current number of idle vehicles and the number of empty vehicles en route, generating forecast data related to empty vehicle return demand. This complete output of demand forecast data for multiple future time windows provides a basis for advance vehicle scheduling. This embodiment enables proactive prediction of airport transportation demand, accurately captures demand fluctuations during peak hours and flight schedules, identifies supply and demand imbalances at stations in advance, provides data support for the pre-allocation of vehicle resources, effectively reduces passenger waiting time, and avoids idle or scarce vehicle resources.

[0026] The priority evaluation module is used to determine the service priority ranking of the service request object data based on passenger condition data in the airport operation data and fairness constraints.

[0027] Specifically, in actual operation, the priority evaluation module relies on passenger condition data provided by the cloud-based shared operation platform, combined with preset fair constraint rules, to prioritize service request data. This passenger condition data includes multi-dimensional information such as whether the passenger is disabled, the risk level of missing the flight corresponding to the remaining flight time, the passenger's waiting time, the number of accompanying passengers, age-related auxiliary tags, and travel route distance. During module operation, the module first analyzes the passenger condition data for each service request item by item. For passengers with disabilities, passengers with a high risk of missing their flight due to approaching boarding deadlines, passengers traveling to distant boarding gates, and passengers whose waiting time exceeds a preset threshold, the module automatically increases the priority of their corresponding service requests. Service requests initiated by ordinary passengers who can walk independently, have no time pressure, and have short travel routes are included in the regular priority queue for sorting. Meanwhile, the module adheres to the principle of fairness throughout the process, not simply prioritizing requests based on passenger urgency. It strictly controls the maximum waiting time and service coverage for different passenger groups, preventing high-priority requests from occupying vehicle resources for extended periods while low-priority requests from ordinary passengers remain unresponsive. This also prevents shared mobility vehicles from being completely monopolized by short-distance, high-frequency orders. The module uses multi-dimensional conditions and a balance of fairness constraints to generate an orderly and reasonable service priority ranking, ensuring that urgent needs are responded to first while maintaining fairness for ordinary passengers. This embodiment enables the scientific and fair determination of service request priorities, ensuring timely service for special groups such as passengers with mobility impairments and time-sensitive passengers, while avoiding excessive allocation of service resources, protecting the basic service rights of ordinary passengers, and improving the overall service experience and social equity.

[0028] More specifically, the priority formula for the priority evaluation module includes: ; in, For the request r priority, It is an accessibility level. To avoid the risk of missing the flight or exceeding the time limit, As the waiting time factor, For path distance or physical burden, To serve the fairness factor, For the request r The corresponding site balance associated cost factor, , , , , , These represent the weights corresponding to each factor. The site balance formula includes: ; in, For site balance, This represents the current actual number of vehicles at station s. Let be the target number of vehicles required for station s at time t. For example, station equilibrium is also used for penalties and future demand forecasting, causing some vehicles to proactively return to areas with high future demand or low supply after service completion.

[0029] The multi-target vehicle dispatch module is used to perform scheduling optimization based on the service request object data, the demand prediction data, the service priority ranking, and the vehicle status in the airport operation data to obtain a vehicle dispatch strategy.

[0030] Specifically, during the actual dispatching process, the multi-objective vehicle dispatch module takes as input the service request object data output by the cloud-based shared operation platform, the demand forecast data generated by the demand forecasting module, the service priority ranking determined by the priority evaluation module, and the real-time vehicle status data synchronized in the cloud. It then performs multi-objective dispatch optimization to ultimately output the optimal vehicle dispatching strategy. When the module runs, it first combines the service priority ranking results to prioritize and filter high-priority service requests. Simultaneously, based on vehicle status data, it excludes invalid vehicles with insufficient battery power, abnormal health status, incomplete cleaning, mismatched service areas, or inability to safely reach the passenger departure station, thus locking in a set of available candidate vehicles. Subsequently, the module comprehensively considers factors such as future station demand predicted by the demand forecast data, vehicle empty-running costs, energy consumption, station supply-demand balance, and service fairness to perform global dispatch optimization. This avoids multiple vehicles simultaneously flooding narrow corridors or congested stations, achieving a dual balance between vehicle dispatching and airport passenger flow. Finally, it generates a vehicle dispatching strategy encompassing vehicle allocation, route planning, and service sequence arrangement, which is then sent to the vehicle for execution. This embodiment can achieve the global optimal allocation of vehicle resources, taking into account service efficiency, energy consumption cost, site balance and service fairness, effectively reducing vehicle empty driving distance and energy consumption, reducing the risk of site congestion, while ensuring reasonable response to requests of different priorities, and improving overall scheduling efficiency and operational benefits.

[0031] For example, the multi-target vehicle dispatch module can be implemented using integer programming, heuristic search, auction algorithms, rolling temporal optimization, or reinforcement learning strategies. Due to the high real-time requirements of airports, this embodiment preferably employs a method of "candidate vehicle screening, local optimization, and rolling recalculation."

[0032] The vehicle-side system is used to control the operation of each vehicle according to the vehicle scheduling strategy and to provide real-time feedback of the operating status data of each vehicle to the cloud-based shared operation platform.

[0033] Specifically, the vehicle-mounted terminal, as the direct control unit for vehicle operation, strictly receives and executes the vehicle dispatching strategies issued by the cloud-based shared operation platform during actual operation. It precisely controls each autonomous shared mobility vehicle to complete various operational actions such as providing transportation services, waiting at stations, returning to stations for recharging, cleaning and disinfection, or offline maintenance. Simultaneously, it collects and feeds back vehicle operational status data to the cloud-based shared operation platform in real time. During the execution of dispatching strategies, the vehicle-mounted terminal relies on its own perception and navigation systems to autonomously complete operations such as path planning, obstacle avoidance, and precise parking, adapting to the complex traffic environment of airport terminals, including narrow corridors, elevator linkages, and temporary enclosure areas. When encountering abnormal situations such as extreme congestion, severe sensor obstruction, or sudden obstacles, the vehicle-mounted terminal automatically triggers an anomaly degradation mechanism, prioritizing safe vehicle parking and sending an anomaly alarm to the cloud, requesting remote assistance. Throughout vehicle operation, the vehicle-mounted terminal collects and uploads real-time operational status data such as vehicle location, speed, remaining battery power, passenger status, emergency stop events, estimated arrival time, sensor operating status, wheel temperature, battery health, and passenger feedback, ensuring that the cloud has real-time control over vehicle dynamics. After completing their service tasks, the vehicle autonomously navigates back to its original station, proceeds to a future high-demand station to await further instructions, or heads to a refueling point, cleaning area, or maintenance point to perform subsequent actions, following the dispatch strategy. If cloud-based instructions experience delays due to network fluctuations, the vehicle can perform short-term local autonomous navigation to ensure service continuity. This embodiment enables precise autonomous vehicle operation and real-time status feedback, adapts to complex airport operation scenarios, possesses anomaly degradation safety assurance capabilities, provides real-time data support for global cloud-based dispatch, and simultaneously ensures the security, continuity, and stability of the service process.

[0034] The edge security monitoring module is deployed locally in the airport area to receive the airport operation data, the vehicle dispatching strategy, and the operation status data. When the cloud-based shared operation platform fails, it controls the vehicles to complete the vehicle orders in the vehicle dispatching strategy.

[0035] Specifically, the edge security monitoring module is deployed locally, distributed across key areas such as airport terminals and service stations. As a local security backup unit for the cloud-based shared operation platform, it receives real-time airport operation data, vehicle dispatch strategies, and vehicle operation status data from the vehicle terminals, while also handling emergency dispatch in case of cloud platform failure. During operation, the module maintains continuous communication with the cloud, synchronizing airport operation data, vehicle dispatch instructions, and vehicle operation status in real time. It also accesses local sensor data to monitor queuing conditions, vehicle distribution, and the surrounding environment's safety status within its jurisdiction, providing real-time safety monitoring of vehicle operations. When the cloud-based shared operation platform fails due to network interruption or system malfunction, the edge security monitoring module immediately triggers a self-regulating mechanism, automatically taking over control of all vehicles within its jurisdiction. Relying on locally cached airport dynamic constraint maps, station capacity rules, and preset dispatch rules, it maintains vehicle dispatch, station queuing order management, and abnormal parking handling within the local area. Priority is given to ensuring that queued passengers receive basic transportation services, while strictly restricting vehicles from leaving the local safety service area to prevent disorderly vehicle movement and potential safety hazards. When taking over vehicle operation or handling abnormal events, the edge security monitoring module displays anonymized images of the vehicle's surrounding environment, real-time vehicle location, passenger status, abnormal event type, and system-recommended actions to back-end operations personnel, providing clear and secure information support for manual intervention. Once the cloud service is restored, the edge security monitoring module uploads complete data from the outage period, including order execution records, vehicle trajectories, and abnormal event logs, to the cloud. The cloud then performs global status merging, ensuring the consistency of scheduling data. This embodiment enables real-time security monitoring of localized airport areas and provides emergency backup in case of cloud failure, ensuring uninterrupted transportation services and safe and controllable vehicle operation during network fluctuations or cloud outages, thus improving the robustness and operational security of the entire cloud-edge collaborative scheduling system.

[0036] In this embodiment, airport operation data and dynamic constraint maps are obtained through a cloud-based shared operation platform, and multi-source service requests are encapsulated into a unified object. This breaks through the limitations of existing technologies, which rely on single data and matching methods detached from the multi-dimensional constraints of airports. It achieves the integration of multi-source airport data and constraints and the standardization of requests, laying a unified foundation for scheduling under complex constraints. The demand forecasting module, combined with airport operation data and dynamic constraint maps, predicts future demand across multiple time windows, adapting to strong time constraints such as missed flights and boarding deadlines. This overcomes the shortcomings of existing technologies, which lack demand prediction and are prone to supply-demand imbalances in time and space. Finally, the priority evaluation module determines service priority ranking based on passenger conditions and fairness constraints, overcoming the drawbacks of existing technologies that are solely driven by commercial benefits or the shortest waiting time. It balances the fairness of services for both accessible and general passengers; by using a multi-target dispatch module to integrate service requests, demand forecasting, priority ranking, and vehicle status for optimal dispatching, it overcomes the limitations of simple location matching in existing technologies, adapts to multiple operational constraints such as airport station capacity and temporary barriers, and improves dispatching accuracy; the vehicle terminal controls vehicle operation according to the dispatching strategy and provides real-time feedback on the operating status, allowing dispatching to dynamically adapt to the ever-changing constraints of the airport, avoiding the dispatching rigidity caused by the lag in vehicle status feedback in existing technologies; relying on a locally deployed edge security monitoring module to receive data, strategies, and status, it controls vehicles to complete orders when cloud services fail, solving the problem of existing technologies relying on the cloud and lacking local backup, which easily leads to service interruptions, and ensuring the stable and continuous operation of airport transportation services.

[0037] Optionally, the cloud-based shared operation platform includes: The airport data access layer is used to acquire initial airport operation data and the airport dynamic constraint map, and to perform time synchronization, desensitization and anomaly filtering on the initial airport operation data to obtain the airport operation data. The airport data access layer is also used to acquire MAC address connection count and signal strength, site monitoring radar data, and vehicle speed data; estimate regional passenger flow based on the MAC address connection count and signal strength, count the current number of people queuing and the inspection rate based on the site monitoring radar data, and calculate the traffic flow speed of local road sections based on the vehicle speed data distribution; align the regional passenger flow, the current number of people queuing and the inspection rate, and the traffic flow speed of local road sections with timestamps, and filter out noise using a weighted fusion algorithm to generate real-time personnel density and flow rate characteristics for different channels and waiting areas; input the real-time personnel density and flow rate characteristics into a pre-trained passenger flow status assessment model to generate passenger flow density heatmap values ​​in the airport operation data; extract high-density areas from the passenger flow density heatmap values ​​and map the high-density areas onto the airport dynamic constraint map; The service request layer is used to encapsulate the multi-source service requests into service request object data.

[0038] Specifically, the cloud-based shared operation platform serves as the core brain of the airport's autonomous driving shared mobility vehicle dispatch system. The airport data access layer is a crucial component of its data entry point, undertaking the entire process of acquiring, preprocessing, and generating passenger flow data for initial airport operational data and airport dynamic constraint maps. The service request layer is responsible for the standardized encapsulation of multi-source service requests. Together, they provide a standardized and complete data foundation for subsequent dispatching. In actual deployment and operation, the airport data access layer first comprehensively acquires initial airport operational data through multiple data collection interfaces, covering multi-source heterogeneous information such as flight dynamics, gate changes, security checkpoint congestion, station queues, passenger reservations, vehicle locations, battery levels, health status, temporary barriers, elevator status, cleaning and maintenance status, and human service resources. Simultaneously, it acquires the basic data for the airport dynamic constraint map. Subsequently, the access layer performs standardized preprocessing on the initial airport operational data, strictly implementing time synchronization, anonymization, and anomaly filtering. It eliminates data time-series deviations through unified timestamps, anonymizes sensitive information such as passenger identity and images to ensure privacy, and filters out invalid information such as missing data and abnormal values, ultimately outputting standardized and reliable airport operational data. To accurately grasp the distribution of passenger flow at the airport, the airport data access layer deploys multiple types of sensing data collection modules. Through Wi-Fi probe devices deployed within the airport area, it continuously collects the number of connected devices' MAC addresses and signal strength to estimate the passenger flow scale in different areas. It also accesses monitoring visual algorithms or linear radar data from stations and security checkpoints to statistically analyze the current queue size and clearance rate in real time. Simultaneously, it receives vehicle speed distribution data reported by vehicles to calculate the vehicle flow speed on local road sections. After data collection, the access layer timestamps the regional passenger flow, current queue size and clearance rate, and local road flow speed. Then, a weighted fusion algorithm filters out data noise caused by environmental interference, generating real-time personnel density and flow rate characteristics for different channels and waiting areas. These characteristics are then input into a pre-trained passenger flow status assessment model (such as one built based on a graph neural network, GNN), outputting a fully gridded passenger flow density heatmap. This accurately marks high-density passenger flow areas at the airport and synchronously maps these areas to the airport's dynamic constraint map, updating dynamic constraint information such as high-cost slow-moving edges to ensure the constraint map matches passenger congestion in real time. The service request layer connects to the airport's omnichannel service initiation portals, including service requests initiated by passenger mobile apps, airport service counters, airline systems, terminal site touch screens, voice call terminals, airport staff calling on behalf of others, and vehicle-based reuse. It unifies these diverse and formatted multi-source service requests into standardized service request object data.The service request data includes core fields such as passenger type, departure station, destination, latest service start time, latest arrival time, number of passengers, number of luggage, whether assistance is needed, whether group booking is possible, language preference, and privacy authorization status. This ensures that all service requests have a unified data structure, allowing them to be directly identified and processed by the system's subsequent priority evaluation and dispatching modules, completely resolving the problems of fragmented data from different channels and the inability to uniformly schedule data. This embodiment achieves effective integration of multi-source airport data through full-dimensional data collection, preprocessing, and passenger flow heat map generation at the airport data access layer, combined with standardized encapsulation at the service request layer. This provides accurate and standardized data support for cloud-edge collaborative dispatching, ensuring the accuracy of subsequent demand prediction and dispatching decisions, while also protecting passenger privacy and security, and adapting to the dispatching needs of complex airport operation scenarios.

[0039] More specifically, the formula for determining the latest service start time includes: ; in, The latest service start time. This refers to the time when flights close or gates close. To estimate vehicle travel time, This provides a buffer time for boarding, alighting, and security checks.

[0040] Optionally, the demand forecasting module includes: The prediction unit is used to construct a model input feature vector based on historical order sequences, real-time flight plans, weather influencing factors, and station congestion index in the airport operation data; based on the model input feature vector and the airport dynamic constraint map, it uses a neural network prediction model based on a spatiotemporal attention mechanism to predict passenger arrivals in multiple future time windows; based on the passenger arrivals, idle vehicle data, and empty vehicle data en route, it determines the supply-demand gap, and generates the demand prediction data based on the supply-demand gap; The pre-scheduling unit is used to pre-call idle vehicles to the standby area adjacent to the demand area in the demand forecast data based on the demand forecast data.

[0041] Specifically, the demand forecasting module is the core unit of the cloud-based shared operation platform for proactive scheduling. The forecasting unit is responsible for accurately predicting the demand for transportation services at each station based on multi-dimensional data, while the pre-scheduling unit executes pre-allocation of vehicles based on the forecast results. Together, they achieve demand prediction and advance allocation of vehicle resources, solving the problem of spatial and temporal imbalance between supply and demand for airport transportation services. In actual operation, the forecasting unit first obtains standardized airport operation data and a dynamic constraint map from the cloud-based shared operation platform. From the airport operation data, it extracts key spatiotemporal features such as historical order sequences, real-time flight plans, weather influencing factors, security check congestion indices, and station congestion indices. Historical order sequences include transportation service order records for different time periods and stations; real-time flight plans cover flight takeoffs and landings, bridge docking, and gate allocation information; weather influencing factors include meteorological data affecting passenger travel efficiency such as rain, snow, and strong winds; and security check and station congestion indices reflect the real-time level of traffic congestion. Subsequently, the forecasting unit fuses the extracted features to construct a complete model input feature vector. This vector comprehensively covers historical patterns, real-time dynamics, and environmental impacts, providing sufficient basis for forecasting. Next, the prediction unit, relying on a neural network prediction model based on a spatiotemporal attention mechanism (such as a spatiotemporal attention graph convolutional neural network ST-GCN or a long short-term memory network LSTM), combined with the spatial topology of the airport's dynamic constraint map, accurately predicts the passenger arrival volume of each station at the airport within multiple future time windows (such as 15 minutes, 30 minutes, and 1 hour). This fully considers the impact of airport spatial permissions and access constraints on passenger flow, improving the spatial adaptability of the prediction results. After obtaining the passenger arrival volume prediction results, the prediction unit further combines the data on idle vehicles and empty vehicles en route from the airport operation data to accurately calculate the supply-demand gap for each station, i.e., the difference between the predicted demand for a station and the current number of available vehicles. For stations with significant supply-demand gaps and strong future demand, it automatically generates empty vehicle return transfer requests, forming complete demand prediction data. This data includes core information such as the demand quantity, supply-demand gap, and return transfer requests for each station. After receiving the demand prediction data output by the prediction unit, the pre-schedule unit initiates the vehicle pre-allocation process, prioritizing available idle vehicles that are currently idle, have sufficient power, are in good health, have been cleaned, and whose service areas match. For high-demand areas marked in demand forecast data, the pre-scheduling unit plans the optimal allocation route, avoiding congested sections, temporary barricades, and high-risk areas. Idle vehicles are pre-allocated to standby areas adjacent to high-demand areas, rather than waiting for orders to be generated before dispatching vehicles. For example, if a peak in transit passenger transportation is predicted for the remote gate area in 30 minutes, the pre-scheduling unit pre-allocates idle vehicles from the main terminal station to a backup standby area near the remote gate. This allows for rapid response when demand surges, significantly reducing passenger waiting time. Simultaneously, the allocation process follows the principles of optimal energy consumption and shortest empty driving distance, avoiding ineffective energy consumption and balancing scheduling efficiency with operating costs.This embodiment achieves forward-looking prediction of airport transportation demand and pre-allocation of resources through multi-dimensional accurate demand prediction by the prediction unit and pre-dispatch vehicle allocation by the pre-scheduling unit. It effectively solves the problems of concentrated demand during peak hours and imbalance between vehicle supply and demand, improves vehicle utilization and service response speed, and adapts to the dynamic operation scenario of airport flight waves and passenger flow fluctuations.

[0042] Optionally, the multi-target vehicle dispatch module includes: The vehicle dispatching unit is used to filter candidate dispatching vehicles based on the service request object data and the vehicle status, and to perform vehicle dispatching optimization based on the objective function and the candidate dispatching vehicles to obtain the vehicle dispatching decision of the vehicle dispatching strategy. The route optimization unit is used to optimize the route based on the vehicle dispatch decision, the service request object data, the demand prediction data, and the service priority ranking, so as to obtain the vehicle running route in the vehicle scheduling strategy.

[0043] Specifically, the multi-objective vehicle dispatch module is the core module of the cloud-based shared operation platform for achieving optimal vehicle dispatch decisions. The vehicle screening and dispatch unit is responsible for candidate vehicle screening and dispatch decision generation, while the route optimization unit is responsible for global route optimization. Together, they consider service efficiency, energy costs, station balance, and service fairness to achieve optimal multi-objective dispatch. In the actual dispatch process, the vehicle screening and dispatch unit first receives service request object data, service priority ranking results, and vehicle status data from the cloud-based shared operation platform, and then initiates the candidate dispatch vehicle screening process. The screening process strictly follows airport operation constraints, first excluding invalid vehicles with battery levels below a preset threshold, abnormal health status, incomplete cleaning and disinfection, mismatched service areas, or inability to safely reach passenger departure stations. Only candidate dispatch vehicles with sufficient battery power, normal health, adequate cleaning, matching service areas, and safe passage are retained, preventing low-quality, high-risk vehicles from participating in the service from the source and ensuring service reliability. After candidate vehicle screening, the vehicle dispatching unit optimizes vehicle dispatch based on a pre-defined multi-objective optimization function. This function focuses on minimizing the weighted sum of total waiting time, empty vehicle distance, energy consumption, station imbalance, service unfairness, and flight miss risk, comprehensively balancing service efficiency, operating costs, station supply and demand balance, and service fairness. The dispatching unit solves for the optimal matching relationship between the candidate vehicle set and the service request set, prioritizing high-priority requests (such as passengers with mobility impairments or time-sensitive passengers) while avoiding prolonged unresponsiveness for low-priority requests. This ultimately generates the optimal dispatch decision, clearly defining the assigned vehicle for each service request and forming the core dispatch instruction of the vehicle scheduling strategy. The route optimization unit receives the dispatch decision, service request object data, demand forecast data, and service priority ranking from the dispatching unit and performs global route optimization. Combining the current vehicle trajectory, real-time capacity of each station, future demand forecasts, and the airport's dynamic constraint map, while also considering the efficiency of passenger vehicles and the cost of empty vehicle relocation, the route optimization unit globally optimizes the service routes of passenger vehicles and the relocation routes of empty vehicles. During the optimization process, the route optimization unit focuses on avoiding narrow corridors, congested commercial areas, temporary fenced-off areas, and high-risk road sections. This prevents multiple autonomous vehicles from simultaneously entering the same congested area or narrow passage, thus avoiding vehicle clustering and congestion that could affect traffic efficiency, and reducing the occurrence of abnormal situations such as sudden stops and detours. Furthermore, for routes that cross floors or require elevator access, the route optimization unit simultaneously plans routes based on real-time elevator status and travel time windows to ensure smooth passage between floors. For high-priority requests, the shortest route is planned first to reduce the risk of missed flights. For ordinary requests, both route smoothness and energy consumption costs are considered to achieve a balance between efficiency and cost. The route optimization unit ultimately outputs the optimal vehicle operating route, integrates dispatch decisions to form a complete vehicle scheduling strategy, and distributes it to the vehicle-side and edge safety monitoring modules for execution.This embodiment achieves optimal allocation of vehicle resources by combining precise vehicle screening and multi-objective vehicle dispatching decisions with global route optimization by the route optimization unit. This effectively reduces passenger waiting time, vehicle empty driving distance, and energy consumption, avoids station congestion and supply-demand imbalance, and balances service efficiency, operating costs, and service fairness, adapting to the complex traffic environment and diverse service needs of airports.

[0044] More specifically, the objective function formula includes: ; in, As a variable for dispatching vehicles, , , are the weight coefficients corresponding to the costs of each item in the multi-objective optimization function. For passenger waiting time, This refers to the vehicle's empty driving distance or time. For the cost of vehicle energy consumption, For the cost of vehicle health or maintenance, To address the issue of unfairness, The cost of missing the flight.

[0045] More specifically, the formula for selecting dispatch units based on airport operational constraints includes: ; in, As a variable for dispatching vehicles, For vehicle battery level, For vehicle health, The minimum battery level threshold for vehicles allowed to dispatch orders. To set a minimum health threshold for vehicles to be allowed to dispatch orders, The spatial area where vehicle k is currently located or can serve. The set of permission zones that request r is allowed or required.

[0046] Optionally, the cloud-based shared operation platform is also used for: Obtain the vehicle health status of vehicles without assigned tasks whose vehicle orders have been completed; When the vehicle health status is normal, the long-term overall revenue of the unattended vehicle is determined by the revenue calculation method, and the task instruction of the unattended vehicle is generated based on the long-term overall revenue. When the vehicle's health status is abnormal, a vehicle return command is generated.

[0047] Specifically, the cloud-based shared operation platform is not only responsible for order dispatch but also for the full lifecycle scheduling and management of vehicles after service completion. By accurately assessing the health status of vehicles without assigned tasks, it generates task instructions using scientific revenue calculation methods, achieving efficient recycling of vehicle resources, avoiding vehicle idleness and waste, and ensuring vehicle health and service capabilities. In actual operation, once a vehicle completes passenger service and becomes a no-task vehicle, the cloud-based shared operation platform immediately retrieves the vehicle's real-time health status data, including remaining battery power, hardware self-check results, sensor operating status, braking system status, battery health, wheel temperature, cleaning and disinfection status, emergency stop records, passenger complaint records, and mileage, comprehensively assessing the vehicle's health status and determining whether it is in a normal or abnormal state. When the vehicle's health status is determined to be normal, the cloud-based shared operation platform initiates the revenue calculation process, employing scientific revenue calculation methods (preferably Markov Decision Process (MDP) or heuristic greedy matching algorithm) to comprehensively evaluate the long-term overall revenue of the vehicle performing different subsequent actions. The platform calculates the revenue value for each of the following optional actions for vehicles without assigned tasks: returning to the original station, proceeding to a future high-demand station, entering a refueling point, entering a cleaning and disinfection area, or waiting for manual inspection. The revenue calculation considers three core dimensions: first, the revenue from improving supply and demand, i.e., the effect of the action on improving the supply-demand balance at the target station; second, the cost of empty runs, i.e., the energy and time costs associated with the distance the vehicle needs to travel to perform the action; and third, the long-term service value, i.e., the number of future orders the vehicle can handle after completing the action and its priority matching. The platform comprehensively weighs the revenue from improving supply and demand against the losses from empty runs, selecting the action with the highest long-term overall revenue, generating corresponding task instructions, and issuing them to the vehicle for execution. For example, if a vehicle has sufficient battery power, has completed cleaning, has no abnormal records, and predicts no high demand at the original station in the next hour, while a distant boarding gate station is about to experience a peak, the platform calculates that proceeding to the distant station to wait has the highest long-term revenue, and thus generates a task instruction to proceed to the distant station to wait. When the cloud-based shared operation platform determines that the health status of a vehicle without tasks is abnormal, it immediately generates a vehicle return command, forcing the vehicle to return to a designated station, maintenance point, or cleaning area. Abnormal states encompass various situations: remaining battery power below a hard threshold, hardware self-test failure, sensor obstruction, excessive braking distance, excessive frequency of emergency stops, substandard battery health, unresolved passenger complaints, mileage reaching the maintenance cycle, and incomplete cleaning and disinfection. For example, if a vehicle repeatedly triggers emergency stop alarms or experiences frequent sensor obstruction, the platform determines it as abnormal and generates a return command to a maintenance point; if the vehicle's battery is severely low, a return command to a charging point is generated; if the vehicle has completed multiple service trips and requires cleaning and disinfection, a return command to a cleaning area is generated. Simultaneously, the platform restricts the vehicle's subsequent order assignment permissions to prevent it from continuing service and reduce safety risks; once the vehicle completes maintenance, charging, or cleaning and is re-determined to be in a normal state, the order assignment restriction is lifted, and the vehicle is reinstated into the normal dispatch queue.This embodiment uses a cloud-based shared operation platform to accurately determine the health status of vehicles without tasks, generate revenue-generating task instructions, and manage abnormal vehicles. This enables efficient recycling of vehicle resources, reduces vehicle idle time, and improves vehicle utilization. At the same time, it ensures vehicle health and service safety, avoids abnormal vehicles from being put into service, adapts to the long-term and continuous transportation service operation needs of airports, and balances operational efficiency with safety and compliance.

[0048] Optionally, the airport-oriented cloud-edge collaborative scheduling system further includes: The operation evaluation closed-loop module is used to acquire actual operation indicators at preset cycles, determine the deviation between the actual operation indicators and the target expected indicators, and adjust system parameters according to the deviation.

[0049] Specifically, the operation evaluation closed-loop module is the core module of the cloud-edge collaborative scheduling system, enabling continuous optimization and forming an operation closed loop. Through periodic evaluation of service performance, comparison with target indicators, and reverse adjustment of system parameters, the scheduling system continuously learns from actual operational data, constantly optimizing scheduling strategies and improving service quality and operational efficiency. In actual operation, the operation evaluation closed-loop module pre-sets statistical periods, which can be divided by flight wave, daily, weekly, or monthly, adapting to the airport's flight operation rhythm, and periodically collects and evaluates operational indicators. At each preset period, the operation evaluation closed-loop module comprehensively acquires actual operational indicators from all system modules, including the cloud-based shared operation platform, vehicle-side, edge security monitoring module, and maintenance work order module. These indicators cover multiple dimensions of core data, such as average waiting time, maximum waiting time for passengers with disabilities (PRM), order completion rate, number of missed flight risk interceptions, vehicle utilization rate, empty-running rate, emergency stop rate, manual takeover rate, complaint rate, energy consumption, station vehicle shortage duration, low battery dispatch rate, and maintenance timeliness rate, comprehensively reflecting service efficiency, service fairness, operational safety, vehicle utilization rate, and operating costs. After obtaining the actual operational indicators, the operation evaluation closed-loop module retrieves the preset target expected indicators. These indicators are the service quality and operational efficiency benchmarks set by the airport operator, such as average waiting time ≤ 5 minutes, maximum PRM waiting time ≤ 10 minutes, vehicle utilization rate ≥ 80%, and emergency stop rate ≤ 0.5%. The module compares each actual operational indicator with its corresponding target expected indicator, calculating the indicator deviation, i.e., the difference between the actual value and the target value, and the deviation loss. For continuous indicators (such as waiting time and energy consumption), it calculates the quantified deviation loss; for discrete indicators (such as complaint rate and emergency stop rate), it statistically analyzes the frequency and scope of deviation. After completing the deviation calculation, the operation evaluation closed-loop module adjusts system parameters across dimensions based on the deviation results to achieve closed-loop optimization. For continuous parameters (such as demand forecast weight, multi-target vehicle dispatch weight, and path cost weight), the module uses a gradient descent algorithm to construct a loss function (with indicator deviation as the core), and iteratively updates the formula: ,in, For parameter set, For the parameter set of the d-th period, For the parameter set of the (d+1)th period, For gradient operators, For sets The partial derivative calculations performed The learning rate or step size for the update iteration, and L is the deviation loss function. The meaning is "to find the gradient of the loss function L with respect to the parameter Θ (i.e., the direction of the fastest rate of change)". For the current (d-th) evaluation period, the actual operational indicators are... The module automatically updates model weights to align the scheduling strategy for the next cycle with the preset target operational indicators. For example, if the actual empty-run rate is significantly higher than the target value, the module increases the weight of empty-run cost in vehicle dispatching, reducing empty-run scheduling; if PRM waiting time exceeds the standard, the module increases the weight of accessibility level in priority evaluation, prioritizing passengers with mobility impairments. For discrete strategies (such as station configuration and risk zone settings), the module identifies areas or processes with persistent problems through spatial clustering of abnormal events: if the detour rate or emergency stop rate of a certain road segment continues to exceed the standard, it automatically generates a map risk weight increase instruction and updates the airport dynamic constraint map; if a station has a long-term shortage of vehicles or severe queuing, it generates an alarm to add a standby point or increase the number of stationed vehicles and pushes it to operations personnel. In addition, the module also optimizes anomaly handling strategies and remote takeover processes based on indicators such as complaint rate and manual takeover rate, improving service experience and emergency response capabilities. This embodiment constructs a "operation-evaluation-optimization" closed-loop mechanism through the periodic collection of indicators, deviation analysis, and iterative adjustment of system parameters in the operation evaluation closed-loop module. This enables the cloud-edge collaborative scheduling system to adapt to the dynamic changes in airport passenger flow and flights, continuously optimize scheduling strategies, site configurations, and risk control rules, and continuously improve service efficiency, fairness, security, and operational benefits. It achieves system adaptive optimization and adapts to the long-term large-scale operation needs of airports.

[0050] Optionally, the airport-oriented cloud-edge collaborative scheduling system further includes: The remote takeover module provides a remote control and emergency command interface for manual intervention when the vehicle is not operating normally.

[0051] Specifically, the remote takeover module is the core safety backup module of the cloud-edge collaborative dispatch system. It connects the edge safety monitoring module with back-end operations personnel, providing a safe and convenient channel for manual intervention when vehicles encounter anomalies, cannot operate autonomously, or require human assistance. This ensures the safety of vehicles and passengers while improving the efficiency of anomaly handling. In actual operation, the remote takeover module maintains real-time communication with the edge safety monitoring module and the vehicle, continuously receiving vehicle operating status data, anomaly alarm information, and environmental perception data. It monitors vehicle operating status in real time and identifies abnormal vehicle operation scenarios. Abnormal vehicle operation encompasses various situations: severe obstruction, inability to autonomously avoid obstacles, excessive frequency of emergency stops, positioning drift, sensor malfunction, abnormal battery power, passenger emergency requests, route planning failure, network fluctuations causing interruption of autonomous operation, and the need for manual guidance when entering complex or unfamiliar areas. When the remote takeover module detects abnormal vehicle operation, or when the vehicle actively sends a takeover request, it immediately initiates the remote takeover process. It pushes a takeover alert to back-end operations personnel and simultaneously displays anonymized vehicle information, including the vehicle's real-time location, trajectory, current status, passenger availability, surrounding environment summary, anomaly type, risk level, and system-recommended actions. This ensures operations personnel have a clear understanding of the situation on-site. Strictly adhering to privacy principles, it does not display sensitive data such as original passenger images or complete identity information, providing only anonymized semantic grids and bounding boxes. The remote takeover module provides back-end operations personnel with two types of manual intervention interfaces: a remote control interface and an emergency command interface. The remote control interface allows operations personnel to remotely control the vehicle through a visual interface to perform basic actions such as forward, reverse, turning, parking, and low-speed driving. The control precision is adapted to the operational needs of airport low-speed shuttle vehicles, avoiding operational errors. It also supports manual adjustment of the vehicle's route, guiding the vehicle to avoid congestion and dangerous areas, and safely reaching the destination or nearest station. The emergency command interface provides one-click emergency response functions, including commands such as emergency stop, pull over, return to the nearest station, contact passengers, disable vehicle functions, and trigger audible and visual alarms, adapting to sudden emergency scenarios for rapid response. During manual intervention, the remote takeover module synchronizes vehicle control feedback and environmental changes in real time, ensuring real-time control and accuracy. After intervention, the module records a complete takeover log, including the triggering reason, operation duration, control actions, handling results, and operator information, for subsequent auditing, accountability, and system optimization. Furthermore, the remote takeover module is deeply integrated with the edge security monitoring module. When the cloud network is normal, the module directly takes over; when the cloud fails, the edge security monitoring module temporarily stores abnormal information and synchronizes it to the remote takeover module after the network is restored, ensuring uninterrupted abnormal handling.This embodiment constructs a safety fallback mechanism for abnormal vehicle operation through the anomaly monitoring, anonymized information display, manual remote control, and emergency command support of the remote takeover module. It effectively addresses complex scenarios that cannot be resolved by autonomous vehicle operation, ensuring passenger and vehicle safety and improving anomaly handling efficiency. At the same time, it strictly adheres to privacy protection principles, balances safety and compliance, and adapts to the safety operation needs of airport public spaces.

[0052] Optionally, the airport-oriented cloud-edge collaborative scheduling system further includes: The maintenance work order module is used to integrate the vehicle's hardware health indicators, emergency stop alarm records, and mileage data, and generate maintenance work orders with different priorities.

[0053] Specifically, the maintenance work order module is the core operation and maintenance module for ensuring vehicle health and maintaining service continuity. By integrating multi-dimensional data on vehicle hardware, operation, and safety, it accurately identifies vehicle maintenance needs, generates tiered work orders, and achieves coordinated preventative and fault-based maintenance. This avoids vehicle downtime due to malfunctions and ensures the overall service capability of the fleet. In actual operation, the maintenance work order module connects in real time with the vehicle-side, cloud-based shared operation platform, and edge security monitoring module, continuously integrating three core data points: vehicle hardware health indicators, emergency stop alarm records, and mileage, to comprehensively assess the vehicle's maintenance status. Hardware health indicators cover vehicle battery health, sensor (vision, radar, ultrasonic) working status, braking system performance, wheel temperature, motor condition, circuit status, charging interface health, and cleaning and disinfection completion status, accurately reflecting whether there are potential hardware faults in the vehicle. Emergency stop alarm records include the number of emergency stops, the cause of the emergency stop, the area where the emergency stop occurred, and the vehicle speed at the time of the emergency stop. High-frequency emergency stops usually indicate abnormalities in vehicle perception, braking, or path planning. Mileage includes cumulative mileage, mileage per service, and average daily mileage, serving as the core basis for regular maintenance cycles. After integrating the above data, the maintenance work order module distinguishes between preventative maintenance and fault-based maintenance scenarios, generating maintenance work orders with different priorities. Preventative maintenance work orders target routine vehicle wear and tear, generated based on mileage, battery cycle count, brake wear, sensor cleaning cycles, etc., with priorities divided into low and medium levels: low-priority work orders correspond to non-emergency maintenance such as routine cleaning and basic checks, which can be scheduled for nighttime or off-peak flight times to avoid affecting peak-hour service; medium-priority work orders correspond to periodic maintenance such as battery maintenance, brake adjustment, and sensor calibration, which must be completed within 1-2 working days to prevent further wear and tear. Fault-based maintenance work orders are generated for abnormal vehicle malfunctions based on factors such as hardware failures, frequent emergency stops, sensor obstruction, passenger complaints, location drift, and frequency of manual intervention. Priority is divided into two levels: high and emergency. High-priority work orders address malfunctions affecting service quality, such as sensor failures, braking anomalies, and battery failures, and require same-day maintenance. Emergency-priority work orders address serious hardware damage, frequent emergency stops, and safety hazards; these immediately lock vehicle dispatch permissions, prioritize maintenance personnel for handling, and prevent faulty vehicles from being put into service. Each maintenance work order includes detailed information such as vehicle number, maintenance type, priority, fault / wear description, relevant data, recommended maintenance content, estimated work hours, maintenance location, and deadline, facilitating rapid problem location and efficient handling by maintenance personnel. Simultaneously, the maintenance work order module pushes generated work orders to the maintenance management terminal, tracking the receipt, processing, and acceptance status of work orders in real time. After maintenance is completed, the module updates the vehicle's health status, removes the dispatch restrictions for abnormal vehicles, and incorporates maintenance data into closed-loop maintenance analysis, providing a basis for subsequent maintenance cycle optimization and vehicle quality assessment.This embodiment achieves refined and scientific management of vehicle maintenance through multi-dimensional data integration, hierarchical work order generation, and full-process tracking via the maintenance work order module. It takes into account both preventive and fault-based maintenance, effectively reduces the probability of vehicle downtime, ensures the overall health and service continuity of the fleet, reduces maintenance costs, and adapts to the routine maintenance needs of a large-scale airport fleet.

[0054] Optionally, the airport-oriented cloud-edge collaborative scheduling system further includes: The closed-loop operation and maintenance module is used to generate operation and maintenance work orders based on the vehicle's fault codes, emergency stop frequency, sensor obstruction, wheel set temperature, battery health, passenger complaints and mileage, and adjust the subsequent dispatch strategy for the vehicle based on the operation and maintenance work orders.

[0055] Specifically, the closed-loop operation and maintenance module is the core module of the cloud-edge collaborative scheduling system, enabling the linkage between operation and maintenance and scheduling to form a closed-loop operation and maintenance system. By integrating operation and maintenance data throughout the entire vehicle lifecycle, it accurately generates operation and maintenance work orders and simultaneously adjusts the dispatch strategy in reverse, avoiding high-risk and low-health vehicles from the source of scheduling. This achieves operation and maintenance optimization and scheduling collaboration, improving the overall reliability and service quality of the fleet. In actual operation, the closed-loop operation and maintenance module collects real-time, multi-dimensional vehicle operation and maintenance data, covering seven core dimensions: vehicle fault codes, emergency stop frequency, sensor obstruction, wheel set temperature, battery health, passenger complaints, and mileage. This provides a comprehensive and accurate understanding of vehicle health status, operational performance, and service feedback. Vehicle fault codes are hardware fault codes output by the onboard system's self-diagnosis, directly reflecting faults in core components such as circuits, motors, and sensors. Emergency stop frequency statistics track the number of emergency stops per unit time, relating to the vehicle's perception and obstacle avoidance capabilities. Sensor obstruction records the duration and frequency of obstruction, affecting the accuracy of autonomous navigation. Abnormal wheel set temperature indicates potential problems in the braking or transmission system. Battery health reflects range and safety status. Passenger complaints cover service experience and vehicle fault-related feedback. Mileage serves as the basis for routine maintenance and wear assessment. The closed-loop maintenance module integrates the above data and automatically generates differentiated maintenance work orders. Work order types include routine maintenance, fault repair, component replacement, cleaning and disinfection, and special inspection work orders. Each type of work order is marked with priority, handling requirements, reference data, and risk warnings. For example, if a vehicle has an excessive emergency stop frequency, frequent sensor obstruction, and passenger complaints about inaccurate navigation, the module generates an emergency fault repair work order with the highest priority; if a vehicle's mileage is within the acceptable range and the battery is healthy, a routine maintenance work order is generated with a lower priority. After a maintenance work order is generated, the closed-loop maintenance module synchronizes the work order to the maintenance management platform to track the handling progress and ensure timely resolution of issues. More importantly, based on the vehicle problem corresponding to the maintenance work order, the module reversely adjusts the subsequent dispatch strategy for the vehicle, achieving coordinated control between maintenance and dispatch. For vehicles with minor anomalies or low-priority work orders, the module lowers their dispatch priority, prioritizing short-distance, low-risk, and ordinary service orders to avoid high-load and complex service scenarios. For vehicles with serious faults or high / urgent-priority work orders, the module directly locks dispatch permissions, prohibiting them from participating in any order dispatch until maintenance is completed and the vehicle returns to normal. For vehicles with frequent problems (such as a certain type of sensor being easily blocked or a certain batch of vehicles having a high emergency stop rate), the module adjusts the dispatch strategy for the same type of vehicles in batches, restricting dispatch in high-risk scenarios and simultaneously pushing batch maintenance recommendations. For vehicles that have completed maintenance and returned to normal, the module gradually restores their dispatch priority, prioritizing low-risk orders, and only includes them in the regular dispatch queue after a trial run without any anomalies. In addition, the closed-loop operation and maintenance module incorporates operation and maintenance work order data and dispatch adjustment records into the closed-loop operation analysis to optimize maintenance cycles, improve vehicle selection, and improve dispatch rules, forming a complete closed loop of "operation-monitoring-operation and maintenance-dispatch optimization".This embodiment achieves deep linkage between operation and maintenance work and the dispatch system through the integration of full-dimensional operation and maintenance data, precise work order generation, and dynamic adjustment of dispatch strategies in the closed-loop operation and maintenance module. It controls high-risk vehicles from the source, reduces safety hazards, and promotes continuous optimization of operation and maintenance strategies and dispatch rules to adapt to the refined operation and maintenance and dispatch needs of the airport's large-scale fleet, ensuring service security, stability, and high quality.

[0056] Optionally, the cloud-based shared operation platform further includes: The vehicle state layer is used to record the current state of the vehicle and receive the operational state data. The airport constraint layer models the airport topology as a graph structure with permission, time window, and capacity constraints, and dynamically sets the graph nodes and edges of the graph structure to obtain the dynamic constraint map of the airport.

[0057] Specifically, the vehicle status layer is the foundational data layer that enables the cloud to monitor vehicle dynamics in real time and support dispatching decisions. The airport constraint layer is the core map layer that adapts to the complex space and operational rules of airports, ensuring compliant and feasible dispatching. Together, they provide vehicle status data and spatial constraint support for cloud-edge collaborative dispatching, ensuring accurate, compliant, and feasible dispatching decisions. In actual operation, the vehicle status layer connects in real time with the vehicle-side and edge security monitoring modules, continuously recording the vehicle's current status. It covers nine core states: idle, passenger-carrying, returning to station, recharging, cleaning, maintenance, abnormal, remote takeover, and offline, fully reflecting the vehicle's status throughout its entire operating cycle. Idle state indicates that the vehicle has completed its service and is ready to be dispatched; passenger-carrying state indicates that the vehicle is performing passenger service; returning to station state indicates that the vehicle has completed its service and is en route back to the station; recharging state indicates that the vehicle is heading to a recharging point or is charging; cleaning state indicates that the vehicle is being cleaned and disinfected; maintenance state indicates that the vehicle is undergoing maintenance; abnormal state indicates that the vehicle has encountered abnormal situations such as malfunctions, sudden stops, or sensor obstruction; remote takeover state indicates that the vehicle is undergoing remote human intervention; and offline state indicates that the vehicle's network is interrupted or disconnected. The vehicle status layer simultaneously records the status trigger time, duration, cause, corresponding order / task, and related data (such as battery level and health status), forming a complete vehicle status log. This provides direct evidence for vehicle dispatch screening, task instruction generation, and anomaly handling. Furthermore, the vehicle status layer also synchronously links to station status data, including station capacity, queue length, available vehicles, waiting time, staff on-duty status, and service area boundaries, achieving a linkage and matching between vehicle status and station supply and demand. The airport constraint layer models the complex physical space, permission rules, and operational constraints of the airport into a graph structure containing permission, time windows, and capacity constraints, realizing a digital and rule-based mapping of the airport space. The graph structure consists of nodes and edges. Nodes cover stations, boarding gates, elevators, corridor intersections, security checkpoints, service counters, refueling points, and maintenance points, accurately marking key functional areas and facilities of the airport. Edges cover passable paths, one-way paths, slow-moving paths, elevator connections, temporary closures, and high-congestion edges, comprehensively depicting airport access rules and conditions. Each edge comes with detailed attributes, including length, estimated travel time, congestion cost, security level, accessibility, and dynamic availability, comprehensively reflecting travel efficiency, risks, and adaptability scenarios. The airport constraint layer adopts a multi-layer graph structure. The first layer is the physical reachability graph, describing physical connections such as corridors, elevators, and doorways. The second layer is the permission graph, defining permission boundaries such as after security checkpoints, customs, international / domestic isolation areas, and employee access routes, restricting cross-permission access. The third layer is the operations graph, linking operational dynamics such as boarding gates, flights, queues, and commercial areas. The fourth layer is the security graph, marking security constraints such as no-stopping zones, fire lanes, and low-speed zones.The map layer can be dynamically updated, incorporating dynamic constraints such as temporary fencing, elevator outages, boarding gate changes, congested areas, cleaning operations, and fire lane occupancy in real time. Edges that do not meet permission or safety conditions are directly marked as impassable, and the passage cost is increased for slow-moving or congested edges, forming a real-time and accurate dynamic constraint map of the airport. This map is deeply coupled with the scheduling model, and vehicle dispatching and route planning must simultaneously meet multiple layers of constraints to ensure that scheduling decisions comply with airport spatial permissions, access rules, and safety requirements, avoiding illegal and infeasible scheduling. This embodiment provides accurate vehicle status data and compliant spatial constraint basis for cloud-edge collaborative scheduling through full-dimensional status recording of the vehicle status layer and multi-layer dynamic modeling of the airport constraint layer. This ensures that scheduling decisions are aligned with actual vehicle conditions, adapt to the complex space and operational rules of the airport, guarantee scheduling feasibility, compliance, and security, and adapt to the multi-area, multi-constraint, and dynamic operational scenarios of airport terminals.

[0058] For example, in the specific implementation of this invention, the application of reservation and automatic vehicle dispatch for special passengers is first carried out. Passengers or airlines can submit travel requests before departure. The cloud-based shared operation platform inputs the flight number, departure time, passenger arrival time at the terminal, whether an escort is needed, the amount of luggage, and the destination into the service request object data. The airport data access layer obtains the estimated departure time of the flight associated with the service request through the airport interface and calculates the flight's boarding cut-off time or the gate's closing time. The airport constraint layer constructs a dynamic constraint map of the airport, which is combined with the real-time congestion status. The path optimization unit calculates the estimated time for the vehicle to travel from the current station to the destination gate using the A* algorithm or Dijkstra's algorithm. The fastest safe passage time is calculated by adding reasonable buffer times for boarding, alighting, and security checks based on passenger type characteristics, and then working backwards to determine the latest service start time. If the current system time approaches this threshold, the priority evaluation module will significantly increase the service priority ranking of the service request data. The multi-target vehicle dispatch module will trigger priority dispatch guarantee or proactively request manual intervention for demotion. At the same time, the pre-scheduling unit of the demand forecasting module will allocate idle vehicles to nearby standby areas before passengers arrive. If passengers are late or flights are delayed, the cloud-based shared operation platform will re-trigger the priority evaluation module to calculate the service priority ranking, and the multi-target vehicle dispatch module to update the vehicle dispatching strategy and vehicle routes. This application fully embodies the invention. System attributes: Vehicles are not isolated devices executing vehicle orders, but rather mobile nodes in the airport shared service network. Each vehicle dispatch affects subsequent station supply, refueling queues, maintenance windows, and service fairness. Therefore, this invention integrates service request object data allocation, path constraints, station relocation, and maintenance strategies into a cloud-based shared operation platform. In actual deployment, airports can choose a centralized cloud platform, airport private cloud, or local edge cluster based on their management authority. Important security events are handled locally in a closed loop, independent of the external public network. Statistical analysis and model updates are performed by uploading anonymized airport operation data during off-peak hours to reduce real-time communication pressure. Secondly, expedited service applications for transit passengers are implemented. When the distance between the passenger arrival gate and the next boarding gate is far and the connection time is tight, the priority evaluation module takes the risk of missing the flight as the core factor for service priority ranking. The multi-target vehicle dispatch module's screening and dispatching unit selects candidate dispatch vehicles that can reach the transfer point the fastest and whose battery level and health status meet the standards. The route optimization unit plans vehicle operation routes to avoid congested commercial areas. If congestion or vehicle abnormality occurs en route, the cloud-based shared operation platform can send a transfer instruction to the edge security monitoring module to change the vehicle order at a safe station along the way. This application also reflects the attribute of vehicles as mobile nodes in the airport shared service network. The actual deployment follows the above selection principles and data processing methods for cloud platforms, private clouds, or edge clusters.Next, the vehicle station relocation application is implemented. Before peak hours, the forecasting unit of the demand forecasting module constructs a model input feature vector based on historical order sequences, real-time flight schedules, weather influencing factors, and station congestion indices from airport operation data. Combined with the airport dynamic constraint map, it predicts passenger arrival volumes for multiple future time windows, thereby determining the supply-demand gap and generating demand forecast data. The pre-scheduling unit uses the demand forecast data to pre-allocate idle vehicles to standby areas adjacent to the demand area. If future demand is high near remote boarding gates and current vehicles are concentrated at the main terminal station, the cloud-based shared operation platform pre-arranges some empty vehicles to slowly relocate to remote standby areas. The relocation process does not compete with passenger vehicle orders for high-priority resources and must meet road congestion requirements. Despite power constraints, the application still reflects the network node attributes of vehicles and corresponding deployment and data processing rules. It then implements vehicle return to the station, recharging, and cleaning collaborative applications. After a vehicle completes its order, the cloud-based shared operation platform obtains the vehicle health status of vehicles without tasks. When the vehicle health status is normal, a revenue calculation method is used to determine the long-term overall revenue of vehicles without tasks and a task instruction is generated. When the vehicle health status is abnormal, a vehicle return instruction is generated. After each service, the cloud-based shared operation platform retrieves real-time vehicle data. If a vehicle is marked as having reached its mandatory cleaning cycle or its real-time remaining power is below a threshold, a new vehicle order is refused and the vehicle is locked. When a vehicle is in a critical power range, the cloud-based shared operation platform queries its... If there are high-priority service requests or concentrated dispatch needs in the region in the near future, and the real-time queue number of vehicles at the nearest available charging point is queuing, if there are high-value needs in the future and the current charging point is congested, the system will temporarily postpone queuing for charging and allow short-distance vehicle orders to be completed. If there are no urgent needs in the region and the charging point is vacant, a dispatch instruction to the charging point will be issued directly. For vehicles with short-term low battery but high demand nearby, they will be arranged to complete short-distance vehicle orders before charging. For vehicles with obstructed sensors or passenger complaints, priority will be given to cleaning and inspection. This application follows the vehicle network node attributes and deployment and data processing rules. Furthermore, an edge network outage autonomous application will be implemented. When the cloud-based shared operation platform fails, the edge security monitoring module will connect locally. This system manages the station queues and vehicle status within its area, receives airport operation data, vehicle dispatching strategies, and operation status data, stops relying on high-computing-power global scheduling optimization algorithms, downgrades to using local cached preset strategies, adopts a first-come-first-served queue mechanism or a greedy matching rule based on the nearest distance to arrange local vehicle dispatch, calls the local conservative baseline security map for path guidance and prohibits the dispatch of cross-regional long-distance vehicle orders, and stores the status changes and operation status data generated during the network outage in the edge security monitoring module. After the cloud-shared operation platform is restored, logs are uploaded and status is merged to ensure that queued passengers receive basic services and restrict vehicles from leaving the local security area. This application reflects the vehicle network node attributes and corresponding deployment and data processing rules.Subsequently, a collaborative application of human services and autonomous vehicles was implemented. For passengers who cannot be accommodated by autonomous mobility scooters, such as those carrying special medical equipment, exceeding vehicle capacity limits, or requiring manual assistance, a special assistance checkbox will pop up when the passenger applies via mobile terminal. Alternatively, the cloud-based shared operation platform can identify special passenger service codes pushed by airlines through dictionary rules. When passengers arrive at the station and attempt to board, special circumstances can be identified through station load monitoring devices, vehicle load sensors, or station visual perception cameras. Alternatively, a human can click a special interception mark on the dispatch management terminal for final judgment. After judgment, the cloud-based shared operation platform automatically transfers the passenger to the human service queue and releases vehicle resources. It can also recommend combined service methods based on the location of human service personnel and vehicle availability, with human service personnel transporting the passenger to the station, and then the autonomous vehicle completing the long-distance journey. This application reflects the vehicle network node attributes and corresponding deployment and data processing rules. Furthermore, an operational quality assessment application was implemented. The operational evaluation closed-loop module obtains actual operational indicators based on flight waves as a preset cycle, including average waiting time and the most frequent special passenger incidents. The system measures long waiting times, order completion rates, vehicle utilization rates, empty-running rates, station vehicle shortage durations, low battery dispatch rates, emergency stop rates, manual takeover rates, complaint rates, and maintenance timeliness to determine the deviation between actual operational indicators and target expectations. If repeated vehicle detours, emergency stops, or passenger cancellations occur in a particular boarding gate area, the cloud-based shared operation platform marks this area as an operational pain point and suggests adding stations, adjusting routes, lowering speed limits, or optimizing wayfinding. If the failure rate of a certain type of vehicle increases, the multi-target dispatch module restricts its dispatch range, and the maintenance work order module generates maintenance work orders with corresponding priorities. This application reflects the vehicle network node attributes and corresponding deployment and data processing rules. Finally, privacy protection and auditing applications are implemented. The cloud-based shared operation platform adopts a minimal collection principle for passenger identity and image information. Dispatch and scheduling only require the service request number, area permissions, time window, and auxiliary tags, without sending complete identity information to the vehicle. When abnormal events need to be traced, the platform retrieves anonymized logs according to permissions and records the accessor, access time, and purpose. This application reflects the vehicle network node attributes and corresponding deployment and data processing rules.

[0059] For example, in the extended implementation, parameter boundary setting, and industrialization verification of this invention, service request object data is the foundation of the cloud-based shared operation platform method. Each service request object data includes not only the origin and destination, but also time window, passenger assistance level, area permissions, baggage quantity, number of companions, whether carpooling is possible, whether staff assistance is required, language preference, and privacy authorization status. Through unified modeling, airline special passenger work orders, airport service desk calls, station screen calls, and ordinary passenger QR code scanning requests can be placed in the same queue for comparison, avoiding the formation of multiple isolated systems. The airport constraint layer preferably adopts a multi-layer graph structure to construct the airport dynamic constraint map. The first layer is a physical reachability map, used to describe corridors, elevators, etc. The system consists of four layers: a gate and a station connection; a second layer, a permission graph describing the boundaries of the post-security checkpoint, customs, international area, domestic area, and employee access points; a third layer, an operations graph describing boarding gates, flights, queues, commercial areas, and temporary barriers; and a fourth layer, a security graph describing no-stopping zones, fire lanes, low-speed zones, and takeover priority zones. During scheduling, feasible paths are calculated only on edges that simultaneously satisfy multiple layers of constraints. The demand forecasting module can be configured with different levels of complexity depending on the airport size. Small airports use a time-series model based on flight waves and historical orders, while large hub airports use a neural network prediction model based on a spatiotemporal attention mechanism. This model incorporates flight arrivals, passenger walking time, security queues, and station availability into its input feature vector, predicting the results. This system is used not only for scheduling optimization in the multi-target vehicle dispatch module, but also for vehicle relocation, energy replenishment scheduling, and staff shift recommendations. The service priority ranking in the priority evaluation module should not be simply understood as fixed label ranking. The module incorporates mobility impairment level, waiting time, flight miss risk, and service fairness into its calculation dimensions. For ordinary passengers, a longer waiting time and a longer destination will result in a higher service priority ranking. For special passenger service requests, if the corresponding flight is delayed and can be handled manually, the vehicle dispatch strategy can be adjusted based on resource availability to avoid rigidity. The multi-target vehicle dispatch module can employ integer programming, heuristic search, auction algorithms, rolling temporal optimization, or reinforcement learning strategies to achieve scheduling optimization, given the real-time requirements of airports. For high-quality dispatching, a candidate vehicle screening + local optimization + rolling recalculation approach is preferred. The vehicle screening unit first eliminates vehicles that do not meet the requirements of power, health, area and safety, and then solves the optimal match in a small set of candidate vehicles. The route optimization unit simultaneously optimizes the vehicle operation route and quickly recalculates the vehicle dispatching strategy when the vehicle status or flight status changes. The waiting time in the dispatching objective function should distinguish between the time passengers wait for the vehicle to arrive and the time passengers travel to their destination. In airport services, the latter is equally important. Even if the vehicle arrives quickly for passengers at remote boarding gates, they may still miss their flights if the route is too long. Therefore, the priority evaluation module incorporates the service start time, estimated arrival time and latest arrival time into the calculation dimension of flight miss risk.Vehicle empty-run rate and station balance are important indicators for shared operation. If the system only pursues minimizing the current vehicle order waiting time, it may lead to all vehicles flowing to popular stations while leaving unpopular stations empty for extended periods. The cloud-based shared operation platform uses station balance penalties and demand forecast data to encourage some vehicles to proactively return to areas with high future demand or low supply after completing their orders. Vehicle return and refueling scheduling should be coupled with vehicle order scheduling. Low vehicle battery does not necessarily mean immediate refueling is required. If there is a short-distance, high-priority service request nearby and the vehicle can safely reach the refueling point after completion, the cloud-based shared operation platform allows the vehicle to complete the order. Conversely, even if the battery is still sufficient, if the vehicle's health is abnormal or the frequency of emergency stops is too high, the maintenance work order module will prioritize generating high-priority work orders. For maintenance and repair work orders, the closed-loop operation and maintenance module adjusts subsequent dispatch strategies to improve service continuity and reduce risks. The edge security monitoring module assumes a local autonomy and security buffer role. While the cloud-based shared operation platform is suitable for global optimization, some areas of the airport may not be continuously connected due to network, construction, or security requirements. The edge security monitoring module can maintain the station queue, vehicle status, and temporary airport dynamic constraint map for its local area. It also executes conservative vehicle dispatch rules when the cloud-based shared operation platform fails. After the cloud-based shared operation platform recovers, it merges local events with cloud status to avoid duplicate vehicle orders or vehicle status errors. The monitoring interface of the remote takeover module should be designed around anomaly handling, rather than allowing operators to control vehicles for extended periods like drivers. The interface should preferably display vehicle information. The system displays vehicle location, current status, passenger availability, surrounding target summary, risk level, suggested actions, and optional buttons. Privacy-sensitive areas are displayed as semantic grids or bounding boxes instead of the original video by default, with more detailed footage only accessible during permission approvals or emergencies. The maintenance work order module generates two categories: preventative maintenance and fault-based maintenance. Preventative maintenance is based on mileage, battery cycles, wheel temperature, brake wear, and sensor cleanliness. Fault-based maintenance is based on fault codes, emergency stop anomalies, positioning drift, manual intervention, and passenger complaints. The cloud-based shared operation platform can schedule maintenance windows based on subsequent vehicle order pressure to avoid all vehicles being offline simultaneously. The operation evaluation closed-loop module not only outputs reports but also analyzes actual operating indicators against target periods. To adjust system parameters based on the deviation of indicators, if the emergency stop rate in a certain area is consistently high, the risk cost of the airport's dynamic constraint map for that area should be increased, the default speed reduced, or the airport's signage and isolation zones should be adjusted. If there are long queues at a certain station, it is recommended to increase the station's capacity or reposition vehicles in advance during peak hours. If the cancellation rate of a certain type of order is high, the display of estimated waiting time and the way passengers are notified should be optimized. In terms of data security, the cloud-based shared operation platform follows the principle of minimization. The vehicle-side navigation only requires a partial map, destination, authorized area, and service number, without requiring complete passenger identity. The identity information stored in the cloud is isolated from the operational status data. During anomaly audits, it is linked through an authorization process. Model training prioritizes the use of anonymized trajectory, event, and actual operational indicator data to reduce the risk of personal information leakage.In terms of deployment, the platform can adopt an airport private cloud, edge server, or hybrid cloud architecture. Key business data is preferably deployed on the airport intranet or private network. Offline model training and statistical analysis can be transferred to an external computing platform after anonymization. Communication between vehicles and the platform adopts 5G private network, Wi-Fi 6, Ethernet backhaul site, or multi-link redundancy. The cloud-based shared operation platform can collaborate with existing airport systems, including flight information display system, boarding gate management system, accessibility service system, security platform, fire protection system, elevator system, and commercial operation system. Not all interfaces are necessary conditions for implementing this invention, but the richer the interfaces, the closer the scheduling results are to the actual operational optimality. The core method emphasizes the coupling of multi-source airport constraints and vehicle scheduling, without limiting a specific interface protocol. For shared services for general passengers, the cloud-based shared operation platform can set prices, free periods, service areas, or usage limits. For special passenger services, the platform can set free priority service strategies. Regardless of changes in the business model, the core of scheduling remains the unified solution of service request object data, airport dynamic constraint maps, vehicle status, and service priority ranking, which does not affect the technical essence of this invention. The platform supports mixed operation of human service personnel and autonomous vehicles. In the early deployment phase, airports can arrange service personnel at stations to help passengers board, confirm destinations, and handle anomalies. After the system matures, some processes will be converted to self-service. Mixed operation data will be used to reverse train the platform to identify which passengers, routes, or time periods still require human intervention. In terms of verification indicators, the operation evaluation closed loop is implemented. The module sets average waiting time, maximum waiting time for special passengers, order completion rate, vehicle utilization rate, empty running rate, station vehicle shortage duration, low battery dispatch rate, emergency stop rate, manual takeover rate, complaint rate, and maintenance timeliness rate. These indicators can be used as project acceptance indicators or as inputs to the loss function for closed-loop optimization. If the airport has multiple terminals or integrated transportation centers, the airport constraint layer can model each terminal as a subgraph, and model the connecting passages, shuttle buses, elevators, or metro nodes between terminals as cross-domain edges. The cloud-based shared operation platform coordinates vehicle resources between different subgraphs, but must meet regional permissions and operation rules. Vehicles that cannot cross regions can only be dispatched within their permitted service area. In the event of emergencies such as large-scale flight delays, security checkpoint closures, etc., In the event of fire alarms, temporary security controls, or extreme congestion, the cloud-based shared operation platform switches to an emergency strategy, prioritizing the safe arrival of vehicles already carrying passengers at the nearest station, suspending new vehicle orders, retaining data on special passengers and those requesting emergency assistance services, and relocating idle vehicles to locations that do not obstruct passageways, thus avoiding increasing the airport management burden on autonomous mobility scooters in emergency scenarios. Alternative implementation methods include integrating autonomous mobility scooters with baggage delivery robots, cleaning robots, and inspection robots into the same airport robot dispatch platform. Different robot types share the airport's dynamic constraint map and edge safety monitoring module, but use different task models and safety parameters. This expansion approach facilitates the formation of a unified robot operation platform for the airport. The cloud-based shared operation platform's data... According to the preferred approach, an event flow and a status table are combined. Flight changes, vehicle emergency stops, passenger cancellations, and station congestion are considered event flows, requiring rapid triggering of scheduling recalculation. Vehicle location, battery level, health status, station capacity, and queue length are considered status tables, requiring up-to-date snapshots. After separating event flows and status tables, the platform can perform both real-time responses and stable statistical analysis. Service request object data can be set with scalable service attributes. When a passenger needs to travel from the check-in area to a remote boarding gate, but one segment is unsuitable for autonomous vehicles due to safety rules, the cloud-based shared operation platform can divide the service into a manual assistance segment, an autonomous vehicle segment, and a walking shortcut segment. Each segment has an independent time window and responsible entity, and the platform is responsible for ensuring smooth connection. For multiple travelers traveling together, the cloud-based shared operation platform supports a group booking strategy. When a family or group needs multiple vehicles, the platform treats it as a related request, requiring vehicles to arrive at the same time, have similar routes, and be released simultaneously near the destination. When there are not enough vehicles, priority is given to members with mobility impairments, and walking navigation or waiting suggestions are provided to other members. For scenarios where group booking is possible, the multi-target vehicle dispatch module can arrange shared routes under the conditions of same direction, same access area, compatible time window, and passenger consent. Autonomous mobility vehicles have limited space and do not require multiple passengers in the same vehicle, enabling multi-vehicle platooning or close-range collaborative services. The platform reduces redundant empty runs through platooning while avoiding impacts on passenger privacy and comfort. In the engineering implementation of the multi-target vehicle dispatch module, the cloud-based shared operation platform first sorts and bins the service request object data according to region, time window, and service priority, and then solves vehicle matching within each bin. This reduces the computational complexity during peak airport periods. Extremely high-priority requests can interrupt the return-to-station tasks of low-priority vehicles, but will not interrupt vehicles already carrying passengers or potentially causing safety issues. Vehicle orders may involve fairness issues; station capacity constraints are a key characteristic of airport scenarios. Stations that are too small will cause returning vehicles to occupy passageways, while stations that are too large will occupy terminal space. The cloud-based shared operation platform uses real-time station capacity and demand forecast data to jointly determine whether a vehicle should return to a station. When a station is full, a vehicle can enter a virtual station or a nearby standby point, only entering the station entrance when requested by a passenger. Vehicle cleaning and disinfection status are incorporated into the cloud-based shared operation platform's scheduling. After infectious disease control, long-term operation, or special passenger services, vehicles may require window cleaning. The platform determines the cleaning frequency based on airport rules, vehicle usage frequency, and passenger feedback, and treats cleaning points as nodes on the airport's dynamic constraint map for scheduling, avoiding vehicle... During peak periods, vehicle supply is insufficient due to concentrated cleaning; the cloud-based shared operation platform can interface with airport membership systems or airline service systems, but the technical solution does not rely on commercial identity. Even without membership data, the platform can still complete scheduling based on request source, time window, departure point, and destination. The role of connecting with membership or airline data is to improve service personalization and advance prediction capabilities, but it is not a necessary condition for the implementation of this invention; in the remote takeover module audit, every manual intervention records the triggering reason, operator, operation duration, vehicle location, passenger status, and result. The audit data is used for accountability and also for identifying system weaknesses. Frequent manual confirmation in certain areas indicates that the airport dynamic constraint map or perception model needs improvement. For updates, frequent occurrences of certain types of faults indicate that vehicle hardware or maintenance cycles need adjustment; the closed-loop learning of the cloud-based shared operation platform adopts a safe, layered update approach. Demand prediction modules, vehicle relocation, and waiting time estimation can be iterated relatively quickly, while safety thresholds, speed limits, and restricted access rules require manual review before updates. This approach can improve efficiency by utilizing operational data while avoiding unverified model updates that could affect public space safety; it provides airport management with a strategy sandbox function. Before actually adjusting stations or adding vehicles, operations personnel can simulate waiting times, utilization rates, and station congestion under different flight waves and vehicle numbers in a digital twin environment. The sandbox output serves as the basis for purchasing vehicles, setting up stations, and assigning personnel;When airports operate multiple brands or models of shuttle vehicles, the cloud-based shared operation platform ensures compatibility through a unified vehicle capability description. This description includes maximum speed, range, service area, elevator support, remote takeover capability, load capacity, and sensor capabilities. The multi-target dispatch module filters vehicles based on these capability descriptions, without limiting vehicles to the same manufacturer. In scenarios where regulations or airport rules require staff confirmation, the cloud-based shared operation platform sets up a manual confirmation node. For first-time use, special passengers, cross-floor travel, elevator linkage, or entry into specific areas, staff confirmation is required on a station screen or mobile terminal. This confirmation node is considered a time window constraint and incorporated into the scheduling process, without being processed independently of the system. The economic benefits are reflected in three aspects: reducing vehicle empty runs and passenger waiting through demand forecasting module scheduling; reducing downtime through integrated vehicle return-to-station recharging and maintenance; and reducing manual inspections and ineffective patrols through data closure in the operation evaluation closed-loop module. Even with higher unit vehicle costs, platform-based operation can achieve a return on investment advantage by improving utilization and reducing manual implementation pressure. This invention adopts different tailoring methods for airports of different sizes. Small airports only deploy reservation, station, vehicle status, and simple priority configurations; medium-sized airports add demand forecasting and edge security monitoring modules; and large hub airports further integrate flight dynamics, passenger flow heatmaps, elevator linkage, and digital twins. All tailored versions retain the number of service request objects. Based on the core of the system, including airport dynamic constraint maps and multi-target vehicle dispatching modules; from a patent examination perspective, this invention is not a typical shared vehicle dispatching algorithm, but rather combines airport accessibility services, flight time windows, regional permissions, station capacity, vehicle health, and closed-loop operation and maintenance into the operation of autonomous driving mobility scooters. This combination solves the technical problems in airport scenarios where there are vehicles but they are not in the correct locations, there is demand but it cannot be responded to fairly, and there is autonomous driving but a lack of operational closed loop; when dealing with predictive uncertainty, the cloud-based shared operation platform uses confidence intervals rather than single predictive values. The demand at a certain station in the next fifteen minutes may be five to ten vehicles. The system combines the current vehicle availability and relocation costs to choose a conservative or aggressive strategy, with special passenger services given priority. A conservative supply strategy is adopted, while ordinary shared services prioritize efficiency. This invention sets up an order commitment mechanism. When the cloud-based shared operation platform receives a request, it provides the estimated pick-up time and estimated arrival time, and updates the commitment based on the real-time operating status. If the predicted latest arrival time cannot be met, it will prompt passengers in advance to use manual service, walking navigation, or other transportation methods at the airport, rather than waiting until the timeout to fail. It provides airport operation managers with service heat maps, which display the demand, waiting time, vehicle shortage duration, emergency stop events, and manual takeover locations at each station during different time periods. Operators can adjust station locations, signage, vehicle quantity, and staff scheduling based on the heat map, transforming autonomous vehicle operation data into a basis for airport space optimization.During vehicle relocation, the cloud-based shared operation platform sets up rules for empty vehicles without passengers. Empty vehicles choose routes that prioritize operational efficiency but still adhere to low speed, safe distance, and restricted areas. During peak hours, empty vehicles avoid crossing boarding gate queues or core pedestrian areas in commercial districts, ensuring vehicle supply while preventing empty vehicle dispatch from interfering with passengers. The cloud-based shared operation platform provides different permissions for different airport roles: service personnel can view station queues and assist passengers in booking taxis; maintenance personnel can view vehicle health and maintenance work orders; security personnel can view abnormal events and audit records; and management personnel can view actual operational indicators and policy configurations. This hierarchical permission system reduces errors and complies with airport operational standards. The platform implements a clear division of responsibilities. In cases of abnormal vehicle re-dispatch, the cloud-based shared operation platform distinguishes between vehicles already carrying passengers and requests from vehicles without passengers. When a vehicle carrying passengers experiences an anomaly, priority is given to ensuring passengers reach the nearest safe station and arranging alternative vehicles or human assistance. When a vehicle without passengers experiences an anomaly, its order is directly canceled and reassigned. This differentiated logic enhances passenger experience and safety. The platform incorporates station design into its methodology. Stations include vehicle location markers, passenger queuing areas, boarding waiting areas, operator support areas, and vehicle refueling interfaces. The platform calculates the number of vehicles that can park and the maximum number of waiting passengers based on the station's physical capacity, preventing congestion around the station from negatively impacting vehicle access. For elevator linkage, the cloud-based shared operation platform treats elevators as dynamic edges with limited capacity and time windows. When dispatching orders across floors, it predicts elevator waiting time, car capacity, and whether vehicle entry is permitted. If the elevator is unavailable, it reselects the destination reachable on the same floor, provides manual service, or offers an alternative route. During holidays or large events, the cloud-based shared operation platform switches to special operation strategies, increasing the weight of future demand predictions, increasing vehicle reserves at remote stations, lowering the acceptable distance threshold for ordinary orders, and increasing the number of vehicles available to support special passenger service requests. After the event, it gradually reverts to the regular strategy. To facilitate commercial replication, the cloud-based shared operation platform provides airport configuration templates. These templates include terminal topology import, station type, service area, vehicle capacity, accessibility rules, priority weights, and actual operation indicator thresholds. Different airports only need to configure the templates without rewriting the dispatch system, reducing deployment costs. This invention provides a basis for decision-making regarding vehicle procurement and deployment quantities. By simulating waiting times, utilization rates, and vehicle shortage durations under different vehicle numbers, the cloud-based shared operation platform outputs minimum vehicle configuration suggestions and peak-hour temporary expansion suggestions, extending the system from an operational tool to an airport smart operation planning tool. For airports with multiple operators, the cloud-based shared operation platform supports the division of responsibilities among airlines, airports, and third-party service providers. Service request sources, vehicle dispatch results, anomaly handling, and maintenance records are all timestamped in logs, facilitating service settlement and accountability. This is beneficial for the implementation of autonomous mobility scooters as airport service outsourcing or joint operation projects. Regarding model updates, the cloud-based shared operation platform adopts a canary release approach. New demand forecasting module parameters or scheduling weights are first tested at a limited number of stations or during off-peak hours. Waiting time, emergency stop rate, and complaint rate are compared with the old model. The application scope is expanded only after the new model meets safety and service indicators, reducing the operational risks brought about by algorithm updates. The cloud-based shared operation platform incorporates passenger feedback. After the trip, passengers evaluate waiting time, comfort, route rationality, and level of assistance. Feedback is associated with specific routes, vehicles, stations, and time periods to identify localized problems. A low comfort score for a certain route may be due to uneven ground, sharp turns, or frequent congestion. For cross-language airport environments, the cloud-based shared operation platform distributes interactive language to the vehicle based on passenger language preferences and provides standardized multilingual prompt templates to operators in case of anomalies, reducing the impact of differences in service personnel's language proficiency on service quality. This invention allows airports to set different service access ranges under different risk levels: initially only open to internal staff or specially booked passengers, then to fixed areas after security checks in the mid-term, and finally to general passengers in the mature stage. The cloud-based shared operation platform controls the access range through permission and area configuration without changing the vehicle's underlying architecture. Through the above extensions, this invention forms a prediction-dispatch-execution-monitoring-maintenance-evaluation-optimization system. This closed-loop system, rather than a one-off vehicle dispatch, is key to the airport shared mobility service's transition from pilot to large-scale operation, and is the core value that distinguishes this invention from ordinary autonomous driving vehicle management systems. The cloud-based shared operation platform establishes a no-fly risk model based on flight cut-off rules. The model considers not only the distance to the boarding gate but also the walking time after security check, the boarding gate closing time, the passenger boarding preparation time, the estimated vehicle travel time, and the possible detour time. When the no-fly risk exceeds the threshold, the priority evaluation module prioritizes the service, and the multi-target vehicle dispatch module prioritizes dispatching vehicles or suggests rapid human assistance, thus truly embedding the autonomous driving mobility service into the airport travel chain. For station queue management, the cloud-based shared operation platform generates transparent queue numbers and estimated waiting times. Regular passengers can choose to continue waiting or walk after seeing the estimated waiting time, while passengers with special needs receive more stable waiting times. Staff decide whether to add extra human assistance based on the queue status. Transparent queuing reduces on-site disputes and improves the acceptability of shared services. The cloud-based shared operation platform provides operators with anomaly aggregation functionality. When multiple vehicles report sensor obstruction, emergency stops, or failed detours in the same area, the platform no longer treats the event as a single-vehicle malfunction but classifies it as a regional anomaly and sends alerts to map maintenance or on-site management personnel. Regional anomalies may originate from temporary barriers. Obstructions, ground reflections, crowd congestion, or changes in wayfinding; in large-scale fleet scenarios, the cloud-based shared operation platform avoids localized congestion between vehicles. Vehicle return to station, relocation, and dispatch routes are penalized by fleet density to prevent multiple empty vehicles from simultaneously traversing the same narrow corridor. Tasks in the same direction are staggered or different routes are chosen, so that autonomous vehicles themselves do not become a source of airport congestion. The cloud-based shared operation platform supports service level agreement configuration. Airports can stipulate the maximum waiting time for special passengers, the average waiting time for ordinary passengers, the minimum vehicle availability, and the peak-hour station vehicle shortage limit. The multi-objective dispatch module transforms these service level agreements into constraints or penalties, so that the technical system directly supports management objectives. Regarding the charging relationship between vehicles and stations, the cloud-based shared operation platform employs different strategies such as slow charging, fast charging, battery swapping, or manual charging. Charging stations are considered resources with limited capacity, and vehicles need to make an appointment to enter. Charging for some vehicles is temporarily suspended during periods of high demand, while charging and maintenance are centrally scheduled during off-peak periods to improve service continuity throughout the day. When deployed across multiple airports, the cloud-based shared operation platform retains the common algorithm core, replacing only the airport dynamic constraint map, station configuration, service rules, and interface adaptation layer. This protects core technologies while quickly adapting to the spatial structure and operational habits of different airports. This replicability is a significant commercial value of this invention as a platform-based patent. The cloud-based shared operation platform also provides management suggestions. The platform recommends adding new stations, adjusting station opening hours, changing the number of vehicles deployed, setting up temporary standby areas, or optimizing accessible pathway signage. These management suggestions are generated based on real operational data and better reflect airport passenger flow changes than one-time planning. Through supplementary implementation methods, the platform has developed a complete technology chain from single vehicle dispatch to long-term operational optimization, protecting key coverage data of service request objects, airport dynamic constraint maps, service priority ranking, multi-target dispatch modules, edge security monitoring modules, anomaly auditing, and closed-loop updates at multiple levels. Even if vehicle hardware changes in the future, the platform's approach remains stable and applicable. When the cloud-based shared operation platform connects with the flight system, it addresses data latency and data loss issues, including flight dynamics. When temporarily unavailable, historical flight schedules and real-time station queues are used to estimate demand. When gate data is delayed, conservative inferences are made based on the most recent valid information and airport signage status. If data reliability is insufficient, the strength of automatic commitments is reduced, and orders requiring manual confirmation are marked for operations staff. For service cancellations and no-shows, the cloud-based shared operations platform employs a flexible release mechanism. Vehicles will not immediately leave if passengers do not arrive at the station at the agreed time; after a short wait, decisions are made based on queue conditions to continue waiting, reassign to the next order, or return to the standby area. For special passengers or airline-booked orders, vehicles are released only after confirmation with staff to avoid service interruptions due to slow passenger movement. The cloud-based shared operations platform establishes a system based on vehicle historical performance. Vehicle trust rating is determined by factors such as frequent sudden stops, location drift, sensor obstruction, manual intervention, or low passenger ratings. Vehicles with low trust ratings are only assigned to low-risk routes or enter maintenance checks, while vehicles with high trust ratings are given priority for time-sensitive or complex routes. This mechanism directly feeds back the operational status to scheduling decisions. In terms of algorithm fault tolerance, the cloud-based shared operation platform sets up layers of hard and soft constraints. Area permissions, minimum battery level, vehicle health, and restricted areas are hard constraints that cannot be exceeded by the optimization model. Waiting time, empty driving distance, station balance, and energy consumption are soft constraints that can be compromised through weight adjustments. Layered constraints ensure that the system does not sacrifice basic safety and compliance requirements when optimizing between complex objectives.The cloud-based shared operations platform provides airports with a strategy replay function. Operations personnel can select an abnormal order or peak period to replay the service request queue, vehicle location, airport dynamic constraint map, vehicle dispatch results and subsequent status changes at that time. By replaying, they can determine whether the problem is caused by insufficient vehicles, incorrect map constraints, unreasonable site settings or inappropriate algorithm weights. For airports requiring third-party audits, the cloud-based shared operations platform exports standardized reports, including total service volume, special passenger support, abnormal events, manual takeover, vehicle maintenance, data access records, and model versions. These reports correspond to operational logs, supporting safety assessments, service quality evaluations, and project acceptance. The cloud-based shared operations platform supports scenario-based configuration of multi-objective weights: emphasizing waiting time and special passenger support during morning peak hours, energy consumption and maintenance at night, site balancing and passenger reassurance during flight delays, and remote gate supply during large-scale events. Different configurations are authorized and activated by management personnel, and their effects are automatically recorded after activation. The long-term value of this invention also lies in data asset accumulation. Airports obtain fine-grained data on traffic efficiency, accessibility needs, and spatial congestion through autonomous vehicles. This data supports terminal renovation, wayfinding optimization, service personnel allocation, and commercial area circulation optimization. Autonomous vehicles are not merely transportation tools but also mobile sensing and service nodes for smart airport operations. In actual charging or resource allocation scenarios, the cloud-based shared operations platform integrates service strategies with airport public service attributes. For services such as accessibility, emergency transfers, and airline-commissioned services, a priority strategy is adopted. For short-distance shared use by ordinary passengers, a reservation, time-limited, or queuing strategy is adopted. The technical system is only responsible for executing fair scheduling according to configuration rules, without taking commercial prices as the sole optimization target, thus avoiding unreasonable resource allocation in public transportation hub services. When the airport adds temporary events, VIP access control, or construction barriers, operators can mark the temporary areas graphically in the cloud-based shared operation platform. The system automatically converts them into no-entry edges, slow-entry edges, or time window edges in the airport's dynamic constraint map. Vehicles can adjust dispatch and return routes according to the updated constraint map without re-mapping, and the rapid configuration capability significantly improves the platform's adaptability to daily changes at the airport. The cloud-based shared operation platform has a simulation evaluation interface that imports real orders and vehicle status into the simulation environment to compare waiting time, empty run rate, and service fairness under different scheduling weights. The simulation results are approved before being incorporated into the actual operation strategy, avoiding unverified parameters from directly affecting passenger service. This mechanism makes the scheduling strategy iteration engineering controllable and management traceable.

[0060] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc. In this application, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of the present invention according to actual needs. Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units can be implemented in hardware or as software functional units.

[0061] While the present invention has been disclosed above, its scope of protection is not limited thereto. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the present invention, and all such changes and modifications will fall within the scope of protection of the present invention.

Claims

1. A cloud-edge collaborative scheduling system for airports, characterized in that, include: The cloud-based shared operation platform is used to acquire airport operation data and airport dynamic constraint maps, and encapsulate the multi-source service requests in the airport operation data into service request object data respectively; The demand forecasting module is used to predict demand forecast data for multiple future time windows based on the airport operation data and the airport dynamic constraint map. The priority evaluation module is used to determine the service priority ranking of the service request object data based on passenger condition data in the airport operation data and fairness constraints. The multi-target vehicle dispatch module is used to perform dispatch optimization based on the service request object data, the demand prediction data, the service priority ranking, and the vehicle status in the airport operation data to obtain a vehicle dispatch strategy. On the vehicle side, it is used to control the operation of each vehicle according to the vehicle scheduling strategy and to feed back the operating status data of each vehicle to the cloud-based shared operation platform in real time. The edge security monitoring module is deployed locally in the airport area to receive the airport operation data, the vehicle dispatching strategy, and the operation status data, and to control the vehicles to complete the vehicle orders in the vehicle dispatching strategy when the cloud-based shared operation platform fails. The cloud-based shared operation platform includes: The airport data access layer is used to acquire initial airport operation data and the airport dynamic constraint map, and to perform time synchronization, desensitization and anomaly filtering on the initial airport operation data to obtain the airport operation data. The airport data access layer is also used to acquire MAC address connection count and signal strength, site monitoring radar data, and vehicle speed data; estimate regional passenger flow based on the MAC address connection count and signal strength, count the current number of people queuing and the inspection rate based on the site monitoring radar data, and calculate the traffic flow speed of local road sections based on the vehicle speed data distribution; align the regional passenger flow, the current number of people queuing and the inspection rate, and the traffic flow speed of local road sections with timestamps, and filter out noise using a weighted fusion algorithm to generate real-time personnel density and flow rate characteristics for different channels and waiting areas; input the real-time personnel density and flow rate characteristics into a pre-trained passenger flow status assessment model to generate passenger flow density heatmap values ​​in the airport operation data; extract high-density areas from the passenger flow density heatmap values ​​and map the high-density areas onto the airport dynamic constraint map; The service request layer is used to encapsulate the multi-source service requests into service request object data respectively; The demand forecasting module includes: The prediction unit is used to construct a model input feature vector based on historical order sequences, real-time flight plans, weather influencing factors, and station congestion index in the airport operation data; based on the model input feature vector and the airport dynamic constraint map, it uses a neural network prediction model based on a spatiotemporal attention mechanism to predict passenger arrivals in multiple future time windows; based on the passenger arrivals, idle vehicle data, and empty vehicle data en route, it determines the supply-demand gap, and generates the demand prediction data based on the supply-demand gap; The pre-scheduling unit is used to pre-call idle vehicles to the standby area adjacent to the demand area in the demand forecast data based on the demand forecast data. The cloud-based shared operation platform also includes: The vehicle status layer is used to record the current vehicle status and receive the operating status data; The airport constraint layer models the airport topology as a graph structure with permission, time window, and capacity constraints, and dynamically sets the graph nodes and edges of the graph structure to obtain the dynamic constraint map of the airport.

2. The cloud-edge collaborative scheduling system for airports according to claim 1, characterized in that, The multi-target vehicle dispatch module includes: The vehicle dispatching unit is used to filter candidate dispatching vehicles based on the service request object data and the vehicle status, and to perform vehicle dispatching optimization based on the objective function and the candidate dispatching vehicles to obtain the vehicle dispatching decision of the vehicle dispatching strategy. The route optimization unit is used to optimize the route based on the vehicle dispatch decision, the service request object data, the demand prediction data, and the service priority ranking, so as to obtain the vehicle running route in the vehicle scheduling strategy.

3. The cloud-edge collaborative scheduling system for airports according to claim 1, characterized in that, The cloud-based shared operation platform is also used for: Obtain the vehicle health status of vehicles without assigned tasks whose vehicle orders have been completed; When the vehicle health status is normal, the long-term overall revenue of the unattended vehicle is determined by the revenue calculation method, and the task instruction of the unattended vehicle is generated based on the long-term overall revenue. When the vehicle's health status is abnormal, a vehicle return command is generated.

4. The cloud-edge collaborative scheduling system for airports according to claim 1, characterized in that, Also includes: The operation evaluation closed-loop module is used to acquire actual operation indicators at preset cycles, determine the deviation between the actual operation indicators and the target expected indicators, and adjust system parameters according to the deviation.

5. The cloud-edge collaborative scheduling system for airports according to claim 1, characterized in that, Also includes: The remote takeover module provides a remote control and emergency command interface for manual intervention when the vehicle is not operating normally.

6. The cloud-edge collaborative scheduling system for airports according to claim 1, characterized in that, Also includes: The maintenance work order module is used to integrate the vehicle's hardware health indicators, emergency stop alarm records, and mileage data, and generate maintenance work orders with different priorities.

7. The cloud-edge collaborative scheduling system for airports according to claim 1, characterized in that, Also includes: The closed-loop operation and maintenance module is used to generate operation and maintenance work orders based on the vehicle's fault codes, emergency stop frequency, sensor obstruction, wheel set temperature, battery health, passenger complaints and mileage, and adjust the subsequent dispatch strategy for the vehicle based on the operation and maintenance work orders.

Images