ACCORD: A Formal Model for the Digitalization and Automation of Drone Coordination Processes

Abstract

This paper introduces ACCORD, a support platform designed to digitalize and automate the coordination processes required by the current drone regulatory framework. Drone operators must complete several coordination actions with both aeronautical and non-aeronautical entities. Traditional aeronautical coordination actions relate to the need to access protected airspace volumes around airports. Additional coordination should be established with smaller aeronautical infrastructures, like small aerodromes and heliports, which are not surrounded by any type of pre-defined airspace. Therefore, drone-specific protection volumes have been created. ACCORD enables a single entry point for all the necessary coordination processes for drone operators and infrastructure managers. The objective is to minimize the number of required actions, guarantee full traceability of the process, maximize access to the relevant information, automate the processes as much as possible, and maintain a high level of flexibility to support all coordination processes. After coordination is established, it moves from the strategic/planning phase to the actual execution phase. ACCORD also enables a communication mechanism between the drone operators and the aeronautical infrastructures to extend the coordination to the actual mission execution. ACCORD is currently being tested by some of the most relevant actors in the Catalan drone ecosystem. The current version of the system provides support for all types of aeronautical infrastructures (heliports, aerodromes, and airports) and management duality for situations in which the infrastructure manager and the aeronautical service provider coexist.

1. Introduction

Within the current European regulatory context, Commission Implementing Regulation (EU) 2019/947 [1] by EASA, and based on the future definition of U-space airspace [2,3], drone operators must take numerous actions before any intended flight can be fully authorized [4]. Among other requirements, drone operators must take into consideration the potential existence of so-called geographical zones. Geographical zones [5] are volumes of airspace in which drone operations may be permitted, restricted, or excluded for reasons of public safety, protection of infrastructure and other airspace users, or protection of privacy and the environment. Each EU country should provide detailed implementation of the general EASA provision.

Within the Spanish context, the Royal Decree 517/2024 [6] governs the use of airspace by drones. Geographical zones in the national definition are designed to protect, among other things, aeronautical infrastructures, natural parks, and other ground infrastructures. A drone operation within aeronautical-related geographical zones requires actions to establish coordination with both aeronautical and non-aeronautical entities. Coordination with aeronautical entities is generally well established and derives from the modus operandi of manned aviation. However, the low-level nature of drone operations implies that flights may also interact with other locations or infrastructures outside the aeronautical domain.

The most traditional aeronautical coordination actions are directly related to the need to access protected airspace volumes. Such coordination is generally established with the Airspace National Service Provider (ANSP) or with airport service providers and relates to the conditions required to gain access to managed airspace.

Additional forms of coordination have been introduced to protect smaller aeronautical infrastructures, like small aerodromes and heliports. Generally, these infrastructures are not surrounded by any type of pre-defined airspace, and therefore specific airspace volumes have been created to protect them from drone operations (which varies depending on the country).

Beyond aeronautical infrastructures, a long list of ground areas and other infrastructures also require some protection (see Figure 1). The exact types of protection procedures associated with these areas are strongly dependent on the country and its administrative organization; these may include, for example, critical infrastructures (associated with energy production, petrochemical plants, etc.), ground and sea transportation infrastructures (roads, railways, bridges, harbours, etc.), urban environments for public safety, and environmental areas to be protected under the Natura 2000 network (Section 8 will detail the Spanish geographical area definitions associated to aeronautical infrastructures).

In addition to the pre-flight coordination, regulations requires drone operators to notify the daily initiation and finalization of their activity. In some cases, when within controlled airspace, this will imply the need to fill out a flight plan to be activated and end daily, with additional phone calls or frequency notifications to indicate that the flight has been initiated, completed, or temporarily paused.

Over the years, AESA (Agencia Estatal de Seguridad Aerea), the aeronautical safety agency in Spain, has produced regulations and guidelines to reduce and simplify the required coordination processes [6]. However, even though some simplifications have been successfully introduced, the coordination processes remain strenuous for both drone operators and the public and private entities managing them.

The complexity of the various coordination scenarios depends strongly on national and regional regulations and the organization. Back in 2023, both drone operators and infrastructure managers in Catalonia (Spain) approached UPC, raising concerns about the coordination processes in place and wondering whether alternatives existed to alleviate the burden of the process. Several issues were identified as critical bottlenecks by drone operators to carry out the legally binding coordination process efficiently, e.g., managing multiple coordinations simultaneously, managing coordinations with the Nature 2000 network, improving communication mechanisms, and avoiding using paper documentation.

At the same time, entities at the receiving end of the coordination process (infrastructure managers) also complained about several aspects, e.g., some managers were overwhelmed by the number of requests, others did not receive sufficient administrative support, non-aeronautical organizations did not understand the implications of the process, complex airspace conditions could not be computationally checked, etc.

The current development of the U-space concept is also introducing additional airspace management objects like the ATS.TR.237 Dynamic Reconfiguration of the U-space Airspace (DAR) as per Commission Implementing Regulation (EU) 2021/666 [5], defining the requirements for manned aviation operating in U-space airspace. The DAR concept originates as a strategy to manage parts of U-space dynamically. It allows controlled air traffic to cross a portion of airspace designated as U-space airspace, ensuring segregation is maintained between UASs in U-space and manned aircraft. In that sense, a DAR is a dynamic piece of airspace that does not require explicit coordination and is directly managed by ATC. SESAR, through the AURA and ENSURE projects [7], aims to refine and complete the DAR definition and develop a dynamic airspace configuration service. Air traffic management stakeholders in charge of airspace reconfigurations should employ that service to maintain traffic segregation and to avoid proximity between manned and unmanned aircraft within the designated U-space airspace.

Given the existing complex regulatory context, this paper introduces a support process designed to digitalize and automate most of the required coordination processes. The end goal is to define a single point of entry for all the necessary coordination processes, for both drone operators and infrastructure managers. The process’s objective is to create a digital model of the coordination workflow, minimize the number of required actions, guarantee complete traceability, maximize access to information, automate processes within legal boundaries, and maintain a high level of flexibility to be able to support the broadest possible coordination scenarios.

The overall proposal is built on formalizing the various restrictions that may apply to a coordination process. Restrictions are not only specified by airspace volumes but may also include temporal factors, drone characteristics, operational profiles, etc. Such a formalization enables the natural extension of its scope to new requirements, following a concept similar to object inheritance. Furthermore, the whole coordination workflow is described through several state-transition diagrams, formalizing the various actions required along the coordination process. At each transition step, it is properly defined which stakeholders are responsible for acting and under which circumstances that transition can be carried out automatically, eliminating the need for human intervention, thus significantly improving overall efficiency.

The designed process is currently under test with some of the most relevant actors in the Catalan drone ecosystem, consolidating its implementation. The current version of the process provides support for all types of aeronautical infrastructures (heliports, airfields, and airports) and the management duality associated with infrastructures operating an aeronautical service provider. The process has been implemented within the supporting platform referred to as ACCORD.

The following sections will describe the key elements, workflows, and specification rules that define the proposed coordination process, and they will be organized as follows. Section 2 outlines the current state of the art associated with the coordination requirements in the EU and US. Section 3 will describe the mechanisms employed to organize a request by a drone operator across all required infrastructures and the entities in charge of the coordination process. Section 4 details the different elements that can be employed to describe the coordination conditions associated with an infrastructure and how they are tailored for each specific type currently supported. The dynamics of the coordination evaluation from its initial request until it is finally granted or rejected is described in Section 5. Section 6 and Section 7 outline some interfaces designed to support its users. Section 8 describes the current experimental deployment, while Section 9 provides an initial evaluation context comparing our proposal with current document-based coordinations. Finally, Section 10 concludes the paper and proposes future work.

2. Current State of the Art

Although providing a full review lays outside the scope of this paper, this section will review the state of the art related to the coordination processes limited to the European Union and United States contexts. Even though multiple initiatives exist, most of them focus exclusively on providing context information for the intended operations, except for the US initiative, which extends to providing drone operators with support to interact with infrastructures managed by the airspace service provider. However, none of the identified initiatives provides coordination support to other aeronautical infrastructure operators or other types of geographical areas.

2.1. Coordinations Within the European Union

The European regulatory framework for unmanned aircraft system (UAS) operations, established through Regulation (EU) 2019/947 [1], introduced a comprehensive approach to drone management in European airspace. Article 15 of this regulation establishes that Member States shall define UAS geographical zones based on safety, security, privacy, or environmental considerations. This provision enables Member States to prohibit or restrict UAS operations, establish specific conditions, or require prior authorization in these zones.

The European Union Aviation Safety Agency (EASA) categorizes unmanned aircraft system (UAS) operations based on their associated risk levels. Currently, three distinct categories are utilized, with two corresponding to commercially available vehicles and the third pertaining to certified vehicles.

Table 1. Characteristics and restrictions of open and specific category scenarios.

Category/Scenario	MTOW/Class	Distance and Area	Limitations	Pilot Requirements
A1	<250 g (C0, Legacy, Private)	Overflight of people allowed	Not over assemblies of people; also in A3	Read manual
	<900 g (C1)	No overflight of people	Not over assemblies of people; also in A3	Online training + test
A2	<4 kg (C2)	Min. 30 m from people; 5 m in low-speed mode	Low-speed mode allowed; also in A3	Exam + self-declared practice
A3	<25 kg (C3, C4, Legacy, Private)	150 m from urban areas	Remote areas only	Online training + test
STS-ES-01	<10 kg, no class marking	Controlled ground area; urban environment	VLOS; no overflight of uninvolved people	STS-ES-01 training + declaration
STS-ES-02	<10 kg, no class marking	Controlled ground area; sparse areas	BVLOS with observer; no overflight of uninvolved people	STS-ES-02 training + declaration

MTOW: maximum take-off weight. VLOS: visual line of sight. BVLOS: beyond visual line of sight. C0–C4: EU drone classification. Note: Max flight altitude for all categories is 120 m.

summarizes the most common classifications within these categories.

The open category encompasses lower-risk civil drone operations, where safety is assured provided that the UAS operator adheres to the relevant regulatory requirements for the intended operation. This category is further divided into three subcategories: A1, A2, and A3. Given that operational risks within the open category are deemed minimal, no prior operational authorization is required to initiate a flight. The specific category addresses higher-risk civil drone operations. In this category, safety is ensured through the acquisition of operational authorization from the national competent authority prior to commencing the operation. This process involves a risk assessment and, in some cases, the submission of a detailed operational declaration or a Specific Operational Risk Assessment (SORA). The certified category applies to operations where the safety risk is significantly elevated. Consequently, this category mandates the certification of both the UAS operator and the drone itself, as well as the licensing of the remote pilot(s). These stringent requirements are implemented to ensure the highest levels of safety for operations falling within this category. Each category reflects a progressive increase in regulatory oversight, commensurate with the level of risk associated with the UAS operations.

EU Member States have developed different approaches to implementing these requirements, particularly regarding coordination procedures near aerodromes and critical infrastructures. These implementations vary significantly in their level of digital integration and coordination requirements. Information about each country can be found in the National Aviation Authority (NAA) drone website reference [8].

France has adopted an authorization-based approach through its national regulation (Article 4, Arrêté du 3 décembre 2020) [9]. Their system, implemented through the AlphaTango platform [10], requires operators to obtain prior authorization for operations in restricted areas, but does not mandate specific stakeholder coordination procedures. The French system emphasizes digital authorization processes, with geographical information accessible through Géoportail [11], enabling operators to visualize applicable restrictions and authorization requirements for each zone.

Portugal, focusing primarily on geographical information accessibility, has developed an interactive platform [12] through ANAC (Portuguese Civil Aviation Authority). While the Decreto-Lei $n^o$ 87/2021 [13] does not establish explicit coordination requirements, their system emphasizes providing a clear visualization of restrictions and requirements for different operational areas, leaving specific coordination procedures to local stakeholder discretion.

Italy has implemented a more comprehensive approach through the ENAC UAS-IT Regulation [14], which mandates authorization for operations near airports and critical infrastructures. This regulation is implemented through the D-Flight platform [15], which provides a digital ecosystem for UAS operations management. D-Flight enables operators to submit operation plans digitally, including required authorizations and documentation. The platform features an automated validation system that checks operational parameters and compatibility, with results communicated via email. While the initial ENAC authorizations must be obtained separately, D-Flight manages the subsequent operational approval process through standardized submission procedures and status tracking, although specific coordination timelines and requirements are less prescriptive than in other frameworks.

Spain has established a detailed coordination framework through Real Decreto RD-517/2024 [6], implementing specific requirements beyond the approaches adopted by other Member States. Article 41 introduces a general prohibition of UAS operations in the surroundings of aerodromes and heliports for safety reasons, while establishing a structured framework for exceptions through coordination procedures.

The Spanish regulation outlines the coordination framework through Article 43, requiring coordination with relevant stakeholders, including aerodrome managers, heliport managers, and Air Traffic Service (ATS) providers. The regulation establishes specific timelines, requiring infrastructure managers to respond within one month, either providing operational information or explaining why coordination is not possible. UAS operators must submit operation details, including operation planning, risk mitigation measures (if required), technical specifications of the UAS to be used, operator identification, and contact details. Additional technical safety equipment, such as voice communication systems, anti-collision lights, or transponders can be required by infrastructure managers.

The ENAIRE Drones platform [16] serves as the primary tool for UAS operators to visualize operational restrictions in Spanish airspace. Through its interactive map interface, operators can identify restricted areas, controlled airspace, and airspace limitations. The platform provides information about which stakeholders need to be contacted for coordination in each area—whether aerodrome managers, ATS providers, or other relevant authorities.

However, the actual coordination process remains manual. Once operators identify the required coordination parties through the platform, they must initiate contact via email or phone calls with each stakeholder separately. This process involves sending the required documentation, following up on responses, and maintaining records of all communications for the mandatory three-year period. The lack of a standardized digital coordination system means that operators must manage multiple communication channels and varying response times, which can impact the operation planning phase.

2.2. Accessing Controlled Airspace in the US

The strategy followed in the United States of America differs from the approach in Europe. The Federal Aviation Administration (FAA) has developed the FAA UAS data exchange platform called Low Altitude Authorization and Notification Capability (LAANC) [17]. LAANC is a collaborative tool between the government and the private industry, optimizing the sharing of airspace. It is available at 726 airports across the United States.

LAANC provides drone pilots access to controlled airspace under 400 ft (120 m), awareness of prohibited fly zones, Notices to Air Missions (NOTAMs), and Temporary Flight Restrictions (TFR). It also provides air traffic professionals with awareness of where and when drones will fly.

LAANC is a service offered by the FAA through a number of FAA-approved UAS service suppliers. Through these applications, pilots submit operations in order to obtain airspace authorization. Requests are checked against different restrictions: UAS Facility Maps [18], Special Use Airspace data, Airports and Airspace Classes, TFRs, and NOTAMs. If the request is approved after being analyzed through all these constraints, the pilot receives the authorization. Afterwards, pilots do not need to notify the air traffic control tower unless it is specifically requested.

The tool is available to pilots operating under the Small UAS Rule Part 107 [19] or under the exception for recreational flyers [20]. Flying under the Small UAS Rule Part 107 involves registering the drone and holding a Remote Pilot Certificate. On the other hand, flying as a recreational flyer involves registering the drone and taking the TRUST (Recreational UAS Safety Test). LAANC can be used in two scenarios:

• Operations below 400 feet (120 m) in controlled airspace and around airports.
• An operation above 400 feet that was applied for 90 days in advance, and for which the approval was coordinated manually through the FAA. In this case, infrastructure operators can provide guidance for the denied coordination, in order to allow pilots to modify their operations and re-submit them.

LAANC defines a state-transition diagram [21] which describes the six operation states and the possible transitions between them (see Figure 2). By formally defining operation states, the coordination process could be greatly automated. The states currently supported by LAANC are:

• Authorized: The authorization is approved but has not been completed or de-authorized.
• Complete: Approved authorization that has finished.
• Pending: Active authorization that is not yet approved.
• Never Authorized: Pending authorization that was denied, expired, or cancelled.
• De-Authorized: Authorization that was cancelled.
• Rescinded Awaiting: Authorization is rescinded and awaiting operator acknowledgement.

As described, LAANC is the platform US drone operators should use to coordinate their requests with FAA-managed aeronautical infrastructures. LAANC does not extend to other aeronautical infrastructures not managed by the FAA or other types of geographical zones. From that perspective, our proposal extends LAANC capabilities as it would support multilateral interactions between drone operators and a variety of infrastructure managers, including the national ANSP, but also many other public and private managers. Unfortunately, LAANC access is unavailable for further evaluation for non-US drone operators.

2.3. Accessing Controlled Airspace in South America

Like other regions in the world, South America has witnessed a substantial increase in drone adoption, mainly in fields like agriculture, mining, and logistics, generating a revenue of USD 3.58 billion [22]. Countries that have led the development of the sector include Brazil, Mexico, and Uruguay. Other countries are still in an early stage of the process [23].

In order to fly in Brazilian airspace, authorization from the Department of Airspace Control (DECEA) is mandatory [24]. In order to ask for it, a system called SARPAS has been developed. In this system, the user has to submit the type of operation, vehicles, flight plan (areas or sequences of waypoints), and other parameters. Coordination with aeronautical infrastructures and natural parks must be separately managed and attached to the request. Then, with the SARPAS system, the authorization with the DECEA is digitalized but not completely automatized. Unfortunately, the system does not support the tactical phase of a flight.

In 2022, Unmanned Airspace published the Brazilian UTM sandbox and its programme [25]. In it, the development of SARPAS was justified with the latest reports of 92,000 registered pilots and 93,000 registered vehicles. During 2021, 242,862 airspace access requests were submitted. Within this scenario, the National Civil Aviation Agency (ANAC) decided to develop SARPAS and establish its implementation programme.

In Uruguay, the National Directorate of Civil Aviation and Aeronautical Infrastructure (DINACIA) has developed a platform called CIELUMeasy [26]. Operators can ask for authorization (SOCA) within this platform in geographical zones, mainly for aeronautical infrastructures. The authorizations can be automatically or manually accepted, depending on their risk. The application shows tactical information, and the flight areas are shown in the application’s map.

In other countries in South America, authorizations remain managed by emailing or submitting electronic procedures with the corresponding ANSP.

3. The Structure of a Drone Operation Request

3.1. Objectives and Current Scope

The current mechanisms employed to establish operational coordination between drone operators and the various stakeholders impacted by drone activities are fundamentally outdated. In general terms, each of these coordination processes involves extensive information gathering and the generation of a large amount of documentation and individual one-to-one communications between entities, such as emails, phone calls, or text messages. As a result, conducting a flight in certain areas may require multiple, time-consuming interactions, and it would be difficult to maintain a proper evidence track. For instance, in a city like Barcelona, a single drone operation may necessitate at least five separate heliport coordinations, in addition to coordinations with the LEBL (Barcelona) and LELL (Sabadell) airports, natural park coordinations, and communication with the national and regional authorities (see Section 9 for some validation examples). Each of these coordination processes is extremely repetitive, exchanging the same drone operator details, mission details, insurance, and operator documentation, and performing a myriad of individual negotiations, etc.

The main objective of the ACCORD model is to formalize the coordination process between drone operators and organizations with whom coordination should be established under the current EU law. This formalization enables the definition of the precise state workflow that each coordination should follow, creating a common understanding around the process. Once formalized, the model can be digitalized and the processes automated within a common software platform, enabling a comprehensive generation of the documentation associated with all coordination actions and streamlining the necessary interactions before and after the coordinations are established. Such a platform would provide a single entry point to centralize all coordination actions, as well as keeping an evidence sequence, capturing the state evolution of each coordination, from the definition of the drone mission to the conclusion of each coordination process and the execution of the flights.

Figure 1 illustrates the different stakeholders with whom drone operators must coordinate according to current EU and Spanish regulation [5,6]: airports, aerodromes, heliports, critical ground infrastructures, protected natural areas as a result of existing geographical areas, and national or regional police as a result of national security. The coordination with each of these stakeholders may slightly differ in the details, but shares the same underlying concept: if the drone mission interacts with a geographical area (defined under some spatial and/or temporal conditions in the regulation), drone operators should formally request the establishment of an operational coordination with the corresponding organizations. Once coordinations are established, drone operators are obliged to comply with several safety-related restrictions that may be imposed on them. Infrastructure operators may introduce further restrictions within reason for operational safety. Moreover, in most cases, on the day of the mission, drone operators should announce both the initiation and completion of the flights and, at the same time, remain vigilant in case the mission should be suspended due to an emergent situation.

ACCORD’s current modelling focuses on supporting coordination processes associated with aeronautical infrastructures and communications to public safety agencies. This initial scope addresses (1) large and small airports, characterized by the fact that there exists managed airspace volumes or information zones protecting the infrastructure; (2) small uncontrolled aerodromes; (3) heliports; (4) communication to both national and regional public safety entities. In the case of airports, there may exist a management duality, because in addition to the organization that operates the airport itself (the infrastructure manager), a separate organization would be in charge of providing its airspace management services (ANSP). On the contrary, small aerodromes are generally managed by professional or non-professional organizations, ranging from well-established aero clubs and small pilot associations to individual citizens.

3.2. Elements in an Operation Request

A drone operation request is the entry point in the ACCORD flow model for drone operators. An operation request would contain the four fundamental elements that encompass the description of an intended operation:

1.

A unique object identifier to unequivocally track the digital transaction.

2.

Information identifying the drone operator (company data, EASA identification, legal status, contact information, etc.).

3.

Intended drone mission (location, description, trajectories or areas of operation, drones, pilots, type of operation, observers, etc.).

4.

Operation time period (days or day period, hours of the day, expected duration, etc.).

The operation request should be filled with enough information to perform all necessary coordination processes without requiring further inputs from the operator.

Additional information may be attached to the operation request in the form of documents that may complement the process. Drone operators would be entitled to enable the sharing of key documentation associated to their operation, like legal or operational documents, vehicle registration documents, insurance documents, pilot certificates, and even specific risk assesment documents associated with the operation, like the Specific Operations Risk Assessment (SORA) [27,28]. Note that only those documents selected by the drone operator would be entitled for inspection by the corresponding infrastructure managers.

Once the operation request details are fully completed, the request could be submitted for coordination. At that point, the operation request would be automatically enhanced with all the elements that enable the traceability of the process, including a detailed timeline of the performed interactions (to be described in the upcoming sections), guaranteeing that the precise sequence of coordination actions is preserved.

3.3. Coordination with Aerodromes and Heliports

An operation request may interact with several aeronautical infrastructures at the same time, and each one may require different conditions to be satisfied. Such conditions will be formalized as restrictions in our context (to be later refined). Some restrictions will be exactly the same for each type of infrastructure, as they are derived from the local regulatory context. Others may be specific to each infrastructure. For example, each heliport may employ different approach and departure routes; thus, those routes may deserve special protection. For this reason, a specific object needs to be employed to enable the encapsulation of all those particular restrictions emanating from each individual infrastructure, which should be associated to the operation request. In the ACCORD context, such an object will be called a coordination request.

Coordination requests will be generated to encompass all restrictions associated with an aeronautical infrastructure with which the drone operation interacts, given the geographical areas defined under the corresponding regulation. However, aeronautical infrastructures cannot be considered individually as, in some occasions, several of them would be managed by the same entity. For example, the Medical Emergency Services (SEM) and the Bombers de la Generatitat (BOMBERS) operate around 25 heliports in the case of Catalonia. As it may often be the case that the same entity would be managing several infrastructures requiring coordination with the same mission, a general coordination should be established with that entity.

Each entity managing a group of aeronautical infrastructures may require specific restrictions associated with their own operational nature, which will, in turn, be common for all the infrastructures under their management responsibility. As a result, an additional coordination request object is employed to support the definition of such restrictions emanating from infrastructure managers.

Figure 3 outlines the process associated with the proposed coordination model. After an initial analysis, all infrastructures requiring a coordination process would be determined, and individual coordination requests created. Then, additional coordination requests would be created for each of the infrastructure operators involved in a coordination.

A coordination request is the key object enabling infrastructure managers to track the coordination process with drone operators. Each coordination request is defined by a unique identifier, a reference to the corresponding operation request (enabling access to the drone operator information and the operation details), and references to each corresponding infrastructure manager (to encapsulate general restrictions) or to each particular infrastructure (to encapsulate the specific restrictions associated to each infrastructure).

Coordination requests will also be automatically enhanced with all the elements that should enable the detailed traceability of the process, including a detailed timeline of the various interactions to be described in the upcoming sections, as well as a blockchain structure, guaranteeing that the history of the coordination actions associated with each manager/infrastructure is appropriately preserved.

3.4. Coordination with Airports

In most cases, the coordination process with airports will involve interaction with the entities providing the corresponding air navigation services. Those services imply the management of volumes of controlled airspace around large- and medium-sized airports, in which CTR, CTA, FIZ, or ATZ airspace may exist.

Through discussions with several airports, we learned that in some situations, the airport operator may perform such a coordination process rather than the ANSP. This may occur if the drone operation is performed within the airport perimeter. Therefore, when analyzing the coordination requirements for an operation request, it would be necessary to determine which one of these entities should manage the coordination: the airport operator or the air navigation service provider. ACCORD would provide a general mechanism to configure those areas of responsibility according to the interests of each airport. As a result, the coordination request object for an airport would be annotated with both the corresponding airport operator and air navigation service provider.

Finally, it is relevant to mention that even though airport operators may be determined to retain the coordination responsibility, the air navigation service provider should be informed at all times of all coordinated operations, regardless of the entity managing that coordination. ACCORD will also provide support for such functionality.

4. Coordination Restrictions and Containers

The ACCORD model formalizes the various types of conditions associated with a geographical area by the term restriction. Restrictions will be employed for various purposes, such as defining the global areas within which coordination is needed, sub-areas that deserve special protection, general conditions to comply with, etc. This section will describe the various types of restrictions currently supported and the context in which they will be employed.

Restrictions would need to be grouped to represent different functionalities, like the conditions that define whether coordination is necessary, whether the coordination is managed by an airport organization or a service provider, etc. Groups of restrictions will be referred to as containers. The second part of the section will describe which containers are employed in ACCORD and which types of restrictions are employed within each container type.

4.1. Formalizing the Restriction Concept

A restriction is a way to represent the various conditions that may be applied to a drone operation if that operation occurs within a geographical area. Restrictions are constructed as a formal language in which adding further words adds meaning to the definition of the intended condition. Three types of basic semantics can be expressed in a restriction: spatial, temporal, and operational conditions.

Table 2. Basic semantics expressed in a restriction as spatial, temporal, and operational conditions.

Restriction	Type	Parameters	Incompatibility
MESSAGE	Any	—	—
LIMIT-TO-TIME	TC	—	AVOID-TIME
AVOID-TIME	TC	—	LIMIT-TO-TIME
ON-DATE	TC	Start/end date	–
ON-HOUR	TC	Start/end hour	–
ON-WEEKDAY	TC	Day of week	–
AVOID-AREA	VC	Polygon	VOLUME-AS-CIRCLE, VOLUME-AS-RECTANGLE, LIMIT-TO-AREA
LIMIT-TO-AREA	VC	Polygon	VOLUME-AS-CIRCLE, VOLUME-AS-RECTANGLE, AVOID-AREA
VOLUME-AS-CIRCLE *	VC	uptoRadius/belowRadius	VOLUME-AS-RECTANGLE, LIMIT-TO-AREA, AVOID-AREA
VOLUME-AS-RECTANGLE **	VC	rectangleWidth/rectangleLength	VOLUME-AS-CIRCLE, LIMIT-TO-AREA, AVOID-AREA
NO-CLOSER-THAN	VC	—	–
NO-HIGHER-THAN	VC	uptoAltitude/belowAltitude	–
VOLUME-AS-RESTRICTION	VC	—	VOLUME-AS-COORDINATION, VOLUME-AS-RESPONSIBILITY
VOLUME-AS-COORDINATION	VC	—	VOLUME-AS-RESTRICTION, VOLUME-AS-RESPONSIBILITY
VOLUME-AS-RESPONSIBILITY	VC	—	VOLUME-AS-RESTRICTION, VOLUME-AS-COORDINATION
ON-OPERATION-CATEGORY	OC	A1/A2/A3/C1/STS01/STS02	–
MUST-OBSERVER	OC	—	–

TC: temporal conditions, VC: volume conditions, OC: operational conditions. Note: * Associated to an infrastructure centroid. ** Associated to a runway (location, length, and heading).

formalizes the syntax employed to define the catalogue of symbols, the type of condition, the parameters currently available to define each condition, and potential incompatibilities with other conditions. Currently, available conditions are defined as follows.

Temporal Conditions (TC) are specified by adding either LIMIT-TO-TIME or AVOID-TIME symbol, which express that the restriction is satisfied within or outside that temporal range, respectively. Then, additional details can be added, like expressing a date period, a day of the week selection, or an hour period. The resulting condition will be the combination of at least one of the temporal restrictions.

1.

Limit-to-Time or Avoid-Time: Restriction to circumscribe to or avoid a certain temporal condition (employing the above modifiers).

2.

On-Period: Restriction only applies between a range of two dates.

3.

On-Weekday: Restriction only applies to selected days of the week.

4.

On-Hour: Restriction only applies between a range of two hours.

Spatial Conditions (SC) are specified by adding the symbols VOLUME-AS-CIRCLE, VOLUME-AS-RECTANGLE, or VOLUME-AS-AREA, which express that the restriction is satisfied if the drone operation occurs outside the area defined by a circle, a rectangle, or a general polygon surrounding the protected infrastructure. Circle and rectangle symbols need additional symbols to define the horizontal (NO-CLOSER) and vertical (NO-HIGHER) size of those volumes. Area symbols already embed the horizontal component in the specified rectangle.

1.

Volume-As-Circle/Volume-As-Rectangle: Restriction represents either a circle or a rectangle. For a circle, the bounds are a radius around the reference point; for a rectangle, they are width and length, with a bearing for heliports or a bearing and length for runways.

2.

Volume-As-Area/Limit-To-Area: Restriction represents 2D polygons, and the operation to be completely outside or inscribed in it.

3.

No-Closer: Restriction to be no closer than a certain distance with an upper and lower bound.

4.

No-Higher: Restriction to be no higher than a value from a reference altitude with an upper and lower bound.

Additional symbols can be employed in combination with the previous ones to add further Operative Conditions (OC), specifying requirements associated with the operation and drone categories, the need to employ observers, or meta conditions expressed in plain text.

1.

Message: Free text describing a written condition, e.g., the operators must employ a radio and connect to a specific frequency.

2.

On-Category: Restriction applies if the operation employs a drone within a specified category.

3.

Must-Observer: Restriction applies if the operation employs observers.

Two additional properties can be attached to a restriction to determine the level of automation associated with its processing. Restrictions can be annotated as blocking, implying that they are considered safety-critical, and if violated, the coordination cannot be accepted. Alternatively, a restriction can be annotated as must-review, implying that if violated, the infrastructure manager should manually decide whether the risk is acceptable and the coordination may proceed or, on the contrary, the coordination cannot be accepted. In any other case, a violated restriction will be incorporated into the coordination request, and the process will follow its evaluation process.

4.2. Grouping Restrictions into Containers

Restrictions are employed in groups that describe some of the different functions required by ACCORD. Each of the groups, referred as to containers, offers a coherent view of the various conditions associated with the coordination process:

• Coordination Volume Container: Defines the volume-related restrictions associated with an infrastructure. If an operation request violates any of the restrictions, then coordination between the drone operator and the infrastructure is necessary. This type of container models the geographical areas associated with the protected infrastructure.
• Coordination Restriction Container: Defines a set of various restrictions, defined by the infrastructure manager, that the drone operator must comply with when operating within the geographical area. Two subtypes of restrictions lay within this container: restrictions associated with an infrastructure (specifying conditions to that particular infrastructure), and those associated with the corresponding infrastructure manager (specifying generic restrictions associated with the operational procedures imposed by the infrastructure manager). Different coordination containers may exist, each one applicable to different types of drone operators: those operating under civil EASA regulations, public service organizations (within EASA but considered of higher priority as part of government organizations), or non-EASA operations (various police or military agencies, etc.).
• Responsibility Volume Container: Defines volume-related restrictions that indicate which organization should manage the coordination process in the case of airports: the infrastructure manager or the air navigation service operator.

Containers are stored in the ACCORD database and extracted as necessary when processing an operation request to generate the corresponding coordination request. For example, these are some application cases specifying various types of restrictions. In particular restrictions integrating coordination volume containers for different types of infrastructures (heliports, airfields, and aerodromes) under the Spanish regulations (see

Table 3. Geographical zones requiring coordination according to operational safety around civil or military aerodromes or heliports in Spain (Article 41 of Royal Decree 517/2024).

Infrastructure Type	Height (m) *	X-Distance **	Y-Distance ***	Radius ****
Public-use civil and military aerodromes	0–45 45–900	6 km 10 km	5 km 7.5 km	N/A N/A
Public-use civil and military heliports	0–90 90–900	2.5 km 3.3 km	2.5 km 3.3 km	N/A N/A
Restricted-use civil aerodromes	0–45 45–900	3 km 5 km	3 km 4.5 km	N/A N/A
Restricted-use civil heliports	0–90 90–450	N/A N/A	N/A N/A	2.5 km 3.3 km

* Measured from the Aerodrome Reference Point (ARP) or Heliport Reference Point (HRP). ** Measured from the ends of the runway running outwards as though in an extension of the runway axis. *** On both sides, measured from the runway axis. **** Measured from the centre of the FATO. If runway-type FATOs are more than 100 m long, the distance measured from each end of the FATO.

). Restrictions integrating coordination containers for the risk assessment associated with infrastructures can be specified by employing the same formalism. The set of restrictions currently employed by the SEM and BOMBERS when managing their network of heliports [29] under the Spanish regulations can be reviewed in Figure 4 and

Table 4. Coordination areas with SEM (Sistema d’Emergencies Mediques).

Operation Category	Subcategory	MTOW or Line of Sight	Height (m)	X-Distance (m)	Automatically Coordinated
Open Category	A1	<250 g	0–20	<250	YES
		<900 g	0–60	<500	YES
	A2	<4 kg	0–60	<750	YES
	A3	<25 kg	0–60	<1000	YES
Specific Category	STS-ES-01 *	VLOS	0–60	<250	YES
	STS-ES-02 *	BVLOS	0–60	<1000	YES

* With Observer.

. This protection strategy, which will be further discussed in Section 8, can also be specified employing the proposed formalism.

Table 5. Language description of restrictions conditions.

Coordination Volumes	Restriction Conditions
Heliports	{ VOLUME-AS-COORDINATION, VOLUME-AS-CIRCLE, NO-CLOSER-THAN ( belowRadius: 2500 ), NO-HIGHER-THAN ( belowAltitude: 90 ) }
	{ VOLUME-AS-COORDINATION, VOLUME-AS-CIRCLE, NO-CLOSER-THAN ( belowRadius: 3300 ), NO-HIGHER-THAN ( belowAltitude: 450, uptoAltitude: 90 ) }
Airfields	{ VOLUME-AS-COORDINATION, VOLUME-AS-CIRCLE, NO-CLOSER-THAN ( belowRadius: 2500 ), NO-HIGHER-THAN ( belowAltitude: 45 ) }
	{ VOLUME-AS-COORDINATION, VOLUME-AS-CIRCLE, NO-CLOSER-THAN ( belowRadius: 5000 ), NO-HIGHER-THAN ( belowAltitude: 450, uptoAltitude: 45 ) }
Aerodromes	{ VOLUME-AS-COORDINATION, VOLUME-AS-RECTANGLE, NO-CLOSER-THAN (rectangleWidth: 3000, rectangleLength: 3000), NO-HIGHER-THAN ( belowAltitude: 45 ) }
	{ VOLUME-AS-COORDINATION, VOLUME-AS-RECTANGLE, NO-CLOSER-THAN (rectangleWidth: 4500, rectangleLength: 5000), NO-HIGHER-THAN ( belowAltitude: 900, uptoAltitude: 45 ) }
Restriction Volumes	Restriction Conditions
Restriction volumes (SEM and BOMBERS)	{ VOLUME-AS-RESTRICTION, VOLUME-AS-CIRCLE, NO-CLOSER-THAN (belowRadius: 2500), NO-HIGHER-THAN ( belowAltitude: 60 ) }
	{ VOLUME-AS-RESTRICTION, VOLUME-AS-CIRCLE, NO-CLOSER-THAN (belowRadius: 500), NO-HIGHER-THAN ( belowAltitude: 20, uptoAltitude: 60 ) }
	{ VOLUME-AS-RESTRICTION, VOLUME-AS-CIRCLE, NO-CLOSER-THAN (belowRadius: 250), NO-HIGHER-THAN ( belowAltitude: 0, uptoAltitude: 20 ) }
	{ VOLUME-AS-RESTRICTION, VOLUME-AS-CIRCLE, NO-CLOSER-THAN (belowRadius: 1000), NO-HIGHER-THAN ( belowAltitude: 0, uptoAltitude: 60 ), ON-CATEGORY ( A3 ) }
	{ VOLUME-AS-RESTRICTION, VOLUME-AS-CIRCLE, NO-CLOSER-THAN (belowRadius: 750), NO-HIGHER-THAN ( belowAltitude: 0, uptoAltitude: 60 ), ON-CATEGORY ( A2 ) }
	{ VOLUME-AS-RESTRICTION, VOLUME-AS-CIRCLE, NO-CLOSER-THAN (belowRadius: 500), NO-HIGHER-THAN ( belowAltitude: 0, uptoAltitude: 20 ), ON-CATEGORY ( A1, C1 ) }
	{ VOLUME-AS-RESTRICTION, VOLUME-AS-CIRCLE, NO-CLOSER-THAN (belowRadius: 1000, uptoRadius: 250), NO-HIGHER-THAN ( belowAltitude: 0, uptoAltitude: 60 ), ON-CATEGORY ( STS02 ), MUST-OBSERVER }
	{ VOLUME-AS-RESTRICTION, VOLUME-AS-CIRCLE, NO-CLOSER-THAN (belowRadius: 2500, uptoRadius: 250), NO-HIGHER-THAN ( belowAltitude: 0, uptoAltitude: 60 ), ON-CATEGORY ( STS01 ), MUST-OBSERVER }

lists the language description of both types of restrictions.

4.3. Letter of Agreement to Automate the Coordination Process

Letters of Agreement are modelled in ACCORD through dedicated coordination containers that identify the specific set of conditions that must be satisfied for the LoA to hold true. If an operation request fully satisfies all the restrictions in the container, the operation will be automatically accepted as coordinated. If any of the restrictions are not satisfied, the operation request should carry out the standard coordination process.

Even though an operation request is processed automatically, all necessary coordination requests are constructed, and the submission and coordination are registered in the system to guarantee an adequate level of traceability.

4.4. Coordination Request Traceability

A traceability mechanism is integrated into the coordination process to guarantee that all major coordination actions are properly recorded, providing evidence of the whole coordination process. The implemented process employs a simplified version of the ubiquitous blockchain mechanism [30].

An initial information block containing all the operation request and coordination request information is created. That block will be employed as the genesis block, and a hash block is “mined”, freezing the whole set of information associated with the Coordination Request.

From that genesis block, all further transactions will be recorded, including those required to reach the intended coordinated status and those proceeding further into the actual activation and finalization of the drone flights. Each of these transaction blocks will contain the following elements:

• The previous block-mined hash key.
• The time stamp for the transaction.
• The details of the executed transaction, which will be detailed throughout Section 5, including restriction, coordination requests, and operation request transitions.
• A randomly generated nonce, an arbitrary number used in cryptography to obfuscate the data block.

Subsequent blocks are then mined, freezing the whole transition sequence to the current state of the operation request. The resulting sequence of hash keys allows us to trace back at any point in the negotiation process to validate whether a particular state transition was legitimate.

It is important to note that mining a block in cryptocurrencies involves solving a highly complex computational task. However, considering the low-risk level of the intended application, the current mining algorithms are kept at a medium complexity.

5. Management of the Coordination Workflow

Together with the definition of the restriction concept, the formalization of the coordination process under the ACCORD model is subdivided into three phases that will be described in this section. Initially, (1) all the necessary coordination requests must be determined according to the drone operational area. Each coordination request would involve a collection of restrictions, which (2) would need to be accepted by the drone operator. Once each individual restriction is processed, the (3) coordination requests can be accepted by both parties, leading to the full coordination of the operation.

5.1. Coordination Request Generation

Once an operation request is submitted for coordination, several checks are necessary to determine which infrastructures and infrastructure operators are involved in the process and require the generation of the corresponding coordination requests and the set of restrictions involved in each coordination through the following actions:

1.

A preliminary list of infrastructures is short-listed according to an efficient built-in distance criterion.

2.

The coordination volume container for each infrastructure is extracted from the database and validated to determine if any intersection exists between the volume-related restrictions and the drone mission. Existing intersections indicate which part of the drone operation requires coordination.

3.

Based on the infrastructures requiring coordination, the infrastructure managers of the infrastructures that are involved in the process are determined. One coordination request is generated for each infrastructure manager, and additional coordination requests are generated for each coordinated infrastructure.

4.

For all infrastructures categorized as airports, we determine which organization is managing the coordination process based on the responsibility volume container associated with those infrastructures.

5.

The drone operator may have a standing LoA with the infrastructure manager. If all the restrictions in the LoA are satisfied, then the coordination is immediately accepted.

6.

If no LoA stands or the LoA conditions are not satisfied, then we recover the coordination container that applies for the type of operation (EASA operation, public body operator, or non-EASA operator). Each of the restrictions is analyzed and associated with the corresponding coordination request.

5.2. State Transition Modelling of the Coordination Process

The dynamics of the coordination process are modelled and executed through a series of state transition diagrams that capture the current state of each restriction, coordination request, and operation request. Each state transition diagram contains a set of states and transitions to formalize the process. Transitions can only be exercised by the relevant actor as the coordination process advances from the drone operator to the infrastructure manager, etc. Transitions may also contain a series of guards, preventing execution until certain conditions are satisfied; for example, all restrictions should be accepted before a certain coordination request transition can be executed.

For some special guarded transitions, once the guarding property is satisfied, the transition may be automatically exercised without human intervention. This type of automatic transition is configurable and will help the infrastructure operator to reduce its workload. For example, specific coordination request transitions can be automatically executed once all restrictions are accepted, or the infrastructure manager may like to inspect all restrictions before moving forward. Another example occurs in the case of rejecting a request, e.g., a coordination request may be automatically denied if a critical restriction is not satisfied, or alternatively, the operator may like to inspect the restriction itself before making a final decision.

The following subsections detail the state transition diagrams and the existing automation mechanisms for the key objects in the coordination process: restrictions, coordination requests, and operation requests. Note that the state diagrams label each transition with the actor entitled to execute it. Guarded transitions that can be configured to be executed automatically have the corresponding condition annotated (the system enables the users to enable or not that automatic activation).

5.2.1. Restriction State Transition Flow

Restrictions will follow a formal negotiation workflow between the drone operator and the infrastructure manager (see Figure 5). A restriction could be initiated in three states, CREATED, PENDING ACCEPTANCE, or BLOCKING, depending on the properties associated with it.

A CREATED restriction waits for the infrastructure manager to confirm its application, transitioning to PENDING ACCEPTANCE, just being disregarded, transitioning to REMOVED, or transitioning to BLOCKING. A restriction may be removed if the infrastructure manager evaluates its application as unnecessary or irrelevant for a particular situation (e.g., a protection volume is violated by just a few metres). A restriction may block the coordination if it is considered that the associated risk is unacceptable.

Restrictions may automatically transition to either PENDING ACCEPTANCE or BLOCKING according to the associated properties, as described in Section 4.

A restriction in the PENDING ACCEPTANCE state waits for the drone operator to formally accept it by transitioning to the ACCEPTED state, indicating that the drone operator will convey the referred conditions (see Section 4).

A drone operator has the possibility to perform a negotiation by sending text annotations back to the infrastructure manager for evaluation (transitioning to the PENDING REVIEW state). In turn, the infrastructure manager may respond by accepting or rejecting them, returning to the PENDING ACCEPTANCE state. As previously described, the whole process is traced in order to keep evidence of the set of interactions.

A drone operator finally accepts the restriction by transitioning to the ACCEPTED state, before obtaining full approval from the infrastructure manager, and then transitioning manually or automatically to the final APPROVED state (which can be configured at any time). The infrastructure manager may retain manual control before reaching a final approval if the restriction is considered of high priority, or just enable a full automatic transition to reduce their workload. Note that the infrastructure manager may remove the restriction at any moment if it is deemed irrelevant until it is approved.

5.2.2. Coordination Request State Transition Flow

The evolution of a coordination request state will result from the evolution of its associated restrictions, leading to an actual coordination before the actual operation. Additionally, the coordination request state will further evolve to support the interaction between drone operators and infrastructure managers during the execution phase of the drone mission (see Figure 6).

When a coordination request is created, it starts in a CREATED state, in which infrastructure managers are responsible for reviewing all associated restrictions that have been automatically generated. Some restrictions may be transitioned to PENDING ACCEPTANCE by the drone operators or REMOVED if deemed irrelevant (as described in the previous section). Once all restrictions have transitioned to either state, the coordination request will automatically transition to the state PENDING ACCEPTANCE, that is, waiting for the acceptance of the imposed restrictions by the drone operator. In the event that all restrictions are removed, the coordination request would transition to the REMOVED state. Such a situation may occur when a drone operation barely clips an infrastructure and is thus considered not relevant.

An alternative path of action is the direct rejection of the coordination due to some restriction or situation that makes it unacceptable to the infrastructure manager. In that case, the coordination request would be transitioned to the REJECTED state, concluding the process.

While in the PENDING ACCEPTANCE state, the drone operator may annotate some of the restrictions. In that case, the coordination request will transition to an intermediate PENDING REVIEW state until all restrictions are accepted and the coordination request transitions to the APPROVED state. Once all restrictions are APPROVED, the coordination request transitions to the COORDINATED state.

Recall that some of these transitions are guarded to guarantee that the required conditions are met. The guarding conditions are annotated in the diagram shown in Figure 6. Guarded transitions can be configured to be executed automatically or manually by the infrastructure manager once the condition is met. Such a configuration enables the trade-off of the workload level associated with the coordination management according to the operator’s safety policies.

From then on, the coordination request moves from the strategic/planning phase to the actual execution phase. The objective of that phase is to enable a communication mechanism between the drone operator and the infrastructure manager to handle the operation’s actual evolution. On a day of operation, the drone operator transitions the coordination request into the ACTIVATED state. Activations indicate that the drone operation will undoubtedly occur, and the transition will be made sometime before the actual flight.

If the operation stands down for some time, the operator can transition to the DEACTIVATED state. If the drone mission needs to restart, transitioning back to the ACTIVATED is feasible. Once done for the day, the operator should transition back to the DEACTIVATED state and then further to the COORDINATED state. The operation may be reactivated some other day within the requested schedule or, if done for good, transition to the FINISHED state.

The infrastructure manager may also have a say, either suspending or cancelling the drone coordination in the case of safety concerns (cancelling being definitive, while a suspension may be temporary). Some justification for the motivation of the state change should be attached to the state change request, informing the drone pilots about the emergent situation. In both cases, a slight difference was introduced depending on whether or not the drone mission had already been ACTIVATED. An ACTIVATED mission that should be SUSPENDED or CANCELLED requires an intermediate state—SUSPENDING or CANCELLING, respectively—in which the drone operator is requested to acknowledge the petition. On the contrary, if the drone mission is not ACTIVATED, then the transition to the SUSPENDED or CANCELLED states is immediate.

5.2.3. Operation Request State Transition Flow

The coordination request is the main object an infrastructure manager employs to negotiate an operation request. However, the drone operator may have multiple coordination requests associated with the same operation request to handle. It is unreasonable, therefore, that the activation/deactivation flow and other operation requests are made at the coordination request level. Hence, the ACCORD model assumes that drone operators will carry out some of the aforementioned transition changes at the operation request level.

The formal operation request states and transitions highly resemble those of the coordination request. Once an operation request is performed and the associated coordination requests are created, it starts in the OPERATION CREATING state. Once all coordination requests have been transitioned to the PENDING REQUEST state, the operation request transitions to an equivalent state, thus hiding all the internal transitions performed by each of the infrastructure managers and minimizing the drone operator’s workload. Similarly, once all coordination requests have transitioned to the COORDINATED state, the operation request transitions to an equivalent global state as well.

Note that some of these transitions are guarded, with conditions annotated in the diagram shown in Figure 7. In this case, guarded transitions are always executed automatically, as they depend on the collective status associated with the underlying Coordination Requests.

The activation of the operation is, in fact, performed at the operation request level (transition to the ACTIVATED state) and then automatically transmitted to all coordination requests. Similarly, deactivations and finalizations are handled from this higher level and forwarded to the coordination requests.

On the contrary, suspensions and cancellations from an individual infrastructure manager do not necessarily imply a global suspension or cancellation. To this end, it is necessary to evaluate if the area of influence of the suspending/terminating infrastructure covers most of the operation. If this is not the case, it may be argued that the drone mission may partially continue without permission to interfere with the referred infrastructure.

Overall, an operation request will only fully transition to the equivalent SUSPENDED or ACTIVATED states when all the underlying coordination requests transition to the equivalent states.

6. Drone Operator Interface

ACCORD allows the drone operators to define the details associated with future missions and guides them through all the required coordination processes. This section will review some of the interfaces provided to drone operators to manage the whole workflow. This is fully accomplished if the various infrastructure managers in the relevant area employ the same platform. However, if this is not the case, ACCORD would also provide support for generating all the appropriate documentation to perform classical email-based coordination.

6.1. Operation Request Management

All operation requests for each operator can be accessed on the application home page, which allows them to be distinguished based on the actual operation phase:

1.

Submitted: operations in the coordination pipeline.

2.

Created: draft operations, allowing modifications, and pending submission.

3.

History: completed, expired, removed, or cancelled.

4.

Today: operations to be executed on the current day.

Each operation request displays a summary with essential information such as callsign, location, start/end date, categorizations, and the number and general state of each coordination (once submitted). Clicking on an operation provides further details, including the detailed flight plan, selected pilots and vehicles, etc. (see Figure 8).

Once an operation request is created with all details fulfilled, drone operators can use the “Check” function to assess it. This allows the number of required coordinations and specific details of each one to be determined, facilitating the introduction of changes if necessary. When ready, the operator can submit the operation to the system via the “Coordination” function, initiating the coordination workflow. This process involves the creation of the corresponding coordination requests and accepting the restrictions associated with each involved infrastructure, as well as general restrictions applied by individual infrastructure managers.

6.2. Detailed Operation Management

Drone operators can visualize the full details of the ongoing operations listed in the various tabs on the home page. For detailed management of a specific operation, the “Operation Details” page is available (see Figure 9). This page provides operators with all essential information about the operation, including:

1.

Flight plan.

2.

Operation details such as contact pilot and vehicles.

3.

Infrastructures and their influence areas.

4.

Applicable restrictions.

5.

Infrastructure information and contacts.

6.

A dialogue box displaying the current state of the operation and buttons to execute the following available state transitions.

The “Operation Details” page also displays all infrastructure managers associated with each coordination request, along with applicable restrictions.

This interface allows restrictions to be accepted. The flight plan is visualized alongside the interacting infrastructures and influence areas. The drone operator may “Accept” or “Annotate” the associated restrictions, facilitating the coordination workflow.

Additional actions, according to the designed operation state transitions flow, are available depending on the operation’s current state; this would include all actions associated with the activation and deactivation of the flight on the day of the operation.

6.3. Drone Operation Design and Fleet Management

A Flight Plan Editor within ACCORD enables drone operators to specify their missions with various levels of detail. Every flight plan comprises two main parts: the descriptive part and the operational part. The descriptive part requires the user to complete a form with essential information, including the flight plan name, version, search keys, folder storage path, and general text description. The operational part involves specifying the default altitude and speed, followed by detailing all the elements constituting the flight plan trajectory, which includes take-off and landing locations, sequences of waypoints, and operational areas. Detailed speed, altitude, and operation time can also be individually assigned to each point in the trajectory.

Flight plans are separately stored to be used later to create operation requests or to generate further flight plans based on them. This strategy is especially relevant to drone operators who perform a large volume of commercial operations, implying the repetition of the same or similar flight plans for long periods of time.

The New Operation Request form allows drone operators to create an operation request, including the desired flight trajectories and all additional operational details. The main fields included in this form are:

• Callsign: a reference short name for the operation.
• Description: a concise description of the intended operation.
• Operation category: three categories based on current EU regulation—open, specific, and certified. A subcategory can be chosen based on the selected category. The subcategories for the open category are A1, A2 and A3. For specific categories, two standard scenarios are defined: STS01 and STS02.
• Operation’s Line of Sight: VLOS, EVLOS, and BVLOS.
• Operation’s nature: type of operation being conducted.
• Observers: observers included in the mission (individual details may need to be included in the case of communication to authorities).
• Non-EASA Operation: either the operator is non-EASA (police, military, etc) or a commercial operator on behalf of a non-EASA operator.
• Number of flights: approximate number of daily flights.
• Flight time: daily duration of the operation.
• Vehicles: list of all vehicles to be employed with their details.
• Pilots: all pilots, including one as designated contact.
• Scheduled date: operation days, start and end hour per day.
• Trajectories: all intended flight plans.

Note that many of the required details are already part of the information about the operator stored by ACCORD, e.g., its fleet of vehicles and pilots. Moreover, an operation may be created on the basis of an existing one, thus speeding up the process. Once all fields are completed, the operation request is created and stored for further review of coordination.

7. Infrastructure Manager Interface

Infrastructure managers enjoy a centralized view of all their managed infrastructures and pending coordination requests on their “Home” page (Figure 10). Alternative visualizations are available in which various selection filters exist, in order to select coordinations according to dates and states.

7.1. Detail of an Infrastructure

The “Infrastructure Detail” page allows operators to control and modify specific aspects of each infrastructure (see Figure 11). Here, operators can adjust the General State of the infrastructure, manage the associated restrictions, and handle drone operators with approved Letters of Agreement. Furthermore, highly visible indications alert the infrastructure managers of any pending actions related to the incoming coordination requests.

In terms of spatial representation, they can visualize the influence areas of each infrastructure. To enhance this functionality, operators can create, manage, and display various spatial elements, such as regions or obstacles. This includes adding representations of helipads, surrounding buildings, etc.

7.2. Coordination Request Management

To facilitate agile coordination, the “Coordination Request Management” page offers the operator a comprehensive view of all active coordination requests grouped by infrastructure or operation. Operators can apply general filters to display requests with pending actions or those awaiting further drone operator input. Each coordination request entry displays essential information, including the requesting drone operator, the operation callsign, requested and operation dates, and a summary of applicable restrictions. When appropriate, interfaces are available to transition the various coordination states (see Section 5), and once coordination is completed, managers can download the corresponding coordination documents directly from this page.

The “Coordination Request Detail” page (see Figure 12) provides a map visualization showing infrastructure influence areas, the portion of the flight plan conflicting with the infrastructure, and the specific restrictions affecting the operation, schedule, and current coordination state.

In the initial stages of the workflow, the infrastructure manager can accept or remove restrictions and communicate with drone operators by adding or responding to notes. The state transition model aims to progress a coordination request from “Created” to “Coordinated” status efficiently, requiring minimal input from both infrastructure managers and drone operators.

Once an operation is coordinated, the drone operator and the infrastructure manager would digitally sign a document confirming the coordination. This document is automatically generated by the ACCORD platform. Under the proposed paradigm, the document is initially generated for the drone operator, and after its signature, it is, in turn, transferred to the infrastructure manager for their final signature.

7.3. Ongoing Coordinations

When an operation is ready, the drone operator should notify the infrastructure manager by activating the operation. This action is reflected on the “Today Coordinations” page, which provides operators with a comprehensive view of all operations scheduled for the current day, distinguishing them depending on the state of the operation. This page enables them to manage concurrent events while being aware of all planned and ongoing drone activities in the area surrounding their infrastructures.

As described in the state transition workflow, in the case of emergencies, the platform allows infrastructure managers to notify drone operators by suspending or cancelling individual or multiple coordinated operations across one or more infrastructures. In such a case, drone operators will be notified through the platform and by secondary means like email, SMS, or other instant messaging platforms.

8. Operational Deployment

ACCORD is currently being tested within the Catalonia geographical context. In this region, there are around 100 aeronautical infrastructures. Six airports are managed regionally and nationally. Up to 55 heliports are managed by various Catalan agencies, 20 small aerodromes are managed by individuals, aeroclubs, etc., and some additional heliports are associated with key infrastructures. Article 41 of Royal Decree 517/2024 has defined UAS geographical zones (see Table 3), where any drone operation requires coordination between the drone operator and the infrastructure manager.

At the moment of writing this article, preliminary agreements are in place with Sistema d’Emergencies Mediques de Catalunya (SEM), which manages around 25 permanent heliports located at hospitals. In Catalonia, SEM is leading the development of more efficient procedures for managing the drone coordination process and coordination with manned emergency helicopters. For the first time, SEM is enabling the use of Letters of Agreement and coordination rules tailored to the type of drone operator and the operation nature (see Table 4).

Bombers de la Generalitat, the Catalan firefighter structure, manages a network of 30 permanent and temporary heliports scattered throughout the territory. Aeroports de la Generalitat, the Catalan airport operator, manages three regional airports in the Catalan area. Finally, discussions have also occurred with AENA, the national airport operator that manages the region’s three main international airports.

As previously indicated, SEM applies a risk-based strategy to determine which drone operations within the areas of responsibility around its network of heliports present an acceptable risk and which ones are unacceptable (refer to Table 1 for a summary of EASA’s risk classification). SEM accepts any operation beyond 2500 m from the heliport without further restrictions, regardless of the altitude. When operating closer, coordinations are accepted for open category flights depending on the drone classification (A1–A3) or the STS scenario for the specific category. However, this is limited to operations performed below 60 m. Coordinations are generally rejected above that altitude. See Table 4 and Figure 4 to review the restrictions introduced by SEM.

Below 60 m of altitude, A3 operations are accepted within 2500–1000 m from the heliport. A2 operations are accepted within 2500–750 m from the heliport. A1 operations below 900 gr are accepted within 2500–500 m from the heliport. In addition to the previous areas, A1 operations below 250 gr are additionally accepted within 500–250 m but are limited to 20 m of altitude.

Similarly, STS-02 BVLOS operations with observers are accepted within 2500–1000 m from the heliport, and STS-01 BVLOS operations with observers are accepted within 2500–250 m from the heliport (both limited to 60 m of altitude).

The success of the ACCORD platform will be tied to extending its use to the largest number of aeronautical infrastructures. This process, not driven by the Spanish aeronautical regulator, will only rely on negotiation and persuasion. Within the Spanish context, infrastructure managers are entitled to select which coordination mechanisms they desire to employ, so mixed scenarios in which some managers embrace ACCORD and others employ some other sort of solution would undoubtedly occur. For that reason, it is expected that once a critical mass of users is persuaded, the addition of the rest will be simplified. To cope with this interim process, ACCORD has emphasized supporting drone operators with the capacity to generate the coordination documents necessary to perform a traditional (email-based) coordination process.

9. Operational Evaluation

Introducing a digital platform to manage the coordination processes associated with drone operations has several immediate advantages compared to the current document-based processes. The first and most apparent is that no documents need to be edited, as the platform enables the exchange of the necessary information across all participant profiles, drone operations, and infrastructure managers. In case documentation is needed, it is automatically generated and stored in the ACCORD database, ready for download or signature. A second immediate benefit is that operational information must only be filled out once and then used across all necessary coordinations. In contrast, document-based procedures may require filling a multitude of different documents containing similar information but most likely expressed in various orders and formats. Finally, a third and most important advantage is the fact that ACCORD takes care of validating every one of the infrastructures in potential conflict, taking into account all the geometric conditions (protection areas and associated altitudes), reducing the potential for error to the minimum or skipping required coordinations.

The complexity and burden to drone operators become apparent when we discover that specialized companies have emerged to manage the analysis and execution of all the necessary coordination processes on behalf of drone operators. A quick check on the current pricing shows that each coordination may be charged up to around 30 euros. Such an amount may represent a large quantity at the end of the year.

Even though the advantages above seem relevant enough, it is true that only after the initial deployment of the ACCORD platform and some extensive employment by all the actors involved will its actual advantages and improvement areas be identified. Given that such a milestone lies in the future, an initial comparative evaluation has been carried out by managing the coordination process associated with several drone operations. All the operations have been located close to the Barcelona metropolitan area, one of Catalonia’s densest areas in terms of aeronautical infrastructures. A document-based and ACCORD-based coordination process has been carried out for each test operation.

Collaborating drone operators have been requested to create the coordination documentation for twelve complex operations of various natures within the Barcelona area. Note that the last two operations include large operative areas, which induce a larger burden when processed manually, as the number of individual validations due to the additional waypoints increases. The results, collected in

Table 6. Evaluation of a manually executed coordination management process.

Operation	Wp	T Ck (min)	N Ifr	N Co	T Co (h)	T Doc (min)	T Tot (h)
STGERVASI-BCN001	11	05:30	5	2	01:17	08:00	01:25
CASTELLDEFELS01	13	06:30	1	1	01:11	06:00	01:17
CAMPNOU001	19	09:30	3	3	01:58	10:00	02:08
SEQUIA001	27	13:30	3	1	01:34	06:00	01:40
RADAR001	21	10:30	1	1	01:22	06:00	01:28
INSPECTION	22	11:00	2	2	01:49	08:00	01:57
RUGBY	20	10:00	1	1	01:15	06:00	01:21
ZOO	11	05:30	3	3	01:38	10:00	01:48
RIUCLAR-LEFT	14	07:00	4	3	01:40	10:00	01:50
RIUCLAR-RIGHT	16	08:00	4	3	01:45	08:00	01:53
CANVIDALET001	16	08:00	6	5	03:10	16:00	03:26
BELLVITGE001	29	14:30	3	3	01:57	10:00	02:07

, show that the processing time is divided into two aspects. First, the time required by the drone operator to determine which infrastructures require coordination. This time is directly proportional to the complexity of the operation (to the number of waypoints or areas within the operation) and to the number of infrastructures near the area of operation that may need coordination. Second, the time required to fill out the coordination templates and process their requests through email (the fact that, in some cases, instant messaging may be employed is neglected in this study). Note that in some cases, a single document is required to coordinate various infrastructures (in particular those coordinated by SEM and Bombers).

Table 6 describes details of ten operations with the following information: reference name for the operation (Operation), number of waypoints in the operation (Wp), time in minutes required to check the potential interaction of each waypoint with geographical zones (Ck T), number of infrastructures requiring coordination (N Ifrst), number of coordination processes to be carried out (N Coor), time in hours required to fill out the coordination documents (Co T), time in minutes required to communicate the coordination documents through email (Doc T), and finally the total processing time in hours (Tot T). Coordination times include the effort required to complete all required documents in their precise formats and data order. Moreover, given that the operations mostly occur in the Barcelona metropolitan area, further communication documents need to be generated setting coordination with police authorities. Those documents will be automatically generated by the ACCORD platform if necessary.

Beyond processing the request, significant uncertainty exists regarding the time required to receive a positive or negative response, and this reaction time is dependent on the personnel dedicated to managing the influx of coordination requests at each affected infrastructure manager.

To perform an equivalent comparison, the same operations have been introduced and coordinated through the ACCORD platform (see results in

Table 7. Evaluation of a coordination process managed by MOCCA.

Operation	T Trj (min)	T Op (min)	T Tot (min)	Ifr S1	Ifr S2	Ifr F	N Co	T Cr (s)	T Cc (min)
STGERVASI-BCN001	08:50	05:19	14:09	21	7	4	2	7.4	3:15
CASTELLDEFELS01	06:54	03:54	10:48	15	2	1	1	4.8	0:49
CAMPNOU001	07:01	04:22	11:23	21	5	5	5	7.4	2:49
SEQUIA001	06:30	03:24	09:54	14	4	1	1	1.5	0:51
RADAR001	06:37	04:00	10:37	20	1	1	1	4.8	0:52
INSPECTION	07:52	03:57	11:49	25	4	3	3	6.3	0:55
RUGBY	08:51	04:30	13:21	21	4	3	3	6.7	1:40
ZOO	05:29	03:29	08:58	21	3	2	2	5.5	1:00
RIUCLAR-LEFT	06:09	03:30	09:39	13	4	4	3	4.3	2:28
RIUCLAR-RIGHT	05:27	03:27	08:54	13	4	4	3	4.4	2:32
CANVIDALET001	12:34	09:52	22:26	21	6	6	5	10.7	2:38
BELLVITGE001	13:22	10:43	24:05	21	6	3	3	8.6	2:02

). The process is divided into two phases: first, introduce the operation in the platform by defining the flight area or trajectory as a sequence of waypoints (required time in minutes shown in column T Trj); then, the details of the operations, like description, selection of vehicles and pilots, classification, etc., are defined (required time in minutes shown in column T Op). The total time in minutes required to enter the operation in ACCORD is shown in column T Tot. Once the operation has been introduced, the drone operator selects to coordinate the operation, which initiates a completely automated sequence of evaluation processes.

The time spent entering the operational area or waypoint trajectory has a hidden advantage not considered in this evaluation. The current ACCORD release can directly load flight plans from the most common drones, e.g., those employing Mavlink or DJI vehicles, or even generate those flight plans from the information entered in ACCORD. Hence, that extra effort can be somehow nullified as it is shared with the autopilot trajectory generation effort.

ACCORD evaluates the required coordinations in the four-phase sequence described in the previous sections. First, it must identify the infrastructures near the drone operation based on a fixed distance threshold. The number of such infrastructures is shown in column Ifr S1. Those infrastructures are then further analyzed to confirm that the operation intersects the geographical zones protecting it (shown in column Ifr S2). Then, a detailed analysis is performed for all restriction details associated with the geographical zones, considering flight altitudes, operation periods, drone types, etc. As a result, a final list of infrastructures and infrastructure managers requiring coordination is consolidated. Finally, all the necessary coordination requests are generated and associated with the corresponding entities, completing the request for coordination phase. Columns Ifr F and N Co show the number of infrastructures requiring coordination and the number of involved infrastructure managers. Column T Cr indicates the total computation time needed to complete the overall coordination request process, while column T Cc indicates the total time needed by the infrastructure manager to inspect and approve all coordination requests associated with the operation.

The results demonstrate the benefits of providing a digitalized and highly automated workflow for coordination management. Even for the most complex operations, the initial effort to enter the operation details within the ACCORD platform is limited to a few minutes. Completing the coordination process within ACCORD is accomplished in a few seconds of computation time, followed by a few minutes to complete the inspection and acceptance by infrastructure managers (as reflected in Table 7).

The effort required to operate the ACCORD platform becomes almost negligible compared to the equivalent workload required to analyze, generate, and process the coordination documents manually. Even though the total time required to check for potential coordination requirements manually is limited to a few minutes (between 5 to 14, depending on the situation), the time required to manually fill out the coordination forms and send them to the appropriate recipients by email rapidly increases to values between one and two hours. This time only accounts for the coordination request submission, requiring additional efforts to manually inspect the operations by each of the involved infrastructure managers. Even though we do not have actual measures of such processes for our test set, it is well known that downloading, reading, and responding to each request may take no less than 30 min per request (values described through discussions with various infrastructure managers).

Enabling ACCORD to process the full coordination request process implies direct time and efficiency gains that would enable operators to concentrate on the operation analysis rather than its associated paperwork. Significantly reducing the time to process documentation manually enables both drone operators and infrastructure managers to focus on the key motivation behind the introduction of the coordination process by EASA. First, the risks associated with drone flights are reduced by enabling drone operators to exchange operational information with infrastructure managers effectively. Second, it allows infrastructure managers to communicate better with drone operators regarding the safety boundaries and operational limitations around their infrastructures.

10. Conclusions and Future Work

The regulatory context in Europe is evolving, allowing the progressive expansion of drone operations. In particular, introducing U-space should become a cornerstone for logistic operations in urban areas. However, this fast-paced regulatory evolution lags behind the necessary adoption support for drone operators. This paper has shown that some of these processes induce a huge management burden for drone operators and organizations managing aeronautical infrastructures. Both organizations manually manage the process, with the obvious inherent inefficiencies. The immediate conclusion is that automation and digitalization of processes must also be expanded into that domain.

The ACCORD platform is a step forward in the correct direction. The system transforms the vague “coordination” concept into a formal process, which a digital platform can automate. The coordination process is made efficient by managing the interaction between the drone operator’s mission requirements and the restrictions to operate near an aeronautical infrastructure. Furthermore, the whole process is traceable at any point, including the possibility of exercising some level of strategic negotiation and tactical tracking of drone operations.

Beyond the necessary in-depth evaluation of its current capabilities, it is necessary to expand its objectives into other areas, like coordination with non-aeronautical infrastructures, operations within natural parks or other natural protected areas, coordination with local authorities near urban areas, etc. Some additional functionalities and types of restrictions have been recently identified as relevant. For example, specific validations are performed on the locations where take-off and landings take place, as natural park managers consider those locations to be the ones generating the most negative impact. Extending the tactical capabilities of the platform has also been suggested, including the capacity of drone operators to notify an emergency status associated with their drone operation, especially relevant when operating close to aeronautical infrastructures. All these extensions will be progressively developed and integrated as the involved stakeholders become engaged in the platform deployment.