Development of a Flexible and Expandable UTM Simulator Based on Open Sources and Platforms

: In order to study air trafﬁc control of UAS’s (Unmanned Aerial Systems) in very low altitudes, the UTM (UAS Trafﬁc Management) simulator has to be as ﬂexible and expandable as other research simulators because relevant technologies and regulations are not matured enough at this stage. Available approaches using open sources and platforms are investigated to be used in the UTM simulator. The fundamental rationale for selection is availability of necessary resources to build a UTM simulator. Integration efforts to build a UTM simulator are elaborated, using Ardupilot, MavProxi, Cesium, and VWorld, which are selected from the thorough ﬁeld study. Design requirements of a UTM simulator are determined by analyzing UTM services deﬁned by NASA (National Aeronautics and Space Administration) and Eurocontrol. The UTM simulator, named eUTM, is composed of three components: UOS (UTM Operating System), UTM, and multiple GCSs (Ground Control Stations). GCSs are responsible for generation of ﬂight paths of various UASs. UTM component copies functions of a real UTM such as monitoring and controlling air spaces. UOS provides simulation of environment such as weather, and controls the whole UTM simulator system. UOS also generates operation scenarios of UTM, and resides on the same UTM computer as an independent process. Two GCS simulators are connected to the UTM simulator in the present conﬁguration, but the UTM simulator can be expanded to include up to 10 GCS simulators in the present design. In order to demonstrate the ﬂexibility and expandability of eUTM simulator, several operation scenarios are realized and typical deconﬂiction scenarios among them are tested with a deconﬂiction algorithm. During the study, some limits are identiﬁed with applied open sources and platforms, which have to be resolved in order to obtain a ﬂexible and expandable UTM simulator supporting relevant studies. Most of them are related to interfacing individual sources and platforms which use different program languages and communication drivers.


Introduction
UTM (Unmanned aircraft system Traffic Management) is a concept that brings an automated ATM (Air Traffic Management)-like system to very low level airspace which will be occupied primarily by unmanned aircrafts weighing less than 25 kg (commonly referred to as drones). A number of conceptual frameworks, platform architectures, methodologies, and practical demonstrators have been developed across the globe over the last few years to attempt to tackle the complex challenge of how all of this civilian UAS (Unmanned Aerial System) traffic management activity is actually going to work. These activities are in response to modern world expectations and commercial service demands, and are counterbalanced by technology developments and regulated operation. communication drivers and limits of inserting 3D objects in its 3D maps. For 2D and 3D visualizations of maps, air space information and graphic UAS models, GIS platforms of VWorld and Cesium are streamed and integrated in real time.
Integration efforts to build eUTM simulator were elaborated, using Ardupilot, Mission Planner, MavProxi, Cesium, and VWorld. Most of them are related to interfacing individual sources and platforms, which use different program languages and communication drivers. In order to demonstrate the flexibility and expandability of eUTM simulator, typical deconfliction scenarios [1] were also tested with a deconfliction algorithm [19]. During the study, some limits were identified with applied open sources and platforms, which have to be resolved in order to obtain a flexible and expandable UTM simulator supporting relevant studies. The technologies applied to the UTM simulator can also be utilized in smart GCS (Ground Control Station), UAS-based EW (Electronic Warfare), and real UTM systems. In order to demonstrate the applicability to EW, an aerial EW scenario was also generated.

Rationale for Selection of Open Sources/Platforms
The objective of this review is to determine the most reliable and effective UAS/UTM simulation architecture for research, industry collaboration, and product deployment, and the relevant analysis, which shall be applied to eUTM simulator. As mentioned in the introduction, there exist at least five UAS/UTM simulation frameworks based on open sources and platforms in the UAS community: AirSim, Gazebo, jMavsim, ROS, and ArduPilot-Mission Planner. AirSim is an open source, cross platform simulator for UAS, ground vehicles such as cars and various other objects, built on Unreal Engine 4 as a platform for AI research. AirSim is developed by Microsoft and can be used to experiment with deep learning, computer vision, and reinforcement learning algorithms for autonomous vehicles. Gazebo is an open source 3D robotics simulator. Gazebo integrates physics engine, OpenGL rendering, and support code for sensor simulation and actuator control. jMAVSim is a simple multirotor/quadcopter simulator that allows flying copter type vehicles running PX4 around a simulated world. It is easy to set up and can be used to test that a vehicle can take off, fly, land, and responds appropriately to various failure conditions. ROS (Robot Operating System) is robotics middleware (i.e., collection of software frameworks for robot software development). Although ROS is not an operating system, it provides services designed for a heterogeneous computer cluster such as hardware abstraction, low-level device control, implementation of commonly used functionality, message-passing between processes, and package management. ROS is familiar to the UAS community and provides appropriate drivers to communicate with most of the commercial autopilots. Moreover, ROS is integrated with Gazebo simulator, which has a large variety of available UAS models. These frameworks can be used for developing a UTM simulator. The main driving factor in selecting a UTM simulator platform is availability of resources to develop a simulator applicable to the national airspace of South Korea. Besides, most autopilots and ground control stations of real UASs are based on ArduPilot and Mission Planner in the international and Korean UAS communities, while very limited information is available for other aforementioned simulation frameworks. Thus, the simulation framework of Ardupilot/Mission Planner/MavProxi was selected in this research, with Mission Planner replaced by its short version, MavProxi, for real-time simulation. This is another criterion in selection of the simulator framework, which will lead to minimum discrepancy between real and virtual worlds. Besides, ArduPilot and Mission Planner have been used for years in mixed-reality-based GCS study, and have proven to be reliable for both real UAS's FCC (Flight Control Computer) and virtual simulation [18].
ArduPilot is one of the most advanced, full-featured, and reliable open source autopilot software available in the UAS community. It is the autopilot software capable of controlling almost any vehicle system, from conventional airplanes, quadplanes, multirotors, and helicopters, to rovers, boats, and even submarines. The ArduPilot project is made up of ArduCopter, ArduPlane, ArduRover, ArduSub, and Antenna Tracker. ArduCopter is of special interest in this study, and can be used for simulation of multirotor/helicopter UASs. ArduCopter runs on ArduPilot (SW)/Pixhawk FCC (Flight Control Computer) HW. Adding GPS, this ArduPilot/Pixhawk becomes a complete UAS solution that sets it apart from traditional multirotors, which often only support remote control. The ArduCopter system features fully autonomous waypoint-based flight, with mission planning and realtime telemetry via the powerful ground control station. ArduCopter code is capable of controlling all of the major rotor wing airframes, including traditional helicopters, tricopter, quadrotor, hexa, and octa. SITL allows running ArduPilot on a desktop PC (Personal Computer) directly, without any special hardware. It takes advantage of the fact that ArduPilot is a portable autopilot that can run on a very wide variety of platforms. A PC is just another platform that ArduPilot can be built and run on. When running in SITL, the sensor data comes from a flight dynamics model in a flight simulator. ArduPilot has a wide range of vehicle simulators built in, and can interface to several external simulators. This allows ArduPilot to be tested on a very wide variety of vehicle types. Mission Planner is a ground control station for plane, copter, and rover. It is compatible with Windows only. Mission Planner can be used as a configuration utility or as a dynamic control supplement for an autonomous vehicle. MAVProxy is a fully functioning GCS for UASs, designed as a minimalist, portable, and extendable GCS for any autonomous systems supporting the MAVLink protocol (such as one using ArduPilot), and runs on any POSIX OS and Windows with python. MAVLink is a very lightweight messaging protocol for communicating with drones (and between onboard UAS components). Integrating ArduPilot SITL, ArduCopter, and MAVProxy with 3D visualization services, a UTM simulator based on open sources and platforms can be configured with additional modules to provide security, information, and flight services.
Three-dimensional visualization of geoinformation is important in UTM simulation due to UAS's very low-altitude flight under 150 m height from the ground. There exist obstacles such as buildings, bridges, and so on, which are of no concern to manned airplanes and ATC/M. There exist several 3D visualization platforms providing users with SDKs for inserting 3D objects into the virtual spaces. Google Earth, Bing Map, and AirMap are good candidates for 3D visualization with geospecific information. The main issue in realizing a UTM simulator is whether it is easy or possible to insert geospecific information, restricted/prohibited airspace markers, geofences, 3D objects, and so on. Visual update rates and qualities are of concern, too. VWorld is also considered in this study because of availability of necessary tools and local airspace information. VWorld 3D map service has been developed under the sponsorship of the Korea Ministry of Land and Transport, and it provides services that enable users to see a map through the open platform. There remain some technical issues in VWorld to be resolved in order to realize a practical UTM simulator. Simply speaking, VWorld does not allow external 3D objects such as drones and geofences, and its visual update rate is very poor, less than 10 Hz. From the perspective of this research, none of the aforementioned visual platforms are satisfactory now, because they are designed not just for UTM or UTM simulators. Thus, Cesium was selected for the basic visualization platform because of the availability of these utilities, and local airspace information directly came from VWorld. As a result, a hybrid streaming approach was determined to be used in the eUTM simulator.

Design Requirements of eUTM Simulator
Typical UTM services have been determined by aviation authorities in US, Europe, China, and many other countries. They are about the same, and classify UTM services in four levels or stages [1,2]. Copying the concept of European UTM, named U-Space, four service levels are foundation (U1), initial (U2), enhance (U3), and full (U4). Similarly, US NASA also defines TCL (Technical Capability Levels) from one to four. The UTM research simulator, named eUTM simulator, was designed to support UTM services up to TCL 4 or U4. Because the UTM simulator has to accommodate new research subjects and simulation of VLL (Very Low Level) urban airspace environments, the following design principles of eUTM simulator were determined: Applicable to training of UTM operators by augmenting pre-flight procedures even before the UTM concepts and relevant rules are confirmed by international communities.

A Prototype of eUTM Simulator
The UTM simulator, eUTM, is composed of three components: UOS (UTM Operating System), UTM, and multiple GCSs. GCSs are responsible for generation of flight paths of various UASs. UTM component copies functions of a real UTM such as monitoring and controlling air spaces. UOS provides simulation of environment such as weather, and controls the whole UTM simulator system. UOS also generates operation scenarios of UTM, and resides on the same UTM computer as an independent process. The system configuration and relevant UIs are illustrated in Figures 1-6. Two GCS simulators are connected to the UTM simulator in the present configuration, but the UTM simulator can be expanded to include up to 10 GCS simulators in the present design.
NASA also defines TCL (Technical Capability Levels) from one to four. The UTM research simulator, named eUTM simulator, was designed to support UTM services up to TCL 4 or U4. Because the UTM simulator has to accommodate new research subjects and simulation of VLL (Very Low Level) urban airspace environments, the following design principles of eUTM simulator were determined: • Applicable to training of UTM operators by augmenting pre-flight procedures even before the UTM concepts and relevant rules are confirmed by international communities.

A Prototype of eUTM Simulator
The UTM simulator, eUTM, is composed of three components: UOS (UTM Operating System), UTM, and multiple GCSs. GCSs are responsible for generation of flight paths of various UASs. UTM component copies functions of a real UTM such as monitoring and controlling air spaces. UOS provides simulation of environment such as weather, and controls the whole UTM simulator system. UOS also generates operation scenarios of UTM, and resides on the same UTM computer as an independent process. The system configuration and relevant UIs are illustrated in Figures 1-6. Two GCS simulators are connected to the UTM simulator in the present configuration, but the UTM simulator can be expanded to include up to 10 GCS simulators in the present design.  As mentioned in the previous section, real-time 3D visualization capability is needed in the eUTM simulator for VLOS/BVLOS support. Cesium was selected as a 3D visualization platform of geoinformation, which provides open sources and necessary utilities to build 3D visualization of UTM environment, while local navigation and terrain information is streamed from VWorld. Both Cesium and VWorld have to be connected through internet in order to simulate 3D geoinformation in real time.
Development of fantastic deconfliction algorithms is not of concern in this study. The concern is whether eUTM can provide flexibility to test deconfliction algorithms. Among available deconfliction and avoidance algorithms, Barfield's Algorithm [19] was selected for the feasibility study. Barfield designed a comprehensive structure satisfying the requirements of an ACAS (autonomous collision avoidance system). The structure divides the avoidance into two spheres, named deconfliction and avoidance sphere, respectively. In the deconfliction sphere, an aircraft could avoid an obstacle while maintaining its original path and an aircraft should solely escape in the avoidance sphere as fast as possible.
build 3D visualization of UTM environment, while local navigation and terrain information is streamed from VWorld. Both Cesium and VWorld have to be connected through internet in order to simulate 3D geoinformation in real time.
Development of fantastic deconfliction algorithms is not of concern in this study. The concern is whether eUTM can provide flexibility to test deconfliction algorithms. Among available deconfliction and avoidance algorithms, Barfield's Algorithm [19] was selected for the feasibility study. Barfield designed a comprehensive structure satisfying the requirements of an ACAS (autonomous collision avoidance system). The structure divides the avoidance into two spheres, named deconfliction and avoidance sphere, respectively. In the deconfliction sphere, an aircraft could avoid an obstacle while maintaining its original path and an aircraft should solely escape in the avoidance sphere as fast as possible.   build 3D visualization of UTM environment, while local navigation and terrain information is streamed from VWorld. Both Cesium and VWorld have to be connected through internet in order to simulate 3D geoinformation in real time.
Development of fantastic deconfliction algorithms is not of concern in this study. The concern is whether eUTM can provide flexibility to test deconfliction algorithms. Among available deconfliction and avoidance algorithms, Barfield's Algorithm [19] was selected for the feasibility study. Barfield designed a comprehensive structure satisfying the requirements of an ACAS (autonomous collision avoidance system). The structure divides the avoidance into two spheres, named deconfliction and avoidance sphere, respectively. In the deconfliction sphere, an aircraft could avoid an obstacle while maintaining its original path and an aircraft should solely escape in the avoidance sphere as fast as possible.            Figure 1. Figure 2 shows a GCS UI (User Interface), requesting a flight plan. UI is designed based on the rule dictated by KRPASA [20], where information of airspace notice and addresses along with latitudes and longitudes in the designated flight zone can be identified. Figure 3 includes a GCS UI for generation of a flight plan. Waypoints are generated by clicking on the map, and a flight path is composed out of the waypoints. Real-time edition of UAS speeds can be made during the flight. The button "start flight" is clicked to start the flight. Figure 4 has a UOS UI for registration of a flight plan. UOS releases a flight code to the GCS if the plan is approved. If it is not approved, then a message of relevant reasons is delivered to the GCS. Figure 5 shows a simulation control window of UOS. Airspace information is released to a GCS. Operation scenarios can be set such as collision of two UASs by unexpected appearance of a non-registered UAS, geofence collision, etc. In Figure 6, UTM UI is the UAS control window. The control volume of a UAS can be identified in the control window. Command messages of deconfliction maneuver and return flight can be issued for a relevant UAS. Figure 7 includes a GCS connect window. Up to 10 GCSs can be connected. A port and an ip (Internet Protocol) address are assigned to each GCS, which can be edited through the GCS connect window. Each GCS can generate UOS. Airspace information is released to a GCS. Operation scenarios can be set such as collision of two UASs by unexpected appearance of a non-registered UAS, geofence collision, etc. In Figure 6, UTM UI is the UAS control window. The control volume of a UAS can be identified in the control window. Command messages of deconfliction maneuver and return flight can be issued for a relevant UAS. Figure 7 includes a GCS connect window. Up to 10 GCSs can be connected. A port and an ip (Internet Protocol) address are assigned to each GCS, which can be edited through the GCS connect window. Each GCS can generate up to nine UASs, among which one UAS is fully controlled either manually or by autopilot, and the remaining eight UASs fly along preassigned routes.

Integration Issues to Be Resolved
It is imperative to resolve the integration issues in order to develop simulation SW based on open sources and platforms. Most issues are caused by different languages and drivers supporting individual sources or platforms. Drone dynamics and autopilot are based on ArduPilot and MavProxy, which use Python. For real-time simulation of physics, Linux virtual machine in Windows comprises ArduPilot and MavProxy rather than using Windows' own operation environment. For 2D and 3D visualization of maps, airspace information and graphic UAS models from GIS platforms of VWorld and Cesium are streamed and integrated in real time, which uses HTML in Java script. Graphic user interfaces of eUTM simulator are programmed in C#, and the component modules of the UTM simulator are written in C or C++, which are compiled into DLL format. Unfortunately, the Linux virtual machine does not support USB joystick inputs. Thus, some drivers and adaptors have to also be developed in order to integrate the whole system. Some of such efforts are elaborated as follows:  WSL (Windows Subsystem Linux):

•
Communication between real-time dynamics in MavProxy on Linux (virtual machine) and Windows operation program (wpf);

Integration Issues to Be Resolved
It is imperative to resolve the integration issues in order to develop simulation SW based on open sources and platforms. Most issues are caused by different languages and drivers supporting individual sources or platforms. Drone dynamics and autopilot are based on ArduPilot and MavProxy, which use Python. For real-time simulation of physics, Linux virtual machine in Windows comprises ArduPilot and MavProxy rather than using Windows' own operation environment. For 2D and 3D visualization of maps, airspace information and graphic UAS models from GIS platforms of VWorld and Cesium are streamed and integrated in real time, which uses HTML in Java script. Graphic user interfaces of eUTM simulator are programmed in C#, and the component modules of the UTM simulator are written in C or C++, which are compiled into DLL format. Unfortunately, the Linux virtual machine does not support USB joystick inputs. Thus, some drivers and adaptors have to also be developed in order to integrate the whole system. Some of such efforts are elaborated as follows: Generation of weather effects such as snow and rain, using Cesium particle system.  Additional Efforts:

•
Address search function using a commercial portal service (Daum.net) for friendly generation of waypoints; • Generation of waypoint files; • Database management of log information using sqlite.
Resolving aforementioned integration issues, a prototype of eUTM simulator has been realized. Figures 8 and 9 illustrate the overall system configuration and communication among the system components.

WSL (Windows Subsystem Linux):
• Generation of weather effects such as snow and rain, using Cesium particle system.  Additional Efforts:

•
Address search function using a commercial portal service (Daum.net) for friendly generation of waypoints; Cesium: • Communication between Windows operation program (wpf) and Cesium by BindObjectAsync (html to wpf) and web socket (wpf to html); • Asynchronous generation, editing, and deletion of UAS graphic objects and flight paths; • Display of realistic UAS objects of Glb format, including rotating rotors, in Cesium 2D and 3D maps; • Application of VWorld's national airspace information via wms in http to Cesium 2D and 3D maps; • Generation of weather effects such as snow and rain, using Cesium particle system. Generation of weather effects such as snow and rain, using Cesium particle system.  Additional Efforts:

•
Address search function using a commercial portal service (Daum.net) for friendly generation of waypoints; • Generation of waypoint files; • Database management of log information using sqlite.
Resolving aforementioned integration issues, a prototype of eUTM simulator has been realized. Figures 8 and 9 illustrate the overall system configuration and communication among the system components. Additional Efforts:

•
Address search function using a commercial portal service (Daum.net) for friendly generation of waypoints; • Generation of waypoint files; • Database management of log information using sqlite.
Resolving aforementioned integration issues, a prototype of eUTM simulator has been realized. Figures 8 and 9 illustrate the overall system configuration and communication among the system components.

•
Asynchronous generation, editing, and deletion of UAS graphic objects and flight paths; • Display of realistic UAS objects of Glb format, including rotating rotors, in Cesium 2D and 3D maps; • Application of VWorld's national airspace information via wms in http to Cesium 2D and 3D maps; • Generation of weather effects such as snow and rain, using Cesium particle system.  Additional Efforts:

•
Address search function using a commercial portal service (Daum.net) for friendly generation of waypoints; • Generation of waypoint files; • Database management of log information using sqlite.
Resolving aforementioned integration issues, a prototype of eUTM simulator has been realized. Figures 8 and 9 illustrate the overall system configuration and communication among the system components.

Deconfliction Algorithms
Barfield's Algorithm [19] is considered in eUTM as a basic collision avoidance algorithm on UASs. The structure divides the avoidance into two spheres, namely deconfliction and avoidance spheres (Figure 10, Tables 1 and 2). In the deconfliction sphere, an aircraft could avoid an obstacle while still maintaining its original path and a UAS should solely escape as fast as possible while in the avoidance sphere. Other deconfliction algorithms such as ORCA (Optimal Reciprocal Collision Avoidance) and adapted ORCA [21] can also be integrated and tested in the eUTM platform.
In order to determine the minimum turning angle of a UAS, which is predicted to

Deconfliction Algorithms
Barfield's Algorithm [19] is considered in eUTM as a basic collision avoidance algorithm on UASs. The structure divides the avoidance into two spheres, namely deconfliction and avoidance spheres (Figure 10, Tables 1 and 2). In the deconfliction sphere, an aircraft could avoid an obstacle while still maintaining its original path and a UAS should solely escape as fast as possible while in the avoidance sphere. Other deconfliction algorithms such as ORCA (Optimal Reciprocal Collision Avoidance) and adapted ORCA [21] can also be integrated and tested in the eUTM platform. tion and avoidance spheres (Figure 10, Tables 1 and 2). In the deconfliction sphere, an aircraft could avoid an obstacle while still maintaining its original path and a UAS should solely escape as fast as possible while in the avoidance sphere. Other deconfliction algorithms such as ORCA (Optimal Reciprocal Collision Avoidance) and adapted ORCA [21] can also be integrated and tested in the eUTM platform.
In order to determine the minimum turning angle of a UAS, which is predicted to have a potential conflict with another UAS, the simple 2D analysis is made. According to the suggestion of Barfield, three circles or spheres around UAS A are determined with radii r1, r2, and r3, which are for avoidance, deconfliction, and traffic warning, respectively. First, the distance, d, from UAS A to expected flight path (L) of UAS B is determined as in Figure 11. Then the minimum turning angle of UAS B is determined as in Figure 12. Figure 10. Concept of collision avoidance system structure on UAS. Figure 10. Concept of collision avoidance system structure on UAS. In order to determine the minimum turning angle of a UAS, which is predicted to have a potential conflict with another UAS, the simple 2D analysis is made. According to the suggestion of Barfield, three circles or spheres around UAS A are determined with radii r1, r2, and r3, which are for avoidance, deconfliction, and traffic warning, respectively. First, the distance, d, from UAS A to expected flight path (L) of UAS B is determined as in Figure 11. Then the minimum turning angle of UAS B is determined as in Figure 12.

Simulation Scenarios
Now the simulation scenarios are set to support studies regarding pre-flight process, deconfliction study by time and altitude, emergency by unexpected UAS flights, and geofence avoidance. The test scenarios are expandable to comprise additional situations, which are identified to be considered later in Figures 13-16.

Simulation Results (DeConfliction)
Firstly, Scenario #2 in Figure 14 is tested. For demonstration, the altitude of Drone A is changed while Drone B maintains the altitude. UTM identifies the potential collision between two drones, then sends a warning message to Drone A. The GCS of Drone A changes the mode from autopilot to manual control. After completing deconfliction by ascending Drone A, the GCS returns to the autopilot mode and appropriate waypoints on the original planned flight path as in Figure 17.

Simulation Scenarios
Now the simulation scenarios are set to support studies regarding pre-flight process, deconfliction study by time and altitude, emergency by unexpected UAS flights, and geofence avoidance. The test scenarios are expandable to comprise additional situations, which are identified to be considered later in Figures 13-16.

Simulation Results (DeConfliction)
Firstly, Scenario #2 in Figure 14 is tested. For demonstration, the altitude of Drone A is changed while Drone B maintains the altitude. UTM identifies the potential collision between two drones, then sends a warning message to Drone A. The GCS of Drone A changes the mode from autopilot to manual control. After completing deconfliction by ascending Drone A, the GCS returns to the autopilot mode and appropriate waypoints on the original planned flight path as in Figure 17.
Secondly, Scenario #4 in Figure 16 is tested. UTM identifies the potential collision of the UAS with the geofence, and then sends a warning message to the UAS. The GCS changes the mode from autopilot to manual control. After completing deconfliction by changing the yaw angle while maintaining the altitude, the GCS returns to the autopilot mode and appropriate waypoints on the original planned flight path as in Figure 18.  Secondly, Scenario #4 in Figure 16 is tested. UTM identifies the potential collision of the UAS with the geofence, and then sends a warning message to the UAS. The GCS changes the mode from autopilot to manual control. After completing deconfliction by changing the yaw angle while maintaining the altitude, the GCS returns to the autopilot mode and appropriate waypoints on the original planned flight path as in Figure 18.

Aerial EW Application
The GCS of eUTM can also be used for aerial EW studies. In the EW simulation, a UAS flies along waypoints generated by the GCS in the presence of threats such as missiles and radars. Figure 19 illustrates the flight path generated by eUTM. Figure 19. Flight path of a UAS in aerial EW (Electronic Warfare) simulation.

Conclusions
Design requirements of eUTM simulator such as flexibility and expandability are satisfied. The eUTM simulator is modularly designed to accommodate new deconfliction algorithms, registration procedures, and relevant regulations. More complicated operation scenarios can be generated by GCS's control of preassigned UASs in addition to their own UASs. These satisfy the design requirements of flexibility and expandability. The prototype of eUTM simulator can support some UTM services up to TCL 4 or U4, which can be

Aerial EW Application
The GCS of eUTM can also be used for aerial EW studies. In the EW simulation, a UAS flies along waypoints generated by the GCS in the presence of threats such as missiles and radars. Figure 19 illustrates the flight path generated by eUTM.

Aerial EW Application
The GCS of eUTM can also be used for aerial EW studies. In the EW simulation, a UAS flies along waypoints generated by the GCS in the presence of threats such as missiles and radars. Figure 19 illustrates the flight path generated by eUTM. Figure 19. Flight path of a UAS in aerial EW (Electronic Warfare) simulation.

Conclusions
Design requirements of eUTM simulator such as flexibility and expandability are satisfied. The eUTM simulator is modularly designed to accommodate new deconfliction algorithms, registration procedures, and relevant regulations. More complicated operation scenarios can be generated by GCS's control of preassigned UASs in addition to their own UASs. These satisfy the design requirements of flexibility and expandability. The prototype of eUTM simulator can support some UTM services up to TCL 4 or U4, which can be

Conclusions
Design requirements of eUTM simulator such as flexibility and expandability are satisfied. The eUTM simulator is modularly designed to accommodate new deconfliction algorithms, registration procedures, and relevant regulations. More complicated operation scenarios can be generated by GCS's control of preassigned UASs in addition to their own UASs. These satisfy the design requirements of flexibility and expandability. The prototype of eUTM simulator can support some UTM services up to TCL 4 or U4, which can be used to study relevant policies, regulations, deconfliction algorithm, and so on. Some drivers and adaptors are developed in order to integrate the independent sources and platforms such as ArduPilot, MavProxy, Cesium, VWorld, and Linux virtual machine. As a result, eUTM simulator composed of UOS, UTM, and GCS is developed based on open sources and platforms. By adopting ArduPilot and MavProxy, minimum differences lie between real and virtual UTM systems, which implies that simulation results can be applicable to the real world without much discrepancy. Cesium allows universal and realistic 3D visualization of a UTM geoenvironment, not limited to South Korea. VWorld provides information of national airspace of Korea, which cannot be obtained from international geoservices. As a result, a universal UTM simulator has been developed for Korean UTM environment, which can be expanded to other countries, replacing VWorld by other platforms providing relevant air space information. The eUTM simulator uses SW, not designed only for simulation, but for real drone systems. That is, eUTM can be easily converted to a real UTM simulator by changing simulated drones to actual ones. A real GCS can also be realized, replacing drone physics by a real drone system. Of course, the communication among the SW components has to be changed to the real ones in order to realize the actual UTM system.
In order to fulfill the UTM requirements up to TCL 4 or U4, more operation scenarios and deconfliction algorithms need to be included. The present system configuration also needs to be expanded to comprise more GCSs. In order to accommodate sensor-based deconfliction algorithms, inclusion of sensor models is also needed in the future enhancement. There are additional issues to be considered, including boundary management, communication failure, and dynamic airspace configuration, such as dynamic geofences. The eUTM simulator shall be ultimately enhanced to handle integrated air spaces with both manned and unmanned flights.