1. Introduction
The use of unmanned aerial systems (UASs) of various sizes and configurations is already a sound reality in a wide set of civil and military applications. Nonetheless, future use of drones on a large scale in the civil airspace, especially for beyond visual line-of-sight (BVLOS) operations, requires adequate developments which commonly are collectively referred to as UAS traffic management (UTM).
The development of a UTM framework includes technological and procedural aspects which can be grouped into three (strongly interacting) areas:
(1) Technological aspects related to the vehicles and ground technologies supporting UAS operations;
(2) Rules for carrying out drone operations in the civil airspace, especially when a potential conflict with conventional air traffic is possible;
(3) A precise chain of roles and responsibilities for handling UAS operations in a safe manner.
Specific areas, such as airports, that require special attention and management for the safe integration of UAS operations are considered as “critical areas.” These are areas that present one or more of the following risk factors: interference with other operations (e.g., collisions with other aircraft); risks to the security of sensitive infrastructure and people; and risks to the collection of sensitive data.
AcrOSS (Environment for Safe Operations of Remotely Piloted Aircraft) is a research project funded by the Italian Ministry for Research aimed at developing a platform for management of UAS operations in or close to restricted areas, such as the airspace surrounding airports or other sensitive areas, for which access authorization is required. The project included an experimental validation of the whole system, with a focus on the use of small multi-rotor platforms (sUAS) within the boundaries on Grottaglie airport infrastructure, in southern Italy. At a high level, the main objective is to contribute to the development of safe, efficient, and secure integration of sUAS operations in low level airspace, both in controlled (i.e., airport airspace) and uncontrolled airspace, where manned and unmanned traffic coexist. The focus is on the study and development of innovative on-ground and on-board capabilities and technologies which contribute to increase sUAS traffic situational awareness for all involved operators. This is achieved by developing a comprehensive multilayer architecture which implements procedures and enabling technologies into a unique framework, thus connecting UAS operator(s) with conventional air traffic management and control (ATM/ATC) by means of a dedicated platform. In this context, it also addressed the management of contingency situations related to dynamic airspace constraints or unexpected events that may have an impact on safe and efficient sUAS operations.
The final objective is to enhance safety by defining best practices and guidelines for all airspace actors involved in sUAS operations, developing a proposal for the standardization of the procedures based on a set of novel CONcepts of OPerationS (CONOPS), while providing recommendations for regulatory task forces. In the medium term, this effort should contribute to unlocking new potential markets in BVLOS and autonomous operations in sensitive areas, thanks to innovation actions based on the development of new on-board and on-ground enabling technologies, while reducing barriers to equitable access to airspace for all very low level (VLL) airspace users.
More in detail, the main activities within the project can be grouped into three steps. The first phase was focused on ① the analysis of sUAS operations regulatory framework; ② the definition of ad hoc concepts of operations and of a set of requirements for safe operations; and ③ the definition of the high-level architecture of the platform. A second phase followed, aimed at the design and development of the major architecture components, which will be better described in Section 3.2:
• Dynamic drone traffic control support systems in critical areas, at both UAS side and ATC side;
• Multi-channel, multi-constellation Drone Boxes, which are miniaturized devices for the identification and tracking of cooperating drones;
• Innovative Notification and Authorization (N&A) service platform;
• Enhanced small drone radar-based detection and tracking system (DTS) for airport application;
• Scenario simulation and playback investigation platform (SPI).
All elements of the platform were first tested and validated separately. Subsequently, after an integration phase with laboratory testing, the entire platform was tested in a relevant environment at the Grottaglie airport. The testing campaign demonstrated the technical and operational feasibility of the technologies developed and the validity of the platform.
This paper aims at presenting the architecture of the AcrOSS platform, with a focus on the proposed workflow of operations among the N&A platform, the advanced platform, based on augmented reality (AR), for enhanced remote pilot situation awareness and the contingency management system, which includes a trajectory replanning tool. Based on the requirements for the AR platform and contingency scenarios outlined in earlier works
[1],
[2], the present paper describes the implementation of tools for improved pilot’s situation awareness and their integration in a broader context, illustrating the operations that should be performed via the platform in a typical mission scenario. While the two previous papers respectively defined the information shown to the unmanned aerial vehicles (UAVs) pilot through AR
[1] and the possible actions to be taken to manage contingencies that may occur
[2], this new paper describes the result of the full implementation of these functionalities and their integration within a broader platform consisting of various hardware and software elements for planning and managing UAS operations in critical areas. As discussed in detail in the sequel, all these elements were developed at the University of Salento, although the architecture of the system is the result of the joint effort of all project partners (IDS Ingegneria Dei Sistemi SpA, as lead partner, the University of Salento and the University of Bologna, Aeroporti di Puglia, Exprivia, and TopView-UAS Engineering). After the description of the architecture, this paper also reports the results of a test campaign conducted at the Grottaglie–Taranto Airport and the feedback and considerations gathered from the operators involved.
The next section introduces the research context, with a focus on the regulatory framework within which the project was developed, in order to assess the novelty of the contribution developed within the project with respect to current methods. Section 3 on Research Methodology describes the architecture of the AcrOSS platform and its components and then presents and analyzes the workflow of operations. Section 4 summarizes the experimental tests carried out in the Grottaglie–Taranto Airport and reports the feedback collected from the operators. Section 5 analyses the limitations of the proposed architecture and of the test campaign carried out at the airport. A section of concluding remarks ends the paper.
2. Research context
2.1. UAS traffic management: An overview
Various monitoring and simulation tools have been presented in the literature for UTM. A hierarchical UTM system was developed in Taiwan, China
[3] to monitor multiple UAVs flying in visual line-of-sight (VLOS) and BVLOS from near ground to high altitude. After some checks on pilot, UAV registration and flight plan, the proposed UTM controller considers the time to conflict for UAVs approaching the same airspace, sending alerts to pilots’ phones in the attempt of preventing potential collisions.
UTM concepts inspired also the design of a platform for Urban Air Mobility (UAM)
[4]. The system provides a Situation Display and a Grafana Dashboard for the definition of the tasks of a fleet manager or the roles of an air navigation service provider. It allows the investigation of the interactions between conventional commercial and UAM traffic through a simultaneous visualization on different displays. The live video system presented in Ref.
[5] enables remote monitoring of UAV operations for first aid supplies. To this aim, it synchronizes the UAV camera with the operator’s head movement detected by an inertial measurement unit embedded on the virtual reality (VR) headset.
A system providing simulation capabilities for UTM has been developed by National Aeronautics and Space Administration (NASA)
[6]. It includes a display of UTM information and tools enabling the interaction with the research platform. A concept for the management of simultaneous BVLOS operations of multiple small UAS flying up to 1.5 miles (1 mile = 1609.34 m) in the US national airspace was evaluated in Ref.
[7]. The study highlighted the importance of providing each operator with weather information and updates on dynamic changes in airspace. In particular, accurate and timely information about the position of nearby UAS have been considered indispensable for a safe altitude stratification, since pilots have a reduced awareness and an increased reaction time during BVLOS operations. Moreover, attention was paid to keep flight trajectories inside the admissible airspace volume.
CONOPS for civil space traffic management was described in Ref.
[8], where an architecture was defined for an efficient coordination between participants that should allow safe operations in UAS traffic: In this way, the platform allows commercial space management services to co-exist with those provided by the government thanks to a distributed conflict resolution among civil and commercial members.
Several classes of events and the related management operations were defined in Ref.
[9], which proposed a method to handle emergencies autonomously, based on the operational state of the UAS, even though the described Emergency Management service just suggests the UAS pilot some mitigation actions. A decision maker component determines whether a contingency mitigation or an emergency action should be carried out: The former is necessary when the UAS gets out of its flight geometry, which is the airspace for the UAS operations submitted by the operator, while the latter is necessary when the UAS gets out of the operational volume, which increases the flight volume of a buffer for environmental or performance uncertainties.
Various techniques for the identification of safe landing zones in emergency situations were analyzed in Refs.
[10],
[11]. In UTM the concept of geofence has been introduced to represent the boundaries of airspace volumes where UAS flight operations are permitted for a given period of time. A formal definition of geofence can be found in Ref.
[12], which presents algorithms for the spatio-temporal organization of the airspace based on three-dimensional (3D) geofence deconfliction. An approach based on closure rate constraints was proposed in Ref.
[13] to prevent any violation of geofence boundaries and generate timely warnings. The method takes into account UAV dynamics, performance, and sensor uncertainties. The application of 3D flight volumization algorithms for UTM was studied in Ref.
[14], where computational geometry was employed to design flight trajectories inside geofence volumes also supporting multi-vehicle deconfliction. A weighted distance, energy and time cost function was evaluated to rank any admissible path.
An important actor of a UTM system is the UAS Service Supplier (USS), whose duty is to support the safe and efficient use of airspace in accordance with operational requirements by providing services to the Operator
[15],
[16]. To this end, USSs must share information about mission and position of vehicles to reduce the risk of conflicts in a common airspace. The UTM core platform
[17] was introduced to alleviate this burden through a centralized function based on a separation between the low altitude airspace management and the services for UAS operators. Various other works addressed the identification and updating of the optimal trajectory of UAS in the presence of obstacles and when emergencies occur. A temporal and spatial maze routing algorithm for UAS trajectory management in a high-density urban area in presence of both static and dynamic obstacles was presented in Ref.
[18]: It consists of a flooding stage based on a breadth-first search followed by a traceback stage from the destination to the source for path reconstruction.
A methodology for route planning and risk evaluation for UAS missions over populated areas was presented in Ref.
[19]: It discretizes trajectory in motion primitives, evaluates feasibility, and assesses risk based on population distribution. The developed platform consists of a decision support system (DSS) for UAV operators and other decision makers and several dashboards for mission planning. Another DSS for multi-UAV mission planning was designed in Ref.
[20]: It consists of a ranking system, for which fuzzy methods showed the best performance among various multi-criteria decision making methods, and a filtering system, which employs a similarity function and an empirically-tuned threshold to order and reduce the optimal solutions. The continuous state-dependent-transition model described in Ref.
[21] exploits an intent inference for trajectory prediction based on automatic dependent surveillance–broadcast (ADS-B) information. The estimation method is improved by applying a constrained Kalman filter. The trajectory segments are smoothed by means of a Rauch–Tung–Striebel backward method. The proposed method is not yet able to deal with time-varying and dynamic airspace constraints.
As it is apparent from the discussion above, previous studies were mainly concerned with relevant, yet specific, aspects of the problem of UTM in the civil airspace. To the best of the authors’ knowledge, this paper presents and discusses one of the first prototypes of an integrated platform for UTM, characterized by a complex architecture, which implements a wide variety of technologies, including an AR interface, tested and validated in a real operational environment in the Grottaglie–Taranto Airport (Italy).
Drone Response
[22] is a software package for the configuration of multi-sUAS missions under safety requirements. In particular, such work focuses on safety checks aimed at detecting incorrect task sequences, which are analyzed to identify non-deterministic transitions causing unexpected behaviors, non-reachability of states generating deadlocks or livelocks, and undesirable task sequences resulting in mission failures. Thanks to an onboard state machine each UAS can perform various missions, each one described by a specific workflow. In contrast to this work, the AcrOSS platform follows another approach that allows ATC operators to modify airspace constraints during missions to cope with various types of unforeseen events that may occur (such as emergency landings, weather alerts and, even more, undefined events that are difficult to predict) known as “contingencies.” In addition, thanks to the support of AR, the same platform also allows UAV pilots to be informed in real time and suggest optimal maneuvers to be carried out in a timely manner in order to restore safe conditions for UAVs.
2.2. The UAS regulatory framework
The sustainable development of the drone market and its social acceptance depend on effective and transparent guarantees that the operation of this class of aircraft will take place under safe and secure conditions, with constant monitoring of competent authorities. The AcrOSS project, and the platform developed in its framework as the major outcome of the research, were conceived for the European market, hence in this section we focus on European Union (EU) regulations. To ensure legal certainty and consistency across the EU with a vision projected towards a “Single European Sky,” the European Commission proposed a revision of the UAS regulatory framework in December 2015. The result of that proposal was the Regulation (EU) 2018/1139, through which the EU rules civil operations of all types of drones, progressively replacing national regulations on civil operations of drones weighing less than 150 kg. Regulation (EU) 2018/1139 became fully applicable on January 1, 2021. It is accompanied by the Commission Delegated Regulation (EU) 2019/945 and by the Commission Implementing Regulation (EU) 2019/947.
The definition of a homogeneous, coherent, and shared regulatory framework at the European Community level has always been a unanimous request of all stakeholders in the sector and a guarantee of technological, economic, and social development. This was an important turning point for the entire industry, since it provided clarity to a legislative landscape that had previously been fragmented into a myriad of national provisions that did not help to promote the all-round growth of the drone market and even less to regulate its operations and areas of use. Now, Regulation (EU) 2018/1139 provides guidance on data protection, operators training, design, production, maintenance, operation of aircraft, and registration requirements and defines, in Article 55, the essential requirements for unmanned aircraft.
The Commission Implementing Regulation (EU) 2019/947 laid down detailed provisions for the operation of unmanned aircraft systems as well as for personnel, including remote pilots and organizations involved in those operations. Referring to the platform proposed in this paper, the Regulation defines some important responsibilities for the remote pilot (UAS.SPEC.060):
• Before starting a UAS operation, the remote pilot should obtain relevant information about the flight geographical area and ensure that information about the operation has been made available to the relevant air traffic services (ATS) unit, other airspace users and relevant stakeholders;
• During the flight, the remote pilot must adhere to operational limitations of flight zones and must not fly near or within areas where action is being taken in response to an emergency situation.
The Commission Delegated Regulation (EU) 2019/945 laid down the requirements for the design and manufacturing of UASs intended to be operated under the rules and conditions defined in Implementing Regulation (EU) 2019/947 and of remote identification add-ons. It also defines the type of UAS whose design, production, and maintenance shall be subject to certification. On May 12, 2020, the European Commission adopted the Implementing Regulation 2020/639 partially amending Regulation 2019/947. Referring to the platform proposed in this paper, the Regulation sets July 1, 2021 as the deadline for member states to make maps available on airspace allowed/banned to UAS in a single, common digital format. In view of an expected increase in drone traffic, in order to allow unmanned aircraft to be able to operate safely together with existing air traffic, the European Commission has found it essential to develop an ad hoc regulatory framework, with the support of EU Aviation Safety Agency (EASA), for airspace use (i.e., Commission Implementing Regulations 2021/664-665-666). Developments under the AcrOSS project have been guided by the European Commission’s definition of mandatory U-Space services for all UAS operations: ① the network identification service; ② geo-awareness service; ③ UAS flight clearance service; and ④ traffic information service. The role of the USS, first introduced by NASA and Federal Aviation Administration (FAA) and then adopted by EU regulations, has also been incorporated and thus provided for as a role in the AcrOSS framework.
The differences between what is prescribed by the European regulatory framework and what has been developed within the AcrOSS project concern the object of the take-off authorization: a four-dimensional (4D) trajectory within the regulatory framework and segregated areas within the project.
In the “4D trajectory” approach the take-off clearance would involve a precise, time-based flight path that the UAS must follow. The clearance would be integrated with a comprehensive plan that covers the entire flight, including climb, cruise, descent, and landing phases. This method emphasizes predictability and optimization, ensuring that each UAS’s trajectory is managed to fit seamlessly into the overall traffic flow.
In the “segregated areas” approach, the take-off clearance would involve flying the UAS into a pre-defined airspace region that is reserved for specific types of operations. The clearance would specify the boundaries of this segregated area, within which the aircraft can operate without conflicting with other traffic. This approach is more about managing airspace usage through spatial separation, ensuring that different types of operations remain confined to designated zones. From an ATM/ATC perspective, segregated areas offer a straightforward means of managing airspace. By clearly delineating boundaries, it is easier to enforce compliance and ensure that UAS adhere to the rules governing these zones.
In our opinion, both approaches are valid and should not be alternatives to each other but complementary. The approach proposed by the regulations (4D trajectory) fits well in typical logistics scenarios (e.g., parcel delivery) in which it is possible to accurately predict the path that the UAS will have to follow during the mission. In other scenarios, however, such as environmental monitoring or people search, the approach proposed by AcrOSS is considered preferable.
3. Research methodology
3.1. The design approach
The research behind the development of the AcrOSS platform was based on the design research methodology (DRM)
[23], a structured approach that helps researchers systematically address design problems in various contexts, improve processes, and generate knowledge that bridges theory and practice. DRM follows an iterative workflow where researchers often revisit earlier phases to refine their work based on new insights. It consists of the following four phases:
(1) Research clarification, aimed at defining the context, the research problem, and the objectives;
(2) Descriptive study I, which involves collecting and analyzing data about the existing problem, identifying gaps, and understanding the design challenges; it lays the groundwork for developing effective solutions;
(3) Prescriptive study, aimed at developing solutions or methodologies based on the findings from the previous phases; researchers propose models, tools, or guidelines to address the identified issues; the focus is on creating practical and theory-based improvements for the design process;
(4) Descriptive study II, consisting in the evaluation and refinement of the proposed solutions; this phase tests the effectiveness by empirically comparing results with initial objectives to validate their impact and refine them further.
Building on DRMs principles of combining systematic inquiry with actionable results, the Lean Content Design guidelines extend this framework to the context of product-service systems (PSS) development
[24]. These guidelines translate the iterative and evidence-based approach of DRM into a structured engineering workflow based on the PSS lean design methodology (PSSLDM) methodology.
In contrast, Simons model views design as a problem-solving activity, high-lighting the importance of crafting interfaces between systems and stakeholders to manage complexity and adapt to dynamic environments
[25]. While DRM and Lean Content Design emphasize structured methodologies, Simons model is broader, focusing on conceptual problem framing and adaptability.
The design of the AcrOSS platform integrates the structured methodologies of DRM and Lean Content Design to ensure systematic development and stakeholder alignment, while also embodying Simon’s principles of adaptability and interface-focused problem-solving. The identification of operational challenges in congested airspace corresponds to Descriptive study I of DRM, while the development of the UTM platform represents the Prescriptive study phase, where solutions are proposed to address these challenges. Testing the platform in a real-world scenario, such as the Grottaglie–Taranto Airport, aligns with Descriptive study II, validating the solution and gathering feedback for refinement.
The principles of Lean Content Design, which emphasize streamlined collaboration and efficient interaction among system components, led to the integration of three distinct layers in the AcrOSS architecture, described in the next subsection, which ensures efficient interactions among operators. At the same time, the platforms three-layer architecture exemplifies Simons principle of interface design, creating a framework for effective communication and coordination between complex systems. The iterative refinement process, incorporating operator feedback to improve usability and functionality, reflects the Lean Content principle of continuous improvement through real-world data and user input. Simons emphasis on adaptive problem-solving inspired the contingency management and trajectory re-planning functionalities, which allow the platform to dynamically respond to evolving operational conditions.
3.2. The AcrOSS architecture
The proposed platform is based on a clear division of responsibilities between the ATM/ATC operator and the USS: The former handles conventional traffic and weather implications, while the latter handles UAS traffic. One purpose of the AcrOSS project is in fact to avoid the ATC operator having to monitor a potentially large number of small flying objects, leaving him/her only with the task of avoiding interference between conventional and UAS traffic and to report any contingencies, including weather related ones, to all flying traffic in his area of responsibility. In light of this, the AcrOSS platform is organized into three different layers, as shown in
Fig. 1:
• ATM/ATC layer for management and control of manned aircraft and the relevant airspace;
• USS layer for management and control of UAS operations;
• UAS layer.
Together with the listed layers,
Fig. 1 provides the most relevant communication patterns between the main elements of the platform. The details of these elements, the communication patterns and the corresponding protocols are given in the following sections.
ATC and UAS operators/pilots, as well as USS, interact with the platform by means of specific web user interfaces. UAS pilots also interact with the AcrOSS platform by means of an AR headset with a dedicated application and by means of a haptic joystick
[26],
[27]. These latter interfaces were introduced in the system in order to test tools for improving UAS pilot situation awareness in a (possibly dynamically changing) operation environment.
In the AcrOSS platform, a DSS and an airspace replanner are responsible for the dynamic control of the integration of UAS operations with conventional manned air traffic: They work together to handle the re-planning of the air space whenever there is an unpredicted event (e.g., a contingency) that requires to change or cancel the airspace volume available to current UAS operations.
The DTS, which consists of an advanced radar and an electro-optical (EO) system based on a full color 5 megapixels high definition (HD) camera, provides the position of collaborative and non-collaborative UAS’s (including small ones) to the platform modules in charge of handling these data and, when necessary, to security forces. The DTS aims at integrating information provided by existing monitoring infrastructures deployed in airport environment for dynamically managing conventional manned air traffic, thus supporting surveillance of airport sites. It has an output power of 4 watt and operates in the X band frequency. Thanks to an embedded real-time decision support system, it is able to detect any threat in less than 30 seconds in a complex airport scenario, handling more than 50 contemporary tracks in a nominal detection range of 10 km with an azimuth coverage of 2π rad (360°) and an elevation coverage of 0.385 rad (22°)
[28].
The AcrOSS platform supports the USS in the dynamic control and management of UAS operation through an N&A module, a simulation and playback module and a tracking gateway. The first module, the core of the platform, is accessed by the USS and is the collector for all the communications between all the actors involved in the UAS operations. Given the relevance of the element within the platform architecture, details on the N&A module are provided in Section 3.3. The simulation and playback module is in charge of recreating old scenarios (playback) or simulating new ones (such as a contingency event or the presence of a non-collaborative drone) by using existing data collected from previous operations or data derived from simulated (possibly critical) test cases (synthetic data). The tracking gateway collects position data from the DTS and makes them available to the other modules of the platform. For this purpose, as explained in detail in Section 3.5, it exploits the Message Queuing Telemetry Transport (MQTT) protocol
[29] and hosts an MQTT broker, which connects entities sending messages with entities ready to receive them. Mosquitto
[30] was chosen as the MQTT broker to exploit some of its specific flags for a more efficient handling of messages, as will be explained in Section 3.5. Mosquitto was configured to enable secure sockets layer/transport layer security (SSL/TLS) to enhance the security of the AcrOSS platform. In particular:
• SSL/TLS ensures that the data transmitted between the client and the MQTT broker is encrypted to prevent eavesdropping on sensitive information;
• SSL/TLS can validate the identity of both the client and the broker using certificates to prevent unauthorized entities from participating in the communication;
• SSL/TLS ensures that the transmitted data cannot be altered in transit without detection to protect against message tampering or man-in-the-middle attacks.
Although the currently used version 2.0.14 of Mosquitto is compatible with version 5.0 of the MQTT protocol, the features of MQTT v3.1.1 were sufficient for the development of the AcrOSS platform.
The messages exchanged between the various entities are structured in JavaScript object notation (JSON) format.
The UAS subsystem consists of a UAV platform, a ground control station (GCS) and some advanced features specifically developed within the research program, namely an advanced situation awareness module, a contingency manager and a trajectory replanning module. The UAV platform is equipped with a drone box, which includes a global positioning system (GPS) receiver, an ADS-B transponder and a third and fourth generation mobile communication (3G/4G) long term evolution (LTE) subscriber identity module (SIM) for communicating with the DTS.
The advanced situation awareness module is part of the user interface of the AcrOSS platform for the UAS pilot, which guarantees him/her full awareness of the flying area, including operational space modifications due to temporary constraints and air traffic needs. The contingency manager and the trajectory replanning module work in synergy, with the contingency manager module, handling contingencies/emergencies locally. In this context, communications regarding a contingency event, issued by ATM/ATC using the situation awareness module, triggers a series of countermeasures and protocols to preserve flight safety. One of the most important countermeasures is the trajectory re-planning: A new trajectory is defined locally by a specific component and it is sent to the GCS (so that the operator can implement the prescribed route) and to the USS (as a notification).
3.3. Notification and Authorization platform
The N&A manages the processes of ATC, USS, and UAS. The list of the main functions of the N&A platform for the three layers is reported below:
• The ATC layer notifies contingency events and forwards airspace re-plans to the involved USSs and UAS operators;
• The USS layer authorizes flight plans and sends take-off requests, communicates with collaborating sUAS, monitoring flights and access to real-time position information provided by the DTS system via the tracking gateway module;
• The UAS layer submits flight plans and takeoff requests and receives updated information on airspace constraints.
The N&A platform plays different roles within each layer in order to enable the execution of missions. In particular:
• ATC operator for the ATC layer;
• USS operator for the USS layer;
• UAS operator, UAS pilot, and observer for the UAS layer.
As a major task, the ATC operator monitors conventional manned air traffic, but an overview of unmanned operations is also needed. The ATC operator notifies contingency events in the area of responsibility. Once a contingency is notified, the DSS suggests possible countermeasures to the ATC operator, including airspace re-plans, with possible modification, reduction, or cancellation of available airspace volume for UAS operations. The countermeasures suggested by the DSS are either approved or modified by the ATC operator and then notified to the involved USS and pilots.
The USS operator manages the services for unmanned operations at a local level. USS operators have their own area of responsibility, which is a subset of the area under ATC supervision. They are responsible for approving or rejecting flight plans as well as take-off requests, and for communicating with UAS pilots by sending them messages or, in the case of contingency events, by sharing with them information on new no-fly zones. In the latter case, the USS operator may send messages to the UAS pilot indicating maneuvers to be undertaken to deal with the contingency.
The UAS operator may be a company or a private individual who needs to flight and thus reserve an area that will be interdicted to other traffic. They have the option of submitting plans for aerial activities involving one or more drones in a given area that will be approved or rejected by the USS operator. The UAS operator can also enter his or her own fleet within the N&A platform.
The UAS pilot is the one who actually flies the drone during the operations of a plan submitted by the UAS operator. On the day of the operation, the UAS pilot will go to the planned location and perform pre-flight checks. These checks will be sent to the USS operator for approval and, only after receiving permission for takeoff, the UAS pilot will be able to take off the drone, after notifying the start of operations. During the operations, the N&A platform will show to the UAS pilot the position in real time of the sUAS along with the takeoff and landing points, and the emergency landing spots that were defined by the UAS operator during the submission of the flight plan and that the UAS pilot can use if there is a contingency event. The N&A platform also allows the UAS pilot to receive notifications and messages from the USS and, in case of contingency event, to visualize both airspace constraints (e.g., no-fly zones) and any trajectory re-planning.
Finally, the observer is the one who accompanies the UAS pilot during the operation. The observer is also assigned when the flight plan is submitted. He/she has the ability to follow the operation and view the messages sent to the UAS pilot.
3.4. Advanced UAS platform
3.4.1. Head-up display and force feedback
The head-up display consists in an AR application running on wearable smart glasses. The AR display shows an overlay of contextual information. When starting the application, the user is asked to log in by framing a quick response (QR) code, which enables the reception of a message containing take-off approval data (
Listing 1):
A geographic JSON (GeoJSON) section of the take-off approval message contains the geodetic coordinates (latitude and longitude) of the vertices of the polygon delimiting the base and roof of the initial geofence; two other JSON sections, named minimumAltitudeGeofence and maximumAltitudeGeofence, specify the height of the base and roof relative to the ground. In addition, the message contains the geographical coordinates of the landing spots on which the drone can land in the event of an emergency.
The AR application was developed using the Unity 2019 game engine
[31] and version 2.7.3 of the Mixed Reality Toolkit (MRTK)
[32]. Although the Epson Moverio BT-300
[33] headset has often been used for monitoring drones (especially in the Drone first person view (FPV) Edition), Microsoft Hololens
[34] was preferred, as it allows users to see more AR content in space thanks to a wider field of view than the approximately 0.4014 rad (23°) diagonal display of the Moverio BT-300
[35]. This is crucial for more advanced and complex AR experiences, where large amounts of data or interactive holograms need to be visualized. In addition, Hololens allows users to interact with digital content via hand gestures and voice commands.
The main gesture used to interact with the virtual buttons visualized through Hololens is Air Tap (
Fig. 2), which emulates a mouse click on a traditional interface. Starting from the finger position shown in the left-hand side of
Fig. 2, Air Tap consists of bending the index finger downwards until it touches the thumb as if pressing a button in the air, as shown in the right-hand side, and then returning it to its original position.
The boundaries of the admissible area defined by the geofence are represented in AR in the form of a grid. The surfaces of the polyhedra representing the geofences are decomposed into triangles by means of a Delaunay triangulation
[36],
[37],
[38], which maximises the amplitude of the smallest angle and generates as few “narrow” triangles as possible
[39], thus reducing the risk of rounding errors. The geodetic coordinates of the geofence vertices are then converted into Cartesian coordinates in the Universal Transverse Mercator system. The same transformation is applied to the geodetic coordinates of landing spots. Delaunay triangulation and coordinate conversions were performed using geospatial data abstraction library (GDAL)
[40], an open-source library for handling geospatial data. An example of the AR interface during normal operations is reported in
Fig. 3. Each time the flight parameters are received, the application checks the position of the UAV in relation to the geofence. If the UAV is inside, the geofence grid remains blue. If the UAV is rapidly approaching the boundaries of the permitted zone, the color of the grid turns yellow to warn the pilot of the danger. If the UAV is outside the geofence, the application assigns the color red to the grid and activates the trajectory re-planning procedure. The latter provides the pilot with an indication on the best strategy to bring the UAV back inside the admissible flight volume. This visual information is complemented by a force feedback produced by a joystick
[26],
[27] to further enhance the pilot’s situational awareness. In order to provide advance perception of impending collisions and guide the pilot in the actions to be taken, the force feedback simulates the UAV’s contact with the virtual fences. The pilot may follow such a suggestion, but will always be able to override it, in order to preserve full authority, provided the pilot remains responsible for all UAV operations.
A 3D model of the UAV is shown at the bottom center of the display, representing the attitude of the vehicle in space, which may not be perfectly visible to the pilot, when an sUAV is in the distance. The percentage of remaining battery power of the UAV is shown in the bottom right corner of the display. Direction, speed, and altitude during flight are represented as graduated scales on the display top, left, and right sides, respectively. The angle of direction, speed, and altitude are indicated on these scales by cursors in the shape of green, yellow, and light blue squares, respectively. Landing points are represented as circles of different colors, depending on whether they are standard or emergency landing points.
3.4.2. Contingency management and trajectory replanning
A contingency event involving a given ATC operator and a given USS operator is notified through a JSON message sent on an MQTT topic of the type across/<id_company_atc>/<id_company_uss>/emergencyMessagesForDrones:
Contingency notifications are sent to the instances of the AR application running on the headsets of only UAS pilots operating in the area managed by a given ATC and USS, identified by the
id_company_atc and
id_company_uss parameters respectively. This is made possible by the subscription that such AR clients make on that MQTT topic immediately after the take-off approval. Each time a notified contingency imposes a reduction in the permissible volume for operations, the application calculates the difference between the volume of the current geofence and the volume of the interdicted zone (red geofence) described in the contingency message (
Listing 2).
If the UAV is outside the permitted volume due to a pilot error, the optimal trajectory to bring it back inside in the shortest possible time is calculated. To this aim, the trajectory re-planning algorithm finds the shortest segment between the UAV’s position and the nearest face of the geofence. The waypoints of the suggested route to bring the UAV back into the permitted zone are, in addition to the current position (starting point), the entry point into the geofence and a point within the geofence. Contextually, an overlay message on the AR display prompts the pilot to perform the maneuver as quickly as possible.
If the UAV is outside the permitted volume due to an airspace restriction, the same procedure is applied to find the trajectory to bring it back inside the new geofence, obtained as the difference in volumes between the previous geofence and the restricted zone. In this case, the maximum time within which to execute the maneuver is also calculated as the difference between the instant when the airspace restriction begins to be valid and the current instant of time. Based on this parameter, a recommended speed for the pilot to execute the maneuver in time is also estimated.
In both cases the UAV is outside the geofence, the AR display draws the geofence in red and shows arrows indicating the path to bring the UAV within the permitted zone, while the bottom left shows the total distance to be flown (
Fig. 4). In the case of an airspace restriction, the AR display also shows the maximum time available to perform the maneuver and the recommended speed. The geofence turns blue again when the UAV is back in it.
If the contingency results in the complete cancellation of the volume previously available for operations or the UAV cannot be driven back into the new geofence within the imposed timeframe, the re-planning algorithm identifies the shortest path to bring the UAV back to the starting point. If the UAV cannot reach the operator in the time imposed by the contingency, the trajectory re-planner evaluates the possibility of landing at the landing spot chosen in the initial planning of the mission or, if this operation also takes too long, it suggests the closest landing spots among a set of emergency ones. In any case, the AR display shows the pilot the suggested trajectory until landing at the identified landing spot, indicating in the lower left corner the distance to reach it (
Fig. 5).
The operations just described for handling contingencies are represented by the manage contingency function of pseudocode 3 (
Listing 3).
The UAVtoSafePosition function in pseudocode 4 (
Listing 4), on the other hand, represents the algorithm for suggesting operations to bring the UAV to a safe position in the shortest possible time when it cannot be returned to the geofence or when the geofence has been removed completely.
3.5. Communication protocol
The advanced UAS platform receives real-time contingency data in the form of JSON messages via Message Queuing Telemetry Transport (MQTT)
[29], a communication protocol designed for devices with limited resources that guarantees a low overhead of communication messages, resulting in reduced bandwidth occupancy and battery consumption. To this end, the application connects at start-up to an MQTT broker installed on the Tracking Gateway, which forwards messages published by publisher entities in relation to a specific topic to other subscriber entities that are interested in receiving that specific type of message. When an entity depicted in
Fig. 1 needs to send a message, it publishes it via the tracking gateway with the indication of a topic. Only those entities that have subscribed to that specific topic when connecting to the tracking gateway, that is, those to whom the message is relevant, will receive it.
By setting a special MQTT flag, called retained, to TRUE in the publish of a message, it is possible to ensure that it is also delivered to clients who subscribe to the topic at a later time. If more than one message is published consecutively on the same topic, the mere use of the retained flag ensures, however, that only the last in a sequence of such messages will be delivered to each client who performs a subsequent subscribe. This limitation may be overcome by parameterizing the topic with a timestamp or an increasing numeric identity (ID) and using a wildcard to receive all messages as this parameter changes.
However, if a client were to lose the connection and then reconnect, repeating all the subscriptions made earlier, it would risk receiving again all the messages already received and processed previously. To avoid this inconvenience, in addition to setting the retained flag, it is necessary to adopt persistent MQTT connections, which allow the state of subscriptions already made to be restored without having to repeat them. In this way, the disconnected client, after having performed only one connection, can continue to receive new messages related to previously subscribed topics, but will not receive old messages related to the same topics again. The MQTT libraries provide flags, such as clean session, which must be set to FALSE to obtain a persistent connection.
3.6. Workflow of operations
In order to better illustrate the functioning of the entire system, a description of a workflow of operations from planning to the end of the mission is depicted in
Fig. 6 using the Business Process Model and Notation (BPMN). BPMN
[41],
[42] is a standard developed by the Object Management Group (OMG) with the aim of providing a notation understandable by both business analysts and technical developers and filling the gap between the business process design and the process implementation.
The operations that are part of the workflow are carried out through the modules of the N&A platform. If the UAS operator needs to perform a mission in a sensitive area (e.g., within or near the airport grounds), he/she has to submit a plan for operations through the web interface (
Fig. 7,
Fig. 8) that allows him/her to:
• Choose the ATC area in which he/she wants to operate and subsequently a USS that is responsible for that area (
Fig. 7);
• Define on a map the flight volume in which he/she intends to operate (
Fig. 7);
• Enter additional flight plan information, such as the UAV, activity, pilots involved, takeoff, and landing points, and so forth (
Fig. 8).
At this stage it is particularly important for the UAS operator to indicate appropriately distributed landing spots on the map to be used when an emergency occurs. All this information is put into a JSON message which is sent via the MQTT protocol, as described in Section 3.5. The USS operator will be able to approve or reject the flight plan by accessing the N&A platform.
When the UAS operator enters all the information, the flight plan can be submitted. The USS operator receives the complete flight plan, analyzes it, and decides whether to approve it or reject it. If the flight plan is approved, the UAS pilot along with any observers goes to the mission site on the day of the mission. The UAS pilot performs the necessary pre-flight checks through the interface shown in
Fig. 9 to ensure safe operations and sends the results to the USS operator to request takeoff approval.
The USS operator receives the pre-flight checks sent by the UAS pilot, analyzes them, and decides whether to authorize or deny takeoff through the interface shown in
Fig. 10. The operations described in this section involve only one UAS and its operator, but can easily be extended to several UAS and operators, as the platform gives the possibility to manage different flight volumes avoiding overlaps in space and time.
Upon receiving takeoff approval from the USS operator, the UAS pilot, equipped with the AR headset, scans a QR code from the N&A platform to connect to the platform and receive mission relevant information (e.g., geofence, takeoff point, landing point). After acquiring this information, the UAS pilot can start operations with a click in the N&A platform interface or with an Air Tap gesture (introduced in Section 3.4.1) in the AR application; in both cases, the USS operator will receive a notification.
Once the mission has started, the USS operator and the UAS pilot can view via the N&A platform a map page showing various information (e.g., drone location, reserved flight volume, any interdicted areas, takeoff and nominal landing spots, in green and yellow, respectively, and available emergency landing spots, in red) and a box containing all messages exchanged. An example of the interface is shown in
Fig. 11. Similar information is visible to the UAS pilot through the AR display, which presents an overlay of various information as described in Section 3.4.1.
When a contingency needs to be reported, the ATC operator can report it through the appropriate functionality developed in the N&A platform. Currently, the contingencies that the platform allows to be reported are emergency landings or weather alerts, in both cases with low, medium, or high severity, corresponding to the colors yellow, orange, and red. Before reporting the contingency, the ATC operator selects the USS to which he/she intends to send the contingency and then selects a contingency type; the latter will be sent to the DSS of the AcrOSS platform, which will suggest to the ATC operator the best action to take (e.g., airspace replanning), based on an elementary decision table. In the case of airspace re-planning, the new area, if any, interdicted to unmanned flight, will be calculated. The ATC operator can view the interdicted area(s) suggested by the DSS on the map and decide whether to accept it or modify it (in the second case the ATC operator can draw the new interdicted area on the map). Then the ATC operator defines the start and end time of interdiction of that area and sends this information to the USS operator and the involved UAS pilots through the interface shown in
Fig. 12.
Once the UAS pilot has been notified of the interdicted area, the trajectory re-planner is activated, whenever the drone is outside of the airspace volume available for safe operations during the contingency or if the volume is canceled. The re-planner task is to determine the optimal trajectory that takes the drone to a safe position in the shortest possible time, based on the new airspace constraints, current contingency event, and drone operational parameters and performance limits. The outcome can be any of the following options: reach the admissible airspace volume; and fly back to the landing site or land in an emergency landing spot. The re-planned trajectory is notified to the USS, who can monitor the situation and possibly send text messages to the UAS pilot. Finally, the UAS pilot is responsible for communicating via the N&A platform the end of the mission.
4. Results and discussion
4.1. Experimental tests
The functionality of the AcrOSS platform was tested at the Grottaglie–Taranto Airport, both to validate its functioning and to collect feedback from operators, by means of interviews right after the end of the tests.
The UAS chosen for testing the AcrOSS platform was the DJI Mavic 2 Enterprise Dual quadcopter
[43] in free flight configuration, recognized by the Italian Civil Aviation Authority, whose technical specifications are shown in
Table 1.
The ground risk buffer for the untethered UAS, that is, the safety zone delimited around the flight path to mitigate risks associated with potential accidents, was defined in compliance with the prescriptions of ENAC (Ente Nazionale per l’Aviazione Civile, i.e., the National Civil Aviation Authority in Italy) as reported in
Table 2. Given the operational maximum height
H of 70 m above ground level, a 20 m minimum buffer
b per side was considered appropriate, with the layout depicted in
Fig. 13.
The operational limitations for the area chosen for the flight tests are reported in
Table 3.
Each experimental test began with the reservation of the flight area and compilation of the flight plan by the UAS operator. Subsequently, the flight plan was approved by the USS. After approval, the UAS pilot would complete the pre-flight checks to request take-off clearance from the USS. Once permission was granted by the USS, the UAS pilot would begin operations.
The flight parameters (speed, altitude, direction, drone attitude, remaining battery charge) and the boundaries (geofences) delimiting the permissible volume for operations were displayed and updated in real time in the AR application running on the headset. The geofence correctly and promptly changed color to signal the potential violation. In some tests, fake contingencies were generated and the correct exchange of messages between the ATC operator, UAS pilot, and USS involved was tested. The operation of the contingency manager was tested by varying conditions and parameters such as the number of waypoints to be crossed and the distance to the perimeter of the permitted area. Non-cooperating drones were also simulated during a real flight. In cases of restriction of the allowable space, the geofence displayed in augmented reality was updated correctly and guidance was provided to the pilot on the path to take to bring the drone back within the new allowable space or to the nearest landing spot.
4.2. Feedback from operators
The detection system based on the Drone Box, developed by IDS, was positively evaluated, especially for freight transport applications in urban environments, where short-range networks would have major limitations, unless a suitable infrastructure is available. The detection of non-cooperating drones, based on a radar system developed by IDS, which guarantees an error of the order of a few meters with respect to the actual position, was also considered as a relevant feature of the system, even though the radar signature of a drone is extremely low and the detection range is limited to a few kilometers. This clearly poses a problem for the coverage of wide areas. As a consequence, the system will be implemented only close to areas that require a higher-than-average security level, such as airports, military zones, critical infrastructure, and so forth.
The flight plan submission system of the N&A platform was particularly appreciated during the airport tests, due to its user-friendly interface that allows intuitive booking of the flight area through cartographic tools. The airport staff managing the booking process at Grottaglie airport recognized a significant operational advantage in using the flight plan submission system because:
• It standardizes the booking/authorization process, both in terms of compilation and authorization;
• It makes it more streamlined, thanks to the dematerialization of documents;
• It makes it traceable, thanks to the presence of a historical database.
However, some improvements were suggested that could make the tool even more efficient, such as:
• Information on weather forecasts when submitting the flight plan (e.g. from public application programming interfaces (APIs));
• Extension of the cartographic map (e.g., aeronautical maps);
• An “alert” during flight booking (e.g., “bad weather on selected date,” “selected area already booked in that time slot”).
Pilots and personnel involved in monitoring operations have highlighted the benefits in terms of safety of using the unmanned traffic supervision system offered by the N&A platform, due to the increased awareness of what is happening during the flight and the possibility for the USS Operator to intervene promptly and effectively if necessary. In fact, the N&A platform allows the creation and sharing of geofences in order to separate the space allocated to the different flight operations and to dynamically reshape flight volumes as needs arise.
Suggestions for improvement, which deserve attention in future release of the platform are as follows:
• The extension of the cartographic base (e.g., aeronautical maps);
• The possibility of being able to decide between a 2D view of the scenery (as now implemented) and a 3D view;
• The integration of the conventional manned traffic component within the same view as the unmanned one;
• The integration of real-time weather information such as cloudiness, precipitation, and wind;
• The introduction of automatically generated text messages (e.g., in case of adverse weather).
The simulation and playback module, developed by Exprivia, interacted correctly with the rest of the platform during all experimental validation tests. This feature was seen as a quick and powerful experiential learning tool to improve system performance, since it allows to conduct effective debriefing sessions, during which operators reflect on a recent experience and identify opportunities for improvement, verifying the achievement of objectives and critical aspects of the mission performed, in order to re-plan it in a safer and/or more effective manner for future operations.
Finally, the use of an AR headset combined with a haptic controller was considered very useful by the pilots to increase the level of awareness of operations and the level of attention. The intuitivity of the interface and readability of relevant information was highly praised. Some critical issues highlighted concern:
• The wearability of the visor, which if worn for a long time can lead to fatigue, mainly of the neck and shoulders;
• The visibility, in high external light conditions, of the information provided by the visor;
• The generalization/standardization of the interface between the haptic controller and the drone’s command and control system.
5. Contribution and limitations
The progress achieved in recent years by aerospace applications, and in particular those relating to unmanned traffic, is linked to the rapid development of enabling digital technologies. The concept of situational awareness, that is, the possibility of acquiring increasing amounts of detailed information and being able to manage it effectively, in terms of the quality of perception in the monitoring, control and management of critical scenarios, is opening up new horizons and new prospects for development. In this context, the main impacts expected from the adoption of the AcrOSS platform are:
• Increased safety for all airspace actors and ground personnel through improved airspace management at low altitude;
• New procedures for actors involved in low-altitude sUAS operations in sensitive areas;
• Contribution to the standardization of new CONOPS, with a focus on BVLOS and autonomous operations and recommendations for the creation of guidelines and regulations;
• Unlocking potential new markets related to the possibility of BVLOS and autonomous operations in sensitive areas;
• Contribution to the development of new enabling technologies and capabilities for the adoption of the European U-Space concept;
• Availability of tools to validate the development of new operational concepts and demonstration exercises;
• Reduction of barriers to equal entry into low-altitude airspace for all operators.
Some limitations of the implemented platform relate to the ergonomics of the headset used, which may prove somewhat cumbersome for prolonged use and may not guarantee perfectly sharp images in brightly lit scenarios during particularly sunny days. With a porting of the GDAL library to Android systems, the AR application could also be made to work on lighter headsets, perhaps even equipped with dark plates on the lenses to counteract excessive sunlight. A compromise would have to be found, however, between the lightness of the headset and the presence of more advanced functionalities such as voice command recognition. Such commands could be useful to make the consultation of the head-up display easier, as they would allow the user to activate or deactivate the visualization of information while avoiding clogging the AR interface with an excessive number of graphic and textual elements.
Other limitations concern the integration between some system components. In the architecture of the advanced UAS platform, communications between the Hololens headset, the haptic joystick and the UAS radio controller were implemented in the form of JSON messages exchanged via the MQTT protocol. In this way, it was possible to develop a system that does not require hardware modifications to the UAS controller and is not bound to a specific model of radio control. However, in the future, a more efficient platform could be achieved if major UAS manufacturers decide to integrate haptic joystick logic directly into their controllers. If, on the other hand, the haptic joystick and the radio control were to remain separate, it would still be possible to improve the performance of the system by setting up a direct communication channel between the two devices and avoiding the transit of messages through an MQTT broker. A communication protocol such as Bluetooth Low Energy, supported by Hololens, or WiFi-Direct, supported by Hololens 2, could be used for this purpose.
It would be necessary to design an accurate model to modulate the force returned by the haptic joystick according to various parameters, such as the speed at which the UAV is approaching the boundaries of the geofence. Furthermore, various parameters of force feedback would require accurate force calibration through tests involving various pilots to account for various levels of sensitivity that might vary from person to person.
The main limitation of the test campaign is the small number of UAS pilots who were involved in the tests. Moreover, among the various critical operational scenarios for which the AcrOSS platform was designed, tests were only conducted in the airport scenario.
By extending the experimentation to a few dozen pilots, it would be possible, in addition to collecting qualitative feedback, to administer standard questionnaires such as System Usability Scale (SUS)
[44], User Experience Questionnaire (UEQ)
[45], and NASA-Task Load Index
[46] to evaluate the usability, user experience and ergonomics of the advanced UAS platform. Such tests would also be useful to carry out comparisons between several headsets in UAS piloting support in order to identify which compromise between functionality and ergonomics would satisfy users the most. In such a context, the improvement in situational awareness under various conditions could be assessed more accurately by using the Situational Awareness Rating Technique (SART) questionnaire
[47], which gives indications about supply of attention, demands upon attention and degree of situational understanding. A variant for UAVs
[48] of the Cooper–Harper scale, which is typically used to evaluate the handling qualities of aircraft while performing a task during a flight test
[49], could also be employed.
6. Conclusions and future work
The paper describes the AcrOSS platform, designed to provide an interface between ATCs and UAS operators and pilots. At an architectural level, the platform works as an interface for a USS, to interact with ATM/ATC at a higher level and UAS operators and pilots at a local one. Such a figure will provide in the future the required assistance for managing UAS operations in the controlled airspace, also in critical areas. The modules developed within the research program include: ① innovative N&A service platform; ② dynamic drone traffic control support systems in critical areas, at both UAS side and ATC side; ③ multi-channel, multi-constellation Drone Boxes; ④ enhanced small drone radar-based DTS for airport application; and ⑤ SPI. The structure and the workflow were kept as simple as possible in order to allow for efficient and timely communications during standard operations (e.g., take-off notifications) or contingencies (e.g., available airspace for UAS operations reduced or canceled).
After validation of the individual components and their integration, the entire platform was tested in a dedicated experimental campaign carried out in the Grottaglie–Taranto Airport (Italy), which proved not only the successful implementation of each physical and digital module of the architecture, but also their efficient interactions during a simulated contingency. The operators provided very useful feedback and suggestions for improvement on the main functionalities and components of the AcrOSS system.
The main limitations concern some possible ergonomic issues of the headset, the communication between certain components, which could be optimized by testing other protocols, and the small number of UAS pilots involved in the tests, which did not allow for more accurate evaluations in terms of usability, user experience, and ergonomics.
Future work will be aimed at testing the platform in critical scenarios different from airport sites and obtaining more comprehensive feedback for the evaluation of the user experience and the improvement of situational awareness through AR interfaces. Such tests will also allow the force feedback provided by the haptic joystick to be more accurately calibrated to the users’ sensitivity.
In addition, weather forecast information obtained by querying public APIs will be integrated into the platform: This will be relevant in the planning of flight plans and will make it possible to wisely suggest suitable times for UAS missions also based on wind direction and intensity.
CRediT authorship contribution statement
Valerio De Luca: Writing – review & editing, Writing – original draft, Validation, Software, Methodology, Investigation, Formal analysis, Data curation, Conceptualization. Claudio Pascarelli: Writing – original draft, Visualization, Validation, Methodology, Investigation, Formal analysis, Data curation. Mattia Colucci: Writing – original draft, Visualization, Validation, Methodology, Investigation, Formal analysis, Data curation, Conceptualization. Paolo Afrune: Writing – original draft, Visualization, Validation, Software, Investigation, Data curation. Angelo Corallo: Supervision, Project administration, Funding acquisition. Giulio Avanzini: Writing – review & editing, Writing – original draft, Validation, Supervision, Project administration, Methodology, Funding acquisition, Conceptualization.
Declaration of competing interest
The authors declare the following financial interests/personal relationships which may be considered as potential competing interests: Giulio Avanzini reports financial support was provided by Italian Ministry of University and Research. If there are other authors, they declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.
Acknowledgments
The research was supported by the European Union and Italian Ministry of University and Research through the call PON Research and Innovation 2014–2020, Axis II, Action 2, project AcrOSS (Environment for Safe Operations of Remotely Piloted Aircraft), project number ARS01_00702-CUP: F36C18000210005.
The authors also express their sincere gratitude to Marianovella Mello, for her contribution as Project Manager. The authors also acknowledge the contributions of Silvano Pagone and all the project partners to the development and critical review of the AcrOSS platform architecture.
PDF
(4164KB)
