INTEGRATING UAS INTO THE MANAGED AIRSPACE THROUGH THE 

EXTENSION OF ARINC CLOUD SERVICES

George Elmasry, Rockwell Collins, Carlsbad, California

Diane McClatchy, Rockwell Collins, Annapolis, Maryland 

Rick Heinrich, Rockwell Collins, Cedar Rapids, Iowa

Boe Svatek, Rockwell Collins, Cedar Rapids, Iowa

Abstract

Rockwell Collins is working closely with 

government agencies such as the FAA and NASA to 

extend its service provider portal that offers National 

Airspace System (NAS) services to range of aircraft 

operators to include Unmanned Aerial System (UAS) 

operators. These UAS services, offered in a cloud 

infrastructure, are referred to as WebUASTM. In this 

paper, we will present the WebUASTM architecture --

its layers of security, its adaptability to future FAA 

interfaces, and its organic growth capability as UAS 

applications expands. We will present its current 

architecture serving a scaled system of large and 

small UAS operators and its interfaces to air-traffic 

control. The paper will also show this current suite of 

services applied to representative railroad operations 

-- weather, precision navigation, aircraft situation

display (ASD), temporary flight restrictions and an 

authentication engine. One important aspect of 

WebUASTM is the separation of computational

engines (e.g., authentications engine) from services 

infrastructure and the ability to use different engines 

either developed in-house or by 3rd party vendors for 

the same purposes. Mapping a specific computational 

engine to a service package depends on the service 

package and factors such as minimum cost to 

maximize capability for the specific operational

needs but also use a set of “engine elements” to 

qualify an engine for a service package. In this paper, 

we will cover the “engine elements” studied by 

Rockwell Collins. These engine elements” will be 

applied to the sUAS notification and authentication 

engine currently addressed by the FAA. 

Introduction

Rockwell Collins ARINC offers many cloudbased services to the aviation community. For 

example, ARINCDirect [1] is a Rockwell Collins 

service provider portal that offers National Airspace 

Services (NAS) to business aviation and military 

aircraft operators. WebUASTM is a natural extension 

of our cloud-based service-oriented infrastructures. 

WebUASTM adheres to the FAA rules [2] and is 

organically growing to serve the needs of each 

different UAS operations types. WebUASTM provides 

a service infrastructure with the flexibility to 

incorporate services from 3rd party computational 

engines through agile APIs. WebUASTM is not a 

tactical situational display tool; it is an infrastructure 

that can adapt to the diverse needs of UAS operations 

to include situational awareness, operational 

awareness, resource management, and adherence to 

FAA rules and regulations. All functionality that 

requires any form of computation is modularized 

forming sets of stand-alone tools that can be selected

by WebUASTM. 

Offering UAS services is drastically different 

from offering flight planning and filing services for 

manned aircrafts. UAS services include the 

equivalent of flight following for manned aircraft. 

UAS services will continue when aircraft is airborne. 

Many aspects of our flight following and flight 

management services will be included in UAS 

services. These aspects include conflict probe, 

conflict detection and resolution, flow management, 

capacity planning, contingency planning, surveillance 

data processing, etc. All aspects are expected to be 

met through the use of computational engines.

The WebUASTM cloud has the following 

characteristics:

1- Secure information exchange with computational 

engines, UAS operators and FAA systems. 

WebUASTM provides multilayered firewalling 

hosted in the Rockwell Collins Cyber Security 

Operations Center (CSOC). 

2- Leverages the current FAA interfaces (SWIM 

model [3]) adaptable to future standardization 
sponsored by government agencies such as NASA

[4-8] and the FAA.

3- Computational engines are separated from 

services infrastructure such that third party 

computation engines (e.g., drift calculations, 

weather, and flight authentication) can be used 

seamlessly (in-house or any third party) based on 

the each specific UAS operator’s needs. These 

computational engines can run as an application 

on a server or can be utilized through an API to 

the computation engine vendor. 

4- Dedicates a server for each large UAS operator.

UAS services are integrated into UAS operations 

as specified by the large operator requirements. 

Firewalling the large operator from WebUASTM is 

agreed upon with the operator; dataflow to and 

from the UAS operations to WebUASTM are part 

of a service level agreement (SLA) with the large 

UAS operator. This SLA reflects the FAA rules 

and regulations for the specific UAS operations; 

and the large operator can have an integrated view 

of its operation and the services provided by 

WebUASTM.

5- WebUASTM supports dedicated servers for airtraffic control interfaces. These servers provide 

bi-directional filters passing only relevant UAS 

information to the air-traffic control.

6- For small UAS operators, WebUASTM dedicates 

servers amongst operational types and offers predefined levels of SLAs. Each SLA is developed 

for the specific industry needs. 

7- WebUASTM has a hierarchical architecture that 

can add regional servers for future extension to 

UAS services

This paper presents: (1) critical aspects of the 

WebUASTM architecture with emphasis on its layers 

of security and interface to Air Traffic Control 

(ATC); (2) UAS services to large and small UAS 

operators with the rail operations as an example of 

open architecture, security implementation, 

integration of UAS operation with UAS services; (3) 

the separation of computational engine from services 

infrastructure with the application of “engine 

elements”.

Critical Aspects of WebUASTM 

WebUASTM is hosted in a cloud-based serviceoriented infrastructure and was developed applying

open architecture principals. The WebUASTM cloud 

architecture provides for multiple dedicated virtual 

and physical servers. These servers can be dedicated 

to external interfaces, by UAS operational size and/or 

service type. Our architecture employs agile APIs 

emphasizing modularity to account for future 

requirements and capabilities. External computational 

engine APIs are separated from the service 

infrastructure. Some critical aspects of the 

WebUASTM architecture follow. 

WebUASTM Notional Architecture 

Figure 1 shows a notional architecture of 

WebUASTM Cloud. Please notice the following: 

1- WebUASTM utilizes AviNet® – a Rockwell 

Collins secure global network for airlines and airports 

– to interface to FAA systems. AviNet® is a trusted 

provider of secure connectivity to FAA systems. 

2- The same FAA approved firewalling used with all 

our aviation customers is used with WebUASTM

insuring that UAS operations will meet or exceed 

FAA approved security constraints. 

3- There are national centralized WebUASTM servers 

that are peers to our ASD servers and are under the 

same security constraints as ASD servers. This 

allows for the secure use of ASD data in real time 

with UAS services as needed. 

4- WebUASTM cloud supports regional servers for 

future expansion of UTM service. 

5- WebUASTM cloud supports dedicated servers for 

ATCTs-interfaces. 

6- WebUASTM cloud supports dedicated servers for 

interfacing with other industry partners. 

7- WebUASTM cloud supports dedicated servers for 

large UTM operators such as railroads and power 

lines operators.

8- Any communications infrastructure can be part of 

the WebUASTM cloud. 

9- WebUASTM cloud supports secure links to remote 

operator’s Ground Control Stations (GCSs). 
Figure 1: WebUASTM Notional Architecture

Further security capabilities of WebUASTM are 

discussed below. The WebUASTM cloud extension 

can use dedicated IPSec tunnels or AviNet® links as 

shown in Figure 1. Another extension layer of 

WebUASTM cloud can use secure access over the 

Internet for Ground Control Stations (GCSs) that may 

only have Internet access. 

Interface to ATC 

The WebUASTM service-oriented architecture 

relies on specialized servers to meet specific needs. 

The architecture creates servers dedicated for external 

interfaces. These dedicated servers insure security 

while interfacing to external systems, performing

specific data processing and filtering information that 

are not relevant to the external entity. The 

WebUASTM network can dedicate servers for the 

integration of manned and unmanned aircrafts in the 

airspace. These servers could process UAS data and 

present relevant information to the associated ATC

entities looking at the tactical separation management 

of the integrated airspace. The needs of these ATC 

entities can be met with minimal demands on the 

operator. Relevant UAS data can be displayed on a 

separate screen, or a mix of manned ASD and UAS

data can be displayed for the ATC operator. These 

dedicated virtual servers can also create warnings and 

inform both the air traffic control tower (ATCT)

operator and UAS operators of potential conflicts. 

These dedicated servers can also be used to pass 

messages from the ATCT to UAS operators such as a 

message to abort a UAS flight. 
Figure 2: WebUASTM Interface to an ATCT Operator Showing a UAS Infringing on a Manned Aircraft Flight 

Path 

Figure 2 shows an experimental WebUASTM

interface to an ATCT operator showing a sUAS 

infringing on a manned aircraft flight path (red line). 

Notice that the interface to ATC uses a 

computational engine. An in-house or third party 

engine can be used for this interface and this 

computation engine will be vetted through a set of 

“engine elements”. This paper presents a set of 

“engine elements” created for the sUAS 

authentications engine. 

UAS Services to Operators 

The WebUASTM architecture, cloud-based and 

service-oriented is designed for scalable a la-cart 

capabilities. Dependent upon the enterprise size and 

needs, WebUASTM is tailored for each customer 

requirements. In addition to the standard and relevant 

services envisioned for UAS service suppliers, the 

WebUASTM architecture facilitates add-ons such as 

the ability to monitor and manage private

communication networks for both command and 

control links and payload data. In support of BNSF’s 

pathfinder efforts, Rockwell Collins installed a 

command and control data link network into the test 

ranges. WebUASTM is used to support the command 

and control tower radio monitoring and management. 

A WebUASTM proxy server is currently collocated 

with BNSF’s pathfinder operations center in Playas, 

NM. WebUASTM is integral to the private network 

for radio tower data backhaul and other railroad 

operations infrastructure. WebUASTM is designed to 

support both larger operators likely demanding 

locally controlled proxy servers as well as smaller 

subscribers dependent upon a Rockwell Collins 

hosted and maintained server supporting many 

smaller customers. BNSF has been operating 

WebUASTM for the purpose of radio network health 

monitoring per FAA authorization, beyond visual 

line-of-site (BVLOS) without the use of visual 

observers. The UAS operations management 

component of WebUASTM for large operators 

provides tailorable views for a multitude of users 

both inside the enterprise and selectively outside the 

enterprise.
Figure 3: Notional View of WebUASTM UTM Services to Railroad Operation

Figure 3 shows a notional view of the UTM 

services supplied to railroad operations. The rail 

survey flights, the communications towers and the 

rail operation center are all controlled and operated 

by the UAS operator. Other functions such as 

payload link and data manager, GCS, C2 link 

manager and flight mission planning are also internal 

to the operation center although they interface to the 

local WebUASTM server (proxy server). The firewall 

of the WebUASTM proxy server is agreed upon by 

both Rockwell Collins and the UAS operator. This 

agreement insures that UTM services flow to UAS 

operations and flight information relevant to UAS 

traffic management systems are communicated to the 

WebUASTM cloud, per the agreed upon SLA. Flight 

information relevant to UTM systems can be 

processed and communicated to the FAA and other 

UAS service providers’ networks as needed. The 

WebUASTM cloud brings a bundle of services to the 

UAS operations to include external UTM data and 

services, flight restrictions data, ASD data and 

weather data. Rockwell Collins also uses its in-house 

authentication engine and a precision navigation 

function that aids the railroad UAS operations. 

The concept of using a proxy server at the large 

UAS operator operational facility can be extended to 

the many types of UAS operators such as sUAS 

manufactures who also provide services. Our 

flexibility in packaging services will allow us to cater 

for to each specific need.

The Engine Elements 

WebUASTM is a service-oriented infrastructurefocused cloud. From one angle, WebUASTM uses 

specialized servers for external interfaces and to 

create tailored services for UAS operators while 

relying on firewalling to ensure security. From 

another angle, WebUASTM separates services 

infrastructure from computational engines in order to 

make it possible for UAS operators to select 

computational engines they desire and also to create 

the flexibility to generate service packages for a 

myriad of UAS operations in the future. The type of 

UAS operation, the location of UAS operation 

(sparse versus dense airspace) and many other factors 

can lead to one computational engine being suitable 

for an industry type and location while another 
computational engine developed for the same 

purpose can be more suitable in another location and 

another industry type. 

The concept of separating computational engines 

from services infrastructure has been used 

successfully by other Rockwell Collins cloud based 

services, like ARINCDirect for NAS services [1]. 

Users can chose one flight plaining engine over 

another flight planning engine as part of their service 

package. This concept is even more valuable for UAS 

services due to the different types of UASs, the 

different types of airspace (dense or sparse, flat or 

mountainous, temperate or extremes), and the diverse 

industries planning to use UAS services. In this 

section, we present the engine elements for a sUAS 

authentication engine. The FAA is studying an 

authentication engine as the first step in developing 

sUAS services. Rockwell Collins is developing its 

own sUAS authentication engine, WebUASTM But 

because WebUASTM open architecture supports 3rd

party API, WebUASTM can support both its in-house 

and 3rd party sUAS authentication engines. The 

engine elements discussed herein provides insight 

into how a sUAS authentication engine may be vetted 

to be included as a WebUASTM service package. 

For each computational engine, a set of engine 

elements will be developed. The sUAS authentication 

engine elements include the elements listed in the 

following subsections. 

Comprehensive reference to fenced areas

The FAA has decided that the first step of a 

sUAS authorization is the reference to fenced area 

element. The FAA offers data services for UAS 

restriction facility maps to be used to authorize a 

sUAS flight. The engine element of a comprehensive 

reference to fenced areas (airports, military bases, 

government restricted area, etc ) will be the first 

engine element for a UAS authentication engine.

The ability to make recommendations

UAS flight planning will need more automation 

and must allow for millions of flights to exist safely. 

There are significant differences between manned 

aircraft flight planning and UAS flight planning. For 

example, traditional flight planning considers an 

origin and destination with a trajectory between. A 

UAS operation may originate and terminate at the 

same point and the flight path may be a gridded 

pattern not a linear trajectory. So a flight planning 

engine for UASs will require different planning 

algorithms from manned aircrafts planning engines. 

The algorithms are critical to an ability to make 

recommendations to the operator.

Both manned and unmanned flight planning 

systems will need to accommodate system constraints 

– altitude, terrain, temporary flight restrictions (TFR), 

special use airspace (SUA), air defense information 

zones (ADIZ), etc. UAS flight planning will need to 

consider airport perimeter boundaries that may limit 

operations as mentioned in the previous engine 

element.

An important element of an authorization engine 

for sUAS is to make recommendations to the UAS 

operator instead of rejecting their flight plan. Flight 

plan recommendations capabilities will include the 

following:

1- Change altitude recommendation. Since some 

fenced areas such as those in the vicinity of an airport 

will have a gradual altitude restriction, a 

recommendation to lower an altitude of a sUAS can 

lead to an authorization of a sUAS flight instead of a 

rejection. 

2- Time interval exclusion. As UAS services 

grow, the path of different UAS flights will intersect

even in rural areas. An authentication engine would 

need the ability to exclude certain time intervals from 

one flight plan to allow another flight plan to exist. 

Figure 4: The intersection of Railroad inspection 

flight path with powerline inspection flight path. 

Figure 4 shows an example of rural area where a 

railroad inspection flight path and a powerline 

inspection flight path can intersect. An authentication 

engine would be expected to exclude certain time 

interval from one flight path in order to allow these 2 
flight path to exist. Notice that a third flight path may 

also exist in the same area where a crop duster UAS 

may cross the same area. Time exclusion can be 

expected to work with more than 2 flights plans and 

must be able to access flights plans from all service 

providers in the area.

3- Format conversion. In a dense airspace, time 

interval exclusion may not suffice. An authentication 

engine should be expected to convert a flight path 

from a 3-D format (altitude, latitude and longitude 

weigh points) to 4-D format where a timestamp is 

added to each weigh point based on the aircraft type 

and ability. In essence, this capability extend time 

interval exclusion to as narrow as specifying flight 

time. 

3- Weather-based flight grounding. Under 

certain weather conditions, the sUAS authentication 

engine should be able to recommend flight grounding 

or the abort of ongoing flights for sudden weather 

changes. 

The speed of making recommendations

UAS operators’ requirements can include the 

need to receive flight path recommendations 

promptly. An engine element that quantifies the 

response speed of the authentication engine can be 

used to approve the use of that engine in certain 

operations. 

Airspace status monitoring 

This is a critical component of insuring airspace 

safety and it parallels the NAS ASD data. It is 

therefore a critical sUAS flight authentication engine 

element. This element will measure how well 

airspace is monitored for all operations for all UAS 

types in order to avoid potential conflicts and account 

for nonconforming flights.

Access to special activities 

sUAS operations can be expected to have an 

unexpected events that may trigger the need to abort 

some UAS flights or make changes to their path. An 

example of these unexpected events is an emergency 

landing of a manned aircraft or police and emergency 

operation of sUAS. This engine element will vet an 

authentication engine for its access to these special 

events and its ability to make recommendations to 

ongoing UAS flights (abort or change of path) in 

reaction to these unexpected events. Notice that this 

engine element has a parallel in manned aircraft 

flight operation where a flight path can be changed 

under special conditions. 

Real-time separation assurance in dense air space 

In dense airspace, real-time monitoring of all 

sUAS activities and the ability to create ground-based 

separation assurance [9] may become a critical 

engine element for sUAS authentication. Notice that 

there are no approved flight plans that can be used as 

with NAS services. The future may bring a database 

of securely separated routes and the authentication 

engine may need to assign UASs to routes and 

monitor conforming to the assigned routes or more 

autonomous algorithms may be accepted by the FAA. 

Regardless of these requirements emerge, the ability 

of an authentication engine to assure real-time 

separation in dense airspace may become a critical 

element. 

Regional versus national flights 

As UAS services grow, the selection of an 

authentication engine for certain operators may 

depend on the region or area of operation. In the 

future, authentication engines may be required to be

area focused.

Industry type 

sUAS operators may have specific requirements 

that may be met with one authentication engine over 

another. This engine element may become a 

discriminator in engine selection for the type of 

operation. 

Route optimization 

Specifically for long range flights, route 

optimization will become an important engine 

element for sUAS authentication. This will tied with 

the ability to make recommendations of flight path 

change in order to optimize the route for factors such 

terrain and weather effects. It will be necessary for 

long range UAS flights to avoid turbulence. 

Collaborative decision making 

As the airspace becomes denser; as different 

UAS service providers merge; and as UAS aircraft 
capabilities develop, sUAS authentication engines 

will require a collaborative decision making 

interface. The engine interface will collaborative 

decision making and will include the use of 

negotiation protocols with different UAS service 

providers and with the aircraft types. 

Graphic depiction of recommended routes 

It is critical for the UAS operator to be able to 

visualize the recommended routes facilitating optimal 

route selection from a set of recommended routes. 

WebUASTM will depict these recommended routes to 

the operator but the authentication engine will be 

expected to make graphic depiction user friendly. An 

engine element will quantify the graphic depiction 

ease and how helpful it is for the UAS operator. 

Prediction and warning capabilities

This engine element will measure the proactive 

capabilities of the authentication engine [9 - 10]. As 

actual flight path deviates from a planned route, the 

risk of airspace collision is increased. As airspace 

density increases, the ability of an engine to analyze 

current situational data and create escalating 

warnings that can prevent potential accidents will 

become a critical engine element.

Summary

This paper presented a cloud-based serviceoriented infrastructure for the UAS domain referred 

to as WebUASTM. We presented how WebUASTM 

creates a multi-layer of security in its architecture and 

how the service provider infrastructure is separated 

from interfaces to the FAA and other external 

systems as well as the separation of computational 

engines from services infrastructure.

The paper presented critical aspects of 

WebUASTM with notional architecture that shows the 

layers of this service-oriented cloud. The paper also 

presented how WebUASTM dedicates servers for 

ATC interfaces and how services are provided to 

large and small UAS operators. 

A special focus of this paper was regarding the 

engine elements that are created for each 

computational engine and vetted to be used with 

WebUASTM. A set of engine elements was created for 

each computational engine type and is used to vet and 

map each engines use to a specific service package. 

The paper focused on the sUAS authentication engine 

as an example of how each engine elements are 

created and can be used to vet a computational 

engine. 

As the standards of UAS services evolves, 

WebUASTM will evolve and will be able to account 

for future capabilities through its open cloud 

architecture, dedicated servers or virtual servers, and 

the separation of computational engines from each 

service infrastructure. 

References

[1] https://www.rockwellcollins.com/arincdirect

[2] https://www.faa.gov/uas/

[3] https://www.faa.gov/nextgen/programs/swim/

[4] https://utm.arc.nasa.gov/docs/Rios_DASC_1570

265251.pdf

[5] Prevot et. el., 2016, “UAS traffic management 

(UTM) concept of operations to safely enable 

low altitude flight operations,” Proceedings of

the 16th AIAA Aviation Technology, Integration, 

and Operations Conference, no. AIAA-2016-

3292.

[6] Kopardekar, 2014, “Unmanned Aerial System 

(UAS) Traffic Management (UTM): Enabling 

Low-Altitude Airspace and UAS Operations,” 

NASA Technical Memorandum, NASA/TM2014-218299.

[7] Kopardekar et, el., 2016 “Unmanned Aircraft 

Systems Traffic Management (UTM) Concept of

Operations,” Proceedings of the 16th AIAA 

Aviation, Technology, Integration, and

Operations Conference.

[8] Rios, 2016, “UTM Client Interface Control 

Document,” version 2.0, NASA Ames Research 

Center.

[9] https://utm.arc.nasa.gov/docs/Denney_DASC_15

70263561.pdf.

[10] Ishihara et. el., 2016, “Rapid Trajectory 

Prediction for a Fixed-Wing UAS in a Uniform 

Wind Field with Specified Arrival Times,” 

Proceedings of the 16th AIAA Aviation, 

Technology, Integration, and Operations 

Conference.
Disclaimer

The information presented in this paper contains

the views and opinions of Rockwell Collins engineers 

who are working on forward looking concepts for 

UAS services and is not necessarily the current views 

and policies of Rockwell Collins or any of its 

subsidiaries.

Email Addresses

george.elmasry@rockwellcollins.com

diane.mcclatchy@rockwellcollins.com

richard.heinrich@rockwellcollins.com

boe.svatek@rockwellcollins.com

2017 Integrated Communications Navigation 

and Surveillance (ICNS) Conference

April 18-20, 2017