User role definition

The system shall provide functionality for three basic roles of users: functional requirements shall be defined for these roles using use case analysis.

The tourists are C-end users and are the main recipients of services. They have basic needs such as browsing and searching scenic spots and packages through the WeChat mini-program, placing orders and making online payments through QR code scanning (with WeChat Pay support), and scheduling or instant triggering of aerial photography services, viewing real-time drone flight footage, push notifications on task status, and viewing, downloading, and sharing aerial photography products generated by AI.

The scenic area operators are B-end users, who will take care of the operational management in their respective area. They need to create, edit, and manage the availability of packages and attraction information, register drone hangars and equipment and monitor status and set up maintenance, plan, test, and publish preset flight routes, query order information and export statistical reports, and browse and manage the aerial footage library.

Platform-level operations and maintenance are the responsibility of system administrators. Their basic features are user permission management, user role management, setting system parameters, monitoring services, auditing logs, and handling exceptions and alerts.

It is an end-to-end service, that is, it is activated at the occurrence of a user or system event and has four different phases. During the ordering and payment phase, tourists choose the package, make an order, and the order is initially in unpaid state, after receiving the WeChat Pay call-back, the order is paid and can be scheduled. During the scheduling phase, paid orders are placed in a scheduling queue and then the scheduler assigns a real drone instance to each order based on drone availability, battery margin, and proximity. During the aerial execution phase, the drone used on the mission is launched, the flight path is flown and the drone finally lands, while flight telemetry and status updates are streamed back in real time. During the delivery phase, raw footage is uploaded, the post-production process is completed and the product is delivered to the user. In the implementation part, a formal state machine for the order lifecycle, with explicit transition rules and recovery paths, will be introduced later. This is a plain language description that contains enough information to describe the business logic at the requirements level.

Overall system architecture design

Layered architecture design.

The system is of a classic four-layer distributed microservice architecture, as shown in Fig 1.

Download:

• PNG
  larger image
• TIFF
  original image

Fig 1. A diagram of a distributed microservice architecture with four layers.

https://doi.org/10.1371/journal.pone.0343832.g001

There are a number of components in the Presentation Layer. The WeChat Mini-Program, based on the Uni-app framework, is the C-end user access point that can be deployed across platforms. The Backend Management System is built on Vue.js and Element UI as the B-end management console. The API Gateway, built with Spring Cloud Gateway, is for unified request routing, authentication, and rate limiting.

The Business Service Layer is a microservice cluster developed using Spring Boot 2.x, with the responsibilities of each service detailed in Table 1.

Download:

• PNG
  larger image
• TIFF
  original image

Table 1. Microservice responsibility definitions.

https://doi.org/10.1371/journal.pone.0343832.t001

There are a number of important components in the Hardware Access Layer. The EMQ X-based MQTT Broker guarantees reliable transmission at QoS levels 1 and 2. The GCS Gateway is a ground control station communication gateway, which parses and converts the MAVLink protocol. Real-time video stream forwarding relies on the Streaming Service, which is based on SRS.

The Data Layer comprises different storage options. MySQL 8.0 is used to store structured business data and high availability is achieved through master-slave replication. Redis 6.x offers distributed caching and distributed lock services to provide hot data access and atomicity of the scheduling. Drone telemetry data is semi-structured and stored with MongoDB. Object Storage Service is utilized for storing large quantities of raw aerial footage and finished products.

Data model design

The basic data entities and their relationships in the system may be represented as:

(1)

where is the entity set, is the relationship set, and is the attribute mapping. The basic entities are defined as follows.

The User entity is defined as:

(2)

The Order entity is defined as:

(3)

The Drone entity is defined as:

(4)

The ComboMeal entity is defined as:

(5)

The relationships between entities can be expressed as:

(6)

FSM-based order lifecycle management

Formal definition of the state machine.

As the core business entity of the system, order lifecycle management is modeled using a Deterministic Finite Automaton. We adopt a formal DFA model here, rather than the plain-language description used in the requirements section, because the implementation must guarantee atomicity and consistency of state transitions under concurrent updates; without an explicit transition function it is not possible to specify which event sequences are legal and which must be rejected. The formal definition is as follows.

The order state machine is defined as a quintuple:

(7)

where Q represents the set of states containing , , , , , , , , , , and . The symbol denotes the event alphabet including , , , , , , , , , and . The function represents the state transition function. The initial state is , and the set of final states is .

State transition function.

The key rules of the state transition function are defined as follows:

(8)

The complete state transition diagram is illustrated in Fig 2(a), and the operational reliability metrics are shown in Fig 2(b).

Download:

• PNG
  larger image
• TIFF
  original image

Fig 2. FSM-based order lifecycle management:

(a) Order lifecycle state machine with transition probabilities showing all possible states and events; (b) State transition success rate over a 30-day operational period demonstrating system reliability above the 97% target threshold.

https://doi.org/10.1371/journal.pone.0343832.g002

Transaction guarantees for state transitions.

To ensure atomicity and consistency of state transitions in a distributed environment, the system employs an optimistic locking mechanism based on Compare-And-Swap:

(9)

The integrity constraint for state transitions is expressed as:

(10)

where represents an invalid transition, which the system should reject while logging an exception.

In practice, the dominant operational failure mode is not unknown states but duplicate events arriving from retry mechanisms (payment callbacks, MQTT redelivery at QoS 1/2). The combination of an explicit transition function and version-based optimistic locking ensures that duplicate events are idempotent: a second arriving after the order has already moved to leaves the state unchanged, because is undefined and rejected. This idempotency property is the main practical justification for the DFA formalism, and is the reason simpler ad-hoc status flags were rejected during design.

Multi-objective optimization scheduling algorithm for heterogeneous drones

Problem formalization.

The drone task scheduling problem can be formalized as a constrained optimization problem. Let the set of orders to be scheduled be , the set of available drone resources be , and the scheduling decision variable matrix be , where indicates that order is assigned to drone .

The multi-objective scheduling optimization problem is defined as:

(11)

The objective functions are decomposed as follows. Objective 1 minimizes response latency:

(12)

where is the estimated response time for drone to service order .

Objective 2 maximizes resource utilization:

(13)

Objective 3 maximizes service reliability:

(14)

where is the historical task success rate of drone .

Scheduling scoring function.

The full multi-objective formulation above is well suited to offline batch scheduling, but in our deployment scheduling decisions must be made within a single user-facing request cycle, i.e., within tens of milliseconds. Solving the constrained multi-objective program exactly at this latency budget is impractical for the fleet sizes targeted in scenic-area deployments. We therefore adopt a weighted scalarization: the three objectives are mapped into interpretable per-drone sub-scores, combined linearly, and the highest-scoring valid drone is selected greedily. This sacrifices Pareto-optimality for tractability and interpretability, which we argue is the correct trade-off for online consumer scheduling.

In real-time scheduling scenarios, the system employs a weighted scoring function for rapid decision-making. For order and candidate drone , the scheduling score is calculated as:

(15)

where the weight coefficients satisfy , and the sub-scoring functions are defined as follows.

The battery awareness function is defined as:

(16)

where is the current remaining battery level, is the safe threshold battery level typically at 30 percent, and is the full battery capacity.

The spatial distance decay function is defined as:

(17)

where is the Euclidean distance between the task starting point and the drone current position:

(18)

The parameter controls distance sensitivity. In experiments, with distance measured in meters.

The device reliability function is defined as:

(19)

where is the number of successful tasks, is the total number of tasks, is the indicator function, and is the most recent heartbeat time interval.

Fig 3(a-b) shows a visualization of the scheduling score function’s behavior to illustrate how battery level and distance affect assignment decisions. Weight sensitivity analysis (Fig 3(c)) displays the corresponding weight priority settings to the corresponding scheduling results and Fig 3(d) shows a representative scheduling decision scenario.

Download:

• PNG
  larger image
• TIFF
  original image

Fig 3. Multi-objective scheduling algorithm visualization:

(a) 3D surface plot of scheduling score as a function of battery level and distance; (b) Contour map illustration of the regions of optimal scheduling scores in terms of high battery and low distance; (c) Weight sensitivity analysis to show the effect of different priority configurations on the scheduling scores; (d) Scheduling decision visualization with drone fleet distribution and optimal assignment selected.

https://doi.org/10.1371/journal.pone.0343832.g003

Design of real-time communication protocol using MQTT

Communication architecture.

The system uses MQTT protocol for the bi-directional real-time communication between cloud scheduling service and ground control stations. The MQTT publish/subscribe paradigm is well suited to the command dispatch and telemetry data reporting cases where one-to-many communications are required.

The communication topology structure is:

(20)

Topic design specification.

Table 2 shows that the topics of MQTT are designed to have a hierarchical structure, so as to route the message and implement access control.

Download:

• PNG
  larger image
• TIFF
  original image

Table 2. MQTT topic design specification.

https://doi.org/10.1371/journal.pone.0343832.t002

Message reliability guarantees.

In order to make sure that the important instructions are transmitted reliably, the following mechanisms are used.

For QoS level selection:

(21)

The above QoS assignment isn’t random. Safety-critical commands (takeoff, land, return-to-home) are exactly-once, meaning that duplicated commands (after a successful landing) are a flight-safety hazard and lost commands (land) are unacceptable; hence, they are using QoS 2. Telemetry and status messages have QoS 1 (at-least-once) because the consumer side doesn’t care about duplicate messages and they’re not lost, but the operator would be lacking in situational awareness if they were lost. The reasoning behind using QoS 0 is that heartbeats are sent at fixed intervals and when one is lost, the next heartbeat is sent naturally, and it would not improve the operation to pay to send a QoS 1 or 2 heartbeat.

With regard to the timeout retransmission mechanism:

(22)

where and .

The entire communication sequence is shown in Fig 4(a) and the distribution of message latency is shown in Fig 4(b), which shows that all types of messages are complying with the 50 ms SLA.

Download:

• PNG
  larger image
• TIFF
  original image

Fig 4. MQTT-based real-time communication analysis:

(a) The message sequence diagram of the whole communication between the client, cloud server, MQTT broker and ground control station in the four operational phases; (b) The distribution of message latency by type, where all categories of messages are compliant with the SLA of 50 ms.

https://doi.org/10.1371/journal.pone.0343832.g004

Automated video production pipeline

Pipeline architecture.

Upon receipt of aerial footage, the system automatically triggers the post-production pipeline to achieve capture-to-delivery automation. The pipeline comprises four sequential stages:

(23)

In what follows we draw an explicit distinction between two qualitatively different computational components of this pipeline. The quality filtering stage is a transparent rule-based score combining three interpretable visual features (sharpness, exposure, motion blur); it is not a deep learning model. The semantic matching stage in the editing step does use a pre-trained vision encoder to compute similarity between footage segments and template slots, and is the only stage that warrants the term “AI-powered”. We adopt this terminology consistently throughout this paper to avoid overstating the role of machine learning in the pipeline.

The pipeline architecture is depicted in Fig 5(a). The quality filtering effectiveness is demonstrated in Fig 5(b), and the processing time distribution is shown in Fig 5(c).

Download:

• PNG
  larger image
• TIFF
  original image

Fig 5. Automated video processing pipeline:

(a) Four-stage pipeline architecture comprising ingestion, rule-based quality filtering, learned semantic matching and editing, and final rendering; (b) Frame quality score distribution before and after filtering, demonstrating 40% rejection rate at the quality threshold; (c) Processing time breakdown showing render stage dominates at 55.8% of total processing time.

https://doi.org/10.1371/journal.pone.0343832.g005

Video quality assessment model.

The footage filtering stage uses a lightweight, no-reference frame quality score that combines three interpretable visual features into a single weighted index. We deliberately avoid a learned end-to-end CNN at this stage for three reasons: (i) the filter must run at video frame rate on the inference node without saturating the GPU that is reserved for downstream rendering; (ii) the features below are well established in the image-quality literature and remain reliable under the lighting conditions typical of outdoor scenic flights; and (iii) interpretability matters operationally, because reviewers and operators need to understand why a frame was rejected. A learned model is reserved for the downstream semantic matching stage, where richer perceptual features are required. The three component features are defined as follows.

Sharpness assessment is based on the variance of the Laplacian operator:

(24)

Exposure assessment is based on histogram distribution:

(25)

where is the mean frame brightness value.

Motion blur detection is based on optical flow estimation:

(26)

The three features are normalized to [0,1] and combined into a single weighted quality index:

(27)

The weights , , and were tuned empirically on a held-out set of scenic-area footage. The resulting index is a transparent weighted score, not a deep network. This design also makes it straightforward to audit individual rejection decisions, which is desirable when operators need to explain quality decisions to scenic-area customers.

Intelligent editing algorithm.

The editing stage employs a scene semantic matching algorithm to match filtered footage segments with preset editing templates. Let the set of footage segments be and the set of template slots be . The matching problem is formalized as:

(28)

The semantic similarity Sim(c, t) is computed based on feature vectors from a pre-trained vision model:

(29)

where is the feature embedding vector of the footage segment.

Final product quality evaluation.

The comprehensive quality evaluation function for the final product is defined as:

(30)

where represents the frame-level visual quality score, represents the footage-template semantic matching degree, represents the audio-visual synchronization score, and the weight coefficients , , satisfy .

Experimental environment configuration

Experiments were conducted in the software and hardware environment specified in Table 3.

Download:

• PNG
  larger image
• TIFF
  original image

Table 3. Experimental environment configuration.

https://doi.org/10.1371/journal.pone.0343832.t003

It is important to clarify that the 8-core, 16 GB cloud instance listed above refers to the centralized cloud tier shared across multiple scenic sites, not to a per-site requirement. A single scenic deployment hosts only the local MQTT bridge, the GCS gateway process, and a video forwarder, all of which run comfortably on a 4-core, 8 GB edge box. The cost and scalability implications of this separation are discussed quantitatively in the deployment-footprint analysis later in this section.

Functional verification testing

Complete end-to-end testing was conducted on the system core business processes, with verification results shown in Table 4.

Download:

• PNG
  larger image
• TIFF
  original image

Table 4. Functional test results summary.

https://doi.org/10.1371/journal.pone.0343832.t004

Performance stress testing

Test results.

Key performance metrics are shown in Table 5.

Download:

• PNG
  larger image
• TIFF
  original image

Table 5. Performance test results.

https://doi.org/10.1371/journal.pone.0343832.t005

Two aspects of Table 5 require emphasis to correctly interpret Fig 6 and the discussion that follows. First, the 200 ms SLA referenced in Fig 6(b) applies to average response time, not P99 tail latency: all three interfaces remain below this average-latency threshold up to 500 concurrent users, and order creation approaches it only near 1000 users, even though scheduling assignment and order creation reach 312 ms and 245 ms respectively at P99. Second, the P99 values in Table 5 are the most stringent latency figures reported in this paper and should not be conflated with the average response times plotted in Fig 6(b).

Download:

• PNG
  larger image
• TIFF
  original image

Fig 6. System scalability and performance analysis:

(a) Throughput scalability showing QPS growth patterns for different API interfaces under increasing concurrent users; (b) Latency degradation curves demonstrating average response time remains below the 200ms SLA target up to 500 concurrent users; (c) Resource utilization trends for CPU and memory, both remaining below the 80% warning threshold; (d) Throughput-latency trade-off scatter plot revealing the operating characteristics of different interfaces.

https://doi.org/10.1371/journal.pone.0343832.g006

Fig 6 comprehensively analyzes the scalability characteristics. As illustrated in Fig 6(a), throughput increases in a linear fashion with the number of concurrent users. Fig 6(b) shows that latency is kept in SLA limits, and Fig 6(c) shows that the utilization of resources is kept below critical limits. The throughput-latency trade-off in Fig 6(d) shows the system’s operation envelope.

Efficiency comparative analysis

This system has been compared with the manual aerial photography modes and the result is shown in Table 6.

Download:

• PNG
  larger image
• TIFF
  original image

Table 6. Efficiency comparative analysis.

https://doi.org/10.1371/journal.pone.0343832.t006

The cost reduction rate (computed using the bottom of the traditional cost range and the lowest point on the system cost range, the most conservative range) is computed as:

(31)

To complete the picture, the maximum of the traditional cost (3000 CNY) and the minimum of the system cost (50 CNY) is a reduction of approximately 98.3%, and even the worst combination within the system’s range (3000 CNY vs. 100 CNY) is a reduction of approximately 96.7%. The “over 90%” value in the abstract and in Table 6 is not a mid-range or best-case statement, but rather the most conservative lower-bound estimate and applies to all of the locations within the paper. The efficiency improvement factor (once again calculated based on a lower limit for the traditional cycle time, 24 h, and a representative time of system delivery, 20 min) is:

(32)

As a comparison, the worst case to the worst case (72 h 30 min) results in a factor of 144, while the best to the best (24 h 15 min) is a factor of 96. The “over 99% reduction” therefore in Table 6 should be understood as a summary of a range of values across the entire distribution of conventional delivery cycles, and even the most conservative value among the reductions paired in the above equation is already more than 98.6% reduction.

Deployment footprint, scalability, and amortisation of infrastructure cost

The service-level cost and latency performance shown in Tables 5 and 6 does not include the cost of the system itself, as well as the associated computational and energy cost, and a more complete accounting would confirm a real reduction in cost, not a simple shift of cost into hidden infrastructure. This is where we come in.

Per-site computing scale. The 8-core, 16 GB cloud instance reported in Table 3 is the centralized cloud tier and is shared across multiple scenic sites. A single scenic deployment hosts only one MQTT bridge, the GCS gateway process, and a local video forwarder; in our measurements these components run comfortably on a 4-core, 8 GB edge box, and local CPU is bounded by the streaming forwarder rather than by scheduling. Per-site hardware cost is therefore small and largely independent of fleet size within the practical fleet sizes (up to about eight drones per site) we have tested.

Scaling down for low-traffic sites. For low-traffic deployments serving fewer than approximately 50 orders per day, the post-production pipeline can be migrated from a Tesla T4 to a CPU-only inference container, at the cost of a roughly five to seven times slowdown in the rendering stage; the rule-based quality filter does not require a GPU at all. Sites that share a regional rendering pool incur GPU cost only when actively rendering, so the marginal cost of adding a new site is dominated by network and storage, not compute.

Scaling up: multiple drones per site sharing one ground station. As clarified above, the 1000-concurrent-user stress test exercises cloud APIs, not GCS links. We separately verified that a single ground-station host sustains eight simultaneous drone MQTT sessions at QoS 1 without exceeding 30% CPU on a commodity 4-core box. This is the relevant capacity figure for scenic-area operators who deploy a small fleet behind one ground station.

Infrastructure cost amortization. Taking the cloud tier (approximately 1,200 CNY per month for the ECS instance plus storage and bandwidth) and amortizing it over the demonstrated capacity of at least 100 orders per site per day, the marginal infrastructure cost per delivered service is on the order of a few CNY, well below the 50–100 CNY service price. Electricity for the drone fleet (battery charging at the hangar) and for the cloud tier is similarly negligible at the per-service level once aggregated. These figures support the cost-reduction claim in Table 6: the headline saving is not an artefact of moving costs into hidden infrastructure, but reflects a genuine elimination of per-order pilot labour.

Robustness testing

System robustness was verified against exceptional scenarios, as shown in Table 7.

Download:

• PNG
  larger image
• TIFF
  original image

Table 7. Robustness test results.

https://doi.org/10.1371/journal.pone.0343832.t007

Addressing the accessibility gap in consumer drone services through microservices architecture

The results of the experiments carried out in this study show that the proposed microservices-based architecture successfully alleviates the three key pain points of UAV aerial photography services, which until now have hindered the democratisation of the industry, namely high cost, long delivery times, and high operational barriers. Our system reduced the cost of service from 500 to 3000 CNY to 50–100 CNY (under the most conservative lower-bound pairing reported in the previous section) and the delivery time from 24 to 72 hours to 15–30 minutes, while completely eliminating the need for professional pilot intervention.

These improvements will be a huge improvement over the current consumer drone service models. The conventional aerial photography industry is ill-suited for smooth delivery of the services, as it requires complicated scheduling of the tourists, aerial photography professionals and post-production teams, as documented by [30], creating substantial friction in the service delivery chain. Commercial platforms offer more advanced fleet management features, but are primarily targeted to enterprise users rather than end users and feature a higher level of complexity which makes them less intuitive to use [15]. The experience of our scan to use paradigm, with a WeChat mini-program frontend, is drastically reduced from 8–10 steps to 3 steps: scan, pay, receive.

This was largely because of the architectural design of microservices not monolithic design. The decomposed service architecture allowed us to scale resource-intensive services such as AI processing and video streaming without impacting the core business logic, something that couldn’t be achieved in the existing UAV management systems as all the services were tightly coupled [16]. This is in line with the architecture principles of [1], who believe that microservices are useful for technical agility and organisational scalability. Moreover, the order lifecycle management based on FSM was deployed to facilitate the deterministic transition between orders, and explicitly define the limits of error management and handling, which are the issues in previous UAV software systems [17].

Theoretical contribution

With the exception of the engineering solution to the smart tourism problem, the contributions in this paper are threefold and can be traced directly to the corresponding implications in the Conclusion. It takes the microservice paradigm from software domains to a domain that combines cloud services with airborne hardware in real-time and safety-critical situations, the resulting reference architecture reveals that the basic decomposition principles remain valid, but transactions have to be explicitly controlled by state-machine control to maintain consistency across the cloud–edge boundary. It offers an empirical result that linear scalarisation of multi-objective scheduling, while theoretically suboptimal with respect to Pareto-front methods, is operationally sufficient for online consumer scheduling as it is interpretable, auditable, and allows for the sub-second latency required by user-facing requests. In this work, the authors explicitly separate the two stages of the post-production pipeline: the rule-based quality-filter (RF) and the learned semantic-matcher (LM). The authors argue for using the word “AI-powered” with greater restraint in system papers, and place the LM stage in the post-production pipeline only where the accuracy benefit of the learned stage outweighs its computational and interpretability costs. When combined, the three make up a design pattern that can be reproduced in other service-oriented systems connecting cloud software and real-world hardware.

Performance validation and comparative analysis with existing UAV platforms

The performance evaluation results have given empirical proof of the technical feasibility of microservices architecture for consumer-facing UAV service platforms. The average response time for order creation was 89 milliseconds at 523 QPS under simulated high-concurrency conditions, significantly better than the 500 milliseconds or more latencies typically reported for cloud-based drone management systems [13]. The P99 latency for order creation was 245 milliseconds and for scheduling assignment was 312 milliseconds, which is well under the 400 milliseconds that is generally perceived as instantaneous by users for interactive consumer applications [34]. Throughout this paper, the 89 ms figure and the 245 ms/312 ms figures refer to different statistics: average response time and P99 tail latency, respectively. These two measures are not interchangeable and should be interpreted in the context of the SLA definition stated above.

Due to the complexity of the multi-objective optimization algorithm, the scheduling service showed excellent performance with 389 QPS under 0.05 percent error rate. This reliability can be explained by a distributed locking mechanism, which is based on Redis and is able to effectively serialize conflicting resource allocation requests. Our weighted scoring approach, defined in Equation 15, has been compared to the scheduling algorithms mentioned in the UAV literature and has been shown to offer comparable quality of assignment to computationally heavier scheduling algorithms with only O(n) time complexity, which is suitable for real-time decision-making [18].

The robustness testing results also confirm the fault-tolerant design principles incorporated in the architecture. The system passed all five exception scenarios tested, such as GCS network disconnection, payment callback timeout and failure of the database master node. This fault tolerance and resilience is consistent with the fault isolation properties of microservices architecture highlighted by [4], which can prevent failures in one service from impacting overall system availability. The graceful degradation and circuit breaker patterns in the AI service pathway mean that users will still be able to access raw footage even if intelligent editing is temporarily unavailable, ensuring service continuity over the completeness of the feature.

How automated video processing is helping with service automation

One of the innovations that distinguishes our system from other UAV service systems is the automated video processing pipeline. The traditional aerial photography workflow has 2–4 hours of manual post-processing per flight session, which greatly limits the service throughput and cost reduction [19]. Our automated pipeline on quality assessment, intelligent filtering and template-based editing reduces it to a matter of few minutes of processing time, with minimal human intervention.

An interesting issue in automated video curation is that there are no reference images to compare and verify the technical quality of the footage, which is solved by the no-reference frame quality score on which the footage is filtered. As stated in the implementation part of the paper, this score is not a learned neural network, rather it is a simple weighted index of several features, and the terms used throughout this paper are reflective of that. Our composite quality function is designed following the principles of computational photography [35], is still efficient in terms of computation to be able to operate in real-time, and most importantly, is also interpretable by the operator so he can explain the individual rejection decisions. There is a learned component to the semantic matching algorithm for template-based editing. It can leverage vision encoders that are available to implement content-aware clip selection. This guarantees aesthetically consistent output clips when no domain-specific training data is available.

It is important to note, however, that AI tools’ current capabilities impose limitations on creativity. The template-based method ensures the uniformity of output quality but it has disadvantages in terms of personalization in comparison to human editors. Future applications could involve the use of large language models to generate the video’s script and enable a multimodal understanding to guide content creation based on user preferences, as demonstrated in recent video synthesis research [36].

Implications for smart tourism digital infrastructure

Not only does the KanYiKan system have great potential as an aerial photography service, but it also has a wide range of implications for the development of smart tourism sites. Smart tourism ecosystems must rely on seamless technology platforms to enhance the tourist experience and generate valuable data to help manage the destination, as [26] and [27] have described. Our system fits into this vision because it is capable of providing a replicable template for deployment of automated services to consumers in scenic areas.

The decoupled service design, event-driven communication with the use of MQTT, and FSM-based workflow management patterns created as part of this research can easily be replicated in other similar smart tourism applications such as autonomous tour vehicles, intelligent guide systems, and personalized recommendation systems. Of particular interest with microservices is the integration with the ecosystem, with the ability to ensure seamless interoperability with existing destination management systems, social media, and third-party content distributors, thanks to the use of standard APIs [29].

Furthermore, the aerial images created with our system can be used for further purposes, for example in virtual and augmented reality, in the creation of UGC content, or as virtual tourism. The built-in automatic social sharing function of the WeChat mini-program is a natural feature, and sharing can be seen as an important behavior of modern tourism [32,33].

Limitations and future research directions

The results are promising but there are some caveats that need to be addressed and may suggest further research.

As regards flight path constraints, the current system has only pre-programmed flight paths, and no real-time flight path planning and obstacle avoidance. This design makes it easy to meet regulations and will provide a predictable flight path, but for a price: it will not be as flexible in adapting to changing environmental conditions. Future research needs to focus on integration of SLAM-based visual navigation and sense-and-avoid systems to allow more flexible operations [37]. Until onboard sense-and-avoid is integrated, the present system should only be deployed in those cases where the pre-programmed routes can be determined to be safe: a single scenic area, daylight-hours operation only, and routing which avoids crowding in non-public settings are examples of such cases.

As far as regulatory integration is concerned, there is currently no connection between the system and Unmanned Traffic Management systems or civil aviation authority databases which provide airspace authorization in real time. Seamless UTM integration will be a key component of legal and viable commercial operations at scale as low-altitude economy regulations mature [38]. In the future, we will be using standardized UTM APIs in the development process.

As for privacy protection mechanisms, the current implementation lacks automated privacy filters on-pipeline like face blurring, license plate obfuscation, or no-fly polygon enforcement around sensitive sub-areas of a scenic region [39]. We treat this as a substantive limitation rather than a minor omission: in any production deployment of consumer drone services in public space, the absence of such filters is both an ethical concern [39] and an emerging regulatory liability. The architectural placement for these filters is already defined in our pipeline: the quality-filtering stage is the natural insertion point for face and license-plate detectors, and the route-planning stage is the correct insertion point for geofenced privacy zones. Concretely, we plan to integrate (i) an on-device face and licence-plate detector running before footage upload so that raw identifiable frames never leave the GCS, (ii) operator-configurable privacy polygons that the route planner treats as hard constraints, and (iii) an audit log linking every delivered clip to the privacy-filter version that processed it, so that compliance can be verified after the fact. Until these mechanisms are integrated and independently audited, deployments of the present system should be restricted to scenic settings with explicit signage and consent, and should avoid flight paths over private dwellings or crowds in non-public contexts.

Regarding evaluation scope, performance testing was conducted using simulated workloads rather than actual tourist traffic, and the deployment was limited to a single scenic area. Multi-site validation across diverse geographic and operational contexts is necessary to establish generalizability. We also note explicitly, as a specific limitation, that the present manuscript does not report a quantitative user-satisfaction study. Although informal qualitative feedback was collected during the pilot deployment, a controlled evaluation using validated instruments such as the System Usability Scale (SUS) and the Technology Acceptance Model (TAM3) is required before claims about accessibility improvements can be considered empirically established. We have correspondingly avoided such claims in the present manuscript, and this study is the immediate next step in our research programme.

In the aspect of single drone scheduling, the existing scheduling algorithm is based on maximizing the individual drone scheduling without taking multi-UAV cooperative scheduling into account. Formation flight coordination and collaborative coverage algorithms should be studied in the case of larger-scale deployments [40].

Reproducibility and open science considerations

To ensure transparency and reproducibility of research, we have carefully designed the architecture to enable extension and replication of this work. The complete back-end technology stack consists of popular open-source frameworks, such as Spring Boot for building microservices, Redis for caching and distributed coordination, RabbitMQ and EMQ X for message queuing, and TensorFlow for deployment of AI models. In this manuscript, detailed configuration parameters, FSM transition rules, and the scheduling scoring function have been completely specified.

The system architecture diagrams, API endpoint specifications, and algorithm pseudocode provided herein are sufficiently detailed to be implementable independently. However, some parts will not be disclosed for privacy reasons: information on users’ interaction with the system is personally identifiable and the trained video quality assessment model includes proprietary scenic area footage. We are investigating how to make synthetic datasets and anonymised API documentation available publicly to also help with reproducibility, while maintaining privacy requirements.

Implications for theory

From an architectural perspective, this work advances the microservice architecture paradigm from its well-known domains (e-commerce or enterprise SaaS) to a cyber-physical service domain where, in addition to coordinating software components, the back-end is required to coordinate airborne hardware with real-time and safety requirements. The three implications below are direct elaborations of the theoretical contributions mentioned in the Discussion. Using optimistic-locking transitions, deterministic finite-state machines are sufficient to achieve workflow consistency in a microservice system spanning cloud, edge, and embedded tiers; they do not require richer formalisms like Petri nets or process algebras, and the same decomposition principles that apply to conventional cloud-only microservices carry over once this transactional state-machine layer is added. Multi-objective scheduling for heterogeneous devices does not have to be globally optimal to be operationally adequate: a linear weighted score over easily-interpreted features such as battery, distance, and reliability provides sufficient assignment quality at O(n) cost, which has implications for any service domain in which assignment must be made within a single user-facing request cycle. The distinction between the lightweight rule-based quality filter and the learned semantic matcher also represents a more general design principle for AI-augmented pipelines: learned components should be reserved for the stages in the pipeline where their accuracy advantage is worth the computational and interpretability cost.

Implications for practice

For service providers developing low-altitude economy services, the key takeaway is that it is quite possible to meet the consumer-facing latency budget (sub-400 ms average ordering response time and sub-second status update response time, with P99 tails of approximately 312 ms as reported in Table 5) with off-the-shelf components (Spring Boot, Redis, MQTT, OSS), provided the order lifecycle is explicitly modelled as an FSM and the GCS link uses publish/subscribe semantics with per-message QoS. The over-90% cost reduction per service reported here is not a marketing figure: under the most conservative pairing of price ranges it is exactly 90%, and under the worst-case-to-best-case pairing it rises to 98.3%, both of which follow directly from removing the pilot from the per-order critical path. This in turn is only possible once scheduling, flight, and post-production are all automated and connected by an event-driven backbone. Scenic-area operators considering adoption should focus their procurement on standardizing hangars, routes, and consent signage; the software stack itself is reproducible with commodity components, and the per-site computing footprint is small.

Key lessons learned

Based on the design and operation of this system, there are three lessons that we feel are applicable to other situations. First, state explosion is not averted by introducing additional states, but by making the transitions transactional and idempotent: the predominant operational failure modes were not unknown states but duplicate events generated by retry mechanisms, and the combination of a DFA-style transition function with version-based optimistic locking was the simplest defence that worked. Second, the most difficult engineering boundary is not internal but is the cloud–GCS link; investing in MQTT QoS tuning, heartbeat policy, and offline-replay buffers paid back disproportionately compared to in-cloud optimization. Third, calling a weighted three-feature score “AI” obscures rather than clarifies the design; in revising this manuscript we explicitly relabelled such components, and we recommend that future system papers in this area do the same so that the role of machine learning in pipelines is communicated accurately.

Limitations of this research

The present study has four principal limitations that bound the generality of its claims. First, the deployment was confined to a single scenic area, so the cost and latency figures should be regarded as a proof of concept and confirmed by multi-site replication. Second, the system supports only pre-programmed routes; dynamic path planning and onboard sense-and-avoid remain future work and limit applicability in complex airspace. Responsible deployment is therefore currently restricted to single scenic-area settings where routes can be surveyed in advance, daylight-hours operation, and paths that avoid crowds in non-public contexts. Third, automated privacy filtering is not yet integrated into the pipeline, so responsible deployment is currently restricted to settings with explicit signage and consent. Fourth, no quantitative user-satisfaction study using validated instruments has yet been conducted; user-experience claims in this paper therefore remain provisional. These four items define our immediate research roadmap.

Outlook

Looking forward, the architectural patterns documented here, namely microservice decomposition, FSM-driven workflows, lightweight multi-objective scheduling, and tiered post-production pipelines, are in our view transferable to a wider class of low-altitude services beyond aerial photography, including autonomous inspection of public infrastructure, on-demand emergency response imaging, and short-range last-50-metre delivery. The contribution of this paper is therefore not only the KanYiKan system itself, but also the demonstration that the low-altitude economy can be served by mainstream cloud-native software practices, provided that those practices are adapted with care to the real-time, safety-critical, and privacy-sensitive characteristics of airborne hardware.